What's the point? He'll never beat LuaJIT. I'd rather see a new language with a "slow, slow, and slow" implementation that had interesting semantics than another python/lua/js cut-down LISP.
Do we need another fractional Lisp that reuses Python/Ruby/IO syntax?
Just give me the power of Lisp and more in a new and interesting way and we'll discuss implementation performance later.
Oh look, operator precedence. Yet another thing prefix notation eliminates me from having to memorize or otherwise puzzle out.
Why do we have to keep doing this over...and over...and over...
Make an LLVM Lisp with S and M expressions and concurrency primitives and you have an interested customer, otherwise, I'll keep hacking in Clojure.
I love seeing new things but I don't understand why people keep making these kinds of languages over and over, we've been doing it since Perl, Python, and Ruby came out.
"I don't understand why people keep making these kinds of languages over and over" -- TJ makes lots of things, from web frameworks to template engines and css DSLs, to see him make a language makes me think: "ooh, TJ made a new toy!"
As far as does the world need it? That is a hard question to answer. Will it achieve mass adoption? My money is on no -- another question is: How long will TJ keep at it?
Sweet! I love seeing your thoughts come to fruition in the language design, and how you compare your syntax and semantic choices to ruby and js. Congrats!
People keep playing with the syntax because there are still low hanging fruit to pick when it comes to syntax improvements. This one seems really nice to me - I really like : as function keyword and the implications it has.
Let language tinkerers keep tinkering, the slow convergence toward Lisp is continuing. Hopefully by the time the convergence is complete it will have brought with it the niceties of its successors: a single standard library, a de facto package manager, and other things that have sharded the various Lisp communities.
For now I'd like to stick with ANSI C for portability but other than that I'm down for JIT alternatives as long as it's quick and easy for others to hack on/install.
Nah that's valid but that macro list might as well just be the enum I'm not using it for anything else right now
No worries. One problem with adding a Jit is you usually want to put extra information in the ast, such as LLVM objects, so I'm not sure how totally easy it would be to hack in in an unobtrusive way.
The other problem is that VMs like LLVM are quite good for statically typed languages, but not always great for dynamic ones. It's probably too early to tell either way. And yeah, even if you use the C interface to LLVM, you still need to compile it with a C++ compiler, which sucks a bit.
Regarding what I thought was a typo, you define n but undef t, but no worries, I guess I didn't read the rest of the code.
with an LLVM backend. But I was relying on closed source code for the parser generation and that began to nag at me, so I'm rewriting the entire thing from scratch to use greg (a fork of leg).
Params used to be comma separated, and they still could be, but definitely optional unless defaults are implemented. To future-proof it's probably best to add them back
This is the kind I do on my whiteboard when I feel like procrastinating a new language.. but I find it terribly cool that you've been forward with this and started implementing it :)
Also, I didn't get how you would make the difference between a closure and a simple boolean?
For instance:
users map(age > 20)
and
users show_age(age < 40) # Because for some reasons, people > 40 don't like to say their ages ;)
Also, I don't know if you know the Arc language, but I'd suggest reading the tutorial written by pg. I particularly like how all functions are shortened.
I.e. keep instead of filter/select, etc.
Also, something cool is that if a literal instead of a lambda is given to keep, it will use the identity function.. (keep 'a '(a b a c)) = '(a a)
Good luck with that :) (And forget about the "Do we need another language crap"; they say that on about any new languages. (Hint: We'd still be using C++))
haha thanks man. yeah I agree, the day I stop playing around as a programmer, is the day I'm dead. Every programmer should explore different aspects of CS and have fun doing it.
32 comments
[ 3.7 ms ] story [ 65.2 ms ] threadJust give me the power of Lisp and more in a new and interesting way and we'll discuss implementation performance later.
Oh look, operator precedence. Yet another thing prefix notation eliminates me from having to memorize or otherwise puzzle out.
Why do we have to keep doing this over...and over...and over...
Make an LLVM Lisp with S and M expressions and concurrency primitives and you have an interested customer, otherwise, I'll keep hacking in Clojure.
I love seeing new things but I don't understand why people keep making these kinds of languages over and over, we've been doing it since Perl, Python, and Ruby came out.
As far as does the world need it? That is a hard question to answer. Will it achieve mass adoption? My money is on no -- another question is: How long will TJ keep at it?
Nothing is set in stone, it's just a playground for now.
How attached are you to writing a slow old C virtual machine back end?
Why not use a fast JIT/AOT, like the LLVM backend? I could be tempted to just implement one.
By the way is there a typo on line 46 of ast.h?
Nah that's valid but that macro list might as well just be the enum I'm not using it for anything else right now
The other problem is that VMs like LLVM are quite good for statically typed languages, but not always great for dynamic ones. It's probably too early to tell either way. And yeah, even if you use the C interface to LLVM, you still need to compile it with a C++ compiler, which sucks a bit.
Regarding what I thought was a typo, you define n but undef t, but no worries, I guess I didn't read the rest of the code.
Good luck!
https://github.com/wbhart/Cesium
In backend.c (esp. lines 171 and following) you can find the beginnings of an LLVM backend (it does work, but doesn't do a whole lot atm).
The whole project is in a major rewrite at the moment. I had fully implemented the toy language described here:
http://selmer.warwick.ac.uk/cesium.pdf
with an LLVM backend. But I was relying on closed source code for the parser generation and that began to nag at me, so I'm rewriting the entire thing from scratch to use greg (a fork of leg).
I'm also adding type inference this time around.
Also, I don't think it is possible to implement lazy arg eval (opt-in callee evaluated messages) in a VM. That's why IO is an ast walking interpreter.
Good luck!
Params used to be comma separated, and they still could be, but definitely optional unless defaults are implemented. To future-proof it's probably best to add them back
Also, I didn't get how you would make the difference between a closure and a simple boolean?
For instance:
and Also, I don't know if you know the Arc language, but I'd suggest reading the tutorial written by pg. I particularly like how all functions are shortened.I.e. keep instead of filter/select, etc.
Also, something cool is that if a literal instead of a lambda is given to keep, it will use the identity function.. (keep 'a '(a b a c)) = '(a a)
Good luck with that :) (And forget about the "Do we need another language crap"; they say that on about any new languages. (Hint: We'd still be using C++))
I'll check out Arc!
may become:
User allowed =: realm not banned || blockedFrom(realm)
Nearly choked when I saw this one. Wish I never have to look for bugs in a language with such syntax.