Kay C Lan wrote:
On 7/14/06, Alex Tweedly <[EMAIL PROTECTED]> 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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
