1. Re: we need official libs : Swap
> >> (One might suggest that theoretically we should be able to close our
eyes
> >to
> >> the implementation, but that's just not possible with this
> >construct--which
> >> says something by itself. There's no way of knowing how
> >>
> >> {s[i], s[j]} = my_func ()
> >>
> >> evaluates when i=j without knowing how it's implemented.)
> >
> >Interesting. You can code confusingly with theoretical improvements.
> >I can even do it with any feature of euphoria already ... Should we
start
> >removing all those features ?
> >
> >I don't care how the above is handled. Illegal, legal ( s[i/j] becomes
2nd
> >element as if it was written out. )
>
> Ralf, that's part of the problem. Euphoria was designed to be a wholistic
> programming language. It was meant to be consistent, not a collection of
> unrelated ideas and constructs. You can't continue with that paradigm by
> just throwing in new things to ease one particular situation without
> caring about what it leads to.
First of all, being able to format using sequences is more consistented.
Secondly, it would make Euphoria more whole, because it gives native support
for multiple return values, something still lacking. (the sequence part
currently, in my eyes is a trick, you aren't checking length, format nor
types with the current 'trick' we're pulling )
So, it would be more of a whole. It is consistend because it uses a format
already known, namely the sequence. It is more consistent, then it currently
is. I and many others, i'm sure, in the beginning, being introduced to
Euphoria, at least tried if this was possible, assuming the odds were high
it would work. So, I think it would be more consistend.
> >Thirdly, although, you may have been taught differently, as most. Just
> >because something is there and others use it, doesn't mean you have to
use
> >it.
>
> Yes, the "if you don't like it, don't use it" argument. It's not credible.
You aren't even using arguments to explain why you think its not credible.
> >Yes, off course, did you understand every Euphoria program without even
> >reading the documentation ? Get real.
>
> >Most parts of Euphoria are quite confusing in the beginning.
>
> <snip>
>
> ????
>
> Perhaps I'm in the minority here, but I had no difficulty learning the
> basics of Euphoria. The operation of certain *functions* (routine_id comes
> to mind) held me back for a while, but Euphoria itself, even multiplying
> sequences by sequences, was IMMEDIATELY very clear, very elegant, and very
> obvious in it's strength and power.
Difficulty in learning is something totally different, than not having to
read the documentation, and learn its basic, consistent rules. Its just the
fact, that a suggestion such as assignments of multiple variables require
rules to be consistent and powerfull as well, is not a bad thing. Its a
logical thing, and it applied to all parts of Euphoria.
> WHY was this the case? Because of consistency. There were a handful of
> key rules, and a handful of key concepts and that was it. Virtually
> everything from that derived logically from those keys. This doesn't just
> make the language easier to learn... it makes it easier to USE, day in and
> day out, whether whipping up a quick program, or trying to decode someone
> else's library.
>
> Please forgive me if I'm against anything I feel takes away from that
> overall consistency, even if it's as simple as "x += 1".
About consistentcy. People have an idea of what good and bad is, (most do
anyway 
.. they see a big picture of right and wrong, and create rules so
they can apply and judge situations much more clearly. One could even define
a rule as a generalization, actually it is.
These rules serve a higher purpose. A goal. Rules should be consistent and
should be kept to a bare and powerfull minimum, I totally agree. But it is
ok, to have lesser rules as well. Some things need to be handled more within
the context and some exceptions are better not generalized away.
For example, a rule, that would say, you are not allowed to slice sequences
within a sequence formation on the left side, is fine with me. It would
solve this whole issue.
Just as you are not allowed to multiple two sequences of different lengths.
Is this consistent ? No, it would be more consistent if each element was
multiplied with each element of the other sequence. The fact is, it would be
very confusing to say which way they would be multiplied, and it usually not
the wanted behaviour anyway. Is this a bad thing, just because we added an
exception to a consistent rule ? No, it is not. You can't specify everything
down to basic principles of right of wrong: It takes too long.
But this whole discussion of implementation vs principles, has got nothing
to do with this construct anyway. As to this construct, I never heard any
real arguments that still apply, when I include (which I still think has got
nothing to do with it, but i'll give in..) the rule mentioned above, (about
not being allowed to slice on the left side within a concationated sequence)
into my suggestion. Now lets hear the new problems and issues, I'm sure you
can come up with ..
But before you all balk with, not friendly enough for new users, not .. bla
bla bla..
I want to make one thing clear, the construct is, in my eyes, allowed to be
as confusing as any construct in Euphoria currently is. It is allowed to be
as user-unfriendly as any of those constructs, etc. .. you get the point,
I'll be comparing it to current parts of Euphoria.
Ralf N.
