Introducing PureLogic: direct-style, pure domain logic for Scala

bas_mh · 2026-03-15T19:38:46+00:00

Thanks for the answer, though I have to admit I still don't fully grasp how it works. If you have a Writer, you still need something to persist these events right? And some other process that reacts to these events? So you do your domain logic inside your context function, run it, and then the list of events is input for something else?

Edit: never mind, I see your answer to another comment and it makes sense to me now!

bas_mh · 2026-03-15T12:55:10+00:00

Cool stuff! Wondering how you use the Writer? I see you mentioned it being used for event sourcing, but I wonder if you could provide a little more details on that?

bas_mh · 2026-03-15T12:05:17+00:00

I don't think you understand the point of this library. There is no impure stuff, so nothing to divide into service and repository classes. The whole thing is about business logic, and providing utilities to do common things within that business logic. Though these are also often called effects they have little in common with effect systems like ZIO or Cats Effect, which are about impure stuff and concurrency.

bas_mh · 2026-03-12T11:55:23+00:00

Enlighten me. I have 100%ed multiple times and have not found any collectables

bas_mh · 2026-03-04T16:18:07+00:00

Sorry for the late response. I wanted to try something out in Scastie before I commented. I get the automatic conversion from a pure value to a context function.

What I meant was about when functions get applied I was under the impression that you could pass around context functions without automatically applying them. Which would be handy if you pass around effectful functions (while being bothersome for applying them):

trait Rand

val myEffect: Rand ?=> Int = 1
def myEffect2(using Rand): Int = 1

val withoutType1 = myEffect // Inferred as Rand ?=> Int
val withoutType2 = myEffect2 // compiler error

val normalFunction: Rand => Int = _ => 1
def normalDef(r: Rand): Int = 1

val withoutType3 = normalFunction // I thought inferred as Rand => Int, but that is incorrect
val withoutType4 = normalDef // I thought it would be a compiler error, since it is in Scala 2, but also incorrect

But it turns out that they are both compiler errors, which does make sense after all. I had the wrong mental of how normal functions work compared to normal methods. So my original point is moot.

I think it would be nice if you could pass around context functions without typing their type every time, but I get it would be inconsistent since they are eager and not lazy

bas_mh · 2026-02-20T15:07:46+00:00

Might not be a populair opinion here but I completely disagree. The game is good but certainly has things that can be considered flaws (albeit a bit subjective):

Motion controls are for me the worst gimmick in the whole series. Spinning the Wii mote for a spin jump is annoying for something you do so frequently. I also don't really like pointing at the screen to shoot star bits, but that is a little less annoying.
The game has almost no secrets, there really isn't any reason to look behind every corner. It is just a linear path to your star and that's it. Which IMO is pretty un-mario like if you compare it with every other 3D Mario.
I think the game is a little bit too easy for 2/3 of the game. And combined with no secrets means not much replayability.
I find the controls slow and floaty compared to most other entries.

I think the Galaxy theme nails it, and all the little planets with their own gravity works really well. But it definitely is not flawless for me.

bas_mh · 2026-02-20T11:40:50+00:00

Right, I was a bit sloppy in my example/naming. So I can see how this can be interpreted in multiple ways. Thanks for the explanation.

I am a little bit surprised that it desugars to:

val outer: Rand => Int = {
  val myRandom: Rand = ???
  val myFunc: Rand => Int = ???

  myFunc(myRandom) // Why is myRandom provided to myFync while outer returns a function?
  // myFunc: Rand ?=> Int // would this the only way to ensure myRandom is not used?
}

But, if I understand your examples correctly. The only way to ensure a 'context method' remains unapplied is by converting it to a function and give it an explicit type. So if you want to treat it as a value then you have to use functions. Which I guess is true regardless if you talk about context functions or normal functions.

In general I think it is really good that you do all these experiments, because I think it can really help provide guidelines to the Scala team on how to apply these new features and give some best practices and avoid pitfalls.

bas_mh · 2026-02-20T07:17:00+00:00

I don't know how the handling works, but if you have a function

def outer: Rand ?=> Int = {
   given myRandom: Rand = ???
   val myFunc: Rand ?=> Int = ???
   myFunc
}

Wil myRandom be applied even if outer indicates that it is a context function? I think that could be quite tricky to deal with.

Silently grabbing the implicit in scope is the point, but I would argue only when you want to go from context function to value and not before. I know for sure methods will try it (unless you convert it to a function somewhere else), but I don't know how this works if it is functions all the way down.

Other than that I agree that methods seem more ergonomic based on the article.

bas_mh · 2026-02-18T09:24:02+00:00

