I think you may have glossed over that paper I linked.
No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. I am not aware of any such language. According to Wikipedia, Miranda and Clean are also non-strict but they are also purely functional.
Haskell allows you to create non-strict impure code using functions like unsafeInterleaveIO, this is generally regarded as a bad idea for technical reasons except in very special cases. See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees.
In short, a function which does not terminate is said to return ⊥ from a semantic perspective. The monotonicity of Haskell functions is what makes this work as you'd expect without violating purity, since ⊥ is the least element.
> I think you may have glossed over that paper I linked.
I've read it before, and not precisely yesterday or today.
> No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects.
Sure, such a language wouldn't be very usable, but it's very much definable.
> See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees.
You don't need to convince me that lazy I/O is a bad idea. If it were up to me, the type of a lazy stream would be:
data Stream m a = Nil | Cons a (m (Stream m a))
Where m is Identity when you have a strict (and guaranteed finite!) list. Of course, laziness is a monadic effect just like any other.
> On your second point, nontermination is treated semantically as a value in Haskell.
Nothing is a value in Haskell. (If you work out the operational semantics of a non-strict language, you'll see that you don't need to “carve out” a subset of terms that must be considered “values”, unlike the case for a strict language.) All you have is computations, some terminating, some not.
These comments seem to be redefining words each time they are used. A parent comment refers to "value-level code" in Haskell and now this comment says that "nothing is a value in Haskell". This seems to be contradictory.
It's hard to come to any other conclusion here—other than the conclusion that the author of these comments wishes to argue rather than discuss.
There's a lot to learn from the Haskell community if you're willing. For example, there's probably about two decades of work that's been done past the definition of lazy streams which you provide. Conduit, iteratee, pipes, etc. Really cool stuff with stream fusion rules and bounded resource usage.
No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. I am not aware of any such language. According to Wikipedia, Miranda and Clean are also non-strict but they are also purely functional.
https://en.wikipedia.org/wiki/Strict_programming_language
Haskell allows you to create non-strict impure code using functions like unsafeInterleaveIO, this is generally regarded as a bad idea for technical reasons except in very special cases. See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees.
http://stackoverflow.com/questions/5892653/whats-so-bad-abou...
On your second point, nontermination is treated semantically as a value in Haskell. It is an error to consider nontermination an "effect". See:
https://en.wikibooks.org/wiki/Haskell/Denotational_semantics
In short, a function which does not terminate is said to return ⊥ from a semantic perspective. The monotonicity of Haskell functions is what makes this work as you'd expect without violating purity, since ⊥ is the least element.