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

[David Leimbach]

On Tue, Nov 3, 2009 at 10:44 PM, Ben Lippmeier <Ben.Lippmeier at anu.edu.au>wrote:

> David Leimbach wrote:
>
>> I have to admit, the first time I hit the wiki page for DDC I said to
>> myself "Self, this sounds crazy complicated".  Then I read part of the PDF
>> (your thesis I believe) about Region Types on the bus ride to work and
>> thought.  "Gee I think I scared myself off too quickly".
>>
>> Uniqueness typing is quite interesting in Clean, but to control aliasing,
>> like really *control* aliasing, that's just far out man.
>>
>> So I still have to wrap my head around "why this isn't going to get
>> completely out of control" and see why it's all safer than just writing C
>> code but I must say the attention I will be paying to DDC has just gone
>> quite a bit up.
>>
>
> :) A correct C program is just as safe as a correct Haskell/Disciple
> program.
>

Well, of course, the question is in what sort of guarantees a language or
compiler provides I guess.



>
> If you're using destructive update then aliasing, side effects and
> mutability all start to matter. It might look complicated when you reflect
> all these things in the type system, but you're really just getting a handle
> on the inherent complications of the underlying program.
>

So it's just really more notation to let you know which tools are being used
when you use them?

Does Disciple completely avoid the need for such things as unsafePerformIO?

(a perhaps overly paranoid comment but...)
I realize we're probably not supposed to worry about the existence of
unsafePerformIO, and that library authors "know what they're doing".  But
doesn't it automatically mean that there's a bit of implicit trust whenever
I see a function that's  of type (a -> a) that there *isn't* IO going on in
there? :-)

If Disciple can guarantee that no one is allowed to cheat, is that not a
better approach?


> I suppose the trick is to be able to ignore said complications when you
> just don't care, or they're not relevant for your particular problem...
>

Yes, the Disciple documentation says that this stuff can be inferred, but I
don't even let Haskell infer my types for *any* functions I write in any
code.  I like to restrict what can go in and out of the function even if
it's more general.  Perhaps this is the knee-jerk reaction of an angry
Erlang programmer who really wanted some types to reign in the
overly-dynamic evaluations that are allowed in that environment, but that's
how I roll baby!  I will admit that on occasion I will write and expression
that I think does what I want, and look at in in ghci, having it tell me the
type because sometimes I've not had enough coffee to do it in my head, but I
either look at the inferred type and realize that it's what I originally
wanted, or add further restrictions.

Dave


>
> Ben.
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20091104/967ad9ee/attachment.html