Fwd: [Haskell-cafe] What's the deal with Clean?

The code executed by uniqueness types is somehow similar to the internal
code executed in a state monad (or in the case of IO, the IO monad). The
main difference is that the pairs of results (state, value) are explicitly
written in Clean by the programmer and the type sytem assures that the
order of executions makes sense at compile time, whereas in the case of the
state monad the sequence of instructions is lazily assembled at runtime in
the first step and executed in a second step. So there is a little more
overhead in haskell but the code is higher level.
Am I right?
2009/11/4 wren ng thornton
Stephen Tetley wrote:
2009/11/3 Andrew Coppin
: As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean
is notionally very similar to Haskell, but with lots of added clutter, complexity and general ugliness - but it's probably somehow more machine-efficient as a result.
(All of which makes the name "Clean" rather ironic, IMHO.)
OUuch - you really could put it the other way round.
Part of this really comes down to how one feels about the monads vs uniqueness types argument. It's a silly argument to have since the ideas are orthogonal and only really intersect at IO, but there's history there which lead to the current state of things.
Sometimes in Haskell I've thought about how uniqueness typing would make something faster, but in general all the plumbing associated with it in Clean makes me feel like I'm writing systems-level code (i.e. C, asm) instead of using a high-level language. The extra plumbing really makes it feel dirtier to work with. That doesn't mean Clean is bad, but I think it does contribute to the "cluttered" feeling Haskellers get.
But as I said, it's a silly argument and folks should use whichever gives them warm fuzzies. I also have a vague unnameable distaste whenever working with Python, and rather enjoy working with Perl. Nobody's perfect :)
-- Live well, ~wren
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hello,
2009/11/4 Alberto G. Corona
The code executed by uniqueness types is somehow similar to the internal code executed in a state monad (or in the case of IO, the IO monad). The main difference is that the pairs of results (state, value) are explicitly written in Clean by the programmer and the type sytem assures that the order of executions makes sense at compile time, whereas in the case of the state monad the sequence of instructions is lazily assembled at runtime in the first step and executed in a second step. So there is a little more overhead in haskell but the code is higher level. Am I right?
I would rather say: code with uniqueness types allows for safe destructive updates. In Clean, a variable of unique type is ensured to have only one reference to it, at any time (that's why it's called "uniqueness typing"). So you can't write the code like this
f(x) + f(x)
where f : *a -> int (x is of unique type), because x is clearly referenced two times here. What to do? Let f yield another reference to x! That also means that the old reference is not usable any more, since you have new one. f becomes:
f : *a -> (int, *a)
and the code looks very familiar:
let (a, x') = f(x) (b, x'') = f(x') in a + b
The function f can use destructive updates under the hood though it doesn't violate referential transparency. I bet you can you see why. I'd say that call-by-need is orthogonal to uniqueness typing. Cheers, Artyom Shalkhakov.
participants (2)
-
Alberto G. Corona
-
Artyom Shalkhakov