Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> I must admit, that was my first reaction too. I can't really see what
> this change buys us.
Hackability. Anyway, I'll give up for now due to lack of time and
energy.
Thanks,
Ludovic.
___
Guile-devel m
Kevin Ryde <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>>
>> Ok to commit?
>
> No. Please don't move stuff around, it works fine like it is.
I must admit, that was my first reaction too. I can't really see what
this change buys us.
Regards,
Neil
__
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Ok to commit?
No. Please don't move stuff around, it works fine like it is.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Ludovic Courtès escreveu:
> Not sure about this. The alternative would be to keep both in a single
> file, but that would lead to a long file with mixed
> memoizing/unmemoizing logic, and with a load of helper functions for
> both. Would that be preferable?
I think yes. I expect that memoize an
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>> Do these need to be .i.c - i.e. implying that they need to be
>> #included? Can't they be normal .c files?
>
> No, because some of them are `static' (all the `unmemoize_' functions
> for instance) and should
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> I have a patch that further "despaghettifies" the evaluator, as Han-Wen
> would say. ;-)
Can you say more about how your change despaghettifies the code? I
can see that it makes eval.c shorter - but what else?
> It adds two files, `eval-me
