The link given in the README for the "The Lux Programming Language" book is https://www.gitbook.com/book/luxlang/the-lux-programming-language/details which redirects to https://legacy.gitbook.com/book/luxlang/the-lux-programming-language/details. That takes me to a page which shows nothing but "Please log in to preview this content", and apparently logging in requires me to provide a phone number ... uh, no. Even if the number is thrown away after use.

I see there's also, apparently, a version of the book at https://luxlang.gitbooks.io/the-lux-programming-language/. Do these two URLs provide exactly the same content? If so, it might be worth mentioning this latter URL in the README.

Can you have a non copyleft license like Boost, BSD, MIT, ASL 2.0?

It seems it's a common stumbling block for people to be unable to build even a "Hello world" program in Lux due to their using versions of Leiningen and the JDK that Lux doesn't work with - e.g. #41.

Rather than just closing those issues, could I suggest that it might, perhaps, be useful to add to both the README and to the Lux book (assuming the URL I have for it is up to date - perhaps this has already been added) a new section called "Prerequisites" which details the versions of JDK and Leiningen which Lux is known to work with?

my terminal network is so bad to download

com.github.luxlang:lux-jvm-0.7.0
com.github.luxlang:stdlib-0.7.0

how to manual install this thing ?

The EPL is not compatible with the GPL 😢 can you please relicense under something that is compatible? Some ideas here https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility

I'd personally prefer if you chose a copyleft license such as LGPL or MPL as that would ensure that the language remains free.

Hi, I'm really happy that there is a new release of Lux! So I wanted to get started and learn some basics. However, when following along chapter 1 of the book I am getting an issue when trying to run the built program. Following the steps in section 3 works fine up until step 6. I have a target folder but, first of all, there is no file target/jvm/program.jar, but there is a file called target/program.jar. However, running java -jar target/program.jar gives me the following exception:

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
        at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:317)
        at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:259)
        at java.util.jar.JarVerifier.processEntry(JarVerifier.java:318)
        at java.util.jar.JarVerifier.update(JarVerifier.java:230)
        at java.util.jar.JarFile.initializeVerifier(JarFile.java:383)
        at java.util.jar.JarFile.ensureInitialization(JarFile.java:617)
        at java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:69)
        at sun.misc.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:991)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:451)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)

Looking up this issue I came across this StackOverflow post which suggests that the issue can occur when packaging signed jars. Is there something I can do to fix this or should this be fixed inside of Lux?

What about a comparison to the Clojure Spec library?

There are a lot of naming schemes and a lot of sigils that are used in the standard library. They should be documented.

https://www.unisonweb.org/

https://www.youtube.com/watch?v=gCWtkvDQ2ZI

Basically, as far as I undestand it, this should not be it's own language. The ideas are AMAZING and should/could be incorperated into any 'new' language.

Maybe you considered the idea of addressing code by hash instead of "names" and it doesn't work for lux.
If that is the case, just ignore this :)

much love :)

@LuxLang I'm writing down a specific proposal with code snippets that I'm happy to post here most up to date version, but can we discuss collaborate on draft on google docs or dropbox paper instead ? In my experience it provides a lot better interface for proposing edits and inline feedback.

I like the project, although I don't really understand most of the design decisions and what they would mean to me in real world applications (due to my own ignorance). I like the goal to target many platforms. I work with Clojure and it generally takes a long time to start for me. Is there any goal to minimize this start up time for Lux on JVM? Is this even possible? Thanks

My understanding is that the lack of commercial use means that:

1. A company could not build software written in Lux that they intended to sell.
2. A company could not use software written in Lux internally to help them operate their business.

Am I interpreting this correctly?

Do you intend to allow commercial use at some point in the future? Do you intend to sell licenses to it in the future? If not, any information as to why you made this choice? Obviously you can do whatever you want with it, and I appreciate you open-sourcing it at all - but I am curious.

Would be interested to know how you stack against Hackett

What about a comparison to the Typed Clojure project?

Modern compilers have very good integration with development tools and Language Sever Protocol seems to be very helpful to lower the effort to support a variate of editors/IDEs.

I was following along in the book and wanted to try compiling to JS.

project.lux:

[""
 ["identity" ["my.group" "lux-test" "0.1.0-SNAPSHOT"]
  "repositories" ["https://oss.sonatype.org/content/repositories/snapshots/"
                  "https://oss.sonatype.org/service/local/staging/deploy/maven2/"]
  
  "dependencies" [["com.github.luxlang" "stdlib" "0.6.5" "tar"]]
  "compiler" ["com.github.luxlang" "lux-js" "0.6.5" "jar"]

  "program" "main"]]

