Re: Heterogenous lists [ was Re: [boost] BGL: property "num" members ]

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2002-01-15 18:46:13

On Tue, 15 Jan 2002, Emily Winch wrote:
emily>
emily> Yep. Only, I went to tidy it up, and then I realised that every design
emily> decision I made was with the intent to mock up a quick proof-of-concept for
emily> the paper, and not to actually produce decent code :-)
emily>
emily> So then I discovered a nasty issue with my plot to have clones of the
emily> standard algorithms that work on this kind of list. In brief: How do the
emily> names get out of the list and into the functors called by the algorithms?
emily> and crucially, How can I do that while keeping my algorithms general to
emily> _all_ compile time object lists (e.g. boost::tuple, or some future
emily> heterogenous_vector), and without making the algorithm implementations
emily> smell?

Can we leave the algorithms for later, and first just get the
association_list into Boost? It's much easier for us lazy folks to review
small peices at a time :)

emily> That begs the question, do the functors need to know the names? Can anyone
emily> think of a use for an associative_list that would require that? The paper
emily> mentions some, but none of them to my mind are sufficient to justify the
emily> capability without more concrete evidence that they'd be useful to someone
emily> in real life.

I think the functors would indeed need to know the names. BTW, I would use
the term "key" instead of "name", since that is the terminology typically
used with an association list. So I would pass the functor some kind of
key-value pair, where the key is just a unique type, and the value is the
associated value object.

emily> I'm just hoping that there aren't _other_ attributes (apart from names) that
emily> items in hypothetical heterogenous container implementations might need to
emily> introduce to functors. Otherwise each element of a heterogenous container
emily> would need a heterogenous container of attributes :-)

If we stick to the idea of an associative list, a list of key-value pairs
where you look up value's based on keys, then we don't need to worry about
this other stuff. Those problems can be solved by other software
components. We don't have to solve everything all at once :)

BTW, in the Scheme programming language (and lisp too), they have a bunch
of functions for dealing with associative lists (but with run-time, not
compile-time lookup). They have the names assq, assv, assoc.

http://www.cs.indiana.edu/chezscheme/tspl2d/objects.html#g2055

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                          http://php.indiana.edu/~jsiek/
 Ph.D. Student, Indiana Univ. B'ton   email: jsiek_at_[hidden]
 C++ Booster (http://www.boost.org)   office phone: [phone]
----------------------------------------------------------------------