Reverted. On Sat, Sep 5, 2009 at 3:57 PM, Joe Marshall<[email protected]> wrote: > 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 >
-- ~jrm _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
