1. Re: unfolded expressions
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Jul 20, 1999
-
Last edited Jul 21, 1999
Lewis Townsend wrote:
>
> >Its seems I don't have too convice many of the advantages of these use:
> >
> > { x, y } = location ()
>
> agreed 100%
a quick notice: the above looks elegant and simple and although I'm positive
one can come up with non-elegant uses and examples, one of the reasons I
would want this syntax is because in _some_ cases it looks the most elegant.
It is ok, (don't be afraid, be a big .. j/k), to allow multiple
syntaxes to do the same thing. Because *any* syntax allows complex and
unclear use. The above to me, looks so much better then:
object junk
junk = location ()
x = junk[1]
y = junk[2]
> Okay, how about NOT allowing opperators or functions
> on the left side? Only values:
> >However, about multiple variables on the left-side, why not consistently
> >assign to the first variable mentioned or dissallow multiple variables
> >alltogether.
>
> Hey, I like multiple variables.
> Multiple variables would be good because its
> an assignment statement. You assign to variables, right?
> You don't assign to expressions, at least I don't think
> you should in Euphoria (IMHO).
>
> >Actually, I feel sorry, that a new idea such as this, is approached upon
> >implementation issues rather the theory and use behind it.
>
> Wouldn't it be wonderful if we could just make up ideas
> and let someone else work out all the problems they caused?
No, logical and practical and ok, maybe wonderful as well.
My point is, it would be like attacking Euphoria because it isn't supported
on all platforms.
I see a big difference between the grammer and ideology of a language and
its implementation.
Its just that RDS provides the only 'real' implementation and have
developped Euphoria themselves, which clouds and connects implementation
issues with language grammer.
> >I never specified on the exact rules, and it really shouldn't matter, the
> >choice of wether or not allowing confusing code is one totally apart from
> >the decision and discussion of such a language extension.
>
> Okay, it shouldn't matter to you that the rules I
> suggested above would severely restrict the syntax
> you suggested.
Precizely. I don't care how, as long as I can say these two things:
{ x, y} = location ()
and
{a, b} = {b, a}
And if I can do more things on an elegant way, cool, if not, so be it.
> >Speaking about confusing statements, its really in the hand of the
> >programmer.
> >This is legal, already:
> >
> > function pos (object x)
> > return x + ( x < 0 ) * -2x)
> > end function
>
> What?! I didn't know that was legal! Can you really
> eliminate the "*" operateor like that? (-2x)
It doesn't eliminate the '*' .. what I eliminate is the if-statement, by
using boolean math.
I've written far more complex if-statements as one calculation for any type
of arbiturary object.
They are messy, but the advantages are more valuable to me. Others can do
what they want.
The argument is can create confusing statement is, in my eyes, a ridiculous
argument. So can I with any part of the syntax of Euphoria.
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
Check out the [[ Elevator ]] (its like updated 5 times this month.)
http://www.xs4all.nl/~nieuwen
