Re: Sequence Ops
CChris wrote:
>
>
> 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
> }}}
<eucode>
> 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
> </eucode>
{{{
> 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 </font><font color="#FF00FF">sequence </font><font
> color="#330033">of 1 </font><font color="#0000FF">and </font><font
> color="#330033">0s more useful than the well
> known 0.</font>
>
> 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:
> }}}
<eucode>
> 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 -- ...
> </eucode>
{{{
> 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
Hello,
I think i agree that 1+{1,2,3} should stay the same too, as changing
it now would break code, but im not really sure just how much i
actually used this in the past. I think a few times but that's it.
The reason is because i would seldom have the need to add two things
whos type were not the same. Usually, when i add two things it's
because they originated from two other sources, and both sources
would be basically the same.
Still, it is very handy when you want to act on every element in
the sequence.
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
|
Not Categorized, Please Help
|
|
