Re: disassemble

On Thu, 18 Aug 2005, bryan o'connor wrote:

> the spec says that disassemble should throw a type-error
> if the arg is not an "extended function designator" or a
> lambda expression.  this seems to exclude methods.
>
> if the arg is a method, openmcl's disassemble will replace
> it with (ccl::%method-function arg).
>
> it seems wrong to commit something that removes functionality
> or requires the user to know and use ccl::%method-function.
>
> i'm ok with skipping this one (disassemble.error.3) or
> conditionalizing it behind some *pedantic-ansi* flag.
>
> what do you think?


It's difficult to imagine a real program depending on an error
being signaled in this case, though the use of CCL::%METHOD-FUNCTION
should probably be replaced with the MOP's METHOD-FUNCTION.  (The
fact that there wasn't a public way of getting ahold of a method
function was probably the rationale for extending DISASSEMBLE in
the first place.)

Having a *PEDANTIC-ANSI* flag might be useful for running the test
suite, to keep the cases where we're intentionally deviating (for
MOP compatibility or for usability concerns) from being reported
with the same level of seriousness as cases where VECTOR-PUSH-EXTEND
starts chewing on memory.

It's maybe slightly more believable that some users would prefer
that misplaced close-parens signal errors instead of warnings, so
we might want to say:

   (if (or *pedantic-ansi* *whatever-the-other-variable-is*)
     (error "dangling close-paren ...")
     (warn "dangling close-paren ..."))

As far as DISASSEMBLE goes: disassembling a generic function shows a
little bit glue that's used in the dispatching mechanism.  I'd almost
prefer that it error in that case, or at least remind me that the code
I'm looking at has almost nothing to do with what any of the method
functions do, and I probably want to look at one or more of them.  I
should know better, but it's the sort of thing that can be confusing
at 3:00 AM.


>
>    ...bryan
>
> _______________________________________________
> Bug-openmcl mailing list
> [email protected]
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>