The Lux Programming Language | Hacker News Reader

The Lux Programming Language

github.com

85 pointseduardoejp45 comments

How does it compare to Shen? http://www.shenlanguage.org/

"runs under CLisp, SBCL, Clojure, Scheme, Ruby, Python, the JVM, Haskell and Javascript"

Wow, someone really likes writing compilers...

Mark Tarver originally wrote Qi, which exclusively ran on top of Common Lisp. Qi was refactored as Shen, which is implemented on a small core and is thus very portable. IIRC Mark only maintains the Common Lisp implementations, and the rest were implemented by the community.

How can something, no matter how small core it has, be very portable from CL to Haskell?

Shen doesn't execute directly, it's compiled to K-lambda, a very small, simple, lisp-as-bytecode. K-lambda is very portable, and wherever K-lambda can run, so can Shen.

Details here: http://www.lambdassociates.org/blog/klambda.htm

Interesting to see how many of these overlap.

For example:

Lux->Clojure->JVM

Lux->Ruby->JVM

Lux->Haskell->Javascript

Any more that I missed?

Hypothetically: Lua->Clojure->Javascript (since Javascript is supposedly one of Clojure's compilation targets, in the form of ClojureScript).

From what I've seen about Shen, it seems like the idea is to write some kind of layer on top of the host language on which Shen is run, kind of like an interpreter, though not quite. Or at least that's the feeling I've got from watching a talk on Shen. Lux, on the other hand, will be compiled directly to the target platforms. There will be a degree of separation (mostly because portability is a #1 concern for me and I don't wan't host semantics to compromise it), but Lux is meant to compile down to host code (bytecode, in the case of the JVM). Also, the type-system is more like Haskell's, whereas Shen has it's own way of doing it (sequent-calculus).

Comes with a fully functional prolog. Sweet!

You'd do well to stick with existing syntax conventions. People care about this stuff and introducing changes just because you can seems like a bad idea if you want your language to get wide adoption.

So I'd like to see ; be restored as the comment character, to match every other lisp ever written, and you should probably use / for namespacing like in Clojure. The use of / for namespacing is already a well established convention, because we do that all the time on the web.

Your concerns are well founded but what's going on is this.

Import paths will be using / for the separation of the path, so you'll be writing things like: (import foo/bar/bar #as baz)

I haven't added imports yet, but they're coming for v0.2

Regarding ; as comments and not namespacing, I chose it mostly because:

a) Using / for namespacing leaves the / function in a weird position.

b) I originally wanted to use : for namespacing, but ended up choosing it for the type-annotating macro, so I settled for ;.

c) ## Was chosen for comments because I get to save on reserved characters. For instance, Clojure reserves an awful lot of characters (, . / ^ # @ ~ ' ` ; : \), whereas Lux only reserves 2 (# ;). So I chose ## to save on characters and because if you squint, ; kinda looks like :

d) Ultimately, there is nothing written in stone and I can change my mind about syntax, but I don't see how rocking the boat a little bit with the syntax will cause much trouble.

Syntax is always a prime candidate for bicycle shedding so they'll always be brought up but uncommon syntax is jarring at first.

One problem I see is how overloaded the `#` character is right now. I think one problem that Scala is stuck with is how many things for which `_` is used.

Just curious, is this for fun, or is the goal to compete with clojure/scala etc?

The goal is to compete.

This is just version 0.1, so the release was mostly so people could get a taste for it.

But version 0.2 will come with all features (except type-inference and code-sharing between platforms). Those two will come in subsequent releases.

I'll also be working on finishing the prelude (i.e. lux.lux) and expanding the standard library.

Why EPL? I use Clojure everyday and I know why it is EPL'd, but I wish it was another license since it's incompatible with the GPL. Couldn't you consider a GPL-friendly license? It sets the tone for the community.

I am not much of a licenses buff, so I just went with EPL because it sounded reasonable.

Anything that looks like *GPL will be avoided because of its virality.

