Try Hy(try-hy.appspot.com)

178 pointsby proppyvor 13 Jahren64 comments

try-hy.appspot.com

http://try-hy.appspot.com/

26 comments

ninetaxvor 13 Jahren

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

paultagvor 13 Jahren

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!

kro0ubvor 13 Jahren

Great work, man.

agentultravor 13 Jahren

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

mkramlichvor 13 Jahren

A+ for presentation

ceauteryvor 13 Jahren

Indeed; that was fantastic.

danellisvor 13 Jahren

A little off on Chrome for Linux, though.

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

recursivevor 13 Jahren

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.

proppyvor 13 Jahren

Which version? resolution? zoom-level 0?

anaphorvor 13 Jahren

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

paultagvor 13 Jahren

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.

leifafflesvor 13 Jahren

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

paultagvor 13 Jahren

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

leifafflesvor 13 Jahren

Yes. Thanks.

anaphorvor 13 Jahren

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?

derp_doggvor 13 Jahren

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 ]

anaphorvor 13 Jahren

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"

paultagvor 13 Jahren

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.

59nadirvor 13 Jahren

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

Foxboronvor 13 Jahren

It desugars into python's AST, not python.

haneyvor 13 Jahren

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.

anaphorvor 13 Jahren

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.

toxikvor 13 Jahren

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.

haneyvor 13 Jahren

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.

zaph0dvor 13 Jahren

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

girvovor 13 Jahren

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/

dmoneyvor 13 Jahren

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

vezzy-fnordvor 13 Jahren

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.

nine_kvor 13 Jahren

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.

agentultravor 13 Jahren

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

aidenn0vor 13 Jahren

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)

agentultravor 13 Jahren

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>

nlake44vor 13 Jahren

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

andrelaszlovor 13 Jahren

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

mattholtomvor 13 Jahren

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.

matchuvor 13 Jahren

"+ 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

sockgrantvor 13 Jahren

They had you do that in the interview?

mattholtomvor 13 Jahren

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.

jackhammonsvor 13 Jahren

Incredible implementation.

anaphorvor 13 Jahren

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

haneyvor 13 Jahren

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.

rhizome31vor 13 Jahren

Yes, pretty cool stuff.

petercoopervor 13 Jahren

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

hcarvalhoalvesvor 13 Jahren

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

a3_nmvor 13 Jahren

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

dagurpvor 13 Jahren

(defun f [x] (x))

chrismonsantovor 13 Jahren

(defun f (x) (x))

a3_nmvor 13 Jahren

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

Sunlisvor 13 Jahren

Finally my knowledge of Scheme comes in handy!

tallesvor 13 Jahren

Love at first sight with the presentation

d0mvor 13 Jahren

I think this is fucking amazing.

[deleted]vor 13 Jahren

basytvor 13 Jahren

effin' finally. now to do some serious lisping!

derp_doggvor 13 Jahren

where's cons?

danneuvor 13 Jahren

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

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

skrebbelvor 13 Jahren

It only has pros.

derp_doggvor 13 Jahren

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

nick2021vor 13 Jahren

jbejavor 13 Jahren

This could be the next big thing.

jbejavor 13 Jahren

Is Python really that awesome?

stoliovor 13 Jahren

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

Foxboronvor 13 Jahren

Yes! It is indeed!

ravestarvor 13 Jahren

[]+1 = [] 1

[]+[] -> error ...

twotwotwovor 13 Jahren

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.

ravestarvor 13 Jahren

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?

twotwotwovor 13 Jahren

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