source/main.lux

(.using
[library
[lux "*"
 [program {"+" program:}]
 ["[0]" debug]
 [control
  ["[0]" io]]]])

(program: args
(io.io (debug.log! "Hello, world!")))

when I run lux build I get

➜ lux build
[?] Fetching com.github.luxlang:lux-js-0.6.5 from "/Users/williamdyer/.m2/repository"
[O] Found com.github.luxlang:lux-js-0.6.5 at "/Users/williamdyer/.m2/repository"
[?] Fetching com.github.luxlang:stdlib-0.6.5 from "/Users/williamdyer/.m2/repository"
[O] Found com.github.luxlang:stdlib-0.6.5 at "/Users/williamdyer/.m2/repository"
Local successes: 0: "com.github.luxlang:lux-js-0.6.5"
                1: "com.github.luxlang:stdlib-0.6.5"
Local failures: 
Remote successes: 
Remote failures: 
[BUILD STARTED]
/Users/williamdyer/.m2/repository/com/github/luxlang/lux-js/0.6.5/lux-js-0.6.5.jar:1
PK
^

SyntaxError: Invalid or unexpected token
  at Object.compileFunction (node:vm:352:18)
  at wrapSafe (node:internal/modules/cjs/loader:1027:15)
  at Module._compile (node:internal/modules/cjs/loader:1063:27)
  at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
  at Module.load (node:internal/modules/cjs/loader:975:32)
  at Function.Module._load (node:internal/modules/cjs/loader:822:12)
  at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
  at node:internal/main/run_main_module:17:47

Node.js v17.8.0
[BUILD FAILED]

Let me know if you need any other info

I've been thinking for a while on what the right concurrency primitives should be for Lux.
There are a few considerations the design should take into account in order to satisfy all that's needed.

1. The library/model should work on all of the supported platforms for Lux in the same way.
2. Lux should ideally provide the most primitive, but usable, concurrency model, so that more advanced infrastructure can easily be built on top.

There were 5 models I considered while doing research and design for concurrency.

1. Software Transactional Memory (STM)
2. Promises/Futures
3. Communicating Sequential Processes (CSP)
4. Functional-Reactive Programming (FRP)
5. Actor model

Thinking about those models, I was first considering which models could be implemented on top of other ones, hoping that many ways of doing concurrency could be supported while doing minimal base work on Lux.

Actor model on top of of CSP

This one seems to me to be the easiest one to do.
All that would be needed to do that is to have some form of ID assigned to each CSP process and to assign channels for the exclusive use of processes to serve as mailboxes.
Finally, some error-handling & monitoring mechanisms would need to be added to handle the failure/crash of actors.

Actors, however, seem a bit too heavyweight to be a concurrency mechanism for programs.
That being said, I do think they would be an excellent choice for doing distributed programming, as having identity for processes means that you could have actors on one machine communicating with actors on another machine.

Because of that, I think it would be best to leave actors outside of the Lux standard library in order to implement them in a more heavyweight distributed programming framework.

Simplifying Promises and Futures

From what I've seen, languages that have both seem to show a somewhat confusing picture.
The story goes like this:
A future points to a value that will eventually be made available.
Futures are read-only.
A promise also points to a value that will eventually be made available.
Promises can be written to.
You set the value of a future by writing to its associated promise.

For those of you familiar with Clojure's promises and futures, that story might sound a bit weird.
You only know that promises are little black boxes you can write once to, while futures run code whose return value is the value of the future.
On the inside, the story is the same as the one above, even if it looks a bit simpler.

I think this whole divide between futures and promises sounds a bit ridiculous, so I'd rather simplify things a bit.

I'm thinking of having a type (Async a). It would be implemented natively on every platform Lux runs. You will only be able to set it once.
If you try to get it's value and it's already set, you'll just get it.
Otherwise, you'll give it a callback that will be run once the value has been set.

