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: Rob Browning
Subject: Re: New command line option --use-srfi
Date: 15 May 2001 15:34:46 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Martin Grabmueller <address@hidden> writes:

> This was the first time I was hacking the option parsing stuff, so
> if you could have a look, feedback would be much appreciated.

ISTR some talk about eventually migrating the option processing to
scheme code.  Is there any reason this should be hard?  If not, I'm
tempted to do it.

> While implementing this, I thought about generalizing this idea to
> add a command line option for using modules.

An alternate possibility would be a general purpose command line
option, like -c, but that could be repeated multiple times, and would
allow you to do things *before* entering the repl or running a
script.  I've thought I wanted this a number of times.

It would be kind of liike perl's -e option.

  guile -x "(use-modules (foo bar))" \
        -x "(use-modules (baz bax))" \
        -x "(set! %load-path ...)" \
        -s some/file.scm

except that if you didn't specify any "terminal action", like "-s",
you would just get a repl after the "-x" items had been run:

  $ guile -x "(use-modules (foo bar))" \
          -x "(use-modules (baz bax))" \
          -x '(display "Welcome to Guile.\n")'
  Welcome to Guile.
  guile>

alternately, if people don't like the implicit repl, you could have a
bit of scheme code that would bring up the repl explicitly:

  $ guile -x "(use-modules (foo bar))" \
          -x "(use-modules (baz bax))" \
          -x '(display "Welcome to Guile.\n")' \
          -x "(run-repl)"
  Welcome to Guile.
  guile>

If people think this is a good idea, I'd be happy to see about
implementing it.

> I have not done that because I don't know whether it's useful, and
> because the SRFI stuff needs some special treatment to work with
> `cond-expand'.  A possibility would be to invent a command line
> option for using modules on startup, and let the SRFI modules
> register themselves with `cond-expand' on their own.

That's what I'd originally thought about.  I actually implemented
cond-expand (in a rather hackish way) as two modules, one that was the
public module that exported cond-expand, and another for clients of
cond-expand that needed to register further features.

Basically, there was a module (srfi srfi-0) and there was a module
(srfi srfi-0-provider).  If you were a module that wanted to provide a
feature, you'd need to use the second module and then call:

  (srfi-0-add-supported-feature! 'srfi-0)

Of course, I think I was trying to be a little too careful to hide
information.  There's no reason that srfi-0 couldn't export this
function.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930



reply via email to

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