I originally sent this suggestion directly to Axel, and he seemed
to think there is some merit in it, so I thought I would post it
to Fish-Users and see if anyone else agrees. As I mention below,
I had been trying to design my own shell language -- largely in my
head, as I would surely have never had time to implement it -- and
I am pleased to notice that there are significant similarities
between fish and what I was coming up with. I have a couple of
other ideas that I may post eventually, but first I need to read
the documentation a little more carefully, to make sure that they
fit into the fish way of doing things. In the meantime I will be
most interested in hearing any criticism of this one.
There don't seem to be that many shell language projects out there
(I looked), and I have to say it's good to see someone seriously
working on one that isn't just more of the same old same old. Any
suggestions I might make are made in the hope that some day I might
actually get to use a language that implements them!
John Brock
[EMAIL PROTECTED]
----- Forwarded message from Axel Liljencrantz <[EMAIL PROTECTED]> -----
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on
mailcrunch1.panix.com
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable
version=3.1.0
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Authentication-Info: No information was avaliable at smtp.nada.kth.se
X-Authentication-Warning: my.nada.kth.se: f97-ali owned process doing -bs
Date: Tue, 20 Dec 2005 09:53:42 +0100 (MET)
From: Axel Liljencrantz <[EMAIL PROTECTED]>
To: John Brock <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Re: A suggestion for implementing hashes in Fish
In-Reply-To: <[EMAIL PROTECTED]>
On Mon, 19 Dec 2005, John Brock wrote:
>
> Axel --
>
> I just read your article about Fish at arstechnica.com. I had also
> been thinking about designing a shell language, although I knew I
> would never find time to actually implement it. There is one idea
> I had which I think is particularly clever, and which I thought
> you might find interesting.
>
> I see that Fish has arrays, and that in fact all variables are
> arrays. The same is true in my language. However in my language
> all variables are simultaneously arrays and Perl style hashes!
> There is only one variable type; every variable can serve as either
> an array or a hash at any time.
>
> Here is an example. Consider the array:
>
> set tst tom 2 dick 5 harry 17 jane
>
> This creates a 7 element array named "tst". If you look at this
> variable as an array -- the way you currently look at it -- the
> value of the 4th element, $tst[4], is "5".
>
> My suggestion is that by using a different syntax you can always
> look at any array as a hash. The way it works it to take the key
> you are interested in, lets say "dick", scan through the *odd*
> elements of the array until you find a match, and then the even
> element following that match would be the result of the hash lookup.
>
> For example in this case the value of $tst{tom} (notice the curly
> rather than square brackets!) would be "2", $tst{dick} would be
> "5", $tst{harry} would be "17", $tst{mary} would be "" (since there
> is no such element), and $tst{jane} would also be "" (since there
> is no value following "jane" in the array). Of course there are
> other ways the syntax could look, for example $tst[[tom]] rather
> than $tst{tom}. Whatever works best for you.
>
> As for setting and deleting hash elements, the obvious:
>
> set tst{tom} 22
>
> sets the first and second elements of the array to "tom" and "22".
>
> set -e tst{tom}
>
> removes the first and seconds elements of the array.
>
> I've thought this though, and the obvious conceptual problems all
> seem to have fairly obvious answers. For example, if a key occurs
> more than once in an array, only the first occurrence is used. If
> you delete an element from the hash, then both the key and the
> value are deleted from the array. As far as I can tell, it all
> works.
>
> The advantage to all this is that you don't have to introduce a
> new data type for hashes, just a little bit of extra syntax! Of
> course, for large hashes the naive lookup -- just starting from
> the beginning of the array until you find a key match -- would be
> very inefficient. But there is a hidden beauty here: you are not
> limited to using a naive lookup. At the point where a large array
> is first used as a hash you have the option of transparently
> generating an index and attaching it to that variable. From then
> on all hash access would use the index, which solves the efficiency
> problem. The user would never even need to know!
>
> Anyway, if this seems like a good idea to you please feel free to
> use it. Let me know if you have any questions. Actually my only
> request is that you answer this e-mail and let me know what you
> think about my suggestion, whether positive or negative. And good
> luck with Fish -- we really do need fresh thinking with Unix shells!
Hi James.
The idea of using hashes in fish is a very good one. We have actually
discussed this on the mailing list, and I added an entry to the todo
list. (Though we called them map-variables and not hashes. Different
backgrounds, I guess)
The solution we discussed was a bit different, it consisted of
inventing a key-element separator character and store key and value
as a single element. When doing so, it would be readily detectable if
an array was a map variable, so we could simply use the same
notation, i.e. $foo[horsie], etc.
I must admit that your proposed solution seems to have fewer edge
cases, and while I'm not thrilled about using different brackets to
differentiate between maps and arrays, it really does make sense in
many ways. And everything is both an array and a hash seems pretty
useful, for transparency, etc.. It seems a pretty fair tradeoff.
If you are interested in discussing language features, please
consider joining the fish-users mailing list on sourceforge.net.
>
> John Brock
> [EMAIL PROTECTED]
>
--
Axel
----- End forwarded message -----
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
