Hacker News new | past | comments | ask | show | jobs | submit login
Eden: a Lua-based scripting language in Clojure (github.com/benzap)
50 points by tosh on Aug 3, 2018 | hide | past | favorite | 19 comments



If this project relies on the GraalVM, I think it could go even further by implementing the GraalVM Polyglot interface [1] and becoming a first class language on the GraalVM. Then it wouldn't need to share Lisp syntax, and could use the real Lua syntax. It would also be much faster since it would be compiled into JVM bytecode by Graal compiler.

[1] https://www.graalvm.org/docs/graalvm-as-a-platform/implement...


I saw the title and thought "Hey, an old friend of mine would love this!"

Then I opened it and realized it was him who had written it. Small world.


Except for lisps, few languages let you name functions/variables using dashes and other symbols but looks like any legal name in Clojure is fair game:

    function people-eq?(p1 p2)
      if p1 == p2 then
        println("Are Equal!")
      else
        println("Not Equal!")
      end
    end
Interesting.


Common Lisp allows arbitrary names via escaped symbols:

  CL-USER 2 > (defun |this
  is a
  multiline
  symbol with whitespace|
                     (a b)
                (+ a b))
  |this
  is a
  multiline
  symbol with whitespace|

  CL-USER 3 > (|this
  is a
  multiline
  symbol with whitespace| 20 22)
  42


Then variable names can be very self-descriptive! Looks useful to me


And people wonder why it never caught on...


Yes, a common pattern in Clojure is to name your lookup functions like

(defn user-id->foo [user-id] ...)

Which allows for quite readable code when using it.


That seems to be because they use whitespace as commas (look at the parameter list). It also means you can't write "a - b" as "a-b" because the whitespace is now required. I can remember many times that I have typed "a-b" or "a+1" so I wouldn't be able to write in my natural style in this language. Maybe I'm wrong for using that style in the first place, but I think languages should be a little more permissive with style preferences like this.


Clojure uses prefix notation for math operations (since math operators are just functions), so you wouldn't write "a+b" or "a + b", you'd write "(+ a b)".


This is about Eden, which uses infix notation and Algolic syntax.


Perl6 allows scewer casing like that.


In Perl 6, this is usually called `kebab-casing`, instead of `skewer casing`.


Interesting project.

I think "Lua inspired" instead of "based" would be more accurate.

I have been quite happy with luaj for "end-user" scripting on a clojure app we develop. While it requires to know a bit about lua internals it's quite easy to use. Also just using Lua (plus some bundled fns) buys us a lot of stuff for free (libs, docs, tutorials etc).

I guess an advantage of eden could be portability (cljs), but it's not something that matters to me.


It's interesting that you are using LuaJ in your clojure app! I thought Lua was mostly used for scripting games, so I'm curious now: What is the benefit of using it within your closure app? What do you use it for?


Not the GP, so my guess:

> What is the benefit of using it within your closure app?

The benefit is probably it not being Clojure. While objectively not any better, more people are familiar with the non-prefix syntax and imperative semantics. If you intend the scripts to be written by some 3rd party, trying to convince them that Lisps are great is a waste of time. I mean, they are great - but there are many programmers (a majority, even) who don't care or can't appreciate it, and it gets even worse if you consider other professionals in the field.

If not for this, and if you don't need any particular feature the other language provides (in Lua it would be either sandboxing or coroutines, I think), then Clojure is perfectly capable of being used for scripting. Even more so than most languages; for example, simple syntax and macros (and the resulting ease of making DSLs) are desirable properties in a scripting language.


It's super easy to learn for people with programming experience limited excel macros and the like, not to mention the huge number of tutorials, books etc.

It's used in a rule engine for cases where the user needs an escape hatch to express super context specific rules we do not provide matchers for out of the box.


Excited to see that finally someone has written an imperative language in a functional runtime. Normally it's the other way around - countless Lisp implementations running in C, because those are trivial to write.

The most important feature of Eden IMHO is the copy-on-write semantics for collection that it inherited from Clojure. I hope this extends to nested structures like JSON data (it should). This opens the door to not having to distinguish between passing by value and passing by reference, although atom() is still available for mimicking references if needed. This opens the door for content-addressable memories and rapid application development where the user can focus on business logic, with less time wasted on the more mundane aspects of programming like resource management.

I've written about all this stuff countless times in previous comments so kudus to Eden for being one of the first languages I've seen to start getting this stuff right!


> Excited to see that finally someone has written an imperative language in a functional runtime.

Aren't there zillions of languages implemented on top of Lisp dialects?

    CL-USER 13 > (CLPYTHON.APP.REPL:REPL)
    Welcome to CLPython, an implementation of Python in Common Lisp.
    Running on: LispWorks 7.1.1
    REPL shortcuts: `:q' = quit, `:h' = help.

    ;; Consider customizing variable *CLPYTHON-MODULE-SEARCH-PATHS*
    ;; to be a list of paths that are tried when locating a module in order to import it
    ;; (in addition to the current directory and `sys.path'). Typically it should at least
    ;; contain the path to the Python 2.x standard libraries, as those are not
    ;; distributed with CLPython.
    >>> for i in range(4): print i
    ... 
    0
    1
    2
    3
    >>> 3 + 14
    17


> Excited to see that finally someone has written an imperative language in a functional runtime. Normally it's the other way around - countless Lisp implementations running in C, because those are trivial to write.

This is not as hard as one might imagine; the first assignment for a compiler course I took, was to write a interpreter for a simple imperative language, running in SML, a mostly functional language. The rest of the course was to write a compiler for another imperative language, again in SML. As soon as you know the "tricks" (some might call them patterns, if we were talking OOP), writing imperative code in functional languages is relatively easy.

The course followed "Modern Compiler Implementation in ML", if anyone is interested.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: