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

Re: [Scheme-reports] R7RS-large library declarations

Peter Bex scripsit:

> > I also spell out that it is not an error (though it is in Chibi) to
> > provide a library declaration that the implementation does not understand.
> If these are accepted, there should be at least a warning, to prevent
> confusion in the case of typos and misunderstandings by the user.


> These optimization hints aren't user-defined either, so I'm not sure I
> follow your line of reasoning.  If an implementation provides a SRFI-0
> feature that's the name of the implementation this will be easy of
> course.

I'm still not following you.  As I see it, a cond-expand feature is the
implementation telling you what it can do, whereas these declarations
are you telling the implementation what it should do.  Can you explain
how these purposes can be neatly conflated?

> IIRC in Scheme48 a module can specify it requires an interface, which
> can then be put together by the user with another module that provides
> said interface.  In Chicken they are primarily designed for use in
> combination with functors, which are higher-order modules.  A functor
> can specify it requires a particular interface to be available.  Then
> it can be instantiated when provided with an implementation of this
> interface.  These are the kinds of abstraction features I was talking
> about.

Yes, I see the issue.  I have moved interfaces into their own page,
InterfacesCowan, and have repurposed the "undefined" declaration into the
library declaration "require-interface", which accepts interface names.
It is required to muffle warnings about undefined names when the module
is processed in isolation, and that's all, though it can have a much
more sophisticated implementation.

One art / There is                      John Cowan <cowan@x>
No less / No more                       http://www.ccil.org/~cowan
All things / To do
With sparks / Galore                     --Douglas Hofstadter

Scheme-reports mailing list