Re: Another macro/module question related to implementing srfis.

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Rob Browning <rlb@cs.utexas.edu> writes:

>   $ (cd build/guile && guile)
>   guile>   (begin
>       (define-module (srfi srfi-8)
>         :use-module (ice-9 slib))
>       (require (quote macro-by-example))
>       (require (quote values)))
>   standard input:4:5: In expression (require (quote macro-by-example)):
>   standard input:4:5: Unbound variable: require
>   ABORT: (misc-error)
> 
>   Type "(backtrace)" to get more information.
>   guile>
> 
> Am I doing something wrong here, or is this just a problem with the
> current implementation?

It's a bug in the module system.  The effect of `define-module' does
not take place until next form in the input (e.i. things coming after
the begin expression).

> [1] One uncomfortable problem is that cond-expand isn't specified to
> work in anything other than at the "top-level", so you can't do things
> like this:

This is probably a strength since it keeps the basic language simple.

>   (define (foo bar)
> 
>     ;; Implement fast helper functions for each implementation...
>     (cond-expand
>       (guile
>         (define (optimized-helper baz) ...))
>       (rscheme
>         (define (optimized-helper baz) ...))
>       ;; RXRS default helper
>       (else
>         (define (optimized-helper baz) ...)))
> 
>       ...)

Well, you can do

(cond-expand
  (guile
    (define (optimized-helper baz) ...))
  ...)

(define (foo bar)
 ...)

If you have problems with name space cluttering, you can use the
module system.

If you absolutely must have conditional constructs within a procedure,
you can use conditional definition of macros.

I'm sure there is a reasonable solution to most problems using the
current version of cond-expand.