1. Re: we need official libs : Swap
Cuny, David wrote:
>Roderick Jackson wrote:
>
>> But let me ask... does this situation actually
>> cause trouble for you, or would this new construct
>> just be a nice convenience?
>
>Yes, it actually causes trouble. Having to write lines like this:
>
> draw_line( color, pt1[1], pt1[2], pt2[1], pt2[2] )
>
>actually does cause problems, since it had errors in it the first time I
>wrote it. The code is hard to read, and prone to errors, and difficult to
>debug. Another real disadvantage of having data in sequences is you can't
>query it in the trace screen.
Ah, but that focuses on a different difficulty. I agree, the above is more
confusing, error-prone, and debug-proof than:
draw_line (color, x1, y1, x2, y2)
But that's just an inherint side effect of sequence (or array) indexing in
general. If I have a complex operation, and need to shove it into the yth
element of the xth subsequence of a sequence, I'll generally store it in
a holding variable if I need to make later use of it--in other words:
r_factor = (my_table1[x][y] * your_table3[x][y]) / x_factor
main_array[x][y][z + i] = r_factor
...
-- continue coding, using r_factor instead of main_array[x][y][z + i]
That increase in clarity isn't impacted by multiple-assignment. The only
difference between the code example you presented, and the one I presented,
was that while you had a multiple-assignment construct move the values into
the variables, I moved them manually.
Don't misunderstand, I'm not trying to be stubborn here, but I honestly just
CANNOT see how such an auto-move feature is anything more than a convenience
(and a circumstantial convenience, at that.)
>I can't buy the argument that:
>
> { a, b } = foo()
>
>is somehow 'un-Euphoric' because the number or type can't be determined
>until run time ignores precedent. Despite arguments to the contrary,
>Euphoria actually lets quite a lot of things go until run-time.
No disagreement there.
>For example,
>many languages (like C) require that functions only return values of a given
>type. Euphoria's gets() function actually returns two different types of
>data - a sequence, or an integer. Other languages (like QBasic) commonly
>guarantee that a function will return a value; Euphoria can't make that
>determination until run time.
No, gets() returns one type of data. The beauty of Euphoria lies in the
fact that all data is of the class 'object'. Every function in Euphoria
returns exactly one object. Whether that object is of subclass sequence,
or of subclass atom (and then of subclass integer) is only relevant if you
want it to be, for purposes of transmitting different types of info.
But no matter what the subclass of the object my function returns, I can
still do a " + 2 " to it.
Granted, we pretty much know how the implementation works here, but this
is one area where Rob made this language so lucid; the implementation is
hidden, and not necessary to describe the fact that gets() can return a
sequence or an atom. If Rob changed the documentation tommorrow to show
that gets() returned a data item of type 'object', and to present sequences
and atoms both as literal subclasses of that type, there would be no new
change in the way things worked, or the way we understood things (in fact,
it might make things easier for newbies...)
>The 'for' loop was missing from Euphoria for some time, because Robert
>considered it syntactic sugar. This is too spartan for my taste.
Hmm, well I wasn't around back when "for" wasn't supported, but I tend
to think that the construct would have been one I would have supported
(and I would probably have insisted on an untouchable index variable...)
>Besides,
>Euphoria already supports a mechanism to return an arbitrary number of
>argument from a function. It seems to me there should be a reciprocal
>mechanism to recieve them.
But Euphoria CAN'T return an arbitrary number of arguments from a function.
The fact that the sequence type gets around that so elegantly is another
part of the language's beauty. I can't return 'a' and 'b'. I have to combine
them, make a sequence out of them, and return the sequence. It would be
similar to, in BASIC, returning:
(A * 256) + B
to get back two values from a function.
Yes, I know the above example is much different. Sequences are MUCH less
cumbersome, without arbitrary limits. I'm also not trying to quibble over
the fact that technically, one object is returned even though that one
object contains several other objects. But the truth is, that fact is WHY
multiple-assignment is such a tricky proposal. Every function returns one
object, yet suddenly we're going to have a construct that automatically
extracts (all of or some of, your choice) the elements of that object,
storing those elements at (several different, several identical, or several
arbitrary, your choice) locations? It just seems like an unnecessary and
troublesome convenience, especially considering the limits that would have
to be placed on it.
Rod
