Arc Forumnew | comments | leaders | submitlogin
1 point by almkglor 5911 days ago | link | parent

Oh, bummer. I guess I got too used to lazy evaluation in Haskell.

Macro support... dang. It's kind hard to scan through the code looking for macro definitions, and then you need to have them exportable, meaning you need the original list - and exportable macros will not be able to refer to the exporting environment (bummer).



1 point by raymyers 5908 days ago | link

Macros in packages are a hard problem, no doubt. I still wonder if some degree of macrolet hackery might do the trick.

On a brighter note, I decided to make the lazy semantics of "lib/treeparse.arc" a special case, not the default. That way, there only needs to be one macro, delay-parser. Apart from making the code cleaner, this also makes a module more feasible.

-----

1 point by almkglor 5908 days ago | link

The problem is an expectation like the following:

  (module
    (module-vars foo)
    (interface settings
      foo-option)
    (def foo-option arg
      (if arg
        (= foo (car arg))
        foo))
   (mac macro-using-foo body
     `(do ,foo ,@body)))
Hmm. Maybe export the macros as functions. Hmm. This also means that everything within the module has to be macro-expanded, in case macroexpansion creates a reference to a module-based macro. Aargh.

-----