Re: [r6rs-discuss] Implementors' intentions concerning R6RS

[ludo@gnu.org (Ludovic Courtès)]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> These sound really interesting!  Do we need to wait for a rewrite of
> the core interpreter, though, or could we try doing this in the
> current code?

The current code is very tricky to work with.  I once tried to change
environments to use vectors instead of lists so that `scm_ilookup ()'
would become O(N), but it proved hard to do and I eventually bailed out
(IIRC the issue that stopped me had to do with rest arguments handling,
currently handled by `SCM_CDRLOC', which assumes that a frame's
variables are contained in a list, if you see what I mean).

>>   * heap-allocation-free closure invocations, which can be achieved by
>>     storing a closure's arguments into a stack-allocated C array or,
>>     even better, in registers (of course, invoking closures with rest
>>     arguments would still require allocating an argument list);
>>
>>   * O(1) ILOC lookup, compared to the current O(N * M) algorithm, where
>>     N is the frame number and M the position of the variable within that
>>     frame's environment;
>
> Are you sure the current algorithm is O(N*M)?  I would have said
> O(N+M).

Oh yes, you're right (these are two non-nested `for' loops).

>>   * no C function call overhead for tail(-recursive) calls.
>
> I thought that was mostly achieved already, by extensive use of
> gotos.  But I guess there must be important cases that I've not
> noticed.

You're right too.  :-)

Anyway, it looks like there are opportunity for performance
improvements, and that could be an opportunity to switch to a
compiled-to-C meta-circular interpreter (as seen in SICP).

(It looks like I'm "dreaming" too much compared to my free time, but I
hope others could adopt the idea!)

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel