bugGuile - Bugs: bug #20941, Modules interact badly with macros

 
 

bug #20941: Modules interact badly with macros

Submitter:  Andreas Rottmann <rottmann>
Submitted:  Fri 31 Aug 2007 12:41:48 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 20 Jul 2009 09:35:04 PM UTC, comment #3: 

The good news is that this is already addressed by the 1.9 development series.

However, it's very unlikely that it will ever be fixed in the 1.8 series (fixing it would require a major overhaul of the interpreter, which is does not appear like a good option given the compiler/VM now available in 1.9.)

Therefore, I'm closing this bug.

Thanks,
Ludo'.

Ludovic Courtès <civodul>
Group administrator
Wed 31 Oct 2007 09:15:25 AM UTC, comment #2: 

The thing is, for engineering reasons, there are procedures used by macros that you may not want to export.  Or the macros you export may be using procedures from other modules that you do not want to re-export.  Overall, you don't want to pollute the user's name space.

Worse, if the module user uses a renamer or a selector (e.g., "#:select (the-macro-that-i-want)"), the macros just won't work.

Symbols used by macros should be resolved in the macro definition context, not in its usage context (see "Composable and Compilable Macros: You Want it When?" by M. Flatt).

FWIW, I used a hack to make "macros that work" in SRFI-35.

Ludovic Courtès <civodul>
Group administrator
Wed 31 Oct 2007 12:23:54 AM UTC, comment #1: 

Is this causing real trouble for you?

From the practical point of view, isn't it straightforward just to export any procedures that are used by the syntax expansion, as well as exporting the syntax itself?

From the conformance point of view, there is no case to answer, since R5RS doesn't specify a module system.

If we in future implement a module or library system according to some external standard (e.g. R6RS or ERR5RS), and that system specifies that the procedures should not need exporting, in cases like this, then we will have to make sure that Guile follows that specification.

For now, however, it seems reasonable just to document that any procedures used by a syntax expansion must also be exported.

Do you agree?  If you do, I'll look at updating the manual.

Neil Jerram <ossau>
Group administrator
Fri 31 Aug 2007 12:41:48 PM UTC, original submission:  

When a (syntax-rules) macro expands into the use of an internal procedure, the module the macro resides in must export that internal procedure, which should not be necessary.

Example session:

guile> (version)
"1.8.2"
guile> (define-module (test) #:export (test-macro) #:use-module (ice-9 syncase)
#<directory (test) b7b2a1d0>
guile> (define (test-proc x) (write x) (newline))
guile> (define-syntax test-macro (syntax-rules () ((test-macro x) (test-proc (* x x)))))
guile> (define-module (test-user) #:use-module (test))
#<directory (test-user) b7b28ae0>
guile> test-macro
#<macro! sc-macro>
guile> (test-macro 5)

Backtrace:
In standard input:
   9: 0* (test-macro 5)
   9: 1  (test-proc (* 5 5))

standard input:9:1: In expression (test-proc (* 5 5)):
standard input:9:1: Unbound variable: test-proc
ABORT: (unbound-variable)
guile>


Here is a session with gauche, which gets this right:

gosh> (define-module test
  (export test-macro)
  (define (test-proc x) (write x) (newline))
  (define-syntax test-macro (syntax-rules () ((test-macro x) (test-proc (* x x))))))
gosh> (import test)
#<undef>
gosh> test-macro
#<macro test-macro>
gosh> (test-macro 5)
25
#<undef>
gosh>

Andreas Rottmann <rottmann>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by civodul (Posted a comment)
  • -email is unavailable- added by ossau (Posted a comment)
  • -email is unavailable- added by rottmann (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-20 civodul Open/ClosedOpen Closed
    2007-10-31 ossau StatusNone Invalid
    2007-08-31 rottmann Carbon-Copy- Added rottmann

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code