OpenEuphoria

Re: Sequence Ops

• Posted by CChris <christian.cuvier at agricultu?e.gouv.fr> Jul 15, 2007
• 598 views

Let me state what I think we should do. Because "sequence operations" are
diverse, I don't think an all-encompassing solution would work, whatever it is.
The contexts where the various operations are used hardly overlap, so that
forcing a unniform meaning across them just doesn't make sense for me.

1/  [arithmetic op_]assignments: lhs=, +=, -=, *=, /= rhs

I have always worked in mathematics and statustucs. As a result, I completely
share Rob's views on these operations as extremely useful to keep the source
files readable as well as providing a very needed flexibility.

Note for Pete: I'd probably stop using Euphoria altogether if 1+{1,2,3} ever
started to return anything other than {2,3,4}, even without an error, because
that's one of its current strengths. Using sq_add() and friends just means more
typing for no benefit. That's the single construct I use most when doing
scientifical/statistical computing.

However, because CPUs don't work exactly as they used to 18 years ago, a good
thing to do would be to assess whether, when the rhs is an atom, the above
sequence ops are indeed faster than loops. If the benchmarks say no, then we
might have to reconsider their being in the language. If the answer is no when
the rhs is a sequence, I don't think it is much of a problem, because it is a
less typical use.

There is a moblem, however, with the semantics of "s[p..q] = x". When x is an
atom, this is clear, and assigns a few contiguous elements the same value. But
when x is a sequence, the semantics change to mean "set a subsequence of s to x",
and the lengths have better match. Perhaps this point should be emphasized more
in the docs, and the awkward, error prone 
<euocde>s[p..q]=repeat(x,q-p+1)</eucode>
{{{
 be mentioned as the way to do the
possibly more natural thing: assigning a sequence value to contiguous elements.

I had suggested s[p..q][]=x a few years ago, see the corresponding thread.

2/ The &= operator.

This one is a special case, because it doesn't apply a transformation to each
element of a sequence as the above, but takes the lhs as a whole. I wish the
former could be done too, and it has been requested a couple times on th list.

Since "seq[p..q] &= x" is always illegal (except when x is "", in which case seq
remains unchanged), why not use this idiom to apply a "&" to each element of a
sequence?
We'd have

sequence s
s={1,2,3}
? s & 0 -- {1,2,3,0}
? s[1..3] & 0 -- {{1,0},{2,0},{3,0}}, currently errors out because lengths don't
match

Alternatively, as above, s[]&=x could be used too. That syntax would also allow
some useful stiff, like }}}
<eucode>s=atom(x[])</eucode>
{{{
 returning a sequence of 1
and 0s more useful than the well known 0.

3/ Relational ops:  (lhs =, !=, <,<=,>,>= rhs).

Here comes the highly debated stuff.

Once again, I fully agree with the vector interpretation being by far the most
useful.

However, inside an if or while block header, this interpretation wouldn't make
sense. This is what Pete is gtiping about, with some reason, because the result
cannot be a vector, contrary to one would expect in the general case.

I don't see any issue in having the relational operators behave differently
whether they are rhs or not. Hence:

if "Pete" = "Lomax" then
w/eucode>
would be optimised out because the conditional clause is known to be the FALSE
constant, while
}}}
<eucode>
s= ("Pete" = "Lomax")
w/eucode>
won't work because lengths don't match. compare() and equal() can still be used
if you need the boolean in a rhs. Note that appearing in a routine argument is
the same as being a rhs, since the actual value is being used.
So, if you really wish to crash your program, you could still do this:
}}}
<eucode>
funcion id(object x) return x end function
if id("Pete "="Lomax") then -- ...

Here, because the = operator defines part of a rhs, id() will return a sequence,
and this triggers a run time error because an atom i expecyed.

That's how I view sequence operations after using them a fair amount over years,
and experienced strengths and weaknesses of the current scheme. There are
improvements to make. But remving sequence operations from the language would
certainly cripple it beyond repair, and Eu doesn't need that.

CChris