If Rumi were a programmer. I'm really good at self-proclaimed manifestos. Too reckless to be an entrepreneur. Open-source fanatic. Bare-metal hardware, virtual machine, and all-computing wisdom.
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?
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.
If Rumi were a programmer. I'm really good at self-proclaimed manifestos. Too reckless to be an entrepreneur. Open-source fanatic. Bare-metal hardware, virtual machine, and all-computing wisdom.
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?
At the start - I'm sorry if I haven't understood you correctly. So, you're meant to be able to access something likethis 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.
If Rumi were a programmer. I'm really good at self-proclaimed manifestos. Too reckless to be an entrepreneur. Open-source fanatic. Bare-metal hardware, virtual machine, and all-computing wisdom.
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.
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.
If Rumi were a programmer. I'm really good at self-proclaimed manifestos. Too reckless to be an entrepreneur. Open-source fanatic. Bare-metal hardware, virtual machine, and all-computing wisdom.
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.
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.
We're a place where coders share, stay up-to-date and grow their careers.
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?
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.
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?At the start - I'm sorry if I haven't understood you correctly. So, you're meant to be able to access something like
thiswith context modifier... As for the other one, I think an example might be the best way of showcasing it.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.
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:
Excuse me if I didn't get it right, but hope the idea went across.
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.
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.
By this moment I explored only Jison, but thanks for other suggestions. Most likely I try to do my own.
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.
>>for comments is very odd since it is already a mathematical operator.See: developer.mozilla.org/en-US/docs/W...
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.