I like the way you annotate your explorations. I was trying to make a DSL that extends a config language called KDL, and I had tons of those little notes. I was wondering if I should be keeping notes some other way, but if you do it too, then I'll keep TODO-ing my explorations.
Tsoding has something that turns the TODOs into code issues for a repo, so by all means if you want to create tons of tasks from the plethora of TODOs which should be condensed into design questions enough hopefully can be answered via mindmaps that are imported into a digital document full of condensed points for better semantic search 😊
In code todos are super helpful to keep track on specs. There is a VSCode extension called “ToDo Tree” - highlights them, is extensible and are easy to navigate too. There is also imdone that goes further, but I suggest to keep it simple. In code comments are not a replacement for tickets and stories.
Very interesting! I’m currently building my first interpreter with the Writing an Interpreter in Go book (though I’m using Kotlin). That’s for the monkey language though, but after I want make one with my own language. And it’s fascinating how alluring the prospect of implementing a language with very few orthogonal features seem to be. I really like some of what you are doing here! Thanks for sharing as always!
Hi Contextfree, Rio is a beautiful and small language! how do you feel? would you recommend using Rust to experiment with language creation or is something like Typescript or Haskell better? (I know Haskell a little better than Rust, but TS better than both)
I found typescript quite good as a host for a programming language. It is quite fast to develop in, which is good especially if you consider to bootstrap your lang later on. I can recommend reading a blog post from a rust-analyzer developer called "TypeScript is Surprisingly OK for Compilers ".
Thanks! Rio's especially small since it's not done yet. :) Different languages for developing in have different pros and cons. And I'm being especially hard on myself by too much manual juggling of dense arrays. I probably could abstract it better. I'm mostly coding in Rust because I want to use a non-GC language, and Rust has the most convenient package ecosystem and tooling of non-GC languages. But GC languages probably are fine, too, depending on how you want to do things. And I might have to look up that "TypeScript is Surprisingly OK for Compilers" article now.
I agree that getting to working language as fast as possible is a good idea, especially if you want to bootstrap. I'm just having fun (or misguided) doing some things in hard ways.
and I think it is the right attitude to embark on the path of creating a new language. we must love the path and not the impossible end :) I even thought about using Zig just to learn it, but maybe that would be too much -.-"
For generating wasm, I learned some about how to code wat by hand, and I also look at output from other language compilers to wasm, using wasm2wat (or equivalent) to read it. I also review the wasm spec while working. Then I use the wasm-encoder crate to generate binary wasm and then again translate it to wat for reading. Here's the wasm-encoder crate that I use: crates.io/crates/wasm-encoder
I generate binary wasm only because I want to be a small binary myself, and wasm is more important than wat (although some wasm engines can read wat directly).
@@contextfree the way you define constructs inside the language itself manipulating the lazy expressions is kind of similar to lisp macros at a first glance. Do you have plans for macros?
@@fedang I'm currently mixed on userspace tree manipulation macros. I don't plan to prioritize it, at least, but if I keep working this project, I might get to it eventually. More likely is guaranteed-inlined functions and/or *maybe* some flexibility in the compile-time functions.
I like the way you annotate your explorations. I was trying to make a DSL that extends a config language called KDL, and I had tons of those little notes. I was wondering if I should be keeping notes some other way, but if you do it too, then I'll keep TODO-ing my explorations.
Tsoding has something that turns the TODOs into code issues for a repo, so by all means if you want to create tons of tasks from the plethora of TODOs which should be condensed into design questions enough hopefully can be answered via mindmaps that are imported into a digital document full of condensed points for better semantic search 😊
Nice TODO tooling can be great for sure. I'm also ok just leaving them alone to notice them whenever, depending on project management needs.
Tell me more about your KDL dsl? That is very cool
In code todos are super helpful to keep track on specs. There is a VSCode extension called “ToDo Tree” - highlights them, is extensible and are easy to navigate too. There is also imdone that goes further, but I suggest to keep it simple. In code comments are not a replacement for tickets and stories.
loving this.
Very interesting! I’m currently building my first interpreter with the Writing an Interpreter in Go book (though I’m using Kotlin).
That’s for the monkey language though, but after I want make one with my own language. And it’s fascinating how alluring the prospect of implementing a language with very few orthogonal features seem to be. I really like some of what you are doing here!
Thanks for sharing as always!
Sounds like some fun work! Thanks for the feedback!
Also, I hadn't heard of that book, so thanks for mentioning it!
great
Hi Contextfree, Rio is a beautiful and small language! how do you feel? would you recommend using Rust to experiment with language creation or is something like Typescript or Haskell better? (I know Haskell a little better than Rust, but TS better than both)
I found typescript quite good as a host for a programming language. It is quite fast to develop in, which is good especially if you consider to bootstrap your lang later on.
I can recommend reading a blog post from a rust-analyzer developer called "TypeScript is Surprisingly OK for Compilers ".
Thanks! Rio's especially small since it's not done yet. :) Different languages for developing in have different pros and cons. And I'm being especially hard on myself by too much manual juggling of dense arrays. I probably could abstract it better. I'm mostly coding in Rust because I want to use a non-GC language, and Rust has the most convenient package ecosystem and tooling of non-GC languages. But GC languages probably are fine, too, depending on how you want to do things. And I might have to look up that "TypeScript is Surprisingly OK for Compilers" article now.
I agree that getting to working language as fast as possible is a good idea, especially if you want to bootstrap. I'm just having fun (or misguided) doing some things in hard ways.
and I think it is the right attitude to embark on the path of creating a new language. we must love the path and not the impossible end :)
I even thought about using Zig just to learn it, but maybe that would be too much -.-"
Hey very interesting.
Can you share any resources about how to generating wasm?
For generating wasm, I learned some about how to code wat by hand, and I also look at output from other language compilers to wasm, using wasm2wat (or equivalent) to read it. I also review the wasm spec while working. Then I use the wasm-encoder crate to generate binary wasm and then again translate it to wat for reading. Here's the wasm-encoder crate that I use: crates.io/crates/wasm-encoder
I generate binary wasm only because I want to be a small binary myself, and wasm is more important than wat (although some wasm engines can read wat directly).
Oh no Text. SQL?
Thanks for the reminder! I forgot that SQLs often use this type name.
@@contextfreeBarely relevant, but Swift got SQL's inout.
It's like lisp cond
One of my problems is spending too little time in Lisp. I should fix that sometime.
@@contextfree the way you define constructs inside the language itself manipulating the lazy expressions is kind of similar to lisp macros at a first glance. Do you have plans for macros?
@@fedang I'm currently mixed on userspace tree manipulation macros. I don't plan to prioritize it, at least, but if I keep working this project, I might get to it eventually. More likely is guaranteed-inlined functions and/or *maybe* some flexibility in the compile-time functions.
It **be** like that sometimes fr fr
Whisper words of wisdom, let it be.