Lisp is often used to create domain-specific languages.
- Lisp S-expressions are powerful because they represent both code and data. So data is code; code is data: it is very simple to augment the language.
- Lisp S-expression syntax conveniently mirrors the tree shape of Abstract Syntax Trees.
F# also supports macros and meta-programming: futures (F# version of async/await) were added to existing versions of F#. No need for a new language runtime!
If JS had that level of meta-programming, I wouldn't have to wait for pattern-matching support! And pipes!
Some years ago I used the Python library Lark (https://github.com/lark-parser/lark) to parse my programming language. It lets you write your grammar in basically EBNF, builds parse trees (that you can automatically reduce by removing leaves for parentheses, for example) and generates standalone pure-Python LALR(1) parsers for your grammar. Back then, I had a blast with it, it was fast, super easy to use and just worked. Now it's got 5k stars and seems to be a mature and production-ready library.
Thus, I vote Python: it has this amazing parser library, it's garbage-collected (no need to fiddle with memory allocations, like in C), it's dynamically typed (so you basically don't need to think about types at all), it now has a `match` statement (!) that makes it super easy to dissect your parse trees and abstract syntax trees.
Hmm, sounds appealing, and I agree, C is still pretty complicated and the slow speed of the program is not that critical, in exchange for this wonderful library that will save me a lot of time, unlike C.
The language mostly doesn't matter. There may be some benefits to some over others, but none are definitively better than all the others. The ML family languages with their rich type system and pattern matching can make some parts of interpreter/compiler building very straightforward, for instance, but they aren't the only languages with those features and other languages have comparable features or idioms. Some languages are going to force you to do more bookkeeping, like C, so you have to decide if it's worth the trouble for your circumstances.
I'd recommend selecting a language you already know well, a language you also want to learn, or a language with libraries (or good bindings to libraries) that you want to take advantage of. If you want to make a compiler but don't want to do code generation (to machine code) yourself you may want to use a language with good LLVM bindings to get support for a lot of target platforms. If you're interested in making an interpreter, you may want to consider the libraries available to the host language. An interpreter implemented in Python gives you a chance to use Python libraries in your new language (same argument for other languages, the decision would be based on what libraries you might want to use).
As mentioned elsewhere here, Ocaml and the ML family are often cited as easy to implement other languages, due to pattern matching, enum variants, sum types, etc. Since newer languages like Rust and Swift copied those features, you might be more interested in them since they're more popular than older ones like Ocaml and Haskell. Personally I like the syntax sugar in Swift.
If you're doing a compiled language, you'll end up having to interface to LLVM, or write your own output in assembler or ELF or Win32 EXE files. LLVM has been hooked up to almost every compiled language you'll need. They're even figuring out how to hook it up to Free Pascal.
If you're doing an interpreted language, things get a lot looser. If you've done any programming in the past, it's likely the language you're most familiar with will work ok.
This doesn't answer your question. But it would be an interesting project to try and make a programming language where you as the dev only and solely use an llm to do all the work.
So then you could say it was programmed in english*
Well, ANTLR[0] includes many programming language targets. I can also recommend OMeta [1] for quick prototyping. Other developers has implemented it in JS, .NET,
etc. I just found Panini[2] in Rust but I am sure you can find others[3].
Lisp is often used to create domain-specific languages.
- Lisp S-expressions are powerful because they represent both code and data. So data is code; code is data: it is very simple to augment the language.
- Lisp S-expression syntax conveniently mirrors the tree shape of Abstract Syntax Trees.
F# also supports macros and meta-programming: futures (F# version of async/await) were added to existing versions of F#. No need for a new language runtime!
If JS had that level of meta-programming, I wouldn't have to wait for pattern-matching support! And pipes!
If really depends on what you want the language todo and gow much time you want to spend on it.
A smart contract language (for Blockchains)
- Rust
A desktop executable with browser support
- Nim
A cross platform language (iOS, Android, Linix, Mac, Windows)
- Dart
Talk to GPUs
- C++ or C on top of Tensorflow
A toy language for learning compilers/interpreters
- Python
Some years ago I used the Python library Lark (https://github.com/lark-parser/lark) to parse my programming language. It lets you write your grammar in basically EBNF, builds parse trees (that you can automatically reduce by removing leaves for parentheses, for example) and generates standalone pure-Python LALR(1) parsers for your grammar. Back then, I had a blast with it, it was fast, super easy to use and just worked. Now it's got 5k stars and seems to be a mature and production-ready library.
Thus, I vote Python: it has this amazing parser library, it's garbage-collected (no need to fiddle with memory allocations, like in C), it's dynamically typed (so you basically don't need to think about types at all), it now has a `match` statement (!) that makes it super easy to dissect your parse trees and abstract syntax trees.
Hmm, sounds appealing, and I agree, C is still pretty complicated and the slow speed of the program is not that critical, in exchange for this wonderful library that will save me a lot of time, unlike C.
The language mostly doesn't matter. There may be some benefits to some over others, but none are definitively better than all the others. The ML family languages with their rich type system and pattern matching can make some parts of interpreter/compiler building very straightforward, for instance, but they aren't the only languages with those features and other languages have comparable features or idioms. Some languages are going to force you to do more bookkeeping, like C, so you have to decide if it's worth the trouble for your circumstances.
I'd recommend selecting a language you already know well, a language you also want to learn, or a language with libraries (or good bindings to libraries) that you want to take advantage of. If you want to make a compiler but don't want to do code generation (to machine code) yourself you may want to use a language with good LLVM bindings to get support for a lot of target platforms. If you're interested in making an interpreter, you may want to consider the libraries available to the host language. An interpreter implemented in Python gives you a chance to use Python libraries in your new language (same argument for other languages, the decision would be based on what libraries you might want to use).
Prototype in Python with PLY (https://github.com/dabeaz/ply) or you could try Raku (https://raku.org/) which has nice functionality for building grammars.
After you know what you want to build, you could convert it to C, C++, or Rust to make it fast.
Thanks, that sounds interesting, I'll try to find out more information about it, and maybe use your advice.
Use C++ with one of the following:
Boost.Spirit https://www.boost.org/library/latest/spirit/ Boost.Parser https://www.boost.org/library/latest/parser/ (which I think succeeds Boost.Spirit Boost.Metaparse: https://www.boost.org/doc/libs/latest/doc/html/metaparse.htm...
All of these allow you to build a parser using C++ syntax and then add semantic or composed actions.
As mentioned elsewhere here, Ocaml and the ML family are often cited as easy to implement other languages, due to pattern matching, enum variants, sum types, etc. Since newer languages like Rust and Swift copied those features, you might be more interested in them since they're more popular than older ones like Ocaml and Haskell. Personally I like the syntax sugar in Swift.
Also I found it useful to compare other people's implementations to get a feel for different approaches. See this suggestion: https://news.ycombinator.com/item?id=28479120
If you're doing a compiled language, you'll end up having to interface to LLVM, or write your own output in assembler or ELF or Win32 EXE files. LLVM has been hooked up to almost every compiled language you'll need. They're even figuring out how to hook it up to Free Pascal.
If you're doing an interpreted language, things get a lot looser. If you've done any programming in the past, it's likely the language you're most familiar with will work ok.
Just use the one you are most familiar with. All of them are OK unless it is something very esoteric.
I used lexy, which is a great C++ parser combinator.
I then used python match syntax to convert my ast to C.
This doesn't answer your question. But it would be an interesting project to try and make a programming language where you as the dev only and solely use an llm to do all the work.
So then you could say it was programmed in english*
*Or whatever human language you want.
Well, ANTLR[0] includes many programming language targets. I can also recommend OMeta [1] for quick prototyping. Other developers has implemented it in JS, .NET, etc. I just found Panini[2] in Rust but I am sure you can find others[3].
[0] https://www.antlr.org/
[1] https://en.wikipedia.org/wiki/OMeta
[2] https://github.com/pczarn/panini
[3] https://github.com/topics/parser
Thank you, for these materials you have helped me a lot to understand everything better.
A number of years ago I tried Antlr and could not get it to work. Now I see the have a 'Hello world' equivalence. So I am excited to try it again.
Thanks for posting.
Feel free to contact me if you have any ANTLR blocker.
OCaml