Conversation

This has some good "nerd snipe" potential for programming language designers. In grad school, I was poking around possible solutions to this (though sadly didn't go far enough). A possible direction - modules could expose all of their implied imports to configurability.

Quote Tweet

Jonathan Müller

@foonathan

· Mar 30

I wrote my thoughts about writing a new type vs adding new functions to change behavior: saturating_add vs. saturating_int – new function vs. new type? foonathan.net/2022/03/behavi #cpp #cplusplus

Joshua Barretto

@jsbarretto

Apr 4

I wonder whether you could do this through an effect system. You could have an 'overflow' effect that can be handled in a manner easily and cleanly chosen by the caller.

Replying to

and

Oh, good idea! I guess in practice you'd need an effect system lightweight enough in terms of runtime overhead… which could be a tough ask at the moment? But could be fun to experiment with?

11:21 AM · Apr 4, 2022Twitter Web App

Replying to

and

So this is something I've been thinking about with my effect system which in the process of being born (preliminary codegen & typing works). Right now, I implement it as stack-walking but one of my goals is to monomorphise *everything* (no runtime HKTs) a consequence of... (1/n)

Joshua Barretto

@jsbarretto

Apr 4

...this is that generic effects (i.e: where generic parameters aren't specified in an effect type, such as async/await) codegen doesn't really compose and can only be done at a best-effort level. I am very unhappy with this, so I've been thinking of changing effect types to (2/n)

Show replies