Comments on: Allow MAP! indexing?

The MAP! datatype is a dictionary, providing a hashed access storage method.

Recently, we extended MAP! to allow integers as keys (in addition to words and strings). This is handy to manage sparse arrays.

For example:

m: make map! 100
m/1: "this"
m/10: "is"
m/500: "an"
m/1234567: "example"

>> print [m/1 m/10 m/500 m/1234567]
== this is an example

Ok, agreed, that kind of thing can be very useful.

However, now we've lost the ability to ever access the map as a series, independent of its key values. We now get:

>> first m
== "this"
>> pick m 1
== "this"
>> pick m 2
== none

Is this a desirable result, or did we just lose something?

Note that we can still use the select function to obtain values from keys:

>> select m 1
== "this"

So, for maps, pick is a synonym for select. They are the same.

But should they be?

There are times when I want to obtain the first value of a MAP! to use as a default value for something. At other times, it would be nice to be able to iterate over the MAP!, even though we are not guaranteed the order of the elements. And, to be safe, we may only allow index by number, not by series offsets (more research is required there.)

Although it is true we can use to-block to return the map as a block, for a simple index access that operation is not efficient.

Your thoughts?

9 Comments

Comments:

Paul LYS 29-May-2008 14:54:24	It is a shame to lose access as a series because it is very natural rebol access to such data as well. Also the effort to maintain this type of access seems to me necessary. pick is sufficient to access map! (instead of select)and It's more consistent.
Gabriele 30-May-2008 5:20:04	Personally, the only thing that I miss is being able to do: foreach [key val] m [ ... ]
Norm 30-May-2008 10:04:28	In some fields it would be an important feature, as sparse maps are frequent, like the association an arbitrary number to a classification string in library applications and linguistics. Opportunities to classify what is not are frequent. One could suppose the need to maintain an internal link list here, but you are a better judge of that. The built in iteration mecanism would otherwise have to be built externally by the programmer, as I suppose, from usage, the need of it would become universal. Thanks to cater for usefullness.
Andreas 30-May-2008 18:08:47	Is there no way to get only the keys and/or values of a map!?
Chris 30-May-2008 21:04:43	I'd go for different meanings -- pick to return an item by offset and select to return it by reference.
Paul LYS 31-May-2008 18:49:04	I think we need to be Radin into words, so use one word "pick" (possibly with a refinement) instead two ("pick" and "select"). I prefer pick by what most rebolish (select is more SQLish).
Brian Hawley 2-Jun-2008 11:16:25	I'm a little wary of having maps have an ordering - it doesn't really act like a series, at least not a series of individual values. And what would the order be? Order of addition of key/values to the map? Would sorting even make sense? If it does have an ordering, what would be at an index: value, key or tuple? I would like to have keys-of and values-of functions that would return blocks of keys or values, and foreach to iterate over both (like Gabriele's idea). Chris' idea of having pick and select behave differently sounds interesting too, with both functions returning values, not keys. We should be selective as to which of the series functions would also support map!, and the best way to do so may be to not have map! be a series.
Brian Hawley 2-Jun-2008 12:14:11	Also, it would be helpful if values-of would not return none values, keys-of would not return their keys, and foreach and any other ordered functions would skip over them. We want to keep consistent that amap/akey: none effectively removes the key from the map, as that is too valuable a principle to mess up.
Oldes 9-Jun-2008 12:31:01	I cannot help myself but I'm still missing fast Hash! (dictionary!) table where key can be of ANY value - or at least binary!

Post a Comment:

You can post a comment here. Keep it on-topic.