Starter recipe for extensible interpreter using Final Tagless style

[afcondon]

Recipe Name

SimpleTaglessFinal

Recipe Description

Re-cast the first example in this repo: https://github.com/afcondon/purescript-tagless-final-examples into the Recipe style

[afcondon]

Not sure if this is good recipe material or not so go ahead and close if it's not

[milesfrain]

For those who know what they're looking for in the cookbook and are familiar with tagless-final style, this recipe may be helpful.

But another target audience of the cookbook are folks who just want to see a menu of building-blocks that they can use for their app, and I feel like a bit of explanation is required to make this topic digestible.

This may be a better fit for the DSL chapter of the book. We could even make the exercises a bit more involved (with less hand-holding) in this last chapter and suggest readers consult some specific sections of these papers for guidance.

[afcondon]

Yeah, that sounds right.

[and-pete]

You could go for a minimalist Final Tagless / mtl example that demonstrates the composition of functions that compsoe effectful functions that return Effect (Either e result), where the reader wouldn't have to understand another domain such as interpreters. This is based off of a question that came up in Slack the other day.

Something like this gist could be named maybe something like ComposeEithersFinalTagless: https://try.purescript.org/?gist=fb1897409a2542ab2991d91b5a217b18

And then you could have it listed against a ComposeEithersExceptT (..with functions returning ExceptT MyError m Foo/etc.). And instead of having a ComposeEitherStaircase, the README.md for each recipe could just show the unwrapping with staircases problem that the recipes are trying to solve with eihter Final Tagless or ExceptT.

[afcondon]

I think generally when we have multiple types like data Foo = Foo in a recipe is a sign that it's just that little bit too abstract for a recipe, in that it's asking a reader (who we'd like to imagine might be just dipping their toe in the water of PureScript and FP) to hold extra abstractions in their mind while they try to see the shape of the solution on offer. That's how i remember it being as a total beginner in Haskell anyway.

i now think that examples like mine and yours (@and-pete) would actually be best in some annex to the useful list that's currently on the try.purescript.org landing page

[and-pete]

Yeah, I tend to agree with you now too about those types.

I probably should have kept the example more closely replicate what the question on Slack was. The question asker had several functions. An initial Aff (Either Error Json) where they wanted to have the Json chained into several subsequent Json -> Aff (Either Error Json).

I thought it might be less for a recipe reader to deal with if we didn't expect them to have any familiarity with handling the Aff type within main or any familiarity with Affjax/Argonaut's types.

Do you think there's a middle ground or is Final Tagless entirely out of recipe scope? :)

[afcondon]

I think what's in and out of recipe scope is totally up to Miles and Jordan but how i personally see it is that cookbooks are a great asset for the sort of person who's (a) curious about the language, in this case PureScript (b) likes to learn by doing (c) comes to the cookbook with a desire to achieve some specific small win.

The more specific example from the SO question (threading Aff (Either Error Json)) does sound cookbook-ish to me, i totally think you should suggest it.

[JordanMartinez]

Determining what is a good/bad recipe is something we're still figuring out (see #79). We want recipes to solve just one problem (at the cost of having many recipes that do similar things) rather than one large recipe that might better exist as its own repo.

[JordanMartinez]

Thoughts on #193 in regard to this recipe request?

[afcondon]

i think it's an excellent contribution but maybe proves your own point in your comment above, @JordanMartinez - i think what you have there is something like a skeleton app / architecture...it's somewhere between a recipe and an example program like Real World Halogen. That said 180 LOC is not long, it's more that its showing how several things fit together.

It seems so useful tho that my $0.02 would be that it should stay in cookbook unless/until you find a place for things of that intermediate length, maybe? And it's a win that it's in the cookbook with the package set compatibilty and CI that that guarantees.

[JordanMartinez]

I think its the simplest example with enough complexity to be something worth storing here. I think I also realized later today that I likely could have used ExceptT to clean up the control flow a bit better.