The Luna Programming Language | Hacker News Reader

The Luna Programming Language

tjholowaychuk.com

46 pointsjashkenas31 comments

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.

That's not a very good reason to ignore writing something you're interested in.

Namespace collision: http://asana.com/luna/

I thought Asana's Luna was dead in the water?

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.

I'll check out Arc!

Looks interested! But I find the function args syntax very confusing:

    greet =: user msg
      console log('hello #{user} #{msg}')

You're using whitespace as a message separator AND as an argument separator.

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!

I have plans :D thanks man!

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

@tjholowaychuk: Check out context threading (http://www.cs.toronto.edu/syslab/pubs/demkea_context.ps) by Prof. Angela Demke Brown as an alternative to direct threading.

looks like a good read! thanks :)

This looks a lot more like Io than Javascript. I wonder why he didn't mention it.

Units of measure is fun little detail :) F# has something similar: http://msdn.microsoft.com/en-us/library/dd233243.aspx

Looks like it could be fun.

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?

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.

Good luck!

ah you're right haha, didn't catch that

Just for fun I threw up a project I've been working on:

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.

User allowed =: realm !(banned || blockedFrom(realm))

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.

ruby? just like any language you just have to understand op precedence..

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?

yeah, I'm really expecting it to be widely adopted, it's just a fun project to hack on in spare time and share some thoughts.

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!

Missing a "not"?

haha yikes, yeah my bad, not expecting..

the problem this seems to be solving is that everyone decides to "discuss implementation performance later", i.e. never.

You're not familiar with Mike Pall I take it?

that's more the exception than the rule. i think it's a good sign that luna put performance first.

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.

Because it's fun :)

Nothing is set in stone, it's just a playground for now.

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.

Reply on news.ycombinator.com