339 |
actually obtain the result for scm_lookupcar: First, in function |
actually obtain the result for scm_lookupcar: First, in function |
340 |
symbol2memoized_symbol the environment is scanned to obtain the iloc, |
symbol2memoized_symbol the environment is scanned to obtain the iloc, |
341 |
second, in function memoized_symbol2location the environment is scanned |
second, in function memoized_symbol2location the environment is scanned |
342 |
according to the iloc data. |
according to the iloc data. This, however, only applies to the first lookup |
343 |
|
of a local variable. |
344 |
|
|
345 |
* revoke macro transformers from being stored in variables. I.e. |
* revoke macro transformers from being stored in variables. I.e. |
346 |
(define-macro (foo ...) ...) |
(define-macro (foo ...) ...) |
370 |
environment where the macro was defined. That is, somehow the relationship |
environment where the macro was defined. That is, somehow the relationship |
371 |
between the macro and its environment has to be retained.] |
between the macro and its environment has to be retained.] |
372 |
|
|
373 |
* Separating memoization/compilation and execution. Instead of doing |
* Separate execution of memoized code from all other steps. Instead of doing |
374 |
memoization combined with execution, these two issues should be separated. |
syntax transformation and memoization combined with execution, these issues |
375 |
|
should be separated. A first step would be to extract the execution phase. |
376 |
That is, after reading an expression, the code is first transformed by the |
That is, after reading an expression, the code is first transformed by the |
377 |
syntax transformer (if one is given). Then, the resulting code is processed |
syntax transformer (if one is given). Then, the resulting code is processed |
378 |
by a memoization phase. In this phase, all remaining syntax checks and |
by a phase that handles the built-in syntax transformer and this way also |
379 |
|
performs the memoization. In this phase, all remaining syntax checks and |
380 |
transformations are performed. The result of this phase is the memoized |
transformations are performed. The result of this phase is the memoized |
381 |
code that is run by the executor. |
code that is run by the executor. |
382 |
|
|
387 |
all any more. In general, code that makes use of guile's built-in system to |
all any more. In general, code that makes use of guile's built-in system to |
388 |
create acros, macros and mmacros may have problems. |
create acros, macros and mmacros may have problems. |
389 |
|
|
390 |
|
* Split the handling of the built-in syntax transformer into two separate |
391 |
|
tasks: First, the handling of user-provided acros, macros and mmacros. |
392 |
|
Second, the handling of the built-in syntactic forms. The interface between |
393 |
|
the two steps would then be fully macro expanded scheme code, which makes |
394 |
|
use of a limited set of syntactic forms. In principle, even the handling of |
395 |
|
standard scheme forms like 'cond could be done in the first phase. This |
396 |
|
would limit the set of syntactic forms that can appear in the second phase. |
397 |
|
|
398 |
* Allow to write memoized code to disk and load it back in. |
* Allow to write memoized code to disk and load it back in. |
399 |
|
|
400 |
* Make syntax-case our standard macro expander. |
* Make syntax-case our standard macro expander. |
436 |
and the executor. There should also be some way to store memoized/compiled |
and the executor. There should also be some way to store memoized/compiled |
437 |
code and read it in later. The format of the memoized code may also |
code and read it in later. The format of the memoized code may also |
438 |
influence the layout of the stack/continuation data structure as well as the |
influence the layout of the stack/continuation data structure as well as the |
439 |
layout of the local environment data structure. |
layout of the local environment data structure. It may make sense to split |
440 |
|
up the compilation/memoization phase into two phases: The first phase would |
441 |
|
perform a scheme->scheme optimization, where those optimizations would be |
442 |
|
performed, that can be performed on scheme code itself. The second phase |
443 |
|
would then perform the memoization and possibly some optimizations that are |
444 |
|
based on the format of the memoized code. The advantage of the |
445 |
|
scheme->scheme compilation phase is, that all memoizer backends would |
446 |
|
benefit from the optimizations performed in that phase. Further, for such a |
447 |
|
phase a lot of optimizer code from the scheme community could be used |
448 |
|
without need to do a lot of guile-specific tuning. |
449 |
|
|
450 |
* stack/continuation - This is an interface between the executor and the |
* stack/continuation - This is an interface between the executor and the |
451 |
debugger. In a 'stackless' execution model, scheme stacks and continuations |
debugger. In a 'stackless' execution model, scheme stacks and continuations |