Live data from Hacker News

Algebraic Effects in Practice with Flix

relax.software

11–20 of 55 posts

Re: Algebraic Effects in Practice with Flix

#11
post #9

Earlier quoted context omitted.

yeah, most times its solved by side-stepping the strict type system and making an exception for debug prints. but this is not a real practical solution, this is a stupid workaround born from overinsistence on "beautiful" design choices.

It seems to me like a pragmatic compromise and very much a real solution. What would you consider a real solution that isn’t overinsisting on beautiful design choices?

putting strong static type system into optional compiler pass. yes, I know this may be null is some cases, let me run my program for now, I know what I am doing. yes, there are unhandled effects or wrong signature, just let me run my test. yes, that type is too generic, i will fix it later, let me run my god damn program.

Re: Algebraic Effects in Practice with Flix

#12
post #8

The algebraic effect handler pattern is a much simpler mental model than monads. And is transferrable to other languages pretty easily. See something like https://github.com/doeixd/effectively in Typescript

1. The effect data type admits an instance of monad, like arrays or option or result. Not sure why would you put those in competition, an effect is a supercharged ReaderResult. The only differences are in naming choices, traverse being called foreach, flat map being called "and then", etc.

2. There is a much more popular and robust implementation of effects for Typescript: https://effect.website/

Re: Algebraic Effects in Practice with Flix

#13
For anyone using a dark theme with their browser or OS, the string constants actually have interpolation syntax in them. It's just black, on a black background. For example, I thought it was strange their error message was:

    "Error:       "
Turns out its actually:

    "Error: ${msg}"

Re: Algebraic Effects in Practice with Flix

#14
post #6

> Solving the “what color is your function” problem. Eh. I currently use monads for my effects, and am open to the idea of language-based effects. But this isn't a solution to the colour problem - it is the colour problem. The compiler stops you accidentally calling red from blue. If you want to do it deliberately, you change the caller from blue to red.

This depends on the implementation. In effect typescript land, synchronous and asynchronous code is treated equally as soon as it's lifted in an effect.

Re: Algebraic Effects in Practice with Flix

#15

I really want effects to shine and thrive, but since this is a very academic topic, only academic people engage with the research and it comes with academic pedantism, perfectionist worldview, strange attraction to beautiful consistency, etc. This automatically places effect research FAR from any practicality and grounded realism. 2 points, as examples: 1. Ever tried adding a simple print statement for debugging purp…

1. Nonsense [1]

2. It's implementation dependent, but of course you lose tracing, etc if you want to just log with language primitives, which is why you shouldn't when every effect system offers you tools to do so. If you want a system where each side effect is traced, monitored and encoded as a recipe, then you use the effectful version.

[1] https://effect.website/play#769a55e0ea0a

Re: Algebraic Effects in Practice with Flix

#16
post #9

Earlier quoted context omitted.

It seems to me like a pragmatic compromise and very much a real solution. What would you consider a real solution that isn’t overinsisting on beautiful design choices?

putting strong static type system into optional compiler pass. yes, I know this may be null is some cases, let me run my program for now, I know what I am doing. yes, there are unhandled effects or wrong signature, just let me run my test. yes, that type is too generic, i will fix it later, let me run my god damn program.

This puts a lot of extra conditions on the runtime; you basically have to implement a "dynamically typed" runtime like Javascript. In doing so you lose a lot of performance. Google have invested something like a century of man-hours into V8 and on typical benchmarks the performance is about half of Java's, which in turn is typically about half of C / Rust's performance. That's a pretty big compromise for some.

Re: Algebraic Effects in Practice with Flix

#17
post #8

The algebraic effect handler pattern is a much simpler mental model than monads. And is transferrable to other languages pretty easily. See something like https://github.com/doeixd/effectively in Typescript

I use effects to make guarantees about what the code will and won't do.

When Option was retrofitted onto Java, the NPEs didn't disappear. We got Options that could be null, but more importantly, devs (and the standard library) continued to use null liberally. We never ended up at the tautological goal of "if I have a Person, then I have a Person".

I am equally skeptical of bolting on effect systems after the fact. Even if one of these effect systems becomes 'the main one' and starts showing up in standard libraries, we'll still end up with declared-effectful code and undeclared-effectful code, but will again fall short of the goal, declared-effectful code.

Re: Algebraic Effects in Practice with Flix

#18

"The only one that I know of besides Flix is Unison." huh? Koka, Effekt

Regarding Effekt, here's an interactive introduction on how to use its effect system: https://effekt-lang.org/tour/effects

Other pages also contain some more advanced details and casestudies on effect handling

Re: Algebraic Effects in Practice with Flix

#20
post #19

Maybe I’m not getting it, but isn’t this just interfaces and implementations from the OO world? For example their movie one is: interface MovieApi { List getPopularMovies(); } What are effects providing over this?

I wasn’t aware of effects until I read the article, but I like the idea. The example you have is just an interface. Effects work a bit like boundary hooks. A pure function only works on things internal to its scope, and so it has no effects. An impure function might affect things outside of its scope, and may want to allow the caller to hook when those effects occur. Think a function that uses the gpu. That’s a side effect, and the function should be decorated to reflect that.

I’m guessing some languages would allow for checking to ensure that any induced effects are correctly noted and advertised so that the system as a whole can be more easily reasoned about.

Post reply on HN