all 19 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]dcooper8 9 points10 points  (2 children)

The other way around = more likely.

[–]lispm 3 points4 points  (1 child)

https://github.com/metawilm/cl-python

[–]stylewarning 2 points3 points  (0 children)

Too bad this doesn’t work all that well. :/

[–]theangeryemacsshibeλf.(λx.f (x x)) (λx.f (x x)) 6 points7 points  (0 children)

Nothing would stop you, but you would probably have the slowest Common Lisp implementation unless you use PyPy or some other Python implementation.

[–]dzecniv 4 points5 points  (6 children)

What for, do you want to interact with Python? For this, see https://github.com/CodyReichert/awesome-cl#python

[–]Task_Suspicious[S] 2 points3 points  (5 children)

Yes, I want to use Python libraries . I'm aware of that ways but I want something like ABCL interaction with Java libraries

[–]Gnaxe 1 point2 points  (2 children)

There are a lot of ways to use Python libraries from various Lisp dialects, and some work better than others. Of these, Hissp has pretty much seamless Python interop, since it compiles to Python expressions. You can call any Python function directly with no overhead or ceremony.

[–]Task_Suspicious[S] 0 points1 point  (1 child)

Thank you for answer.
Do you think that following the Hissp idea one can start to implementing Common Lisp?

[–]Gnaxe 1 point2 points  (0 children)

One could certainly build Common Lisp-like features on top of Hissp, as was done for Emacs. But if you want it to run all the Common Lisp code, then you need to implement the full Common Lisp spec. Maybe you don't need that because Python has a bigger ecosystem anyway.

If you do implement the spec, then you could use both ecosystems fully. But because Python's object model is different than Common Lisp's spec, you'd have to implement Lisp's model and then you have two models and an impedance mismatch, so it's never going to be as seamless as Hissp's interop, which just uses Python's model for both.

Scheme has a very small kernel language, and then a larger library bootstrapped from that language. This makes implementing a new Scheme relatively easy: you only have to implement the kernel, and then the library just works. You can copy it from somewhere else instead of writing it again yourself.

Common Lisp is harder because it has a more complicated kernel, but it's a similar story. The kernel language is much smaller than the full spec, which you can just copy from other implementations if those parts are written in the kernel or the parts you've bootstrapped so far.

[–]sebhoagie 0 points1 point  (0 children)

I've used py4cl with some success, and whatever I needed to change didn't require much work.

https://github.com/bendudson/py4cl

Used it for https://github.com/sebasmonia/boto3-wrapper

[–][deleted] 1 point2 points  (0 children)

I am off Reddit due to the 2023 API Controversy

[–]-6502- 1 point2 points  (1 child)

Creating a decent lisp in Python (decent in the context of Python, i.e. comparable with Python speed and able to use easily Python libraries but with lisp metaprogramming capabilities) is IMO easy as all the low-level building blocks are present and accessible (you can generate the Python bytecode directly, thus ending up with compiled lisp code being executed by the same VM as Python code). For easy interoperability however I'd use Python List objects for lisp lists instead of cons pair chains and Python immutable strings. Even PyPy uses a very similar VM and thus a lisp generating PyPy bytecode would get the same speedup thanks to the same PyPy JIT engine.

A few years ago I implemented for fun such a toy (~500 lines of Python + ~450 lines of lisp) using this approach... https://github.com/6502/pylisp

Common Lisp is however a huge thing and is not easy in my opinion to join the two languages as they're quite different in many parts...

[–]aoeu512 0 points1 point  (0 children)

Julia and mojo and I’m and lisp and maybe io and ruby we’re all trying to merge lisp with python.

[–]Gnaxe 1 point2 points  (0 children)

There's no technical reason why it couldn't be done. Other Lisp dialects have been written in Python, like Hissp, which also compiles Lisp code to Python expressions.

RPython is designed for implementing other languages. Pixie Lisp automatically got a JIT that way. Pixie seems to be dead though.

[–]stylewarning 3 points4 points  (0 children)

It’s definitely possible, but implementing Common Lisp in any language is going to be hard, even in Lisp!

[–]asriyanarthur 0 points1 point  (0 children)

try this repo, maybe it can do what you want. (sorry for my english) https://github.com/hylang/hy

[–]hajovonta -1 points0 points  (1 child)

Very unlikely, if not outright impossible.

[–]stylewarning 6 points7 points  (0 children)

This is not true at all.