Pushing forward

[Robert Kuzelj]

At the moment I'd like to do some work on the Erlang VM and I am researching a few options (Erlang the language isn't one of course)

- LFE (but List-2 and funcall)

- Elixir (somehow nice syntax BUT 3 different function call syntaxes <shudder>)

- Joxa (nicest and cleanest imo but still very, very early and so many things missing )

I could help with the std library or dependency management / project management.

Robertj

[Eric Merritt]

Robert,

 Lets start with listing out the missing pieces of Joxa. I think that would be useful information.

Eric

--
You received this message because you are subscribed to the Google Groups "joxa" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joxa+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Kuzelj]

Ok. Here is my List

CORE

- Reader Macro => Should allow for a lot of syntactic sugar

- destructuring syntax=> maybe that could also be done via reader macros as well? I think one of Clojures sweet points

INFRASTRUCTURE

- Std. Libraries

- Project management tools

- Dependency management tools

- Default Repository for Joxa Libs

DOCUMENTATION

- Language (and differences to other Lisps/Clojure/Erlang)

- Libraries

One specific discussion point (or not) is how far Joxa should lean towards Clojure (syntax and libraries)

IMHO I would suggest to lean as far as possible towards clojure as it has the biggest community out there and we could probably copy lots if stuff from them.

ciao robertj

[Eric Merritt]

Replies inline:

On Fri, Aug 1, 2014 at 2:56 AM, Robert Kuzelj <rob...@robkuz.com> wrote:

Ok. Here is my List

CORE

- Reader Macro => Should allow for a lot of syntactic sugar

Reader macros are already in the roadmap

 

- destructuring syntax=> maybe that could also be done via reader macros as well? I think one of Clojures sweet points

What do you mean here. We already have pattern matching, I am not sure how destructing is different.

 

INFRASTRUCTURE

- Std. Libraries

This begs the question. Historically, joxa has relied on Erlangs libraries. So we didn't replace anything that already existed. Should Joxa have its on Std apart from erlang?

 

- Project management tools

- Dependency management tools

Some thing to some extent with the above here. We have simply relied on erlangs stuff. I think the argument you are making is to move away from that.

 

- Default Repository for Joxa Libs

What do you mean here? A library for the std lib apart from the joxa repo?

 

DOCUMENTATION

- Language (and differences to other Lisps/Clojure/Erlang)

- Libraries

One specific discussion point (or not) is how far Joxa should lean towards Clojure (syntax and libraries)

IMHO I would suggest to lean as far as possible towards clojure as it has the biggest community out there and we could probably copy lots if stuff from them.

So I have little or no interest in reimplementing clojure. I don't mind borrowing ideas from them, or from any other lisp for that matter. However, I think we have some very unique capabilities across the board with Joxa/ERTS and we should bend the language to take advantage of that.

[Bernie R]

Hi Eric and Robert,

first off, it's great to see some action on Joxa again!

I understand your unwillingness to simply reimplement Clojure and it would be a waste of effort to stop there without focusing on the capabilities Erlang brings to the table.
However, I would also like to second Robert's suggestion to stay somewhat close to Clojure syntax and libs style. The language has proven itself to work well in practice and attracted a fairly large and very active community. Making it easy for them to cross over and try out Joxa could be a huge asset.

Also, are you familiar with Brace? It looks like a fork by Maxim who is one of the lead guys behind the N2O framework. Maybe he could be interested in contributing as well.
https://github.com/devaspot/brace

Cheers,
Bernie

[Eric Merritt]

Bernie,

 I certainly don't have any problem pulling from closure.  We have done that and will continue to do that :)

I was aware that Maxim was going to do that. He pinged me about it. No reason we can't pull back in ideas where it makes sense.

Eric

[Robert Kuzelj]

sorry for the late reply

CORE

- Reader Macro => Should allow for a lot of syntactic sugar

Reader macros are already in the roadmap

Do you need help on this?

I tried to look thru joxa/src/joxa-cmp-peg.jxa ?

But I couldnt make sense out of it on my own.

- destructuring syntax=> maybe that could also be done via reader macros as well? I think one of Clojures sweet points

What do you mean here. We already have pattern matching, I am not sure how destructing is different.

