Online listserve & email list hosting made simple

At Thu, 3 Apr 2003 17:52:50 -0500, Matthias Felleisen wrote:
>
> 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?
The analysis must (can) figure out which symbol goes where (in some
programs). This is only more difficult because of the kinds of programs
people tend to write when they have the ability abstract over the keys
in the hashtable, but you can write such programs with define-struct
style structures too. This program:
(define-struct s (a b c))
((case (read)
[(0) s-a]
[(1) s-b]
[else s-c])
(make-s ...))
is going to cause most analyses to conflate to the fields of a
structure (you can do similar tricks as you construct the records).
Of course, people tend not to use structures that way. So, in a
"practical" sense structures are more amenable to analysis and I, for
one, think you want both in a real PL (plus, you sometimes want the
efficiency for a structure -- say when you are implementing a class
system).
Long live lambda! :)
Robby