I disagreed with 'symbols' in 1
Roger Hui writes:
Premature optimization is said to be the root of all evil in programming
[Knuth 1974, p.671], but premature generalization is worse. Premature
optimizations can at least be backed off
If we start with only symbols as dictionary keys, then it is easy to let
other objects be keys later; but it is much harder to do the reverse.
In particular, I do not like (<<x) { y, and that is not necessary if only
allowable keys are symbols.
b. I envisioned Dic , newitem as the idiom to add an item to Dic.
newitem would be an item of Dic.
I still do not understand. A dictionary maps keys to values. I infer
from what you say that newitem is a value. Where is the key?
Duplicate keys are interesting and important. There needs to be a
way to get the set of values associated with a key.
Wait--one key can be associated with multiple values? An array is now a
multi-valued function? I strongly object to that.
2c. The number of keys is surely of interest, as is the number of
distinct keys. There needs to be some way to query that, and ($ Dic)
seemed good for the number of keys; perhaps ($@~.) for the distinct keys
Ah--what semantics were you envisioning for ~.? I imagined that, if
supported, ~.Dic would return a dictionary whose keys are a subset of
Dic's, such that no two of the values are the same as each other. The
difficulty would be deciding, given two keys corresponding to the same
value, which to pick.
But given your mention of 'distinct keys' (and above the 'set of values
associated with a key') I think we may still be talking about very
different things when we say 'dictionary'.
2e. This is a real issue. You say 'keys should not be ordered' but I am
not sure about that. This needs discussion.
I think of an array as a function. A function's domain is not inherently
ordered. We may impose some ordering on it; what should we impose (if
anything)?
J defines two orderings: < and /:. Ordinary array's domains are sorted
according to both. Which is the interesting one? I think it is <. < has
interesting properties; /: is simply total for the sake of being total.
And as < is not total, it is not suitable for ordering dictionary keys.
An alternative is to retain insertion order. I think this is definitely
better than ordering according to /:, but am still sceptical that it is
worthwhile. I still do not think of maps as having order.
At least: domain (new primitive) index transpose amend apply-at-rank
filter indices. From rank follows any rank-0 operation. Maybe: key
catenate shape reshape nub index-of tally reduce.
Please: when I was younger, I might have said 'What you say makes no
sense' to mean you were wrong; but after a long life of making mistakes
I mean no more than what I say: I don't get what you're saying. It
might be that I'm dense.
I definitely did not mean to imply that! Just did not know what you
were referring to.
I think the following should definitely be supported:
key { Dic
|: Dic
axes |: Dic
values keys} Dic
u"n Dic
Dic # Dic
I. Dic
Because u"n Dic works, any primitive of rank 0 may be applied to a
dictionary. I think there should also be a new 'domain' primitive that
gives the domain of an array.
I think the following should perhaps be supported, but am not sure:
Dic u/. Dic
Dic , Dic
$ Dic
shape $ Dic
~. Dic
# Dic
u/ Dic
Dic1 i. Dic2
The last sentence results in a mapping from the keys of Dic1 to keys of
Dic2 (call it R), where for any i, (i{Dic1) -: Dic2 {~ i { R. Problems
with i., /, ~., and /. are all the same: order.
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
