Richard Feldman, "The Functional Purity Inference Plan"

[@DomainObject]

Roc is looking spectacular! 🎉 I wish Richard and friends would hurry up and get it out the door. LOL.

[@smores56]

This stuff is priority number one right now! And of course, contributions are always welcome 😉

[@dupersuper1000]

Amazing! I’m going to try out Roc now. And I’m actually tempted to start writing my CLI programs in Roc as well.

[@ytpah9823]

🎯 Key points for quick navigation: 01:25 *📖 Pure Function Definition: A pure function always returns the same output for the same input and has no observable side effects.* 02:00 *🔍 Lookup Table Analogy: Pure functions can be thought of as lookup tables that map inputs to outputs without altering state.* 02:53 *🧩 Elm Ecosystem: In a purely functional language like Elm, functions are consistently pure, reducing ambiguity and simplifying debugging.* 04:18 *🚀 Rock Language Goals: Rock focuses on being fast, friendly, and purely functional, aiming for rapid compile times and efficient performance.* 05:03 *⚡ Effects vs. Side Effects: Purely functional languages handle effects like I/O through values representing those effects, avoiding side effects.* 06:13 *🧱 Pure and Effectful Code: Even in functional languages, codebases mix pure functions and effectful code to handle real-world tasks.* 07:34 *🛠️ Imperative Languages Adopting FP: Languages like Rust, Kotlin, Swift, and TypeScript support functional styles but remain fundamentally imperative.* 08:42 *🧭 Rust’s FP Support: Rust supports functional programming concepts, but its core style remains imperative.* 09:19 *🔧 TypeScript FP Adoption: TypeScript is commonly used in a functional style, with many developers preferring FP-first approaches.* 10:04 *✅ TypeScript Purity Assurance: Pure functions in TypeScript rely on developers manually verifying purity; type signatures don’t enforce it.* 13:14 *🖨️ Imperative Simplicity: Some tasks, like printing sequences, are naturally suited to imperative code for clarity and efficiency.* 15:00 *⚖️ Efficiency Considerations: In certain cases, imperative code is more efficient, avoiding redundant loops and computations.* 16:00 *🤝 Fit for Purpose: Imperative programming can be the best approach for specific problems, even for developers who prefer functional programming.* 16:43 *🔄 Recursion vs. Loops: In languages without for loops, recursion can replace them, but the resulting code may not be clearer or easier to understand.* 17:46 *❗ Effectful Code: In Rock, side effects are represented using tasks, but this can complicate code readability.* 19:28 *🆕 Imperative Support: Rock is introducing imperative-style syntax (e.g., `var`, `for` loops) while maintaining functional purity principles.* 20:18 *📝 Syntax Similarity: Rock's imperative syntax closely resembles TypeScript’s, with slight differences like `do` blocks and no semicolons.* 21:45 *🔍 Pure vs. Effectful Functions: Rock will differentiate pure functions (thin arrows) and effectful functions (thick arrows) in type signatures.* 22:59 *🚫 Compiler Enforcement: Pure functions in Rock cannot call effectful functions, ensuring purity is preserved.* 23:25 *🔄 Reassignments with `var`: The `var` keyword in Rock allows reassigning names within functions, but not mutating values.* 24:56 *🛡️ Immutable Guarantees: Even with `var`, Rock guarantees that values passed into functions cannot be mutated externally.* 26:28 *📊 Information-Rich Code: Rock’s type signatures and naming conventions (e.g., `!` for effectful functions) provide clear insights into function behavior.* 27:44 *⚠️ Exclamation Naming: Functions with side effects end with `!`, making effectful operations easy to identify at a glance.* 30:17 *🔄 `var` Naming Convention: Variables that can be reassigned end with an underscore, helping distinguish them from constants.* 32:20 *🔀 Code Portability: Pure functions allow flexible code reordering, whereas reassignments limit this flexibility.* 32:54 *⚠️ Portability Warnings: The underscore convention warns developers when code is not easily portable due to variable reassignment.* 33:49 *🔍 Quick Inference: Even without the function name or type signature, developers can infer purity and portability by glancing at code conventions like exclamation points and underscores.* 36:45 *🕵️‍♂️ Debugging Clues: The exclamation point convention acts as a clue to potential gotchas in code, aiding in debugging and understanding.* 37:46 *💡 Information Richness: Minimal syntax additions, like an exclamation point, can provide valuable insights into function behavior without cluttering the code.* 39:13 *📄 Thick Arrow Utility: The thick arrow explicitly indicates effectful functions, making type discussions clearer, especially in API design or REPL scenarios.* 43:19 *🛠️ Preventing Mistakes: The `var` keyword prevents accidental variable conflicts when copying and pasting code, reducing potential bugs.* 45:01 *✅ Purity with `var`: Using `var` inside a function doesn’t affect its purity; purity depends only on input-output consistency.* 46:32 *🔄 Imperative Flexibility: Rock aims to support an imperative style when it suits the problem, without sacrificing functional principles.* 49:33 *🚀 Ease into Functional Programming: Beginners can start writing imperative-style code in Rock and gradually adopt functional idioms over time.* 50:23 *🛠️ Rust’s `clone` Analogy: Just like Rust's `clone` helps beginners bypass complexity, Rock’s imperative support provides an accessible learning path.* 51:34 *🧗 Smoother Learning Curve: Rock aims to avoid the steep learning curve of recursion by providing simple imperative constructs like loops and variable reassignment.* 52:13 *📝 Simplified Syntax: Rock's new syntax for handling effects is clearer and avoids complex task chaining, making code more readable.* 52:48 *🔄 Backpassing Challenges: Earlier designs like backpassing confused beginners, prompting a shift to simpler syntax for handling effects.* 54:20 *🧩 Alternative Designs: Gleam and Haskell’s approaches to chaining tasks were considered but found to be too complex for beginners.* 55:54 *⚠️ Clearer Error Messages: Rock’s new design promises simpler and clearer error messages by avoiding complex desugaring.* 56:37 *❌ Limitations of Chaining: Chaining syntax struggles with conditional logic, making straightforward imperative code more practical for such cases.* 58:52 *⚡ Performance Considerations: Task-based handling introduces performance overhead; new designs aim to support high-performance concurrency similar to Go.* 01:00:47 *🔍 Minimalistic Approach: Rock aims for a simple and minimal system with binary algebraic effects, focusing on purity and effectfulness.* 01:02:57 *📦 New Primitives: Although adding new primitives like `var` and effectful arrows, the overall goal is to make Rock easier for beginners while maintaining simplicity.* 01:04:27 *✅ Compiler Enforcements: Rock’s compiler will enforce purity, effectfulness, and variable conventions to maintain code clarity and consistency.* 01:05:21 *💬 Considering Break and Continue: The team is open to adding `break` and `continue` statements in the future but sees it as non-critical for now.* 01:05:41 *📝 Rock’s New Identity: Rock is transitioning from a purely functional language to one with purity inference, maintaining a functional core.* 01:07:10 *🔒 Var in Closures: Vars captured in closures cannot be mutated. The team may enforce this strictly or allow immutable snapshots for convenience.* 01:09:27 *🌐 Platforms in Rock: Rock applications are built on a single platform that interfaces with non-Rock languages, typically via Rust, Zig, or CFFI.* 01:10:57 *🔄 Single Platform Rule: Each Rock application must use exactly one platform; combining multiple platforms is not supported.* 01:12:33 *⚠️ Effectful Functions Must Have Effects: Rock’s compiler warns if a function is marked as effectful but does not perform any side effects.* 01:14:18 *🔍 Reading Code Clarity: Richard prioritizes code readability and prefers imperative style when recursion or functional constructs complicate comprehension.* 01:19:52 *🎓 Target Audience: Rock’s design considerations focus on programmers familiar with coding, not absolute beginners.* 01:21:30 *⚖️ Trade-Offs in Design: The team acknowledges design trade-offs, particularly around error handling and early returns, settling on a `try` keyword inspired by Zig.* 01:22:40 *🧪 Experimentation Over User Testing: Rock is in a pre-1.0 phase, so changes are made through iterations and experimentation rather than formal user testing.* 01:23:05 *⚠️ Expect Change: Because Rock is still in development with nightly builds, users should expect frequent changes to the language.* 01:23:38 *🔄 Major Yet Subtle Change: The shift to purity inference is a significant change, though much of the current code will look similar, as the exclamation point operator transitions to a naming convention.* 01:24:43 *🚨 CI Failure on Warnings: Compiler warnings won’t prevent local builds but will exit with a non-zero code, causing CI pipelines to fail automatically if warnings are present.* 01:25:16 *🎉 Community Enthusiasm: The community appreciates Rock’s strategy of adopting imperative features while maintaining functional programming principles.* Made with HARPA AI

