1. RE: Syntax of &-operator
Hi Lutz,
I'm not sure what the issue is here? When I tried these examples I got
this...
> a = 1, b = 3 results in a & b = append({a}, b)
{1,3}
> a = {1, 2}, b = 3 results in a & b = append(a, b)
{1,2,3}
> a = 1, b = {3, 4} results in a & b = prepend(b, a)
{1,3,4}
> a = {1, 2}, b = {3, 4} results in a & b = concat(a, b) -- {1, 2, 3, 4}
{1,2,3,4}
in each case this is exactly what I expected.
> -----Original Message-----
> From: Lutz_Heitmann at NF.MAUS.DE [mailto:Lutz_Heitmann at NF.MAUS.DE]
> Sent: Monday, 2 April 2001 8:18 AM
> To: EUforum
> Subject: Syntax of &-operator
>
>
> Hi Euphorians,
>
> I don't like the syntax of the &-operator. & is a fine tool
> to concatenate
> sequences, but its use is error prone. If you combine
> variables a and b you
> get different results, depending on the types of a and b. E.g.:
The '&' operator always returns the same data type - a sequence, regardless
of the data types that the two operands are. Atoms are treated *as if* they
were single element sequences and '&' works by adding every element of the
second operator to the end of the first operator and returning the resulting
sequence.
Thus, to use your examples...
> a = 1, b = 3
a & b ==> 1 & 3 ==> {1} & {3} ==> {1,3}
> a = {1, 2}, b = 3
a & b ==> {1,2} & 3 ==> {1,2} & {3} ==> {1,2,3}
> a = 1, b = {3, 4}
a & b ==> 1 & {3,4} ==> {1} & {3, 4} ==> {1,3,4}
> a = {1, 2}, b = {3, 4}
a & b ==> {1,2} & {3,4} ==> {1,2,3,4}
>
> I'm using "concat" for the only usage of "&" that makes sense
> to me. Of
> course I don't want something like a & b & c & d (all atoms)
> to be written
> like this:
>
> append(append(append({a},b),c),d)
>
> It could be coded like this:
>
> {a} & {b} & {c} & {d}
or like this ...
{a,b,c,d}
>
> -- "concat" is just too long as a word
>
> A little bit more typing but a lot clearer. A lot of programs
> are using "&"
> the "old" way, and that can't be changed. But I still don't like it...
the "old" way? What is the "new" way then? How have things changed? Are you
advocating that a new function be included in Euphoria called 'concat' and
that it should work the same as '&' operation?
-------------
global function concat( object a, object b)
return a & b
end function
-------------
Now, append() and prepend() do not work the same as '&'.
These also always return a sequence, but they work by adding the second
parameter - as a single thing - to the end/beginning of the first parameter.
This is done regardless of how many elements are in the second parameter.
The net result is the the first parameter gains one, and only one, new
element. Another subtle difference is that only the first parameter, if an
atom, is treated as if it were a single element sequence, the second
parameter is always treated as its own datatype.
Again using the examples supplied...
> a = 1, b = 3
append(a , b) ==> append(1 , 3) ==> append({1} , 3) ==> {1,3}
> a = {1, 2}, b = 3
append(a,b) ==> append({1,2}, 3) ==> {1,2,3}
> a = 1, b = {3, 4}
append(a,b) ==> append(1, {3,4}) ==> append({1},{3, 4}) ==> {1,{3,4}}
!! Note the different behaviour with that one.
prepend(b,a) ==> prepend({3,4}, 1) ==> {1,3,4}
(This is why prepend() seems to "work" like '&' here)
> a = {1, 2}, b = {3, 4}
append(a, b) ==> append({1,2} ,{3,4}) ==> {1,2,{3,4}}
!! Note the different behaviour with this too.
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
---------------------
2. RE: Syntax of &-operator
> As I said, I don't like the behaviour of "&". This seems
> strange to me:
>
> > a & b = append({a}, b)
>
> > a & b = append(a, b)
>
> being valid at the same time!
Is the strangeness due it allowing both atoms and sequences in the operands?
> > It could be coded like this:
> >
> > {a} & {b} & {c} & {d}
>
> DP>or like this ...
> DP> {a,b,c,d}
>
> Nope! That would eliminate the option of "&=".
How so?
sequence x
atom a,b,c,d
x = {1,2,3,4}
a = 91
b = 92
c = 93
d = 94
x &= {a,b,c,d}
-- leaves x to be {1,2,3,4,90,91,92,93}
> DP>the "old" way? What is the "new" way then? How have things changed?
>
> Replace "old" with "current". Then replace "new" with "an
> alternative", and
> you've got it! Things haven't changed, and they won't ever
> with so many
> programs and libraries up and running.
I suspect that if enough advocacy is used on things that won't break
existing code, RDS just might be bothered with it. Its always worth a try.
> DP>Are you advocating that a new function be included in
> Euphoria called
> DP>'concat' and that it should work the same as '&' operation?
>
> Not the same, of course (nothing would be gained by that!),
> and its name
> doesn't matter. In fact, it should be a single character like
> "@". Nobody
> *has* to use it but it would be faster by assuming operands
> to be *always*
> sequences. And debugging would be easier in many cases where
> "&" ignores
> the difference between atoms and sequences...
And yet, I'm glad of the way that '&' uses both datatypes. Otherwise I'd
have to code ugly things like this all the time ...
if atom(a) or atom(b) then
x = a & b
else
x = a @ b
end if
If you really want a function to do this I suppose you could create ...
function concat(sequence a, sequence b)
return a & b
end function
which would force type checking on the operands.
I imagine that the '&' operation was born, primarily, out of the desire to
join strings together.
a = "Derek"
b = "Parnell"
x = a & " " & b
but to make life simplier and faster for both coder and interpreter, atoms
could be used too.
delim = ' '
a = "Derek"
b = "Parnell"
x = a & delim & b
-----------
cheers,
Derek Parnell
Senior Design Engineer
Global Technology Australasia Ltd
dparnell at glotec.com.au
---------------------