I am not sure of all of this (http://blog.jayfields.com/2010/07/clojure-destructuring.html) is really possible with erlang destructuring or

if this kind is anyhow possible when targeting the ERL VM.

 

  

INFRASTRUCTURE

- Std. Libraries

This begs the question. Historically, joxa has relied on Erlangs libraries. So we didn't replace anything that already existed. Should Joxa have its on Std apart from erlang?

I think Joxa being a Lisp should have more lispy libraries ... no?

 

- Project management tools

- Dependency management tools

Some thing to some extent with the above here. We have simply relied on erlangs stuff. I think the argument you are making is to move away from that.

not necessarily so - but I am leaning towards it. At the very least we should exactly explain in the joxa docs why and how you should for example use rebar.

Instead of simply advising the user to use rebar and RTFM. Again Clojure does a good job with Leiningen - It does it all the stuff in Clojure syntax AND uses transparently Maven or Ivy in the background so you dont need to know about it (at least initially)

 - Default Repository for Joxa Libs

What do you mean here? A library for the std lib apart from the joxa repo?

an online repository that allows for easy finding/resolution and download of joxa libraries. similar to npm.org in the node world or rubygems or clojars.org etc.

 

DOCUMENTATION

- Language (and differences to other Lisps/Clojure/Erlang)

- Libraries

One specific discussion point (or not) is how far Joxa should lean towards Clojure (syntax and libraries)

IMHO I would suggest to lean as far as possible towards clojure as it has the biggest community out there and we could probably copy lots if stuff from them.

So I have little or no interest in reimplementing clojure. I don't mind borrowing ideas from them, or from any other lisp for that matter. However, I think we have some very unique capabilities across the board with Joxa/ERTS and we should bend the language to take advantage of that.

Why would one exclude the other? 

I must admit that of all the lisps out there Clojure has the most appeal to me. The biggest reason being that it has a much nicer syntax that is so much easier on the eyes.

For example 

(let [x 1 y 2]

  ...)

is so much easier to read than

(let ((x 1) (y 2))

   ...) 

It seems so minute - but it has a drastic effect on readability (imho)

[Eric Merritt]

On Fri, Aug 8, 2014 at 8:00 AM, Robert Kuzelj <rob...@robkuz.com> wrote:

sorry for the late reply

CORE

- Reader Macro => Should allow for a lot of syntactic sugar

Reader macros are already in the roadmap

Do you need help on this?

I tried to look thru joxa/src/joxa-cmp-peg.jxa ?

Its a peg grammer. You need to get your mind around pegs before it starts making sense. That said, the entire parsing infrastructure needs a rewrite. Its way too slow. I still like the idea of introduce the peg to users. I think its more approachable than normal reader macros. However, I am more than willing to discuss that. It may be just easier to model normal reader macros.

 

But I couldnt make sense out of it on my own.

- destructuring syntax=> maybe that could also be done via reader macros as well? I think one of Clojures sweet points

What do you mean here. We already have pattern matching, I am not sure how destructing is different.

I am not sure of all of this (http://blog.jayfields.com/2010/07/clojure-destructuring.html) is really possible with erlang destructuring or

if this kind is anyhow possible when targeting the ERL VM.

From the look of things its not different at all. We should have a conversation around how to surface that better. For example, `joxa-core/let*` does that right now but the `let` special form does not. Joxa has been follow the model of a simple and understandable base language with everything interesting as librarys. So the above `joxa-core/let*` is a macro that maps onto `case` special forms. 

 

 

  

INFRASTRUCTURE

- Std. Libraries

This begs the question. Historically, joxa has relied on Erlangs libraries. So we didn't replace anything that already existed. Should Joxa have its on Std apart from erlang?

I think Joxa being a Lisp should have more lispy libraries ... no?

I actually agree with this. It would probably be nice to come up with a set of targets that we should shoot for.

 

 

- Project management tools

- Dependency management tools

Some thing to some extent with the above here. We have simply relied on erlangs stuff. I think the argument you are making is to move away from that.

not necessarily so - but I am leaning towards it. At the very least we should exactly explain in the joxa docs why and how you should for example use rebar.

Instead of simply advising the user to use rebar and RTFM. Again Clojure does a good job with Leiningen - It does it all the stuff in Clojure syntax AND uses transparently Maven or Ivy in the background so you dont need to know about it (at least initially)

I would add that rebar is a rather poor tool. It could be that we adopt one of the better ones and simply wrap it in some joxa-ish goodness. I will try to come up with a list of options and some support ideas. You can too.

 

 - Default Repository for Joxa Libs

What do you mean here? A library for the std lib apart from the joxa repo?

an online repository that allows for easy finding/resolution and download of joxa libraries. similar to npm.org in the node world or rubygems or clojars.org etc.

 

Ah, yes a package repository essentially. I think we can do that. We may even be able to leverage some of the stuff thats going on in the Elixir space.

 

DOCUMENTATION

- Language (and differences to other Lisps/Clojure/Erlang)

- Libraries

One specific discussion point (or not) is how far Joxa should lean towards Clojure (syntax and libraries)

IMHO I would suggest to lean as far as possible towards clojure as it has the biggest community out there and we could probably copy lots if stuff from them.

So I have little or no interest in reimplementing clojure. I don't mind borrowing ideas from them, or from any other lisp for that matter. However, I think we have some very unique capabilities across the board with Joxa/ERTS and we should bend the language to take advantage of that.

Why would one exclude the other? 

The don't necessarily. However, saying we are going to implement clojure restricts us to only implementing clojurue and nothing more. Basically, it doesn't allow us to make the best decision given the platform and capabilities. So again, I think we should steal extensively from clojure, but never say we are going to reimplement it.

 

I must admit that of all the lisps out there Clojure has the most appeal to me. The biggest reason being that it has a much nicer syntax that is so much easier on the eyes.

For example 

(let [x 1 y 2]

  ...)

is so much easier to read than

(let ((x 1) (y 2))

   ...) 

I tend to agree with this. I tend to like closure's syntax as well.