[plt-scheme] immutable strings vs. uninterned symbols

Eli Barzilay writes:
 > On Jun  6, Doug Orleans wrote:
 > > Eli Barzilay writes:
 > >  > It's the concept of a different type for different uses.
 > >  > Otherwise you would feel just as well in a world that uses
 > >  > numbers/strings/church-encodings/goedel-numbers for everything.
 > > 
 > > Right, but there's more to a type than just what procedures
 > > accept/produce it.  In some ways that's the least interesting part,
 > 
 > I disagree.

So you're saying that there are no ways in which that's the least
interesting part?  Can you prove that?  :)

 > > especially if I'm going to make an abstract type on top of it, in
 > > which case none of those procedures should be used.
 > 
 > Without functions that generate object of the type, and functions that
 > work on the type, how can you use it?

What I meant was, if I'm making an abstract data type, and I'm
deciding what Scheme type to use to implement it, the user of my type
is only going to use the procedures I provide for that type, rather
than using the builtin procedures that are specific to the
implementation type.  In particular, if I choose to represent a string
type as an immutable string, an uninterned symbol, an integer, a
vector, a structure, or whatever, I will provide procedures to create
them, get the length, reference a character, etc.  But my choice of
implementation type depends much more on other properties of the type
than whether each procedure I want to provide maps to a single builtin
procedure or if I have to write my own (e.g. symbol-ref).  In
particular, the performance of my procedures will depend on the
implementation type.  Also, if I want my users to be able to use the
builtin procedures that are not type specific, such as equal? and
write, I need to know how my implementation type is handled by them.

--dougorleans at gmail.com