Re: Swindle question & bug report

[Eli Barzilay <eli@barzilay.org>]

On Nov  6, Noel Welsh wrote:
> I disagree - I think it a very useful add-on to PLT
> Scheme and others may be interested in the discussion,
> so I'll discuss it on the list unless others object.

Well, all I can do is be flattered...  (But still, I'm keeping my
mailing list thing - I'm think Swindle is not that popular...)


> Well, it depends on what the see as Swindle's use.  If
> you want to build wholly Swindle programs then it
> isn't much use, but I see more value in Swindle's
> ability to dispatch on type (i.e. generic functions)
> than in the ability to (essentially) define a new type
> of structure.   For a start, dispatching on structures
> & PLT classes makes the system more unified -
> everything is an object.  Having generic functions as
> a core part of PLT Scheme would be really useful - one
> could overload display and write for instance, and the
> whole system could be more reflective.

Yes, and because the built-in printer etc don't have enough hooks to
change the way they behave, I implemented my printer.  As for built-in
types: the object system is just too much to hack around, I think that
I'm overriding names in more than one place -- I don't know how
feasible it would be to use Swindle generic functions with built-in
objects.  Besides, considering the plans that Matthew just mentioned,
it would make sense to wait until this phase is done.  Especially, if
the built-in object system is made into a loadable module, it would
make using Swindle much more reasonable as a substitute (the problem
is that MrEd will probably rely on it, so a future DrSwindle thing
will have to use both again).


> My intended
> use of Swindle is dispatching on structure type (in
> this case Zodiac structures).

As for built-in structures, the only thing I'd need for this is some
way to get a structure object that correspond to some struct instance.
If I get it in a form of an object that allows me to pull out its
super-structs (Java-style limited reflection) then I'm happy, but even
some unique object would allow hacking some table in Swindle that
you'll use to declare the struct object you're using (saying that a
struct X inherits from a struct Y).  Currently, all I saw was
struct->vector that has a symbol which is only the name and is not a
unique object for the structure.  The point is that Swindle must have
some class hierarchy to be able to choose methods at a generic call.
The hierarchy is for sorting methods, so it is not enough to know that
something is a struct but what struct does it inherit from.


> Unfortunately the whole Swindle packages breaks PLT
> Scheme a bit - the bug I reported and the loss of the
> buttons (Spidey, syntax highlighting) being two
> obvious problems.

I'm sure that there are many more places that get broken.  The
original motivation was not trying to make MzScheme behave like a CLOS
system, but to have enough CLOS features in a Scheme environment so we
could get rid of an old and very unstable implementation of a
Dylan-like thing.  The result is pretty useful by itself but doesn't
take things like built in classes too seriously as it was not designed
to cooperate with them.


> FWIW, I don't see a conflict between the existing PLT
> Scheme objects and CLOS ala Swindle.  The former are
> more suited to the typical 'islands of state' OO
> model, whilst the latter seem more appropriate for the
> 'transformation of inputs' functional style.

Well, I don't see either any serious problem - there is some minimal
support (or hacks to mimic such) that should be added to make the
internal object/struct system a bit less opaque.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!