From: Andrew Cooke
Subject: MOP implementations
Date: 
Message-ID: <8987j1$7gn$1@nnrp1.deja.com>
Hi,

AMOP finally arrived in the post today.  Reading the introduction before
I go and hire a grinder to cut lumps out of our banisters I find that
the MOP itself is not part of ANSI Common Lisp (my reading of the very
end of the intro, pages 9 and 10).

But looking at the ANSI spec, it does talk about standard meta objects
(7.4.1).

So I'm a bit confused - what in the book can I expect to find in a
Common Lisp implementation, and what may be missing?

[I realise that CLISP, which I have been using, isn't completely ANSI
anyway, but the next Debian release will come out "real soon now" and
when I install that I can easily move to CMUCL if it's any more
complete....]

Thanks,
Andrew
http://www.andrewcooke.free-online.co.uk/index.html

PS There was a message here asking about CLOS and predicate dispatching,
but I never saw a reply.  Has anyone looked at this?


Sent via Deja.com http://www.deja.com/
Before you buy.

From: Tim Bradshaw
Subject: Re: MOP implementations
Date: 
Message-ID: <ey34sawrukf.fsf@tfeb.org>
* Andrew Cooke wrote:
> AMOP finally arrived in the post today.  Reading the introduction
> before I go and hire a grinder to cut lumps out of our banisters I
> find that the MOP itself is not part of ANSI Common Lisp (my reading
> of the very end of the intro, pages 9 and 10).

> But looking at the ANSI spec, it does talk about standard meta objects
> (7.4.1).

> So I'm a bit confused - what in the book can I expect to find in a
> Common Lisp implementation, and what may be missing?

It varies.  An ANSI-conforming lisp will have what is described in the
standard, which is very little.  Implementations vary in how much they
conform to AMOP or whether they provide a MOP at all I guess.

My personal opinion is that AMOP in its entirety is not actually
something should be conformed-to since it has a number of nasty areas
in it.

I am involved, with someone else, in a survey of implementations which
will, we hope, produce some documents describing what they do in the
way of MOPs, which documents will be relatively available, we hope.

--tim
From: Robert Monfera
Subject: Re: MOP implementations
Date: 
Message-ID: <38B7D38D.D1149AF5@fisec.com>
Besides the Lispm, ACL and LispWorks support MOP in its entirety with
very minor differences.

CMUCL, Corman Lisp and CLISP also support MOP, although with important
limitations (in fact, they support CLOS in a limited way).  There has
been a discussion about the reason for the limited support, look it up.

I don't know for sure about MCL, SBCL, Eclipse or Lucid/Liquid, but I
think they all support MOP one way or another.

Maybe MOP is ripe for standardization: there are existing successful
implementations for all platforms, and there are no mainstream Lisp
implementations whose CLOS is not MOP-based.  The boundaries between
CLOS and MOP are a little blurred.

Predicate dispatching is interesting, sometimes I thought I'd need it,
but it's not terrible to work around its absence with dispatching on
symbols or CHANGE-CLASS if a program isn't too reliant on it. Predicate
dispatching may easily lend itself to pattern matching based dispatch,
and ML has some interesting PM constructs.  Check out Screamer, maybe it
can do something similar.

Robert

Andrew Cooke wrote:

> So I'm a bit confused - what in the book can I expect to find in a
> Common Lisp implementation, and what may be missing?
From: Pierre R. Mai
Subject: Re: MOP implementations
Date: 
Message-ID: <8766vc0xgn.fsf@orion.dent.isdn.cs.tu-berlin.de>
Robert Monfera <·······@fisec.com> writes:

> Besides the Lispm, ACL and LispWorks support MOP in its entirety with
> very minor differences.

Well, the minor differences can be annoying.  And they're not always
quite so minor (see e.g. the differences something like PLOB needs to
take into acount when dealing with ACL and LispWorks and the MOP).

> CMUCL, Corman Lisp and CLISP also support MOP, although with important
> limitations (in fact, they support CLOS in a limited way).  There has

While CLISP's support for CLOS (and the MOP) is clearly limited to
some degree (I know nothing about Corman Lisp), I'd like to know
what the supposed limitations in CMUCL's support (which is by and
large PCL) might be?

I have until now found that CMUCL's MOP differs from ACL's or LW's
about as much as those differ between them, but YMMV.

> I don't know for sure about MCL, SBCL, Eclipse or Lucid/Liquid, but I
> think they all support MOP one way or another.

I would be very astounded if SBCL differs in this regard with CMUCL.
IIRC then both MCL and Eclipse support the MOP.  Not sure about
Lucid/Liquid though.

> Maybe MOP is ripe for standardization: there are existing successful
> implementations for all platforms, and there are no mainstream Lisp
> implementations whose CLOS is not MOP-based.  The boundaries between
> CLOS and MOP are a little blurred.

Yes, I agree that it would be very nice to standardize at least some
parts of a MOP, and I'm under the impression that the ANSI CL working
group is currently undertaking efforts to evaluate the sitatuation and 
decide on a useful approach/course of action.

> Predicate dispatching is interesting, sometimes I thought I'd need it,
> but it's not terrible to work around its absence with dispatching on
> symbols or CHANGE-CLASS if a program isn't too reliant on it. Predicate
> dispatching may easily lend itself to pattern matching based dispatch,
> and ML has some interesting PM constructs.  Check out Screamer, maybe it
> can do something similar.

There are some things that crop up frequently, and which can be solved 
with PD more elegantly than with the corresponding CL idioms, IMHO.
The whole -using-class (and similar things, -using-server, -using-*)
stuff for example.

Given the article that Fernando mentioned, it would be very
interesting to see how well something like this could be implemented
in CL and maybe integrated into the current framework.  If the CL
community could come up with an experimental (portable and tunable)
implementation, the experience gained could lead to some
standardization efforts in the _next_ round of ANSI CL renewal.

There exists the slight possibility that I could further efforts to
implement something like that in the 1-2 year time frame, but there
are currently too many unknowns to say more on this.  But this is
definitely on my priority list for language internal work that should
be done.  Let's wait and see...

Regs, Pierre.

-- 
Pierre Mai <····@acm.org>         PGP and GPG keys at your nearest Keyserver
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Pekka P. Pirinen
Subject: Re: MOP implementations
Date: 
Message-ID: <ixu2itz96h.fsf@harlequin.co.uk>
····@acm.org (Pierre R. Mai) writes:
> IIRC then both MCL and Eclipse support the MOP.  Not sure about
> Lucid/Liquid though.

Sure it does.  Look at the externals of the CLOS package.  There's
some documentation in the wizard*.doc file.
-- 
Pekka P. Pirinen, Harlequin/Xanalys
          "Once a new technology rolls over you, if you're not part of
the steamroller, you're part of the road."
                    Stewart Brand 
From: Robert Monfera
Subject: Re: MOP implementations
Date: 
Message-ID: <38BBECFF.1366452E@fisec.com>
"Pierre R. Mai" wrote:

> While CLISP's support for CLOS (and the MOP) is clearly limited to
> some degree (I know nothing about Corman Lisp), I'd like to know
> what the supposed limitations in CMUCL's support (which is by and
> large PCL) might be?
>
> I have until now found that CMUCL's MOP differs from ACL's or LW's
> about as much as those differ between them, but YMMV.

I had a false recollection of earlier comments from the expert of the
area (a lad called Pierre Mai :-).  I concluded that PCL had some
significant limitations, maybe it was something to do with the fact that
it's a user-level implementation, and that one has to juggle between
CLOS and MOP, but this isn't a functional limitation on its own.  I've
ran a couple of quick tests, but haven't found obvious omissions.  I
still suspect there is less difference between LW and ACL at the API
level, maybe you know about more areas where they differ.

Is anyone using PCL on Symbolics, CLISP or Corman Lisp?  Is it compliant
with ANSI CL as far as CLOS goes?  Is there a write-up that explains the
differences between the AMOP and the PCL MOP (other than the source)?

Pierre, you've described a few annoyances with using PCL on CMUCL, and
Howard Stearns had a proposal (with some sample code) for a MOP
compatibility layer.  What were your thoughts on that?

Robert
From: His Holiness the Reverend Doktor Xenophon Fenderson, the Carbon(d)ated
Subject: Re: MOP implementations
Date: 
Message-ID: <w4oem9mswaw.fsf@nemesis.irtnog.org>
>>>>> "RM" == Robert Monfera <·······@fisec.com> writes:

    RM> Is anyone using PCL on Symbolics, CLISP or Corman Lisp?

I've built a version of Clisp that includes PCL.  It's not pretty,
though.  I can't use :METHOD arguments to DEFGENERIC, DESCRIBE breaks,
and so forth.

