When I was thinking about unquoted literals I was thinking about string 
literals, something like
put one into counter
put one into two

Numeric literals don’t offend the senses:
put 1 into counter

In the case of property assignments I could be persuaded either way:  that 
there is a global constant left that means “left” (making it a reserved word), 
that in the context of certain properties, certain string values are constants 
and not containers (not as ideal since there is then also going to have to be a 
warning to the user that their container called “left” is not going to work in 
the context of the property), that we’re going to have to quote “left” (also 
not ideal), or that we’re going to allow unquoted string literals in property 
assignments (but then we are back to the parser/lexer really should error check 
 assignments for some properties so someone doesn’t set the align to tpo unless 
tpo had previously been used and/or assigned a value, and therefore appears in 
the symbol table).  The last one gets us back to having the parser/lex doing 
some spellchecking or symbol lookup.

Deprecating “features” is often the right thing to do because it cleans up 
kluges that are no long necessary, and clarity and simplicity and order are 
restored.  Yes, that means that some code will be affected and have to be 
reworked.  It’s either that or n00bs need a separate note in the dictionary for 
every kluge, the same way that non-native English speakers get to fight through 
every exception in spelling and punctuation.  I sometimes mention the running 
joke in 4D, “The Tao”, a collection of all the things that are counterintuitive 
that you have to work around.
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to