guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New command line option --use-srfi


From: Martin Grabmueller
Subject: Re: New command line option --use-srfi
Date: Tue, 22 May 2001 16:08:53 +0200 (MET DST)

> From: Rob Browning <address@hidden>
> Date: 21 May 2001 16:20:28 -0500
> 
> Martin Grabmueller <address@hidden> writes:
> 
> > 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.
> 
> Hmm.  If we really want the srfi-X features in cond-expand to be
> useful in guile, I think we'll probably have to come up with a better
> solution than this.  Otherwise it seems like there would be no point
> in using cond-expand srfi clauses for in code intended to be used with
> guile, since you're still going to have to change the way that it's
> invoked.  People trying to write portable code would be better off
> just sticking everything inside a "guile" feature check, but that
> seems kinda ugly, and won't automatically enable appropriate code
> whenever new srfis are added to guile...

You are of course correct that it's ugly, but I don't see how this can
be integrated cleanly without enabling all SRFIs by default, in any
Guile invocation.

The problem I see is: You can't use cond-expand to detect for a
specific feature like srfi-2, because it is not loaded; but you also
cannot load it before you know you're using Guile and can use
`use-modules'.

So somewhere, the user _must_ know she's working with Guile; either by
changing the way the interpreter is invoked, or by checking with
cond-expand for 'guile and then using the appropriate `use-modules'
statement.

Regards,
  'martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]