Discuss project/package organization to support more Lisp features

[oubiwann]

In PR #31, an important point was brought up: does REPL code below in the LispSyntax.jl package?

This also begs the same question for an evolving (if nascent) Lisp reader (mentioned in the same PR), Lisp parser (also mentioned in the same PR), etc.

[oubiwann]

I'll kick this off with a question, since 1) my Julia is pretty rusty, and 2) I think that Julia packages and/or their best practices have evolved a bit since I last worked with them:

• Do Julia projects (repositories) easily handle multiple packages? Or is the typical practice to have one package per repo?
• If the latter, should a new org be created to accomodate future growth?
• If the former, should this project be renamed to something more general? (or a new project created by the owner the more general goals?)

Very curious!

[c42f]

The new package manager supports multiple packages per git repo in principle, but I've never seen anyone using this feature yet. I suspect it would just make things more difficult to manage as most tooling will assume a single package per repo.

Here's my view of where things should go (coming from a julia programmer, not a lisper):

• A solid standalone package (maybe stdlib) for parsing S-Expressions in various flavors (clojure / racket / ...) + read macros + maybe simple support for a string macro with unquote interpolation. My desire for such a package is to have a nice syntax for writing hierarchical structures which can be used by julia packages in general, and Base in particular. As of now, I'm interested in doing or collaborating on this part and maintaining it.
• Make LispSyntax.jl a pure code generator which lowers S-Expressions into Julia syntax with Julia semantics. For myself, I'm quite happy with julia syntax so I'd probably leave this to someone else. If this is the direction that LispSyntax takes, I'd encourage to make it an explicit goal in the README. I think the current package name is very appropriate for this goal.

Separately from this, one could consider writing a lisp with non-Julia semantics on top of the Julia runtime. Personally I'm not sure this would be worthwhile as it's a lot of work and Julia already seems quite lispy in many ways. But if someone else wants to do it, more power to you :-)