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.
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...
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. 🙇
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
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!
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_
@@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
@@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.
Roc is looking spectacular! 🎉
I wish Richard and friends would hurry up and get it out the door. LOL.
This stuff is priority number one right now!
And of course, contributions are always welcome 😉
Love to see that Roc is getting more pragmatic!
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.
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...
Gleam's `use` is exactly like the first example - the arrow backpassing.
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. 🙇
This is super clever!
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
I've literally just saw Jose Valim on ThePrimeagen show telling that he tries and tried to bring imperative while loop in functional language.
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!
awesome :D
LOL I was prepared to be surprised, turns out its just effectful types.
Also, Julia-like in place mutation convention.
At 26:00, if you put another function within the printAsteriks! function that mutated totalPrinted_, wouldn't that one be unpure?
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_
@@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
@@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.
@@smores56 cool. I know koka is an effect based language, and it doesn't let you do it to avoid complications
Richard Feldman is a snitch