That's interesting, though => might be confusing since it's used quite differently from other languages like JS or Ocaml, which is a construct for lambdas. (Ocaml actually uses ->). Moreover, it wouldn't make sense to do something like this:
recv => block => block => runnr
Or is that valid AIM too? How would the two blocks work in this way? Would the second one be a nested block of the first?
Hm, that's a good question. Most likely not as only different advanced types should be bonded with blocks. As for the syntax, it's inspired by JS arrow function.
Exactly, but JS arrow function syntax actually has a deep root in lambda calculus and functional programming. For instance, in Ocaml, a lambda function can be defined as such:
let add_one = fun n -> n + 1
Familiar? => or -> has the definition of referential transparent mapping, meaning it maps a value n to n + 1. This makes it possible to curry indefinitely:
fun a -> fun b -> fun c -> b * (a - b)
Same thing in JS.
In Rust, a block statement, interesting enough, takes cue from Ruby.
|v| { ... }
Point is I think it would be confusing to use the arrow for this type of composition. What AIM is doing with advanced types are macro-level thing, changing the syntactical meaning. That's why it piqued my interest in the first place. A language with macro built-in.
Naturally, I would expect advanced types to play out like this, if arrow was to be used:
>> this is cool
recv => block (a)
>> this is also cool
myfun = recv1 => recv2 => recv3 => block
myfun (v)
>> but maybe not between block and runner or block and block
recv => block => (a)
block => block
>> but maybe you could think of a syntax to nest blocks
recv => block :: block (a)
Of course to make it less ambiguous you could come up with a totally new symbol and I think it would totally be justified since what AIM is doing here is not mapping a function to its application.
block = { $0 + 1 } >> fictional `$n` as a binding of parameter n in the preceding receiver
val = <a #int> => block (10) >> val is 11
Good job on the design. It feels like a fun language to hack in.
Good to hear that you're interested in the project! Anyway, it's most likely that many decisions will be made at the time of finishing the parser. Even if, you've given me quite a rethink on this actually. 😅
That's mostly right, you just didn't get the way to bind advanced types. It's like you have created something like 3 runners.
The correct way to do this is by using bind modifier for binding advanced types variables - they're not needed for static values.
It also applies everywhere else in the code. Aside from that, everything is just right.
That's interesting, though
=>might be confusing since it's used quite differently from other languages like JS or Ocaml, which is a construct for lambdas. (Ocaml actually uses->). Moreover, it wouldn't make sense to do something like this:Or is that valid AIM too? How would the two blocks work in this way? Would the second one be a nested block of the first?
Hm, that's a good question. Most likely not as only different advanced types should be bonded with blocks. As for the syntax, it's inspired by JS arrow function.
Exactly, but JS arrow function syntax actually has a deep root in lambda calculus and functional programming. For instance, in Ocaml, a lambda function can be defined as such:
Familiar?
=>or->has the definition of referential transparent mapping, meaning it maps a valuenton + 1. This makes it possible to curry indefinitely:Same thing in JS.
In Rust, a block statement, interesting enough, takes cue from Ruby.
Point is I think it would be confusing to use the arrow for this type of composition. What AIM is doing with advanced types are macro-level thing, changing the syntactical meaning. That's why it piqued my interest in the first place. A language with macro built-in.
Naturally, I would expect advanced types to play out like this, if arrow was to be used:
Of course to make it less ambiguous you could come up with a totally new symbol and I think it would totally be justified since what AIM is doing here is not mapping a function to its application.
Good job on the design. It feels like a fun language to hack in.
Good to hear that you're interested in the project! Anyway, it's most likely that many decisions will be made at the time of finishing the parser. Even if, you've given me quite a rethink on this actually. 😅
I'd be great if you could keep refining the design as well. When the design is solid, anyone could implement it in anything.