On 19 Oct, 19:23, rem6...@[EMAIL PROTECTED]
(Robert Maas, see
http://tinyurl.com/uh3t)
wrote:
> > From: James Harris <james.harri...@[EMAIL PROTECTED]
>
>
> Are you the same JSH who usually postes crankish stuff about
> factorization algorithms to sci.math? If so, this is an amazing
> improvement to see you posting like a normal person instead:
No, not the same person. An overloaded name!
....
> > FWIW I would call all of these mappings from a source set to a
> > result set. Mapping seems to me to be more general.
>
> I wanted to get just the right amount of generalization. IMO
> "mapping" as you define it is too general.
....
> > When I saw your question I thought 'associative array' as that is the
> > most familiar term.
>
> Yeah, that's what I thought too, probably because I saw the term in
> some tutorial for Perl or PHP or both. But in both languages the
> syntax is as if arrays, which tends to eliminate Japa 'map' and
> Lisp 'hashtable' as anything the reader would think of.
In my case that's the term I've known for so long I cannot recall
where I first heard it. All these years I've assumed that it was the
correct term and that names used in languages (Perl: hash, Python:
dictionary) were simply attempts to reduce 'associative array' to a
single-word name. Maybe not.
> > Of the comments you've already received 'keyed array' from Frank
> > Swarbrick was a new one to me but immediately conveyed the thought.
>
> Yeah, except it too has the connotation of it being syntactically
> an array rather than a hashtable or balanced tree or association
> list etc.
Haha. Sounds like the only possible term for the things you want to
cover is, "data structure."
Seriously, how about keyed data structure?
In trying to design data structures for a new language I am coming
round to the view that the name /could/ be dispensed with altogether.
I wouldn't recommend this yet but the reasoning is as follows.
Option 1 is to provide a small set of limited structures that cover
most cases. Option 2 is to provide a comprehensive suite of
structures. There may be a middle way, option 3, to provide combinable
features. These could be:
1. How do you want to index the data - names, integers, both?
2. Can names be used bare or do they need to be quoted? For example,
cheque["payee"] and cheque.payee.
3. Does storage have to be contiguous?
4. Does the whole structure need to be in memory?
5. Are data to be returned as tuples or as packed binary and is the
index/name to be included? (The name is normally included when
considering database records but not arrays. The array approach is
fine as long as only one item is being referenced but does not work
well for a range. For a range each index may be needed to identify the
row or record returned.)
> > Someone else said that a dictionary was familiar to IT folk. I think,
> > though, that Database people might think of a data dictionary.
>
> Yeah. At first I thought "dictionary", mentionned by one of the
> early posters, was the right DB term, but when I actually looked it
> up I realized it refers more to XML semantics, basically a set of
> restructions on the basic XML syntax, given as a set of allowed
> usages, nothing else allowed unless explicitly listed, sort of like
> BNF. Obviously that's nothing at all like what I am trying to name.
> So that would be even more misleading than "... array".
Don't forget that the XML or any other meaning of a word may itself be
a corruption of an original term. There are probably few terms which
are unambiguous.
> > How do you want to use the term? Is it for a language or library, or
> > is it for communication with humans?
>
> Not for a language, i.e. I'm not designing yet another programming
> language. Common Lisp and Java and PHP are quite enough for my
> present needs.
OK.
> For in-code comments/do***entation as well as formal external
> do***entation and posted articles or Web pages summarizing what
> I've accomplished.
OK.
> For example, I've long known the term "Balanced
> Binary Tree", but just recently I've switched to the more accurate
> term "Self-Balancing Binary Tree". (Technically as a mere
> structure, it doesn't balance itself, the associated functions or
> methods do the balancing of it. But as either an OO class or as a
> package of functions "it" balances itself in the process of
> ordinary usage when put or delete methods are called, and with
> splay trees even 'get' method usually rebalances. You don't have to
> call a special method outside the package which externally performs
> a balance, as might be implied by the original term.)
Sure.
> Only for a library in the sense that I'd like the function/method
> names to correspond to the do***entation to make it easier to use
> the API for it. For example, assume class/library MKVL meant
> "Maas Key-to-Value Lookup", then the functions might be:
> make-mkvl
> mkvl+key+val-put
> mkvl+key-find
> mkvl+key-delete
> mkvl-size
Here you could use associative-array or associative-data-structure but
programmers would not like the bother of the long names (a pain to
type and inhibit compactness, most notably requiring some calculations
to split over a line). Perhaps that is why language designers make up
a name or put their own interpretation on an existing term.
Some options:
keyed-node (a node can exist in many structures)
keyed-tuple (generic keyed info)
though perhaps it depends on whether you see the node or the
collection of nodes as being keyed. Maybe:
keyed-collection
> and for OO method or named package you'd just drop the "mkvl"
> prefix since that's redundant with the package name or class name:
> Lisp package: (setq animals (mkvl:make)) (mkvl:put animals "Carp"
"Fish")
> Java class: Mkvl animals = new MySuperHashTable(); animals.put("Carp",
"Fish").
> where MySuperHashTable implements the Mkvl interface, for you Java
experts.
>
> So I want the self-do***enting code and the comments and formal
> do***entation and discussions/advertisements to all use the same
> easy-to-grok jargon.
Understood. I'm curious to find out what you finally choose. You'll
have to let us know.
--
James
|
