Dependence on Programming Experts

[Richard Gaskin]

Rob Cozens wrote:

>>The proposed assignment OPTION is consistent with several dozen 
>>languages, many of which are still actively growing a strong rate, 
>>as opposed to Pascal which is the only one which uses Pascal-style 
>>assignment and is in rapid decline today.
> 
> The proposed OPTION would eliminate my current OPTION to replace code like:
> 
>    if recordNumber = 1 then set the disabled of button 
> "Previous Record" to false
>          else  set the disabled of button "Previous Record" to true
>          if recordNumber = recordCount then set the disabled of 
> button "Next Record" to false
>          else  set the disabled of button "Next Record" to true
> 
> with
> 
>          set the disabled of button "Previous Record" to (recordNumber = 1)
>          set the disabled of button "Next Record" to (recordNumber = 
> recordCount)
> 
> and break every script where I use this structure.
> 
> I can't believe you find the need for this OPTION so great that you 
> would advocate breaking existing syntax.

Not at all.  I've tried (though apparently failed) to express that I 
changed my opinion over the years to come to favor more consistent 
support for "=" as an assignment operator based on two factors:

- It needn't break any existing syntax
- It already exists in Transcript

This second point is critical to this discussion, yet somehow overlooked 
in half the posts here.  What's on the table is not to make anything 
new, but merely to make something that's already in place more consistent.


Statements begin with a command, and are parsed according to what's 
expected based on that command.

Statements beginning with "if", "set", or really anything that isn't a 
variable name or type declaration (such as those in the example above) 
would not be affected by making support for "=" as an assignment 
operator more consistently supported.

Currently when the command is "constant" then "=" can be used as an 
assignment operator.  But currently this only works in a script-local 
context, and all other variable types and contexts are arbitrarily 
excluded from using this assignment operator.  The current partial 
implementation introduces a "sometimes" rule into the language, and such 
rules make learning unnecessarily difficult.

The proposal at hand would make the language simpler and more 
consistent, and not break any existing code, by simply allowing 
assignment when the first word of a statement is a variable name, and 
removing the arbitrary restriction of its usage to script-locals only.


To the best of my knowledge, there is currently no context other than 
the proposed in which a statement can begin with a variable name, thus 
no conflict with existing usage.  If we find an exception to that I'm 
sure we could just as easily come up with a rule for the compiler to 
account for it.  After all, this isn't exactly splitting the atom; 
dozens of languages have allowed this assignment operator for many 
years, even languages that also use that token for comparison, so it's 
not like it really requires much in the way of invention.


Some here may be glad to hear this will be my last post on this subject. 
I haven't said much new since my first post in this thread, and I trust 
I've restated things enough since then that anything I could hope to 
contribute is about as clear as I can make it.  If anything more needs 
to be said I'll leave that to better writers....

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com