What is "Open Language"?
Richmond
richmondmathewson at gmail.com
Mon Oct 26 14:08:56 EDT 2015
On 26/10/15 11:00, Mark Waddingham wrote:
> 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.
>
+1
As 'hilite' is the de facto standard, whether anyone likes or not, that
would seem to be the one to stick with.
I feel similarly about all those North Americanisms: speaking as someone
who was born in Scotland, spent all his school days
in England, and holds a Masters degree (in Linguistics) from a
University in the States, although instinctively my lip curls at
American spellings, I am well aware that:
1. That is nothing more than my cultural subjectivity.
2. American English IS the dominant form of English in the world right
now (and probably for the forseeable future).
So "bu**er" [not, that isn't 'butter'] the British spellings and stick
with the Americanisms . . .
And, quite frankly, if somebody really starts banging on about "British"
spellings [i.e. English English spellings] I shall get
awfy thrawn anent Scotticisms; qhilka dae nae fowk onie guid at aa!
What might be a GOOD IDEA is to work out all the synonyms for each term
in LiveCode [no, I will not, I am not THAT nerdy or a*al]
and list them against a term: so, for instance, if someone searches for
"colour" they will come to a section in the dictionary that
basically states 'for "colour" => "color" '.
Personally, while I am very proud to be a Scot (mainly because I live
and work in Bulgaria: go figure), that does not mean I am
anti American usage.
Polyglottism is all very well and fine, but it would bring the LiveCode
engine to its knees: and I, for one, am not prepared to wait
20 minutes for some script to execute, which currently takes 10 secs,
because the thing has to trawl through endless look-up
tables of variant spellings and words: a dish made with aubergines is
still a dish made with eggplants even if the chef calls
them brinjals, melongenes, guinea squash or whatever: so let's all call
then 'eggplants' (the American word) and be done with it.
Richmond.
More information about the use-livecode
mailing list