1. Re[2]: Source to come: sequence implementation?
- Posted by akusaya at gmx.net
Oct 15, 2006
>>unless you are speaking about extended sequence ops?
> It will be fun to see how long it takes for someone to rip out
> [implicit] sequence ops, so instead of (eg) {1,2,3}+{4,5,6}, you have
> to write sq_add({1,2,3},{4,5,6}), so that you can write say
> if name="pete" then, vs if equal(name,"pete") then.
> Properly, I mean, short circuit evaluation of all expressions, and all
> that jazz 
.
Pete, I saw this on your Positive page too: to make { if name = "pete"
then ... } possible, all implicit seq operations need to be changed to
function names.
Why is it so? Why don't make 2 changes:
1. comparison of sequence will result in atom 0 or 1
"a" = "b" -> 0
"a" > "b" -> 0
"a" < "abc" -> 1
"pete" = "pete" -> 1
1 > "a" -> 0
"a" > 9e99 -> 1 -- compatible with compare()
2. +, -, *, / will result in another sequence like Eu behaves now
That way, if name is "pete", then { if name = "pete" then } will
evaluate to { if 1 then }
My reason is that, overally, people use implicit sequence operators
+, -, *, / (or maybe << >> % ^ SOON after 3.0 released), much more
frequently than <, >, >=, <=, =
Advantages:
1. we can discard equal() and compare() forever!
2. see number 1
3. see number 2
4. no more "sequence lengths are not the same"
2. Re: Re[2]: Source to come: sequence implementation?
On Sun, 15 Oct 2006 16:53:05 +0800, aku saya <akusaya at gmx.net> wrote:
>Pete, I saw this: to make { if name = "pete" then ... } possible, all
>implicit seq operations need to be changed to function names.
>
>Why is it so? Why don't make 2 changes:
>1. comparison of sequence will result in atom 0 or 1
>2. +, -, *, / will result in another sequence like Eu behaves now
Existing sequence op use, (eg upper/lower) automatically implode:
x - (x >= 'a' and x <= 'z') * TO_LOWER
If I let the outer - and * do sequence ops, whereas the inner
relational ops result in booleans, and always yields false unless x is
an atom, then upper/lower (on sequences) just do nothing.
Otoh if I ban implicit maths sequence ops outright, it will crash on
that line, which I consider far better than failing silently.
There is also some consistency (usually a good thing):
"<" returns a boolean, sq_lt() can return atom or seq; and
"+" returns an atom, sq_add() can return any object.
One thing I will say is that while my opAdd demands atom parameters,
unlike Rob's opPLUS, it ought not to be particularly difficult to
change the front end to emit calls to sq_add() in some conditions,
though getting those conditions right may well be far trickier than
you might think - I once had a notion of 'Atomic coercion and
propagation in expressions', and it was as horrible as it sounds.
You are quite correct in that +,-,/,* are completely unambiguous when
passed sequences, unlike the relational operators. I won't state that
the change you suggest will never happen, but there are good reasons
for it being the way it is now.
>My reason is that, overally, people use implicit sequence operators
>+, -, *, / (or maybe << >> % ^ SOON after 3.0 released), much more
>frequently than <, >, >=, <=, =
I stand by my claim that real programs use sequence ops less than once
per 2000 lines of code, eg Edita+Arwen, some 42,000 lines, use(d) 17,
and that it is more than a fair trade to allow = instead of equal() at
the expense of occasionally forcing sq_add() instead of +.
>Advantages:
>1. we can discard equal() and compare() forever!
apart from legacy code.
>4. no more "sequence lengths are not the same"
apart from within sq_add etc.
Regards,
Pete
