> > Felix Winkelmann scripsit: > >> Wow, cool. I have to try these patches out. But note that hardcoding > >> special cases for SRFI-1 procedures is moot, since these will be > >> thrown of the core system, sooner or later (or in other words: there > >> will be only internally used variants, possibly with less error > >> checking).
Yeah, I thought about that, but once the code was written I figured I'd put it out there in any case (that's patches #1, #3 and #4). Maybe it'll be possible to add them to the srfi-1 module when the time comes (either as a hack or via some future extension to the API -- see below). > On Tue, 9 Sep 2014 08:03:29 -0400 John Cowan <co...@mercury.ccil.org> wrote: > > Eventually, there should be a way for eggs to add types to the > > scrutinizer database through a public API of some kind. There is in general, per Mario's response. However, the reason these are "special cases" is because they're trying to preserve information in a way that can't be expressed with the current type specification language. If you call `(reverse (list 1 #\2 "3"))`, it's clear that the resulting type should be `(list string char fixnum)`. However, reverse has the type `((list-of a) -> (list-of a))`, so the resulting type will be `(list-of (or fixnum char string))`. That information loss would be nice to avoid, but in order to do so a specialization needs programmatic access to the call's argument types. This is done behind the scenes for a handful of procedures in the scrutinizer, hence "special case". I don't know what user-level provisions for this would look like. (Thinking out loud now.) It'd be easiest if we allowed the user to register a handler procedure at scrutiny time, but that's its own can of worms. Otherwise, I think you'd have to eval something somewhere. (: reverse (forall (a) ((list-of a) -> (list-of a))) (((list . #(a))) ; capture part of the argument type as #(a) ((list [reverse #(a)])) ; refer to #(a) somehow in the result type #(node))) ; "node" = leave the original node unchanged Evan _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers