Re: module interface changed or changing?

[mike@olan.com (Michael N. Livshin)]

lutterdc@cs.purdue.edu (David Lutterkort) writes:

> > On Tue Jun 16, Clark McGrew <mcgrew@sukat.icrr.u-tokyo.ac.jp> wrote:
> > 
> > I do have a very short wish-list which can be implemented as a very
> > short macro: Add "export-from-module" which takes a list of names and
> > does "(define-public <name> #f)" to export the names, then a regular
> > "define" can be used everyplace else.  This makes it really trivial to
> > wrap existing scheme code in a guile module.  If the current module
> > system is not DOA, I'll submit an "export-from-module" patch.

<AOL> Yes, please! </AOL>

I really wonder why this hack is not in the Guile README or something.
One small step - and you can write modularized code and not make it
Guile-specific at the same time.

> > 
> 
> This would be a giant step forward. I tried something similar, but couldn't
> get it to work with define _and_ defmacro. With the present module system,
> I have no idea how I could for example define new syntax with define-syntax
> and export that definition.

Surprisingly, you can, just like with normal definitions:

(define-public my-macro #f)
(defmacro my-macro (arg)
  `(car ,arg))

The above just works - `my-macro' is exported.  Valid for syncase too.
I don't know, however, if it is wise to depend on this behavior.
OTOH, in whichever way Guile module system may be changed in the
future, it should permit such things somehow, right?

> As I see it, a module system should regulate visibility of names,
> independent of what they're bound to. That's why I don't like the
> distinction between define-public and defmacro-public in the current
> system.

Hmmm.  I think *-public stuff is just wrong anyway, as it renders your
code Guile-specific.  Also, it is good to have separate export clauses
for regular definitions and syntax - separate compilation (somewhere
in the blue sky) requires this.

Here is what I just started to use for my code:

---------------------->8 cut here 8<----------------------
;;; module-hacks.scm --- export-from-module etc.
;; -*- Scheme -*-
; Copyright (C) 1998 Michael Livshin

(define-module (util module-hacks))

(if (not (defined? 'export-from-module))
    (begin
      (defmacro-public export-from-module names
        `(begin
          ,@(map (lambda (name)
                   `(define-public ,name #f))
                 names)))
      ;; happens to be the same now:
      (defmacro-public export-syntax-from-module names
        `(export-from-module ,@names))))

;;; module-hacks.scm ends here
---------------------->8 cut here 8<----------------------

So that you can write:

(define-module (my-module)
  #:use-module (util module-hacks))
(export-from-module proc1 var1 var2 proc2 etc)
(export-syntax-from-module macro1 macro2 etc)

Thanks Clark!

> 
> Here's my wish-list for a module system:
> (1) Make names available outside of module with an export clause instead of
> different define/defmacro
> (2) Allow selective imports from a module
> (3) Allow renaming of imported names
> 
> Maybe all this can be done with the current module system already ... I'm
> not an expert.

(1) See the code above

(2) You can lookup individual symbols in modules, so some magick macro
can probably be written.

(3) Ditto.

> I do like Scheme48's module system (Jonathan Rees: Another
> Module System for Scheme) a lot better than the current one. Has anybody
> ported that to Guile already ?

I guess not.  Would be cool - I like it too.  In fact, the mailing
list archive seems to suggest that everybody here likes it :)

> David

HTH,
mike.