This is absolutely neat.
Algebraic Effects in Practice with Flix
31–40 of 55 posts
Re: Algebraic Effects in Practice with Flix
#32wait, associated types are amazing! i have spent more time than is healthy goofing around with doing more things than is probably sane via metaclasses, and this concept would actually make life SO much cleaner… i was already predisposed to liking this post because i feel strongly that algebraic effects (and delimited continuations) are amazing and being slept on, but having poked around the docs and blog a bit i am beyond impressed. baasically every “choice” made with this project is one that i either agree with or i’ve never seen before and is quite clever. for example, putting polls in the middle of blog posts to ask the reader what kinds of things would be most relevant for them to touch on in future posts. maybe others have done it before— i don’t know— but what a great way to run a programming language project, where i can only imagine that trying to get in the minds of actual or prospective users is one of the hardest tasks— probably more so than the implementation and development of the language itself! will be watching this project for sure!
Re: Algebraic Effects in Practice with Flix
#33wait, associated types are amazing! i have spent more time than is healthy goofing around with doing more things than is probably sane via metaclasses, and this concept would actually make life SO much cleaner… i was already predisposed to liking this post because i feel strongly that algebraic effects (and delimited continuations) are amazing and being slept on, but having poked around the docs and blog a bit i am b…
in that same vein, “nothing runs before main” is actually an extremely based take. i suppose this is another take informed by my python (mis-)adventures, but it is so unfortunate that you don’t have just a liiittle more flexibility in terms of the order that code, imports, etc. are evaluated. it is hard for me to give a concise answer as to why i felt this pain, but it is an idea that immediately feels like respite, and gives programmers more leverage / lattitude in making libraries / other code simpler and ergonomic.
Re: Algebraic Effects in Practice with Flix
#34The 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. Ev…
Doing something a bit vs almost completely can have a significant difference in practice - having a way to maybe avoid nulls doesn't solve the million dollar problem, but making non-nullability the default arguably has (see Rust, Kotlin, etc).
An even better example would be Rust's memory safety. Sure, there is still unsafe, but it being used very sparingly has reached its goal.
So I think a new language where 'pure' is the default (with a few, locally scoped escape hatches), and effects are "mandatory" would actually be pretty effective at reaching its stated goals.
Re: Algebraic Effects in Practice with Flix
#35> 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.
One important thing that languages with algebraic types can usually do and most others can't is being generic in this "colorness" - precisely because this is the color problem they are solving.
So they can e.g. have a `map` function that can take a pure lambda, or an effectful one, and based on that itself will become pure or the given effect. Colors will stop being "infectious" without limits, you can now better barrier their reach.
Re: Algebraic Effects in Practice with Flix
#36Earlier quoted context omitted.
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.
Well, you can reuse all that man-hours that went into the JVM - this is what Flix does!
Re: Algebraic Effects in Practice with Flix
#37I 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
on 1: i want to stab my eyes out. you cant surely implement any monadic and/or effect system on top of any native generators and effect.ts is no exception, but this is just so wrong, buegh
on 2: can you please reformulate and elaborate more? i have re-read what youve said 5 times and it feels like gpt written rambling, sorry
Re: Algebraic Effects in Practice with Flix
#38The 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/
> The only differences are in naming choices
Naming choices matter, as does syntax.
Re: Algebraic Effects in Practice with Flix
#39Maybe 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?
Implementing an interface results in a class that implements it. From then on, the fact your class implements that interface is entirely obscured from your code. In the case of tracking effects, this is clearly undesirable. (Also, in a language that doesn't have classes, implementing interfaces is difficult for me to think about.)
In the case of algebraic effects, they're functions with type signatures explicating the effects the function has. Those don't go away until somewhere nearer the edge of your program, outside the core, you say "by the way, use this to handle those effects"
Effect handlers also give you control over continuations so you can sequence effects explicitly, which is—speaking as someone who writes a lot of code in a language that has algebraic effects as a core part of the language (Unison)—really powerful. Deciding in some instance how you prioritize IO vs Exceptions, making a thrown error go away and replacing it with an HTTP effect that, wayyyy far away from this code handles all HTTP calls by attaching a self-signed certificate when doing the SSL handshake, or whatever, is very nice.
The more I write in this style, the more interesting techniques I come across.
Re: Algebraic Effects in Practice with Flix
#40There are some parallels with Zig's current move toward an IO-object, and requiring it to be passed to any function that wants to do IO (so that it can call methods on that object). Admittedly, it's a more limited and less elegant implementation, but it's a small step in this direction.