Dependence on Programming Experts

[Alex Tweedly]

Kay C Lan wrote:

> On 7/14/06, Alex Tweedly <alex at tweedly.net> wrote:
>
>> If there was any context where either could appear, there would be an
>> ambiguity - but there isn't.
>
>
> So assuming the new syntax was adopted:
>
> x = 4 -- I assume x is 4

Yes, x has the value 4 when the statement is complete.

> (x = 5) -- I assume x is now 5

Nope - This would give a compile error, just like it does today. It says:
 Handler: bad command
Object: button
Line: (x=5)
Hint: (
It says this because you cannot use an expression alone where a 
statement is expected, because doing so would be pointless. The value of 
the expression has nowhere to go - so it's a useless statement, and not 
allowed.

BTW - do not test this in the one-line message box. The one-line message 
box has the special case that if it sees an expression, it will add a 
"put" in front of it to output the value. That's a convenience special 
to the one-line msgbox. I have to admit this is one piece of behaviour 
that might need to change if this syntax were introduced.

> set the customBoolenProp of stack myStack to (x = 4) -- it would put 
> false

Yes, it would put false into the property

> set the customNumericProp of stack myStack to (x = 6) -- it would put
> 6 into x and into the customProp

Nope. It would put false into the property, just like it does today. The 
phrase "x=6" is there as part of an expression, and so is calculated as 
part of that expression - has nothing to do with an assignment to x.

>
> If I got use to 'x = 4' being a valid var assignment, then I would
> assume that as with other Rev statements, placing it in brackets would
> make it just as valid but calculated earlier, to have it suddenly not
> have it work as expected is some cases (although I really can't see
> myself using the above) would cause confusion.
>
Nope. Today you can put a part of an expression into brackets to force 
the relative order of the clauses of the expression; you cannot put a 
complete statement into brackets - it gives a compile error.  So putting 
"x=4" into brackets as a statement would produce a compile error - just 
like you get today from the statement "(put 2 into x)"

> Although you are probably right in that it may not break current code,
> I see that it could create confusion, or at least have a bunch of
> 'extra' rules associated with it. I also assume that this is why
> languages that use 'x = 6' use 'x == 6', because determining the
> meaning by context seems a little roundabout when you can use syntax.

There are various reasons why other languages do that.
In Algol, I believe it was a deliberate choice for academic reasons 
(designed by mathematicians).
    (there may also be cases of ambiguity, but it's been tooooooo long ....)
Pascal followed it (I think).
FORTRAN had a single pass, non-recursive, non-backtracking  parser, so 
needed to did it the very easy way :-)
    (funny - no-one's even suggested Transcript use "x .eq. 4" for 
equality comparisons :-)
In C, there are places where the syntax allows *either* a statement *or* 
an expression (e.g. in the sub-clauses of the for statement), so you 
need to use different operators to distinguish the two cases  Actually, 
in C the assignment operator is just another operator - it 'returns' the 
result of the operation - so it can be mixed freely within expressions 
(e.g.   x = 4 + (y=4)   put 8 into x !!)

And, I think, some languages just do it because their designers/users 
are used to having different operators, so they did the same.

On the other hand, there are a variety of languages (Babbage !?, many 
variants of Basic) which don't have those issues, so simply allow a 
single "=" for assignment or for equality comparison.

Transcript is a straightforward language (though very extensive), so 
there is no difficulty distinguishing the two cases.


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.0/388 - Release Date: 13/07/2006