Alan Watson wrote:
> Let me see if I have this straight.
>
> With the R5RS we could redefine standard procedures but we did not have
> a standard way to signal an error.
>
> With the R6RS we now have a standard way to signal an error but we no
> longer have a standard way to redefine standard procedures.
Was there ever "a standard way to redefine standard procedures"? The
equivocation in R5RS section 6, "Standard procedures", is not promising
in this respect.
Note that in the R6RS, library features can be used to rename standard
procedures and provide your own definitions for the original names. Such
a redefinition can be packaged as a library for easy import by other
libraries (this relates to Will's points about parameterization).
So afaict, when it comes to a *standard* way to redefine standard
procedures, i.e. one that is required of conforming implementations, the
R5RS offers nothing, whereas the R6RS offers a precise, unambiguous
capability.
> Was irony really one of the guiding principles of the R6RS or is this
> just one of those happy coincidences of history?
Irony is inherent in the design of programming languages. Heisenberg's
uncertainty principle applied to programming language design says that
the more carefully you specify a feature, the less it resembles what you
were originally trying to achieve.
Anton
Received on Sat Jun 23 2007 - 09:53:26 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC