[Asdf-devel] Program with metaclass on MKCL.

Thu Dec 4 16:37:51 UTC 2014

D. Martinez wrote:
> I understand your hypothesis and I guess it makes sense.
> 
> I have done the testing as you suggest.
> 1. load-source-op is good
> 2. load-op fails on the first time. But it produces fasl.
> 3. load-op succeeds, on the second time.
> In a larger program, the load-op seems to fail as many times as there are custom metaclasses so I have to repeat the operation that many times (certainly why I haven't had the idea to do that in the first place).
> 
> This is hardly a satisfactory solution but it is way better than nothing. For lack of a good solution it will do for now.
> So, should I conclude that MKCL is at fault and redirect my bug reporting there ?

One thing I notice is that you are defining like this:

(defclass A (standard-object)
  ()
  (:metaclass A-class))

I don't believe that this is in general correct.

Looking at the spec:

Each superclass-name argument specifies a direct superclass of the new
class. If the superclass list is empty, then the superclass defaults
depending on the metaclass, with standard-object being the default for
standard-class.

As I read this, you should drop the specification of STANDARD-OBJECT,
because the implementation is licensed to choose a more appropriate
default superclass. If it does, probably you want that more appropriate
superclass.

I don't mean to be troublesome, but if you are new to serious CL
programming maybe

1. You should try using a more mature CL implementation.
2. You should avoid the MOP. Unless you are doing something that, with
all due respect, someone who's new to serious CL programming shouldn't
be doing, you don't need the MOP.  CLOS is already so powerful, that
unless you are doing something that fundamentally changes the object
system, you don't need the MOP. And see my earlier point: if you are new
to serious CL programming, you shouldn't be fundamentally changing the
object system.

Cheers,
r

> 
> ----------------------------------------
>> To: asdf-devel at common-lisp.net
>> From: pjb at informatimago.com
>> Date: Thu, 4 Dec 2014 13:45:32 +0100
>> Subject: Re: [Asdf-devel] Program with metaclass on MKCL.
>>
>> "D. Martinez" <denis.martinez at live.com> writes:
>>
>>> Thank you Pascal for pointing this out, but I don't think this relates to my problem.
>>> I have looked at MKCL source and it was evident that it does not
>>> implement superclass validation at this time.
>>> Its MOP is not supported either in Closer-MOP so I assume it is somewhat young.
>>> Quoting for clos/standard.lsp:
>>>   ;; FIXME!!! Here should come the invocation of VALIDATE-SUPERCLASS!
>>> As I have played with various CLs I noted that some required
>>> VALIDATE-SUPERCLASS and some did not. I have not really checked what
>>> is the standard's stance on this.
>>>
>>> I can trace the error rising from defclass to standard.lsp in mkcl.
>>> It is the cond clause from ensure-class-using-class. I display some more information to post here.
>>>           ((not (eq (class-of class) metaclass))
>>>            (format *error-output* "class: ~A~%" class)
>>>            (format *error-output* "(class-of class): ~A~%" (class-of class))
>>>            (format *error-output* "metaclass: ~A~%" metaclass)
>>>            (error "When redefining a class, the metaclass can not change.")))
>>>
>>> Which provides this output
>>>
>>> class: &<The A-CLASS A 140012460512096>
>>> (class-of class): &<The STANDARD-CLASS A-CLASS 140012464325568>
>>> metaclass: &<The STANDARD-CLASS A-CLASS 140012460537344>
>>> Error during command line arguments processing:
>>> When redefining a class, the metaclass can not change..
>>>
>>> This does show that A-CLASS is intanciated twice, and it is why the EQ test fails.
>>> The mystery is why there happen two instanciations when I use ASDF.
>> An explaination could be that MKCL uses the same environment for
>> compilation and loading, and that ASDF does both COMPILE-FILE and LOAD
>> (when the file is not already compiled).
>>
>>
>> A compiler doesn't have to define the class completely when compiling; it
>> only has to do the following:
>>
>> If a defclass form appears as a top level form, the compiler must
>> make the class name be recognized as a valid type name in subsequent
>> declarations (as for deftype) and be recognized as a valid class
>> name for defmethod parameter specializers and for use as the
>> :metaclass option of a subsequent defclass. The compiler must make
>> the class definition available to be returned by find-class when its
>> environment argument is a value received as the environment
>> parameter of a macro.
>>
>>
>> You could test and compare:
>>
>> 1.1- remove the fasl files.
>> 1.2- from a fresh image, (asdf:oos 'asdf:load-source-op :hello)
>> this only LOAD the source file (situation :execute)
>>
>> 2.1- remove the fasl files (if any)
>> 2.2- from a fresh image, (asdf:oos 'asdf:load-op :hello)
>> this uses COMPILE-FILE and LOAD (situations :compile-toplevel and :load-toplevel)
>>
>> 3.1- keep the fasl files from the previous compilation.
>> 3.2- from a fresh image, (asdf:oos 'asdf:load-op :hello)
>> this should only LOAD the fasl file (situation :load-toplevel)
>>
>>
>>
>> --
>> __Pascal Bourguignon__ http://www.informatimago.com/
>> “The factory of the future will have only two employees, a man and a
>> dog. The man will be there to feed the dog. The dog will be there to
>> keep the man from touching the equipment.” -- Carl Bass CEO Autodesk
>>
>>
>> _______________________________________________
>> Asdf-devel mailing list
>> Asdf-devel at common-lisp.net
>> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
>  		 	   		  
> _______________________________________________
> Asdf-devel mailing list
> Asdf-devel at common-lisp.net
> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel