Warp wrote:

>   You are telling me you can create very memory-efficient programs in
> haskell without resorting to ugly low-level hacks?
>   That seems to be contradictory to what I remember you saying about
> those ugly arrays which can be modified in-place and such.

Accessing an array is no more ugly than accessing a file. (After all, 
what is a file anyway? It's a named array of bytes!) You have to use a 
monad, which makes things a bit more wordy, but that's about it.

(As I have noted before, the various array libraries are currently a 
little incomplete though...)

>   In C++ you can often make it so that the objects require as much
> memory as the contents of the object (eg. 4 bytes) times the number
> of objects (plus a few additional bytes for book-keeping). So for
> example one million of such objects could require only 4 million bytes
> (plus a few bytes more). And this still while keeping the abstraction
> of these objects: You still don't need to know what these objects look
> in the inside. The inside of the objects doesn't need to be exposed.

Short answer: Haskell can do this. But the current level of library 
support is... somewhat lacking.

[I particularly like that way that if I make an array of 4 million 
Boolean values, each one takes up exactly 1 *bit* of RAM. And yet, the 
interface is identical to any other kind of array...]

>   I don't have the slightest idea how all this works in Haskell, though.
> Being a functional language it probably doesn't even have the concept of
> "module", nor the concept of "object". Can you create "concepts" (such
> as "a pixel") at all? Can you instantiate these "concepts" (and, for
> example, put them inside diverse types of data containers)? Does it have
> the concept of "abstraction" and "public interface" which hides
> implementation details?
> 
>   If I'm not completely mistaken, in Haskell you can probably define
> things like "a pixel consists of these four elements". However, that
> already exposes the internal structure of a "pixel".

Here's the Haskell way:

Haskell has "modules". The module is the unit of abstraction in Haskell. 
When you write a module, you can define precisely what parts of it are 
visible from the outside, and which parts aren't.

Most particularly, you can make a type visible without making its 
structure visible. So you could define a Pixel type (and some functions 
for creating and manipulating Pixel values), and export the type name 
only (and the functions for working on it).

You now have a situation not disimilar to a class in Java: Only the code 
in this module knows the true implementation of Pixel. If you change 
that implementation, you'll have to change the rest of the module too, 
but any client modules will be unaffected.

So, really, it's not so different. And indeed, the standard libraries 
provide examples. There is a standard library named "Data.Set". It 
provides a type called "Set". There is a constant named "empty" which 
contains an empty set. There is a function called "insert" which takes a 
set and an item and returns a set containing that item. And so forth. 
Now, I'm *told* it's implemented with some kind of balanced tree 
algorithm, but I don't actually know. Or care. And if it changes in the 
next release of the libraries, it won't matter.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message