On 5/18/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
On 5/15/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:
I'm assuming you mean outer product, not cross product. That operation
is only supported in R3.
Yes, sorry, outer product.
> 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.
I was suggesting for this to be changed. Would that cause problems?
It would not only fix array slicing but I think generally make the
syntax more consistent and logical. Brackets are an operator (array
reference), just as parentheses are an operator (command
substitution). And just like parentheses they need to match if they
are unquoted. Treating them as token separators, as parentheses are,
would solve the problem of brackets non-matching after expansion. For
example
foo[5 (seq 2)]
would expand to
foo[5 1 2]
and the brackets would match. Again, besides this it would be more
consistent and logical, don't you think?
Then we can still consider which way of expanding is preferable --
concatenation or outer product.
> 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 "]".
I don't think you had an objection to this, did you?
> 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
Yup, my last suggestion has the problem that Beni pointed out with the
"grep" example. But not the previous suggestion, right?
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.
You don't seem to object to the fact that this non-orthogonal to
(duplicates the functionality of ) "{ }".
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
