I understand. I'll revert that. On Sat, Sep 5, 2009 at 3:49 PM, Chris Hanson<[email protected]> wrote: > Don't do this. It's very important for compiled code that these > primitives be wrapped in Scheme code. This allows the compiler to > open-code them in place, so things like (map car ...) work well. > > If this is a problem for your interpreter, we'll have to find another > solution. > > On Sat, Sep 5, 2009 at 3:14 PM, Taylor R Campbell<[email protected]> wrote: >> You changed DEFINE-PRIMITIVES and a number of primitive definitions in >> the run-time system to eta-reduce them. I presume that this makes the >> system run faster on your C# interpreter, but conversely, Chris had >> made the opposite change about a year ago in order to make the system >> run faster when compiled, because if the primitive is open-coded, as >> most of them are, then the compiled procedure is much faster to call >> from compiled code than the primitive procedure. While I appreciate >> that you'd like the system to run faster on your C# interpreter, I >> suspect that even with the eta-reduced primitives, it's much slower >> than compiled code, so personally I think I'd prefer the eta-expanded >> definitions. >> >> There's also a separate issue of which form is more documentative. By >> eta-reducing the definitions, M-A in Edwin will generally show the >> primitive's documentation, including its parameter list as described >> in the microcode -- if the primitive's microcode definition was >> written with a documentation string. Eta-expanding the definitions >> with generated names makes M-A a little less useful for case when >> documentation was available, but maybe we could make DEFINE-PRIMITIVES >> generate parameter lists from the primitives' documentation strings if >> available. On the other hand, using DEFINE-PRIMITIVES at all makes >> life hard for grep and tags, silly as those may be. >> >> >> _______________________________________________ >> MIT-Scheme-devel mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/mit-scheme-devel >> >
-- ~jrm _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
