Re: fixes to goops + light structs + 'u' slots

[Andy Wingo]

Hi,

On Sun 20 Apr 2008 01:07, "Mikael Djurfeldt" <address@hidden> writes:

> Well, apparently I'm the very author of this GC chain thing you are
> talking to me about. The only thing I can say is that there was
> probably a reason at the time to do this.

The reason is simple: you need a class to know how to free an instance.
If a class and all of its remaining instances are all unmarked and thus
sweepable, we need to sweep instances before classes.

The particular strategy for dealing with this (i.e. GC chains) is ugly,
however.

> In fact, and to be honest, I've never had the impression that structs
> are good design either.

They're not in many aspects (heavy/light/entity representations, tail
args), but the fundamentals are OK I think: word-vectors that are
interpreted by other word-vectors (denoted "vtables").

> The Right thing to do is probably to throw out structs and design new
> GOOPS objects, something I wanted to do from the start.

You might be right; OTOH we could just weed out those anachronistic
parts of structs, and orthogonalize the struct interface, making structs
contain the minimum necessary to support GOOPS objects and SRFI-9
records.

> Also, I've seen your GOOPS todo.  It's nice to see your willingness to
> continue development on GOOPS.  Unfortunately, I won't have the time
> to help.  Just don't be too quick to throw things out.

ACK. I'll be mailing patches to the list, so if you have time, take a
look and carp if things aren't going well.

> Otherwise I think I should shut up.

If it's for your own reasons, fine, but your insights are appreciated.

> Oh, and please *don't* try to compile methods at macro expansion time.
>  GOOPS method compilation is based on the crazy idea to have one
> compiled method per combination of argument types.  The idea is that
> this won't give you a combinatorial explosion if you compile lazily,
> waiting until the first application for a certain combination.   This
> was an experiment.  Apparently, it works well enough in practise.  The
> *big* possibility is that since each compiled method in the method
> cache has typed arguments, there is the opportunity for *very*
> interesting optimizations, such as elimination of a lot of the type
> dispatch (e.g. that in accessors and in other calls to generics).

Interesting!

Well, off to hack, or something. Thanks for the note.

Andy
-- 
http://wingolog.org/