On 5/26/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
On 5/26/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> 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.
>
Note that for indexing you the brackets to remain in the expansion
(a[1] a[2]), but for general use you want the operator to disappear.
Well, in the parameter expansion pass, we could do something clever to
keep track of where there used to be a bracket, so that even if we
drop the brackets, things keep working. Fish already does something
like that in order to make sure that e.g. '$foo(echo bar)' or
'{$foo}bar' gets expanded to the contents of variable '$foo' plus the
string bar, not the contents of the variable '$foobar'.
Trouble is, that wouldn't work for assignment using the set builtin,
since set doesn't have access to internal expansion states.
I don't really see how one can use [] for both a general purpose
concatenation and for special purpose variable slicing. But it would
be nice if it is possible to work this out, this solution only uses
general purpose operators that have multiple use cases. I really like
that. But currently, I can't see a way out of the problem with dropped
brackets in set.
[snip]
> '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.
>
Yikes! Forget the implementation, this would be a weird corner case
in the syntax, which is even worse ;-)
If you want to go that way, at least tokenize on the brackets:
'foo[' '1' '2' '3' ']'
or:
'foo' '[' '1' '2' '3' ']'
The above assumes tokenization on spaces, same as always. Why is that
weird? I guess one could implicitly tokenize arguments around
brackets, but I'm not sure why you'd want to.
But remember that set syntax should mirror $foo[abc] expansion syntax.
We want something elegant that works for both, and splitting to
multiple words like this doesn't look like somthing that fits
expansion.
Definitely, and I guess that is the main trouble. We can't play any
magic syntax games with 'set'. But the lack of magic syntax games is
also an advantage, for example a user could define:
functions set
set -x $argv
end
in order to make sure that variables are always exported by default.
How about this idea: let brackets be like braces but space-separated
and the brackets remain in the expansion, and let them expand *before*
brace and command expansion.
Then 'a[7 (seq 2)]' expands into 'a[7]' 'a[(seq 2)]' which is then
command-expanded into 'a[7]' 'a[1]' 'a[2]'. Subtle but appears to
work. Don't know whether it matches the Right order of expansion in
general.
That would work. Then main disadvantage I see is that the suggested
bracket expansion is really pretty useless for anything other than
variable slicing, which is a shame.
--
Beni Cherniavsky <[EMAIL PROTECTED]>, who can only read email on weekends.
Governments are like kernels - everything possible should be done in user space.
--
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
