(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.

  (fn (bigtree)
    (let o-self self
    (let trav
         (fn (node)
             (o-self node!l)
             (do-something node!v)
             (o-self node!r)))
    (map trav bigtree)))

  sub method {
    my $self = shift;
    ...
  }

Suppose we have nested macro expressions. The inner macro will not see the expression until the outer macro processes that value; the outer macro might even decide to completely bollix the inner macroexpression.

   (macro ....
     (sub-macro ...))

  arc> (using
      (
         foo   bar
         nitz  koo)
      '(foo bar nitz koo))
  (bar bar koo koo)

The benefit of this using macro is as a basis for module systems. Suppose we have a module system such that:

  arc> (macex
    '(module foo
        (def foo () 0)
        (mac bar () nil)))
  (do
     (= (*members* 'foo) (list 'foo 'bar))
     (def foo--foo () 0)
     (mac bar--foo () nil))
  arc> (module foo
        (def foo () 0)
        (mac bar () nil)))
  <#procedure:foo--bar 3 mac>
  arc> (macex '(w/module foo (bar)))
  (do (foo--bar))

  (fn (x) x) == (fn (y) y)

Hygienic macros can also be dealt properly, mzscheme is an example. But I have no idea how Arc macros can work well with modules.

  (def report-result (result form)
    (prn)
    (prn form)
    (prs '-> result)(prn)
    (prn))

  (mac check args
    `(do ,@(do (map (fn (test)
                    `(report-result ,test ',test)) args))))

;;; so why doesn't this work? ;;;(mac check args ;;; `(do ,@(do (map [`(report-result ,_ ',_)] args))))

Anyway, this then produces the expected results:

  (check
   (is (* 6 9) 42)
   (is (* 6 9) (coerce "42" 'int 13)))

  [`(report-result ,_) ',_]

  (fn (_) (`(report-result ,_) ',_))

Standard? I don't think so. They are used for very different purposes, and just because the convention of separating a record or an object and its attribute with a dot or an arrow is common is not reason enough to blindly adopt the same convention in a new programming language.

2. It's like a kind of ad-hoc non-complete pattern matching. It would be better if we implement a complete pattern matching operator as a macro, in my opinion.

3. I have no idea whether it's right, but I would be glad if most special characters are left for the user who wants to write reader macros.