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