DEV Community

Hello World! in AIM

Arek Nawo on December 12, 2018

This is a continuation of The AIM Project series, so if you haven't read the introductory post, then take a time to do that. So, let's start this ...

Read full post

Pan Chasinga • Jan 7 '19

From a language design perspective the syntax is a bit odd, but the concept of advanced type pique my interest. Is AIM inspired by any other languages?

Arek Nawo • Jan 7 '19

I know it is a bit odd but not much. Anyway it's meant to be this way. As for inspiration, not in obvious manner, mainly JavaScript and C++ I think. But its mostly whole new language.

Pan Chasinga • Jan 7 '19

I wonder you mentioned in the doc about how advanced types could be combined to represent class and interface. Have you thought about that through? For instance, how would you represent methods with a block and refer to itself in the receiver (i.e. this)? How would you represent a collection of methods for interfaces?

Arek Nawo • Jan 7 '19

At the start - I'm sorry if I haven't understood you correctly. So, you're meant to be able to access something like this with context modifier ... As for the other one, I think an example might be the best way of showcasing it.

myInterface = {
    myMethod1 #codeblock >> If you don't return anything
    myMethod2 #string >> If it's meant to return string
}

Now, that's the basic idea but I understand your concerns. It's all in early stages with me writing the lexer right now. The syntax might change (even drastically) until I finish work on the parser, so yeah. Of course, I'm open-minded and welcome any ideas.

Pan Chasinga • Jan 7 '19

No worries, I'm interested in your design of advanced types, though I'm not sure where they're headed. It's a fresh approach on programming language complexity at this point. Obviously, modern languages tend to not priority class-based OOP (Rust and Go).

According to your idea, is it possible to define advanced types and compose them later, something maybe like this:

recv = <a #int, b #int>
block = { print(a + b) }
runnr = (1, 2)

(recv)(block)(runnr)      >> prints out 3

fn = (recv)(block)
runnr2 = (10, 2)
(fn)(runner2)                  >> prints out 12

Excuse me if I didn't get it right, but hope the idea went across.

Arek Nawo • Jan 8 '19

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.

(recv)(block)(runnr)

The correct way to do this is by using bind modifier for binding advanced types variables - they're not needed for static values.

recv => block => runnr

It also applies everywhere else in the code. Aside from that, everything is just right.

Pan Chasinga • Jan 8 '19

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?

Arek Nawo • Jan 8 '19

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.

Pan Chasinga • Jan 8 '19

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.

Arek Nawo • Jan 8 '19

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. 😅

Pan Chasinga • Jan 8 '19

I'd be great if you could keep refining the design as well. When the design is solid, anyone could implement it in anything.

At Indo • Dec 16 '18

I'm interested with this project. This looks good.

My question, what would you use for the Lexer, and the parser? Have you thought about what you will use? If not, I recommend use moo for the lexer and for nearley or jison parsers. Personally I like nearley more because it's easier.

Or, maybe you want to create your own? Thanks.

Arek Nawo • Dec 16 '18

By this moment I explored only Jison, but thanks for other suggestions. Most likely I try to do my own.

Pan Chasinga • Jan 7 '19

I know @areknawo is interested in writing a compiler in JS or TS, but something to look at is ReasonML, which is a JS-like language over Ocaml, a very nice parser language.

Meghan (she/her) • Jan 13 '19

>> for comments is very odd since it is already a mathematical operator.

See: developer.mozilla.org/en-US/docs/W...

Arek Nawo • Jan 14 '19

Yeah, I have changed all bytewise operators by preceding them with & e.g. &>> or &|. This is coming to the syntax repo soon. Anyway, still thinking about the design tho. I think this is good enough.