Pixie: A small fast, native lisp
github.com
github.com
That being said I'll try to answer any questions you may have. Thanks!
A great example of this is the (fn [& args]) bit. In Clojure, variadic parameters are passed in as a ISeq. In Pixie they are a vector (or an immutable array actually). This allowed me to tune the JIT quite a bit to allow it to remove the allocation of "args" completely. As well as allow for things like unrolling a reduce over the args. This stuff would have been much harder if the arguments were passed in as an ISeq.
This is the whole reason why Pixie exists, instead of something like "clojure-on-rpython". Compatibility means constraining the feature set. And that's not something I want to do yet.
'Common Lisp' also does not mean it needs the full language. Some applications use subsets.
And, as lispm notes, one can implement a subset of Common Lisp—all that's required is that one define the subset.
I used to be on the fence about multiple namespaces in programming languages. After a decade of programming in Common Lisp and in other languages that pretend to have a single namespace, I see multiple namespaces as a clearly superior approach. I don't think it is a deterrent either - a reason to post complaints on the Internet, yes.
Links to source code or GTFO. The only way people manage to combine DSLs in a single-namespace language is by having stupid naming rules and restrictions (see for example Ruby on Rails). Compare this to something like https://github.com/vsedach/cliki2 where I could just throw arbitrary CL libraries that define their own DSLs together and not worry that my function name is going to clobber some reference in the template system.
Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort.
Of course, macros must have their own namespace, but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway.
How so? And why only two namespaces? Common Lisp probably has a dozen: package name, lexical variable, dynamic variable, function (stores either function or macro function), documentation string, property list, type name, class name, slot name, etc.
As long as you have first-class identifiers, you can define arbitrary namespaces without having to worry about conflicts between the namespaces.
> Of course, macros must have their own namespace
That doesn't have to be true, and is not true in Common Lisp: http://www.lispworks.com/documentation/HyperSpec/Body/03_bba...
Having an identifier denote a function and a macro at the same time like that enables adding partial evaluation and other compile-time optimizations to DSLs without having to dig into the compiler.
> but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway.
? You have to mix them if you want a compiler in your runtime.
It literally compiles the lisp code into python bytecode, which is pretty neat - sort of like clojure is for the JVM.
https://github.com/pixie-lang/pixie/blob/master/pixie/vm/com...
Perhaps not magical, but I like the effort (though lisp-as-shell has to contend with emacs first).
[1]: https://github.com/pixie-lang/pixie/blob/master/pixie/vm/int...
How so ever shiny and neat dynamic typing might be, I have had very little use of it in my own Python code. A situation where I absolutely must store values of different types in the same variable (that or bullet to the head) has not presented itself that often if ever. For me RPython would have been a fine enough replacement, except that I do like generators a lot.
Given the prominence of inversion of control (via coroutines) as a feature, I assume it would have helped pixie implementation too.
So there is nothing "native" about it, and until we see this on http://benchmarksgame.alioth.debian.org/ no basis for calling it "fast."
https://bitbucket.org/pypy/pypy/src/f7bc5ed1602fb522625a3d02...
Assembler.py is the jit assembler.
It also has a Jit engine inside it.
It reminds me a bit of diy-lisp where you implemented Lisp in Python yourself! https://github.com/daGrevis/diy-lisp
https://groups.google.com/forum/#!topic/clojure-py-dev/HbeNE...
Your problem is with Python, not Hy. Hy inherits the "stupid limitations" of Python, and not even all of those - for example, it does away with the statement/expression distinction, which means multiline lambdas (at last!).
It's just Python with s-expressions. If you don't like it, you either don't like Python or don't like s-expressions.
Does it have fully polymorphic other basic functions, like setq, eql (or however they are named)? I guess not? Do you plan on introducing some parts of CLOS?
Lack of OO integration in CL is one of its biggest drawback for me... for me CLOS was the most powerful thing in lisp, not macros (mostly because they are not dynamic).
[0] http://pypy.readthedocs.org/en/latest/coding-guide.html#id1
If you ask me, full Python interop makes Hy the most practical s-expression language today.
Isn't that how all the tiny lisps do it? :)
You know, maybe 'magic' simply sets the bar higher than the project is prepared to support. Consider 'clever'.