3 ms·

Meh. In C, everything is a pointer, in Haskell everything is a monad. Regarding effects, I found Koka to be a breath of fresh air: https://koka-lang.github.io/

by zvrba 5y ago

Meh. In C, everything is a pointer, in Haskell everything is a monad. Regarding effects, I found Koka to be a breath of fresh air: https://koka-lang.github.io/koka/doc/book.html#why https://koka-lang.github.io/koka/doc/book.html#why

puddingforears 5y ago
But does Koka let you generalize over effects?
- Quekid5 5y ago
  Not as far as I can tell, but it seems to let you supply handlers to discharge effects at any point. That should at least allow you to 'embed' any effect type in a more general effect type (but the 'embedding' itself would be hardcoded, so not 'first class'... I think.).
- gryn 5y ago
  from reading it docs in the past, it seems to have polymorphism over effects. I don't know if that's what you mean by generalizing over effects.
- CornCobs 5y ago
  Disclaimer: only have dabbled in Koka slightly. Not very sure if this is what you were asking about but yes, you can write functions that are polymorphic in their effect. E.g. the map function takes a function that has some effect e and the map function itself has the same effect e
ithkuil 5y ago
Frank is also interesting https://github.com/frank-lang/frank https://github.com/frank-lang/frank https://arxiv.org/abs/1611.09259 https://arxiv.org/abs/1611.09259
eru 5y ago
The saying is perhaps more true for C than for Haskell. Haskell has lots of things that either can't be made Monads or are even deliberately not Monads (to preserve parallelism).
- nybble41 5y ago
  Precisely. Monads are a big topic in Haskell not because other languages don't have monads (they're actually quite pervasive—any time you can perform operations with side effects and have the results influence other side effects you are working in a monadic context) but rather because in Haskell you often don't have a monadic context, which allows you to reason more effectively about the code.
  - tome 5y ago
    Interesting point. Haskell introduces monads not so that you can have them but so that you can not have them!
    - nybble41 5y ago
      > Haskell introduces monads not so that you can have them but so that you can not have them! Another way of looking at this which is perhaps not so brain-twisting is that in most languages you start out with the ability to perform arbitrary side effects at any point in the program, which gives the programmer a lot of power but makes the program hard to reason about. In Haskell the "default state" is pure functions, which are great for reasoning about your program but much less powerful (no side effects). To this we can selectively add Functor, Applicable, and Monad instances to recover the ability to express side effects to varying degrees while still keeping most of the program pure. The fact that you have a choice about how much monadic code to introduce into your program is why monads are such a big topic in Haskell.

by zvrba 5y ago

puddingforears 5y ago

But does Koka let you generalize over effects?

Quekid5 5y ago
Not as far as I can tell, but it seems to let you supply handlers to discharge effects at any point. That should at least allow you to 'embed' any effect type in a more general effect type (but the 'embedding' itself would be hardcoded, so not 'first class'... I think.).
gryn 5y ago
from reading it docs in the past, it seems to have polymorphism over effects. I don't know if that's what you mean by generalizing over effects.
CornCobs 5y ago
Disclaimer: only have dabbled in Koka slightly. Not very sure if this is what you were asking about but yes, you can write functions that are polymorphic in their effect. E.g. the map function takes a function that has some effect e and the map function itself has the same effect e

ithkuil 5y ago

Frank is also interesting https://github.com/frank-lang/frank https://github.com/frank-lang/frank https://arxiv.org/abs/1611.09259 https://arxiv.org/abs/1611.09259

eru 5y ago

The saying is perhaps more true for C than for Haskell. Haskell has lots of things that either can't be made Monads or are even deliberately not Monads (to preserve parallelism).

nybble41 5y ago
Precisely. Monads are a big topic in Haskell not because other languages don't have monads (they're actually quite pervasive—any time you can perform operations with side effects and have the results influence other side effects you are working in a monadic context) but rather because in Haskell you often don't have a monadic context, which allows you to reason more effectively about the code.
- tome 5y ago
  Interesting point. Haskell introduces monads not so that you can have them but so that you can not have them!
  - nybble41 5y ago
    > Haskell introduces monads not so that you can have them but so that you can not have them! Another way of looking at this which is perhaps not so brain-twisting is that in most languages you start out with the ability to perform arbitrary side effects at any point in the program, which gives the programmer a lot of power but makes the program hard to reason about. In Haskell the "default state" is pure functions, which are great for reasoning about your program but much less powerful (no side effects). To this we can selectively add Functor, Applicable, and Monad instances to recover the ability to express side effects to varying degrees while still keeping most of the program pure. The fact that you have a choice about how much monadic code to introduce into your program is why monads are such a big topic in Haskell.