On Sun, Oct 19, 2014 at 11:05:24PM -0700, Evan Hanson wrote: > On 2014-10-19 13:27, Peter Bex wrote: > > I have one concern > > That's addressed, as discussed on IRC.
Yeah, obviously I wasn't paying attention. Sorry about that. > Also as discussed, here are versions that suffix specializations "#s#0", > "#s#1", ... to avoid collisions in the following (admittedly rare) case: > > (define (foo x) 0) ; foo > (define-specialization (foo (x fixnum)) x) ; foo#0 > (module foo (|0|) (import scheme) (define |0| 1)) ; foo#0 How about changing this to use the full argument list, instead? (define-specialization (foo (x fixnum)) x) ; |foo#s:(fixnum)| (define-specialization (bar (x fixnum) (y flonum)) (+ x y)) ; |foo#s:(fixnum flonum)| That should make it more robust against changes: whenever a specialization entry is removed or inserted anywhere but at the end, the current patch would cause difficult to diagnose errors. If you include what is being specialised on (the argument list), errors becomes more self-documenting: inserting a new specialization in the middle won't cause already-compiled code to break. If a specialization is removed, it will give an error which is at least debuggable. Perhaps (if available), we should even include the result type(s), like |foo#s:(fixnum flonum) -> (or flonum fixnum)|. That way, if a specialization's rewrite changes semantically, it will cause a runtime error in the user's code due a missing "hook" procedure. This is a good thing, because the specializations in the calling code that resulted from application of this specialization are no longer valid, either: You'd have to recompile. Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers