[Comment/Suggestion] The Definition Operator

[ChristoferK]

I couldn't find much background about the considerations underpinning the earlier decision to swap out -> for is as the definition operator, which will potentially be very relevant in what I am aware might sound like I'm framing to be a simple Find/Replace... job. But, for now, I'm providing the following comments within the context of an ideal world:

Comment

The definition operator ought not to be is

Justification

1. It is not easy-to-read

As a single entity and a word in the English language, "is" is undeniably easy-to-read for a lot of people. Placed within lines or paragraphs of code, a lot of which will be comprised of other latin-based strings, it suffers from being paradoxically too easy-to-read (and instinctively not processed during a skim-read), thus making it more difficult to read quickly and efficiently, and forcing one to engage more cognitively to dissociate from linguistic context to a non-linguistic context but one in which it's intentionally mimicking a linguistic approximation in a jarring way. Linguistics aside, as initially alluded to, it is easy to lose among a group of other strings that camouflage its occurrence.

2. It's a misappropriation

It is the singularly-defined syntactic form for an operator that takes on the appearance of an English word in a language that, otherwise, has no other hard-coded entities we would be required to invoke that parallel a meaningful relationship between a coding language one would otherwise be free to cultivate esoterically dissociated syntax divorced from a spurious linguistic connotation hinted at by such a specific choice of entity. Somewhat frustratingly, it uses that word which, in English contextual prose, seldomly crops up in its copulative (relational) state: "is" is most often used intransitively, which underpins the previous argument; here, it copulates one clause to bond it relationally to another, which is, indeed, what would be valid grammatically when speaking, most typically in mathematical (and computer science) discussions as a loose-and-free way to infer equality, but never in formal usage. The overall effect is one that has borrowed a well-recognised object commonly used in one way, to crowbar it into an unrelated situation where its less-common form serves a proxy for a muddy-sounding description of what purpose it is intended to serve.

3. It's language-biased

"is" is specifically taken from English. Aside from those on the team likely having English as a common language between them, there's no need or reason to impose that on those who'd not want that. Other programming languages do this, rightly-or-wrongly, because of the industry that is driven by English-language developers, necessitating anyone wishing to develop professional basically have to deal with that. But that's part of what what XL appears to free itself from the burden of formally pre-defined syntax of procedural code where things have names and names ended up English-like. However, imagine how really weird it would seem to have a programming language where everything semantically or syntactically was curated by the coder, except for the one appearance of the Mandarin word 為 (wèi). We'd live, and I would probably use it to define a synonym to serve as a definition operator, if that is possible (and, if so, it still undesirable).

Suggested Solution

Use a symbol that is representative, without being language-specific. It might be additional effort to implement an accessible way to type special symbols from selected unicode blocks, but that could be a worthwhile endeavour in the long-run for a language untethered from what one conventionally sees on their keyboard's keys.

1. The most obvious would be to revert back to the symbolic arrow ->.

2. To be distinct, whilst remaining familiar, another unicode arrow form could be used. Given the nature of the operator is effectively (in mathematical terms) a functional mapping of syntax onto an operation, the most representatively authentic arrow form might be ↦ (the maths symbol for maps onto, e.g. 𝑓﹕𝑧 ↦ 𝑧² + 𝑐) but doesn't print well in some fonts.

   Other symbol suggestions:

   • ⇒ ("implies"), or the keyboard-friendly => which we all know from JS
   • ≔ (a familiar definition operator used in other languages) or the easier-to-type :=
   • ⧴ (no idea)
   • ⁑ a symbolic, decorative colon
   • ≡ ("is equivalent to", but would prevent it being defined for use as a mathematical operator)
   • ➔ an arrow that prints consistently well, which I have on shortcut

3. Create your own symbol and stick it in a reserved block of the unicode table the compiler can access.

[FrozenVoid]

Typing 'is' is much easier than -> (- shift.), typing the unicode symbols proposed above would require frequently using the numpad or ui dialogs to insert specific unicode characters for each definition.

[ChristoferK]

Typing 'is' is much easier than -> (- shift.)

This doesn't seem more significant nor more impactful than any of the justifications I outlined.

It also isn't true as an assertion: it presumes that these are the only characters one would be typing. If you take a whole script and define any sort of metric that quantifies the cumulative difficulty of every keystroke required to produce it, it immediately shows that there is approximately zero differential between is and ->. This myth is pervasive and often cited by programmers, but it is demonstrably false, having become true only by virtue of how often it is said.

typing the unicode symbols proposed above would require frequently using the numpad or ui dialogs to insert specific unicode characters for each definition.

I think anyone who is familiar enough with a computer—particularly anyone who has even a passing interest in scripting (or coding of any nature)—knows how to define a simple keybinding in their OS that negates this concern completely. I have one already implemented that makes typing → even "easier" than typing is.

That, of course, is just one possible solution to a very small problem. A small amount of imagination will almost certainly yield many more possible solutions.

Don't forget, also, that, if I recall, is is the only pre-defined operator in the language. Therefore, the definition operator easily be : or =, which each require a single keystroke (with <shift> in the case of the colon) and are both readily available on all latin character-based keyboards.

[FrozenVoid]

I have to agree here, = would be actually more appropriate, as most languages with C-syntax use it for defining/setting lvalue objects/variables and its shortest to type.

[c3d]

On 17 Dec 2020, at 07:31, FrozenVoid notifications@github.com wrote:

I have to agree here, = would be actually more appropriate, as most languages with C-syntax use it for defining/setting lvalue objects/variables and its shortest to type.

= means equality. The fact that C and other languages use it for assignment is a frequent cause of confusion for beginners. Who has not written "if (a=b)" at least once?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/c3d/xl/issues/42#issuecomment-747240317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM6BNDZGNI4E4FFRP7IPQLSVGQT3ANCNFSM4S253HQA.

[dumblob]

Anything non-ASCII is a no go for many reasons. And regarding the mentioned reasons for changing is to something else I don't find them as decisive as they sound.

Despite me generally prefering using a symbol to distinguish an important "cut" in the otherwise linear source code (and this case definitely is an important "cut") I don't think it does much harm in XL. Just read the source and you won't feel uncomfortable with it (there are enough of other symbols so the code doesn't feel messy because of is).

is is also easily searchable because there is surprisingly small overlap with english and other languages (even transliterated text!), so no problem even here.

Just my 2 cents.