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

Re: problems with rationale & design



campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:

There seems to be two parts to the rationale:

  - SRFI 7 isn't incremental or linear, so it's not designed to work
    interactively.
  - SRFI 7 doesn't specify the precise _loading_ of features' code.

I have several problems with this.  To the first part, I really don't
see any need for standardizing interactive features.  If you're using a
specific implementation's interactor, well, you're going to be doing
stuff that's really implementation-specific anyways, and to make an
attempt to standardize all interactive Scheme features would be simply
silly.  And anyways, SRFI 7's clauses could easily be adapted to some
form of interactive declarations.


SRFI-55 is not mainly about interaction. It's one possible application,
where `require-extension' would simplify loading/importing of external
libraries (SRFIs in this case), but could be used in any other context
as well.

The second part of the rationale is more significant.  First of all,
SRFI 7 defines a language for specifying the dependencies of a Scheme
program.  SRFI 7's intent is _not_ to specify a program loader -- for
example, a SRFI 7 processor for which it would make no sense to perform
loading of necessary features might be a dependency analyzer --; but
SRFI 7 _does_ suggest that a program loader exist somewhere in a Scheme
system that purports to support SRFI 7, and a useful program loader
_would_ indeed load the necessary features.

I don't think one should make too much effort interpreting certain features
into overly vague specifications. If the author of SRFI-7 did indeed have
something like "loading" (in any possible sense) extension libraries into
the system, then he could have specified it as such. SRFI-55 specifies
what SRFI-7 only (and incompletely) hints at.

If someone wrote a SRFI 7
program loader that didn't actually load the features, why would they
write a SRFI 55 program loader that _did_?

Sorry, I don't get the point here.

(Unless that person had the
initials FLW and was the author of a Scheme->C compiler based on Henry
Baker's Cheney on the MTA garbage collection & compilation system...)

Oh, I know from good sources that this particular compiler will drop
SRFI-7 in the next release...

Furthermore, SRFI 7 even suggests that implementations that purport to
'support SRFI 7' provide a front end to their compilers or program
loaders for SRFI 7, whereas SRFI 55 doesn't even suggest that!

No, why should it? `require-extension' *is* the front end.
What are you talking about?


Now, I am also troubled by the design of SRFI 55.  It has the _exact_
same problems that Kelsey argued against in the SRFI 0 discussion list
and for which reason Kelsey 'responded' to SRFI 0 with SRFI 7!
Specifically, it is embedded in Scheme, which is utterly incompatible
with certain module system designs that cleanly separate the metadata
that the module system provides about the source and the source data
itself; in an example such module system, Scheme48's, it would require
absolute contortion to the system to make this operate correctly, and
so I can envision the Scheme48 developers to, indeed, _not_ provide a
useful program loader for SRFI 55, while it already has a useful one
for SRFI 7!

Fine. Then I suggest that the authors of Scheme48 do not
support SRFI-55. I don't have a problem with that. In fact,
I think that's one of the great properties of the SRFI system.


Now, if all you want is for SRFI 7 to specify that, if a program
loader is supported, it should try to load the necessary features, if
possible, (way too many conditional clauses there...sorry...), why
isn't this SRFI just a brief amendment to the wording of SRFI 7?

Because I find SRFI-7 incredible inconvenient and total overkill
(IMHO, AFAICT, etc. etc.).

Why do I have to learn a new language just to use `iota'? Please survey
the current Scheme implementations, you will be surprised how many
of them provide `require-extension' in one form or the other.


cheers,
felix