Re: SRFI package for guile, rscheme, and maybe stalin (minor questions).

[Rob Browning <rlb at cs dot utexas dot edu>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> Therefore, I think the right approach to the extension in SRFI-1 is
> to let the core primitive be restricted to R5RS behaviour,
> reimplement the primitive in the list library, and let the new
> primitive shadow the original when the user uses the list library
> module.

I had only thought that perhaps srfi-0 (i.e. cond-expand) could be put
in the core (because otherwise there's a bootstrapping problem).  Once
you know you have cond-expand, you can use it elsewhere to determine
when a given srfi is available (among other things).  At the moment
I've got it so that the srfi's that I've added to guile are accessed
as modules via "(use-module (srfi srfi-1))"

Now I'm not saying that the rest of the guile core code should be
allowed to use the srfi's, but that from the user's perspective,
having cond-expand at startup would probably be useful.

As an example of use:

  ;; If we're in guile, use srfi-1
  (cond-expand
    (guile (use-modules (srfi srfi-1)))
    (else))

  ...

  ;; Trivial, but you get the point...
  (cond-expand
    (srfi-1 (define my-xcons xcons))
    (else (define (my-xcons a b) (cons b a))))

For the most part, my current srfi code uses cond-expand to handle the
rscheme/guile/whatever specific bits, and the rest is common.

The only drawback to cond-expand is that it only specifies that it'll
work at the top-level.  I can understand why this was done, but it
somewhat weakens it.

In any case, I didn't know whether or not top-level meant that only
one or both of these constructs would be OK:

  (cond-expand
    (guile something)
    (else))

  (let ()
    (something)

    (cond-expand
      (guile (foo 4))
      (else 5)))

I suspected that the second would also be considered top-level, but I
wasn't sure.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930