Arc Forumnew | comments | leaders | submitlogin
1 point by sacado 6098 days ago | link | parent

There's a problem with using = and def. I tried it, but many parts of the core and libraries assume a unique namespace. As commands can have many side-effects, everything breaks easily.

But the idea of using tables is excellent.



1 point by sacado 6098 days ago | link

Anyway, we must be able to access the global namespace too. If you overwrite = and def, you can't. Or you have to define g= and gdef :)

-----

4 points by almkglor 6097 days ago | link

Here's a different idea. Suppose that instead we build a basic modulesystem which transforms:

  (modules-base
     ;name of module.
     foo
     ;set of functions in this module
     (bar)
     ;set of module variables
     (nitz)
     ;set of functions from other modules
     ((module2 hmm niawniaw))
     (def bar (x) (hmm) (niawniaw) (do1 nitz (= nitz x))))
to:

  (= foo
     (with
        (bar nil nitz nil hmm module2!hmm niawniaw module2!niawniaw)
       (= bar (fn (x) (hmm) (niawniaw) (do1 nitz (= nitz x))))
       (fill-table (table) 'bar bar)))
Then we create another macro which simply scans through the code for (def ...) forms and transforms the following code:

   (module foo
     (use module2)
     (module-vars nitz)
     (def bar (x) (do1 nitz (= nitz x))))
to:

  (modules-base
     foo
     (bar)
     (nitz)
     ;gotten by taking (keys module2)
     ((module2 hmm niawniaw))
     (def bar (x) (do1 nitz (= nitz x))))
Weaknesses: (1) we can't make module-variables accessible outside. If we had access to environments, though, we could.

(2) macros are impossible as yet, whether shared or not. Possibly, we need macrolet, and adding some mechanism to store macros separately from the module table - possibly in a table-of-tables module-macros.

Implementation: simple scanning would be nice. However, modules-basic would be better implemented by a 'macrolet form.

Conclusion: We need macrolet.

-----