Keyword Spelling Consistency

[LCMark]

In a different thread (about 'the properties') a topic came up about the spelling of 'hilite' used in the engine - this turns out to be rooted in HyperCard which allowed 'hilite', 'hilight' and 'highlight'.

Given that we are going to be getting a new parser and the opportunity (through script translation) to change things such as this it is perhaps the time to start considering whether such varieties of choice are needed/wanted or whether we should settle on saying that all keywords should be spelt according to a particular reference dictionary (which would have to be standard US English really - due to heritage and I believe that it's the most written variant of English around the world).

I've never been particularly comfortable with synonyms in general (particularly as they reduce future syntax options - for example, 'clear' is currently a synonym for 'delete' but 'clear image' has an obvious meaning that is very different from 'delete image'); however, variant spellings don't have this problem since they would all be the 'same' word.

[ The way I see such 'variant' spelling support implemented would be by requiring (as a matter of policy) that the BNF rules for the syntax only use the preferred variant in each case, but it would be possible to specify separately that, say, 'hilite', 'hilight' and 'highlight' all map to 'highlight' ]

What do people think?

[FourthWorld]

I also prefer fewer options. I believe having too many options can actually make it more difficult to learn a language, since it raises expectations for some tokens that can't be met by others. Learn one, use it, move on.

[monte]

Reducing number of synonyms seems a good move... different spellings could be reduced to some kind of word expansion thing in the script editor.

The whole US spelling thing is a bit annoying for me (must be the same for you) where every time I type behavior or color it's marked as a spelling mistake... maybe I should change the language on my computers???

What about abbreviations (grp, btn etc)?

[LCMark]

The whole US spelling thing is a bit annoying for me (must be the same for you) where every time I type behavior or color it's marked as a spelling mistake... maybe I should change the language on my computers???

It was for a few months when I first started at RunRev - eventually I got use to using US English spellings at work and British English spelling everywhere else (a bit like I can now easily switch between Mac and Windows keyboard layouts without thinking). I can't really find fault with the rationale - those of us that use British English spellings natively are in a minority.

What about abbreviations (grp, btn etc)?

Personally, I hate those - particularly in the current syntax where you can do things like:

Code: Select all

  btn 1 grp 2 card 3 wd "foo"

I do hope we can 'get away with' removing those abbreviations in the 'clean' syntax - particularly as the new parser will quite elegantly allow comprehensive auto-complete so the argument of 'but _button_ is too much to type' goes away... (*ducks from opening can of worms at the suggestion of removing such...* ).

[monte]

I don't like them but I find myself using them all the time... I'd be happy for the parser to translate them into their full length variants... They were invented before auto-complete so perhaps become redundant if we get that... Still... the auto-complete might need some synonym expansion in it... btn wouldn't normally auto-complete to button but it could be expanded to button...

[mwieder]

I also prefer fewer options. I believe having too many options can actually make it more difficult to learn a language, since it raises expectations for some tokens that can't be met by others. Learn one, use it, move on.

@Richard- Here's why I brought up the "hilite" thing in the first place: you can use "hilite" and "highlight" interchangeably in some places but not in others, and I think that's an impediment to learning the language. Can you, from memory, describe where you can and can't use "highlight"? Here's one:

You can reference the highlight of a radio button or the hilite of a radio button

but if they're in a group, you can reference the hilitedButton of the group, but not the highlightedButton of the group.

[mwieder]

I hate abbreviations as well, and convert them every time I have to work on someone else's code.

You cannot make another post so soon after your last.

[Janschenkel]

I vaguely recall using abbreviations in HyperTalk because it made code smaller and parse faster. Back in the late 1980s that still mattered.
But if I see how quickly a complete LiveCode build in Xcode executes on my Mac, I wouldn't lose sleep over it any more

Jan Schenkel.

[LCMark]

I vaguely recall using abbreviations in HyperTalk because it made code smaller and parse faster. Back in the late 1980s that still mattered.

From what I understand (or at least have been told), (early versions of?) HyperCard didn't compile code into an internal representation - so every time it executed a command it would have to re-tokenize. If this is the case, then it would make sense why such abbreviations were the norm.

Since LiveCode parses scripts into an abstract syntax tree when you set 'the script' (or a script is used for the first time after load), how many characters you have in your tokens or variables makes no difference at all. (Handler names potentially in the past - but a couple of versions ago we switched to using uniqued names - MCNameRef - and binary search so now its just a pointer comparison to check for equality of those internally).

[LCMark]

You can reference the highlight of a radio button or the hilite of a radio button
but if they're in a group, you can reference the hilitedButton of the group, but not the highlightedButton of the group.

Ah! Now I see why you found it so vexing - I didn't actually realize that. If we have a 'hilite' and 'highlight' as synonyms right now, then there's no reason not to add 'highlightedButton' as a synonym. Particularly if we are looking towards adopting 'highlight' as the one true way...

[monte]

Maybe HC had a limitation on the length of property names so hilite was invented specifically so hilitedButton made sense?

[mwieder]

Ah! Now I see why you found it so vexing

Exactly... "highlight" is a synonym" for "hilite" but "highlighted" is *not* a synonym for "hilited".
I always write "the highlight of" and then end up tripping over "the highlightedNNN of".

[FourthWorld]

After 25 years of habits, if you take my abbreviations away I'll scream.

But if you give me an IDE that lets me type as I'm accustomed and automatically changes it into some more "correct" form I'll stop screaming after only a few minutes.

And if you can quantify the speed difference for disallowing my well worn habits my screaming will be that much shorter.

Kinda funny to read a thread about the language getting smaller after the long thread on the use-livecode list a couple months ago in which folks were all excited about using the new "open language" initiative to invent 37 different ways to set a property.

I'll get over it. Just put in earplugs for a moment when that version comes out, but do whatever you can do to boost performance.

[monte]

Yeah... it will definitely need a smart script editor otherwise half of us will go nuts.

[mwieder]

half of us

Cool. Then that should make a complete set.