Subject: Re: All instances
From: Erik Naggum <>
Date: Sun, 17 Jun 2001 23:33:34 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* David Bakhash
> If what you want is to keep track of all instances of arbitrary
> classes, then you may consider defining a new metaclass for this.

* Christopher Stacy
> That is not available in ANSI Common Lisp (the MOP is not part of that
> language), although some vendors support this.

  Vote with your feet when it comes to supporting the MOP.  If the vendor
  does not support it, just walk away.  If people are told not to expect
  the most basic features above and beyond Common Lisp because it is not in
  the standard, the language will die.  In fact, I consider the fact that
  people are willing to whine about feature X not being in the standard as
  the reason that Common Lisp has seen little development.  The point with
  a standard is not to ask what is in it, it is to ask whether that which
  is in it is implemented, and whether that implementation is according to
  that standard.  If it is not specified in one standard, it may be
  specified in another standard.  MOP is a community standard that merits
  about the same level of authority within the community as ANSI does for
  the greater community.  Similar efforts have been attempted with other
  features that people need, too, but instead of writing standards-quality
  stuff to support an implementation, some people prefer to post only the
  implementation, which is completely useless to people who are used to
  having a really good standard to refer to when they need to understand
  what to _expect_ from an implementation.  (Many other languages are the
  other way around: That the implementation _is_ the specification.)

  MOP _is_ part of the Common Lisp toolchest and the common environment
  that surrounds the language proper.  This is one of the reasons it is not
  a lot of work to build a Common Lisp interpreter or compiler (as is often
  done with Scheme), but a lot of work to build a Common Lisp _system_ (as
  is ofte not done with Scheme).  If we do not appreciate the systems, but
  only the language, we have no chance at all against languages that have
  successfull merged to two concepts, such as Perl and Java.

  The only way to _make_ vendors support stuff people need is to make sure
  they are chosen if and only if they do.  In the case of the "Open Sores"
  community, their biggest problem is that they do not want what they have
  not got, in particular, the lack of willingness to implement what is in
  the commercial offerings, coupled with a lack of willingness to use what
  is only in the commercial offerings, making sure that the willingness to
  implement it is never going to materialize, either.

  Travel is a meat thing.