[chuck-users] get hash keys from associative array
signal.automatique at gmail.com
Wed Sep 26 18:45:16 EDT 2012
On Tue, Sep 25, 2012 at 09:21:17PM -0400, George Locke wrote:
> Is there anything like this, some way for an associative array to tell you
> what keys it has?
No, I don't think so. They are convenient, as long as you remember
what you put where, but you can't get a list or loop over all of them,
etc. This means you can have a array of size 0 taking up a GB, with no
sure way to get to this data, theoretically.
> Ge apparently mentioned it as a development goal for 6 years ago (
> https://lists.cs.princeton.edu/pipermail/chuck-users/2006-March/000436.html ),
> but searching for "key" in the versions page shows no update in this area.
I think you are right and that this leads to some interesting
consequences. Since we don't have things like lists or vectors we tend
to use arrays for a lot; they are our one generic higher level
structure. Because of that, over the last few versions, we got extra
features for them; ways to change the size and a sort of push/pop
structures making them usable like a sort of stack.
I feel that especially those two features imply a sort of usage where
we might expect the ability to totally flush a array (for example at
the start of a new movement to our piece or when a new user picks up
our instrument or....) because of what you note we can not actually do
that. IMHO that makes this kind of feature more coherent with the rest
now than it was when Ge planned to do it. Something like;
which I imagine would return a anonymous array of strings, each of
which would represent one named index. Such a thing we could loop
over. I also imagine;
which would either return the contents of the named entry "foo" and
clear that entry from memory or result in a error/warning if "foo"
would happen to not be a entry.
I think that would bring things more in line with the rest and that
this would be worthwhile, given the notes above. I just came up with
these as I typed; some peer-review would be welcome.
I am, BTW, not at all opposed to just having one generic higher level
structure; it does add coherence and clarity and avoids conversions,
assuming our one such structure behaves very well.
More information about the chuck-users