On 5/15/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:
On 5/13/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> Dang, I _knew_ you where going to bring that up sooner or later. You
> are perfectly correct, spaces are allowed between brackets. It's ugly
> and slightly evil, but ever so useful.
How is it useful that Space is a cross-product operator inside brackets?
I'm assuming you mean outer product, not cross product. That operation
is only supported in R3.
It's not. Space simply doesn't tokenize inside brackets.
foo[1 3 7]{a,b,c}
becomes
foo[1 3 7]a
foo[1 3 7]b
foo[1 3 7]c
> To make things worse, there is
> an exception to this rule, since lone brackets are ok, since '[' is
> often a symlink to 'test'. But still I think this is a relatively
> small source of confusion making [] even more magic would in my
> opinion be bad.
Well, brackets have a similar syntax to parentheses (but different
sematics). Parentheses are not subject to the corss-product
expansion, and brackets should not be either. They should be treated
as special, otherwise we get the problems of matching as you
mentioned.
Parenthesis currently cause an outer product. Brackets are treated as
any other character except that most of the time, spaces inside
brackets are not interpreted as a token separator.
> But I have though about scrapping the magic status of [], one could
> popssibly do some form of magic, weird recombining of parameters
> during expansion.
>
> If given the three parameters '$foo[1', '5' and '7]', a clever
> recombination pass coul try to make sure all variable array brackets
> properly close. The set builtin could do the same. It's harder to
> implement for sure, but [] would no longer be magic and the syntax
> would remain otherwise unchanged. Might have weird corner cases,
> though.
All sound like kludges. You could auto-insert a space after '[' and
before the matching ']' and then carry on with expansion as usual
(without treating spaces as a cross-product operator). But this is
equivalent to ignoring matching brackets when doing cross-product
expansion.
So I'm not sure which is a cleanest solution: (1) no cross-product of
brackets or (2) concatenate adjacent arrays or (3) both together.
With (2)
[a (seq 2)]
expands to the four elements "[a", "1", "2" and "]".
Or you can even string-concatenate their adjacent elements to produce
the 3 elements "[a", "1" and "2]". This approach also seems to me
sensical in general, maybe more sensical than cross-product of
adjacent arrays.
a b(seq 2)c d
would expand to
a b1 2c d
I don't like this one, since you'd need special magic for _any_ type
of array slicing. Even trivial slicing operations like
echo $PATH[(seq 3)]
will break. You'd need to somehow concatenate the elements, e.g.
echo $PATH[(seq -s " " 3 )]
or
echo $PATH[{(seq 3)}]
both of which are ugly.
In the end, none of the proposed solutions are perfect, but I have yet
to see one solution which has fewer corner cases than the simple outer
product. That said, the expansion order should probably be looked
over, as beni pointed out.
--
Axel
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