[@jdm42]

Love the introduction of the for loop with careful thinking behind it! Excited to see where it goes :)

[@lpil]

Cool vid! Just to say the feature attributed to Gleam's at around 50mins doesn't exist in Gleam. Gleam doesn't have anything like that as we prefer to always keep it explicit.

[@hayleigh-dot-dev]

I think there's quite a fundamental misunderstand of what Gleam's `use` is. It is true that folks new to Gleam often take a little time to get their head around the feature, but it has nothing to do with IO, monads, `do` notation, ocaml's binding operators...

[@georgesboris]

Gleam's `use` is exactly like the first example - the arrow backpassing.

[@rtfeldman]

oh, no - really sorry about that! I'd heard about the feature and thought that was how it worked, but I didn't actually verify that in the docs...definitely my mistake. 🙇

[@xtty7644]

@@hayleigh-dot-dev It actually does have to do with all of those, though. Every single feature you mentioned is some variation on automatically transforming the code into and from continuation-passing style. They might seem quite different but they're all variations on that same basic idea.

[@deryilz]

At 26:00, if you put another function within the printAsteriks! function that mutated totalPrinted_, wouldn't that one be unpure?

[@smores56]

I think mutation isn't the way to think of var, it's more accurate to think "reassignment". A called function couldn't "mutate" totalPrinted_, it could only use the current value immutably to generate a different value and reassign it to totalPrinted_

