Re: [Chicken-hackers] [PATCH] Export specializations with generated type database information

[Peter Bex]

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