Just curious, would bringing the MOP into the standard be a useful step?
Was that considered when the current standard was set? is it actually a
bad idea for some reason or another?
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Just curious, would bringing the MOP into the standard be a useful step?
No.
> Was that considered when the current standard was set?
Yes, but that's not relevant to the question you're asking, IMO.
In other words, at the time the current standard was set, the MOP was
considered premature and not appropriate for standardization.
Since then Gregor has published AMOP, which one might argue is a layered
standard. Not a consensus standard per se, but kind of, since it was
at least mostly a product of a subcommittee, if not of a committee of the
whole. But, like CLTL (a committee work) and CLTL2 (an individual work),
a work can take on some de facto standard nature not by how it is designed
but by observing community use is gravitating toward it.
So one might argue it *is* now a de facto standard of sorts.
> is it actually a bad idea for some reason or another?
I think so.
Let me help you with separating the issues...
Standards do two things:
* They write things down and label them in a way such that when two people
talk about a definition, they are talking about the self-same piece of
text. When I say ANSI CL and you say ANSI CL, we don't risk that confusion
that results when I say Lisp and you say Lisp, or even when you say Common
Lisp and I say Common Lisp. We could argue all day about whether GNU CL
is a Common Lisp, but there is much less question of whether it is an
ANSI CL.
* They invoke a community consensus process. This allows a bunch of cooks
to all pace back and forth spicing the brew for a while, and then finally
either results in a recipe that they all grudgingly agree on or else does
not result in any recipe.
AMOP is already written down.
I reduce your question to:
is it actually a bad idea to unwrite it, let a bunch of people fuss
over it, and hope that it recongeals into something at least as usable
as what we have now?
Rather than answer, I'll leave it as a thought exercise.
Kent M Pitman <······@world.std.com> writes:
> Rather than answer, I'll leave it as a thought exercise.
Instead of exercising my thought I cogitated upon the following:
"What the ANSI standard needs is a MOPMOP, that way anyone can change
the object system however they want with the MOP that they want by
changing the MOP into something they like with the MOPMOP."
Actually, the outcome of the standardization process as applied to the
MOP would probably result in something similar, and similarly hideous.
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
i came at it from the other direction. Unlike MOPMOP (each vendor's
design/implementation of their MOP), the MOP has been made available to
CL developers to have fun with. By some vendors. With minor differences.
Standards are about making the stuff presented to the developer
consistent/portable.
By the way, by 'should' I meant, "Gee, anyone think this would be
worthwhile?", not anything judgmental like it inadvertently sounds.
I use the MOP so it matters to me. I cannot port to MCL and I have to
work to port it outside ACL. If CL standardized on a MOP those of us who
do metaclasses would have that much less work to do moving between
implmentations.
kenny
clinisys
The answer
"James A. Crippen" wrote:
>
> Kent M Pitman <······@world.std.com> writes:
>
> > Rather than answer, I'll leave it as a thought exercise.
>
> Instead of exercising my thought I cogitated upon the following:
>
> "What the ANSI standard needs is a MOPMOP, that way anyone can change
> the object system however they want with the MOP that they want by
> changing the MOP into something they like with the MOPMOP."
>
> Actually, the outcome of the standardization process as applied to the
> MOP would probably result in something similar, and similarly hideous.
>
> 'james
>
> --
> James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
> Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
> Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
> Y(F) = F(Y(F)) \_,-_/ Milky Way.
Sorry to be responding to this thread so belatedly.
Kenny Tilton wrote:
> By the way, by 'should' I meant, "Gee, anyone think this would be
> worthwhile?", not anything judgmental like it inadvertently sounds.
>
> I use the MOP so it matters to me. I cannot port to MCL and I have to
> work to port it outside ACL. If CL standardized on a MOP those of us who
> do metaclasses would have that much less work to do moving between
> implmentations.
I agree with most of kmp's response, but I want to approach from a
different angle. Kenny's query, like so many similar musings on the
language, implies that the mythological CL community could decide to
standardize the MOP. Indeed it could, but the only way it could do so
would be for some number of _individuals_ to do the necessary work.
At the 1999 NCITS/J13 meeting standardizing the MOP was one of the
areas some members considered worthwhile to explore, but the effort
never nucleated. But if some number of individuals felt that the
effort would be worthwhile, the project cuold be commenced. But it
won't happen as a result of individuals expressing the opinion that
the community should undertake the work. It will happen only as a
result of some individuals decidinging to undertake the work. You
might say that it would be good if the community would standardize
the MOP for you, and I might say that it would be good if you were
to come over and mow my lawn, but neither of us is likely to get
what we want that way.
Now, what would be the procedure for creating a standard for the MOP?
Those of us who were involved in the original ANSI CL standardization
effort experienced how slow the standardization process can be. All
the checks and balances necessary to keep the process fair do slow
things down. On the other hand, NCITS (the new name of X3) has
recognized that the old, bureaucratic processes can't survive in the
Internet age, and has streamlined procedures greatly.
In particular, there is a new process adopted a few years ago called
"fast track." If there is an existing written specification that has
been taken up in practice by some segment of a community, and if the
community does not object that this specification deserves
standardization, that specification can be converted to a standard in
a process that takes only a few months from start to finish.
So if some number of CL community members were to join NCITS/J13 and
propose putting the existing MOP specification into fast track (and
assuming that intellectual property rights are available to J13, which
I believe is the case) it could be done within six months.
This would have the effect of establishing a new, optional 2002 MOP
Specification, dependent upon the 1994 ANS for CL, but not invalidating
the 1994 ANS nor changing what it means to conform to the ANS.
What would be the result?
Most obviously, there would be a written, authoritative, official
source for the MOP. But we already pretty much have that, given that
chapters 5 and 6 of The AMOP are published both in the original book
and in vendor documentation and elsewhere on the web.
Further, adherence to a standard is always voluntary, never compulsory
(at least, not in the ISO/ANSI/NCITS universe). So implementors could
just keep their current implementations and either ignore the new
addendum, or else state that they implement the new standard with
the following exceptions. Again, this is pretty much the situation
we already have without an actual MOP standard.
Would implementors be moved to improve their conformance by the mere
officialization of the MOP specification? Well, there might be slightly
more market pressure for conformance, but I doubt implementors who have
successful mplementations that are wildly nonconformant would be moved
to expend necessary effort to redo their MOP implementation.
All of the implenmentations with serious pretensions at conforming to
the MOP have bugs of sections of the MOP that the don't implement, or
implement incorrectly. Most of these are in lpaces that serious
programmers never use, or shouldn't use, because they fall far outside
the domain where reasonable optimized performance is possible.
Remember that CL is intended to be a practical, industrial language,
not a research platform for adademic object-system experimentation. In
general those places where speed and/or customizability are really
needed have attended to, but not so for other, obscure features.
To put the question more bluntly: Would mere standardization of the MOP
cause any implementor to expend large effort on the MOP implementation?
I think not, unless coupled with market pressure.
The other problem with fast track is that there are a few glitches in
the current MOP specification. Gregor realized some of them while the
AMOP was in press, and indeed, this possibility was why he had earlier
recommended that X3J13 _not_ standardize the MOP draft in 1989.
(I have some saved ancient saved mail on the details, but would prefer
not to spiral down into it right now.) In some ways, it would be a
shame not to fix some of these before standardizing the MOP, rather than
carving known mistakes into stone. But this would extend the time
necessary to pass the standard, since the corrected MOP does not yet
exist and therefore cannot be fast tracked. (Not, at least, until some
implementor or group of implementors revise their MOP, write down its
specification, and submit _that_ for fast track.)
So, Kenny, I'm sympathetic to your problem, but as children might taunt on
a playground: Are you or anyone else willing to put your MOP where your
mouth is? :-)
"Steven M. Haflich" wrote:
>
> Sorry to be responding to this thread so belatedly.
>
> Kenny Tilton wrote:
>
> > By the way, by 'should' I meant, "Gee, anyone think this would be
> > worthwhile?", not anything judgmental like it inadvertently sounds.
> >
> > I use the MOP so it matters to me. I cannot port to MCL and I have to
> > work to port it outside ACL. If CL standardized on a MOP those of us who
> > do metaclasses would have that much less work to do moving between
> > implmentations.
>
> So, Kenny, I'm sympathetic to your problem, but as children might taunt on
> a playground: Are you or anyone else willing to put your MOP where your
> mouth is? :-)
First, that was one of the most interesting articles I have ever read on
UseNet. I loved the way it developed, first laying out the way MOP
standardization might happen, then ticking off the problem of
conformance that would follow. I think I learned something new in every
sentence.
But isn't the taunt a non sequitor? Why should I bother if conformance
is highly improbable?
The conclusion I take is that the only scenario for re-opening a
standard, to take the MOP as an example, would be if in practice folks
turned out to be forever using the MOP to get their "practical,
industrial" work done. ie, if the standards group (understandably)
missed that something like that was going to be a rich area of practical
development, which would also create market pressure for conformance
with, as well as provoke, any new standards work.
Thx again for the standardization insights.
kenny
clinisys
Kenny Tilton wrote:
> But isn't the taunt a non sequitor? Why should I bother if conformance
> is highly improbable?
Standardization depends on market pressure, and market pressure develops
from customers or user communities for non-commercial implementations.
Now a standard might focus market pressure and increase its leverage,
but you need to judge whether that would be sufficient to move each
particular implementor. Implementors have different amounts of resources
to apply to this, and different implementors will have very different
distances to cover in order to achieve conformance. So having a MOP
standard would probably move things in the right direction, but it
probably would not lead to conformance from implementors without the
necessary free resources to expend.
> The conclusion I take is that the only scenario for re-opening a
> standard, to take the MOP as an example, would be if in practice folks
> turned out to be forever using the MOP to get their "practical,
> industrial" work done. ie, if the standards group (understandably)
> missed that something like that was going to be a rich area of practical
> development, which would also create market pressure for conformance
> with, as well as provoke, any new standards work.
I remember the 1989 X3J13 meeting at which CLOS was adopted and the MOP
rejected. This was the _recommendation_ of the subcommittee that drafted
both specifications (which were chapters of a single document). The
subcommittee felt that it would have been _premature_ to standardize on
the MOP since there was not yet sufficient practical experience
implementing or using it. But I doubt many would have felt that the MOP
was not important, or worthy of standardization.
I don't want to let this drop without clarifying an important point about
how standardization would proceed.
While it would be possible to "reopen the standard" this would be a huge
and possibly disruptive undertaking, and it is not necessary. Any new
standard component could be drafted as an Amendment, leaving the 1994 ANS
intact and unmodified. This is particularly apt for layered components
that do not require significant changes to the original standard. An
implementation could indicate that it conforms to the 1994 ANS X3.226 and
also conforms to the 2002-456 MOP Amendment or the 2002 Defsystem
Extension Amendment 2002-789. It isn't clear to me whether either of
these would require _any_ small changes to the original, but if so, such
things could be done by referring to alterations to the original without
actually changing the original. I.e., the Amendment would contain text
specifying things like "In the dictionary entry for CONS add an optional
DOCUMENTATION argument to the lambda list..." and a conformance statement
would be something like "This implemenation conforms to the 2002-456 MOP
Amendment and to the 1994 ANS X3.226 as modified by 2002-456."
An implementation that didn't want to adopt the new stuff would not be
harmed by the new stuff, except possibly by market pressure. IMO this
is as it should be.