mit-scheme-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] changes to primitive definitions


From: Chris Hanson
Subject: Re: [MIT-Scheme-devel] changes to primitive definitions
Date: Sat, 5 Sep 2009 15:49:15 -0700

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<address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]