synonyms

[Richmond Mathewson]

On 6/26/17 11:07 pm, J. Landman Gay via use-livecode wrote:
> Just please don't remove the ones we've got. I haven't typed out 
> "background" or "card" in 30 years. My brain would short out.

I wonder if it is about time in this discussion to differentiate between 
*abbreviations* and *synonyms*?

Richmond.
>
>
> On 6/26/17 1:48 PM, 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.
>>
>> 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 at 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
>>> ahsoftware at gmail.com
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at 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 at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>