synonyms

[Mark Wieder]

On 06/26/2017 11:48 AM, Mark Waddingham via use-livecode wrote:
> I'm against synonyms being part of the core language - they have no place there as they are 'tailorings'. Indeed a good part of the argument for them could be solved by better tooling - e.g. autocomplete and suggested tokens if one isn't quite right.

Heh. Autocomplete, I think, works well when you already have an idea 
where you're going. I don't think it would help much with a line like

"if x "

You and I have this discussion about synonyms regularly, and I don't 
expect that either of us will ever convince the other. I'm happy that 
you are the one in charge of shepherding the language, and I'll continue 
my role as proponent from the sidelines.

> 
> Every single property in the engine could have synonyms and some many (see the recent discussion about clipsToRect). An attempt to 'normalise' hilite and its various compound forms would have resulted in 40 (iirc) additions to the token table.

My PR for 'hilite' wasn't to 'normalise' the term, but to be consistent 
about its use. To this day I can't remember where 'highlight' is 
acceptable and where 'hilite' is proscribed, my distaste for 'hilite' as 
a word notwithstanding.

> Moreover every single synonym reduces the set of possibilities of things we could add in the future and can cause backwards compatibility issues in existing scripts (as they become for all intents and purposes reserved).

Point taken, but do you seriously believe it would be a good idea to 
have different meanings for "hilite" and "highlight"? I can't imagine 
that repurposing either of these for the same syntax would help in 
anyone's comprehension of the language or ease in scripting. Making the 
two words synonyms is the only thing that makes sense to me.

> There is no easy way to administer synonym additions centrally and each one increases the maintenance burden in the current architecture.

Having submitted several rejected PRs for synonyms I can vouch for the 
fact that they're not that hard to add.

> So, I get the reasoning behind them (although I still think it better to train people implicitly to use canonical forms via better tooling, as if everyone 'sings' with the same language, uniform understanding is increased) so in the future everyone will be able to 'knock themselves out'...

That may be the basis of our disagreement then... I'd prefer that 
everyone *not* be stamped from the same mold.

-- 
  Mark Wieder
  ahsoftware at gmail.com