Providing compiler notes about static-dispatch HOT 8 CLOSED

Currently the optimize declarations are checked for whether type checks should be inserted for the parameters of the inlined CALL-NEXT-METHOD definitions. If the level for (optimize safety) is greater than or equal to the level for (optimize speed) type checks are inserted, otherwise no types checks are inserted and it is the programmer's responsibility that the arguments passed to CALL-NEXT-METHOD are compatible with the argument types of the next most specific method.
I'll add an explanation of this in the README.
P.S. I'm not entirely sure implicit inlining, with an optimize speed declaration, is such a good idea, since inlining generic functions changes their semantics. They are no longer dynamically dispatched which could result in a different method being called if the actual types of the arguments, that are passed to the generic function, are of a subtype of their declared types. Furthermore methods can no longer be added or removed at run time, and methods declared in a later compilation unit will not be visible when inlining. It's best that generic function inlining is reserved for when you are sure of what you're doing.

from static-dispatch.

Okay, the note about implicit inlining does make sense. And this also further clarifies the ways in which specialization-store differs from generic-functions.

My next question gets a bit off-topic though, may be some other place to discuss this: are you aware of anything in CLHS that prevents the implementation from storing the method lambda forms? I'm aware of inlined-generic-function, but it gets terribly slow without inline. The need arises, because at the time of compiling generic-cl:add, the exact types of the arguments are not known; and that adds a significant (factor of 3 or more on SBCL 2.1.1) overhead.

from static-dispatch.

There are two aspects of the semantics of generic functions which prevent them from being inlined (if I understood your question correctly). The method lambdas can be stored but calls to the generic function cannot be inlined:

1. They are dynamically dispatched which makes them closer to C++ virtual functions than overloaded functions.
   As a result they are dispatched on the run-time types of the arguments. Whilst the type of an argument can be inferred at compile-time it's true type often cannot be determined, for example the compiler may infer that an argument is a number, whilst it's true type is integer. If you have two methods one specialized on number and another specialized on integer, with static dispatch the number method will be called, however the method which is supposed to be called, according to the semantics of generic functions in the CLHS, is the integer method.
2. Generic function methods can be added and removed at runtime, hence the compiler does not know, at the site of a generic function call, the full list of methods nor does it know whether the current methods of the generic function wont be removed at run-time.

As a result of these two aspects generic functions cannot be inlined, while adhering to the specification, because inlining changes their behaviour. static-dispatch explicitly changes the semantics of generic functions when they are declared inline, however it determines the types of the arguments at the call expression by itself and currently it can only determine the types in very basic expressions (you can always surround the arguments in a THE form if it isn't able to). I'm planning on significantly expanding it's capabilities in the future.
I'm not sure if SBCL has a feature for sealing generic functions which would allow them to be inlined, which would be more robust than static-dispatch. I think the commercial Lisps, LispWorks and Allegro have a feature like this.

You can continue this conversation on email.

from static-dispatch.

I've updated the README to include an explanation of the effects of the various optimize declarations, and also included a section on the pitfalls of using statically dispatched generic functions. If it's detailed enough I'll close this issue.

from static-dispatch.

Yes, this does look good. Ideally I'd still want SBCL-like compiler notes .

And thanks for the detailed elaboration!

from static-dispatch.

I've added compiler notes/warnings as a future debugging addition. I can keep the issue open until it's implemented.

from static-dispatch.

Could you confirm that you have just been busy (and so could reply later), and that my email (sent from [email protected]) has not reached your spam? (EDIT: Passers-by can ignore; this has been resolved.)

from static-dispatch.

Added in v0.8
Documentation: https://github.com/alex-gutev/static-dispatch#static-dispatch-failure-warnings

from static-dispatch.