From the readme / github page:

> Hy is a Lisp dialect that's embedded in Python. Since Hy transforms its Lisp code into Python abstract syntax tree (AST) objects, you have the whole beautiful world of Python at your fingertips, in Lisp form.

The "embed" part stems from the fact that you can mix Python and Hy in a project with bi-directional calling. Works great, because it is all Python byte code in the end.

> this compiler is written in Python

Yes, that's right. Hy is not self-hosted.

> The various ways you can embed a Lisp look very different and have very different tradeoffs.

Hy itself provides options. Typically the process is that the Hy source code becomes Python AST objects, which Python then complies and executes, but you can also translate the Python AST objects into Python source text. Or you can use Python from Hy or vice versa: https://hylang.org/hy/doc/v1.0.0/interop

The original hy annoucement makes it clear that they embed a Lisp by compiling with Python bytecode. You can see it in the following video about the 16:25 mark

https://m.youtube.com/watch?v=1vui-LupKJI

> I guide the development of Hy as a morally ambiguous iconoclast not totally averse to indefinite nominal executive rule, or "MAINTAINER" for short.

Hehe, clever.

That post deserves its own star rating! Absolutely brilliant.

Thanks. I enjoyed compiling a huge list of buzzwords to use for it.

not a standalone distribution but:

  uvx hy@1.0.0

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

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

(context: uv can install and manage python versions)

https://hylang.org/hy/doc/v1.0.0/repl

>A convenient way to use this class to interactively debug code is to insert the following in the code you want to debug:

    (.run (hy.REPL :locals {#\* (globals) #\* (locals)}))

    import hy; hy.REPL(locals = {\*globals(), \*locals()}).run()

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.

I managed to do 2, sort of, with py2app and judicious hacking. You can compile everything to byte code and use Python "single file" deployment tools.

Code thats written in Lisp is using AST differently. It makes the process of generating machine code much easier. This in turn enables macros which is meta programming not available in non Lisp languages. However on the other hand I tried this avenue and since most modern computing is not Lisp based it severely limits its potential. I'm hoping for a Rust based Clojure or variant. Clojure has the problem its based on the java ecosystem which has severe downsides. A lisp thats based on python doesnt make much sense to me personally python isnt a good language to write other languages in. I think Zig and Rust would be the interesting choices. One attempt: https://github.com/clojure-rs/ClojureRS

See also: https://paulgraham.com/avg.html

I don't think (fn x y z) is all that different to fn(x, y, z). The lack of finicky operator order or other syntax footguns is nice. You're basically looking at the AST as you work. You're one fewer layer of abstraction removed from the logic you are composing.

In real world Lisp, alignment conventions are used that make even a fairly nested function readable at a glance. You'd also generally work using something like paredit, so you're kind of shuffling the S-expressions around like legos. It's not a language that you'd want to write in something like Notepad.

The most important thing about the syntax, though, is that since it's basically the AST, a Lisp macro can effectively manipulate the AST directly and on the fly. This is incredibly powerful, and would be hard to achieve in an Algolian language like Python.

I find non lisp harder.

In blub lang based on c:

Fn(Val Val Val) to f(1,2,3) or

Val fn val 3 + 3

In blub lang based on lisp

(Fn val val...)

I eliminated a lot of whimsy from Hy and its documentation years ago because it was distracting and created noisy test failures, but I did go too far at some point, and have tried to reintroduce a little whimsy more recently.

You're welcome. There are no actual breaking changes from 0.29.0, so you're already up to date if you got that far.

The author of the e-book is a different guy, Mark Watson. He isn't involved in the development of the language.

Strange, the Lisp example has a lot of syntax, even though the article claims it hasn't.

letrec, lambda, or & and are not functions in Scheme.

Yes, such as: metaprogramming via macros and reader macros; arbitrary compile-time computation; removal of restrictions on mixing statements and expressions; and other arities for Python's binary operators. See http://hylang.org/hy/doc/v1.0.0/whyhy#hy-versus-python

Dynamically shadowing global variables is not built-in, but easy to write a macro for if you want it. See e.g. https://stackoverflow.com/a/71618732

Learning Python is not required to get started and do some simple stuff, but it is effectively required to master Hy.

Remarkably enough, yes, we got it to work, on our 3rd or 4th try.

> 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.

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))

Sure - you are piling another transpilation layer on top of already slow Python.

Why not just use something closer to the metal: Common Lisp, Scheme, Clojure, Racket? Especially, use a compiled language, instead of an interpreter.

Lack of self-contained tooling. Idle doesn't work with Hy. You'll probably need to fiddle with Emacs to set your environment first, before being able to do anything beyond playing with the language in the REPL.

Hy-pothetically, yes, you could take Hy code in and spit Python code out via `hy2py`. I think at one point I considered supporting this officially, but then decided there was really no advantage.

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 relationship with JavaScript.

I get the impression that Clojure tries to convince the programmer to avoid side-effects a lot more strenuously than Hy does, but it's still not a purely functional language, so I don't know how consequential that is in practice.

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

It’s far from new. In 2012 I worked for a shop who used an internal package named “hy”, and the introduction of this Hy made our builds break in a novel and interesting way.

(Also, use something to insure your own internal packages have a higher priority, alright? That’s a lesson I didn’t need to learn twice.)

Sparse? I got a whole chapter for ya: https://hylang.org/hy/doc/v1.0.0/macros

I don't think so? https://youtrack.jetbrains.com/issue/PY-48754/Support-for-hy...

I'm not sure. I was going to say that Mojo is proprietary software and so I've never tried it, but I just checked and apparently it's free now. If nothing else, you can probably get a lot of Hy code to run on Mojo via `hy2py`, if Mojo supports a lot of Python as it claims to.

Edit: actually, confusingly, the GitHub repository for Mojo doesn't have an interpreter. The language is still proprietary.

Not sure either, but it should. I do test it every year or so with pypy.