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.
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. 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). There is no easy way to administer synonym additions centrally and each one increases the maintenance burden in the current architecture. So the only 'synonyms' which it makes sense to adopt right now are the ones which help move the current syntax to having a consistent and sensible canonical form which is easy to document and explain. This allows, in the future, for a far more general and decentralised way to tailor syntax *in general* whilst ensuring there will always be one canonical form to which scripts can be translated to enable them to be compiled and (more importantly) be translated to people's preferred form. 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'... However, I'd point out that the primary reason for the architecture to allow that is specifying custom syntax, and non-English language variants. The fact that the 'synonym problem' would also be 'fixed' by it Is but a happy by-product. Warmest Regards, Mark. Sent from my iPhone > On 26 Jun 2017, at 18:59, Mark Wieder via use-livecode > <use-livecode@lists.runrev.com> wrote: > >> On 06/26/2017 03:55 AM, Mark Waddingham via use-livecode wrote: >> >> I think it is probably generally true that the more consistent and simpler >> the language is, the easier it is to learn. > > ...and I would follow that with the (long-running by now) argument that > synonyms provide for an ease-of-use facility in coding and therefore a > simpler approach to using the language. For the trivial case here, if I can't > remember whether the language supports "is" or "=" for variable assignments, > I can use one or the other without having to interrupt my train of thought to > look it up in the dictionary/guides. > > One of LiveCode's strengths is the fact that there are many possible > solutions to a given problem, and the xtalk language allows much flexibility > in solving it. For a problem placed before any three coders, you will find at > least four different solutions. Limiting the language limits the ways in > which a problem may be thought of - that's the basis of the linguistic > relativism, and it applies to programming languages as well as to natural > languages. > > -- > Mark Wieder > ahsoftw...@gmail.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
