Lennart Augustsson wrote:
On the subject of type signatures, I don't want to make them mandatory, but I think they should be strongly encouraged. I don't buy the argument that they make refactoring programs that much harder. It's still very easy to do, the type checker will tell you exactly where. :)
It can still be in a LOT of places--far too many for comfort. I'm not making this up--I've experienced severe problems in practice caused by this very point. It depends what kind of code you're working with, of course. I'm not saying type signatures are ALWAYS a problem for refactoring, just that they sometimes are--and that it makes sense to leave it up the programmer whether or not to include them. By the way, you leave out a lot of type signatures too. Your Djinn module contains 29 declarations with type signatures--and 17 without. The 17 are local, but local declarations are precisely those where, without the M-R, a lack of sharing would be most likely to bite. John
John Hughes
By the way, you leave out a lot of type signatures too. Your Djinn module contains 29 declarations with type signatures--and 17 without. The 17 are local, but local declarations are precisely those where, without the M-R, a lack of sharing would be most likely to bite.
Local definitions are rarely used polymorphically. Perhaps without a type signature the definition should be polymorphic and recomputed if it's global, and monomorphic and shared if it's local. This is how it works in Clean: =: defines a shared constant, => defines a nullary function, and = is equivalent to =: locally and to => globally, irrespective of a type signature. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
John Hughes
By the way, you leave out a lot of type signatures too. Your Djinn module contains 29 declarations with type signatures--and 17 without. The 17 are local, but local declarations are precisely those where, without the M-R, a lack of sharing would be most likely to bite.
I've never been advocating type signatures on local bindings, only top level. For local bindings I sometimes do it, sometimes not. Since the scope of a local bind is, umm, local, the compiler has a much better chance of figuring out exactly what type it should have. I'm counting on the compiler to do its job here. And it seems to work. :) But I should see what happens with my code if I turn off the M-R. -- Lennart
John Hughes wrote:
Lennart Augustsson wrote:
On the subject of type signatures, I don't want to make them mandatory, but I think they should be strongly encouraged. I don't buy the argument that they make refactoring programs that much harder. It's still very easy to do, the type checker will tell you exactly where. :)
It can still be in a LOT of places--far too many for comfort. I'm not making this up--I've experienced severe problems in practice caused by this very point. It depends what kind of code you're working with, of course. I'm not saying type signatures are ALWAYS a problem for refactoring, just that they sometimes are--and that it makes sense to leave it up the programmer whether or not to include them.
So what if it's in a lot of places? The compiler tells you where to change. Each change takes a few seconds. Even with hundreds of changes you'd probably be done in under half an hour. Of course, you'd like a tool to do these kind of changes. All that said, I think not being able to give a name to a context is a real weakness in Haskell. It's one of the few things that cannot be named, and being able to do so would help refactoring and modularity. -- Lennart
On Mon, Jan 30, 2006 at 10:08:04PM -0500, Lennart Augustsson wrote:
All that said, I think not being able to give a name to a context is a real weakness in Haskell. It's one of the few things that cannot be named, and being able to do so would help refactoring and modularity.
this is one of the things my 'class aliases' proposal was meant to address (among other things). I hope to implement it for ghc, but have been busy as of late so probably won't get to it soon. John -- John Meacham - ⑆repetae.net⑆john⑈
Lennart Augustsson wrote:
All that said, I think not being able to give a name to a context is a real weakness in Haskell. It's one of the few things that cannot be named, and being able to do so would help refactoring and modularity.
definitely. Currently we have to simulate that by class ( C1 , C2 , ... ) => Context instance ( C1, C2 , .. ) => Context (is it equivalent? I hope so) but it is awkward to duplicate information like that. best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
participants (6)
-
Johannes Waldmann -
John Hughes -
John Meacham -
Lennart Augustsson -
lennart＠augustsson.net
-
Marcin 'Qrczak' Kowalczyk