guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mikael Djurfeldt
Subject: Re: fixes to goops + light structs + 'u' slots
Date: Sun, 20 Apr 2008 01:07:39 +0200

2008/4/19, Andy Wingo <address@hidden>:
> > I wash my hands.  :-)  When I left, structs where two words.
> commit 08c880a36746289330f3722522960ea21fe4ddc8
>  Author: Mikael Djurfeldt <address@hidden>
>
>  It is natural for our memory to fade over this much time ;-)
>
>  But if at any point something sparks in your brain to figure out a way
>  around the GC chain, I'd certainly be interested. Otherwise we could put
>  that empty third word to good use.

Sigh... 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.  Of course, when looking
at it now, it doesn't look like good design.  In fact, and to be
honest, I've never had the impression that structs are good design
either.  The GC chain mostly looks like a bug fix, doesn't it?  The
problem is that you don't always have time and resources to redesign
the whole thing.  Most changes I've done to Guile have been done for
the use of Guile in my work.  The Right thing to do is probably to
throw out structs and design new GOOPS objects, something I  wanted to
do from the start.  Also, when considering GC-related
things---remember that a lot of design decisions have been made
against the garbage collector as it looked like three revisions ago,
or something like that.  The current GC is a very different beast.

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.  Some code
needs to be replaced, but then, again, some code has thought behind
it.  Since you say that you couldn't find information in the workbook,
I'll try to dig up my ideas regarding the PURE_GENERIC flag and the
apply-generic MOP.  The extended-generic stuff is a way to get
insulation between two modules A and B which both import a module C.
Otherwise I think I should shut up.

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).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]