On Tue, Nov 3, 2009 at 10:44 PM, Ben Lippmeier
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.