[plt-dev] overriding constructor style printing

Matthias-

On Mar 6, 2009, at 3:24 AM, Matthias Felleisen wrote:

> 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?)

On this "server side" point, CLU had explicit operations to convert a  
concrete representation into the sealed abstraction that a  
"cluster" (module) would export to the outside world.  I'm not sure if  
that's the sort of thing you're thinking of in your musing above though.

> 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.

Hmm.  I do not really agree that I've fallen prey to the ideological  
preaching of that community.  (I will admit that long ago I fell prey  
to the ideological preaching of Liskov and Guttag, and you might  
consider them part of the "Typed" clan; so maybe I am wrong to  
disagree with your claim about to whom I have fallen prey.)

This is not about preventing rep exposure to enforce the invariants of  
my module (a standard topic in discussions of abstract types).  My  
goal (while implementing the constructor style printing aspect of this  
library) is to help my audience *see* and manipulate the abstraction  
being represented, rather than spitting out the underlying  
representation and forcing them to apply an appropriate abstraction  
function ("interpretation") in their heads.

Overriding the constructor-style printing here is about increasing the  
usability of these abstract bags, because it:

   1. Provides an immediate hint towards a "constructor" (or pseudo- 
constructor); in this case, the function most relevant for  
constructing such objects, and

   2. Hides the irrelevant details of the representation that could  
confuse a student who is not familiar with how to map concrete data to  
abstract information. (If you show them the underlying lists of the  
representation, it distracts from the essential point that element  
order does not matter for these objects, which makes them special and  
very different from what they've seen before.  Worse, it may lead them  
to think that in lists as well the order does not matter, and their  
heads explode.)

----

Perhaps my choice of terminology was poor (even though I consider it  
standard, even in the dynamic language community).  How about: "In  
general, the designer of an abstract class of data wants to only  
provide an abstract view of that class."  Do you object to that  
statement as well?  What is wrong with desiring to hide internal  
details of my library?

----

> 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.

I cannot tell if this paragraph is your way of predicting my response  
above and warding it off ahead of time; so I am including the response  
nonetheless.  :)

I also cannot tell which particular "something" that the students  
might encounter you are referring to above.  (Multisets?  Abstract  
data types?  Information with more than one possible representation?)

-Felix