Re: ? 1={}, is there really any other interpretation?
Robert Craig wrote:
>
> Pete Lomax wrote:
> > Rob: Perhaps instead of asking "should we kill off sequence ops", which
> > I am not advocating, it is the IMPLICIT part that causes problems, the
> > questions that should be asked (as well) are:
> > Do we want short-circuiting in all expressions?
>
> In an ideal world, that might be nice.
And one must never strive to make this an ideal world, of course.
> > This cannot be done
> > as long as "and" & "or" are sequence-op-capable, but could be if
> > "and" became atom-only and either "@and" or "sq_and()" created to
> > replace that particular functionality, ditto "or".
>
> I think it's a bit late in the game to change the semantics
> of "and", "or", "=", or any other operator when applied to sequences.
>
> > Do we want the 'if name="pete" then' gotcha to go away and instead
> > for such expressions to work as humans expect?
>
> Humans who were brought up on Basic are very disturbed by this.
And a whole host of other programming languages and human languages!
> Humans who were brought up on C, think it's fine.
And this is the majority of people nowadays, right?
In the newer C-family languages such as C++, C#, D, and Objective C one can
write 'if (name=="pete")'.
> In C you don't
> say:
> if (name == "pete")
> You say:
> if (strcmp(name, "pete") == 0)
And this has always been a mistake in my opinion, but as C was designed to be a
minimulist high-level assembler that does not have a native dynamic array or
string type, it makes sense as a compromise. But it doesn't make C a good
language.
> Since I was brought up on C (and APL, which works like Euphoria in
> this regard), I really can't see why people are so determined
> to replace:
> if equal(a, b) then
> by something like:
> if a == b then
>
> I don't see why that is so important.
You like consistency right?
integer intA, intB
sequence seqA, seqB
if intA = intB -- This works
if seqA = seqB -- This fails
Duh!
How many times do you or anyone else write 'if equal(intA, intB)'?
> There wouldn't be any speed advantage,
> and we'd constantly have newbies asking
> what the difference is between == and =,
> and experienced users also frequently forgetting.
Instead, we have newbies writing the obvious 'if seqA = seqB' and wondering what
the difference is between 'equal()' and '='.
And this doesn't even begin to address the non-intuitive 'compare()' function
instead of the obvious '<', '>', '<=', '>='.
if compare(seqA, seqB) >= 0 then --- Huh? Why the zero?
if seqA >= seqB then --- Oh, is that what you really mean?
THE PURPOSE OF A PROGRAMMING LANGUAGE IS TO MAKE IT EASIER FOR HUMANS TO READ
PROGRAMS. Any programming language that creates a 'huh?' response in a human
reader of code, needs help.
Euphoria has mostly got it right, Robert. You are to be congratulated for that.
But there really are some parts of it that make humans work harder at
understanding the written code than is really necessary.
I don't see why you think it is not important to make Euphoria a
better-for-humans language.
> > Do we want expressions to have the same meaning wherever they occur
> > or behave different in if/while to assign/params?
>
> In the context of an if/while/elsif we know that an expression
> can't produce a sequence as it's overall result, otherwise it
> would be an error, so we are "free" to sometimes ignore the
> remainder of the expression, and assume we are dealing with atoms only.
In your opinion! To re-phrase ...
In the context of an if/while/elsif we know that an expression
can't produce a sequence as it's overall result, otherwise it
would be an error, so people naturally assume we are dealing
with a logical expression (a comparision).
> Short-circuiting was retrofitted into Euphoria, and this little
> trick made it possible. I realize things aren't as clean in this area
> as they might be, but if you really want s.c. you can always change:
> x = logical_expression
> into:
> if logical-expression then
> x = 1
> else
> x = 0
> end if
>
> to get short circuiting.
Why would someone think that 'name > "pete"' is not a logical expression in the
'if' statement?
And when it comes to things like ...
x = name > "pete"
to me LOOKS like I'm setting 'x' to true/false depending on whether or not
'name' contains a string whose value is greater than the string "pete".
If for some rare reason I actually wanted to do a sequence operation, then I'd
appreciate using a different method - either a new operator or a function-like
construct.
x = name [>] "pete"
x = seq_gt(name, "pete")
These are rarely used operations and I firmly believe that breaking code is
justified if improves the language for (the many?) future users.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
|
Not Categorized, Please Help
|
|