[@deryilz]

@@smores56 right, but would a nested function inside printAsteriks! be allowed to reassign totalPrinted? would that apply only within the nested function? if so that it would be pure actually and that kinda makes sense

[@smores56]

@@deryilz we haven't ironed out the details yet, and I'll probably spark up a discussion on this. It seems like we should probably not allow closures to capture var variables because you don't know which value you'll get.

[@deryilz]

@@smores56 cool. I know koka is an effect based language, and it doesn't let you do it to avoid complications

[@pengain4]

Love to see that Roc is getting more pragmatic!

[@scott11x8]

I've been following Roc for a while now (I did the advent of code in it last year!), and I was just wondering, what was the reasoning for only using a naming convention of ending impure functions with "!" instead of requiring "!" as an operator when calling impure functions? It seems to me that it would be simpler to have it be based on the type of the function being called, similar to how "?" or "try" are often used for calling fallible functions (e.g. Zig, Rust). Was it mainly so that changing a function from pure to impure just causes warnings rather than type errors? Also, I'm a big fan of the approach of keeping a simple distinction between pure and impure functions. For a while, I was working on a compiler that supported annotating arbitrary effects (including effect-polymorphic types and functions) as a personal project, and it led to a lot of complexity that probably isn't worth it in my opinion (especially regarding type inference and compiler errors). I'm excited to see where Roc goes!

[@suvetar]

Definitely agree on that line separated type def ... Can't even really put it into words, other than it's an elegant and usefully elegant way of laying out code, ensuring readability and clarity of intent. I've been programming for 35+ years and I find I read more then I write now, so it's very important to me, and at least we now don't have to worry about every byte of RAM saved in a compilation pass! Good stuff Sir! Ed: I know I'm cart before horse here but was just wondering, if its a principle to make it difficult for someone to 'accidently' de-pure the function, you could perhaps: abs : F64 --> F64 by n abs = n if n >= 0 else -n this is as close as I can put an approach I'm using in a DSL to abs ... so, the type obviously enforces parameter count and type, and as a convenience can set you up with a known state too, 'by way of n'. We know it's returning so I can give it a likelihood guess that n's gonna be positive more often and then you've also got a nice chance of short circuiting extraneous code. To be honest though, my DSL is not particularly Functional as I'm simming old Mainframe code!! But, I do like to try for elegant but practical ... I'm the poor fool who's got to maintain it and wonder what I was writing 5 years ago!

[@MaksimVolkau]

I've literally just saw Jose Valim on ThePrimeagen show telling that he tries and tried to bring imperative while loop in functional language.

[@craftvscruft8060]

This is super clever!

[@1Arseniy]

Great talk as always! I really loved the -> and => features, and using the bang (!) to unwrap the result is awesome. I’m not too sure about the var x_ = 1; x_ = x_ + 1 syntax, though. I think something more explicit would work better for mutability. Like var x = 1; x

[@oserodal2702]

LOL I was prepared to be surprised, turns out its just effectful types. Also, Julia-like in place mutation convention.

[@yurtle1851]

awesome :D

[@privatedeletebuttongooglei5221]

Richard Feldman is a snitch