Ketil Malde writes:

In Haskell, I often need to add stubs of "undefined" in order to do this. I don't mind, since it is often very useful to say *something* about the particular piece - e.g. I add the type signature, establishing the shape of the missing piece without bothering with the actual implementation just yet.

Seconded. Sometimes I wish for a -fphp flag that would turn some type errors into warnings. Example: v.hs:8:6: Couldn't match expected type `[a]' against inferred type `()' In the first argument of `a', namely `y' In the expression: a y In the definition of `c': c = a y GHC could substitute 'y = error "Couldn't match expected type `[a]' against inferred type `()'"' and compile anyway. Would that bring Haskell closer to Python? -- Gracjan

On Apr 28, 2011 9:25 AM, "Ertugrul Soeylemez" wrote:

...

Sometimes I wish for a -fphp flag that would turn some type errors into warnings. Example:

v.hs:8:6: Couldn't match expected type `[a]' against inferred type `()' In the first argument of `a', namely `y' In the expression: a y In the definition of `c': c = a y

GHC could substitute 'y = error "Couldn't match expected type `[a]' against inferred type `()'"' and compile anyway.

Would that bring Haskell closer to Python?

It would make people abuse that feature. I don't want it.

I do, particularly in GHCi. I don't mind if Haskell refuses to build a binary, but having to comment out coded in order to load bits in GHCi is definitely a pain. -- Chris Smith

On Apr 28, 2011, at 11:27 AM, Ertugrul Soeylemez wrote:

Gracjan Polak wrote:

...

Ketil Malde writes:

...

In Haskell, I often need to add stubs of "undefined" in order to do this. I don't mind, since it is often very useful to say *something* about the particular piece - e.g. I add the type signature, establishing the shape of the missing piece without bothering with the actual implementation just yet.

Seconded.

I don't see any problem with this. Although I usually have a bottom- up approach, so I don't do this too often, it doesn't hurt, when I have to.

Agreed - in fact, I have always thought of this style of coding as one of the truly great things about Haskell, and was surprised to see it presented as a negative. The idea of that being a burden had never even entered my mind. The fact that I can say "foo = undefined" and go about my business as if foo were, in fact, an existing component, is nice. But as you point out, that can be done in pretty much any dynamically typed language just as trivially. The truly great thing about it is that I can also say "foo :: (Bar a, Num b) => a -> b -> (qux -> m baz) -> f m (x, Either q g)", etc., and the compiler can then tell me when I misuse this *entirely fictitious* entity. Or, when I'm done writing my code that uses foo, I can say "foo :: ()" and let the compiler errors tell me what sort of a creature I have asked "foo" to be. Or, I can just start coding "foo" and let the compiler tell me whether what I do is consistent with how I've used it elsewhere.

...

Sometimes I wish for a -fphp flag that would turn some type errors into warnings. Example:

v.hs:8:6: Couldn't match expected type `[a]' against inferred type `()' In the first argument of `a', namely `y' In the expression: a y In the definition of `c': c = a y

GHC could substitute 'y = error "Couldn't match expected type `[a]' against inferred type `()'"' and compile anyway.

Would that bring Haskell closer to Python?

It would make people abuse that feature. I don't want it. Haskell is so difficult to abuse compared to other languages, and I'd like to keep it that way.

Maybe, but it should be easy to make sure that you aren't using any code that abuses it; just make sure you compile all your stuff with that flag explicitly turned off - any code that "abuses" it would simply fail to build. I'd expect to be able to do that by setting "- fno-php" as a global ghc-option in the cabal config file. I'd probably also advocate making that flag switch type errors to non- suppressible warnings (that is, do not provide any way whatsoever in the compiler to make those warnings silent). On a related note, I think that this sort of a feature would not really get at the usual objection about strong static typing incorrectly rejecting valid programs. All this does is change it so that such programs are, instead of being rejected, altered to throw runtime errors in cases that could actually have worked but the type system was not expressive enough to prove. It would give what I think of as the worst of both worlds: Programs that can never work would be allowed to slip past the compiler, and programs that could work if the type system were smarter still won't work. I think the proper thing to do would be to translate such code into code that uses Dynamic, or more likely some generalization of it. It would require some serious thought about how to deal with polymorphic types, and especially ones that involve type classes. All in all, it seems to me that a full correct implementation of such a system would essentially amount to embedding a full Haskell interpreter in the compiled executable. Done right, though, it could be a pretty nice feature. If nothing else, it would let you experiment extensively in a nice safe little sandbox to gain confidence in your dangerous untypeable code before you "take the plunge" and use unsafeCoerce. -- James

