Hi Jason,

(Just so I got you right, by generality of built-in procedures you do actually mean generics, as in, different actual routines are invoked based on type?)

I believe something like a generics - multiple dispatch system would be really handy.

Through algorithms for analysis through abstract interpretation like 2-CFA, you can probably pin down quite a lot of data types - maybe even 95% for typical-ish code - and thus what exact procedures to use at expansion time and thus also get a really good performance.

Prof. Matt Might at Utah works with abstract interpretation, perhaps he published an implementation of a Scheme-based abstract interpreter of Scheme.

I suppose implementing this atop standard Scheme makes good sense.

2013/1/7 Jason Felice <jason.m.felice@gmail.com>
Thanks for the feedback.  I appreciate it.  I think I'd like to narrow my focus to the primary thing, which was the lack of generality of the built-in procedures, and generics.

Making these efficient to compile (especially with a module system) seems hard, but rewarding.  I'm thinking about how to do this more.  Personally, I don't think efficiency in terms of constant factors should often win versus code which could be more general.  
 
Clearly this is a value choice; however, I wonder how well a compiler can eliminate type dispatching without adding type annotation to the language.

Without having studied it too deep, I believe abstract interpretation can help you a lot with this. If you rely on that objects have a type slot to them, like Gambit's define-type:s have (it's ##vector-ref :able on slot 0 or 1), then you can always dig this out during runtime and handle it the correctly then.
 
So, I'm thinking about these things and will let them stew for... another 10 years?  I don't know.

Thanks,
-Jason

Please feel free to share reflections you're coming up with along the way.
 
Brgds,
Mikael