Extend, Comonad, and StateT #1

maxrothman · 2019-02-04T21:35:16Z

No description provided.

The Setup.lhs file is incompatible with newer versions of the Cabal library. This change adds the appropriate custom-setup stanza to indicate compatibility with Cabal 1.24.

Add custom-setup stanza

by completing the custom setup stanza

Fix new-build on NetworkServer

Test with GHC 8.4

I've had a few people ask for this function in later modules. I also think it's a good exercise before getting to foldRight.

Update tasty pattern examples to match tasty >= 1.0

StateT: Fix typo

Make gitignore ignore cabal artifacts in any subdirectory

Update Leksah instructions.

Remove extra argument of property for ListZipper.index

Add Course.Optional#optional

add editorconfig

Fix typo in Course.Optional#optional

Fix typo in stringTok comment

Fix error typo in Course.MoreParser#string

Add hint about chr to MoreParser.hs

Add a hint to replicateA

Move list and list1 below digit, since digit is used in their tests

The comment that precedes the Traversable type class definition declares there are two laws, but then goes on to define three (naturality, identity, composition). Typeclassopedia does suggest that identity and composition are the traversable laws and that naturality follows if you are dealing with applicatives. But I definitely don't know enough to assess the truth of that claim. (ref: https://wiki.haskell.org/Typeclassopedia#Laws_7) Either way the current comment seems misleading.

Fix typo ('two'=>'three') in Traversable laws

This commit adds some tasty tests for the traversable module. Property-based tests would probably be a good idea and should perhaps be added at a later date. The Compose, Product, and Coproduct newtypes now derive Show and Eq to allow for easier testing.

Add tests for Traversable.hs

ignoring cabal new-test artifact

remove trailing spaces

StateT: add signatures

four Applicative laws

fsoikin · 2019-02-06T14:58:02Z

src/Course/Comonad.hs

-(<$$>) =
-  error "todo: Course.Comonad#(<$>)"
+func <$$> fa = func . copure <<= fa
+-- REVIEW: would it be desireable to eta-reduce this to `(<$$>) f = (f . copure <<=)` ?


No, I think the way it is now is cleaner.

fsoikin · 2019-02-06T15:03:02Z

src/Course/Compose.hs

    Functor (Compose f g) where
-  (<$>) =
-    error "todo: Course.Compose (<$>)#instance (Compose f g)"
+  -- (a -> b) -> Compose f g a -> Compose f g b


FYI: it is possible to add explicit type signatures to instance members with InstanceSigs extension

fsoikin · 2019-02-06T15:08:02Z

src/Course/Extend.hs

-    error "todo: Course.Extend (<<=)#instance List"
+  _    <<= Nil           = Nil
+  func <<= l@(_ :. rest) = func l :. (func <<= rest)
+  -- REVIEW: is this the "right way" to do this, or should I be using foldr or something?


I think recursion is perfectly fine in a vacuum.
However, in some cases, it makes the code look needlessly complex, and in these cases you'd use fold - i.e. foldl (+) xs is way more concise than a recursive analog.
But this is not one of those cases.

When approaching this problem, would you have reached for recursion, or some other looping function?

I would have gone with recursion

fsoikin · 2019-02-06T15:09:08Z

src/Course/Extend.hs

+    Empty  -> Empty
+  -- func <<= fa@(Full _) = Full $ func fa
+  -- _    <<= Empty       = Empty
+  -- REVIEW: both of these work, any reason to prefer one over the other?


No reason other than aesthetics.

Do you have a preference? If so, why? I don't have a strong sense of aesthetics yet, so I'm trying to build up my heuristics.

I have a preference for the uncommented way, because I find the @-aliasing ugly.

fsoikin · 2019-02-06T15:17:27Z

src/Course/StateT.hs

+        pure $ func <$> a
+    -- REVIEW:
+    -- Above, you suggested solutions like these over more point-free ones like theirs
+    -- (OptionalT f <*> OptionalT a = OptionalT (lift2 (<*>) f a)). Does this fall into the same


I think in this case their solution is cleaner: it straightforwardly states that <*> on OptionalT is <*> on Optional lifted through the underlying functor.
Note, however, that their solution is not point-free: it has two points, f and a.

I think I don't have a good intuitive sense of what lift2 means, and my understanding of what lift means might be muddling it further. My understanding is that lift takes a value that is under one monad in a transformer stack and makes it compatible with the entire stack. Does lift2 mean something similar, or is it completely different?

This is a (yet another) slightly confusing naming thing: lift2 doesn't actually have anything to do with lift or with monad transformers. lift2 is just an fmap of two arguments, that's it.

To disambiguate this (or, perhaps, to confuse you even more :-), in the standard library it's actually called liftA2, where the A refers to Applicative.

I've got a great read for you on the subject of lifting: https://fsharpforfunandprofit.com/posts/elevated-world/

fsoikin · 2019-02-06T15:22:08Z

src/Course/StateT.hs

+    -- category? I'm still trying to build my intuition around when it makes sense to go point-free
+    -- and when it doesn't.
+    --
+    -- Also, their version fails tests 5-7


This has to do with how lift2 is defined for lists. In order for these tests to pass, it has to do what your code above does: first run the first argument, then the second, not both at once. I'm not sure what your implementation here is, so can't say more.

In general, however, it is kind of well known that lists are good as functors, but very weird as applicatives and monads. This is because there are multiple ways of implementing <*> and =<< for lists, and none of them make intuitive sense in all edge cases.

Actually, scratch that. There is no way to implement lift2 on lists in a way that will accommodate these tests.

lift2 (+) [1,2] [10, 20] == [11, 12, 21, 22] lift2 ($) [(+1), (+2)] [10, 20] == [11, 12, 21, 22]

It can't know that it has to skip application for some elements, unless it knows the inner structure of those elements, so for lift2 (<*>) [Empty, Empty] [Full 1, Full 2] it will always apply both Emptyies to both Fulls, returning a list of 4.

In general you can say that:

∀f, l1, l2 : length (lift2 f l1 l2) == length f1 * length f2

There is, of course, another way to implement lift2 on lists:

lift2 (+) [1,2] [10,20] == [11, 22]

But that will also not work with some of the tests.

Is it fair to say that one should (almost) never see lists as applicatives or monads in production code?

No.
Even though lists are not well-behaved monads, it is nevertheless very convenient to use the do notation for them:

cartesianProduct :: [a] -> [b] -> [(a, b)] cartesianProduct ax bx = do a <- ax b <- bx pure (a, b)

Of course, in this specific case I could use a list comprehension, but there are more complicated cases where list comprehension comes out really ugly, and monadic syntax looks very understandable. And people do this all the time. In fact, PureScript doesn't even have list (array?) comprehensions, and instead recommends using the monadic syntax.

So then what's the right way to think about this problem?

It's aesthetically more pleasing to use lift2, but doing so doesn't meet the necessary requirements, so we have to use a slightly uglier solution

The specs are defined wrong in some way, it should be possible to use lift2 to solve this problem

Something else?

It's an approximation thing. They behave well enough in mainstream cases. It's only edge cases that are weird.

It's like Newton's gravity is not strictly speaking correct, so you should ideally use relativity, but it is correct enough under normal circumstances that you can still get away with it most of the time.

How do I know when I'm getting near the edges of the safe uses of list monads/applicatives? Or is that just from experience?

It depends on what you mean by "safe".
Technically, everything always works exactly the way it was programmed to.
When I say "weird", I mean that behavior of the program does not correspond to your intuitive expectation.

From here, one can argue that "safe" means "corresponding to my intuition", and therefore the way to determine when I'm approaching the edges is when the behavior starts to diverge from my intuition.

I agree. What I'm asking is: do you have any heuristics for knowing when using list monads/applicatives might behave in unintuitive ways?

Personally, I wouldn't do anything more complex than several <- lines in a row, like:

foo xs = do x <- xs y <- getYs x z <- getZs x y pure $ bar x y z

fsoikin · 2019-02-06T15:24:34Z

src/Course/StateT.hs

