[Top][All Lists]
[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
[MIT-Scheme-devel] Re: changes to primitive definitions, Joe Marshall, 2009/09/06