On 5/25/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:
On 5/18/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> On 5/15/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:
[...]
> > 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?
Probably. But if the syntax becomes better, then we can manage.
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?
If I understand this correctly, you mean that brackets should be made
into some form of concatenation operator that makes sure everything
within is made into a single string. This seems like a bit of a
special purpose operator. Are there any other use areas than for array
slicing? If this is generally useful, then I think this makes a lot of
sense.
Perhaps it could be used with $ to drop the sillyness with $ expanding
to a single token inside "". Instead, [$foo] is always a single token.
Worth considering.
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?
The problem I see is that set and friends expect complete slice
specifications, e.g.
'foo[1]' 'foo[2]' 'foo[3]'
not
'foo[1' '2' '3]'
It's not hard to update the code to guess the latter case, but I'd be
surprised if there aren't any weird corner cases lurking around.
> > 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?
True, the [] as concatenation operator doesn't need any insane
[{}]-syntac to perform simple slicing.
> 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 ) "{ }".
The way I see it is that we have a bunch of parameter expansion
operators, and that they eachg have an orthogonal function (process
expansion, command substitutuion, variable expansion, etc.) but the
way they are _combined_ should be consistent, not orthogonal.
--
Axel
-------------------------------------------------------
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&kid=107521&bid=248729&dat=121642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
