mbw 2017-01-31 22:47:33
I guess it's clearer when you come from the implementation of getCh and putCh.
christiaanb 2017-01-31 22:49:42
Hi, for space profiling (-hy) what is type * again?
christiaanb 2017-01-31 22:49:47
are those thunks?
Cale 2017-01-31 22:52:19
mbw: Well, every MyIO action is going to be one of the following:
Cale 2017-01-31 22:52:57
mbw: 1) It could be Done v for some value v
Cale 2017-01-31 22:53:18
(i.e. it does nothing, but produces the result v)
Cale 2017-01-31 22:53:41
2) It could start out by getting a character, and then on the basis of that, we'll determine what to do afterward
Cale 2017-01-31 22:54:14
This is represented by the GetChar (Char -> MyIO a) case
mbw 2017-01-31 22:54:14
Does 1) correspond to const?
Cale 2017-01-31 22:54:22
It corresponds to return
Cale 2017-01-31 22:54:33
:t return
lambdabot 2017-01-31 22:54:35
Monad m => a -> m a
Cale 2017-01-31 22:55:13
For IO, return v constructs an IO action which does nothing, but produces v as its result when run.
Cale 2017-01-31 22:56:02
and that's generally the case, return is always going to produce something which "does nothing", whatever that might happen to mean in context
Cale 2017-01-31 22:56:16
This is because of the monad laws: return v >>= f = f v
Cale 2017-01-31 22:56:22
and x >>= return = x
Cale 2017-01-31 22:57:36
popping back up to the list of cases, our action might also start out by printing some character
Cale 2017-01-31 22:58:02
and then we'll follow that up with some other IO action (since printing doesn't have a meaningful result, we won't bother making it a function depending on anything)
Cale 2017-01-31 22:58:17
So, that's the PutChar Char (IO a) case
Cale 2017-01-31 22:58:26
er, PutChar Char (MyIO a)
Cale 2017-01-31 22:58:49
You have the character to be printed, and the MyIO action which is meant to occur thereafter
Cale 2017-01-31 23:00:28
Note also that while I wrote an interpreter for this MyIO monad using IO, we could also write something of type MyIO a -> [Char] -> Maybe [Char]
Cale 2017-01-31 23:00:56
which would take the input all at once as a String, and, if there was enough input, produce all the output
Cale 2017-01-31 23:01:09
and many other variations
Cale 2017-01-31 23:01:35
We could choose to use network I/O to implement reading and writing characters
niko 2017-01-31 23:01:48
:14
Cale 2017-01-31 23:02:04
Obviously this particular example isn't especially great -- reading and writing single characters at a time is a bit silly
Cale 2017-01-31 23:02:16
But you can do this kind of thing for operations of arbitrary shape
mbw 2017-01-31 23:02:23
So the functorial context is the concrete representation of our interpreter?
Cale 2017-01-31 23:02:37
which context?
mbw 2017-01-31 23:02:50
MyIO
Cale 2017-01-31 23:02:51
I don't know how to interpret that :)
Cale 2017-01-31 23:02:53
ah
mbw 2017-01-31 23:03:13
I don't know if context is the right word.
mbw 2017-01-31 23:03:19
Kleisli category? :)
Cale 2017-01-31 23:03:20
MyIO is a parametric type of actions
Cale 2017-01-31 23:04:08
In our case, it's effectively just (higher order) abstract syntax for the stuff to do, but we may choose to interpret it in a bunch of ways.
mbw 2017-01-31 23:07:01
What makes this abstract syntax a higher-order one? GetChar?
phadej 2017-01-31 23:08:39
the use of functions there, yes.
phadej 2017-01-31 23:09:12
you cannot inspect that operation
mbw 2017-01-31 23:09:59
Ok.
phadej 2017-01-31 23:10:16
with http://hackage.haskell.org/package/operational-0.2.3.5/docs/Control-Monad-Operational.html you can
phadej 2017-01-31 23:10:31
but operational is "freer" than free, as it doesn't require the `f` to be functor
phadej 2017-01-31 23:10:57
sometimes it's important, sometimes not. depends.
reactormonk 2017-01-31 23:13:09
In emacs with haskell-mode, how do I tell it to restart the flycheck checker?
Cale 2017-01-31 23:13:51
mbw: A general design pattern of functional programming is to invent miniature programming languages in which your problem domain is easily expressed, and then to define the solutions to your problems as interpreters for the description somehow. People do this enough that we end up with lots of fancy machinery to try to abstract over some of the repetition in it.
reactormonk 2017-01-31 23:13:55
... posted it in emacs too.
Cale 2017-01-31 23:14:20
mbw: and indeed, Monad itself can be seen as capturing a commonly occurring pattern in that
mbw 2017-01-31 23:23:27
I did this once, when I wrote a Haskell program to reduce a large algebraic expression. I was afraid to introduce abstractions for recurring compositional patterns though. Even when I find a way to implement Functor/Applicative/Monad for a given data type, I don't necessarily know what it "means".
mbw 2017-01-31 23:25:35
While the container abstraction is somewhat easy, I don't think an algebraic interpretation necessarily is
mbw 2017-01-31 23:27:56
For instance, I can interpret the list monad as representing non-determinism, i.e. an element of the domain does not correspond uniquely to an element of the codomain. But what does a monad instance of data Tree a = Leaf a | Branch (Tree a) (Tree a) mean?
mbw 2017-01-31 23:28:31
How do you come up with these kinds of interpretations?
wz1000 2017-01-31 23:29:44
mbw: It is like the list monad, but preserves the tree structure of the function
wz1000 2017-01-31 23:30:20
If you collapse the tree, you should get a result identical to the one you got with the list monad
mbw 2017-01-31 23:31:43
Does this apply to every data structure that can be flattened like that?
mbw 2017-01-31 23:32:14
i.e. Foldables?
merijn 2017-01-31 23:33:55
mbw: In the case of trees, monads are "trees with grafting"
merijn 2017-01-31 23:34:11
mbw: Monad for "data Tree a = Leaf a | Branch (Tree a) (Tree a)" gives us
merijn 2017-01-31 23:34:25
"(>>=) :: Tree a -> (a -> Tree b) -> Tree b"
merijn 2017-01-31 23:34:43
So, basically, you just replace every 'Leaf a' with the newly created 'Tree b' for that leaf
merijn 2017-01-31 23:34:57
Flattening is completely irrelevant for Monad instance for trees
mbw 2017-01-31 23:40:01
Ok.
mbw 2017-01-31 23:40:14
I shall meditate on what I have learned, thank you very much.
tsahyt 2017-01-31 23:40:22
what would be the semantics of a TreeT transformer then? a tree of computations, i.e. nondeterminism again, but retaining the tree structure throughout?
merijn 2017-01-31 23:40:41
tsahyt: ugh, it's too early to consider that
mrkgnao 2017-01-31 23:42:41
is there a nice way to refactor this?
mrkgnao 2017-01-31 23:42:43
source <- use (instAt (ptr' + bv))
mrkgnao 2017-01-31 23:42:45
instAt (ptr' + av) .= source
Cale 2017-01-31 23:43:45
What's wrong with it?
Axman6 2017-01-31 23:44:00
that's .= from lens right?
Cale 2017-01-31 23:44:09
If you're doing something repetitive, you should define a function which does it.
Axman6 2017-01-31 23:44:37
you could use use ... >>= set ... (it's not set though, it has a lensy name I can't remember)
