On Mar 3, 2009, at 5:17 PM, Felix Klock's PLT scheme proxy wrote: > In general, the designer of an abstract data type wants to only > provide an abstract view of that type.
Late to the game and it's a philosophical answer, too. Over years of Scheme programming I came to the conclusion that this desire is ideologically misguided for a language without types. Types -- in Reynolds's words -- are enforcing syntactic barriers of abstraction. In a world of types, it is therefore natural to wish to present an _abstract type_ as something the client side cannot see. (How about the server side, btw?) Because the barrier is only syntactic, a concrete view of the elements of an abstract type would actually allow us to fake them at run-time. (Example: abstype t = ... : if I print these things concretely as 1 2 3 I can use a 1 or a 2 as t and float it from a (badly typed part of the system) into the abstype region and possibly destroy invariants.) Untyped languages don't support abstract types. They support dynamic protection of invariants (see Robby and Wadler's and Jacob's paper). So it's perfectly okay to show clients how a bag is represented: as (make-bag (list (list 'a 2) (list 'b 1))) or (make-bag (list 'a 'a 'b)). They can't fake it because bag is generative. In short you have fallen prey to the ideological preaching of Typed people. Of course, I realize that you wish to make a point to your students so I also understand why having an appropriate print style around is useful. You are turning the "TeachScheme" language into something students might encounter once they move into types. -- Matthias
