1. 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.:
a = 1, b = 3 results in a & b = append({a}, b)
a = {1, 2}, b = 3 results in a & b = append(a, b)
a = 1, b = {3, 4} results in a & b = prepend(b, a)
a = {1, 2}, b = {3, 4} results in a & b = concat(a, b) -- {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}
-- "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...
Lutz.
2. Syntax of &-operator
-P873@KI
Hi Derek,
DP>I'm not sure what the issue is here?
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!
> 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 "&=".
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.
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...
Lutz.
3. Syntax of &-operator
-P1322@KI
Hi Derek,
> a & b = append({a}, b)
> a & b = append(a, b)
>
> being valid at the same time!
DP>Is the strangeness due it allowing both atoms and sequences in the
DP>operands?
No, it's the different results '{{a}, b}' or '{a, b}', depending on the data
types of a and b.
> 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 "&=".
DP>How so?
DP> sequence x
DP> atom a,b,c,d
DP>
DP> x = {1,2,3,4}
DP> a = 91
DP> b = 92
DP> c = 93
DP> d = 94
DP> x &= {a,b,c,d}
DP> -- leaves x to be {1,2,3,4,90,91,92,93}
Alright, let's assume '@' is the new symbol. In that case I might've written:
{a} @ {b} @ {c} @ {d}
You propose {a, b, c, d} instead. But then you fall back to
x @= {a, b, c, d}
which is exactly why I'd rather see a new operator that can be used like '&'
and especially like '&='.
DP>I suspect that if enough advocacy is used on things that won't break
DP>existing code, RDS just might be bothered with it. Its always worth a
DP>try.
Exactly!
DP>And yet, I'm glad of the way that '&' uses both datatypes.
The '&'-operator won't be dropped, of course, and it can always be used!
DP>Otherwise I'd have to code ugly things like this all the time ...
DP> if atom(a) or atom(b) then
DP> x = a & b
DP> else
DP> x = a @ b
DP> end if
It's the other way round: '@' should eliminate the need for internal type
checking and thus be faster. Where external type checking (by your program)
is necessary, you should use the more general '&' with its much faster
internal check.
It's like with objects, atoms, and integers: Declare an object first. Once
you know it will always be a number, declare it as a number. And once you
know it will always be an integer, declare it as an integer.
But if you don't want to worry about atoms or integers, you can stick to
objects which still work the same...
DP>If you really want a function to do this I suppose you could create ...
[...]
I'm talking about an operator, not a function!
Lutz.
