Arc Forum | resymbol: a step along the line to a symbol-based modulesystem

Arc Forum

resymbol: a step along the line to a symbol-based modulesystem

4 points by almkglor 5969 days ago | 1 comment

CL packages separate modules by symbol, and for good reason: symbols are used for many things, ranging from macro names, function names, and on to hash keys and type names. Sometimes it might be useful for a module to place a symbol for itself in a global table, without worrying that the symbol might be used by another module - for example, the Anarki call* types table.

With that I present resymbol, a macro which changes the symbols of an expression:

  (require "ssyntaxes.arc")
  
  (def resymbol-fn! (sl e)
    (let tb (fill-table (table) sl)
      ; disallow translations of builtins
      (wipe tb!quote tb!quasiquote
            tb!unquote tb!unquote-splicing
            tb!fn tb!if tb!set)
      ((afn (e)
         (if
          (cons? e)
            (do
              (zap self (car e))
              (zap self (cdr e))
              e)
          (sym? e)
            (if (ssyntax e)
                (self:ssexpand e)
                (tb//idfn e))
          ; else
            e))
       e)))
  
  (mac resymbol (sl e)
    (resymbol-fn! sl e))

To use:

  (resymbol (join d>>join)
    (map join (car pts) (cadr pts)))

We could also integrate this into a REPL and/or into load:

  (= my-tl-table '(join d>>join))
  (load "my-file.arc" [resymbol-fn! my-tl-table _])

Edit: Hmm. I seem to use 'zap quite a bit... maybe useful to have ssyntax for this? (!self (car e)) maybe?

edit2: hmm, this might not be simple after all, we would have to make !self the equivalent of a macro call. hmm.

2 points by eds 5969 days ago | link

I really like the zap idea... although your second edit has a good point. But on the other hand, it wouldn't necessarily be a bad thing to allow macros in ssyntax, would it? Just a little difficult to implement perhaps. Or we could just get first class macros...

Another thing I've been thinking about would be allowing macros in call* type tables, e.g. allowing (3 + 4 * 5) to macro-expand instead of forcing infix math to be implemented as a function at runtime. (This would seamlessly integrate infix math into the regular syntax of Arc, with no performance penalty at all... something I personally would like to see.) But this would probably require type inference in the language, so might not be implementable in the near future.

-----