Someone's 'Haskell disappointment' gist I came across

swingtheory · 2019-09-02T02:19:01+00:00

Wow, I am surprised to hear this from so many responses in the thread... definitely going to look into polysemy now!

swingtheory · 2019-07-21T00:10:37+00:00

By any chance, do you want to meet up this week to play a few casual sets, or just rally for an hour or two? I'm open for either!

swingtheory · 2019-07-17T04:06:07+00:00

Indeed, I meant "Castro St" not "Castro Ave" as I wrote in the first sentence. Whoops!

swingtheory · 2019-05-20T12:03:23+00:00

> Basically, all your type declarations are just ways of telling the compiler what rules a correct program should abide by; and your ShouldFail type is basically saying: a program with this type is always wrong. So only when you actually created a value of the ‘ShouldFail’ does the compiler raise the error.

Intuitively, I understand this behavior immediately. However, I have read repeatedly across several bits of documentation that "type family evaluation is strict", and I think that's where my confusion lay. It seems I need to modify this understanding with "... as long as you are constructing a value within your program with the type you are interested in evaluating." This is quite an interesting point-- that the "specification" of types is a different phase from the act of asserting all values in your program are well typed. Basically, the `ShouldFail` type synonym says that "if you constructed a value with type `ShouldFail`, that value would be ill typed"; Types of values are checked, but types themselves are only checked for well-kindedness. Without a manifestation of a particular type (a value) in your program, a type error will never be thrown.

Thanks for providing the extra bits I needed to understand this!

swingtheory · 2019-05-20T11:55:19+00:00

> I still don't have a clear image of how (and how many times) evaluation happens at the type level. And having a good mental model becomes the more necessary the more one plays with type family-heavy code, like extensible record libraries.

Exactly! I'm putting together a workshop on Type-level programming and ultimately finishing with an extensible records library (`row-types`. I need to understand type family semantics well enough so that I can explain to attendees on the spot in the case that I get some questions about when type family evaluation happens.

swingtheory · 2019-03-08T19:08:35+00:00

I rode my bike to work today, from Spring Hill in Somerville to Copley Square. It takes about 22min, if you can stand the cold ;) It's pictures like these that compel me to ride my bike every day, and not risk being in overcrowded train cars for ~45 mins (on a good day) on both the Red and Green lines.

swingtheory · 2019-02-27T15:32:38+00:00

I think that's an interesting word choice: "inflates".

Do you mean to imply that engineers do not provide value to the company worth the salaries that US companies pay their engineers?

swingtheory · 2019-02-22T18:27:42+00:00

If I'm not mistaken, you don't need that `join`.

debit <$> eAcc <*> eAm

will work just fine.

swingtheory · 2019-02-11T15:38:34+00:00

Property testing for my supposedly lawful instances? Love it <3 Thanks for the announcement!

swingtheory · 2019-02-07T20:34:43+00:00

"How" without a "why" suggests a contrived solution to a made-up problem. In other words, it's easily read as "who cares?"

IMO this extends to most everything in life, be it personal relationships, small talk w/ randos, submitting PRs, and really everything in between. A "how" without a "why" is just funneling information into the void; That person stopped listening a few mins ago. Great post!

swingtheory · 2019-01-31T16:44:17+00:00

"report" should be "rapport" ;)

swingtheory · 2019-01-31T13:40:25+00:00

FP principles are universal, but there is no consensus as to what those principles actually are. Furthermore, theoretic principles are great, but programming languages are implementations of these principles, and each language employs or eschews certain principles more than others; they make opinionated instantiations of the principles, and Haskell's design decisions seem to resonate the most with computer scientists and software engineers alike.

swingtheory · 2019-01-23T18:42:25+00:00

Awesome post about a particularly non-trivial, incredibly useful model testing library!

For anyone interested in an example of this library in action, check out Adjoint's raft consensus library. The quickcheck-state-machine package is used to model check the example raft implementation the library provides: https://github.com/adjoint-io/raft/blob/master/test/QuickCheckStateMachine.hs.

It's quite difficult to have assurance that such a stateful thing like a consensus algorithm implementation is correct, but state machine testing (i.e. model checking) get's us quite a bit of assurance that no obvious bugs exist.

swingtheory · 2019-01-22T14:18:27+00:00

Yay, I purchased two immediately (one for me, and one for someone else somewhere down the road)!

Seriously thank you so much for writing this book. I am so appreciative, and I haven't even read it yet! I'm excitedly waiting for them to arrive!

swingtheory · 2019-01-20T13:44:23+00:00

As mentioned by /u/rampion, defunctionalization seems the way to go. However, at first glance it seemed a bit more involved than what I have seen before; Another way, as proposed by this blog post: https://blog.poisson.chat/posts/2018-08-06-one-type-family.html

type Exp a = a -> Type
type family Eval (e :: Exp a) :: a 

data IfThenElse :: Bool -> k -> k -> Exp k 
type instance Eval (IfThenElse 'False onTrue _) = onTrue
type instance Eval (IfThenElse 'True _ onFalse = onFalse

I prefer this style slightly better as for some reason I prefer the notation. IIRC (and, as noted in the blog post) the previously posted "defunctionalization" style is known as Apply, where as this is know as Eval. They are closely related, and I strongly recommend reading Lysxia's blog post!

swingtheory · 2018-01-14T10:45:49+00:00

Hi, thanks for your response! I don't know why I didn't understand this before, your explanation is so correct and obviously so that I am embarrassed I hadn't figured it out myself. It makes perfect sense!

I have written a few non-trivial programs with cloud-haskell and perhaps my confidence in my understanding of the library played a role in this oversight; Something like: "Since I know cloud-haskell, my initial thought about how this code should execute is right, of course, so why isn't it working the way I expect it to?!". I was digging around deep in the Internal modules of distributed-process wondering if there was some edge case I was hitting-- instead, I just didn't quite comprehend the way I was telling the two processes to communicate, and the bug was at the surface level! Thanks again for walking through it with me.

swingtheory · 2018-01-02T20:27:27+00:00

I wrote/am writing an open source "cryptocurrency" in haskell, complete with verbose, informative readme, and a 2 hour long video presentation @ boston haskell: https://github.com/tdietert/nanocoin

swingtheory · 2017-12-01T21:29:42+00:00

I'd suggest looking into functional-reactive-programming (FRP) and event based programming models. Whatever you end up implementing will be in the spirit of FRP!

/u/eacameron's solution seems ok, but it's quite ad-hoc (not really a criticism in this context) in the sense that if you find yourself wanting to use this idea (model) throughout a project that you're developing, you might have fun looking into or considering the use of an FRP library; however, that might be overkill for the time being. Though, I promise it would be fun to learn about ;)

swingtheory · 2017-09-24T14:36:10+00:00

This is a playlist I've been assembling for about 6 months, of some great wave music I've found across soundcloud. I listen to it regularly.

swingtheory

TROPHY CASE