Common or rare Lisp ?

[Luca Pisati]

Reginald S. Perry wrote:
> 
> >"Luca" == Luca Pisati <pisati@nichimen.com> writes:
> 
> > But do not think that ANSI-CL is perferction. It is not.  ANSI
> > failed to standardize vital parts of the language as, for instance,
> > environments.  Please check in the ANSI specs about it, and you
> > would see that environments DO exist in ANSI-CL (and it couldn't be
> > otherwise, or you couldn't even compile and load a lisp file), but
> > they are absolutely undefined.
> 
> [some interesting discussion snipped]
> 
> > EQL specializers, which somehow break part of the perfection of the
> > CLOS/MOP structure, and force language implementors to do triple
> > back flips in order to optimize code.
> 
> > flat package system, which creates, yes, namespaces, but only defer
> > name conflict to package conflict.
> 
> > And what about being able to access compiler information at compile
> > time ? My compiler does type inference, so that it can optimize my
> > code, but I cannot access that information so that I can optimize
> > the way I want (again, missing environments ...).
> 
> > And what about MOP ?
> 
> Thats a good question. What about the MOP. I have heard some arguments
> to eliminate it, but I think that the problem is underexploitation of
> the MOP. It seems to me that we could define another metaclass that
> gives us static(ish) type semantics. What this would do is allow us to
> have fast method access for the low-level stuff or for people who dont
> want or need the full-blown MOP but allow everyone else to have the
> full power of CLOS if they need it.

Well, MOP is CLOS-MOP really.  You are asking to have compile-time
dispatching (very useful for low-level stuff), with its own MOP.

I would be satisfied enough to have access to compiler type
inference and to compiler environments ...

Watch out also that MOP forces implementors to follow certain
rules, leaving less latitude for optimizations.

> But in order to do this we will have to integrate the MOP in at every
> level. Maybe even to the level of being able to alter certain compiler
> semantics. If we can do this and document it clearly, I believe that
> it would allow everyone from pure speed freaks to complete flexibility
> freaks to be able to do what they want with the system.
> 
> But you cannot do it halfway. You have to "go for it".

--
Luca Pisati		       Voice:	 (310) 577-0518
Nichimen Graphics	       Fax:	 (310) 577-0577
12555 W. Jefferson #285        EMail:    mailto:pisati@nichimen.com
Los Angeles, CA 90066          Web:      http://www.nichimen.com