I just used quickcheck to generate arbitrary functions in order to test my functor for lawful composition

I just used quickcheck to generate arbitrary functions in order to test my functor for lawful composition.

This is absolutely magical. I love haskell.

Attached: images.png (267x189, 2K)

Other urls found in this thread:

austinrochford.com/posts/2014-05-27-quickcheck-laws.html
github.com/data61/fp-course/blob/master/src/Course/ListZipper.hs
twitter.com/NSFWRedditImage

You are delusional.

You are upset.

post te code

cool, now lose some weight, neckbeard

pic related. The actual function "functorComposition" is defined with generics but when annotated with a specific type, quickcheck is able to generate functions on the fly. It's neat that this is possible, but its also super slow and it would be annoying if this ran after every local build.

Workin on it.

Attached: tests-generated-functions.png (1920x1080, 243K)

Was reading this guy's stuff to learn:
austinrochford.com/posts/2014-05-27-quickcheck-laws.html

Why not just derive functor? Do you experience joy in undertaking redundant work?

You're right. Thanks. I was under the impression that worked on the first member of the record, but its the first type argument.

Interestingly enough, that made it even slower.

Attached: deriveFunctor.png (1920x1080, 244K)

It would be the last type argument.

I don't understand why the History data type is a Functor. As a design principle, why?

Cool.

instance a => Arbitrary (History a) where
arbitrary = History arbitrary arbitrary arbitrary arbitrary

instance Arbitrary a => ... of course.

I've never seen an arbitrary instance in applicative style. Neat and TY.

I have a rendering function that was applying the same function to different parts of the structure and then doing some concatenation. It was getting messy so I started down this path. It's a pretty limited use case.

Attached: applicativeArbitrary.png (1920x1080, 214K)

For more context: The type argument to History is going to be something more complex than string in the thing i'm actually making, but I'll want it to be a string when I display it. So being able to fmap show over it makes things easier.

or any other function other than show for that matter

Please tell me global is not the concatenation of previous current and next.

it isn't. Global holds long term history like when you view your browser history in the sidebar. The previous, current, and next are more of a session history like when you right click the back button.

It could have a better name, I just didn't dwell on it that much.

The question is, is there a potential to express nonsense (incompatible) data there? Or is global a disjoint past?

Also, for the current session, does it make sense to have a Nothing current but populated previous or next?

The identity law is a free theorem arising from the composition law and parametricity, so you never need to prove it. Also, the deriving mechanism produces lawful instances for all F-algebras, so you rarely need to prove the composition law either. Happy Haskelling.

For context the pet project is a browser of some sort. Global is everywhere that's ever been visited ever and it does not need to be in any chronological order, so I don't see how that could ever get into an invalid state. At the moment, whenever navigation to a new page happens, The new url gets appended to global, set to current, and the old current gets prepended to previous. Additionally I might move global out soon. I'm only supporting one "tab" at the moment so when the time comes to add multi tab support each tab is going to need it's own summary history and shared access to global history.

As far as the Maybe, the answer to your question is I don't think so. I can't think of a time when there would be a previous or a next but not a current. The only time you would be nowhere would be on app launch, or in the future when you close all tabs. The closest scenario I can think of is a browser crash -> session restore scenario, but even then something would be showing, and probably in a page.

Good to know thanks.

Attached: history-functions.png (1920x1080, 139K)

I've had this in the back of my mind a while and have been ignoring it for now because I'm almost certain I won't be in that invalid scenario. But it has been and is bugging me again so maybe ill take a whack at the types. But right now i'm going to bed. I'll check back if the thread is still alive when I wake up.


Thanks for the tips and discussion anons.

Then I suggest making global a Data.Set.Set, since it's order agnostic and you don't wan't to manually weed out multiplicities.

As for the three fields constituting the present session, I'd go with two lists, one extending to the past and one to the future, with the head of one of those (probably doesn't matter which) implicitly expressing current page. You generally don't want nonsensical things to be even expressible, that's the main point of Haskell's type system. Better yet, do something like
data SessionHistory a = Blank | Session [a] a [a]

Now current page exists if and only if the history is not blank. Also, there's a chance it won't ever make sense for the history to be blank, in which case simply drop the Maybe in your original definition.

See here for a similarly useful data structure and note how it's rotated: github.com/data61/fp-course/blob/master/src/Course/ListZipper.hs

As your response to the free theorems suggests, you're not too familiar with the theory, so let me give a couple other suggestions.

If you want create a zipper (history) for your own type (state of some sort), you can mechanically calculate one from its McBride derivative, as long as you can make sense of the resulting equivalences. On a related note, if you want certain inhabitants of your type to be equivalent, you can enrich your type into a setoid. However, both of these things are better done on paper or in a proof assistant and only subsequently translated into Haskell.

I'm not sure how familiar you are with monad transformers, but your application might be better represented as a stack of ReaderT, LoggerT, StateT and maybe other monads.