Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Paul Carey
@paulcarey
thanks for the details
Rob Norris
@tpolecat
no worries
Free is out of style but it's still great for some applications.
Paul Carey
@paulcarey
what has superceded it (generally)?
Rob Norris
@tpolecat
Tagless style is much more common now for writing DSLs and APIs in general.
Paul Carey
@paulcarey
ok, I've been reading a bit around free, tagless final, mtl etc. and trying to find my bearings has been a bit tricky
Rob Norris
@tpolecat
Free is good if you really need to limit what the user can do (the algebra is exactly your data type's (i.e., F's) constructors plus Monad. No more, no less. Sometimes you want this.
There's also FreeApplicative if you want to limit them to applicative composition. Among others.
In general I would steer you toward tagless. Free is kind of a specialized weirdo thing at this point.
Paul Carey
@paulcarey
ok :) thanks
Rob Norris
@tpolecat
@gvolpe's book is about building programs this way, you might find it helpful https://leanpub.com/pfp-scala
Paul Carey
@paulcarey
great! I hadn't come across that
Fabio Labella
@SystemFw
the idea behind Free is great for implementing advanced monads like IO or Stream (which are implemented with a similar strategy even though they don't use Free literally)
tagless final is easier for applications abstractions, where most effects are facades/mini-languages over IO and mixing different languages is pervasive
there are actually a lot of interesting connections between Free, final tagless, Monad.flatMap and Monad.join, if you're interested
Adam Rosien
@arosien
they're both just mumble-jimmies in the category of jiggle-donutoids
Brian P. Holt
@bpholt

I believe pretty strongly in doing local releases for OSS because of the attribution it provides, since attribution and reputation are technically the only trust mechanisms we have to go on.

For our internal stuff, my company only allows releases from CI because we don't want to trust any single individual to release code. PRs have to be approved by someone other than the author(s) of the code, and then it's published on merge.

(I haven't figured out how to make this strategy work with sbt-ci-release yet, so for the most part we're using sbt-release instead. Maybe if it only released tags that were on the default branch, since those commits must have had to go through the PR approval process? Idk.)

Ethan
@esuntag
So my (loose and probably bad) understanding is you might use Free over tagless if you want something that the user isn't going to modify or extend at all?
Rob Norris
@tpolecat
Yes, if you want to prevent the user from extending the algebra beyond exactly your [G]ADT constructors and monadic composition.
The end result is easier to use than tagless because you're just dealing with data. You don't have to thread an effect parameter (typically) everywhere. So your business logic can be very concrete, which is easier for beginners I think.
Ghost
@ghost~5f2c8104d73408ce4feb8fb3

:point_up: September 24, 2020 5:52 PM @tpolecat

Free is kind of a specialized weirdo thing at this point.

:laughing: ... glad to see attitudes have changed in the last few years. I was mocked for saying this in my book: "It was trendy, circa 2015, to write FP programs in terms of Free".

Paul Snively
@paul-snively
I’m even weirder: I don’t see the problem with writing everything in IO.
Ghost
@ghost~5f2c8104d73408ce4feb8fb3
you're not wrong
Ryan Zeigler
@rzeigler
tpolecat makes himself into the hipster ;-)
Daniel Spiewak
@djspiewak

I use Free for prototyping sometimes. It can be a useful tool to see how your effect algebra teases apart at a granular level without actually committing to an implementation, but it really only works for algebraic effects, and you very quickly bump up against some annoying type metaprogramming problems if you want to push it.

FreeT was a pretty awesome kernel for Coop, and I don't regret that design choice, but similarly I wouldn't put Coop into a production code path.

I think we've pretty much all learned that there are better ways of encoding effect composition than Free, and simultaneously the mocking it enables, while powerful, isn't that useful in practice, even with tools like Smock. That kind of mocking is usually better achieved with a sprinkling of polymorphism, whether via final tagless or some other encoding.

It's still a cool toy though

Fabio Labella
@SystemFw
still, IO/Stream etc are encoded with the same idea, so whilst the set of people dealing with implementing those is tiny, a lot of people end up using that encoding indirectly (the data structure encoding, if not the parameterisation that Free gives you)

I don’t see the problem with writing everything in IO.

It's not unlike writing everything with String, you can do it and there's a lot of code doing just fine with that, but generally better modelling yields better maintainability and ease of undestanding

Daniel Spiewak
@djspiewak

It's not unlike writing everything with String

…that is absolutely amazing insight

I never thought of it that way before
Fabio Labella
@SystemFw
final tagless over IO is the same as case class Id(v: String)

I never thought of it that way before

really!?

well, cool :P
Daniel Spiewak
@djspiewak
:-)
Fabio Labella
@SystemFw

final tagless over IO is the same as case class Id

actually it's a bit more than that cause it also tackles the testability/dependency injection aspect, but there are other techniques for that

Daniel Spiewak
@djspiewak
yeah I never made the connection to newtyping
yeah it's newtyping + polymorphism, basically
Fabio Labella
@SystemFw
so all other things being equal, the domain modelling aspects wins it for me
over just IO or ReaderT

yeah I never made the connection to newtyping

it really boils down to how you view effects

Daniel Spiewak
@djspiewak
yeah
Fabio Labella
@SystemFw
the transformer view, where you assemble things, doesn't really have that connection
Daniel Spiewak
@djspiewak
I view effects as sort of like the fabric of the cosmos
like, they're the spacetime of my program
transformers are gravity
Fabio Labella
@SystemFw
the algebraic effects view (in the Eff/Koka sense), where you just layering little languages over an omni-powerful thing, does have it
and that's how I see it
actually can't wait for Scala 3, where between implicit hints, and using parameter lists, we can have something more ergonomical than any other language
I need to write something about that
Daniel Spiewak
@djspiewak
oh yeah, leveraging Scala 3's canonical instances is going to be amazing
like there's so much there which hasn't been tapped yet