
The Lux Programming Language - eduardoejp
https://github.com/LuxLang/lux
======
HerrMonnezza
How does it compare to Shen?
[http://www.shenlanguage.org/](http://www.shenlanguage.org/)

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

Wow, someone really likes writing compilers...

~~~
chadzawistowski
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.

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

~~~
chadzawistowski
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](http://www.lambdassociates.org/blog/klambda.htm)

------
Expez
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.

~~~
eduardoejp
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.

~~~
adamwk
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.

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

~~~
eduardoejp
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.

------
goldfeld
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.

~~~
eduardoejp
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)

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

~~~
afshin
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.

~~~
dragonwriter
> 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.)

~~~
belorn
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.

------
ilaksh
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.

~~~
notduncansmith
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.

------
jtwebman
What are the goals of the language?

~~~
eduardoejp
__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...](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.

~~~
jonnybgood
It sounds like you want Frege, no?

[https://github.com/Frege/frege](https://github.com/Frege/frege)

~~~
eduardoejp
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.

~~~
dllthomas
_" 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.

------
giancarlostoro
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

~~~
eduardoejp
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.

~~~
coldtea
> _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?

~~~
eduardoejp
>> 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.

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

~~~
eduardoejp
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...](http://www.haskellforall.com/2012/05/scrap-your-type-classes.html)

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.

