1. Re: we need official libs : Swap
Lewis Townsend wrote:
>As long as this thread is still going, here's
>what I'd like to be able to do:
>
>include get.e
>atom num
>num = value ("7") [2]
>
>instead of:
>
>include get.e
>object num
>num = value ("7")
>num = num[2]
>
>Complex assignments are Okay with me but I'd still
>put subscripting function calls higher on the list.
>It seems there's less confusion that could occur.
>Anyone else agree with me, or not?
Hmmm, I've run into some situations where I could have used this shorthand.
But I'm actually rather glad it's not allowed. Your second example is, at
first glance (and at second glance to anyone just learning the language,) much
clearer than the first. And while every now and then I groan at having to
declare a "holding" variable, this is another example of preventing abuse of
the idea; much MORE confusion is possible by allowing it than by not allowing
it.
I'd hate to get someone's code and try to figure out what
d = {1,2,my_function(b[{a,b,c}[h]])[other_func({x,y,z})+({a,b,c}*{x,y,z})[h]]
evaluated to. I'd much rather see it all forced out into some semblance of
order:
e = {a,b,c}
f = e * {x,y,z}
g = other_func ({x,y,z}) + f[h]
k = my_function(b[e[h]])
d = {1,2,k[g]}
Obviously, this example is ridiculously complex, but it does illustrate
the principle: requiring one of the grouping delimiters ([], out of {},[],
and ()) to be used only with variables limits potential nesting.
And believe me, there WOULD be folks who would attempt the above, just because
they wouldn't have to create those extra variables, and could compress multiple
expressions into one.
Rod
