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

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

Maciej Stachowiak <mstachow@alum.mit.edu> writes:

> for instance, SRFI-1 (the list library) defines some procedures that
> have the same name as some in R5RS, but an extended interface (one
> example would be delete, which has an additional optional argument
> to specify the equality predicate to use). In such cases, it may be
> better to implement the extended version directly in the Guile core
> rather than using the R5RS version but overriding it in an add-on.

Generally, I think it is very important that primitives don't have
more features than the Scheme standard specifies.  It is a very
important property of Java that once you have written a program in one
implementation, you will be able to run it in another.  Certainly this
is a substantial part of Java's strength.  Similarly, if you have
written a program which works in Guile's pure R5RS module, it should
work under another R5RS-compatible implementation.

If primitives in Guile's R5RS module have extra capabilities, I know
for certain that even some of my own programs will break on other
implementations, even though I'm aware of this problem---it's simply
too easy to use some feature because you didn't remember that it isn't
a pure R5RS one, or out of laziness and then forgetting about it.

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 used this approach when extending the `set!' primitive syntax.  The
old set! still exists in eval.c so that it can be published in the
R5RS module, while the one actually visible in the current guile-user
module is implemented in evalext.c.