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: Joe Marshall
Subject: Re: [MIT-Scheme-devel] changes to primitive definitions
Date: Sat, 5 Sep 2009 15:59:22 -0700

Reverted.

On Sat, Sep 5, 2009 at 3:57 PM, Joe Marshall<address@hidden> wrote:
> I understand.  I'll revert that.
>
> On Sat, Sep 5, 2009 at 3:49 PM, Chris Hanson<address@hidden> 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<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
>>>
>>
>
>
>
> --
> ~jrm
>



-- 
~jrm




reply via email to

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