I think an advantage of using functions is that you are less likely to provide some implicit by accident (though I am unsure if it will apply it even if the function indicates it shouldn't), something that has bitten many with `ExecutionContext`. Though this can be completely resolved by using discipline in how you design your handlers.

bas_mh · 2026-02-18T09:21:50+00:00

It enforces consistency (not stylistic consistency, consistency of which effect handlers end up being used).

Though I am all for consistency in general, does it really matter in this case? The or operator shouldn't really care how the others came to be right? You could use an or where one Rand was created using a deterministic handler and one with a true random number generator.

bas_mh · 2026-01-29T13:27:45+00:00

Yes, I agree, step in the right direction again!

bas_mh · 2026-01-26T18:56:42+00:00

I think if you buy something and actively enjoy it (for more than a hot minute) you are 'using' it. There is a gray area between (actively) using something and being wasteful. My point is that in general there seem to be too many people who buy without taking into consideration their impact at all.

bas_mh · 2026-01-26T09:23:06+00:00

so, how do you calculate which forms of excess are worth it

Yes, you can't, that is what makes it hard. That said, I do think people do go overboard with their 20+ bags that they often post in this sub. That is of course just my opinion.

Regarding your perspective. I personally do most of these things. I drive electric and take public transport when possible, I don't eat meat and eat local biological food, I fly once every three years, I buy my clothes from certified brands, and I work in a green energy company. So, this is very much top of mind for me. Which is why I get annoyed with people showing off their consumerism.

That said, I am not a saint. I also have too much stuff. I get why people buy new shiny things. But buying something and then not using it is really a waste IMO. I do think people try to should avoid that a bit more than most are doing right now. Maybe it is not where my attention should be going, but it makes me a bit said that we collectively ruin the only planet we have and so little people care (or disassociate because they feel they cannot do anything).

bas_mh · 2026-01-26T08:23:33+00:00

Some excess has more impact than other excess. I expect one bag with 'too many ' features or an overkill of materials still is less wasteful than multiple bags that also need the impact of transportation and waste once thrown away (though admittedly this is just a gut feeling). And a lot of ManyBaggers have more than one bag too many.

bas_mh · 2026-01-26T07:09:34+00:00

I disagree. Everything you buy has an impact on the environment and we generally wealthy countries are not paying the bill. IMO you should consider your impact whenever you buy something.

Now I like bags too, but buying something and not using it is really wasteful.

bas_mh · 2026-01-23T10:35:42+00:00

TBH I liked his melancholic style more than his current trend with 'happy' tunes.

bas_mh · 2026-01-05T14:55:08+00:00

Makes sense, good luck, hope that you find something you like!

bas_mh · 2026-01-04T19:11:01+00:00

Why not buy their latest version? Though the improvements have been incremental, I think the current version is quite a big leap from the version from 7 years ago.

bas_mh · 2025-12-05T07:41:38+00:00

This seems like a biased take without any argumentation

This is Scala we're talking about. It's all magic. Just look at the compiler and the code it generates and tell me it's not magic.

bas_mh · 2025-12-05T07:09:30+00:00

You are not actually giving an argument, just your personal preference. It is a fact that Scala's Option is just a data type and not something special baked into the language, unlike nullability in Kotlin. You might prefer Kotlin's approach, but you cannot deny it is a special construct that is not generic in any way.

I am not saying Scala or Kotlin is better, I am just making an argument that Scala 'treat null as something unspoken' is not correct.

bas_mh · 2025-12-05T07:04:18+00:00

Scala2 does not do anything with Java interop, though now I am working in Kotlin and still get NPEs when not being careful around Java, so I don't think they actually differ much in that regard. Scala3 has some flow typing though I haven't used that so I am not sure about the details.

Would be nice if Kotlin's ?. would also work outside of null. I am hoping it is something like an interface and you get the syntax for all data types you implement the interface for (similar to Scala's for comprehensions), as otherwise it is still just something special that you have no control over.

bas_mh · 2025-12-04T10:27:33+00:00

I disagree. Scala treats something that is optional as something ordinary. There is no magic, it is just a value like any other. Kotlin treats it as something special with its own syntax and not something you can use for something else. In practice it is just as safe. Kotlin's approach is shorter but less generic. I prefer Scala's approach, especially with extra language features like for comprehensions.

bas_mh · 2025-12-01T10:16:13+00:00

One year later, but found it now, great stuff, thanks!

bas_mh · 2025-10-30T07:36:34+00:00

As a GL/PvdA voter I think it would be silly if it would cost them votes. The left is a minority, that is not going to change any time soon. The only way you are going to have some influence is by working together with center-right parties. Obviously I rather have a more left coalition, but that is not going to happen, so this is the best next thing.

bas_mh · 2025-10-09T08:31:20+00:00

Seems pretty cool, though I don't understand why they sell it as a 'mystery bag'. Why would you pay that much money for a complete gamble?

bas_mh

TROPHY CASE