synonyms

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps