5 ms·

I think the resource management issue is mostly solved in practice when using pure functional programming. However that comes with performance drawbacks (or at

I think the resource management issue is mostly solved in practice when using pure functional programming. However that comes with performance drawbacks (or at least unpredictable/unreliable performance) which creates the need for languages like Rust. It's great to see the progress in those languages as well.

eru 2y ago
> I think the resource management issue is mostly solved in practice when using pure functional programming. Well, in the sense that garbage collectors solve memory management. But pure functional programming in the Haskell sense doesn't really manage file handles for you, or database connections. You could have more predictable performance in Haskell, if you didn't have to deal with mandatory laziness for some functions. (Basically, in this hypothetical variant of Haskell, by default functions would be safe to be evaluated in any order, strict or lazy or whatever. If you want functions that need to be evaluated lazily, then you'd need to declare that; just like today you already need to declare that your function might have side effects.) The compiler would then be free to re-order evaluation a lot more, and pick predictable, fast performance.
- valenterry 2y ago
  > Well, in the sense that garbage collectors solve memory management. But pure functional programming in the Haskell sense doesn't really manage file handles for you, or database connections. No, I was actually talking about the latter and not about memory management at all. In Scala we even achieve this on the library level. (e.g. https://zio.dev/reference/resource/ https://zio.dev/reference/resource/ which also compares the existing problematic try/catch with its own approach) And despite Scala being strict, the GC still makes it unsuitable for many cases where you just need something like Haskell.
- mrkeen 2y ago
  > If you want functions that need to be evaluated lazily, then you'd need to declare that Not a sensible default. You cannot ask a strict function to behave lazily. But you can ask a lazy function to behave strictly.
  - throwaway17_17 2y ago
    I am unsure where the proof, or even supporting argument, would come from for such a statement. The literature is lengthy and deep, but I would sum up the current understanding and most popular argument against your stated position by citing Robert Harper (who I admit is notoriously anti-Laziness by default) in his commentary to the 2nd Edition to Practical Foundations of Programming Languages: "The problem is the very idea of a lazy language, which imposes a ruinous semantics on types. An eager semantics supports the expected semantics of types (for example, the natural numbers are the natural numbers) and, moreover, admits definition of the lazy forms of these types using suspension types (Chapter 36). A value of a suspension type is either a value of the underlying type, or a computation of such a value that may diverge. There being no representation of the eager types in a lazy language, it follows that, eager languages are strictly more expressive than lazy languages." [1] This paragraph is then followed by a link to Harper's "PCF by Value" supplement/errata to the above referenced PFPL, where such a statement is reinforced. [2] [1] - https://www.cs.cmu.edu/~rwh/pfpl/supplements/commentary.pdf https://www.cs.cmu.edu/~rwh/pfpl/supplements/commentary.pdf [2] - https://www.cs.cmu.edu/~rwh/pfpl/supplements/pcfv.pdf https://www.cs.cmu.edu/~rwh/pfpl/supplements/pcfv.pdf
    - mrkeen 2y ago
      > I am unsure where the proof, or even supporting argument You make a lazy function strict by asking for its output now rather than later. > An eager semantics supports the expected semantics of types (for example, the natural numbers are the natural numbers). What a (counter)example! In lazy semantics the natural numbers are the natural numbers. In eager semantics the natural numbers are stack overflow. > moreover, admits definition of the lazy forms of these types using suspension types This is the required modification that your library maintainer would need to make if he had produced a strict library that you wanted to use lazily. Hence "You cannot ask a strict function to behave lazily." > There being no representation of the eager types in a lazy language Because the lazy representation is the same as the eager representation in the source code. It's up to the caller to demand values now, or later, hence "But you can ask a lazy function to behave strictly."
- marcosdumay 2y ago
  > But pure functional programming in the Haskell sense doesn't really manage file handles for you, or database connections. That's what monads are for. Haskell doesn't require that you use automatic management. But it does absolutely have a solution.
  - eru 2y ago
    How are monads useful for managing file handles or database connections? You might want to look into 'indexed monads', they can perhaps help with that. But they aren't a type monads (it's the other way round, vanilla monads can be seen as a trivial kind of 'indexed monads', I guess).
    - valenterry 2y ago
      The encapsulate direct access to those resource and therefore allow a properly controlled lifecycle because usage is then local and cleanup in case of errors is automatic. The caller pretty much can't do anything wrong. No linear types or indexed monads needed actually.

eru 2y ago

> I think the resource management issue is mostly solved in practice when using pure functional programming. Well, in the sense that garbage collectors solve memory management. But pure functional programming in the Haskell sense doesn't really manage file handles for you, or database connections. You could have more predictable performance in Haskell, if you didn't have to deal with mandatory laziness for some functions. (Basically, in this hypothetical variant of Haskell, by default functions would be safe to be evaluated in any order, strict or lazy or whatever. If you want functions that need to be evaluated lazily, then you'd need to declare that; just like today you already need to declare that your function might have side effects.) The compiler would then be free to re-order evaluation a lot more, and pick predictable, fast performance.

valenterry 2y ago
> Well, in the sense that garbage collectors solve memory management. But pure functional programming in the Haskell sense doesn't really manage file handles for you, or database connections. No, I was actually talking about the latter and not about memory management at all. In Scala we even achieve this on the library level. (e.g. https://zio.dev/reference/resource/ https://zio.dev/reference/resource/ which also compares the existing problematic try/catch with its own approach) And despite Scala being strict, the GC still makes it unsuitable for many cases where you just need something like Haskell.
mrkeen 2y ago
> If you want functions that need to be evaluated lazily, then you'd need to declare that Not a sensible default. You cannot ask a strict function to behave lazily. But you can ask a lazy function to behave strictly.
- throwaway17_17 2y ago
  I am unsure where the proof, or even supporting argument, would come from for such a statement. The literature is lengthy and deep, but I would sum up the current understanding and most popular argument against your stated position by citing Robert Harper (who I admit is notoriously anti-Laziness by default) in his commentary to the 2nd Edition to Practical Foundations of Programming Languages: "The problem is the very idea of a lazy language, which imposes a ruinous semantics on types. An eager semantics supports the expected semantics of types (for example, the natural numbers are the natural numbers) and, moreover, admits definition of the lazy forms of these types using suspension types (Chapter 36). A value of a suspension type is either a value of the underlying type, or a computation of such a value that may diverge. There being no representation of the eager types in a lazy language, it follows that, eager languages are strictly more expressive than lazy languages." [1] This paragraph is then followed by a link to Harper's "PCF by Value" supplement/errata to the above referenced PFPL, where such a statement is reinforced. [2] [1] - https://www.cs.cmu.edu/~rwh/pfpl/supplements/commentary.pdf https://www.cs.cmu.edu/~rwh/pfpl/supplements/commentary.pdf [2] - https://www.cs.cmu.edu/~rwh/pfpl/supplements/pcfv.pdf https://www.cs.cmu.edu/~rwh/pfpl/supplements/pcfv.pdf
  - mrkeen 2y ago
    > I am unsure where the proof, or even supporting argument You make a lazy function strict by asking for its output now rather than later. > An eager semantics supports the expected semantics of types (for example, the natural numbers are the natural numbers). What a (counter)example! In lazy semantics the natural numbers are the natural numbers. In eager semantics the natural numbers are stack overflow. > moreover, admits definition of the lazy forms of these types using suspension types This is the required modification that your library maintainer would need to make if he had produced a strict library that you wanted to use lazily. Hence "You cannot ask a strict function to behave lazily." > There being no representation of the eager types in a lazy language Because the lazy representation is the same as the eager representation in the source code. It's up to the caller to demand values now, or later, hence "But you can ask a lazy function to behave strictly."
marcosdumay 2y ago
> But pure functional programming in the Haskell sense doesn't really manage file handles for you, or database connections. That's what monads are for. Haskell doesn't require that you use automatic management. But it does absolutely have a solution.
- eru 2y ago
  How are monads useful for managing file handles or database connections? You might want to look into 'indexed monads', they can perhaps help with that. But they aren't a type monads (it's the other way round, vanilla monads can be seen as a trivial kind of 'indexed monads', I guess).
  - valenterry 2y ago
    The encapsulate direct access to those resource and therefore allow a properly controlled lifecycle because usage is then local and cleanup in case of errors is automatic. The caller pretty much can't do anything wrong. No linear types or indexed monads needed actually.