[deleted]
The Lux Programming Language
11–20 of 52 posts
Re: The Lux Programming Language
#12How 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.
Re: The Lux Programming Language
#13[deleted]
Re: The Lux Programming Language
#14Re: The Lux Programming Language
#15[deleted]
[deleted]
Re: The Lux Programming Language
#16Describing 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.
Re: The Lux Programming Language
#17Earlier quoted context omitted.
I have to ask: why aren't you using the reply link?
I am wondering the same actually. I wonder if he could paste his comments as replies and then a moderator could make dead the ones left as main comments. As it is the threads are quite hard to follow.
Sorry.
I don't talk to talk a lot on HN, :P
Re: The Lux Programming Language
#18How does it compare to Shen? http://www.shenlanguage.org/
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).
Re: The Lux Programming Language
#19What 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.
Re: The Lux Programming Language
#20Just 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.