Have you benchmarked against Julia? Would be interesting how Clasp compares in their micro perf tests: https://github.com/JuliaLang/julia/tree/master/test/perf/mic...
http://scilua.org/ was added in the tests recently and does pretty well.
Some more advanced GC integration functionality was added more recently because of the work on Webkit's FTL JIT: http://llvm.org/docs/Statepoints.html
Looks like the first one is in C++ and the second one in OCaml . Second one it will be then :)
Then, you pay a LISP consultancy to implement that as a DSL in Racket or Common LISP that runs during development and outputs portable C for production w/ frameworks like WxWidgets and/or NPRS runtime. They should be able to throw the whole thing together in under a year. :)
I really want to, but I struggle to come up with enough features or syntactic tricks to justify creating a new language.
What would your motivation be?
I tend to think that having it be a scripting language (eg. one that's ment to be used as, for example, creating quests / scripting events. Like old Gothic [I and II] used to have) justifies creating it (and potentially could be useful, since the main contenders as far as I am aware are AngelScript, LUA and Squirrel - so there's not a plethora of choices to choose from).
Though you could find any other field where the language could be used for.
Perhaps processing data, or maybe analyzing human language. Whatever you can come up with.
Then it kind of makes sense :D
Now your parser implements a context-free grammar although the language is not context-free.
In general, parsing syntax should be the LEAST complex issue in writing a programming language. Playing with the above ideas in Python will be a lot of fun and you'll learn a lot anyway.
Some resources to look for... writing a LISP in python:
which is EXCELLENT. as is the followup article.
Another fun look at how someone does parsing, etc. in Go is 'lexical parsing in Go': https://www.youtube.com/watch?v=HxaD_trXwRE which is also fascinating.
Good luck! Merry holiday hacking!
But do anything first. So, take this tutorial and complete it. If after it you wanna move...
I'm working in my own language, and after read like hundreds of links/blogs/books/etc, you will find that a lot of that is heavily biased torwards parsing, LISPys, FORTHs, and ultra-heavy-monads-worship or academic complexting that will make your head spin. After all that read, I'm still confused. Because a lot of things are not simpler or obvious in the way how make a blog or a ecommerce site can be.
So, read a part of the list I have collected:
Syntax is very important, but after read a lot, I think that do the parsing stuff is not the very best first step.
INSTEAD DO THE AST WALKER. Seriously. Get clear how the the AST can be processed and focus in that. Changes in the AST will cause heavy impacts in your parsing stuff, and a lot of question need to get clarified first. For example, from the link above:
My first questions? How make a REPL, a debugger, how implement pattern matching, type checking, if a interpreter can be fast enough, if possible to avoid to do a whole VM for it, etc...
Exist a LOT of practical questions that are left as "a exercise for the reader" that need clarifications.
- Get a list of what do you want for your language. Then think harder and try to remove features and get to the core of it.
- From the above, start to understand the details. For example: I wanna to do GO-style concurrency, so... how implement GO-style concurrency? If that is not solved, your syntax is pointless. That is why try to fill the "core" of the language as much as possible before to commit to the GUI (aka:syntax) of it.
- Then do a interpreter. Is FAR easier. Even if you wanna do a compiler, start here is more easier.
- On the side, play with your syntax, and imagine how write in the language could be. Then start to think "to make this syntax do that, how I can do inside the guts of the compiler"? But you can delay the parser for a while.
When the time come for the parsing, probably is better to do as a top-down parser and/or pratt-parser. I don't waste time with parser generators. If your disagree, ok with me ;)
I have find that use F# is great for this stuff. However, OCalm have more code-samples (ie: ML languages are made for this!). Lisp will work great if your are insane to like that ;). Hardcode C-developer? Tons of code to look, but not very much in clarity to see.
Interpreter is unavoidably convoluted, it is full of very complex things like environment handling, it cannot be split into smaller parts in any sane way.
Compiler, on the other hand, is nothing but a trivial sequence of very simple tranforms (as simple as you like), each is nothing but a couple of term rewriting rules. You do not need a Turing-complete language to implement a compiler.
How make a REPL, a debugger, how implement pattern matching, type checking, if a interpreter can be fast enough, if possible to avoid to do a whole VM for it, etc...
REPL, debugger, no-VM and other stuff look easier with interpreters than compilers.
However, I will be happy to be wrong: I wanna the simplest way to get where I want to.
Currently: Working with F#, wanna REPL, debugger, AGDTs, pattern-matching, go-like concurrency, iterators, semi-functional...
Where I hit a big block is how do interop with a interpreter (ie: Call .NET methods) and that look easier with a compiler...
Pattern matching must be compiled anyway, even if the rest is interpreted, same for the static typing.
Execution like python, not as much.
Care to elaborate how do you picture that happening?