Try Hy | Hacker News Reader

Try Hy

try-hy.appspot.com

178 pointsproppy64 comments

Open articleView on HN

It's a dialect of LISP that's compiled down to Python AST IICR.

Here's more information: http://docs.hylang.org/en/latest/tutorial.html

Well done! If anyone wants to learn more:

http://hylang.org/

http://github.com/hylang

http://www.youtube.com/watch?v=ulekCWvDFVI

and a quick 5 minute lightning talk:

http://youtu.be/1vui-LupKJI?t=16m13s

(Creator here)

Hack on!

Great work, man.

I did a little presentation on Hy at Pycon Canada earlier this year [1].

Hy has come a ways since then even. Shortly after that talk we added succinct syntax aliases for QUOTE and QUASIQUOTE. And we added a nice clojure-inspired core library.

It's a cool little language. Fun to hack on. You could learn a few things if you do. And I do hope that we can start help creating documentation for the Python AST module via this project.

[1] http://pyvideo.org/video/2328/hy-a-lisp-that-compiles-to-pyt...

A+ for presentation

Indeed; that was fantastic.

A little off on Chrome for Linux, though.

http://i.imgur.com/sC0xuy9.png

Which version? resolution? zoom-level 0?

It seems to depend on the window size. Full-screen 1920x1200 mis-registers it, but experimenting with different window sizes seem to make it shift around.

So it just desugars into Python? I see there is a section in the documentation for macros, but there's nothing there. Does it support AST macros right now? I thought of doing something similar to this except doing some kind of static or gradual typing (that would be a larger project though).

It desugars into python's AST, not python.

I've had similar ideas. I really like the batteries that are included with python but I would like to be able to add type annotations that are enforced to my code base for type safety.

I also really like the idea of being able to extend the language with macros. Hy certainly seems like a good start towards a language like this.

I think the problem with adding even gradual typing to Python is how to handle duck typing. A lot of existing Python code relies on implicit assumptions about the parameters of functions, e.g. "this is an iterable" or "this is a number or supports some numeric operations". I know there are some Python libraries that formalize interfaces like this, but I can't see a good way of doing it nicely in general and being able to calculate the types of everything (with or without explicit annotations). Someone can correct me if I'm wrong but I don't think Scala or Clojure code has this problem.

I hadn't thought about the duck typing issue. What I have in my mind is more akin to contract programming. I'd love to take a look at a library that does this. I just hacked something together during my layover to give it a try.

There is something called "abstract base classes" which provide the sort of interface testing you're asking for. You can, in Python, see if a thing supports (or more precisely claims to support) item access, iteration, sequence behavior, etc.

Original author of hylang here - because lisp is homoiconic, you have real macros, not AST macros; although the distinction isn't exactly clear, it's nice to have them as first-class members of the language, and allow them to avoid caring about stmt vs expr internally.

Happy to answer questions.

I disagree that homoiconicity is required. Racket is not homoiconic and its macros are pretty powerful (Template Haskell is probably a clearer example but is arguably less powerful). What do you lose by not making the syntax homoiconic? Also what is your definition of homoiconicity?

I thought Racket was homoiconic. You can turn executable code into a data structure by quoting it (e.g. (+ 1 2) is executable code, but '(+ 1 2) is a data structure.) Wikipedia thinks Racket is homoiconic FWIW [ http://en.wikipedia.org/wiki/Homoiconic ]

Racket does not use S-Expressions internally, it uses syntax objects which are not really the same. Furthermore it makes no sense to even ascribe one surface syntax to Racket since it's more than one language really. Also if you ask the main developers of Racket if it's homoiconic they would probably tell you that it's irrelevant (and they would be right). In fact I have this in my IRC logs, "<samth> homoiconicity is a meaningless term that tells you nothing about macros"

It's not meaningless, a lot of people (myself included) use it to talk about programs that can alter their own program in the data structures that they're good at moving around.

In Python, the AST approximates this. Perhaps I'm lax in usage, but I think there's a continuum of homoiconicity - some things (like C) have no language functionality to deal with their own source code. Other languages (like CL) are very good at this, since you write the language in it's own data structures. Other languages (like Python, or Racket) aren't homoiconic, but they approximate what makes homoiconicity special.

Are you saying this approximation makes for less powerful macros? If you are, I find that to be ridiculous, as Racket's macro system is way beyond other Lisps' macro systems.

The syntax objects hold more information about scopes, namespaces and the like than they would were they just datum(s?).

Can you clarify what you mean about "real" macros vs AST macros? The only obvious extension to normal AST-style macros I can think of is fexprs, which re-run the macro procedure on every invocation (rather than once at read/build/macroexpansion/whatever time).

Well, two things.

Firstly, AST visitors in Python (or whatever) are clunky and lots of code to do what you say. Hell, I think that it's borderline unpythonic.

You have to consider lots of things, such as whether or not you can put an stmt where you're inserting code, and write a lot of, frankly ugly, Python code to do it.

Hy macros (and really Lisp macros) that are first-class members of the language are nice, because they're a lot more clean to write.

In addition, since Hy does some nasty stuff under the hood to generate clean Python AST, you can do stuff like:

   (print (if true true flase))

(Ok, that's a lie, since it'll do "print True if True else False", but if that had a (do) around everything, it'd still work by mangling the expression - just too tired to write that example right now :) )

Fundamentally, a Hy macro IS an AST macro, just on the parsed and tokenized Hy code (which turns into AST), rather then fiddling with Python AST (which isn't even a stable interface).

That answer the question? :)

Yes. Thanks.

Very nice. Surface syntax (and some semantics like interop) seem to be heavily inspired by Clojure :-)

Hy is neat. I love Lisps that "compile" or are embedable within host scripting languages.

My favourite one to hack on (owing to my PHP ability) is Pharen[0]. Very neat little Lisp that compiles down to PHP, which is very fun to play with. I highly suggest giving Hy a go if you're a Pythonista, as you can learn a lot about programming in general by seeing how these sorts of languages map to the host. Very fun to hack on, too!

[0]: http://scriptor.github.io/pharen/

To quote Dark Helmet, "What the hell am I looking at?"

Not bad. Could be a very useful tool to teach Python programmers Lisp, although I don't think Python benefits much from converting its syntax to sexprs.

If this thing supports macros (and it seems to, see the pipe example in the tutorial), it may be more powerful than Python — as you'd expect from a Lisp.

It supports macros. It's a lisp-1 and they're not hygienic... but you can hack away with them.

and symbols are just strings... that makes writing macros nearly impossible. CL doesn't need hygenic macros since two symbols with the same name from different packages are not the same it's hard to accidentally shadow someone else's definitions.

P.S. The lisp-1 nature of scheme isn't why hygenic macros are important there, it's really a bit of a red-herring, since macros in common-lisp can (and do) use (flet) and (labels)

I wouldn't say it's impossible but one should be aware of the issues. And we can always use more contributors to help make it better.

Hy isn't trying to be CL or Scheme. It is still after all, Python. However a homoiconic front-end to Python has interesting implications for a language like Python. Macros in Hy are almost like a template language for Python ASTs. You could replace the namedtuple implementation with a Hy macro. If Python didn't have a `with` keyword you could implement it as a Hy macro. I'm sure there may be more.

Python's not a lisp under the hood. However it does benefit from some of the superficial features of a homoiconic transpilation. :) </cheeky>

Source: https://github.com/hylang/tryhy

Apparently without TCO :(

    File "<input>", line 1, in fac
    File "<input>", line 1, in fac
    File "<input>", line 1, in fac
    RuntimeError: maximum recursion depth exceeded
    =>

Heh, recognized reverse polish notation right away. One of the companies I interviewed at last year had me program an RPN calculator fed by CSV spreadsheets. Weirdest thing I've made to date by a pretty wide margin.

They had you do that in the interview?

Heh, no. It was as a take home coding project (in my earlier and dumber years, I would never do this now). This was after one business and two technical phone screeners. Then after they reviewed my code, I was brought in for a marathon interview lasting from 9:30AM to 6:30PM on a Friday. I left for a wedding when they started their company wide "pizza and demo night". I imagine after this was done they pulled out cots and handed out stuffed animals and blankies to the bro's. In the end, I was so massively frustrated that I forced myself to nail everything they threw at me just so I could have the satisfaction of turning down their job offer, which I did.

Thanks matchu for the additional info on RPN. I didn't know about the stack evaluation benefit, that is very cool.

"+ 41 1" more closely resembeles straight-up non-reverse Polish notation. Its cool property is that it has unambiguous grouping without parentheses.

Reverse Polish notation's even cooler property is that, in addition to the unambiguity, it can easily be evaluated from left to right with a stack: If you see a operand, push it onto the stack. If you see an operator, pop two operands off the stack, compute, and push the result onto the stack. By the end you'll have a one-element stack with your result.

Really what we're seeing here, though, is a language without infix operators: all functions are of the form "<name> <operand1> <operand2>…", but grouping still works as expected.

http://en.wikipedia.org/wiki/Polish_notation

http://en.wikipedia.org/wiki/Reverse_Polish_notation

Incredible implementation.

It's not that difficult to parse s-expressions and generate code, which is what this does.

For clarity it's generating a python AST which is an object in python. So it's doing a bit more than just raw syntactic sugar.

Yes, pretty cool stuff.

What blew my mind is this actually worked on my iPod Touch and brought up the keyboard. Usually "dynamic" JavaScript keyboards or games totally fail on there..

Excellent. I thought what a LISP on top of the Python runtime would be (like Clojure + JVM), didn't knew this existed already.

"(defun f x (x))" gives a Python stack trace.

(defun f (x) (x))

Yes, I wasn't expecting this wrong syntax to work, just pointing out that the stack trace looks messy (e.g., leaks the absolute path to the involved Python file).

(defun f [x] (x))

Finally my knowledge of Scheme comes in handy!

Love at first sight with the presentation

I think this is fucking amazing.

effin' finally. now to do some serious lisping!

where's cons?

It only has pros.

+ is overloaded (+ '(1 2) '(3)) => '(1 2 3)

https://github.com/danneu/hyclops/blob/master/hyclops.hy#L27...

Some hilariously bad implementations in that file, but it's just for fun.

This could be the next big thing.

Is Python really that awesome?

Yes! It is indeed!

SciPy (http://www.scipy.org/) is really amazing if that's the corner of programming you're into.

[]+1 = [] 1

[]+[] -> error ...

It's using prefix notation, so

  => (+ [] [])
  []

As in Lisp, commas aren't needed to separate list items. []+1 is parsed like [] followed by positive 1 (+1), which is why it ends up executing even though it's infix notation passed into a prefix-notation parser.

WAT. I entered 3 items to input: [] + and 1 - this it is evaluated without error, but was expecting ([] + 1) or something as a result or error. Why there is no error? Why symbol + and a number are evaluated like + was an operator?

The + in +1 is bound tightly to the number like the - in -1. Think of it as meaning "positive," not addition.

Also, Hy's lexing appears to have an interesting feature where you don't always need a space to delimit things, so []+1 is automagically broken up into [] and +1. Here are some other examples where it breaks things up:

  => []"foo"3"hey"["wakka""wakka"]
  []
  u'foo'
  3
  u'hey'
  [u'wakka', u'wakka']
  
  => (+[1][2][3])
  [1, 2, 3]

So without parens, []+1 is like []; +1; in Python and prints out the same result. With parens, the first token of ([]+1) is treated as a function (as would be typical in Lisp) so it tries to execute the Python [](+1), and you get the error that [] isn't callable.

So []+1 ran, but not for the obvious reasons. I'm basically poking at the REPL like you to try and puzzle this out; if you want to dig further, you could look at Hy's docs or source or contact the folks that wrote it.

Edit: an additional detail, not sure if it's informative or just confusing-- "+ 1" is apparently lexed by Hy as two items, not as positive 1:

  => [] + 1
  []
  Traceback (most recent call last):
  File "<input>", line 1, in <module>
  NameError: name '+' is not defined

Reply on news.ycombinator.com