On 2017-06-26 21:34, Mark Wieder via use-livecode wrote:
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 "
If the autocomplete mechanism is good enough then it could it would come
up with a list like:
'then'
'is <expr>'
'contains <expr>'
...
Of course, there would be a big list in this case (as there are quite a
few operators); however, other contextual information can be used to
order it (e.g. how often had you used operators in the current script)
and implicitly computed type information could help cut down the list to
the things that would actually work.
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.
Indeed - there are 'different cases' of synonyms - this would fall into
the class of spelling variations. However, the point there was that a
specific variation had already been chosen - 'hilite' - for better or
for worse.
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.
No - of course I wouldn't - but then this just goes to show that the
'synonym' thing is a great deal deeper than it appears at first sight.
Already in this thread the following three kinds have been noted:
- abbreviations
- spelling variations
- functional synonyms
Of these, only the last can truly be called 'synonyms' - and they are
more complex than the other two as they *should* be context dependent
(but cannot be at the moment).
Abbreviations people probably wouldn't notice the lack of direct support
for in the language if the tooling auto-expanded them.
In terms of spelling variations choosing *one* and sticking to it in any
particular project is really important otherwise you can create subtle
bugs which are virtually impossible to spot (e.g. using 'colour' as a
key in an array in one place, but 'color' in another).
I normalized my spelling to US English when coding quite early on after
starting at LiveCode - however, you can still see inconsistent vestiges
lurking around in various places. Color wasn't so bad to move to as I'd
already had that battle at the age of around 6 when playing with Amiga
BASIC on my grandfather's computer and not being able to figure out for
the life of me why I kept getting 'syntax error' in my code... It was
because I was typing COLOUR and not COLOR. However, 'Behavior' took me a
fair bit longer!
Having submitted several rejected PRs for synonyms I can vouch for the
fact that they're not that hard to add.
Just because something is 'easy' doesn't mean it is 'right'. (It is easy
to knock down walls in a house with a big enough hammer - but you might
not end up with a house afterwards!).
The point here is that the architecture we currently have for synonyms
is woefully inadequate as it is global - if you apply a synonym to one
property token then it is that way for all uses of that property,
regardless of where they are.
For example, for one type of 'thing' the two words 'purge' and 'delete'
might well mean the same thing... However for another type of 'thing'
they might not.
That may be the basis of our disagreement then... I'd prefer that
everyone *not* be stamped from the same mold.
It is not about stamping everyone from the same mould - however, for
people to work together well and efficiently you need consistent
communication.
In the world of programming, the code is the primary means of
communication so ensuring that is consistent amongst any one group or
team produces big benefits.
As I already said I am against synonyms being part of the *core*
language as they only add friction at level, and do not help (the 'core'
of anything should be only as large as it needs to be to express
everything built on top of it). However, I have no issue with them being
available as tailorings - we just aren't quite at the point where this
is usefully possible.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
