Live data from Hacker News

Hy 1.0 – Lisp dialect for Python

github.com

101–110 of 131 posts

Re: Hy 1.0 – Lisp dialect for Python

#101

Earlier quoted context omitted.

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…

Wouldn't it make more sense then to compile existing languages to a Lisp? From what you said, it sounds like the goal of Lisp making generation of machine code faster/easier? Or is it that forcing programmers to encode there intent into a Lisp removes guessing and optimization overhead for the compiler?

As I understand, that's pretty much exactly how WASM works. It can output either a `.wasm` binary or the same code in a `.wat` text format that looks like this:

    (func (param i64) (result i64)
      local.get 0
      i64.eqz
      if (result i64)
        i64.const 1
    else
      local.get 0
      local.get 0
      i64.const 1
      i64.sub
      call 0
      i64.mul
    end)
https://en.wikipedia.org/wiki/WebAssembly#Code_representatio...

Re: Hy 1.0 – Lisp dialect for Python

#102

I was having some difficulty figuring out how Hy actually is translated to Python (and wasn't even sure if it was compiled or interpreted). Eventually I found on Wikipedia the following: > Hy is a dialect of the Lisp programming language designed to interact with Python by translating s-expressions into Python's abstract syntax tree (AST). Also, looking at the code on Github suggests this compiler is written in Pytho…

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

The actual statement in the video is:

> ...because this is a frontend like LLVM or GCC that compiles instead of bytecode, uh, to Python AST, um, so this Lisp compiles entirely to Python

@ https://youtu.be/1vui-LupKJI?t=1020

Re: Hy 1.0 – Lisp dialect for Python

#104
This reminds me of Berkeley's CS61A when it was taught with Scheme. One of the projects was writing a schema interpreter for scheme. It felt silly, but was a great small project to show case recursion, trees, and blurring the distinct between data and code.

Re: Hy 1.0 – Lisp dialect for Python

#105
post #93

Not a Lisp, but also an interesting take on a functional programming language that transpiles to Python is Coconut ( https://coconut-lang.org/ ). I'd be seriously interested in hearing from people that have actually used any of these two and what their experience was.

I played around with Coconut many years ago and my impression was that the compiler was not smart enough to be useful. The generated code had a big pile of helper functions hardcoded at the top, and the program was much slower than the equivalent plain Python.

By contrast Hy generates Python code that is very close to what you might write by hand, apart from some indirection when it comes to scoping with `let` and some variations around returning values.

Maybe Coconut has improved though, it's been a long time.

Re: Hy 1.0 – Lisp dialect for Python

#106

I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?

Exactly. When certain smug people come about I just humor them. Like, "oh isn't that nice", when I'm really holding my nose internally. Like who dumped a bunch of toenail clippings in your code? When I see Lisp my reaction is like when my dog makes a mess on my carpet. And macros? You get paid to write code. Is it too much to write a few more lines? Python's nice and all, but Algol, that's a rugged person's language, feels very solid. Not like this squishy Lisp. Like how many parens do I have to type?? Please.

Re: Hy 1.0 – Lisp dialect for Python

#107
I would like to make the observation that as Hy matured over the years, instead of accumulating syntactic sugar and special cases to grow more Lispy, less Pythony, it seems to have generally gone the opposite way. That is, becoming a thinner syntactic abstraction of Python's feature set, focusing on the essentials that cannot be emulated in any other way (macros)

A few examples from recent releases:

- "match" is just native Python "match" -- it doesn't even polyfill for pre-3.10 Python versions (in the TypeScript world this would be unthinkable)

- "foo?" used to mangle to "is_foo" as a special case, but this has been removed

- "hy.eval" has been overhauled to be more like Python's "eval"

- nice-to-have but non-essential utilities ("unless") get often pushed out into the Hyrule package

For me this direction was counter-intuitive at first, but it has some very nice outcomes; for one, it simplifies the learning curve when coming over to Hy from Python, and it makes it easier to consistently interact with Python packages (arguably the main reason to use Python in the first place!)

Or maybe it's just a matter of simplyfing maintenance of the language; IIRC, "let" took like 4 attempts to get right :)

In any case, congratulations on this great milestone!

Re: Hy 1.0 – Lisp dialect for Python

#108
post #95
post #89

Earlier quoted context omitted.

> By contrast in a lisp the syntax for setting a variable looks the same as the syntax for looping and for everything else. It's all just function calls. Not really. Setting a variable in Lisp is not a function call. IF is also not a function call. Defining a function is also not a function call. Loop operations like DO, DOLIST, DOTIMES, ... are also not function calls. Lots of things are not function calls. Macro fo…

Yes, my apologies, I should have said "it all looks like function calls".

Depends:

https://github.com/codr7/sharpl

Re: Hy 1.0 – Lisp dialect for Python

#109
post #86

Earlier quoted context omitted.

Wouldn't it make more sense then to compile existing languages to a Lisp? From what you said, it sounds like the goal of Lisp making generation of machine code faster/easier? Or is it that forcing programmers to encode there intent into a Lisp removes guessing and optimization overhead for the compiler?

You can invent another syntax with Lisp/Scheme macros if you want. When compiled or interpreted it will be macro-expanded, and then likely transpiled to an AST and then compiled into byte- or machine code. Take a look at Racket languages for some examples. Lisp syntax with the parens and so on means editing is inherently structural, which makes it relatively easy to reason about and restructure the code. In Python sp…

Read macros, ordinary macro bodies have to follow ordinary syntax rules.

Re: Hy 1.0 – Lisp dialect for Python

#110

I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?

I find lisp horrible for procedural code but fine for functional code for some reason.
Post reply on HN