Re: we need official libs : Swap
Roderick Jackson wrote:
>[...]
>>>I'd think we're better off keeping things pretty much the way they are,
>>>adding functions as necessary rather than new syntax. 
>>
>>+= -= *= /= &=
>
>AAAAH! Back, you!
|-D
Sorry, I just couldn't resist.
>Seriously, I realize those were added, but I was one of the few who saw it
>as being an unnecessary degradation of the language. (I know, I know,
>"efficiency first". But really, if I was concerned enough about Euphoria's
>efficiency to worry about the speed gains in a statement like "x = x + 1"
>over "x += 1" (if any), I doubt I'd be using it.)
For me, the only reason I use += is it's quicker to type. Call me lazy, but
I'd rather type "variablename += 1" than "variablename = variablename + 1".
To my knowledge, the only time there's any "efficiency" consideration is
when the variable is subscripted more than once (i.e. "var[x][y] += 1" is a
bit faster than "var[x][y] = var[x][y] + 1").
[...]
>"{a,b}={b,a}" looks almost
>alluring, but some part of my being cries out at the apparent placement of
a
>sequence on the left side of an assignment.
Actually, I'm becoming less confident about the idea, the more I think about
it. Seems like almost every "little change" proposed for Euphoria has
undesirable consequences which aren't immediately obvious.
Let's use this proposal as an example:
{status, value} = get(0)
Now if we change the above code to this...
{value, value} = get(0)
..it should produce an error at preprocess/compile time. This would
certainly be mandatory, since we don't want programmers attempting to assign
two different values to the same variable. Now, suppose we have
*subscripted* variables in our left-sided sequence:
{values[3], values[7]} = get(0)
This could be okay -- even though we're referencing 'values' both times,
'values[3]' and 'values[7]' are two different locations. But what happens
when we do this:
{values[i], values[j]} = get(0)
We have no guarantee that 'i' and 'j' are not equal, so there's *no* way to
catch this at preprocess/compile time. Either we'd have to allow the same
variable to receive two different values after all (one wiping out the other
-- ick), or we'd have to catch this sort of thing at run time (a nightmare
for the programmer writing the preprocessor, and far less desirable than
being able to catch the error at preprocess/compile time).
Also, say we want to use this marvellous new construct with date()...
{year, month, day, hour, minute, second, day_of_week, day_of_year} = date()
..but we're not going to need the time information. We certainly don't want
to have to create useless variables for the time fields, but neither can we
simply use one "junk" field for all three of them. I suppose something like
this could be done...
{year, month, day, _, _, _, day_of_week, day_of_year} = date()
..but now we've shattered the illusion that this is pure Euphoria code. I
can't see Rob implementing something like this into Euphoria -- it simply
screams "PREPROCESSOR CODE!"
So, in order for this idea to be self-consistent and work within Euphoria,
we'd have to require the left-hand side of the equation to follow these
guidelines:
1) Sequence structure must match the returned value exactly.
2) A different variable for each receiving element, even elements that won't
be used.
3) No subscripted receiving variables.
It's still possible, but not quite the 100% integration into Euphoria I was
hoping for.
And, come to think of it, this seems like a whole lot of work just to swap
two variables, or to store the return value of get().
Be seeing you,
Gabriel Boehme
|
Not Categorized, Please Help
|
|
