Yes, the constructors, selectors, and setters of named records, as opposed
to some S-expression implementation schema can be described via flow
equations. So can hashtables, but not as nicely. Everything that goes into
a hashtable is a symbol. Everything that comes back is everything that went
in. So, how are you going to keep track of separate kinds of values?

-- Matthias

At Thu, 3 Apr 2003 14:47:35 -0800 (PST), bear wrote:
>
>
> On Thu, 3 Apr 2003, Matthias Felleisen wrote:
>
> >
> >
> >> >Constant access time and analysis via 0CFA/SBA. -- Matthias
> >>
> >>
> >> Constant access time is satisfied by a hash table implementation.
> >> Compile-time analysis is easily handled by constant propagation
> >> through the hash function.
> >>
> >> 			Bear
> >
> >Would you mind showing us the equations that govern the analysis of
> >such property-lists-as-hashtables? I am also interested for very different
> >reasons.
> >
> >-- Matthias
>
> At this point I will have to admit to slight bafflement.  Constant
> propagation during compilation would allow you to avoid running the
> hash function at runtime if you are using named properties, in the
> same cases where you don't have to compare the field names in a
> record operation explicitly to a list of possibilities.  But I am
> reasoning from the perspective of a compiler hacker rather than the
> perspective of a mathematician.
>
> What relationships would the equations you wish to see express?  Are
> there similar equations which express similar ideas for named fields
> in records?  And if so, can I look at them to see if they are
> adaptable to the hash table implementation of property lists?
>
>
> 				Bear