https://github.com/halgari/clojure-py
Clojure-Py is an implementation of Clojure running atop the Python VM.
As it currently stands, we have translated over 235 functions from
clojure.core. This is not a clojure interpreter in python; the
Clojure-Py compiler compiles clojure code directly to python code.
Clojure-py functions are python functions. Clojure-py types are python
types, Clojure-py name spaces are python modules.
Please feel free to browse the examples at
https://github.com/halgari/clojure-py/tree/master/examples to get an
idea of what Clojure-Py can currently accomplish.
Version 0.1.0 should be considered "alpha" and "proof of concept".
That being said, if you stick to the afore mentioned 235 functions,
and python interop, the implementation is very usable and so far quite
stable.
The package is released via the Python Package index so you can simply type
easy_install clojure-py
clojurepy
To install and startup the repl. Python 2.6, 2.7 and PyPy are all
supported. Please check out this release and send us your feedback via
Github.
---
Upcoming in version 0.2.0:
Support for bindings
defprotocol and defmulti
defrecord
full support for pr-str
---
Thank you for all the interest we've received from the Clojure and
Python communities. We look forward to seeing this project grow.
Timothy Baldridge (halgari)
> The Clojure-Py team is happy to announce the release of Clojure-Py 0.1.0.
>
> https://github.com/halgari/clojure-py
This looks really nice already. Keep up the good work!
For me, this could be the solution to the main problem I have with
Clojure: the JVM. Most of my legacy code is in Python and most of the
important libraries in my domain are in C or Fortran and have Python
interfaces.
Konrad.
I've seen this once before, in Linux, I'll open a bug for it and see
if we can get it ironed out.
Timothy
python setup.py install
it seems to work just fine. But I'll look into this issue as well.
Timothy
2012/3/8 Daniel Janus <nat...@gmail.com>:
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
"One of the main causes of the fall of the Roman Empire was
that-lacking zero-they had no way to indicate successful termination
of their C programs."
(Robert Firth)
What startup time performance improvements do you see for eg using
this platform for shell scripts-like stuff ?
> What startup time performance improvements do you see for eg using
> this platform for shell scripts-like stuff ?
Currently, it's about 3sec on my machine. This is because we're
parsing/compiling all 2600 lines of core.clj on every start-up. One of
my tasks this week is to compile the file to bytecode, then serialize
this bytecode as a .cljc file. This is the method the rest of python
uses, and at that point we should have almost instant start-up times.
Timothy
--
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
Looks interesting :)
What's the plan for ratios and characters? I assume they're still on
the TODO list? (Maybe Issue 17 covers the ratios?)
e.g.:
$ python clojure.py
clojure-py 0.1.0
user=> \a
Compiling \a
Traceback (most recent call last):
[...]
CompilerException: Compiler Exception could not resolve '\a', '\a' not
found in user reference fn_787
user=> (/ 22 7)
3
user=> 22/7
Traceback (most recent call last):
[...]
clojure.lang.cljexceptions.ReaderException: Invalid number: 22/7
$
--
Michael Wood <esio...@gmail.com>
Yeah, I need to run a few more tests, but I'm thinking of somehow
layering libgmp ontop of Python in order to implement ratios.
The lispreader needs to be fixed to handle characters. I'll create a
bug report for that. Thanks!
Timothy
Timothy
> What's the plan for ratios and characters? I assume they're still onYeah, I need to run a few more tests, but I'm thinking of somehow
> the TODO list? (Maybe Issue 17 covers the ratios?)
layering libgmp ontop of Python in order to implement ratios.
Actually Python fractions would work perfectly. And the decimal class
in Python should be included as well.
Thanks for pointing these libraries out to me!
Timothy
Actually Python fractions would work perfectly. And the decimal class
in Python should be included as well.
Thanks for pointing these libraries out to me!
Timothy
The Clojure-Py team is happy to announce the release of Clojure-Py 0.1.0.
https://github.com/halgari/clojure-py
Clojure-Py is an implementation of Clojure running atop the Python VM.
As it currently stands, we have translated over 235 functions from
clojure.core. This is not a clojure interpreter in python; the
Clojure-Py compiler compiles clojure code directly to python code.
Clojure-py functions are python functions. Clojure-py types are python
types, Clojure-py name spaces are python modules
Well that's the one part where Clojure and Python diverge. Clojure-py
does not use Python's generators. This is because Python's generators
are mutable. So that actually wont' be a problem.
What is a problem though, is the way Clojure-py currently accesses
vars. Consider the following:
(+ 1 2)
In Clojure-py we'd compile this as
LOAD_CONST #user/+
LOAD_ATTR deref
CALL_FUNCTION 0
LOAD_CONST 1
LOAD_CONST 2
CALL_FUNCTION 2
It's this first line that causes the RPython translator to blow up.
Calling LOAD_CONST and supplying a complex type like VAR is more than
it can handle. Now it just so happens this is completely acceptable in
normal Python code, so that's where the issue is.
My plan is to abstract this a bit. I plan on providing global vars
that allow the user to specify how the current code is bound. For
instance, if #user/+ is a static var, there's no reason to deref it
every single time, since it will never change. However, dynamic vars
need to be deref'ed, and RPython vars need to use pure LOAD_GLOBAL,
LOAD_ATTR calls. The plan then is to provide the Clojure-py backend
with a simple (deref this var) object that will allow the compiler to
on-the-fly decide how certain pieces of code are called.
It just so happens that once this is implemented, it will also allow
us to serialize clojure code using CPickle. This should allow us to
drop the startup times of Clojure-py down into the <1sec range.
And actually, being able to run Clojure code on RPython is a personal
goal for me. It's probably one of the biggest motivations for me to
actually start this project. So as I find time, I do plan on exploring
this, and building up a good macro/function library to allow users to
experiment with RPython a bit more easily.
Timothy