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