In #Scala news, I just noticed SIP-69, “Existential Containers”: https://github.com/scala/improvement-proposals/pull/101
The wording needs work IMO, but I love this proposal. It tackles the not-unusual problem where you have a container full of instances of a type class, a small but fairly common pain in the butt.
There's only one good solution I know of, which I've built by hand repeatedly; this takes that pattern, and bakes it in concisely.
Looks like a fairly small change surface, and I'd definitely use it…
=> More informations about this toot | More toots from jducoeur@social.coop
@jducoeur i need to reread, but isn’t it containers of types that have a typeclass, since types don’t extend typeclasses? so it’s the problem of deriving the typeclass of a sum type where the members each have a typeclass instance?
=> More informations about this toot | More toots from arosien@fosstodon.org
@arosien Not quite: the problem is that you often need the specific typeclass instances of the elements -- which often varies a lot from element to element. You don't want the sum, you want the distinct instances, mapped to those elements.
So you wind up needing to package a pointer to the typeclass instance with each element. That's what this proposal reifies.
=> More informations about this toot | More toots from jducoeur@social.coop
@jducoeur ah got it, thanks
=> More informations about this toot | More toots from arosien@fosstodon.org
@jducoeur actually... are there particular designs where this pattern comes up? i don't think i've ever encountered this situation, but maybe i'm operating in some other corner of the design space...
=> More informations about this toot | More toots from arosien@fosstodon.org
@jducoeur
the most similar situation i have is where i have an enum of whatevers and a list of them to perform some aggregate action, so i end up folding over the collection and pattern matching on each element to know what case i'm in, then delegate to the per-case implementation. the pattern matching then becomes tedious.
=> More informations about this toot | More toots from arosien@fosstodon.org
@arosien I mean, there's a matter of taste here. I tend to avoid pattern-matching unless it's necessary: it implies that I've already lost track of my types, so my type-safety is a bit compromised. (And the structure of where the logic goes is very different.)
In general, type classes are an alternative to pattern-matching, essentially compile-time vs runtime dispatching. If you're comfortable with using pattern matching routinely, you don't need type classes as much.
=> More informations about this toot | More toots from jducoeur@social.coop
@arosien So in general, this comes up when:
That naturally leads to this pattern: if you've already committed to thinking in type classes, adding pattern-matching to re-find the types at each fetch kinda sucks.
=> More informations about this toot | More toots from jducoeur@social.coop
@jducoeur I'm too dumb to understand it, but I know some of these words :blobnom:
With scala now having a powerful and proper macro system couldn't these kind of extensions be build or experimented with it? Or compiler plugins?
Just thinking out loud 🤔
=> More informations about this toot | More toots from vascorsd@mastodon.social
@vascorsd Interesting question. I don't know whether this could be done as a macro. Possibly, but I haven't done enough grungy work with macros to have any confidence.
(Keep in mind that Scala 3's macro system is, intentionally, less powerful (but better-behaved) than Scala 2’s.)
Compiler plugin, sure -- but those are (intentionally) a pain in the ass to use for production code.
The pattern here is uncontroversial IMO: I do exactly this myself. This just makes it easier.
=> More informations about this toot | More toots from jducoeur@social.coop This content has been proxied by September (3851b).Proxy Information
text/gemini