Re: [TCLCORE] Unifying list and dict types

[Andy G. <unu...@ai...>]

"Alexandre Ferrieux" <ale...@gm...> wrote:
> On 2/1/10, Andy Goth <unu...@ai...> wrote:
> > (Is this the right forum for this type of discussion?)
> 
> If it's not, we're doomed :}

Next time I'll try 4chan.

> > I believe it is possible to merge the list and dict Tcl_Obj types
> 
> I sympathetize with the idea of inheritance among obj types,

This is a specific performance optimization made to existing types, not the
introduction of a new type or a new method of organizing types.  Dicts are
key/value lists, so let's store them in memory that way.  They just happen
to have fast access via hash tables.

Also: Does my mailer really spit out long lines like that?  Sorry.  I'll see
what I can do to fix it.

> given Donal's reaction to the suggestion I have more or less given it up:

Inheritance and Tcl_Obj operate at two wildly different levels.  Inheritance
is an arguably useful concept in systems of aggregating code and data,
whereas Tcl_Obj is a way to store an individual piece of data.  Sure, a
Tcl_Obj can be a container for other Tcl_Objs, but only in simple ways.
(This is true for the core types, at least.  Extensions can do what they
want.)  Inheritance is best done either at the script level or with the aid
of an extension, not by wiring it into the primitive value storage system.
I'm not proposing a general mechanism of inheritance, and describing my
proposal in terms of inheritance makes it harder to understand, not easier.

> I must say that the lack of a "compelling need" plays an important role
> though...

This change improves performance and reduces memory usage.  It provides a
testbed for a better hash table implementation, which could eventually be
adapted for Tcl-wide use, with Tcl_HashTable becoming a compatibility
wrapper.  It enables Tcl programmers to mix and match lists and dicts
without guilt.  None of these are compelling needs, but optimizations rarely
are.  My intention is to preserve the script interface or the C API, so by
design this change doesn't open up any new possibilities.

> Uh, maybe I'm missing something, but doing this you'll wreck repeated
> headers, right ?  The standard idiom for {HTTP,SMTP,SIP} headers is rather
> (with array, translate to dict if you want): lappend values($header) value

The idea is to only do [dict get] when reading headers for which repetition
is illegal anyway, but use list methods when reading repeatable headers.
But that approach derives from Wibble's lack of header parsing; it just made
a key/value list of headers without attempting to understand them.  The
current development version of Wibble not only makes a list of headers, but
it also converts many headers into easily parseable dicts and lists.  It
should be able to merge all repetitions of a header into a single list, and
it should know which headers allow this.  So for Wibble I will basically do
as you suggest, but that doesn't mean I'm not still interested in improving
the performance of [dict] in Tcl.

> is there a "compelling need" for a new bump in code complexity ?

Much of [dict]'s complexity is due to having to cover for Tcl_HashTable's
shortcomings.  For example, it has to chain all the entries together into a
linked list.  I expect much of the code will become simpler as a result of
ditching Tcl_HashTable in favor of something more targeted.

-- 
Andy Goth | http://andy.junkdrome.org./
unununium@{aircanopy.net,openverse.com}