On 5/12/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
On 5/11/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> On 5/10/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:
> >
> > Sorry, I was not clear.  I did not mean anything about the "set"
> > builtin.  I was suggesting that
> >
> >     foo[(seq 1 2)]
> >
> > should expand to
> >
> >     foo[1 2]
> >
> > not to
> >
> >     foo[1] foo[2]
> >
> > One way to achieve this is to make expansion work differently with
> > brackets than with other strings.  Currently,
>
First, perhaps just allowing quoted command substitution, a-la quoted
variable expansion, would be enough for this indexing issue:

    set foo[1 "(seq 4 7)"] a b c d e

(Currently quoted parens are not expanded.)

The idea has struck me as well. IT has the advantages that it is
consistent with array expansion, but the drawback that double-quoting
mode becomes even more different from single-quoted mode. I am far
from thrilled at having three different quoting modes to begin with.


> I am uncomfortable with making command substitution tokenize
> differently depending on whether we are in brackets or not. Introduces
> far too much modality.
>
Perhaps it doesn't.  It shouldn't be specifically command substitution.
We could define that content inside brackets is always parsed as a
nested command line: it is a space-separated list of words, with each word
possibly expanding to many words.

The effect that we want here is exaclty the joining (of word lists,
not concatenation of words) that happens in::

    echo 1 (seq 4 7)

So we want a new way to apply such concatenation in a part of command line.
Properly designed, it could be a useful operator.  We still have to decide what
is done with the result: ``foo[1 4 5 6 7]`` or ``foo[1] foo[4] foo[5]
foo[6] foo[7]``.

What I still don't like about this direction are the brackets.  If
[...] become a
syntax for joining word lists, they shouldn't be left in the result --
if they are, it's
only useful for indexing.

Interesting.


Now, later in this thread you explain that all expansion in fish works as
outer products.  For example::

    echo %.(echo a\nb).(echo 1\n2)
    echo {%,(echo a\nb),(echo 1\n2)},

prints::

    %.a.1 %.a.2 %.b.1 %.b.2
    %, a, 1, %, a, 2, %, b, 1, %, b, 2,

The first is obviously useful, for some of the examples you gave.  The
second is questionable.  Consider this equivallence::

    echo {a,b},
    set v a b; echo $v,
    echo (echo a\nb),

All print ``a, b,``.  But nesting them breaks the equivallance::

    echo {%,{a,b},{1,2}},
    set v a b; set n 1 2; echo {%,$v,$n},
    echo {%,(echo a\nb),(echo 1\n2)},

print::

    %, a, b, 1, 2,
    %, a, 1, %, b, 1, %, a, 2, %, b, 2,
    %, a, 1, %, a, 2, %, b, 1, %, b, 2,

This is strongly inconsistent and counter-intuitive!

Right. I'd never really though about it, but it all bouls down to
ordering. The first one is expanded outer-to-inner, the second one
inner-to-outer. Actually, the expansion rule is something like this:

1). Expand command substitution, left to right
2). Expand quoting and backslash escapes
3). Expand home directories and process ids
4). Expand brackets, from outer to inner
5). Expand variables, from right to left (this order is needed in
order to make array indices expand before the array itself)
6). Wildcards

I guess that, as your example shows, inner-to-outer expansion is much
more intuitive, even if it is harder both to implement and to define.
This is definitely worth thinking about.

I agree brace/command/variable expansions written side-by-side
(``%.$v.(seq 2)``)
should form an outer product, but inside braces, I think they should be joined,
just like ``{%,{a,b},{1,2}}`` produces ``% a b 1 2``.

What I'm driving at is that braces, not brackets, should be the
joining operator
that I talked about.  And while at that, they should be space-separated like
everthing else in fish, not comma-separated.  Yes, another incpatibility -- but
more consistent and easier to write.

This has come up before. Personally, I think using space as the
bracket separator is a rocking idea, but it was voted down before,
mostly because of compatibility, if I remember correctly. But if we
can redesign the whole parameter expansion system to work very well
with spaces, then I think it's a good enough argument to break
compatibility.


--
Beni Cherniavsky <[EMAIL PROTECTED]>, who can only read email on weekends.
Governments are like kernels - everything possible should be done in user space.



--
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&kid0709&bid&3057&dat1642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users

Reply via email to