I wonder if this will wind up being a category of problems and the solution is a separate "system" set of effects (effectively `({user}, {system})`) or if this one-off extension is all that will be needed.
Either way, extremely well explained both in motivate and implementation!
Honestly a pragmatic solution would be to have printing to stderr (debug print, logs, whatever) not be an "effect". then as an added benefit if its context is elided out in an optimization you know.
As I understand, Flix implements a system to type not only a return type but an Effect too. If that's the case, It's not an overkill solution? and why?
> Hence, when the compiler is run in production mode, we disable the lie that allows the implicit Debug effect. As a result, using dprintln in production mode causes a compilation error.
The team can’t seem to make up its minds of the language is intended for high performance or not. They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code (eg imagine something like a browser and you’re trying to figure out some weird behavior that’s difficult to catch in a debugger but too slow to reproduce in a debug build or even not reproducible due to different timings resulting in different race conditions)
Also blaming the users of your language for your language not being able to meet their needs isn’t a good look. It suggests the language is probably attracting the wrong users or positioning itself incorrectly in the market place.
How does Flix decide if it’s worth it to auto parallelize a map operation? Eg, if it’s a very trivial map operation, it may add overhead to parallelize it
Is there a target use case(s) for this language, at least initially? It seems to focus on programming in a platform-independent sense, but where is it most likely to actually succeed? Are there particular OS’s or other languages that they try be particularly compatible with?
To do this you made the Debug effect a special case in the compiler. Won't users want to create their own special effect types? Could these special effects be expressed within the language itself instead of being compiler builtins?
That's why I don't like "purity above all costs" languages.
It's not just print debugging. It's also logging. Oh, you want/have to add useful/required logging? Good luck refactoring your entire code to thread IO everywhere.
12 comments
[ 3.0 ms ] story [ 32.6 ms ] threadEither way, extremely well explained both in motivate and implementation!
I'm curious what other languages are trying to achieve such?
The team can’t seem to make up its minds of the language is intended for high performance or not. They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code (eg imagine something like a browser and you’re trying to figure out some weird behavior that’s difficult to catch in a debugger but too slow to reproduce in a debug build or even not reproducible due to different timings resulting in different race conditions)
Also blaming the users of your language for your language not being able to meet their needs isn’t a good look. It suggests the language is probably attracting the wrong users or positioning itself incorrectly in the market place.
It's not just print debugging. It's also logging. Oh, you want/have to add useful/required logging? Good luck refactoring your entire code to thread IO everywhere.