The Flix Blog

Making Flix Compiler Errors Helpful and Delightful

Magnus Madsen — Fri, 30 Jan 2026 00:00:00 +0000

Inspired by Elm's Compiler Errors for Humans</a> and Compilers as Assistants</a>, we recently took a step back and reworked every error message in the Flix compiler.

Here is what you can look forward to in the next version of Flix:

All error messages now have semantic syntax highlighting. For single-line errors: 

And for multi-line errors: 

Simple errors are kept brief: 

Whereas complex errors come with explanations and examples: 

And, when possible, with suggestions for a fix: 

For very complex errors, we now give an in-depth technical explanation: 

That's all for now.
Hope you enjoy our new colors!

Will LLMs Help or Hurt New Programming Languages?

Magnus Madsen — Fri, 02 Jan 2026 00:00:00 +0000

Recently, I’ve seen a number of discussions circle around the same question:

Will large language models (LLMs) help or hurt the adoption of new programming languages? </blockquote>
It is a fair and timely question. As an academic researcher in programming language design and theory, and as the lead developer of the Flix programming language</a>, will I soon be out of a job? Well, maybe not!
In this post, I want to explore whether a modern LLM — here, Claude Code (Opus 4.5) — is able to program in Flix. This is an interesting question because the amount of training data, e.g. Flix source code, is tiny compared to what exists for languages like Python and JavaScript.
Given that LLMs are reasonably good at translating between natural languages, e.g. from English to German, I think there is good reason to believe that they can also support new programming languages, if those languages are syntactically and semantically similar to existing ones.
But what happens when a new programming language introduces entirely new syntax and semantics? For example, the Flix programming language is built around effect-oriented programming. Will Claude be able to use that?

