Re: mockmod.el --- The mockery of a module system for Emacs Lisp

[Oliver Scholz <alkibiades@gmx.de>]

Guillaume Marceau <gmarceau@cs.brown.edu> writes:

> On Tue, 28 Mar 2006 14:11:42 +0200
> Oliver Scholz <alkibiades@gmx.de> wrote:
>
>> This package is declared to be experimental and I mean it. I post it
>> here for review and to get comments on the approach used in it, before
>> I start to test it by rewriting my own packages to use it.
>> 
>
> The PLT Scheme module system is very powerful. You might want to read
> its doc to see if there is any feature you would like to borrow, such
> as "provide all-from", "require rename", "require prefix" and "require
> only"
>
> http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-5.html#node_chap_5

Thank you for the pointer. I will peruse this more thoroughly after I
got more experience with the reliability (or lack thereof) of my
`rewrite the symbols'-hack.

> There are also interesting interaction between the PLT module system and
> the macro system, because the supports for accurate separate
> compilation. It might be more than you want to get into, but still, it
> is an important thing to keep in mind. Here is the paper:
>
> http://www.cs.utah.edu/plt/publications/macromod.pdf

Thank you for the pointer, it seems to be an interesting read. Though,
after skimming it, I have the impression that implementing that would
actually require to rewrite the Emacs Lisp compiler.

***

There are some issues with mockmod.el, though, where I'd like to hear
some opinions.

   - Unfortunately, in Emacs Lisp defining operators are just like any
     other special form in that they are not confined to the top
     level.

     (if (require 'foo-bar nil t)
         (defun foo (bar)
           (message "lirum larum"))
       (defun bar (foo)
         (message "larum lirum")))

     There is no way for mockmod.el to cope with that. (It does
     however deal with the reasonable case of defining forms inside
     top-level `let' or `progn' etc.) not to mention `defun's and
     `defvar's inside function definition bodies. I guess it's okay to
     treat those as simple cases of "Don't do that then!"?

   - Right now mockmod.el does not affect the interpreter. Changing
     this while keeping the exact semantics of macroexpansion as they
     are right now would require hacking Feval in the C code itself.
     However, I could provide functions like `mockmod-eval-defun' and
     `mockmod-eval-last-sexp' that a) fully macroexand their
     expressions and b) rewrite the symbols according to the module
     spec before they invoke eval.

     I think that could work for all sane cases. It would however not
     change the semantics of elisp for macros that cause side effects
     during macroexpansion time. (The last two statements together
     include that I consider such macros to be "insane".) Can I
     reasonably treat this as another case of "Don't do that, then!"?


    Oliver
-- 
5 Floréal an 214 de la Révolution
Liberté, Egalité, Fraternité!