We've been using the AST directly for 60 or so years in Lisp. ;) It was going to have more syntax but that got put on hold to great benefit. Except for a few recent dialects who want to litter it with Python/JavaScript literals.
Are you referring to Clojure? To be fair, those reader extensions do look like quality of life improvements over all the parens that you would have otherwise. I haven't tried writing macros in Clojure but afaik you can match them in quote forms just as well as regular list exprs.
Yeah, it was a bit weird that the connection to the abstractness-becoming-pragmaism of S-expressions, since I assume Mr. Saxton is well versed enough to know this connection.
Truffle from GraalVM is interesting to contrast with this. It's an AST centric language implementation framework but it takes performance seriously with lots of the JIT type optimizations you expect from the JVM
Thx Kris. Very interesting. Had never heard of this before. G, I m not even a developer. Like the thinking though and the name is of course hilarious. Anyway, thx!
Interesting video. This guy is obviously smart, but I can not quite determine if the EYG language makes much sense, or if it even qualifies as a language. Possibly my understanding is far off, but here goes. As I see it, supplying a program on AST format, if we are talking about code as text, this means you have already parsed it according to some grammar. But the EYG runtime knows nothing of semantics, so you need to supply "outside world" functionality, to actually do stuff. Is this what effects are? In order for EYG to contribute to creating a new language, it must know of a few primitives, like setting and getting values from local variables, looping, conditionals and function calls. This means it handles stack and heap. But with no assumptions about types, or file systems, or networking, there must be a myriad of functionality that EYG can know nothing of, like even how to add numbers, or string operations, date handling, regular expressions or bit operations, and so on. I see that type checking is mentioned, which means there is some generalized way of expressing complex types even insofar as not making assumptions of representation in memory. Is it correct to say that EYG is not so much a language, as a pluggable runtime for an actual language, and that its input is not source code plus grammar, but the parsed text (AST), as well as a type system? Row types sound like structs, and effects being identified via row types sounds like method signatures. -- In my opinion, writing recursive descent parsers is really quite simple, when one learns to limit recursion. The interesting part is language design. 🙂
Super educational - in a practical way; way to go; Focused and clean POD Cast (very rare on TH-cam).
Mr. Saxton is way sharper than most in this borderline of comp sci and coding.
We've been using the AST directly for 60 or so years in Lisp. ;) It was going to have more syntax but that got put on hold to great benefit. Except for a few recent dialects who want to litter it with Python/JavaScript literals.
xkcd 224
Are you referring to Clojure? To be fair, those reader extensions do look like quality of life improvements over all the parens that you would have otherwise. I haven't tried writing macros in Clojure but afaik you can match them in quote forms just as well as regular list exprs.
Yeah, it was a bit weird that the connection to the abstractness-becoming-pragmaism of S-expressions, since I assume Mr. Saxton is well versed enough to know this connection.
Zig mentioned!!! Looking forward to EYG with Zig
I hope this language stays separated from all machines, especially mine.
Great job again, Chris
😂😂😂😂😂you bastion
Truffle from GraalVM is interesting to contrast with this. It's an AST centric language implementation framework but it takes performance seriously with lots of the JIT type optimizations you expect from the JVM
Languages are well-formed formulae with corresponding semantics. That's been the mainstay understanding since Hilbert, and arguably as early as Frege.
hopefully formally defined.
Do the “platforms” of Roc relate to this in any interesting way?
Is it bad to think of this as a virtual machine with an AST interface? What’s the difference between creating a language for the JVM vs EYG vs LLVM?
As far as I understand JVM and LLVM, they work with instructions, instead of data structures like in the case of EYG.
Thx Kris. Very interesting. Had never heard of this before. G, I m not even a developer. Like the thinking though and the name is of course hilarious. Anyway, thx!
welp, time for my daily productivity to be railroaded.
Interesting video. This guy is obviously smart, but I can not quite determine if the EYG language makes much sense, or if it even qualifies as a language.
Possibly my understanding is far off, but here goes.
As I see it, supplying a program on AST format, if we are talking about code as text, this means you have already parsed it according to some grammar. But the EYG runtime knows nothing of semantics, so you need to supply "outside world" functionality, to actually do stuff. Is this what effects are?
In order for EYG to contribute to creating a new language, it must know of a few primitives, like setting and getting values from local variables, looping, conditionals and function calls. This means it handles stack and heap. But with no assumptions about types, or file systems, or networking, there must be a myriad of functionality that EYG can know nothing of, like even how to add numbers, or string operations, date handling, regular expressions or bit operations, and so on.
I see that type checking is mentioned, which means there is some generalized way of expressing complex types even insofar as not making assumptions of representation in memory.
Is it correct to say that EYG is not so much a language, as a pluggable runtime for an actual language, and that its input is not source code plus grammar, but the parsed text (AST), as well as a type system?
Row types sound like structs, and effects being identified via row types sounds like method signatures.
--
In my opinion, writing recursive descent parsers is really quite simple, when one learns to limit recursion.
The interesting part is language design.
🙂
I now want tk write a proper x86_64 compiler for this thing.
But I don't want to write it in gleam...
It would be painful to do git merge with such json files
i like how the intro and outro music was a tad louder in this video, more exciting
nim ?
The JVM is a burden