Basically we don't compile sub-expressions until they're actually executed, and if they are, we check for macros in the expected places and then compile.

But this would have to be an idiom, and the Lisp way is, there is no idiom: something has to encapsulate this away automatically.

If it's an idiom, it needs a macro.

> Of course, this (defining exports explicitly) is how CL handles things,

So make one.

    (mac uniqtype (name) `(= ,name ',(uniq)))
    (uniqtype my-internal-type)

> I would have thought this was safer. Basically, I'd define my code first outside of any package/module, then when I've got it mostly working and want to release then I'd put it in a module, hiding away my internal functions (which I might want to change later, and which I define as being "implementation-specific").

Naming conventions (eg. preceding dash or underscore for "private") are simpler than export lists, and don't restrict a power user from using "implementation-specific" functions if s/he has unanticipated needs - as someone inevitably will. They might cause name clashes, but unless you're using a symbol-mangling module system, this doesn't cause problems.

The problem here is that the new type name is completely unreadable. What if the new module needs several new types? What if the module would very much like to use 'defcall on its types? 'defm?

Unreadability could be solved by making a 'uniq function that takes a prefix instead of "gs", which 'uniqtype would use. If the module needs several new types, then it creates them; I don't see the problem here. The fact that 'defcall and 'defm assume static type names can be hacked around via 'eval, if necessary; but it's inelegant to have to do so. The reason why all this is inelegant is because everyone has assumed hardcoded symbols are the way to go for types. Only by layering something on top of that, something that makes hardcoded symbols not what they appear to be, such as a CL-like package system, can you get around this without changing existing conventions.

My conventions are different, probably because I'm partial to languages like Ruby, Python, and Smalltalk, where types are structured objects and not simple names. For example, my instinct on making tagged objects callable would be to use ((tag <object>) 'call) as the caller function. Then tables, functions, or even tagged objects could be used as types. This would eliminate the need for 'call*.

In theory it would be possible to add a type object that is dynamically created but is immutable once created, but attaching everything to such a type object would make dynamism a little slower. My plan had been to define polymorphic functions on (probably symbol) types, and replace 'call* with overloading of apply:

  (defcall foo (v x)
    (do-something-on-foo v x))
  =>
  (defm <base>apply ((t gs42 foo) x)
    (let v (rep gs42)
       (do-something-on-foo v x)))

Been thinking of that somewhat; basically the most straightforward would be a symbol-conversion macro upon which any symbol mangling system can be built:

  (resymbol (foo foo@bar
             nitz nitz@bar)
    (+ (foo this) (nitz that)))
  =>
  (do (+ (foo@bar this) (nitz@bar that)))

  (xdef 'uniq gensym)

  > (gensym)
  g26
  > (define g (gensym))
  > g
  g27
  > (equal? g 'g27)
  #f
  > (gensym 'prefix)
  prefix28
  > (gensym "string")
  string29

  arc> (= gs (uniq))
  gs2003

A lightweight but hackish alternative would be to special-case modules in the translation process. This could be done by checking, whenever you have an sexpr of the form "((<name1> <name2>) ...)", whether <name1> is globally bound to a module and <name2> to a macro within the module.

A more general way to do this would be, when you have an sexpr of the form "((...) ...)", before doing anything else, to macroexpand the sexpr in functional position. Then you could write modules as macros, expanding to the evaluation of their arguments in that module (the macro equivalent of what mine do via 'defcall now).

I think, but am not sure (so feel free to prove me wrong), that the real dichotomy is not between CL packages and AST interpretation, but between supporting first-class macros or the equivalent, and making the module system part of the language itself (hacking ac.scm) rather than creating it within the language.

Done. The above links to the result of "git diff" after the changes. While I think it works (it loads arc.arc fine), I don't want to actually push it to anarki in case I've made a mistake and there's some existing code it breaks. With it, and my module system, you can do the following:

In "test.arc":

    (prn "test.arc evaluated")
    (mac mquote (x) `',x)

    Use (quit) to quit, (tl) to return here after an interrupt.
    arc> (load "lib/module/python.arc")
    nil
    arc> (use test)
    test.arc evaluated
    #3(tagged module #<namespace>)
    arc> (mac test* (x) (test x))
    #3(tagged mac #<procedure>)
    arc> (test*.mquote foo)
    foo

As an aside - could we possibly do this without depending on mzscheme namespaces? It should be possible to have the macro instead be something of the form:

  (mac module-name (x)
    (case x
      member  gs42 ; where gs42 is a (uniq)-ed symbol
      member2 gs43
              (err:string "module does not contain member - " x)))

    (define (ac-macro? fn)
      (let ((fn (if (pair? fn) (ac-macex fn) fn)))
        (cond
         ((symbol? fn)
          (let ((v (namespace-variable-value (ac-global-name fn) 
                                             #t 
                                             (lambda () #f))))
            (if (and v
                     (ar-tagged? v)
                     (eq? (ar-type v) 'mac))
                (ar-rep v)
                #f)))
         ((and fn
               (ar-tagged? fn)
               (eq? (ar-type fn) 'mac))
          (ar-rep fn))
         (#t #f))))