Re: = vs := and = vs ==
- Posted by petelomax May 08, 2014
- 2281 views
What would it take to allow := in an assignment statement? (Phix by Lomax already does this.)
NO!
To clarify, where the compiler would treat "=" as assignment it lets you use ":=" but reports an error if you try to use "==". Where the compiler would treat "=" as a comparison it lets you use "==" but reports an error if you try to use ":=". So,
if a:=b then c==d end if
contains two fatal compilation errors.
I don't care if they're assignments or comparisons, the syntax takes care of it, but I would have to if I was forced to be more specific, which for me adds another layer of detail I can just do without.
As above, in Phix, they are entirely optional, you are perfectly free to continue to use "=" for everything, if you want.
I especially like the lack of semicolons between every statement.
I made them optional in Phix. I just got sick of getting home after coding in C++ all day and not being able to write Eu code (and vice versa, but that would probably have taken rather more than the 3 minutes it took to modify my compiler). I also once somehow managed to slip in a ">" between two assignment statements (that used "=") which took 3 days (THREE DAYS!) to track down, which would obviously have been lit up like a Christmas Tree if only they had been separated by semicolons.
What is confusing, however, is why = cannot compare objects while equal() can. (Can't = just be shorthand for equal()?) IIRC, allowing = to compare objects in if/while statements is relatively trivial. I believe it's a simple matter of changing the op (opEQUAL?) routine in the interpreter. At least, this was true in Euphoria 2.x and 3.x. I haven't spent much time in the Euphoria 4.x source code, but I would welcome this change.
The way to properly "fix" this is to change the parser to perform a boolean test in these situations rather than a sequence operation. This is quite a big deal though, given the way its coded.
The real problem is implicit sequence ops. So much so that Phix only allows explicit (function-style) sequence ops. One example I came up with (oh gosh, so many years ago now!) was:
if (a=b)=(c=d) then
It (might) seem clear that the "inner" "=" needs to generate a boolean so must be a comparison, but what about the "outer" two? I am very certain that trying to be "clever" about selecting which in the parser will lead you to a whole new world of pain.
Regards,
Pete
Edit: I retrieved this, from my assorted notes, which might help make that last example a little clearer
name="robbie"
city="moscow"
....
if (name="robert") = (city="london") then
Which could quite reasonably be taken as equivalent to either
if equal({1,1,1,0,0,0},{0,1,0,0,1,0}) then (false)
or
if equal(false,false) then (true)
In this particular case, it seems the compiler would effectively have to make a blind guess about what the programmer actually meant, and most likely get it wrong about 50% of the time.
Another potential gotcha could be temp=(city="london") behaving entirely differently depending on whether temp was declared as integer or sequence, and/or, of course, play a similar guessing game when it is an object.