Aside: How much information about Flix is actually in Claude’s training set? Surely, Anthropic has scooped up our research papers, vacuumed our documentation, and gobbled our source code. Yet Flix evolves rapidly, and some information, e.g. from early research papers, may already be slightly outdated. </blockquote>
Experiment: Vibe Coding Tic-Tac-Toe</h2>
Today, we will "Vibe Code" (I dislike that term) a Tic-Tac-Toe game in Flix using Claude Code with the Opus 4.5 model. I chose Tic-Tac-Toe because it is a well-defined game that requires a moderate use of effects.
My intuition is that writing a new Flix program from scratch is harder for an LLM because there is no codebase it can gradually evolve, where the exsting syntax and semantics can serve as examples. There is only the LLM itself and any information we put into its context.
We begin by creating an empty Flix project:
$ mkdir tictactoe $ cd tictactoe $ flix init </code></pre>Next, we are going to help Claude by downloading the entire Flix API</a> reference and the Flix Book</a> documentation: $ mkdir -p docs $ cd docs/ $ wget -r -np -k https://api.flix.dev/ $ wget -r -np -k https://doc.flix.dev/ </code></pre> The two downloads take a few minutes. If you’re reading this blog post, you have my permission to crawl our documentation just like we did above. Next, we create a CLAUDE.md</code> file with the following text: # Overview This is project is written in the Flix programming language. ## Documentation - **API Reference**: `docs/api.flix.dev/` - **Documentation**: `docs/doc.flix.dev/` ## Flix Compiler Commands The `flix` compiler is available on PATH and supports the following commands: - `flix check` - Check code for errors - `flix run` - Run the project ## Effect System Flix has an effect system. Documentation is in `docs/doc.flix.dev/`: - `effect-system.html` - Core effect system concepts - `effect-polymorphism.html` - Effect polymorphism - `effect-oriented-programming.html` - Effect-oriented programming - `effects-and-handlers.html` - Effects and handlers </code></pre> We explicitly instruct Claude on how to run the compiler and what documentation to consult about the effect system. We can now start. We run claude</code> and enter plan</code> mode. We give it the following prompt: Let us write a tictactoe game in Flix. The game should ask the user for a grid size (e.g. 3x3 or 4x4) and then prompt the user for a move. Check that the move is valid according to the rules of tictactoe. After each player move, the AI makes a valid move. A player wins when they have three consecutive x’s or o’s. Use the Console effect for user input and output. Use a functional data structure to store the game state. Use a recursive function for the game loop. Use the Logger effect to log all moves in the game. Write your own custom handler for Logger that writes to a logfile using the FileWrite effect. Consult the Flix documentation as necessary during planning. </code></pre> The prompt is reasonable, but not very polished. We let Claude chew on the instructions and it comes back with: I’ll help you create a Tic-Tac-Toe game in Flix. Let me first explore the Flix documentation to understand the effect system, Console, and FileWrite APIs. </code></pre> After a few minutes, we are asked a few questions, including: How sophisticated should the AI opponent be? ❯ 1. Random valid moves AI picks any random empty cell - simple to implement 2. Basic strategy AI blocks wins and takes winning moves when available 3. Minimax algorithm Optimal AI that never loses - more complex implementation </code></pre> Initially, I wanted to pick (3). However, choosing (1) is actually more challenging, because it requires Claude to use the Random</code> effect, whose handler introduces the primitive NonDet</code> effect. Claude will have to figure this out on its own. We make our choice: Now I have clear requirements. Let me design the implementation plan. </code></pre> After about seven minutes of Clauding...</code>, which involves reading both the Flix API reference and documentation, including Random.html</code> (which looks promising), Claude reports back with the full plan (which I have abbreviated): 1. Data Type Definitions ... type alias GameState = { board = Board, size = Int32, currentPlayer = Player, moveCount = Int32 } type alias Move = { player = Player, row = Int32, col = Int32 } ... 2. Custom Logger Effect eff Logger { def logMove(m: Move): Unit } 3. Core Functions ... 4. I/O Functions ... 5. Logger Handler with FileWrite def handleLoggerWithFile(logFile: String, f: Unit -> a \ ef): a \ (ef - Logger) + FileWrite = run { f() } with handler Logger { def logMove(m, resume) = { let line = "${m.player} played at (${m.row + 1}, ${m.col + 1})\n"; FileWrite.append({str = line}, logFile); resume() } } 6. Recursive Game Loop def gameLoop(state: GameState): GameResult \ {Console, Logger, Random} = ... 7. Main Entry Point def main(): Unit \ IO = let logFile = "game_log.txt"; FileWrite.runWithIO(() -> handleLoggerWithFile(logFile, () -> Random.runWithIO(() -> Console.runWithIO(() -> startGame() ) ) ) ) |> ignore Effect handling order (inner to outer): Console -> Random -> Logger -> FileWrite -> IO 8. Implementation Steps ... 9. Win Detection Strategy ... 10. User Input Format ... </code></pre> Overall, the plan looks reasonable, but there are a few issues: Claude wants to define its own Logger</code> effect instead of using the Logger</code> effect from the Standard Library with a custom effect handler.</li> The main</code> function, while reasonable, does not use the more idiomatic run-with</code> construct, nor does it use default handlers.</li> Claude wants to use records for GameState</code> and Move</code>. This typically trips up Claude because Flix uses rec#field</code> for field selection, not rec.field</code> which is used for Java interoperability.</li> </ol> We could give Claude instructions to resolve (1) and (2), and warn about (3). But instead, let us see how well Claude does without further help. Later, we can return and ask Claude to refactor (1) and (2). We proceed: The plan is approved. Let me set up a task list and start implementing. </code></pre> Claude generates about 350 lines of code and asks for permission to use the Flix compiler which I grant. The project contains 20+ errors (including parse errors, name resolution errors, and type errors). Claude says: I see several issues. The main ones are: 1. Logger is already defined in the standard library - I need to rename it to GameLogger 2. The backtick syntax doesn’t work with qualified names - need to use Int32.mod(index, size) </code></pre> Claude has discovered that Logger</code> is already defined, so it (incorrectly) decides to rename its own Logger</code> to GameLogger</code>. Claude also incorrectly assumed that Flix has infix syntax for modulo (i.e., x % y</code>), but discovered that it should instead use Int32.mod</code>. While encountering these issues, Claude is using both the Flix API reference and documentation to fix them. Aside: The Flix compiler is highly resilient, so each compilation phase can proceed to the next, even if the program contains errors. In fact, about 95% of compilation errors are recoverable. As a result, for a program generated by an LLM with multiple errors, Flix can report all of them at once, allowing the LLM to fix multiple issues in one pass. </blockquote> Claude makes several changes and reruns the compiler. Now it gets: >> Unable to unify the types: 'Player' and 'JvmToType(j0)'. 286 | match state.currentPlayer { ^^^^^^^^^^^^^^^^^^^ </code></pre> The error message is not great — we are working on it — the problem is that the syntax state.currentPlayer</code> means to read the currentPlayer</code> field on a Java object, but state</code> is a Flix extensible record. Undauted, Claude continues: I see several issues. Let me check the Flix documentation for the correct syntax: I see! In Flix, record field access uses # not .. So state.size should be state#size. Let me also search for the correct modulo syntax: Now I understand. Let me rewrite the file with the correct syntax: - Record access: state#size instead of state.size - Modulo: Int32.modulo(index, size) </code></pre> So far, all problems have been purely syntactic. But now, Claude runs into its first effect-related issues: ... I see! Key insights: 1. Random.runWithIO introduces NonDet effect (which is uninterpretable) 2. Random.runWithSeed(seed, f) handles Random without NonDet 3. No do keyword - effect operations are called directly </code></pre> There are two issues: First, the Random.runWithIO</code> handler has both the IO</code> and NonDet</code> effects which must be part of the effect signature of main</code>. Second, Flix no longer uses the do</code> keyword to invoke an effect operation. Surprisingly, Claude quickly overcomes both issues. A single error remains: Good progress! Just one error left - String.split already returns a List, not a Vector. Let me fix that: </code></pre> And done! The program compiles. Lets try to run it: $ flix run Welcome to Tic-Tac-Toe! ====================== Enter grid size (3-9): 3 Starting 3x3 game. You are X, AI is O. Get 3 in a row to win! 1 2 3 1 . . . 2 . . . 3 . . . Your turn (X): Enter your move (row col), e.g., '1 2': 1 2 1 2 3 1 . X . 2 . . . 3 . . . AI is thinking... AI plays at (3, 3) 1 2 3 1 . X . 2 . . . 3 . . O ... 1 2 3 1 X X O 2 X X . 3 O . O AI is thinking... AI plays at (3, 2) 1 2 3 1 X X O 2 X X . 3 O O O Player O wins! </code></pre> Recall that we asked Claude to log all moves. There is a game_log</code> file: === Tic-Tac-Toe Game Log === X played at (1, 2) O played at (3, 3) X played at (1, 1) O played at (1, 3) X played at (2, 2) O played at (3, 1) X played at (2, 1) O played at (3, 2) </code></pre> Looks alright! Refactoring the Game</h2> Let’s return to our TODO list. We wanted Claude to address two issues: Claude was using its own GameLogger</code> effect, but we wanted it to use the built-in Logger</code> effect with a custom handler.</li> The main</code> entry point is correct, but written in a non-idiomatic style.</li> </ol> Let’s start with (1). We prompt Claude: Refactor the project to use the built-in Logger effect. </code></pre> Claude consults the Flix API reference and documentation. I now understand the built-in Logger API. The refactoring involves: 1. Removing the custom GameLogger effect 2. Using Logger.info(message) instead of GameLogger.logMove(move) 3. Writing a custom handler for the built-in Logger that writes to file using FileWrite </code></pre> Notably Claude has figured out that it has to write its own handler for Logger</code> which itself uses the FileWrite</code> effect. I ask Claude to continue. The refactoring is successful: the GameLogger</code> effect is removed and Logger</code> is used. The new custom handler is: // Named "handleLoggerWithFile" but renamed to h to fit on the screen. def h(logFile: String, f: Unit -> a \ ef): a \ (ef - Logger) + FileWrite = run { f() } with handler Logger { def log(severity, msg, resume) = { let line = "[${severity}] ${msg}\n"; FileWrite.append({str = line}, logFile); resume() } } </code></pre> Claude has figured out the correct syntax for an effect polymorphic function that handles Logger</code> while causing the FileWrite</code> effect, i.e. the signature: def h(logFile: String, f: Unit -> a \ ef): a \ (ef - Logger) + FileWrite = </code></pre> Impressive! Next, I want to fix (2), i.e. improve the style of main</code>. I prompt: Refactor main to use default handlers for the built-in effects. Use run-with for the Logger effect and custom handler. See @docs/doc.flix.dev/default-handlers.html for documentation. </code></pre> At this point the dreaded "compacting conversation" happens. Let’s see how it goes. After a bit of Clauding...</code>: The error shows that `Random` doesn’t have a default handler. Let me check the documentation more carefully: Read(docs/doc.flix.dev/default-handlers.html) ⎿ Read 284 lines I see - the documentation shows Clock, Env, and Logger have default handlers, but Random may not. Let me check the Random API: Search(pattern: "@DefaultHandler", path: "docs/api.flix.dev") ⎿ Found 10 lines (ctrl+o to expand) Console and Logger have default handlers, but Random does not. I need to keep Random.runWithIO() explicit: </code></pre> The refactoring completes successfully. The new main</code> is: def main(): Unit \ {Console, IO, NonDet} = let logFile = "game_log.txt"; // Initialize log file discard FileWrite.runWithIO(() -> FileWrite.write({str = "=== Tic-Tac-Toe Game Log ===\n"}, logFile)); // Run the game - Console uses default handler, Random/Logger/FileWrite need explicit handlers discard FileWrite.runWithIO(() -> handleLoggerWithFile(logFile, () -> Random.runWithIO(() -> startGame() ) ) ) </code></pre> Ugh. This is not good. While the code is technically correct, its structure is terrible. A few things have gone wrong, partly due to my own instructions: I asked Claude to use default handlers for all effects. However, the FileWrite</code> effect has no default handler because it can fail. In particular, FileWrite.runWithIO</code> returns a Result[IoError, Unit]</code>. Claude, in its infinite wisdom, decided that we should simply discard the Result</code> 🤡</li> I asked Claude to use the run-with</code> construct, but it did not.</li> </ul> Let us try again, but this time we will be more specific: I want you to refactor main. I want it to use a single run-with construct. Let bind the result to a local variable called r. Inside the run, you should call FileWrite.write and startGame. You should then use "with" to install the handlers handleLoggerWithFile and Random.runWithIO. Lastly, pattern match on the result r, and print an error message using Console.println if it is Result.Err. </code></pre> Now Claude consults the Flix documentation to learn about run-with</code> and produces: def main(): Unit \ {Console, IO, NonDet} = let logFile = "game_log.txt"; let r = run { FileWrite.write({str = "=== Tic-Tac-Toe Game Log ===\n"}, logFile); startGame() } with handleLoggerWithFile(logFile) with Random.runWithIO with FileWrite.runWithIO; match r { case Result.Err(e) => Console.println("Error: ${e}") case Result.Ok(_) => () } </code></pre> Much better. This example shows that Claude is able to program effectively (no pun intended!) with a rich collection of effects. The program uses the Console</code>, FileWrite</code>, Logger</code>, and Random</code> effects. Embracing the richness of the domain, we handle the Logger</code> effect using handleLoggerWithFile</code>, which in turn causes the FileWrite</code> effect. We then handle the remaining effects using their associated runWithIO</code> handlers, introducing the primitive effects IO</code> and NonDet</code>. Lastly, Console</code> is handled by its default effect handler. Aside: This program illustrates how, in effect-oriented programming languages, effects are pushed outwards toward main</code>, where they must be handled. In other words, all dependency injection and plumbing typically happens near main</code>, while most of the program remains pure modulo effects. </blockquote> We might be disappointed that main</code> is still fairly complex. Why not use default handlers for FileWrite</code> and Random</code>? For Random</code>, Flix has a limitation that prevents it. For FileWrite</code>, errors are pushed to the handler rather than the call site, so we must handle them ourselves (here, by printing to the terminal). We could have used FileWriteWithResult</code>, forcing the game to handle errors and allowing a default handler in main</code>, but that would add complexity to the game logic. Game API and Excerpts</h2> For reference, here are some of the function signatures of the game: def aiMove(state: GameState): (Int32, Int32) \ Random = def cellToChar(cell: Cell): String = def displayBoard(state: GameState): Unit \ Console = def parseInt(s: String): Option[Int32] = def promptGridSize(): Int32 \ Console = def promptMove(state: GameState): (Int32, Int32) \ Console = def gameLoop(state: GameState): GameResult \ {Console, Logger, Random} = def startGame(): Unit \ {Console, Logger, Random} = def main(): Unit \ {Console, IO, NonDet} = </code></pre> Claude has done a solid job breaking the game into smaller functions, each using only the effects it needs. Notably, the IO</code> effect is only used by main</code>. This is the essence of effect-oriented programming, and Claude has achieved it. We can look at a few examples: def startGame(): Unit \ {Console, Logger, Random} = Console.println("Welcome to Tic-Tac-Toe!"); Console.println("======================"); let size = promptGridSize(); let state = initGameState(size); Console.println(""); Console.println("Starting ${size}x${size} game. You are X, AI is O."); Console.println("Get 3 in a row to win!"); Console.println(""); discard gameLoop(state) </code></pre> Here startGame</code> has the Console</code>, Logger</code>, and Random</code> effects. Console</code> is used directly, whereas Logger</code> and Random</code> are used by gameLoop</code>. And here is the promptGridSize</code> function: def promptGridSize(): Int32 \ Console = Console.println("Enter grid size (3-9):"); let input = Console.readln(); match parseInt(String.trim(input)) { case Some(n) if n >= 3 and n <= 9 => n case _ => Console.println("Invalid size. Please enter a number between 3 and 9."); promptGridSize() } </code></pre> Lessons Learned</h2> I think the key lessons are: Giving Claude access to the newest Flix API reference and documentation is invaluable. Claude is surprisingly good at consulting both whenever it needs to use a feature or runs into a problem.</li> Giving Claude access to the compiler is must. Furthermore, the Flix compiler’s resilience allows Claude to discover and correct multiple issues in one pass.</li> </ul> Claude’s code style isn’t great. I’d call it unopinionated, which feels a bit odd—but perhaps makes sense, given that there isn’t yet a defined Flix style. In the future, I’d like to explore whether giving Claude a style guide would help. Conclusions</h2> Returning to the central question of this blog post: Will large language models (LLMs) help or hurt the adoption of new programming languages? </blockquote> Based on my experience over the past six months, I’m convinced that LLMs will only help the adoption of new languages. We’ve seen that by giving Claude access to the Flix API reference, documentation, and compiler, it can become a capable Flix programmer. While Claude makes silly syntax mistakes, which would not happen for Python or JavaScript, it can usually overcome them. More impressively, Claude is already capable of effect-oriented programming. It can write functions that use effects, functions that handle effects, and even intricate effect polymorphic functions such as handleLoggerWithFile</code>. Thus, I think, the future for new programming languages is as bright as ever. Until next time, happy Clauding.
Effect Systems vs Print Debugging: A Pragmatic Solution Magnus Madsen — Mon, 15 Sep 2025 00:00:00 +0000 "Every lie we tell incurs a debt to the truth. Sooner or later, that debt is paid." </blockquote> — Valery Legasov (Jared Harris, Chernobyl 2019) Lying to a type system works the same way: the truth eventually comes out. In memory-safe languages, that usually means as a runtime error (e.g. a ClassCastException</code>, a TypeError: foo is not a function</code>, and so on). In memory-unsafe languages, the consequences can be more dire: corrupted data, segmentation faults, or arbitrary code execution. Nevertheless, if we are in a memory-safe language, we might not feel too bad about lying to the type system... But what happens when you lie to the effect system? Nothing good. To understand why, let us examine how the Flix compiler uses the effect system: Dead code elimination: Flix uses the effect system to identify expressions, statements, and let-bindings that have no side effects and whose results are unused. The compiler removes such code, improving performance and reducing binary size. Inlining and value propagation: Flix also uses the effect system to determine which let-bindings can be safely inlined without changing program semantics. This enables constant folding and closure elimination. Automatic parallelization: The Flix compiler, in cooperation with the Flix Standard Library, automatically parallelizes a selected set of higher-order functions when their arguments are pure, and when parallel evaluation preserves program semantics. Separating control-pure from control-impure code: Flix uses effect tracking to distinguish code that may trigger effects and handlers from purely computational code. Control-pure code is compiled without capturing the delimited continuation, while control-impure code includes the machinery required to reify the stack. These are scary program transformations! Hence, when a Flix programmer writes a function: def add(x: Int32, y: Int32): Int32 \ { } = x + y // ^^^ empty effect set </code></pre> We — the Flix language designers — are downright paranoid about ensuring that the effects of the function are not a lie. But surely one little white lie is okay, you suggest, as you carelessly add that unchecked_cast</code> to your program, while I look on with dark visions of unspeakable cosmic horror. Interlude... Print Debugging</h2> One beautiful autumn afternoon, Jim was sitting in front of his computer. Outside, the leaves were turning brilliant shades of orange, while inside, a freshly brewed cup of coffee sat beside him. He had just finished reading a blog post on HackerNews about a new programming language with a type and effect system: Flix. Intrigued, he downloaded the compiler and typed: def main(): Int32 \ IO = println("Hello World!"); sum(123, 456) def sum(x: Int32, y: Int32): Int32 = let result = x + y; println("The sum of ${x} and ${y} is ${result}"); result </code></pre> Running the Flix compiler, Jim was confronted with: ❌ -- Type Error -- >> Unable to unify the effect formulas: 'IO' and 'Pure'. 6 |> def sum(x: Int32, y: Int32): Int32 = ... </code></pre> Dismayed, Jim poked around a bit but couldn’t get the program to work. Frustrated, he returned to HackerNews and posted a comment: Ever tried adding a simple print statement for debugging purposes while coding in effectful lang? compiler: "NNNOOOO!!!! THIS IS AN ERROR; I WILL NEVER COMPILE THIS NONSENSE YOU MUST SPECIFY THE CONSOLE</code> EFFECT WAAARGH" </blockquote> Being a Programming Language Designer is Hard</h2> The art of programming language design is to balance contradictory requirements: Programmers expect lightning-fast compilation, but also deep, aggressive compiler optimizations. ("The compiler is too slow!" vs. "Surely the compiler will optimize that away!")</li> Programmers want expressive type systems, but also intuitive and helpful error messages. ("What do you mean a skolem variable escapes its scope???")</li> Programmers want type inference, but also simple type error messages ("What do you mean you can't unify these types?")</li> Programmers want escape hatches for everything, but nothing must ever break. ("What do you mean turning off the fuel for the engines crashes the plane? I thought you said this was a safe airplane?!")</li> </ul> Returning to earth: we may be academics, but we are trying to build a real programming language. That means listening to our users and that means we have to support print debugging. The question is how? Print-Debugging — Attempt #1</h2> Consider if we introduce a special function: mod Debug { pub def dprintln(x: a): Unit with ToString[a] = unchecked_cast(println(x) as _ \ {}) } </code></pre> Here we use an unchecked_cast</code> to discard the IO</code> effect of println</code>. That is, we lie to the effect system. While our special dprintln</code> function type and effect checks, it does not work well. If we attempt to use it as follows: def sum(x: Int32, y: Int32): Int32 = let result = x + y; Debug.dprintln("The sum of ${x} and ${y} is ${result}"); result </code></pre> The Flix compiler rejects our program with the error: ❌ -- Redundancy Error -- >> Useless expression: It has no side-effect(s) and its result is discarded. 11 | Debug.dprintln("The sum of ${x} and ${y} is ${result}"); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ useless expression. </code></pre> The compiler correctly reports that dprintln</code> is a useless expression: it has no observable effects and its result is ignored. This redundancy check is normally helpful for catching bugs, but in this case it prevents our use of dprintln</code>. We can try to work around this check with a small trick: def sum(x: Int32, y: Int32): Int32 = let result = x + y; let _ = Debug.dprintln("The sum of ${x} and ${y} is ${result}"); result </code></pre> By introducing a let binding with a wildcard name, the redundancy checker is satisfied and the program now compiles. However, when we run the program... nothing is printed! Now, the optimizer detects that the let-bound expression has no side effects and that its variable is unused, so it removes it. Normally this is desirable; we want the optimizer to eliminate dead code, but here it gets in our way. It seems we are stuck. There are two paths forward: We could try to equip the optimizer with knowledge of print debugging statements. In that case, we would track these "effects-that-are-not-effects" and avoid treating them as pure expressions. The problem with this approach is that it would have to handle the entire language—e.g., lambda expressions, higher-order functions, and polymorphism. In effect (no pun intended), we would essentially be re-implementing an ad hoc effect system inside the optimizer. </li> We could decide to disable the optimizer during development. The problem with that is threefold: (a) it would cause a massive slowdown in runtime performance, (b) somewhat surprisingly, it would also make the Flix compiler itself run slower, since dead code elimination and other optimizations actually speed up the backend, and (c) it would be fertile ground for compiler bugs, because instead of one battle-tested compiler pipeline, there would be two pipelines to develop and maintain. </li> </ul> Neither option is really acceptable to us. Print-Debugging — Attempt #2</h2> What we need is a better lie: one with a different set of trade-offs. We introduce a Debug</code> effect and use it for dprintln</code>: eff Debug { /* empty -- marker effect */ } mod Debug { pub def dprintln(x: a): Unit \ Debug with ToString[a] = ... } </code></pre> We no longer lie about dprintln</code>. Calling it now has the Debug</code> effect. We can use it to debug our sum</code> function from earlier: def sum(x: Int32, y: Int32): Int32 = let result = x + y; Debug.dprintln("The sum of ${x} and ${y} is ${result}"); result </code></pre> The implementation of sum</code> is a let-expression whose body is a statement-expression. Because of the call to dprintln</code>, the inferred effect of both is Debug</code>. We are now back to the original problem: The Debug</code> effect is incompatible with the declared type and effect signature of sum</code> (i.e., sum</code> having the empty effect set). However, instead of changing the signature of dprintln</code> or sum</code>, we will change the effect system to allow the absence of the Debug</code> effect. When a programmer writes a type and effect signature like: def downloadUrl(x: Int32): Unit \ {FileWrite, Http} = exp </code></pre> We first check if exp</code> can be type-checked with the signature: Int32 -> Unit \ {FileWrite, Http}</code> If it cannot, we retry with the signature: Int32 -> Unit \ {FileWrite, Http, Debug}</code> If that works, we consider the function well-typed, but crucially, we do not update the signature of downloadUrl</code>. Consequently, everywhere downloadUrl</code> is used, it is still typed as if it only has the FileWrite</code> and Http</code> effects. The advantages of this implementation are: We can use dprintln</code> anywhere in a function and it just works.</li> We can add dprintln</code> anywhere without having to change the signature of the function nor the signatures of any callers.</li> We can be sure that the optimizer will leave our dprintln</code> calls intact.</li> </ul> There are two minor downsides. First, adding a dprintln</code> marks an expression as impure, effectively disabling the optimizer for that expression and its parent expressions. Still, this is far less invasive than disabling the optimizer for the entire program. Second, because the Debug</code> effect is hidden from the function’s signature, calls to that function inside other functions might be moved or even eliminated. On the bright side, this ensures that a dprintln</code> only prints if the function is actually called! Development vs. Production Mode. We don’t want published packages to (a) lie to the type and effect system, or (b) contain print debugging statements. Hence, when the compiler is run in production mode, we disable the lie that allows the implicit Debug</code> effect. As a result, using dprintln</code> in production mode causes a compilation error. Addendum: Look Ma: No Macros!</h2> Rust has a beautiful dbg!</code> macro</a> which works like this: let a = 2; let b = dbg!(a * 2) + 1; // ^-- prints: [src/main.rs:2:9] a * 2 = 4 assert_eq!(b, 5); </code></pre> Since the macro has access to the syntax tree, it can print the file name, line, column, and the original expression. Flix does not currently support macros (and we would not introduce them solely for this purpose). However, we can achieve part of this functionality using a debug string interpolator. For example, we can write: use Debug.dprintln def main(): Unit \ IO = let result = sum(123, 456); println("The sum is: ${result}") def sum(x: Int32, y: Int32): Int32 = dprintln(d"x = ${x}, y = ${y}"); x + y </code></pre> Note the debug string interpolator d"x = ${x}, y = ${y}"</code>. Running the program prints: [Main.flix:8] x = 123, y = 456 The sum is: 579 </code></pre> We get the file name and line number for the small cost of a single d</code>. That's all for now. Until next time, happy hacking. In Defense of Programming Languages Magnus Madsen — Thu, 01 Jul 2021 00:00:00 +0000 This blog post is written in defense of programming language enthusiasts; whether they are compiler hackers, programming language hobbyists, industry professionals, or academics. In this blog post, I want to examine the discourse around programming languages and especially how new programming languages are received. My hope is to improve communication between programming languages designers and software developers. I understand that we cannot all agree, but it would be fantastic if everyone could at least try to be friendly, to be intellectually curious, and to give constructive feedback! A Few Quotes from the Internet</h2> Let me set the stage with a few quotes from social media tech sites (e.g. Reddit, HackerNews, Twitter, etc.). I have lightly edited and anonymized the following quotes: "Great! Yet-another-programming-language™. This is exactly what we need; the gazillion of existing programming languages is not enough!" — Furious Panda via Reddit </blockquote> "This is – by far – the worst syntax I have ever seen in a functional language!" — Irate Penguin via Reddit </blockquote> "The language is probably great from a technical point of view, but unless Apple, Google, Mozilla, or Microsoft is on-board it is pointless." — Angry Beaver via HackerNews </blockquote> "How can anyone understand such weird syntax? I hate all these symbols." — Bitter Turtle via Reddit </blockquote> "The examples all look horrible. The site looks horrible. This needs a lot of work before it gets close to anything I would even consider using." — Enraged Koala via Twitter </blockquote> While all of the above quotes are in response to news about the Flix programming language (on whose website you are currently reading this blog post), depressingly similar comments are frequently posted in response to news about other new programming languages. Why do people post such comments? And what can be done about it? Where do such comments come from?</h2> I think there are two reasons which are grounded in legitimate concerns: Fatigue: I think there is a sense that there are new programming languages coming out all the time. Paradoxically, I think there is both a dread of having to keep up with ever-changing programming languages (and other technologies) and simultaneously a sense that these new programming languages are all the same. </li> Speech: Programming languages are the material with which we craft programs: It is our way of "speaking" algorithmically. They are about what we say, how we say it, and even what can be said. Like prose, what is beautiful and elegant is in the eye of the beholder. It is not surprising then that when a new programming language comes along and suggests a different form of expression that some may have strong reactions to. </li> </ul> Of course there are also internet trolls; but let us ignore them. A Point-by-Point Rebuttal</h2> I want to give a point-by-point rebuttal to the most common refrains heard whenever a new programming language is proposed. Do we really need new programming languages?</h3> The Flix FAQ</a> joking responds to this question with a rhetorical question: Do we really need safer airplanes? Do we really need electric cars? Do we really need more ergonomic chairs? I think it is a valid argument. We want better programming languages because we want to offer software developers better tools to write their programs. You might say that existing programming languages already have all the feature we need, but I think that there are exciting developments; both brand new ideas and old research ideas that are making their way into new programming languages: Safety: region-based memory management, lifetimes, ownership types, linear types, 2nd class values, and capabilities.</li> Expressiveness: union and intersection types, polymorphic effect systems, algebraic effects, type-driven development, increasingly powerful type inference.</li> Development Experience: the Visual Studio Code ecosystem, the language server protocol, GitHub code-spaces.</li> </ul> I don't think we are anywhere near to the point where programming languages are as good as they are ever going to get. On the contrary, I think we are still in the infancy of programming language design. All programming languages are the same</h3> I strongly disagree. I think we are experiencing a period of programming language fragmentation after a long period of consolidation and stagnation. For the last 15-years or so, the industry has been dominated by C, C++, C# and Java. The market share of these programming languages was always increasing and they were the default safe choice for new software projects. Today that is no longer the case. The ecosystem of programming languages is much more diverse (and stronger for it). We have Rust. We have Scala. We also have Go, Python, and JavaScript. There is also Crystal, Elixir, Elm, and Nim (Oh, and Flix of course!) We are in a period of fragmentation. After a decade of object-oriented ossification we are entering a new and exciting period! If history repeats itself then at some point we will enter a new period of consolidation. It is too early to speculate on which programming languages will be the winners, but I feel confident that they will be much better than C, C++, C#, and Java! (Ok, maybe C++30 will be one of them – that language changes as much as Haskell!) (Addendum: That said, it is true that many hobby programming languages look the same. But there is a reason for that: if you want to learn about compilers it makes sense to start by implementing a minimal functional or object-oriented programming language.) New programming languages are too complicated!</h3> That's the way of the world. What do you think an airline pilot from the 1950's would say if he or she entered the flight deck of an Airbus A350? Sure, the principles of flying are the same, and indeed iteration and recursion are not going anywhere. But we cannot expect everything to stay the same. All those instruments are there for a reason and they make flying safer and more efficient. As another example, once universities start teaching Rust (and we will!) then programming with ownership and lifetimes will become commonplace. As yet another example, today every programmer can reasonably be expected to know about filter</code> and map</code>, but that was certainly not the case 15 years ago! A programming language cannot be successful unless a major tech company is behind it</h3> Historically that has not been true. Neither PHP, Python, Ruby, Rust, or Scala had major tech companies behind them. If industry support came, it came at a later time. Ideas for Better Communication</h2> With these points in mind, I want to suggest some ways to improve communication between aspiring programming language designers and software developers: When presenting a new programming language (or ideas related to a new language): Scope: State the intended scope of the project. Is it a hobby project made for fun? Is it an open source project hoping to gain traction? Is it a research prototype? Is it a commercially backed project? What is the intended use case? Is there a "killer-app"? </li> Implementation: What has been implemented? A compiler? An interpreter? Do you have a standard library? How big is it? How many lines is the project? </li> Novelty: What is new in the programming language? Are there some new takes on old ideas? Is there something novel? How is the language an improvement compared to existing languages? Does the language make you think in a new way about programming? </li> Resources: What resources are behind the programming language? Is it a hobby project? An open source project? An academic project? Are you open to collaboration? Do you have backing (from industry or otherwise)? </li> Feedback: What kind of feedback are you looking for? What other people think? Suggestions for improvements and related work? Constructive criticism about the design? What it would take for someone to consider using it? </li> Reality Check: Try to avoid grandiose or unsubstantiated claims: Do your compiler really outperform modern state-of-the-art C compilers? Is your type system really more expressive than Haskell or Idris? Is your language really safer than Ada? </li> </ul> What about Flix?</h2> The time has come to nail our colors to the flag: Scope: We are building a real programming language intended for real-world use. It is an open-source project lead by academic programming language researchers. </li> Implementation: The Flix compiler project is ~137,000 lines of code. We have a realistic compiler, a standard library (extensive, but still under development), a Visual Studio Code extension (with auto-complete!), an online playground, online documentation, and several published papers on the novel aspects of the language. </li> Novelty: We have a whole page (Innovations</a>) that covers this, but briefly: a unique combination of features, combined with first-class Datalog constraints and a polymorphic effect system. </li> Resources: We are a group of programming language researchers from Aarhus University and the University of Waterloo together with a small community of open source contributors. Through our research we have funding for working on Flix. </li> Feedback: We want to know what people think about Flix, how we can make Flix better, and what it would take for someone to consider using it. </li> Reality Check: We aim to under-promise and over-deliver. We do not promote features before they exist. Our typical pipeline is: (Research) Idea → Implementation → Documentation → Presentation to the World. Development is not secret; everything is on GitHub. We just don't promote anything before it is ready. We have exciting things in the pipeline, but you will have to wait a bit before learning about them (or spoil yourself by diving into the GitHub issues!) </li> </ul> Until next time, happy hacking. Taming Impurity with Polymorphic Effects Magnus Madsen — Fri, 01 May 2020 00:00:00 +0000 In the blog post Patterns of Bugs</a>, Walter Bright, the author of the D programming Language</a>, writes about his experience working at Boeing and their attitude towards failure: "[...] The best people have bad days and make mistakes, so the solution is to change the process so the mistakes cannot happen or cannot propagate." "One simple example is an assembly that is bolted onto the frame with four bolts. The obvious bolt pattern is a rectangle. Unfortunately, a rectangle pattern can be assembled in two different ways, one of which is wrong. The solution is to offset one of the bolt holes — then the assembly can only be bolted on in one orientation. The possible mechanic's mistake is designed out of the system." "[...] Parts can only be assembled one way, the correct way." </blockquote> (Emphasis mine). Bright continues to explain that these ideas are equally applicable to software: We should build software such that it can only be assembled correctly. In this blog post, I will discuss how this idea can be applied to the design of a type and effect system. In particular, I will show how the Flix programming language and, by extension, its standard library ensure that pure and impure functions are not assembled incorrectly. Impure Functional Programming</h2> A major selling point of functional programming is that it supports equational reasoning</a>. Informally, equational reasoning means that we can reason about programs by replacing an expression by another one, provided they're both equal. For example, we can substitute variables with the expressions they are bound to. For example, if we have the program fragment: let x = 1 + 2; (x, x) </code></pre> We can substitute for x</code> and understand this program as: (1 + 2, 1 + 2) </code></pre> Unfortunately, in the presence of side-effects, such reasoning breaks down. For example, the program fragment: let x = Console.printLine("Hello World"); (x, x) </code></pre> is not equivalent to the program: (Console.printLine("Hello World"), Console.printLine("Hello World")) </code></pre> Most contemporary functional programming languages, including Clojure, OCaml, and Scala, forgo equational reasoning by allow arbitrary side-effects inside functions. To be clear, it is still common to write purely functional programs in these languages and to reason about them using equational reasoning. The major concern is that there is no language support to guarantee when such reasoning is valid. Haskell is the only major programming language that guarantees equational reasoning at the cost of a total and absolute ban on side-effects. Flix aims to walk on the middle of the road: We want to support equational reasoning with strong guarantees while still allowing side-effects. Our solution is a type and effect system that cleanly separates pure and impure code. The idea of using an effect system to separate pure and impure code is old, but our implementation, which supports type inference and polymorphism, is new. Pure and Impure Functions</h2> Flix functions are pure by default. We can write a pure function: def inc(x: Int): Int = x + 1 </code></pre> If we want to be explicit, but non-idiomatic, we can write: def inc(x: Int): Int \ {} = x + 1 </code></pre> where \ {}</code> specifies that the inc</code> function is pure. We can also write an impure function: def sayHello(): Unit \ IO = Console.printLine("Hello World!") </code></pre> where \ IO</code> specifies that the sayHello</code> function is impure. The Flix type and effect system is sound, hence if we forget the \ IO</code> annotation on the sayHello</code> function, the compiler will emit a type (or rather effect) error. The type and effect system cleanly separates pure and impure code. If an expression is pure then it always evaluates to the same value and it cannot have side-effects. This is part of what makes Flix functional-first: We can trust that pure functions behave like mathematical functions. We have already seen that printing to the screen is impure. Other sources of impurity are mutation of memory (e.g. writing to main memory, writing to the disk, writing to the network, etc.). Reading from mutable memory is also impure because there is no guarantee that we will get the same value if we read the same location twice. In Flix, the following operations are impure: Any use of channels (creating, sending, receiving, or selecting).</li> Any use of references (creating, accessing, or updating).</li> Any use of arrays (creating, accessing, updating, or slicing).</li> Any interaction with the Java world.</li> </ul> Higher-Order Functions</h2> We can use the type and effect system to restrict the purity (or impurity) of function arguments that are passed to higher-order functions. This is useful for at least two reasons: (i) it prevents leaky abstractions where the caller can observe implementation details of the callee, and (ii) it can help avoid bugs in the sense of Walter Bright's "Parts can only be assembled one way, the correct way." We will now look at several examples of how type signatures can control purity or impurity. We can enforce that the predicate f</code> passed to Set.exists</code> is pure: def exists(f: a -> Bool, xs: Set[a]): Bool = ... </code></pre> The signature f: a -> Bool</code> denotes a pure function from a</code> to Bool</code>. Passing an impure function to exists</code> is a compile-time type error. We want to enforce that f</code> is pure because the contract for exists</code> makes no guarantees about how f</code> is called. The implementation of exists</code> may call f</code> on the elements in xs</code> in any order and any number of times. This requirement is beneficial because its allows freedom in the implementation of Set</code>, including in the choice of the underlying data structure and in the implementation of its operations. For example, we can implement sets using search trees or with hash tables, and we can perform existential queries in parallel using fork-join. If f</code> was impure such implementation details would leak and be observable by the client. Functions can only be assembled one way, the correct way. We can enforce that the function f</code> passed to the function List.foreach</code> is impure: def foreach(f: a -> Unit \ IO, xs: List[a]): Unit \ IO = ... </code></pre> The signature f: a -> Unit \ IO</code> denotes an impure function from a</code> to Unit</code>. Passing a pure function to foreach</code> is a compile-time type error. Given that f</code> is impure and f</code> is called within foreach</code>, it is itself impure. We enforce that the f</code> function is impure because it is pointless to apply a pure function with a Unit</code> return type to every element of a list. Functions can only be assembled one way, the correct way. We can enforce that event listeners are impure: def onMouseDn(f: MouseEvent -> Unit \ IO): Unit \ IO = ... def onMouseUp(f: MouseEvent -> Unit \ IO): Unit \ IO = ... </code></pre> Event listeners are always executed for their side-effect: it would be pointless to register a pure function as an event listener. We can enforce that assertion and logging facilities are given pure functions: def assert(f: Unit -> Bool): Unit = ... def log(f: Unit -> String , l: LogLevel): Unit = ... </code></pre> We want to support assertions and log statements that can be enabled and disabled at run-time. For efficiency, it is critical that when assertions or logging is disabled, we do not perform any computations that are redundant. We can achieve this by having the assert and log functions take callbacks that are only invoked when required. A critical property of these functions is that they must not influence the execution of the program. Otherwise, we risk situations where enabling or disabling assertions or logging may impact the presence or absence of a buggy execution. We can prevent such situations by requiring that the functions passed to assert</code> and log</code> are pure. We can enforce that user-defined equality functions are pure. We want purity because the programmer should not make any assumptions about how such functions are used. Moreover, most collections (e.g. sets and maps) require that equality does not change over time to maintain internal data structure invariants. Similar considerations apply to hash and comparator functions. In the same spirit, we can enforce that one-shot comparator functions are pure: def minBy(f: a -> b, l: List[a]): Option[a] = ... def maxBy(f: a -> b, l: List[a]): Option[a] = ... def sortBy(f: a -> Int32, l: List[a]): List[a] = ... def groupBy(f: a -> k, l: List[a]): Map[k, List[a]] = ... </code></pre> We can enforce that the next</code> function passed to List.unfoldWithIter</code> is impure: def unfoldWithIter(next: Unit -> Option[a] \ IO): List[a] \ IO </code></pre> The unfoldWithIter function is a variant of the unfoldWith</code> function where each invocation of next</code> changes some mutable state until the unfold completes. For example, unfoldWithIter</code> is frequently used to convert Java-style iterators into lists. We want to enforce that next</code> is impure because otherwise it is pointless to use unfoldWithIter</code>. If next</code> is pure then it must always either (i) return None</code> which results in the empty list or (ii) return Some(v)</code> for a value v</code> which would result in an infinite execution. We can use purity to reject useless statement expressions. For example, the program: def main(): Int = List.map(x -> x + 1, 1 :: 2 :: Nil); 123 </code></pre> is rejected with the compiler error: -- Redundancy Error ------------------ foo.flix >> Useless expression: It has no side-effect(s) and its result is discarded. 2 | List.map(x -> x + 1, 1 :: 2 :: Nil); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ useless expression. </code></pre> Notice that the List.map(...)</code> expression is pure because the function x -> x + 1</code> is pure. Polymorphic Effects</h2> Flix supports effect polymorphism which means that the effect of a higher-order function can depend on the effects of its function arguments. For example, here is the type signature of List.map</code>: def map(f: a -> b \ ef, xs: List[a]): List[b] \ ef = ... </code></pre> The syntax f: a -> b \ ef</code> denotes a function from a</code> to b</code> with latent effect ef</code>. The signature of the map</code> function captures that its effect ef</code> depends on the effect of its argument f</code>. That is, if map</code> is called with a pure function then its evaluation is pure, whereas if it is called with an impure function then its evaluation is impure. The effect signature is conservative (i.e. over-approximate). That is, the map</code> function is considered impure even in the special case when the list is empty and its execution is actually pure. The type and effect system can express combinations of effects using boolean operations. We can, for example, express that forward function composition >></code> is pure if both its arguments are pure: def >>(f: a -> b \ ef1, g: b -> c \ ef2): a -> c \ { ef1, ef2 } = x -> g(f(x)) </code></pre> Here the function f</code> has effect ef1</code> and g</code> has effect ef2</code>. The returned function has effect ef1 and ef2</code>, i.e. for it to be pure both ef1</code> and ef2</code> must be pure. Otherwise it is impure. Type Equivalences</h2> Let us take a short detour. In a purely functional programming language, such as Haskell, mapping two functions f</code> and g</code> over a list xs</code> is equivalent to mapping their composition over the list. That is: map(f, map(g, xs)) == map(f >> g, xs) </code></pre> We can use such an equation to (automatically) rewrite the program to one that executes more efficiently because the code on the right only traverses the list once and avoids allocation of an intermediate list. Haskell already has support for such rewrite rules</a> built into the language. It would be desirable if we could express the same rewrite rules for programming languages such as Clojure, OCaml, and Scala. Unfortunately, identities - such as the above - do not hold in the presence of side-effects. For example, the program: let f = x -> {Console.printLine(x); x}; let g = y -> {Console.printLine(y); y}; List.map(f, List.map(g, 1 :: 2 :: Nil)) </code></pre> prints 1, 2, 3, 1, 2, 3</code>. But, if we apply the rewrite rule, the transformed program now prints 1, 1, 2, 2, 3, 3</code>! In the presence of side-effects we cannot readily apply such rewrite rules. We can use the Flix type and effect to ensure that a rewrite rule like the above is only applied when both f</code> and g</code> are pure! We can, in fact, go even further. If at most one of f</code> and g</code> is impure then it is still safe to apply the above rewrite rule. Furthermore, the Flix type and effect system is sufficiently expressive to capture such a requirement! We can distill the essence of this point into the type signature: def mapCompose(f: a -> b \ e1, g: b -> c \ {(not e1) or e2}, xs: List[a]): ... = ... </code></pre> It is not important exactly what mapCompose</code> does (or even if it makes sense). What is important is that it has a function signature that requires two function arguments f</code> and g</code> of which at most one may be impure. To understand why, let us look closely at the signature of mapCompose</code>: def mapCompose(f: a -> b \ e1, g: b -> c \ {(not e1) or e2}, xs: List[a]): ... = ... </code></pre> If e1 = T</code> (i.e. f</code> is pure) then (not e1) or e2 = F or e2 = e2</code>. In other words, g</code> may be pure or impure. Its purity is not constrained by the type signature.</li> If, on the other hand, e1 = F</code> (i.e. f</code> is impure) then (not e1) or e2 = T or e2 = T </code>. In other words, g</code> must be pure, otherwise there is a type error.</li> </ul> If you think about it, the above is equivalent to the requirement that at most one of f</code> and g</code> may be impure. Without going into detail, an interesting aspect of the type and effect system is that we might as well have given mapCompose</code> the equivalent (equi-most general) type signature: def mapCompose(f: a -> b \ {(not e1) or e2}, g: b -> c \ e1, xs: List[a]): ... = ... </code></pre> where the effects of f</code> and g</code> are swapped. Benign Impurity</h2> It is not uncommon for functions to be internally impure but observationally pure. That is, a function may use mutation and perform side-effects without it being observable by the external world. We say that such side-effects are benign. Fortunately, we can still treat such functions as pure with an explicit effect cast. For example, we can call a Java method (which may have arbitrary side-effects) but explicitly mark it as pure with an effect cast: /// /// Returns the character at position `i` in the string `s`. /// def charAt(i: Int, s: String): Char = import java.lang.String.charAt(Int32); s.charAt(i) as \ {} </code></pre> We know that java.lang.String.charAt</code> has is pure hence the cast is safe. An effect cast, like an ordinary cast, must be used with care. A cast is a mechanism that allows the programmer to subvert the type (and effect) system. It is the responsibility of the programmer to ensure that the cast is safe. Unlike type casts, an effect cast cannot be checked at run-time with the consequence that an unsound effect cast may silently lead to undefined behavior. Here is an example of a pure function that is implemented internally using mutation: /// /// Strip every indented line in string `s` by `n` spaces. `n` must be greater than `0`. /// Note, tabs are counted as a single space. /// /// [...] /// def stripIndent(n: Int32, s: String): String = if (n <= 0 or length(s) == 0) s else stripIndentHelper(n, s) as \ {} /// /// Helper function for `stripIndent`. /// def stripIndentHelper(n: Int32, s: String): String \ IO = let sb = StringBuilder.new(); let limit = Int32.min(n, length(s)); let step = s1 -> { let line = stripIndentDropWhiteSpace(s1, limit, 0); StringBuilder.appendLine!(sb, line) }; List.foreach(step, lines(s)); StringBuilder.toString(sb) </code></pre> Internally, stripIndentHelper</code> uses a mutable string builder. Type Inference and Boolean Unification</h2> The Flix type and effect system supports inference. Explicit type annotations are never required locally within a function. As a design choice, we do require type signatures for top-level definitions. Within a function, the programmer never has to worry about pure and impure expressions; the compiler automatically infers whether an expression is pure, impure, or effect polymorphic. The programmer only has to ensure that the declared type and effect matches the type and effect of the function body. The details of the type and effect system are the subject of a forthcoming research paper and will be made available in due time. Closing Thoughts</h2> The Flix type and effect system separates pure and impure code. The upshot is that a functional programmer can trust that a pure function behaves like a mathematical function: it returns the same result when given the same arguments. At the same time, we are still allowed to write parts of the program in an impure, imperative style. Effect polymorphism ensures that both pure and impure code can be used with higher-order functions. We can also use effects to control when higher-order functions require pure (or impure) functions. We have seen several examples of such use cases, e.g. requiring that Set.count</code> takes a pure function or that List.unfoldWithIter</code> takes an impure function. Together, these restrictions ensure that functions can only be assembled in one way, the correct way. Until next time, happy hacking. Naming Functional and Destructive Operations Magnus Madsen — Wed, 01 Apr 2020 00:00:00 +0000 It has been said that there are only two hard problems in computer science: (i) naming, (ii) cache invalidation, and (iii) off-by-one errors. In this blog post, I will explain a name consistency issue that arises when a programming language wants to support both functional and destructive operations. (A functional operation always returns new data, whereas a destructive operation mutates existing data. For example, functionally reversing an array returns a new array with its elements reversed, whereas destructively reversing an array mutates the array in place.) Flix supports functional, imperative, and logic programming. Flix is intended to be functional-first which simply means that if there is a trade-off between having better functional- or imperative programming support, we tend to favor design choices that support functional programming. For example, the Flix effect system separates pure and impure functions mostly to the benefit of functional programming. Flix, being imperative, wants to support mutable data structures such as arrays, mutable sets and maps. We have recently added support for all three. But let us for a moment consider a simpler data structure: the humble list. We can map</code> a function f: a -> b</code> over a list l</code> to obtain a new list of type List[b]</code>: def map(f: a -> b \ ef, l: List[a]): List[b] \ ef </code></pre> (Here the ef</code> denotes that the function is effect polymorphic, but that is for another day.) We can also map</code> a function over an option: def map(f: a -> b \ ef, o: Option[a]): Option[b] \ ef </code></pre> We can also map</code> a function over an array: def map(f: a -> b \ ef, a: Array[a]): Array[b] \ IO </code></pre> This is good news: we can program with arrays in a functional-style. Mapping over an array is certainly meaningful and useful. It might even be faster than mapping over a list! Nevertheless, the main reason for having arrays (and mutable sets and maps) is to program with them imperatively. We want to have operations that mutate their data. We want an operation that applies a function to every element of an array changing it in place. What should such an operation be called? We cannot name it map</code> because that name is already taken by the functional version. Let us simply call it mapInPlace</code> for now: def mapInPlace(f: a -> a \ ef, a: Array[a]): Unit \ IO </code></pre> The signature of mapInPlace</code> is different from the signature of map</code> in two important ways: The function returns Unit</code> instead of returning an array.</li> The function takes an argument of type a -> a</code> rather than a function of type a -> b</code>.</li> </ul> The latter is required because the type of an array is fixed. An array of bytes cannot be replaced by an array of strings. Consequently, mapInPlace</code> must take a less generic function of type a -> a</code>. We have seen that it is useful to have both functional and destructive functions such as map</code> and mapInPlace</code>, but what should such functions be called? Are they sufficiently similar that they should share similar names? What should be the general rule for naming functional operations and their counter-part destructive operations? To answer these questions, we surveyed the Flix standard library to understand what names are currently being used. The table below shows a small cross section of the results: Functional Operation</th> Destructive Equivalent</th></tr></thead> Array.map</td> Array.mapInPlace</td></tr> Array.reverse</td> Array.reverseInPlace</td></tr> missing</td> Array.sortByInPlace</td></tr> Set.insert</td> not relevant – immutable</td></tr> Set.union</td> not relevant – immutable</td></tr> missing</td> MutSet.add</td></tr> missing</td> MutSet.addAll</td></tr> MutSet.map</td> MutSet.transform</td></tr> </tbody></table> The table exposes the lack of any established naming convention. Let us consider some of the many inconsistencies: For arrays, the functional and destructive operations are named Array.map</code> and Array.mapInPlace</code>, but for mutable sets the operations are named MutSet.map</code> and MutSet.transform</code>. As another example, for immutable sets, we have Set.insert</code> and Set.union</code>, but these functional operations are missing on the mutable set. Moreover, the mutable version of Set.union</code> is called Set.addAll</code>. Finally, Array.sortByInPlace</code>, what a name! Exploring the Design Space</h2> With these examples in mind, we tried to come up with a principled approach to naming. Our exploration ended up with the following options: Option I: Distinct names</h3> Proposal: We give distinct names to functional and destructive operations. For example, we will have Array.map</code> and Array.transform</code>, and MutSet.union</code> and MutSet.addAll</code>. We reserve the most common names (e.g. map</code>) for the functional operations. Discussion: With distinct names there is little room for confusion, but it may be difficult to come up with meaningful names. For example, what should the destructive version of reverse</code> be called? Option II: Use similar names but with a prefix or suffix</h3> Proposal: We reuse names between functional and destructive operations. To distinguish operations, we add a prefix or suffix to the name. For example, reverseInPlace</code>, inPlaceReverse</code>, reverseMut</code>, or similar. Discussion: The advantage of this approach is that names are immediately consistent. The disadvantages are that: (i) it may be difficult to come up with a good prefix or suffix word, (ii) some users may dislike the chosen prefix or suffix, and (iii) it may be confusing that the signatures for two similarly named operations differ not only in the return type, but also in the polymorphism of the arguments. Option III: Use similar names but with a prefix or suffix symbol</h3> Proposal: Similar to the previous proposal, but instead we use a symbol. For example: reverse!</code>, reverse*</code>, or the like. Discussion: The same advantages and disadvantages of the previous proposal, but with the difference that using a symbol may be more or less appealing to programmers. Option IV: Use namespaces</h3> Proposal: We place all functional operations into one namespace and all destructive operations into another. For example, we might have Array.reverse</code> and MutArray.reverse</code>. Discussion: While this solution appears simple, it has two downsides: (i) we now have multiple functions named reverse</code> with different semantics and (ii) we get a plethora of namespaces for data structures that exist in both immutable and mutable variants. For example, we might end up with Set.map</code> (functional map on an immutable set), MutSet.Mut.map</code> (destructive map on a mutable set), and MutSet.Imm.map</code> (functional map on a mutable set). Option V: The Python approach: sort vs. sorted</h3> Proposal: In Python the sorted</code> operation functionally returns a new sorted list whereas the sort</code> operation destructively sorts a list in place. We use the same scheme for reverse</code> and reversed</code>, map</code> and mapped</code>, and so forth. Discussion: An internet search reveals that many programmers are puzzled by the Python naming scheme. Another disadvantage is that the common functional names, e.g. map</code> and reverse</code> would be reserved for destructive operations (unless we adopt the opposite convention of Python). Option VI: Drop functional operations for mutable data</h3> Proposal: We drop support for functional operations on mutable data structures. If the user wants to map a function over an array, mutable set, or mutable map he or she must first convert it to an immutable data structure. For example, to functionally reverse an array one would write a.toList().reverse().toArray()</code>. Discussion: The "stick your head in the sand approach". The programmer must explicitly convert back and forth between immutable and mutable data structures. While such an approach side-steps the naming issue, it is verbose and slow (because we have to copy collections back and forth). Deliberately leaving functionality out of the standard library does not mean that programmers will not miss it; instead we are just passing the problem onto them. The Principles</h2> We debated these options and slept on them for a few nights before we ultimately ended up with the following hybrid principles: Library: Mutable Data is Functional Data</h3> In Flix, every mutable data structure supports functional operations. For example, mutable collections, such as Array</code> and MutSet</code> support the map</code> operation. Flix, being functional-first, reserves functional names for functional operations. Across the standard library map</code> has the same name and the same type signature. Library: Destructive Operations are Marked with '!'</h3> In Flix, every destructive operation is suffixed with an exclamation point. For example, Array.reverse(a)</code> returns a new array with the elements of a</code> in reverse order, whereas Array.reverse!(a)</code> destructively re-orders the elements of a</code>. Note: This principle applies to destructive operations that operate on data structures, not to impure functions in general, e.g. Console.printLine</code>. As a side-note: Scheme has used !</code> to indicate destructive operations for a long-time. Library: Consistent Names of Functional and Destructive Operations</h3> In Flix, functional and destructive operations that share (i) similar behavior and (ii) similar type signatures share similar names. For example, Array.reverse</code> and Array.reverse!</code> share the same name. On the other hand, Array.transform!</code> is called transform!</code> and not map!</code> because its type signature is dissimilar to map (i.e. map works on functions of type a -> b</code>, but transform requires functions of type a -> a</code>.) We are in the process of refactoring the standard library to satisfy these new principles. Going forward, we are sensitive to at least four potential issues: Whether users come to like the aesthetics of names that end in exclamation point.</li> If there is confusion about when exclamation points should be part of a name.</li> If there is confusion about when two operations should share the same name.</li> That Rust uses exclamation points for macro applications.</li> </ul> As Flix continues to mature, we will keep an eye on these issues. Until next time, happy hacking. Redundancies as Compile-Time Errors Magnus Madsen — Sat, 01 Feb 2020 00:00:00 +0000 As software developers, we strive to write correct and maintainable code. Today, I want to share some code where I failed in these two goals. I will show you real-world code from the Flix compiler and ask you to determine what is wrong with the code. Then, later, I will argue how programming languages can help avoid the type of problems you will see. (Note to the reader: The Flix compiler is (currently) written in Scala, so the code is in Scala, but the lessons learned are applied to the Flix programming language. I hope that makes sense.) Let us begin our journey by looking at the following code fragment: case Expression.ApplyClo(exp, args, tpe, loc) => val e = visitExp(exp) val as = args map visitExp Expression.ApplyClo(e, as, tpe, loc) case Expression.ApplyDef(sym, args, tpe, loc) => val as = args map visitExp Expression.ApplyDef(sym, as, tpe, loc) case Expression.Unary(op, exp, tpe, loc) => val e = visitExp(exp) Expression.Unary(op, exp, tpe, loc) case Expression.Binary(op, exp1, exp2, tpe, loc) => val e1 = visitExp(exp1) val e2 = visitExp(exp2) Expression.Binary(op, e1, e2, tpe, loc) </code></pre> Do you see any issues? If not, look again. Ok, got it? The code has a subtle bug: In the case for Unary</code> the local variable e</code> holds the result of the recursion on exp</code>. But by mistake the reconstruction of Unary</code> uses exp</code> and not e</code> as intended. The local variable e</code> is unused. Consequently, the specific transformations applied by visitExp</code> under unary expressions are silently discarded. This bug was in the Flix compiler for some time before it was discovered. Let us continue our journey with the following code fragment: case ResolvedAst.Expression.IfThenElse(exp1, exp2, exp3, tvar, evar, loc) => for { (tpe1, eff1) <- visitExp(exp1) (tpe2, eff2) <- visitExp(exp2) (tpe3, eff3) <- visitExp(exp3) condType <- unifyTypM(mkBoolType(), tpe1, loc) resultTyp <- unifyTypM(tvar, tpe2, tpe3, loc) resultEff <- unifyEffM(evar, eff1, eff2, loc) } yield (resultTyp, resultEff) </code></pre> Do you see any issues? If not, look again. Ok, got it? The code has a similar bug: The local variable eff3</code> is not used, but it should have been used to compute resultEff</code>. While this bug never made it into any release of Flix, it did cause a lot of head-scratching. Now we are getting the hang of things! What about this code fragment?: /** * Returns the disjunction of the two effects `eff1` and `eff2`. */ def mkOr(ef1f: Type, eff2: Type): Type = eff1 match { case Type.Cst(TypeConstructor.Pure) => Pure case Type.Cst(TypeConstructor.Impure) => eff2 case _ => eff2 match { case Type.Cst(TypeConstructor.Pure) => Pure case Type.Cst(TypeConstructor.Impure) => eff1 case _ => Type.Apply(Type.Apply(Type.Cst(TypeConstructor.Or), eff1), eff2) } } </code></pre> Do you see any issues? I am sure you did. The bug is the following: The formal parameter to mkOr</code> is misspelled ef1f</code> instead of eff1</code>. But how does this even compile, you ask? Well, unfortunately the mkOr</code> function is nested inside another function that just so happens to have an argument also named eff1</code>! Damn Murphy and his laws. The intention was for the formal parameters of mkOr</code> to shadow eff1</code> (and eff2</code>), but because of the misspelling, ef1f</code> ended up as unused and eff1</code> (a completely unrelated variable) was used instead. The issue was found during development, but not before several hours of wasted work. Not that I am bitter or anything... We are almost at the end of our journey! But what about this beast: /** * Returns the result of looking up the given `field` on the given `klass`. */ def lookupNativeField(klass: String, field: String, loc: Location): ... = try { // retrieve class object. val clazz = Class.forName(klass) // retrieve the matching static fields. val fields = clazz.getDeclaredFields.toList.filter { case field => field.getName == field && Modifier.isStatic(field.getModifiers) } // match on the number of fields. fields.size match { case 0 => Err(NameError.UndefinedNativeField(klass, field, loc)) case 1 => Ok(fields.head) case _ => throw InternalCompilerException("Ambiguous native field?") } } catch { case ex: ClassNotFoundException => Err(NameError.UndefinedNativeClass(klass, loc)) } </code></pre> Do you see any issues? If not, look again. Ok, got it? Still nothing? Pause for dramatic effect. Morpheus: What if I told you... Morpheus: ... that the function has been maintained over a long period of time... Morpheus: But that there is no place where the function is called! I am sorry if that was unfair. But was it really? The Flix code base is more than 100,000 lines of code, so it is hard to imagine that a single person can hold it in his or her head. As these examples demonstrate, and as has been demonstrated in the research literature (see e.g. Xie and Engler 2002</a>), redundant or unused code is often buggy code. To overcome such issues, Flix is very strict about redundant and unused code. Flix Treats Unused Code as Compile-Time Errors</h2> The Flix compiler emits a compile-time error for the following redundancies: Type</th> Description</th></tr></thead> Unused Def</td> A function is declared, but never used.</td></tr> Unused Enum</td> An enum type is declared, but never used.</td></tr> Unused Enum Case</td> A case (variant) of an enum is declared, but never used.</td></tr> Unused Formal Parameter</td> A formal parameter is declared, but never used.</td></tr> Unused Type Parameter</td> A function or enum declares a type parameter, but it is never used.</td></tr> Unused Local Variable</td> A function declares a local variable, but it is never used.</td></tr> Shadowed Local Variable</td> A local variable hides another local variable.</td></tr> Unconditional Recursion</td> A function unconditionally recurses on all control-flow paths.</td></tr> Useless Expression Statement</td> An expression statement discards the result of a pure expression.</td></tr> </tbody></table> As the Flix language grows, we will continue to expand the list. Let us look at three concrete examples of such compile-time errors. Example I: Unused Local Variable</h2> Given the program fragment: def main(): Bool = let l1 = List.range(0, 10); let l2 = List.intersperse(42, l1); let l3 = List.range(0, 10); let l4 = List.map(x -> x :: x :: Nil, l2); let l5 = List.flatten(l4); List.exists(x -> x == 0, l5) </code></pre> The Flix compiler emits the compile-time error: -- Redundancy Error -------------------------------------------------- foo.flix >> Unused local variable 'l3'. The variable is not referenced within its scope. 4 | let l3 = List.range(0, 10); ^^ unused local variable. Possible fixes: (1) Use the local variable. (2) Remove local variable declaration. (3) Prefix the variable name with an underscore. Compilation failed with 1 error(s). </code></pre> The error message offers suggestions for how to fix the problem or alternatively how to make the compiler shut up (by explicitly marking the variable as unused). Modern programming languages like Elm and Rust offer a similar feature. Example II: Unused Enum Case</h2> Given the enum declaration: enum Color { case Red, case Green, case Blue } </code></pre> If only Red</code> and Green</code> are used then we get the Flix compile-time error: -- Redundancy Error -------------------------------------------------- foo.flix >> Unused case 'Blue' in enum 'Color'. 4 | case Blue ^^^^ unused tag. Possible fixes: (1) Use the case. (2) Remove the case. (3) Prefix the case with an underscore. Compilation failed with 1 error(s). </code></pre> Again, programming languages like Elm and Rust offer a similar feature. Example III: Useless Expression Statement</h2> Given the program fragment: def main(): Int = List.map(x -> x + 1, 1 :: 2 :: Nil); 123 </code></pre> The Flix compiler emits the compile-time error: -- Redundancy Error -------------------------------------------------- foo.flix >> Useless expression: It has no side-effect(s) and its result is discarded. 2 | List.map(x -> x + 1, 1 :: 2 :: Nil); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ useless expression. Possible fixes: (1) Use the result computed by the expression. (2) Remove the expression statement. (3) Introduce a let-binding with a wildcard name. Compilation failed with 1 error(s). </code></pre> The problem with the code is that the evaluation of List.map(x -> x + 1, 1 :: 2 :: Nil)</code> has no side-effect(s) and its result is discarded. Another classic instance of this problem is when someone calls e.g. checkPermission(...)</code> and expects it to throw an exception if the user has insufficient permissions, but in fact, the function simply returns a boolean which is then discarded. But this is not your Grandma's average compile-time error. At the time of writing, I know of no other programming language that offers a similar warning or error with the same precision as Flix. If you do, please drop me a line on Gitter. (Before someone rushes to suggest must_use</code> and friends, please consider whether they work in the presence of polymorphism as outlined below). The key challenge is to (automatically) determine whether an expression is pure (side-effect free) in the presence of polymorphism. Specifically, the call to List.map</code> is pure because the function argument x -> x + 1</code> is pure. In other words, the purity of List.map</code> depends on the purity of its argument: it is effect polymorphic. The combination of type inference, fine-grained effect inference, and effect polymorphism is a strong cocktail that I plan to cover in a future blog post. Note: The above is fully implemented in master, but has not yet been "released". Closing Thoughts</h2> I hope that I have convinced you that unused code is a threat to correct and maintainable code. However, it is a threat that can be neutralized by better programming language design and with minor changes to development practices. Moreover, I believe that a compiler that reports redundant or unused code can help programmers – whether inexperienced or seasoned – avoid stupid mistakes that waste time during development. A reasonable concern is whether working with a compiler that rejects programs with unused code is too cumbersome or annoying. In my experience, the answer is no. After a small learning period, whenever you want to introduce a new code fragment that will not immediately be used, you simple remember to prefix it with an underscore, and then later you come back and remove the underscore when you are ready to use it. While there might be a short adjustment period, the upside is huge: The compiler provides an iron-clad guarantee that all my code is used. Moreover, whenever I refactor some code, I am immediately informed if some code fragment becomes unused. I think such long-term maintainability concerns are significantly more important than a little bit of extra work during initial development. Until next time, happy hacking. Design Flaws in Flix Magnus Madsen — Wed, 01 Jan 2020 00:00:00 +0000 Inspired by the blog post Design Flaws in Futhark</a>, I decided to take stock and reflect on some of the design flaws that I believe we made during the development of the Flix programming language. I went through old Github issues and pull requests to discover some of the challenging issues that we have been or still are struggling with. I will classify the design flaws into four categories: (i) design flaws that still plague the Flix language, (ii) design flaws that have been fixed, (iii) poor designs that were thankfully never implemented, and finally (iv) design choices where the jury is still out. I want to emphasize that language design and implementation is a herculean task and that there are features planned for Flix which have not yet been implemented. The lack of a specific feature is not a design flaw, but rather a question of when we can get around to it. Design Flaws Present in Flix</h2> The following design flaws are still present in Flix. Hopefully some day they will be fixed. The Switch Expression</h3> Flix supports the switch</code> expression: switch { case cond1 => exp1 case cond2 => exp2 case cond3 => exp3 } </code></pre> where the boolean expressions cond1</code>, cond2</code>, and cond3</code> are evaluated from top to bottom until one of them returns true and then its associated body expression is evaluated. The idea, quite simply, is to have a control-flow structure that visually resembles an ordinary pattern match, but where there is no match value. In hind-sight, the switch</code> expression is nothing more than a glorified if-then-else-if</code> construct that does not carry its own weight. It is an expenditure on the complexity and strangeness budget that offers almost no gain over using plain if-then-else-if</code>. Moreover, it is error-prone, because it lacks an explicit else</code> branch in case none of the conditions evaluate to true. We plan to remove it in future versions of Flix. String Concatenation with Plus</h3> Like most contemporary languages, Flix uses +</code> for string concatenation. While this is an uncontroversial design choice, it does not make much sense since strings are not commutative, e.g. "abc" + "def"</code> is not the same as "def" + "abc"</code>. A better alternative would be to use ++</code> as in Haskell. However, I believe an even better design choice would be to forgo string concatenation and instead rely entirely on string interpolation. String interpolation is a much more powerful and elegant solution to the problem of building complex strings. Design Flaws No Longer Present in Flix</h2> The following design flaws have been fixed. Compilation of Option to Null</h3> Flix compiles to JVM bytecode and runs on the virtual machine. An earlier version of Flix had an optimization that would take the Option</code> enum: Option[a] { case None, case Some(a) } </code></pre> and compile the None</code> value to null</code> and Some(a)</code> to the underlying value of a</code>. The idea was to save allocation and de-allocation of Some</code> values, speeding up evaluation. But, this screws up interoperability with Java libraries. In Java null</code> might be given a special meaning that is incompatible with the meaning None</code>. For example, certain Java collections cannot contain null</code> and trying to put None</code> into one of these would raise an unexpected exception. Consequently, Flix no longer has this optimization. Useless Library Functions</h3> Flix aims to have a robust standard library that avoids some of the pitfalls of other standard libraries. We have been particularly focused on two aspects: (i) ensuring that functions and types have consistent names, e.g. map</code> is named map</code> for both Option</code> and List</code>, and (ii) to avoid partial functions, such as List.head</code> and List.tail</code> which are not defined for empty lists. Yet, despite these principles, we still managed to implement some problematic functions in the library. For example, we used to have the functions Option.isNone</code> and Option.isSome</code>. The problem with these functions is that they are not really useful and they lead to brittle code. For example, if Option.isSome</code> returns true</code> then that information cannot be used to unwrap the option anyway. Thus such functions are not really useful. Function Call Syntax</h2> Inspired by Scala, early versions of Flix did not always use parentheses to mark a function call. For example, the function: def f: Int32 = 21 </code></pre> could be called by writing: def g: Int32 = f + 42 // returns 63 </code></pre> The problem with this design is at least two-fold: (i) it hides when a function is applied, which is terrible in a language with side-effects, and (ii) how does one express the closure of f</code>? (In Scala the answer is to write f _</code>). Today, in Flix, the code is written as: def f(): Int32 = 21 def g: Int32 = f() + 42 // returns 63 </code></pre> which makes it clear when there is a function call. Infix Type Application</h3> In Flix, a function f</code> can be called with the arguments x</code> and y</code> in three ways: In standard prefix-style f(x, y)</code>, in infix-style x `f` y</code>, and in postfix-style x.f(y)</code>. The latter is also sometimes referred to as universal function call syntax. I personally feel reasonably confident that all three styles are worth supporting. The postfix-style fits well for function calls such as a.length()</code> where the length</code> function feels closely associated with the receiver argument. The infix-style fits well with user-defined binary operations such as x `lub` y</code> where lub</code> is the least upper bound of x</code> and y</code>. And of course the prefix-style is the standard way to perform a function call. Type constructors, such as Option</code> and Result</code> can be thought of a special type of functions. Hence, it makes sense that their syntax should mirror function applications. For example, we can write the type applications Option[Int32]</code> and Result[Int32, Int32]</code> mirroring the prefix style of regular function applications. Similarly, for a while, Flix supported infix and postfix type applications. That is, the former could also be expressed as: Int32.Option[]</code> and Int32.Result[Int32]</code>, or even as Int32 `Result` Int32</code>. Thankfully, those days are gone. Striving for such uniformity in every place does not seem worth it. Unit Tests that Manually Construct Abstract Syntax Trees</h3> The Flix compiler comes with more than 6,500 manually written unit tests. Each unit test is a Flix function that performs some computation, often with an expected result. The unit tests are expressed in Flix itself. For example: @test def testArrayStore01(): Unit = let x = [1]; x[0] = 42 </code></pre> In earlier versions of Flix such unit tests were expressed by manually constructing "small" abstract syntax tree fragments. For example, the above test would be expressed as something like: Let(Var("x", ...), ArrayNew(...), ArrayStore(Var("x"), Int32(0), Int32(42))) </code></pre> The problem with such tests is at least two-fold: (i) the tests turn out to be anything but small and (ii) maintenance becomes an absolute nightmare. I found that the surface syntax of Flix has remained relatively stable over time, but the abstract syntax trees have changed frequently, making maintenance of such test cases tedious and time consuming. Bad Ideas that were Never Implemented</h2> These ideas were fortunately never implemented in Flix. The Itself Keyword</h3> The idea was to introduce a special keyword that within a pattern match would refer to the match value. For example: def foo(e: Exp): Exp = match e { // ... many lines ... case IfThenElse(e1, e2, e3) => itself // refers to the value of e. } </code></pre> The keyword itself</code> refers to the value of the match expression, i.e. the value of e</code>. The idea was that in very large and complicated pattern matches, with many local variables, the itself</code> keyword could always be used to refer to the innermost match value. The thinking was that this would make it easier to avoid mistakes such as returning e0</code> instead of e</code> or the like. The problem with this idea is at least three-fold: (i) it seems like overkill for a very specific problem, (ii) it is not worth it on the complexity and strangeness budget, and finally (iii) it is still brittle in the presence of nested pattern matches. Potential Design Flaws</h2> It is debatable whether the following feature is a design flaw or not. Built-in Syntax for Lists, Sets, and Maps</h3> Flix has a principle that states that the standard library should not be "blessed". That is, the standard library should be independent of the Flix compiler and language. It should just be like any other library: A collection of Flix code. Yet, despite this principle, Flix has special syntax for Lists, Sets and Maps: 1 :: 2 :: Nil Set#{1, 2, 3} Map#{1 -> 2, 3 -> 4} </code></pre> which is built-in to the language. While technically these constructs are merely syntactic sugar for Cons</code>, and calls to Set.empty</code>, Set.insert</code>, Map.empty</code> and Map.insert</code> there is no getting around the fact that this is a special kind of blessing of the standard library. In particular, it is not possible to define your own Foo#...</code> syntax for anything.

The Flix Blog

Making Flix Compiler Errors Helpful and Delightful

Will LLMs Help or Hurt New Programming Languages?

Effect Systems vs Print Debugging: A Pragmatic Solution

In Defense of Programming Languages

A Few Quotes from the Internet</h2> Let me set the stage with a few quotes from social media tech sites (e.g. Reddit, HackerNews, Twitter, etc.). I have lightly edited and anonymized the following quotes:</p>

Ideas for Better Communication</h2> With these points in mind, I want to suggest some ways to improve communication between aspiring programming language designers and software developers:</p> When presenting a new programming language (or ideas related to a new language):</p>

Taming Impurity with Polymorphic Effects

Pure and Impure Functions</h2> Flix functions are pure by default. We can write a pure function:</p>

Naming Functional and Destructive Operations

Redundancies as Compile-Time Errors

Design Flaws in Flix

Bad Ideas that were Never Implemented</h2> These ideas were fortunately never implemented in Flix.</p>

Bad Ideas that were Never Implemented</h2>
These ideas were fortunately never implemented in Flix.</p>