4 ms·

It's not so simple in my mind. Sure it sounds good on paper to just throw out laziness and go strict by default, until you realize how much you are giving up b

It's not so simple in my mind. Sure it sounds good on paper to just throw out laziness and go strict by default, until you realize how much you are giving up by not having laziness the default. My difficulty with Haskell was not that it was lazy, but that it was hard to tell how something would be evaluated without understanding it's entire evaluation model. I think you could have a lazy by default language that makes this a lot more transparent but I'm still thinking about how that might look.

nerdponx 8y ago
Are you familiar with Python's approach to iteration? Obviously Python itself is a world away from Haskell, but its model of lazy and eager iteration is very pleasant to work with, and with Haskell-style typeclasses it would be dead-simple.
- nightski 8y ago
  Absolutely, along with .NET's IEnumerable/LINQ. Laziness is definitely possible in a strict language via thunks (similar to how Haskell does it behind the scenes). However I didn't realize what laziness by default makes possible until I spent considerable time in the Haskell ecosystem. It really is a game changer.
- lmm 8y ago
  > Are you familiar with Python's approach to iteration? Obviously Python itself is a world away from Haskell, but its model of lazy and eager iteration is very pleasant to work with That isn't my experience. As soon as you're in a chain of transformations you have no idea what's lazy or strict.
  - nerdponx 8y ago
    This is true, but I don't often see people writing code like this in the wild. That's what I mean about it being actually easy with static typing -- you can have the compiler and/or your IDE check for you whether it's a lazy sequence (like a Generator in Python) or not (like a Set, List, etc).
    - lmm 8y ago
      Most of the time it would be polymorphic over whether the sequence is lazy though. And the kind of code that wouldn't behave properly with a lazy sequence tends not to be detectable statically; you could maybe rely on types to convey whether the author intended their code to work on lazy sequences, but realistically that probably wouldn't help you much.
      - nerdponx 8y ago
        Wouldn't the return value of the previous function in the chain make it obvious? E.g. in Python you can have def foo() -> Generator def bar(x: Iterable) -> Sequence def baz(y: Sequence) -> List lst = baz(bar(foo())) It's obvious to an experienced Python user (and to a static type checker) what is lazy here. All you need now is a compiler to enforce it.
        lmm 8y ago
        You don't necessarily know which functions are going to be chained together though. If I write (my Python's a bit rusty): def f(x): return map(someOtherFunction, map(someFunction, x)) how can I know whether someOtherFunction interferes with someFunction if they run at the same time? The only way to know whether the maps are strict or lazy is knowing what x is, but x might come from some a different file or a different project even, so there's no way to know whether this function only works (and is only expected to work) for strict x or not. Actually even knowing what x is isn't enough, because even if x is strict, f can end up being called in a lazy way if I later do: (y for x in someGeneratorThatGeneratesLists for y in f(x))
        nerdponx 8y ago
        That's my point about a static type system. You don't have that problem if types are known at compile time. I agree that it's a nuisance in Python as-is (but I still like it overall).
        8y ago

nerdponx 8y ago

Are you familiar with Python's approach to iteration? Obviously Python itself is a world away from Haskell, but its model of lazy and eager iteration is very pleasant to work with, and with Haskell-style typeclasses it would be dead-simple.

nightski 8y ago
Absolutely, along with .NET's IEnumerable/LINQ. Laziness is definitely possible in a strict language via thunks (similar to how Haskell does it behind the scenes). However I didn't realize what laziness by default makes possible until I spent considerable time in the Haskell ecosystem. It really is a game changer.
lmm 8y ago
> Are you familiar with Python's approach to iteration? Obviously Python itself is a world away from Haskell, but its model of lazy and eager iteration is very pleasant to work with That isn't my experience. As soon as you're in a chain of transformations you have no idea what's lazy or strict.
- nerdponx 8y ago
  This is true, but I don't often see people writing code like this in the wild. That's what I mean about it being actually easy with static typing -- you can have the compiler and/or your IDE check for you whether it's a lazy sequence (like a Generator in Python) or not (like a Set, List, etc).
  - lmm 8y ago
    Most of the time it would be polymorphic over whether the sequence is lazy though. And the kind of code that wouldn't behave properly with a lazy sequence tends not to be detectable statically; you could maybe rely on types to convey whether the author intended their code to work on lazy sequences, but realistically that probably wouldn't help you much.
    - nerdponx 8y ago
      Wouldn't the return value of the previous function in the chain make it obvious? E.g. in Python you can have def foo() -> Generator def bar(x: Iterable) -> Sequence def baz(y: Sequence) -> List lst = baz(bar(foo())) It's obvious to an experienced Python user (and to a static type checker) what is lazy here. All you need now is a compiler to enforce it.
      - lmm 8y ago
        You don't necessarily know which functions are going to be chained together though. If I write (my Python's a bit rusty): def f(x): return map(someOtherFunction, map(someFunction, x)) how can I know whether someOtherFunction interferes with someFunction if they run at the same time? The only way to know whether the maps are strict or lazy is knowing what x is, but x might come from some a different file or a different project even, so there's no way to know whether this function only works (and is only expected to work) for strict x or not. Actually even knowing what x is isn't enough, because even if x is strict, f can end up being called in a lazy way if I later do: (y for x in someGeneratorThatGeneratesLists for y in f(x))
        nerdponx 8y ago
        That's my point about a static type system. You don't have that problem if types are known at compile time. I agree that it's a nuisance in Python as-is (but I still like it overall).
        8y ago