+    -- (https://github.com/maxrothman/fp-course/blob/e20fcd61979b76778836dd5277181937ad6facc3/test/Course/StateTTest.hs#L133)
+    -- Mine did too when I had `a <- fa` in the top do. Moving it to the bottom do fixed the issue.
+    --
+    -- Also not really sure what the suggestion to use onFull was about, they don't use it either.


I don't know what onFull is. I can guess that it is probably a catamorphism for Optional, i.e. something like onFull :: b -> (a -> b) -> Optional a -> b. If so, you can replace the case expression with an onFull call, but I'm not sure it would look any better.

It's defined below: onFull :: Applicative f => (t -> f (Optional a)) -> Optional t -> f (Optional a)

I don't see how this is different from map

It basically just puts a case statement around the second argument

It looks exactly like fmap, only with the second type parameter specialized to Optional a

¯\_(ツ)_/¯

fsoikin · 2019-02-06T15:28:01Z

src/Course/StateT.hs

+    case maybeA of
+      Empty -> pure Empty
+      Full a -> runOptionalT . func $ a
+      -- REVIEW: un-OptionalT'ing this to just re-OptionalT it again seems dumb. There's no


Well, that's the essence of what =<< does: it unwraps, applies the function, then rewraps. If you can do it in a clever way that doesn't actually involved unwrapping/rewrapping - more power to you, but in general this is indeed impossible. Look at MaybeT for example.

fsoikin · 2019-02-06T15:28:44Z

src/Course/StateT.hs

+      Empty -> pure Empty
+      Full a -> runOptionalT . func $ a
+      -- REVIEW: un-OptionalT'ing this to just re-OptionalT it again seems dumb. There's no
+      -- straightforward way around it, right? And I can assume the extra work will be optimized away?


The extra work is indeed guaranteed to be optimized away, because OptionalT is a newtype.

mstruebing and others added 30 commits February 10, 2018 18:11

add editorconfig

4c890bc

Add custom-setup stanza

eee4380

The Setup.lhs file is incompatible with newer versions of the Cabal library. This change adds the appropriate custom-setup stanza to indicate compatibility with Cabal 1.24.

Merge pull request system-f#274 from snoyberg/master

f1d9e4d

Add custom-setup stanza

Fix new-build on NetworkServer

d3ddd23

by completing the custom setup stanza

Make gitignore ignore cabal artifacts in any subdirectory

b59f437

Test with GHC 8.4

7057ba5

Merge pull request system-f#275 from data61/fix-custom-setup-stanza

11ef237

Fix new-build on NetworkServer

Merge pull request system-f#277 from data61/ghc-8.4

997775d

Test with GHC 8.4

Add Course.Optional#optional

f85b276

I've had a few people ask for this function in later modules. I also think it's a good exercise before getting to foldRight.

Update tasty pattern examples to match tasty >= 1.0

b291d88

Require tasty >=1

7ffabb3

Merge pull request system-f#283 from gwils/new-tasty

432eef2

Update tasty pattern examples to match tasty >= 1.0

StateT: Fix typo

6d15bb8

Merge pull request system-f#284 from MIJOTHY/patch-1

384d781

StateT: Fix typo

Merge pull request system-f#276 from data61/wider-gitignore

4f12aa7

Make gitignore ignore cabal artifacts in any subdirectory

Remove extra argument of property for ListZipper.index

c038073

Update Leksah instructions.

543181c

Merge pull request system-f#288 from hamishmack/master

048ea7c

Update Leksah instructions.

Merge pull request system-f#285 from Lysxia/patch-1

7b1144c

Remove extra argument of property for ListZipper.index

Merge pull request system-f#281 from puffnfresh/optional

44eeb1d

Add Course.Optional#optional

Merge pull request system-f#260 from mstruebing/addEditorconfig

f30f86f

add editorconfig

Fix typo in Course.Optional#optional

1e10455

Merge pull request system-f#289 from puffnfresh/optional

94a7fa0

Fix typo in Course.Optional#optional

Fix error typo in Course.MoreParser#string

3435f3e

Fix typo in stringTok comment

bfcd178

Merge pull request system-f#291 from puffnfresh/patch-2

acb1902

Fix typo in stringTok comment

Merge pull request system-f#290 from puffnfresh/patch-1

cf4b055

Fix error typo in Course.MoreParser#string

new cheque tests

8808e59

Tweaking the cheque tests

c12016f

Merge branch 'master' of github.com:data61/fp-course into prb

6db0129

dalaing and others added 24 commits November 23, 2018 10:12

Bumps versions of nixpkgs and GHCs for Hydra

6840e34

Move list and list1 below digit, since digit is used in their tests

fb8cfc3

Add a hint to replicateA

ce08058

Add hint about chr to MoreParser.hs

cb2dfaf

Merge pull request system-f#309 from data61/more-parser-chr-hint

07d82d4

Add hint about chr to MoreParser.hs

Merge pull request system-f#308 from data61/replicateA-hint

4de0dee

Add a hint to replicateA

Merge pull request system-f#307 from data61/parser-list-after-digit

c7f676b

Move list and list1 below digit, since digit is used in their tests

Merge pull request system-f#310 from stacktracehq/fix-law-count-typo

29ddf01

Fix typo ('two'=>'three') in Traversable laws

Add tests for Traversable.hs

463b5a0

This commit adds some tasty tests for the traversable module. Property-based tests would probably be a good idea and should perhaps be added at a later date. The Compose, Product, and Coproduct newtypes now derive Show and Eq to allow for easier testing.

Merge pull request system-f#311 from stacktracehq/add-traversable-tests

ad361c5

Add tests for Traversable.hs

ignoring cabal new-* artifact

78ac4b2

StateT: add signatures

88e151d

Merge pull request system-f#313 from wizzup/ignor-cabal-files

f36629b

ignoring cabal new-test artifact

remove trailing spaces

cc67cfd

Merge pull request system-f#315 from wizzup/fix-trailing-spaces

0e9cd43

remove trailing spaces

Merge pull request system-f#314 from wizzup/statet-sigs

deb5227

StateT: add signatures

four Applicative laws

3032918

Merge pull request system-f#316 from stephennancekivell/patch-1

4c036b9

four Applicative laws

Finished StateT

ed22a6a

distinctG take 2

798fadc

Finish Extend

ae5284c

Finish comonad

2014d15

Actually finish StateT

8881060

fsoikin reviewed Feb 6, 2019

View reviewed changes

Max Rothman added 4 commits February 6, 2019 20:21

Finish compose, work on traversable

be39245

Pull upstream

bda8705

in progress

25ba049

Snapshot (final?)

2ef0772

maxrothman force-pushed the master branch from 9bb66f2 to 2ef0772 Compare November 26, 2019 16:21

Extend, Comonad, and StateT #1

Are you sure you want to change the base?

Extend, Comonad, and StateT #1

Uh oh!

Conversation

maxrothman commented Feb 4, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants