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

Re: [r6rs-discuss] [Scheme-reports] Scheme pattern matching: the case for (case)

Three hours ago, John Cowan wrote:
> [...] Consider this:
>         (define cdr #f)
>         (length '(a b c))
> [...]
> The problem's a mess.

Yes, it is a huge wart IMO, one that requires that exception that
Andre pointed at and a distinction between "built-ins" and library.
That distinction forces the above to work, but that's little comfort
for any piece of code that I write, since that disguised assignment
can break my code completely (unless I invent my own module system,
and avoid relying on anything but the standard core...).  A module
system is a much better solution that keeps things sane without
resorting to such special cases.

Two hours ago, Andre van Tonder wrote:
> On Wed, 22 Dec 2010, Eli Barzilay wrote:
> > An hour ago, Peter Kourzanov wrote:
> >> And now do:
> >>
> >> (define eqv? equal?)
> >> (newline)
> >> (write (case "asd" (("asd") #t)))
> >> (newline)
> >>
> >> You'll find Tinyscheme, Minischeme, MIT, Scheme48/SCSH included in
> >> your list. Ypsilon and Stalin exhibit this behaviour for strings,
> >> but not for more structured data like vectors.
> >
> > This is a *very* different issue -- R5RS systems make it a core
> > feature that you can change builtin functions like that, with all
> > references to them changing too.
> No, it doesn't.  R5RS forbids this, so the above systems are not
> even R5RS compliant.

The feature is being able to mutate bindings in general, and it's
(some) R5RS *systems* that make it into a core aspect of the language
they define.

Two hours ago, Peter Kourzanov wrote:
> On Wed, 2010-12-22 at 15:55 -0500, Andre van Tonder wrote:
> > R5RS chapter 6 intro:
> > 
> > A program may use a top-level definition to bind any variable. It
> > may subsequently alter any such binding by an assignment (see
> > 4.1.6). These operations DO NOT MODIFY the behavior of Scheme's
> > built-in procedures.
> But, in R6RS they are in the base library and no longer built-in. 

R6RS doesn't need this exception:

  All explicitly exported variables are immutable in both the
  exporting and importing libraries. It is thus a syntax violation if
  an explicitly exported variable appears on the left-hand side of a
  set! expression, either in the exporting or importing libraries.

          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

r6rs-discuss mailing list