1. Conditional handling (was Re: Reading a file into a "sequence")
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Nov 18, 2004
-
Last edited Nov 19, 2004
On Thu, 18 Nov 2004 12:28:57 -0800, Alexander Toresson
<guest at RapidEuphoria.com> wrote:
>Jason Gade wrote:
>[snip]
>> Be equivalent to equal(s1, s2) when found in a conditional (if, when)
>> Have the result sequence (1, 0, 1, 1) be reduced to an atom that is TRUE if
>> and only
>> if all of its elements are true, again only in a conditional statement (if,
>> when).
>>
>> Personally I prefer the second example.
>
>Me too. The second example would make it more flexible.
Although this may be a moot point, I have to disagree completely with
the selection of the second as "preferred". I hope you'll forgive me
for being a bit blunt about it.
There is no point in generating a sequence if you plan to immediately
"reduce" it to a boolean.
It would be much faster just to create the boolean in the first place.
(Which of course I firmly believe it should do)
While the above (second) idea might be workable for equal, it would
not be for other relational operators. For example:
"if {1,2,3} >= {1,2,2} then" creates {1,1,0} "reduced" to FALSE.
"if {1,2,3} >= {1,1,2} then" creates {1,1,0}, "reduced" to TRUE.
Unless, of course, you have a magic routine which converts {1,1,0}
into true in some cases and false in others.
As for flexibility, the concept of arbitrarily interpreting a sequence
as either true or false is just nonsense.
It should produce an error, as it currently does.
What the language should not do is create a sequence in situations
where the only possible outcome of so doing is a crash.
Regards,
Pete
2. Re: Conditional handling (was Re: Reading a file into a "sequence")
- Posted by Jason Gade <jaygade at yahoo.com>
Nov 18, 2004
-
Last edited Nov 19, 2004
Pete Lomax wrote:
> >Jason Gade wrote:
> >[snip]
> >> Be equivalent to equal(s1, s2) when found in a conditional (if, when)
> >> Have the result sequence (1, 0, 1, 1) be reduced to an atom that is TRUE if
> >> and only
> >> if all of its elements are true, again only in a conditional statement (if,
> >> when).
> >>
> >> Personally I prefer the second example.
> Although this may be a moot point, I have to disagree completely with
> the selection of the second as "preferred". I hope you'll forgive me
> for being a bit blunt about it.
>
> There is no point in generating a sequence if you plan to immediately
> "reduce" it to a boolean.
>
> It would be much faster just to create the boolean in the first place.
> (Which of course I firmly believe it should do)
>
> While the above (second) idea might be workable for equal, it would
> not be for other relational operators. For example:
>
> "if {1,2,3} >= {1,2,2} then" creates {1,1,0} "reduced" to FALSE.
>
> "if {1,2,3} >= {1,1,2} then" creates {1,1,0}, "reduced" to TRUE.
>
> Unless, of course, you have a magic routine which converts {1,1,0}
> into true in some cases and false in others.
>
> As for flexibility, the concept of arbitrarily interpreting a sequence
> as either true or false is just nonsense.
>
> It should produce an error, as it currently does.
>
> What the language should not do is create a sequence in situations
> where the only possible outcome of so doing is a crash.
>
> Regards,
> Pete
Good point. So do you think that comparison operators should work like equal
and compare in if and when statements, or should it remain as-is?
j.
3. Re: Conditional handling (was Re: Reading a file into a "sequence")
- Posted by Derek Parnell <ddparnell at bigpond.com>
Nov 18, 2004
-
Last edited Nov 19, 2004
Jason Gade wrote:
>
> Pete Lomax wrote:
> > >Jason Gade wrote:
> > >[snip]
> > >> Be equivalent to equal(s1, s2) when found in a conditional (if, when)
> > >> Have the result sequence (1, 0, 1, 1) be reduced to an atom that is TRUE
> > >> if and only
> > >> if all of its elements are true, again only in a conditional statement
> > >> (if, when).
> > >>
> > >> Personally I prefer the second example.
> > Although this may be a moot point, I have to disagree completely with
> > the selection of the second as "preferred". I hope you'll forgive me
> > for being a bit blunt about it.
> >
> > There is no point in generating a sequence if you plan to immediately
> > "reduce" it to a boolean.
> >
> > It would be much faster just to create the boolean in the first place.
> > (Which of course I firmly believe it should do)
> >
> > While the above (second) idea might be workable for equal, it would
> > not be for other relational operators. For example:
> >
> > "if {1,2,3} >= {1,2,2} then" creates {1,1,0} "reduced" to FALSE.
> >
> > "if {1,2,3} >= {1,1,2} then" creates {1,1,0}, "reduced" to TRUE.
> >
> > Unless, of course, you have a magic routine which converts {1,1,0}
> > into true in some cases and false in others.
> >
> > As for flexibility, the concept of arbitrarily interpreting a sequence
> > as either true or false is just nonsense.
> >
> > It should produce an error, as it currently does.
> >
> > What the language should not do is create a sequence in situations
> > where the only possible outcome of so doing is a crash.
> >
> > Regards,
> > Pete
>
> Good point. So do you think that comparison operators should work like equal
> and compare
> in if and when statements, or should it remain as-is?
Not as-is. When comparision operators appear in IF or WHILE statements,
they should result in a boolean value (true/false) and never a sequence.
I think that RDS chose the wrong operation to perform in those contexts.
Further more, if RDS changed Euphoria to behave as if a compare() had
been coded, it would *not* break any existing code, because any code
with this in it now is already broken. Instead, it could cause people
to write programs that looked and felt right.
The sematics of the IF wouldn't change either, as 'IF <sequence> THEN'
is still an error, as it should be. The change is simply that
'IF <sequence> <relop> <object> THEN' would be automatically produced as
'IF COMPARE(<sequence>,<object>) <relop> 0 THEN'
I am not saying the the sequence operation is never to be used, only
it shouldn't be used in these contexts.
--
Derek Parnell
Melbourne, Australia
4. Re: Conditional handling (was Re: Reading a file into a "sequence")
On Thu, 18 Nov 2004 13:44:07 -0800, Jason Gade
<guest at RapidEuphoria.com> wrote:
>Pete Lomax wrote:
<snip>
>> It would be much faster just to create the boolean in the first place.
>> (Which of course I firmly believe it should do)
<snip>
>> What the language should not do is create a sequence in situations
>> where the only possible outcome of so doing is a crash.
<snip>
>Good point. So do you think that comparison operators should work
>like equal and compare in if and when statements, or should it remain
>as-is?
OK, I'll be even more specific.
This has been proposed many, many times before and I have never
opposed it, just the "create a sequence of 1s and 0s and then
immediately munge it to a true/false" part.
Something like
if name="pete" then
is written at least once by every person who ever codes more than a
dozen lines of Euphoria. It will /always/ crash. This cannot possibly
be considered anything but wrong (especially when left to a run-time
rather than a parse-time error - but see "cost" below)
If the interpreter must get an atom (if, while, for, subscript, and
slice, but not assignment, parameters, or constant expressions)
otherwise it will crash, then it should use equal()/compare() as it
obviously needs to for all relational operators. (IMHO, that is)
I'll go further and accept that a perfect solution is not necessary.
Should the compiler be in any doubt, then crash, forcing the
programmer to resort to explicit equal() and compare() calls.
Of course, part of the problem is that the parser does not understand
when it needs an atom, eg:
integer i
i="fred"
generates a run-time, not a parse-time error. (You can prove this more
clearly by wrapping it in a procedure, and calling/not calling it)
I'm perfectly aware why Rob does not want to implement this, because
it will slow things down (quite a bit, in all probability).
Even with that cost, yes, I still want it.
Regards,
Pete
PS I also like the idea of "when" statements 
)
