Added more notes

TODO

@@ -1,17 +1,12 @@
 Roadmap:
- - Add macro support (instead of current kludge)
+ - Add macro support, ideally including some level of hygiene
- - Target r7rs support (coordinate with feature list)
  - Code cleanup - need to take care of accumulated cruft before release
+ - Target r7rs support (coordinate with feature list)
  - User manual (or at least API docs, features page may be a good 1st step)
  - Investigate native thread support. see notes at the end of this file
 
 Working TODO list. should start creating issues for these to get them out of here:
 
- - need to speed up the compilation cycle
-   switch to using shared libraries instead of static ones
-   move macro code to that module
-   if necessary, write makefile directive to automate rebuilding cyclone for macro development
-
  - clean up runtime
    - remove unused runtime globals, rename others to make more sense
    - need multiple closure types? maybe just migrate closureN to closure?
@@ -20,12 +15,13 @@ Working TODO list. should start creating issues for these to get them out of her
 
  - macros
    - next steps:
-     - how should ex rename/compare work? check working implementations, papers. find test cases that cyclone does not handle right now
+     - added notes to macros.sld module for how ex rename/compare should work. check working implementations, papers. find test cases that cyclone does not handle right now
+       next step is to work through implementing these notes
+
      - review 4 cases below for handling macro expansion. I think there are still some outstanding issues
        with respect to eval'd macros
      - check chibi's syntax-rules
      - macros within macros, 4 cases:
-       TODO: explain how each one will be expanded:
        - compiled macro within compiled macro - expands fine, a lot of the built-in macros in scheme/base do this
        - eval'd macro within compiled macro - ??
        - compiled macro within eval'd macro - works fine
@@ -89,6 +85,9 @@ when it does not have to, and slowing down compilation even more
    - anything else?
 
 
+ - need to speed up the compilation cycle
+   switch to using shared libraries instead of static ones?
+
  - profile cyclone code, see if there are any bottlenecks we can reduce
    EG: prof cyclone transforms.sld
 
@@ -107,13 +106,6 @@ when it does not have to, and slowing down compilation even more
 
      2) Need to either allow code to read an import after macro expansion, or have another main module for self-hosting
 
-   - what's going on here:
-   cyclone> (call/cc (lambda (k) (k 1)))
-   Error: Expected 2 arguments but received 1.
-
-  extra 'cont' param is being exposed, because this works:
-  (call/cc (lambda (k) (k 1 1)) (lambda (k) (k 1 1)))
-
    - I/O
      - may be able to use fmemopen to implement output strings, although it is not supported on windows
 
@@ -190,6 +182,10 @@ GC - notes from: http://www.more-magic.net/posts/internals-gc.html
 
 The smart reader might have noticed a small problem here: what if the amount of garbage cleaned up is less than the data on the stack? Then, the stack data can't be copied to the new heap because it simply is too small. Well, this is when a third GC mode is triggered: a reallocating GC. This causes a new heap to be allocated, twice as big as the current heap. This is also split in from- and tospace. Then, Cheney's algorithm is performed on the old heap's fromspace, using one half of the new heap as tospace. When it's finished, the new tospace is called fromspace, and the other half of the new heap is called tospace. Then, the old heap is de-allocated.
 
+
+
+
+
 - Notes on native threads
 
 WRT chicken, felix has this to say:
@@ -283,6 +279,11 @@ more thoughts:
    maybe there is a way to make GC more efficient, or GC one thread at a time (not sure that is viable)?
    Baker does have another paper on realtime GC, maybe those concepts can be applied
 
+See:
+- http://comments.gmane.org/gmane.lisp.scheme.chicken/17683
+- http://www.cs.technion.ac.il/~erez/Papers/real-time-pldi.pdf
+- http://www.cs.technion.ac.il/~erez/Papers/stopless.pdf
+
 Final thought on native threads - need to move all of this into a separate document and consolidate it to determine if a viable design can be achieved.
 
 

scheme/cyclone/util.sld

@@ -122,23 +122,43 @@
 
 ;; ER macro rename function, based on code from Chibi scheme
 (define Cyc-er-rename
-  (lambda (sym) sym)) ; temporary placeholder, see below
+  (lambda (sym) sym)) ; TODO: temporary placeholder, see below
-; TODO:
+; Notes:
-;  ;; TODO: this is not good enough, need to take macro environment
+;
-;  ;; into account
+; need to figure out what to return from this function so that renaming
-;   can pass useenv in to this guy (and compare as well), and possibly add renamed bindings to it.
+; actually does what it is supposed to do (or a close approximation).
-;   would still need to modify expand (and eval?) to deal with those renames??? or maybe not, if only macros are affected??
+; then need to figure out what needs to change in the rest of the code to
-
+; support that.
- mac-env is 
+; 
-  - global env for interpreted macros, at least for now until
+; how renaming should work:
-    they can be recognized by eval
+;
-  - ?? for compiled macros
+;  - ideally, add a closure from the macro-env for identifier
-
+;  - practically, if identifier is defined in mac-env, gensym but
- use-env is:
+;    update mac-env so renamed variable points to original.
-  - current env for eval, can be passed in.
+;    if not defined, is it the same as a gensym? or nothing at all???
-    is this really a-env though? or do we need to extend it when
+;
-    a new lambda scope is introduced?
+;in order for this to work:
-  - need to keep track of it for compiled macro expansion
+;
+; - compiler needs to maintain env consisting of at least macros,
+;   and pass this along. presumably this env would be used instead of
+;   *defined-macros*.
+; - interpreter can use a-env and global-env??????
+;   there are open questions about extending a-env, but without eval being
+;   able to define-syntax (yet), I think we can defer that until later.
+; - environment code needs to be added to a common place, away from eval.sld
+;
+;   can pass mac-env, useenv in to this guy (and compare as well), and possibly add renamed bindings to it.
+;
+; mac-env is 
+;  - global env for interpreted macros, at least for now until
+;    they can be recognized by eval
+;  - ?? for compiled macros
+;
+; use-env is:
+;  - current env for eval, can be passed in.
+;    is this really a-env though? or do we need to extend it when
+;    a new lambda scope is introduced?
+;  - need to keep track of it for compiled macro expansion
 ;
 ;  ((lambda (renames)
 ;     (lambda (identifier)