-- 
Don't trust these UNIX people.  They are all demons.  They kill their
parents and fork children.  I don't know how they could do this with
their balls cut off but they manage.                        -- anonymous
From: Tim Bradshaw
Subject: Re: MOP implementations
Date: 
Message-ID: <ey31z60rshi.fsf@tfeb.org>
* Robert Monfera wrote:
> Besides the Lispm, ACL and LispWorks support MOP in its entirety with
> very minor differences.

The lispms (at least symbolics) did not support the whole MOP.

--tim
From: Andrew Cooke
Subject: Re: MOP implementations
Date: 
Message-ID: <898qp9$j3k$1@nnrp1.deja.com>
Thanks to everyone for the replies.

I had a search on Deja for MOP, and then MOP implemetations and I found
hundreds of posts, including one from you (Robert M) saying that if you
want a decent CLOS MOP you have to get a commercial implementation (and
another from Bruno H explaining that CLISP takes a pragmatic approach
since development effort is limited), but I didn't find a real
discussion of how different implementations compared.  Of course, I
didn't read all of the posts that the search turned up, but I did try
most threads - if you can remember any other words from the discussion
title etc I'd appreciate it...

I did find a mention of something called Common-MOP that I am now going
to have a look for.

Thanks,
Andrew

In article <·················@fisec.com>,
  Robert Monfera <·······@fisec.com> wrote:
[...]
> limitations (in fact, they support CLOS in a limited way).  There has
> been a discussion about the reason for the limited support, look it
up.
[...]


Sent via Deja.com http://www.deja.com/
Before you buy.
From: Christopher R. Barry
Subject: Re: MOP implementations
Date: 
Message-ID: <874sawndp3.fsf@2xtreme.net>
Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:

> I had a search on Deja for MOP, and then MOP implemetations and I found
> hundreds of posts, 

[...]

> but I didn't find a real discussion of how different implementations
> compared.

Allegro CL is quite possibly the most rigorously conformant to the MOP
as documented in AMOP. I haven't used the Lispworks MOP, but I've read
several times here that at least one of their MOP functions takes
something as an &rest parameter when it should be something else. (Or
something like that.)

Christopher
From: Robert Monfera
Subject: Re: MOP implementations
Date: 
Message-ID: <38B89EBF.561BC950@fisec.com>
"Christopher R. Barry" wrote:

> Allegro CL is quite possibly the most rigorously conformant to the
> MOP as documented in AMOP. I haven't used the Lispworks MOP, but I've
> read several times here that at least one of their MOP functions
> takes something as an &rest parameter when it should be something
> else. (Or something like that.)

Yes, direct-slot-definition-class and effective-slot-definition-class.
It is quite possible that ACL's MOP is more conformant with AMOP,
although there were only two differences between LW and ACL I bumped
into and I haven't exhaustively tested ACL to say that it conforms to
AMOP at every point.  In fact, Duane once pointed out a quite subtle bug
in Closette (a simplified example implementation by its authors), which
is the type of comment that reveals both insight and care.

Small differences between signatures of functions aren't nearly as big a
problem when coding as significant CLOS/MOP limitations compared to ANSI
CL and the AMOP.

Robert
From: Robert Monfera
Subject: Re: MOP implementations
Date: 
Message-ID: <38B8A3B8.918FC1E9@fisec.com>
Andrew Cooke wrote:

> I had a search on Deja for MOP, and then MOP implemetations and I
> found hundreds of posts, including one from you (Robert M) saying
> that if you want a decent CLOS MOP you have to get a commercial
> implementation

For fairness, I need to clarify that at the time I had two things on my
mind: completeness and robustness.  Without any solid research, I
concluded that the lack of support for parts of CLOS and MOP
functionality in CLISP is an indication that CLOS and MOP didn't get
much attention and use, thus it may lack robustness.  From the answers I
understood that the missing features are conscious design decisions with
worthy considerations behind them (which does not make up for the lack
of features, but one is allowed to workaround it).

> (and
> another from Bruno H explaining that CLISP takes a pragmatic approach
> since development effort is limited), but I didn't find a real
> discussion of how different implementations compared.

The CLISP documentation explains the differences compared to ANSI CL
very well, including CLOS.  I haven't found a discussion of MOP for
CLISP, but there seems to be an option to use PCL.

Robert