On 5/12/06, Beni Cherniavsky <[EMAIL PROTECTED]> wrote:
On 5/11/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
[...]
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
I guess that is consistent with the use of dollar-sign inside double
quotes. But is it better a better syntax for splicing than
foo[5 (seq -s ' ' 2)]
which works anyway?
> 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.
Brackets can be made a general array concatenation operator (instead
of curly brackets as you propose), in addition to being used for array
indexing. So they would be useful in general.
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.
The first can be achieved as
echo %.{(echo a\nb)}.{(echo 1\n2)}
As described in the Fish documentation, that's what curly braces are
for -- cross-product -- and that's how they are used.
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!
I agree that output of examples 2, 3, 5, 6 is unintuitive and
inconsistent. It has nothing to do with the curly braces, only with
cross-product. Examples 1 and 3 output what they do because {}
performs cross-product (as in Bash). That's consistent and intuitive
to me.
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``.
Then what's the use of the curly braces? Just write
% a b 1 2
or
% $v $n
The arrays won't be crossed because they are not adjacent.
What I'm driving at is that braces, not brackets, should be the
joining operator
that I talked about. [...]
So we agree that the splicing should be fixed by changing expansion
behavior, but you take the converse approach -- you want the default
operation (without braces) to be outer product, and the braces to
concatenate arrays. I want the default operation to be concatenation
and braces to perform outer product.
I think the second approach makes more sense, for several reasons.
First, I think it is more intuitive that things sitting together
before expansion still sit together after expansion. It seems more
straightforward that
a[5 (seq 2)]
should expand to
a[5 1 2]
than to
a[5 1] a[5 2]
And it is a simpler to remember that
a(echo 1\n2)
expands to the same as
a"1\n2"
Second, it is more like other laguages. In Bash, adjacent strings are
concatenated (echo a$(seq 2)), and curly braces perform cross-product.
In Python adjacent strings are concatenated (they have to be quoted).
In Matlab adacent lists are concatenated ([[1 2 3] [4 5 6]]).
Third, I think concatenation is more commonly needed than
cross-product. For example, with the first design, you have to write
the braces, "arr[{5 (seq 3)}]", while with the second you write just
"arr[5 (seq 3)]". Writing "arr[{5 (seq 3)}]" is not much simpler than
"arr[5 (seq -s ' ' 3)]" or 'arr["$indeces"]', so using explicit
concatenation defeats the purpose of simplifying array splicing.
True, the tradeoff is that with the first design you can just write
"rm img(seq 4 39).jpg", while with the second, you have to write "rm
img{(seq 4 39)}.jpg". But I think it makes more sense that
cross-product should be an explicit operation, and it is less common.
-------------------------------------------------------
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
