What is "Open Language"?

[Mark Waddingham]

On 2015-10-24 22:47, Mark Wieder wrote:
> On 10/24/2015 12:21 PM, Peter TB Brett wrote:
> 
>> * hilite -> highlight
> 
> Actually I filed a bug report on that six years ago.
> http://quality.runrev.com/show_bug.cgi?id=8211
> 
> It got confirmed and ignored.
> I just submitted a pull request.
> Figured I might as well fix this myself.

There's a slippery slope here (in terms of the current engine parsing 
implementation at least) which means that just adding synonyms because 
the lack of them 'annoy' a small set of people (and/or because you can) 
really isn't something which makes sense.

It is clear that originally 'hilite' was the chosen spelling for that 
operation - it is an 'informal' spelling of 'highlight' which has been 
historically used in GUI frameworks (probably because it is a good deal 
shorter than 'highlight' - something which those who are fond of 'grp', 
'fld', 'ac, 'cd' etc. should feel at home with ;))

There was obviously clearly some contention over whether 'dehilite' or 
'unhilite' should be the antonym - given that even 'dehighlight' nor 
'unhighlight' tend to appear in dictionaries this is probably not 
surprising.

So, clearly someone 'complained' at some point (which is probably why 
dehilite and unhilite both exist) and 'highlight' was added. Indeed, 
there are actually the following fundamental synonyms for 'hilite' in 
the engine:
   - highlight
   - highlighted
   - highlite
   - highlited
   - hilite
   - hilited

So that is 6 ways to write exactly the same thing. (It gets better in a 
moment)

We now have the following 'compound' property names involving 'hilite':
   - hiliteborder
   - hilitecolor
   - hilitefill
   - hiliteicon
   - hilitepattern
   - hilitepixel

We also have the following 'compound' property names involving 
'hilited':
   - hilitedbutton
   - hilitedbuttonid
   - hilitedbuttonname
   - hilitedicon
   - hilitedline
   - hilitedtext

There are also the following 'other' properties:
   - autohilight
   - autohilite
   - linkhilitecolor
   - multiplehilites
   - noncontiguoushilites
   - sharedhilite
   - showhilite
   - threedhilite
   - togglehilites

So, there are (in fact) the following variations on 'hilite' currently 
in use in the engine:
   - hilite
   - highlite
   - hilight
   - highlight

Which, if accounted for in synonyms would mean we would end up with (I 
believe) 72 keywords if we ignore the 'ed' forms, and 144 if we have 
both the preset and past participles. Also, it means that every time 
anyone wants to add a property containing 'hilite', they need to add 4 
(maybe 8) variants. This kind of 'blow-up' suggests that there is 
something wrong with the approach.

So, I do think that in this case it would be far better to *choose* what 
variant spelling is the normative one and deprecate all the other 
synonyms at least until there is a much better mechanism in place for 
parsing and resolving synonyms (i.e. when compound properties are 
specified as separate words, and synonyms are substitutions done as a 
pre-processing step).

For anything like there has to a policy and my policy has always been - 
you choose a single representative for a single concept and you stick to 
it. In this case 'hilite' is a perfectly valid word to use (given its 
domain - i.e. GUIs); indeed, it is just as valid a choice for 
'highlight' as 'color' is for 'colour' and 'behavior' is for 
'behaviour'. At the end of the day this is a computer language and as 
such logical and sensible choices have to be made. (One could also argue 
that the problem of synonyms and abbreviations is far better handled in 
the script-editing environment... Although nobody ever seems to agree 
with me on that one - even though the resulting effect would be 
identical for all intents and purposes ;)).

Now, I'm not saying this won't change - clearly there is a want for 
synonyms as a fair few people seem quite fond of them. However, there 
needs to be a good mechanism in place to deal with them in the engine 
and there currently is not (particularly when considering compound 
forms) so caution is hugely advisable.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps