Re: New command line option --use-srfi

[Martin Grabmueller]

> From: Marius Vollmer <address@hidden>
> Date: 18 May 2001 01:18:50 +0200
> 
> Martin Grabmueller <address@hidden> writes:
> 
> > The SRFI modules are loaded, imported into the module (guile) and
> > the corresponding feature identifers are added to the feature list
> > examined by `cond-expand'.
> 
> Should the loading of the modules add to the feature list?  So that
> when I do `(use-modules (srfi srfi-XX))' manually, a subsequent
> `cond-expand' knows that SRFI-XX is available.

I thought that was a good idea, so I implemented it in my local copy.
Unfortunately, I ran into a problem.  With my simple implementation,
cond-expand and modules do no play well together.  Consider this
example:

  guile> (use-modules (srfi srfi-19))
  guile> %cond-expand-features 
  (guile r5rs srfi-0 srfi-6 srfi-8 srfi-9 srfi-19)

Here, when srfi-19 is loaded, srfis 6, 8 and 9 are also loaded and add
themselves to the %cond-expand-features list.  But, of course, they
are not used properly, so cond-expand will say that srfi-9 is
available, even though it is not:

  guile> define-record-type
  <unnamed port>: In expression define-record-type:
  <unnamed port>: Unbound variable: define-record-type
  ABORT: (unbound-variable)

A solution could be to make the feature list local to modules, and let
check cond-expand the list in the current module,but I'm not sure
whether that really works.

So (my favourite) solution is: leave it as it is, and only modify the
feature list with the --use-srfi option---unless of course, any of you
has a better one.

Regards,
  'martin