|
![](/i/fill.gif) |
Darren New wrote:
> Invisible wrote:
>> I have absolutely *no clue* what the hell any of that means. But try
>> it yourself here:
>
> That makes sense except to the extent that I don't know what LIFT{[]}
> means.
>
>> Indeed, all Haskell types are ADTs. Except things like integers,
>> arguably. OTOH, you could claim that Integer is defined as
>>
>> data Integer = 1 | 2 | 3 | 4 | ...
>
> An abstract data type has to define the operators also.
Yeah, I was talking about *algebraic* data type when I said "all Haskell
types are ADTs". ;-)
>> As for "like say a stack", I'm not really sure what you mean.
>
> Well, an ADT has to define the type in terms of the operations on that
> type, not in terms of a list of values/literals.
I think we're still talking about two different meanings of ADT. ;-)
> In other words, for an ADT, there is no indication at all of the
> representation of values. The value of the stack with 1, 2, and 3 pushed
> is actually
> push(push(push(new,1),2),3)
> and not some list expression. *That* is an ADT.
>
> The advantage is that you can prove things about the behavior without
> understanding what it's "supposed" to do. For example, you can see it's
> impossible to pop an empty stack, or to look at the top element of an
> empty stack, because there's no matching expression for top(new). You
> can also do things like prove you've covered all the possibilities,
> prove that one ADT is a superset of another, and so on.
I always wandered what a abstract data type actually is...
The Eiffel guy had a chapter implementing a stack and "proving" that it
matches the spec. (He attempted to claim that the code *is* the spec.) I
think he was trying to counter the old "there is no mathematical theory
to OOP".
At the time, I believed him. Having seen Haskell, and its evil twin the
Lambda Calculus, I now understand what they mean by "no theory of OOP"...!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |