Live data from Hacker News

Hy 1.0 – Lisp dialect for Python

github.com

111–120 of 131 posts

Re: Hy 1.0 – Lisp dialect for Python

#111

Yay! The birth of a language is a beautiful thing. I’m curious about the macros: how are these implemented? They seem like pretty straightforward unhygienic Lisp macros, which is a little bit of a disappointment, but better some macros than none at all! Anything about the macro system that distinguishes it from the Common Lisp system? E.g. anything borrowed from Scheme or Racket? Docs are sparse here.

There's nothing wrong with CL macros.

Quite the opposite, they are more powerful than the alternatives.

Macros are power tools, dumbing them down for safety is missing the point.

Re: Hy 1.0 – Lisp dialect for Python

#112

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?

Compared to other languages, 'lisp syntax' is very minimal. It is just a prefix notation with parenthesis for enclosing expressions, the first item usually being a function. There are only a handful of special forms to learn, which deviate from this.

The real power of lisp IMHO lies in:

  - Repl driven, dynamic development. This is hard to explain. Its like chocolate. You have to try it. You either love it or hate it.

  - Macros. This is again enabled by the 'lisp syntax. Actually lack of it...'. 
Here is an example I recently ran into when checking out Hy

https://github.com/hylang/hy/discussions/2608#discussioncomm...

This shows how much you can abstract, hide the noise without any runtime penalties..

Re: Hy 1.0 – Lisp dialect for Python

#113

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,…

Not sure if this is sarcasm or trolling.

If trolling, it is not very subtle. :-)

Re: Hy 1.0 – Lisp dialect for Python

#114
post #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…

Yeah, at a certain point I realized that both the maintenance and the use of the language became much slicker if unnecessary deviations from Python were minimized. After all, when I'm writing Hy code, I'm usually spending a lot more time referring to the documentation of Python or third-party Python libraries than the documentation of Hy. I felt there were a number of ways Python could be improved upon, but e.g. the old feature that let you spell `True` as `true` in deference to Clojure was just a needless complication.

Re: Hy 1.0 – Lisp dialect for Python

#115
post #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…

Yeah, at a certain point I realized that both the maintenance and the use of the language became much slicker if unnecessary deviations from Python were minimized. After all, when I'm writing Hy code, I'm usually spending a lot more time referring to the documentation of Python or third-party Python libraries than the documentation of Hy. I felt there were a number of ways Python could be improved upon, but e.g. the…

It is true that Hy really shines in those cases where it adopts an existing Python feature and adds meaningful quality-of-life improvements: anonymous functions without limitations; multiple iteration in for-loops; relaxed character set for identifiers. Things that seem completely obvious, once you have them.

It also demonstrates that elegance in a Lisp-on-Python is reached in a very different way than elegance in a stand-alone language, since it becomes an art of making the best out of what is already there.

Re: Hy 1.0 – Lisp dialect for Python

#116
post #79

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

Because we're so used to thinking parenthesis provides an order of evaluation precedence, the fact that 'fn' is within the parenthesis is very confusing. even (fn(x y z)) would have been better. having the function name and it's arguments just next to each other with no syntactic separation is hard to follow. it's like doing arithmetic this way: "add x y z" , is it x+y = z or x=y+z? I'm sure I can get over this hurdle though.

Thanks for suggesting paredit.

Re: Hy 1.0 – Lisp dialect for Python

#117

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?

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

Thanks, I had no idea this was how it transpiled.

Re: Hy 1.0 – Lisp dialect for Python

#118
post #79

Earlier quoted context omitted.

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…

Because we're so used to thinking parenthesis provides an order of evaluation precedence, the fact that 'fn' is within the parenthesis is very confusing. even (fn(x y z)) would have been better. having the function name and it's arguments just next to each other with no syntactic separation is hard to follow. it's like doing arithmetic this way: "add x y z" , is it x+y = z or x=y+z? I'm sure I can get over this hurdl…

I hear you. Try to shift your thinking from statements to expressions, it will make things easier.

The placement of parentheses is not arbitrary. The parentheses enclose expressions, and the nesting of expressions builds a tree. This tree, in effect, is your program's AST. Your C program compiles to something very similar; Lisp just makes it explicit.

"Add x y z" is exactly what it sounds like, if I said those words to you. The add function is usually +, so (+ x y z) is an expression that adds x, y and z, and the whole expression evaluates to the result. You can nest expressions however you like, so, for example, (+ x (* a b)) adds x to the result of the expression (* a b), which evaluates to the result of multiplying a by b.

Values and expressions are effectively interchangeable. Any one of +, x, or y, could be replaced by an arbitrarily complex expression (yes, the function too - you could replace it with a call to a higher order function, which would return a function that is then called over x and y).

The neat thing is, that's basically[0] all the syntax Lisp has. There are no reserved keywords. Everything works as per above, and can be redefined at will. You can change the language's if and else to work any way you want. You can redefine Lisp's reader to change the syntax of the language to absolutely anything you can imagine, and doing so is quite easy, since you're effectively already working at the AST level.

And you can do all of this in a running REPL without even needing to restart it.

If you're interested, check out Common Lisp: A Gentle Introduction to Symbolic Computation by David S. Touretzky.

[0] Macros are the other piece of the puzzle, but to understand them you would need to read up on Lisp more. Once you understand Lisp macros, the advantages of Lisp's syntax become obvious.

Re: Hy 1.0 – Lisp dialect for Python

#119
post #118

Earlier quoted context omitted.

Because we're so used to thinking parenthesis provides an order of evaluation precedence, the fact that 'fn' is within the parenthesis is very confusing. even (fn(x y z)) would have been better. having the function name and it's arguments just next to each other with no syntactic separation is hard to follow. it's like doing arithmetic this way: "add x y z" , is it x+y = z or x=y+z? I'm sure I can get over this hurdl…

I hear you. Try to shift your thinking from statements to expressions, it will make things easier. The placement of parentheses is not arbitrary. The parentheses enclose expressions, and the nesting of expressions builds a tree. This tree, in effect, is your program's AST. Your C program compiles to something very similar; Lisp just makes it explicit. "Add x y z" is exactly what it sounds like, if I said those words…

Wow, thanks very much for the detailed reply. I'm a bit excited and interested to read up on it more. I can only imagine, it must have inspired so many enthusiast level and esoteric languages.

Re: Hy 1.0 – Lisp dialect for Python

#120
post #111

Yay! The birth of a language is a beautiful thing. I’m curious about the macros: how are these implemented? They seem like pretty straightforward unhygienic Lisp macros, which is a little bit of a disappointment, but better some macros than none at all! Anything about the macro system that distinguishes it from the Common Lisp system? E.g. anything borrowed from Scheme or Racket? Docs are sparse here.

There's nothing wrong with CL macros. Quite the opposite, they are more powerful than the alternatives. Macros are power tools, dumbing them down for safety is missing the point.

I have a hard time trusting the CL macros I write because of unexpected interactions with the context that I use them in. While it is the case that CL macros are more powerful than the R6RS macros-by-example system, Racket’s system (and some other newer languages that have adopted things pioneered by Scheme and Racket, such as Elixir) give you hygienic macros without sacrificing expressive power.

I want my macros to be easy to write correctly. That can only happen when the system has proper hygiene.

Post reply on HN