6 ms·

No you dont. Thats the point. The type of the function completely determines the operation. Dont read the code. Read the type and then you know what the code ha

No you dont. Thats the point. The type of the function completely determines the operation. Dont read the code. Read the type and then you know what the code has to do.

quickthrower2 7y ago
hoistStateIntoStateT :: Sem (State s ': r) a -> S.StateT s (Sem r) a ? Sorry even that'll get my brain CPU on 100% for a few minutes.
- lalaithion 7y ago
  This code takes a Sem monad with a State effect in it, and turns it into a StateT monad with an inner monad of Sem and al l the other effects. I have never user Polysemy, any effects library, or type-level lists before, but I'm reasonably sure my guess is right, despite not understanding any of the code.
- tathougies 7y ago
  Takes a Sem with a state effect and turns it into the state monad transformer over Sem with the remaining effects?
- nilkn 7y ago
  I suspect you probably just need more experience with the base language. And I don't mean that in a bad way -- Haskell is a bit of a weird language, and it's something that you'll need to spend some time with. But indeed that's a fairly standard sort of type signature that you'll process at a glance if you've used the language a fair bit.
md224 7y ago
> The type of the function completely determines the operation. Really? I must be misunderstanding what you mean by "operation", or maybe this is the part of functional programming that hasn't clicked for me yet... my understanding is that the type signature tells you what kinds of things the function works with, but it doesn't tell you how the function maps the input to the output. When I hear "operation", I think of the latter. What are you referring to?
- derefr 7y ago
  Sometimes there's only one possible function of a given typing. For example, if a function's type is `a -> b -> (a, b)`, there's really only one function fitting that shape: cons. What else could a (pure) function possibly do, with that typing, other than "exactly what cons does"?
  - mcphage 7y ago
    Do you frequently find yourself having to redefine cons when programming?
    - posco 7y ago
      No, but surprisingly frequently this property holds: if your function is generic enough, there is only one (or a small number) of possible implementations that type check. Leveraging this rules out bugs.
    - danharaj 7y ago
      If you define a custom generic data type, for example if you need a special kind of tree for a particular algorithm, then you're going to be writing a lot of generic functions like cons for that data type.
      - EdwardDiego 7y ago
        In what language? I thought Haskell and OCaml for example, had generics.
        mrkeen 7y ago
        The situation is a bit better than just generics (as they are in Java). For instance, if I had a List<Int>, I can treat it like a List<I>, but why can't I treat it like an <L>Int? Or an <L><I>?
  - etbebl 7y ago
    Map x : a and y : b to (5x, y-3)?

No you dont. Thats the point. The type of the function completely determines the operation. Dont read the code. Read the type and then you know what the code has to do.

quickthrower2 7y ago

hoistStateIntoStateT :: Sem (State s ': r) a -> S.StateT s (Sem r) a ? Sorry even that'll get my brain CPU on 100% for a few minutes.

lalaithion 7y ago
This code takes a Sem monad with a State effect in it, and turns it into a StateT monad with an inner monad of Sem and al l the other effects. I have never user Polysemy, any effects library, or type-level lists before, but I'm reasonably sure my guess is right, despite not understanding any of the code.
tathougies 7y ago
Takes a Sem with a state effect and turns it into the state monad transformer over Sem with the remaining effects?
nilkn 7y ago
I suspect you probably just need more experience with the base language. And I don't mean that in a bad way -- Haskell is a bit of a weird language, and it's something that you'll need to spend some time with. But indeed that's a fairly standard sort of type signature that you'll process at a glance if you've used the language a fair bit.

md224 7y ago

> The type of the function completely determines the operation. Really? I must be misunderstanding what you mean by "operation", or maybe this is the part of functional programming that hasn't clicked for me yet... my understanding is that the type signature tells you what kinds of things the function works with, but it doesn't tell you how the function maps the input to the output. When I hear "operation", I think of the latter. What are you referring to?

derefr 7y ago
Sometimes there's only one possible function of a given typing. For example, if a function's type is `a -> b -> (a, b)`, there's really only one function fitting that shape: cons. What else could a (pure) function possibly do, with that typing, other than "exactly what cons does"?
- mcphage 7y ago
  Do you frequently find yourself having to redefine cons when programming?
  - posco 7y ago
    No, but surprisingly frequently this property holds: if your function is generic enough, there is only one (or a small number) of possible implementations that type check. Leveraging this rules out bugs.
  - danharaj 7y ago
    If you define a custom generic data type, for example if you need a special kind of tree for a particular algorithm, then you're going to be writing a lot of generic functions like cons for that data type.
    - EdwardDiego 7y ago
      In what language? I thought Haskell and OCaml for example, had generics.
      - mrkeen 7y ago
        The situation is a bit better than just generics (as they are in Java). For instance, if I had a List<Int>, I can treat it like a List<I>, but why can't I treat it like an <L>Int? Or an <L><I>?
- etbebl 7y ago
  Map x : a and y : b to (5x, y-3)?