From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oliver Scholz Newsgroups: gmane.emacs.help Subject: Re: mockmod.el --- The mockery of a module system for Emacs Lisp Date: Mon, 24 Apr 2006 14:53:52 +0200 Organization: Arcor Message-ID: <87fyk3yw3s.fsf@totally-fudged-out-message-id> References: <4429282e$0$7751$9b4e6d93@newsread4.arcor-online.net> <20060413214851.6aac9b2f@hershey> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1145886052 25999 80.91.229.2 (24 Apr 2006 13:40:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Apr 2006 13:40:52 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Apr 24 15:40:49 2006 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FY1Ie-0006Wd-U2 for geh-help-gnu-emacs@m.gmane.org; Mon, 24 Apr 2006 15:40:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FY1Ie-0000RJ-FG for geh-help-gnu-emacs@m.gmane.org; Mon, 24 Apr 2006 09:40:24 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news.netcologne.de!newsfeed-fusi2.netcologne.de!newsfeed01.chello.at!newsfeed.arcor.de!news.arcor.de!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Cancel-Lock: sha1:hM4Pe7a3+KCX0j0mDLf8hgen0nE= Original-Lines: 72 Original-NNTP-Posting-Date: 24 Apr 2006 14:54:48 MEST Original-NNTP-Posting-Host: d5ae1b41.newsread4.arcor-online.net Original-X-Trace: DXC=UNh4>@4^T44E][lTbkER26:ejgIfPPld4jW\KbG]kaM8]kI_X=5Kea6LjZb\=FYmd=3kWa6 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:34627 Archived-At: Guillaume Marceau writes: > On Tue, 28 Mar 2006 14:11:42 +0200 > Oliver Scholz 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é!