How is EPL incompatible with GPL and what licenses are friendly to it? Apache License v2? (That's another one I was considering)

You're avoiding a license because it's popular?

I think by "virality" what was meant was that GPL libraries "infect" non-GPL because the larger work must also be released as GPL. For programming languages, though, this should not be an issue, unless somebody is bundling the whole interpreter/compiler with their app.

In the future, I plan to rewrite the Lux compiler in Lux itself, and one of the reasons is to allow people to embed it and use it's API.

That way, if someone wants to create an online Lux REPL for people to try Lux, it won't be hard for them to do so.

The GPL allows you to modify the source and provide a service on a public server without having to share your modifications.*

But I understand if you prefer a more permissíve license. Lots of people go with MIT License, it's very short, permissive and compatible with the GPL. Apache v2 is also compatible.

See here about EPL being incompatible: https://www.fsf.org/blogs/licensing/using-the-gpl-for-eclips...

Last time I tried understanding the key subtleties of the EPL I came out empty handed, but it would seem it's more viral than the permissive licenses above, bit less so than the GPL.

* That's why the AGPL exists, so someone working on a Lux REPL would only have to show the code for his online Lux modifications if Lux was AGPL.

> I think by "virality" what was meant was that GPL libraries "infect" non-GPL because the larger work must also be released as GPL. For programming languages, though, this should not be an issue, unless somebody is bundling the whole interpreter/compiler with their app.

For programming languages that include a prelude or standard library on which most actual programs will rely on in whole or in part, it may be problematic (and, of course, its especially problematic for languages where substantial parts of the interpreter/compiler itself is part of that standard library, as is the case of any language which implements a general purpose eval.)

This is why almost all free programming languages has their standard library under licenses like LGPL. That license was was created by the free software foundation for the glibc, in order to give direct permission to compile and ship non-free software that uses it.

He meant 'viral' as a negative.

The GPL is pretty much banned across the entire industry because of the fact that it forces accompanying software to be open sourced as well, which is a deal breaker for most companies.

> The GPL is pretty much banned across the entire industry because of the fact that it forces accompanying software to be open sourced as well

The GPL explicitly doesn't require accompanying software to be released under any particular license. (See, e.g., GPLv3 Sec. 5, ending with "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.")

I feel like there should be a way to re-use algorithms and data structures across programming languages and platforms automatically. Sort of like a CLR/JVM etc. but really a common exchange format that could work across different VMs or systems. A little bit like how math can formally describe diverse systems, except you could automatically process/translate this format.

The problem is that even if two languages each have, say, the Set data type, the implementation of those features and how they interact with the language may be radically different. The closest we have to what you're describing right now probably exists in compile-to-JS languages, where one language's implementation of a particular data type or standard library function can (at least in its compiled form) be used by another language.

That, or maybe something at one layer of abstraction up from LLVM - but I'm no expert.

What are the goals of the language?

Simplicity

My ideal of simplicity is more like Haskell's than Clojure's.

Clojure strives to be easy-to-use, but in the process, both the language and standard library have evolved a lot of convoluted and often redundant code (you can take a look at the definition of map to get an idea: https://github.com/clojure/clojure/blob/028af0e0b271aa558ea4...)

Haskell, on the other hand, is a very simple language that seeks simplicity at the library/API level. Lux is more oriented towards that. Portability

I code in Clojure and love the fact that I can work both on the JVM and on JavaScript. However, Clojure's current approach to portability lacks in several ways. I've seen other languages that compile to other platforms (like Scala & Haskell) and they all seem to have limited approaches.

I've come up with a new idea for how to approach the subject that should yield highly portable code that will be trivially reusable.

I've yet to add it to the compiler but it's gonna come in one of the upcoming releases.

Speed

Right now the code generated isn't being optimized in any way (it's v0.1 after all), but I've come with several ideas to make it fast and by the time I'm done, it will be faster than Clojure, and maybe Scala (I'm not sure about Scala, since I'm not a Scala dev and don't know how fast it is).

My goal with Lux is to get it as close to Java's speed as I possibly can.

Extensibility

Lux will allow people to access the compiler state in order to get useful information for macros. There is already a macro (using) that takes advantage of the typing information in the compiler to open up structs ala SML's open.

The pattern-matching macro is also open to extensibility and you can craft your own custom syntax to do crazy things with it.

The prelude (lux.lux) already comes with 2 such pattern-matching extensions.

It sounds like you want Frege, no?

https://github.com/Frege/frege

I wanted a Lisp, not just a functional language.

I also wanted to push things forward in some aspects, like having the module system, first-class types & having higher interaction with the compiler.

Also, Haskell & macros don't seem to mix so well, and meta-programming is a big deal for me.

"Also, Haskell & macros don't seem to mix so well, and meta-programming is a big deal for me."

With the ability to manipulate more of the components of your programs in regular code, macros become less important. But if you want to do compile-time metaprogramming in Haskell, Template Haskell is effective - typed or untyped.

Never tell the creator of a language "It sounds like you want X". Creating a language is done a) for fun, b) just because, c) as a personal development plan, d) to explore, e) to become master of the universe. None of these is achieved by merely using language X, whatever the value of X is.