...

This completely misses what laziness gives Haskell – it gives a way of completing a smaller number of computations than it otherwise would have to at run time. (...) Tony Morris continues the ping-pong: This is not what laziness gives us. Rather, it gives us terminating

Thomas Davie wrote: programs that would otherwise not terminate. Next, please...

You know, this suggests that you should read the parable of Blind Men and the Elephant. Alright, my turn. I never wanted to write non-terminating programs (what for?), and all my programs executed exactly those instructions they should have executed, not more or less. I see ONE usage of laziness: the possibility to write co-recursive equations, which become algorithms. The possibility to represent processes as "data", which makes it easier to reason upon them. Do we really need some dogmatic specification of laziness?... Jerzy Karczmarczuk

Alexander Solla comments my comment :

Alright, my turn. I never wanted to write non-terminating programs (what for?),

Daemons/servers/console interfaces/streaming clients?

Come on, not THIS kind of non-termination. This has little to do with strictness/laziness, I think. Endless loops can be coded in various ways...

I see ONE usage of laziness: the possibility to write co-recursive equations, which become algorithms

What about "infinite" lists? There is no need for mutually recursive functions to see the usefulness of a list which never ends, and is computed to the length that your algorithm /acutally/ requires.

This is almost EXACTLY what I meant. When I say "co-recursive", I do not mean "mutually recursive". Rather the extrapolating recursion, not necessarily "terminating" (lacking the base clause) but finitely progressing, such as the standard definition of the stream of integers, used to scare the beginners... ints = 1 : zipWith (+) (fix (1:)) ints where fix f = f (fix f) Thanks. Jerzy Karczmarczuk

On 11-04-27 05:44 PM, serialhex wrote:

in ruby they use what some call "duck typing" if it looks like a duck and quacks like a duck... it's a duck.

Python and Javascript also do duck typing. Haskell does Functor typing. A Functor is something that provides an "fmap" method. List does it, so you can do fmap not [True,False] Maybe also does it, so you can also do fmap not (Just False) Your own data type could also do it. Suppose your data type is (binary tree) data BT a = Z | Y a (BT a) (BT a) deriving Show then you add instance Functor BT where fmap f Z = Z fmap f (Y x t0 t1) = Y (f x) (fmap f t0) (fmap f t1) then BT provides an "fmap" method too, and so you can also do fmap not (Y True (Y False Z Z) Z) If it fmaps like a Functor, it is a Functor. That is Functor typing.

2011/4/27 MigMit :

It would be, if only it checked the (necessary) types during compile time. As it is now, it seems like a claim that C is lazy just because any pointer can be null.

Strictness analysis is only an optimization, you don't need it to be lazy in the term-level. However Python does check the kinds, the types of the types, at compile-time. Everything is *. ;-) Cheers, -- Felipe.

On Thu, Apr 28, 2011 at 11:38 PM, Ben Lippmeier wrote:

On 27/04/2011, at 7:30 PM, Henning Thielemann wrote:

...

"If Haskell is great because of its laziness, then Python must be even greater, since it is lazy at the type level."

Laziness at the value level causes space leaks, and laziness at the type level causes mind leaks. Neither are much fun.

If the designers could find a way to support laziness at the programmer

level I for one would be very grateful. -G

On 29 Apr 2011, at 05:38, Ben Lippmeier wrote:

Laziness at the value level causes space leaks,

This is well-worn folklore, but a bit misleading. Most of my recent space leaks have been caused by excessive strictness. Space leaks occur in all kinds of programs and languages, and I am not convinced there is a strong correlation between laziness and leakiness. If anything, I think there is observation bias: lazy programmers have good tools for identifying, finding, and removing leaks. Others do not. Regards, Malcolm

On 29 Apr 2011, at 10:42, Ben Lippmeier wrote:

On 29/04/2011, at 6:08 PM, Malcolm Wallace wrote:

...

On 29 Apr 2011, at 05:38, Ben Lippmeier wrote:

...

Laziness at the value level causes space leaks,

This is well-worn folklore, but a bit misleading.

:-) Like permanent markers in the hands of children causes suffering. It's not a tautology, but an overgeneralisation that holds more often than not.

I completely disagree, like Malcolm Wallace, space leaks in my code have *more often* been to do with being too strict than being too non-strict. Bob