Async will have both Functor and Monad implementations, with the idea of making asynchronous computation feel synchronous (having the same effect that you get from using Clojure's core.async).

Lux will also provide a thread-pool that will be used to run the callbacks every time a promise is set.
Functions such as timeouts/delays, and I/O would return Async values in order to async-io.
Processes could communicate with each other by messaging through Async.

A function called future could transform (IO a) into (Async a), to make interfacing with synchronous code easy,

CSP on top of Async

Traditionally, CSP relies on channels to do inter-process communication.
As flexible and cool as that might be, channels are actually unnecessary. You can do all of your communication and synchronization just using Async values.

With that said, channels could be implemented on top of Async:

(deftype (Chan a)
  (Async (Maybe (, a (Chan a)))))

The use of Maybe means channels can be closed by just setting an Async to #None.
Channels implemented this way would be unbounded, unlike channels in other languages; though I don't see that causing much of a problem.

Finally, it will be possible to access old/previous values in a channel by just holding on to previous nodes.

Any CSP process that needed to constantly receive inputs could just process a channel step-by-step, dropping older nodes and only using the latest one if it doesn't need to remember the past.

FRP on top of Async

FRP is much easier to do on top of Async (by using channels), as it just needs to piggy-back on the Functor implementation for Chan, or on the Monad implementation, if fancier work needs to be done.

All that would be necessary is adding the functions and combinators commonly expected for FRP.

STM ???

Actors can be done on top of CSP.
CSP and FRP can be done on top of Async (our little promise/future hybrid).

What happens now with STM?

The thing with STM is that it's fundamentally different from all the other ones.
Promises/futures, CSP and Actors can all be seen as ways to get processes to communicate with each other.
FRP can be interpreted as the same thing, assuming that transformations on channels will be done concurrently by processes hosted by the thread-pool.

STM is not really about communication.
STM is about how do you get multiple processes to bang on shared state without breaking anything.

For that reason, I get the feeling implementing STM on top of promises is probably not feasible (at least with anything resembling good performance).

Now... I'll be honest. I've never used Clojure's STM in any significant way.
I just used atoms for everything until core.async arrived, and then CSP became my hammer of choice.

For that reason, I'm somewhat biased to just dismiss STM and go on the Async (promisses) route.

This is still an open issue

I'm pretty confident that going in the Async route and forgetting STM is a good way to go, but there's nothing set on stone right now.

I made this repo issue to see if there were any ideas anyone else might have regarding concurrency in Lux.

Is it a bad idea to implement CSP & FRP on top of promises?

Is STM more useful and necessary than I think?

Feel free to give your 2 cents.

I plan on implementing promises, CSP and FRP for version 0.3.2, provided that I stay on the path described on this issue.

Here's your chance to alter the course of history.

Running a free software community, you'll benefit from a https://gitter.im channel. It's much easier for people to start a discussion there than mailing lists. In ENSIME, we've found that much more people engage with us through the issue tracker, twitter and gitter than the mailing list.

Going through the readme, the example program compiles, but doesn't run.

Here are the commands I ran after checking the lux program out into "lux"

experimental> cp -r lux/source/* source/
experimental> ls source/
lux     lux.lux     program.lux
experimental> java -jar -Xss4m lux-jvm-0.2.0-standalone.jar program
DEF lux;Bool
DEF lux;Int
...
DEF program;text:unit
DEF program;text:++
Compilation complete!
"Elapsed time: 27331.357 msecs"
experimental> cd target/jvm/ && java -jar program.jar
Exception in thread "main" java.lang.NoClassDefFoundError: lux_data_io/IO (wrong name: lux_data_io/io)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at lux_data_io.println.<clinit>(Unknown Source)
    at program._.main(Unknown Source)

were those the right commands commands to run? Thanks!

Hello, I get an exception when trying to execute lein lux repl in the shell, I have leiningen 2.7.1 java 1.8.0 and lein lux build and lein lux test seem to work fine, here's my project.clj file:

(defproject lux_tests "0.1.0-SNAPSHOT"
:plugins [[com.github.luxlang/lein-luxc "0.5.0"]]
:dependencies []
:lux {:program "main"}
:source-paths ["source"]
)

and the error code:
lein lux repl
clojure.lang.ArityException: Wrong number of args (2) passed to: utils/repl-path
at clojure.lang.AFn.throwArity (AFn.java:429)
clojure.lang.AFn.invoke (AFn.java:36)
leiningen.lux.repl$repl.invokeStatic (repl.clj:9)
leiningen.lux.repl$repl.invoke (repl.clj:8)
leiningen.lux$lux.invokeStatic (lux.clj:14)
leiningen.lux$lux.doInvoke (lux.clj:10)
clojure.lang.RestFn.invoke (RestFn.java:423)
clojure.lang.Var.invoke (Var.java:383)
clojure.lang.AFn.applyToHelper (AFn.java:156)
clojure.lang.Var.applyTo (Var.java:700)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$apply.invoke (core.clj:641)
leiningen.core.main$partial_task$fn__5932.doInvoke (main.clj:272)
clojure.lang.RestFn.applyTo (RestFn.java:139)
clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invokeStatic (core.clj:648)
clojure.core$apply.invoke (core.clj:641)
leiningen.core.main$apply_task.invokeStatic (main.clj:322)
leiningen.core.main$apply_task.invoke (main.clj:308)
leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
leiningen.core.main$_main$fn__5998.invoke (main.clj:401)
leiningen.core.main$_main.invokeStatic (main.clj:394)
leiningen.core.main$_main.doInvoke (main.clj:391)
clojure.lang.RestFn.invoke (RestFn.java:421)
clojure.lang.Var.invoke (Var.java:383)
clojure.lang.AFn.applyToHelper (AFn.java:156)
clojure.lang.Var.applyTo (Var.java:700)
clojure.core$apply.invokeStatic (core.clj:646)
clojure.main$main_opt.invokeStatic (main.clj:314)
clojure.main$main_opt.invoke (main.clj:310)
clojure.main$main.invokeStatic (main.clj:421)
clojure.main$main.doInvoke (main.clj:384)
clojure.lang.RestFn.invoke (RestFn.java:457)
clojure.lang.Var.invoke (Var.java:394)
clojure.lang.AFn.applyToHelper (AFn.java:165)
clojure.lang.Var.applyTo (Var.java:700)
clojure.main.main (main.java:37)

I've tried running eval "$(lein lux repl)" as advised by the lux book which outputs:
bash: syntax error near unexpected token (' `

please excuse me for the bad markdown.

Hello,

I'm just a curious person that happens to use (and love) Clojure, so Lux is kinda interesting for me. With the recent announcement of Oracle's GraalVM, did you already think of using it somehow for Lux ?

Thanks in advance for your answer.

Gitbook link in repo redirects to Gitbooks title page.

I tried to run the "hello world" example as described in chapter 1 of the Lux book. Running lein terminated with a java.lang.ClassCastException. I guess it's because I'm using JDK9 on my computer.

C:\Users\Dominikus\Lux\myproject>lein lux build
Retrieving com/github/luxlang/lein-luxc/0.5.0/lein-luxc-0.5.0.pom from central
Retrieving org/clojure/clojure/1.6.0/clojure-1.6.0.pom from central
Retrieving com/github/luxlang/luxc-jvm/0.5.0/luxc-jvm-0.5.0.pom from central
Retrieving org/clojure/core.match/0.2.1/core.match-0.2.1.pom from central
Retrieving org/clojure/pom.contrib/0.1.2/pom.contrib-0.1.2.pom from central
Retrieving org/clojure/clojure/1.4.0/clojure-1.4.0.pom from central
Retrieving org/sonatype/oss/oss-parent/5/oss-parent-5.pom from central
Retrieving org/ow2/asm/asm-all/5.0.3/asm-all-5.0.3.pom from central
Retrieving org/ow2/asm/asm-parent/5.0.3/asm-parent-5.0.3.pom from central
Retrieving com/github/luxlang/stdlib/0.5.0/stdlib-0.5.0.pom from central
Retrieving org/clojure/clojure/1.6.0/clojure-1.6.0.jar from central
Retrieving org/clojure/core.match/0.2.1/core.match-0.2.1.jar from central
Retrieving org/ow2/asm/asm-all/5.0.3/asm-all-5.0.3.jar from central
Retrieving com/github/luxlang/luxc-jvm/0.5.0/luxc-jvm-0.5.0.jar from central
Retrieving com/github/luxlang/lein-luxc/0.5.0/lein-luxc-0.5.0.jar from central
Retrieving com/github/luxlang/stdlib/0.5.0/stdlib-0.5.0.jar from central
java.lang.ClassCastException: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader
 at leiningen.lux.utils$all_jars_in_classloader.invokeStatic (utils.clj:30)
    leiningen.lux.utils$all_jars_in_classloader.invoke (utils.clj:29)
    leiningen.lux.utils$compile_path.invokeStatic (utils.clj:66)
    leiningen.lux.utils$compile_path.invoke (utils.clj:66)
    leiningen.lux.builder$build.invokeStatic (builder.clj:8)
    leiningen.lux.builder$build.invoke (builder.clj:6)
    leiningen.lux$lux.invokeStatic (lux.clj:12)
    leiningen.lux$lux.doInvoke (lux.clj:10)
    clojure.lang.RestFn.invoke (RestFn.java:423)
    clojure.lang.Var.invoke (Var.java:383)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$partial_task$fn__5932.doInvoke (main.clj:272)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$apply_task.invokeStatic (main.clj:322)
    leiningen.core.main$apply_task.invoke (main.clj:308)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
    leiningen.core.main$_main$fn__5998.invoke (main.clj:401)
    leiningen.core.main$_main.invokeStatic (main.clj:394)
    leiningen.core.main$_main.doInvoke (main.clj:391)
    clojure.lang.RestFn.invoke (RestFn.java:421)
    clojure.lang.Var.invoke (Var.java:383)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    clojure.lang.RestFn.invoke (RestFn.java:457)
    clojure.lang.Var.invoke (Var.java:394)
    clojure.lang.AFn.applyToHelper (AFn.java:165)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

Hi! I can successfully build and run the hello world example from the book, as-is for version 0.7.0. When I change everything to 0.8.0 in the project.lux I get the following:

my_project ❯ lux build
[?] Fetching com.github.luxlang:lux-jvm-0.8.0 from "/Users/cnmne/.m2/repository"
[X] Missed com.github.luxlang:lux-jvm-0.8.0 from "/Users/cnmne/.m2/repository"
[?] Fetching com.github.luxlang:stdlib-0.8.0 from "/Users/cnmne/.m2/repository"
[X] Missed com.github.luxlang:stdlib-0.8.0 from "/Users/cnmne/.m2/repository"
[?] Fetching com.github.luxlang:lux-jvm-0.8.0 from "https://repo1.maven.org/maven2/"
[O] Found com.github.luxlang:lux-jvm-0.8.0 at "https://repo1.maven.org/maven2/"
[?] Fetching com.github.luxlang:lux-jvm-function-0.6.5 from "https://repo1.maven.org/maven2/"
[O] Found com.github.luxlang:lux-jvm-function-0.6.5 at "https://repo1.maven.org/maven2/"
[?] Fetching com.github.luxlang:stdlib-0.8.0 from "https://repo1.maven.org/maven2/"
[O] Found com.github.luxlang:stdlib-0.8.0 at "https://repo1.maven.org/maven2/"
 Local successes:
  Local failures: 0: "com.github.luxlang:lux-jvm-0.8.0"
                  1: "com.github.luxlang:stdlib-0.8.0"
Remote successes: 0: "com.github.luxlang:lux-jvm-0.8.0"
                  1: "com.github.luxlang:lux-jvm-function-0.6.5"
                  2: "com.github.luxlang:stdlib-0.8.0"
 Remote failures:
[BUILD STARTED]
Duration: +45ms

Compilation failed:
{library/lux/data/format/tar.invalid_end_of_archive}


[BUILD FAILED]

... project.lux

[""
 ["identity" ["my.group" "my_project" "0.1.0-SNAPSHOT"]
  "repositories" ["https://oss.sonatype.org/content/repositories/snapshots/"
                  "https://oss.sonatype.org/service/local/staging/deploy/maven2/"]
  
  "dependencies" [["com.github.luxlang" "stdlib" "0.8.0" "tar"]]
  "lux" ["com.github.luxlang" "lux-jvm" "0.8.0" "jar"]

  "program" main.main]]

... By default, Aedifex uses the "source" directory for finding your source-code.
... The file containing our program will be my_project/source/main.lux.

I'm using the aedifex.jar asset from the 0.8.0 release in each case. I have no experience with the "Nexus Repository Manager", so I'm not sure if I might be using that incorrectly?

I've tried wiping the target directory and rebuilding. I haven't modified/deleted anything in ~/.m2/.

tried building a lux project and got this exception when using both lein lux build and lein lux auto build

Exception in thread "main" java.lang.AssertionError: Assert failed: (not (nil? %))                                              at leiningen.lux.utils$find_compiler_path.invokeStatic(utils.clj:35) at leiningen.lux.utils$find_compiler_path.invoke(utils.clj:35) at leiningen.lux.utils$compile_path.invokeStatic(utils.clj:66) at leiningen.lux.utils$compile_path.invoke(utils.clj:66) 
at leiningen.lux.builder$build.invokeStatic(builder.clj:8) at leiningen.lux.builder$build.invoke(builder.clj:6)                                                                    at leiningen.lux$lux.invokeStatic(lux.clj:12)  at leiningen.lux$lux.doInvoke(lux.clj:10)                                                                               at clojure.lang.RestFn.invoke(RestFn.java:423) at clojure.lang.Var.invoke(Var.java:383)                                                                                at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.Var.applyTo(Var.java:700)                                                                               at clojure.core$apply.invokeStatic(core.clj:648) at clojure.core$apply.invoke(core.clj:641)                                                                              at leiningen.core.main$partial_task$fn__4667.doInvoke(main.clj:284) at clojure.lang.RestFn.applyTo(RestFn.java:139) at clojure.lang.AFunction$1.doInvoke(AFunction.java:29)                                                                 at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invokeStatic(core.clj:648)                                                                        at clojure.core$apply.invoke(core.clj:641) at leiningen.core.main$apply_task.invokeStatic(main.clj:334)                                                            at leiningen.core.main$apply_task.invoke(main.clj:320)  at leiningen.core.main$resolve_and_apply.invokeStatic(main.clj:340) at leiningen.core.main$resolve_and_apply.invoke(main.clj:336) at leiningen.core.main$_main$fn__4734.invoke(main.clj:420) at leiningen.core.main$_main.invokeStatic(main.clj:411) at leiningen.core.main$_main.doInvoke(main.clj:408) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:383) at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.Var.applyTo(Var.java:700) at clojure.core$apply.invokeStatic(core.clj:646)  at clojure.main$main_opt.invokeStatic(main.clj:314) at clojure.main$main_opt.invoke(main.clj:310) at clojure.main$main.invokeStatic(main.clj:421) at clojure.main$main.doInvoke(main.clj:384)  at clojure.lang.RestFn.invoke(RestFn.java:457)at clojure.lang.Var.invoke(Var.java:394) at clojure.lang.AFn.applyToHelper(AFn.java:165)  at clojure.lang.Var.applyTo(Var.java:700)  at clojure.main.main(main.java:37)      

my project.clj

(defproject lux/program1 "0.1.0-SNAPSHOT"
  :plugins [[com.github.luxlang/lein-luxc "0.5.0"]]
  :dependencies [[io.vertx/vertx-web "3.0.0"]]
  :source-paths ["source"]
  :lux {:program "main"}
  )

As I'm currently developing a tree-sitter grammar for Lux I've looked at the syntax file you committed and I have some questions:

1. Is it valid to have consecutive commas inside a number or can there only be one comma between two numbers? So are the following valid naturals?

   • 1,,0 (= 10)
   • 123,,,,,456 (= 123456)

2. Are there plans to support exponential notation for fracs (and potentially revs)? e.g.

   • +1.0e4 (= 10000)
   • +123.4e-5 (= 0.01234)
   • .1234e-1 (= 0.01234; for revs there would need to be some restrictions on the exponent so that the resulting number is still between 0 and 1)
     I'm not saying that it's particularly necessary, but it might be convenient sometimes.

3. Can the sign for fractions be optional? E.g. are

   • 1.0
   • 123.456
     valid? The syntax document says that fracs look like ints followed by a rev so there should always be a sign. However, I tried to parse new-luxc with the grammar I wrote so far and there seem to be some instances of floating point numbers that don't have a sign. Some examples:

   • lux/new-luxc/source/luxc/lang/translation/r/case.jvm.lux

     Line 68 in 4049370

     (push! (r.slice (r.float 1.0) (r.length (@@ $cursor)) (@@ $cursor))

   • lux/new-luxc/source/luxc/lang/translation/r/runtime.jvm.lux

     Line 257 in 4049370

     [(|> (@@ input) (r.+ (r.float 1.0)) (r.>= f2^63))

   • lux/new-luxc/source/luxc/lang/translation/r/runtime.jvm.lux

     Line 434 in 4049370

     delta (r.if (|> (r.float 48.0) (r.<= (@@ log2)))

4. Regarding juxtaposition of expressions: My guess is that there are some rules about which expressions can be placed next to each other without whitespace as separator and which cannot. For example: There is no ambiguity in separating two texts next to each other

    "text-a""text-b" 
   

   I'm guessing this would just parse as two separate texts even though there is no whitespace between them. The same goes for all enclosed literals (forms, tuples, records).
   However, there is some ambiguity for example with tags:

    #tag#followed-by-tag
   

   Are these two separate tags or would this be a syntax error?
   And what about identifiers:

    a.bc.d
   

   My guess is that this would be parsed as 2 identifiers (a.bc and .d). The parser couldn't know that I actually meant that this should be the identifiers a.b and c.d because I didn't write a whitespace. However, the parser could state that the expression as a whole (not separated by whitespace) is not a valid identifier since it has more than one dot inside. In this case putting a whitespace at the right position could fix the ambiguity.
   So basically, my question is whether the parser gives a syntax error when there is a potentially erroneous situation like the one above with the identifiers and forces you to fix the ambiguity or if it just starts a new identifier when it sees a dot followed by a character even if there is no whitespace to separate it from the previous identifier.

Not all features are supported on all backends. Most notably, I've seen Lua omitted in several places. There needs to be a features matrix that users can refer to to see what stdlib features are available to each backend.

See this build job: https://builds.sr.ht/~hedgewitch/job/704798

Aedifex can't access the console in CI because CI services use headless JVMs.

Both helloworld and tutorial1 fail on lein lux build with:

[BUILD BEGIN]
Exception in thread "main" java.lang.NoSuchMethodError: java.lang.Long.parseUnsignedLong(Ljava/lang/String;)J
        at lux.parser$fn__6996.invoke(parser.clj:80)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.parser$repeat_PERCENT_$fn__6923.invoke(parser.clj:19)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.parser$repeat_PERCENT_$fn__6923.invoke(parser.clj:19)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.parser$repeat_PERCENT_$fn__6923.invoke(parser.clj:31)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.parser$repeat_PERCENT_$fn__6923.invoke(parser.clj:31)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.parser$repeat_PERCENT_$fn__6923.invoke(parser.clj:31)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.parser$repeat_PERCENT_$fn__6923.invoke(parser.clj:31)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.base$exhaust_PERCENT_$fn__1855.invoke(base.clj:665)
        at lux.base$exhaust_PERCENT_$fn__1855.invoke(base.clj:667)
        at lux.base$exhaust_PERCENT_$fn__1855.invoke(base.clj:667)
        at lux.base$exhaust_PERCENT_$fn__1855.invoke(base.clj:667)
        at lux.base$exhaust_PERCENT_$fn__1855.invoke(base.clj:667)
        at lux.base$exhaust_PERCENT_$fn__1855.invoke(base.clj:667)
        at lux.base$exhaust_PERCENT_$fn__1855.invoke(base.clj:667)
        at lux.base$with_writer$fn__2154.invoke(base.clj:982)
        at lux.compiler$fn__28796$compile_module__28797$fn__28798$fn__28804$fn__28806$fn__28809$fn__28812$fn__28828$fn__28831.invoke(compiler.clj:210)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.base$run_state.invoke(base.clj:919)
        at lux.base$_BAR_eitherL$fn__3023.invoke(base.clj:1520)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.base$bind$fn__1304.invoke(base.clj:382)
        at lux.base$bind$fn__1304.invoke(base.clj:385)
        at lux.compiler$fn__28911$compile_program__28912.invoke(compiler.clj:263)
        at lux$_main.doInvoke(lux.clj:29)
        at clojure.lang.RestFn.applyTo(RestFn.java:137)
        at lux.main(Unknown Source)
[BUILD END]

lein lux repl fails with

clojure.lang.ArityException: Wrong number of args (2) passed to: utils/repl-path
 at clojure.lang.AFn.throwArity (AFn.java:429)
    clojure.lang.AFn.invoke (AFn.java:36)
    leiningen.lux.repl$repl.invokeStatic (repl.clj:9)
    leiningen.lux.repl$repl.invoke (repl.clj:8)
    leiningen.lux$lux.invokeStatic (lux.clj:14)
    leiningen.lux$lux.doInvoke (lux.clj:10)
    clojure.lang.RestFn.invoke (RestFn.java:423)
    clojure.lang.Var.invoke (Var.java:383)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$partial_task$fn__5932.doInvoke (main.clj:272)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$apply_task.invokeStatic (main.clj:322)
    leiningen.core.main$apply_task.invoke (main.clj:308)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
    leiningen.core.main$_main$fn__5998.invoke (main.clj:401)
    leiningen.core.main$_main.invokeStatic (main.clj:394)
    leiningen.core.main$_main.doInvoke (main.clj:391)
    clojure.lang.RestFn.invoke (RestFn.java:421)
    clojure.lang.Var.invoke (Var.java:383)
    clojure.lang.AFn.applyToHelper (AFn.java:156)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    clojure.lang.RestFn.invoke (RestFn.java:457)
    clojure.lang.Var.invoke (Var.java:394)
    clojure.lang.AFn.applyToHelper (AFn.java:165)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

$ lein --version
Leiningen 2.7.1 on Java 1.7.0_151 OpenJDK 64-Bit Server VM

Running Archlinux. No experience with Java or Clojure, so this might be something trivial. Clojure helloworld works fine, as does repl. Luxc version in project.clj is 0.5.0.

Hi,

Just found out about Lux. You should add it to this page to get more exposure. I know I had previously looked there for functional languages and never ended up finding out about lux, until I did a search for "ML JVM".

-- Chad

If you're building a community, I recommend putting one in place. In ENSIME, we welcome contributors with this page https://github.com/ensime/ensime-server/blob/master/CONTRIBUTING.md which leads to https://github.com/ensime/ensime-server/wiki/Code-of-Conduct

It's really good to have one in place just incase a bad apple comes along, who destroys everything that you've worked for.

Could you add a comparison to Typed Racket? What advantages to you see to Lux? Could you acknowledge advantages that Racket has?

Hello there,

I was playing with lux a bit, and ran into an infinite loop with this code:

 lux (lux (host jvm io)
          (control monad functor)
          (codata io)
          (data
           (number #open ("int:" Int/Number))
           (maybe #as May))))

(def (>>= m ma f)
  (All [m a b]
    (-> (Monad m) (m a) (-> a (m b)) (m b)))
  (using m
    (join (map f ma))))

(def (tellWhat a)
  (-> (Maybe Text) (IO (,)))
  (case a
    #;None (print-line "none")
    (#;Some b) (print-line b)))

(def (echo)
  (IO (,))
  (>>= IO/Monad read-line tellWhat))

Most likely the mistake is on my side too, since I still don't understand all, what I am using there...
I am still using luxc3.1.jar since I am getting the following error with luxc.3.2.jar and the following

project.clj:
(defproject lux/testingLux "0.1.0-SNAPSHOT"
  :plugins [[lux/lein "0.1.0"]]
  :dependencies [[lux/stdlib "0.3.2"]]
  :lux/program "testingLux")

lein luxc compile
[BEGIN]

Exception in thread "main" java.lang.AssertionError: Assert failed: @ lux,7,0
[Analyser Error] Unknown syntax: "(_lux_def Bool (10 [\"lux\" \"Bool\"] (0 \"java.lang.Boolean\" (0))))"

false
    at lux.compiler$compile_program.invoke(compiler.clj:556)
    at lux$_main.doInvoke(lux.clj:17)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at lux.main(Unknown Source)
[END]

Current behavior:

$ lein lux build && ls
[BUILD BEGIN]
DEF main;Text/unit
DEF main;Text/append
DEF main;fold
DEF main;identity-text
DEF main;let-test
DEF main;append-three
Compilation failed:
@ main,34,9
[Analyser Error @ find-def] Definition does not exist: main;Text/appnd
[Analyser Error] Functions require function types: (-> (lux;List lux;Text) lux;Text)
[BUILD END]
./  ../  project.clj  source/  target/  Taskfile.yml

For use in CI pipelines

osx 10.11, jdk 1.8.0_112. The first toy project in the book, chap. 1, works. REPL shows the following error at start (below, ../lux_test/.. is ../my_project/..)
$ lein lux repl

$ java -XX:+TieredCompilation -XX:TieredStopAtLevel=1 -XX:-OmitStackTraceInFastThrow -cp $HOME/.m2/repository/com/github/luxlang/luxc-jvm/0.5.0/luxc-jvm-0.5.0.jar:$HOME/.m2/repository/com/github/luxlang/stdlib/0.5.0/stdlib-0.5.0.jar:$HOME/.m2/repository/org/clojure/clojure/1.6.0/clojure-1.6.0.jar:$HOME/.m2/repository/org/clojure/core.match/0.2.1/core.match-0.2.1.jar:$HOME/.m2/repository/org/ow2/asm/asm-all/5.0.3/asm-all-5.0.3.jar:$HOME/.m2/repository/org/clojure/tools.nrepl/0.2.12/tools.nrepl-0.2.12.jar:$HOME/.m2/repository/clojure-complete/clojure-complete/0.2.4/clojure-complete-0.2.4.jar lux repl $HOME/tmp/lux_test/source

Exception in thread "main" clojure.lang.ArityException: Wrong number of args (0) passed to: compiler/init!
at clojure.lang.AFn.throwArity(AFn.java:429)
at clojure.lang.AFn.invoke(AFn.java:28)
at lux.repl$init.invoke(repl.clj:28)
at lux.repl$repl.invoke(repl.clj:55)
at lux$_main$fn__29097$fn__29098.invoke(lux.clj:35)
at lux$_main$fn__29097.invoke(lux.clj:27)
at lux$_main.doInvoke(lux.clj:27)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at lux.main(Unknown Source)`