Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hy 1.0 – Lisp dialect for Python

github.com

Post reply on HN
Print view View original

31–40 of 131 posts

Re: Hy 1.0 – Lisp dialect for Python

#31

Post by tosh »

HexDecOctBin wrote: post #20

Congrats! Two questions: 1. Does it support REPL-driven development? (condition system, breakloop, etc.) 2. Is there a standalone distribution? Distributing python in itself is a hassle, ideal situation would be to simply distribute a single Hy binary that contains all dependencies within it (either statically linked or as a zip file extracted in tmp directory).

not a standalone distribution but:

  uvx hy@1.0.0
gets you into the Hy REPL

  echo '(print "hi hn")' > hi.hy
  uvx hy@1.0.0 hi.hy
prints "hi hn"

https://docs.astral.sh/uv/guides/tools/#running-tools

(context: uv can install and manage python versions)

Re: Hy 1.0 – Lisp dialect for Python

#32

Post by Kodiologist »

BeetleB wrote: post #28

Any downsides to using Hy (over Python)? Other than my coworkers don't know Lisp? More concrete: Are there Python language features I can't use in Hy? Or performance penalties in using Hy?

> Are there Python language features I can't use in Hy?

At the semantic level, no. I work to cover 100% of Python AST node types with Hy's core macros. It does take me a little bit to implement a new core macro after the CPython guys implement a new feature, but you can always use the `py` or `pys` macros to embed the Python you need, should it come to that.

> Or performance penalties in using Hy?

Compiling Hy (that is, translating it to Python AST) can be slow for large programs (I've seen it top out at about 3 seconds), but at runtime you shouldn't see a difference. Hy always produces bytecode, which can be used to skip the compilation step if the code is unchanged.

Re: Hy 1.0 – Lisp dialect for Python

#33

Post by rcarmo »

BeetleB wrote: post #28

Any downsides to using Hy (over Python)? Other than my coworkers don't know Lisp? More concrete: Are there Python language features I can't use in Hy? Or performance penalties in using Hy?

You take a little performance hit upon initial startup (from a clean filesystem, while __pycache__ folders are created). Other than that, mostly everything is the same.

I'm now figuring out how to pack images to OpenAI REST calls (using my own REST wrapper), and everything is peachy. Here's my test snippet (mostly to b64encode the file):

    (import aiohttp [ClientSession]
            base64  [b64encode]
            asyncio [run])

    (defn :async pack-image [filename]
      (with [h (open filename "rb")]
        {
          "type" "image_url"
          "image_url" { "url" f"data:image/jpeg;base64,{(.decode (b64encode (.read h)) "utf-8")}" }
        }))

    (defn :async main[]
      (print (await (pack-image "request.hy"))))

    (run (main))
This shows you async, context managers, selective imports, f-strings... etc. All that you need, really.

Re: Hy 1.0 – Lisp dialect for Python

#34

Post by Kodiologist »

HexDecOctBin wrote: post #20

Congrats! Two questions: 1. Does it support REPL-driven development? (condition system, breakloop, etc.) 2. Is there a standalone distribution? Distributing python in itself is a hassle, ideal situation would be to simply distribute a single Hy binary that contains all dependencies within it (either statically linked or as a zip file extracted in tmp directory).

1. I don't know what a breakloop is. Hy uses Python's exception system, which is more like a traditional exception system than Common Lisp's condition system.

2. No, sorry.

Re: Hy 1.0 – Lisp dialect for Python

#36

Post by wrs »

Kodiologist wrote: post #34
HexDecOctBin wrote: post #20

Congrats! Two questions: 1. Does it support REPL-driven development? (condition system, breakloop, etc.) 2. Is there a standalone distribution? Distributing python in itself is a hassle, ideal situation would be to simply distribute a single Hy binary that contains all dependencies within it (either statically linked or as a zip file extracted in tmp directory).

1. I don't know what a breakloop is. Hy uses Python's exception system, which is more like a traditional exception system than Common Lisp's condition system. 2. No, sorry.

A breakloop is a REPL operating in the context of condition handling. When a condition is signaled, you can use the breakloop to modify state and direct how the condition should be handled (including fixing something local and letting the current function proceed by ignoring the condition).

Seems like that would only be doable by altering CPython to at least have a hook in the initial exception processing (or maybe there is some magic double-underscore thing for that already?).

Re: Hy 1.0 – Lisp dialect for Python

#38

Post by chrisrink10 »

anovick wrote: post #29
chrisrink10 wrote: post #18

Earlier quoted context omitted.

I haven't used Hy, but I am the maintainer of a Basilisp which also compiles to Python and aims for reasonably close compatibility with Clojure if you're interested. https://github.com/basilisp-lang/basilisp

Cool project! Wondering how custom immutable data structures fit in with the Python ecosystem. Particularly, I know that NumPy arrays and Pandas Series/DataFrames are the popular data structures used in research computing in Python (for Statistics, Data Science, Machine Learning etc.). These data structures afaik are mutable, however (for performance reasons), so at least the aspect of immutability from Clojure canno…

This project is much younger and used by many fewer people than Hy, so I couldn't really speak to this besides my own opinions. The few who have started using it and contributing seem to just be using it as a way to write Clojure while interacting with popular Python libraries and tools. Kind of the same way that interacting with the Java ecosystem is often more pleasant from Clojure (IMO) than in Java itself.

I've tried to facilitate strong Python interoperability despite the variety of otherwise incompatible features of each language. It's trivial to work with immutable data structures using Clojure idioms and then convert them to Python data structures (as needed) at the boundaries, but the immutable data structures used by Basilisp are also generally compatible with Python's core (read-only) interfaces so that conversion may also not be necessary if you aren't expecting the called function to perform any mutations.

Re: Hy 1.0 – Lisp dialect for Python

#39

Post by a57721 »

Kodiologist wrote: post #9
anovick wrote: post #7

Congrats! Could you compare the language with Clojure?

Well, this is a little embarrassing: Clojure was one of the biggest influences on Hy in its youth, but that was mostly before I got involved in 2016. I never actually learned Clojure. So hopefully somebody who knows both Hy and Clojure well can answer. I can tell you that at run-time, Hy is essentially Python code, so Hy is more tightly coupled to Python than Clojure is to Java; a better analogy is CoffeeScript's rel…

Clojure has a good collection library with immutable/persistent data structures, but as a language it allows side effects and has some mechanisms to manage them. It is also possible to call any Java method from Clojure.

Clojure does not work with Java ASTs, it translates into JVM bytecode directly.

Post reply on HN