So if I were to learn a Lisp language for the first time, would Lux be worth my time? Also why not setup an IRC channel? edit: Typo

Lux is still in diapers, but everything should be completed in the next few months.

>> So if I were to learn a Lisp language for the first time, would Lux be worth my time?

That depends. Do you like sophisticated types ala Haskell? Are you interested in functional programming? Do you want a language that runs on established platforms such as the JVM or Node.js/IO.js?

If you answered yes to all of those, Lux welcomes you.

>> Also why not setup an IRC channel?

I'm not much of an IRC guy myself, but a channel can definitely be made. I won't be present most of the time, since I've got work & college to worry about, but an IRC channel can be made.

>Lux is still in diapers, but everything should be completed in the next few months.

How accurate is that? In the sense that it's something heard from a lot of projects, and then years pass and they're not ready yet or are abandoned.

Is there some tangibles to support this? E.g. "creator had done some other languages in the past succesfully so he knows the timescales involved", "author is paid to work on this full time", etc?

>> How accurate is that? In the sense that it's something heard from a lot of projects, and then years pass and they're not ready yet or are abandoned.

Basically, I know how much I've done so far and how much needs to be done, so I can kinda guesstimate how much is necessary.

Taking things this far has taken me 5 and a half months, and the vast majority of the work has already been done.

v0.2 will just expand the standard library (which is a piece of cake), add a few missing features that aren't that hard to implement, and make some improvements to compiler speed.

After that, I'll just be focusing on adding compiler optimizations and porting the compiler to ClojureScript to generate JavaScript.

>> "creator had done some other languages in the past succesfully so he knows the timescales involved"

This is my first language made for public consumption.

>> "author is paid to work on this full time"

I sure as hell would like that, but I'm working part time & going to college. With that said, I've gotten quite far just by extracting time from weekends and working late at night. And since most of the work has been done, I've be surprised if Lux wasn't finished before the end of the year.

I'll also be making sure not to tie myself with other projects as much as I can to be able to dedicate all the time I can to Lux.

If you are learning a Lisp for the first time, you should stick with something established that has good resources for learning available. Scheme is a good choice to start with, and eventually you will want to learn either Common Lisp or Clojure.

Definitely not. It is still "in Diapers" as eduardoejp says in this thread. If you want to learn a lisp that has been around for a while, is proven, and is a fully featured language? Try SBCL (Steel Bank Common Lisp): http://sbcl.org/

Since SBCL is an ANSI compliant lisp, anything that should work for common lisp that isn't SBCL specific (This mostly applies to threading related functions/types if memory serves).

If this doesn't appeal to you after some research, check out one of the popular schemes.

Take a look at Racket

Describing Canonicity as a problem that that needs 'hacks' to work around seems a little disingenuous.

platz >> Describing Canonicity as a problem that that needs 'hacks' to work around seems a little disingenuous.

If by "canonicity" you mean having 1 canonical instance of a type-class per type and by "hack" you mean using records as structs/modules, then I think you're not really appreciating the coolness of Lux's approach.

Not only is Lux's approach simpler (just use records vs having to implement a complete type-class subsystem), but it's based on ideas that have existed for years in the ML world.

ML's signatures & structures are not canonical, and yet all you hear is the ML guys praising their system, without a drop of envy for type-classes.

Also, by having everything be based on records instead of ML's system, I get extra benefits and the language becomes much simpler.

Some folks in the Haskell community have already talked about the issues that I address with Lux's module system. http://www.haskellforall.com/2012/05/scrap-your-type-classes...

Plus, using macros & the type-data in the compiler state, I've already conceived how a macro could be made that does code-transformations that make it seem as if you had globally-scoped type classes, as in Haskell.

However, I still prefer ML's approach.

Reply on news.ycombinator.com