1) We could add a "fail" continuation which is called upon error. By default the "fail" continuation will be the same fail continuation as the caller, but for forms such as 'errsafe and 'after, we replace the "fail" continuation.

2) Alternatively, we use a global (or thread-local...) variable to store the current fail handler. Then 'errsafe and friends will store the current value of the fail handler in a local, replace it with its own, and then run its subforms; afterwards (whether it returned via fail or normal continuation) it restores the previous value of the fail handler.

Idea: macros

1) We could piggyback off the existing Arc and just use repeated 'macex until we reduce down to 'fn and 'if and function calls.

1.1) Then for metacompilation, we could create two levels of Arc: an interpreted Arc and a compiled Arc. Macros are done in interpreted Arc while full programs are compiled. Basically interpreted Arc would simply be an 'eval for Arc, in Arc.

Idea: Arc built-in library

1) In the sample we already have a "built-in" which is in fact added to the source to be compiled: ccc or call/cc. We could extend/generalize this to include a set of built-ins that are added to the source to be compiled, maybe like so:

  ; assuming car and cdr are true built-ins
  (def-arc2c-builtin map1 (k f l)
    (if l
        (map1
          (fn (rest-v)
            (f
              (fn (v)
                (cons k v rest-v))
              (%car l)))
          f (%cdr l))
        (k nil))

Simply inserting the entire arc.arc code will add bloat, because most programs don't even use most of the arc.arc code. Given the level of documentation of arc functions (arcfn.com notwithstanding), it is more than likely that the user will not use arc.arc code. So it's better if we simply insert the code if it is used.

Come now, if you want real support for eval, you'll also need to include the compiler:

  (eval `(fn (x) ,@my-variable)) ;how will it build the function?

Basically you create a virtual function:

  (def eval (e (o env))
    (if
      (caris e 'fn)
        (add-attachment
          'environment env
          (annotate 'virtual-function
            (cdr e)))
      ...))
  (defcall virtual-function (f . args)
    (with (env (get-attachment 'environment)
           (arglist . body) args)
      ; has to be nondestructive
      (zap add-args-to-environment env arglist args)
      (each e body
        (eval e env))))

Actually, I don't recommend that the reader parse it; pg's code specifically parses special syntax after the reader. This also means that:

  (mac foo (x)
    (string x))
  (foo arf:narf.oops)
  => "arf:narf.oops"

treeparse is pretty good, and I'm sure a full Arc parser can be built on treeparse.

Looks like I need to speed up writing my treeparse tutorial ^^

As for parsing special syntax, an Arc version of ssyntax would work: we just need a symbol->string conversion (meaning full 'coerce support) and seek ~!.: in the substring.

Continuations & tail-calls are treated the way Steele proposed it in the lambda papers.

The following code :

  (set f (fn (n)
     (if (< n 2)
          n
          (+ (f (- n 1)) (f (- n 2))))))

  (prn (f 30))

  (do
    (set f (fn (n@1)
      (if (%< n@1 2)
        n@1
        (%+ (f (%- n@1 1)) (f (%- n@1 2))))))

  (%prn (f 30)))

  (let ((r@5 (fn (k@6 n@1)
    (let ((r@7 (%< n@1 2)))
      (if r@7
        (k@6 n@1)
        (let ((r@11 (%- n@1 1)))
          (f (fn (r@8)
            (let ((r@10 (%- n@1 2)))
              (f (fn (r@9) (k@6 (%+ r@8 r@9))) r@10))) r@11)))))))

  (let ((r@3 (set f r@5)))
    (f (fn (r@4)
      (let ((r@2 (%prn r@4)))
        (%halt r@2))) 20)))

  (fn nil
    (let ((r@5 (%closure
                       (fn (self@12 k@6 n@1)
                         (let ((r@7 (%< n@1 2)))
                           (if r@7
                             ((%closure-ref k@6 0) k@6 n@1)
                             (let ((r@11 (%- n@1 1)))
                               ((%closure-ref f 0)
                                 f
                                 (%closure
                                   (fn (self@13 r@8)
                                     (let ((r@10 (%- (%closure-ref self@13 2) 2)))   
  ((%closure-ref f 0) f (%closure (fn (self@14 r@9) ((%closure-ref 
  (%closure-ref self@14 1) 0) (%closure-ref self@14 1) (%+ 
  (%closure-ref self@14 2) r@9))) (%closure-ref self@13 1) r@8) 
  r@10))) k@6 n@1) r@11)))))))) (let ((r@3 (set f r@5))) 
  ((%closure-ref f 0) f (%closure (fn (self@15 r@4) (let ((r@2 (%prn 
  r@4))) (%halt r@2)))) 20))))

Also on code block 1 you show (prn (f 30)) but in code block 2 you seem to pass (f <continuation> 20)? I assume this is just a mistake?

I managed to understand the transformation up to code block 3, but not code block 4; what does '%closure do? Allocate heap memory for the closure? Also, what's the syntax for "goto"?

Finally: how about the equivalent C code?

The output C code looks suspiciously like assembly language to me. Perhaps we can also target a temporary assembly syntax so that we can do minimal peephole opts, such as convert stuff like PUSH(x); y = TOS(); to MOVE(x,y);. Can't wait to actually see this code on the git ^^.

As for the generated code, yes, it's a lot like a portable assembly code. There are certainly easy optimizations to perform on it, but as for now, it's working and that's a lot :)

As an aside compile-file could be restructured like the following:

  (def compile-file (filename)
    (compile-ast (parse-file filename) (+ (strip-ext filename) ".c")))
  ; to allow programmatic access
  (def compile-ast (ast dest)
    ; chain of conversions
    (let chain
         (list
           (list cps-convert "CPS-CONVERSION")
           (list closure-convert "CLOSURE-CONVERSION"))
    ; do reduction
    (let final-ast
         (reduce
           (fn (ast (f desc))
             (let new-ast (f ast)
               (prn "----------------- AST after " desc)
              (prn (source new-ast))
               new-ast))
           chain ast)
        (prn "-------------------- C Code:")
        (w/outfile f dest
          (w/stdout f
            (prn:liststr:code-generate final-code))))))

In fact the chain list should probably be better use `(,), so that we can support flags or suchlike for optimizations:

   `(
       (,cps-convert "CPS-CONVERSION")
       ,@(if optimize
             `((,optimize-after-cps "CPS-OPTIMIZATION")))
       (,closure-convert "CLOSURE-CONVERSION")
       ,@(if optimize
             `((,optimize-after-closure "CLOSURE-OPTIMIZATION"))))

For that matter my concern is with the expansion of PUSH and POP:

   PUSH(x); y = POP();

   =>

   *sp++ = x; y = *--sp;

   y = x; //desired target

  BEGIN_JUMP(3); PUSH(LOCAL(5)); PUSH(LOCAL(6)); PUSH(LOCAL(7)); END_JUMP(3);

  memcpy (stack, stack + 5, sizeof(obj) * 3); sp = stack + 3; END_JUMP(3);

  PUSH(x); if(POP)

  if (x)

Basically the only thing that can't be redefined on Anarki are:

  quote
  quasiquote
  if
  compile
  fn
  set
  lset

For instance, scanners redefine car and cdr, and settable-fn's redefine sref.

  (map + (list 1 2 3) (list 9 8 7))

For that matter, it shouldn't be so difficult - basically if the compiler ever sees (set + ...) anywhere (where + is a global, at least), it disables the use of %+.

Possibly, we could add another step in the transformation process (which is why I suggested the structure in http://arclanguage.com/item?id=5598 to allow easy insertion/deletion of steps).

Basically the new step just traverses the structure (without mutating it) and creates a list of built-ins to disable.

To use it, load arc2c.arc, then run (compile-file "foo.arc"). It will then show you all the transformations it performs and generate a file, foo.c. Compile it with your favorite C compiler, and you're done.

Are currently implemented :

- +, -, *, <, >, <=, >=, is, isnt, prn on fixnums - is, isnt, prn on symbols (including t and nil) - let, if, fn, set, and, or, quote.

  (mac my-mac () t)
  (def foo ()
     (my-mac))
  (mac my-mac () nil)
  (foo)

  (def foo ()
    (my-mac))
  (mac my-mac ()
       '(prn "foo!"))
  (foo) ;this last will also depend on whether you're on Anarki or ArcN

So what we do is, we use our own 'eval (this should be easy, this is a lisp after all). However, this 'eval's 'set must determine if it's assigning to a global or a local (again, this should be easy, since it has to know what to write where). Then it checks if a global assign is that of a macro.

For each top-level form, we 'eval the form and check if any global assign is a macro assign. Now we know if a macro has been assigned to a global. Then we compile the form.

The alternative is simply to check if a form has 'mac anywhere in it. If it has (mac ...) or (annotate 'mac ...) anywhere, we run this in 'eval instead of compiling that form.

Really, though, we don't need to keep the semantics of Arc completely. We can add a few rules for macro writers: Always use 'mac. Don't use anything other than the built-in functions, or if you really need a non-builtin function for your macro, then put it in a 'let form together with your macro, and put two copies of the 'let form.

Alternatively, we could just make a REPL for Arc, in Arc, write it in a form suitable for compilation, and then write the compiler in a form compatible with the REPL and arcN.

      ___
     v   \
  REPL    compiler
     \___^

And you're compiling (not executing) a top-level form that does those things?

All right then - make the limitation that macros must be defined in their own top-level forms, and if a top-level form ever contains 'mac in a function position, or (annotate 'mac ...), then it's executed and any macros it assigns to globals are treated as such: macros. If it terminates in weeks, too bad.

Alternatively just write an interpreted REPL and include the ability to compile code, but not include macros in compilation - macros must be loaded into the REPL, then the actual runnable code is compiled (and the compiled code's macros are ignored).

  ref = (malloc (sizeof (cons-cell)) << 1) + 1;

I think it's easier to swap the meaning of numbers with objects rather than build our own GC.

Here's the Lua way:

struct obj{ int type; union data{ double num; void *ptr; }; }

Note that we can actually abstract away the representation of objects from the actual binary bits that represent it. For instance I would recommend that objects use the following representation (as noted by binx):

  typedef struct s_obj{
    enum e_type {
      other = 0,
      number = 1,
      symbol = 2,
      character = 3
    }
    type;
    union u_data{
      void* other;
      int number;
      void* symbol;
      Uchar character; //unicode character
    } data;
  } obj;
  #define OBJ_TYPE(o) ((o).type)
  #define OBJ2FIXNUM(o) ((o).data.number)
  #define FIXNUM_MIN INT_MIN //requires glibc
  #define FIXNUM_MAX INT_MAX
  //others defined similarly

1. 32-bit pointers and 32-bit int's

2. malloc() always returns an address at a 32-bit boundary (i.e. every four bytes, or with the lowest two bits zero)

We can then use:

  typedef int obj;
  #define OBJ_TYPE(o)  ((o) & 0x03)
  #define OBJ2FIXNUM(o)  ((o) >> 2)
  #define FIXNUM_MIN (-(1 << 30))
  #define FIXNUM_MAX ((1 << 30) - 1)

  (int) my_int_ptr << 1

The only thing is that fixnums don't have an architecture-independant size, but that's not a problem in practice anyway. The only constraint is that the biggest fixnum is

  2**(max(sizeof(int), sizeof(int*)) - 2)

  #include<stdio.h>
  
  int main(void){
        printf("sizeof(int) = %d\n", sizeof(int));
        printf("sizeof(long) = %d\n", sizeof(long));
        printf("sizeof(void*) = %d\n", sizeof(void*));
        return 0;
  }

  sizeof(int) = 4
  sizeof(long) = 8
  sizeof(void*) = 8

  #if defined(__COMPILER1__) || defined(__COMPILER2__)
    typedef intptr_t fixnum;
  #else
    typedef long fixnum;
  #endif

  #include<stdint.h>

The infinite loop could be caused by two objects that references each other, e.g. a references b and b references a, so the GC keeps going from a to b and from b to a. To solve the problem, if this is the problem, if an object has been already marked, don't follow it.

"Google does not have specific eligibility requirements for mentors, as we know our mentoring organizations will be best able to determine the selection criteria for their mentors."

I don't know if LispNYC has any specific requirements.

As a mentor, I think you have to be in email contact with your student, give them advice as necessary, and evaluate their work. I believe I read somewhere that they estimate mentoring will take about 5 hours a week depending on the number and difficulty of projects.

As of collections-in-function-position instead of returningm for example, and hash-table one could return a fuction that acts as an interface towards the real hash-table.

  (def table () 
    (let tb (make-real-table)
      (fn (key) (gethash tb key))))

Then let's not attach both types to the same object. pg's implementation creates a new object and attaches the type to that object, leaving the original representation object (type id and all) untouched. Basically we have an annotation type which just contains the attached type and the original object, leaving the type id bits untouched.

> This doesn't handle setting values, but I think that a few macros could solve the problem.