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@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
_______________________________________________
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
