I saw Hy pop up a week or so ago and I've decided to give it a serious spin since I've always wanted to learn a Lisp but never wanted to learn a whole new eco-system.

It's been phenomenal so far and I want to finish my comment the same way the author finishes his blog post:

> It stands on the shoulders of a giant (Python) and balances another giant (Lisp) on top of this. Better is better, guys. pip install hy.

Don't take it bad, but here is my attempt in creating a new "Lisp dialect" compiling into BASIC:

  (main
    (linenumber 10 (print "hello world"))
    (linenumber 20 (print "Hey!"))
    (goto 10))

More seriously, is Hy anything more than writing Python with some parentheses there and there?

Coding in Lisp has nothing to do with putting parentheses everywhere but rather with thinking in some specific way. For instance, I know that I am ready to code something in Lisp when I see my whole task as a sequence of CONS, but how could Hy truly implement such a thing as long as it relies on Python lists?

I played with it a bit, it's homoiconic, has macros, and papers over the difference between Python statements and expressions (so that everything is expressions).

Seems pretty neat, if you ask me.

Does Hy add its own "symbol" datatype, or use something in the standard library?

Own symbol type

    => 'foo
    HySymbol(u'foo')

Assignment and conditionals are expressions, however assignment returns None.

    => (setv bar (setv foo (if True True False)))
    => (type bar)
    <type 'NoneType'>

Quoted expressions evaluate to Hy AST.

    => '(+ 1 2 3)
    HyExpression([
        HySymbol(u'+'),
        HyInteger(1L),
        HyInteger(2L),
        HyInteger(3L)]
    )

So it's kind of a frontend for the Python compiler, it goes:

Hy AST -> Python AST -> Python bytecode

Users of Hy who don't know Lisp deserve to be informed that in an actual Lisp, it goes more like this:

  => 'foo
  foo

(or, at worst FOO rather than foo).

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

Your example looks great! Now i want

  (defmacro print-loop (line-start line-inc strings)
    (let ((i line-start))
    `(main
      ,(mapcar (lambda (x) `(linenumber ,(setq line-start (+ line-start line-inc)) (print ,x))) strings)
      (goto line-start))))

That's sort of the point. It's "just Python". It's s-expression syntax for Python.

Why would one want such a thing? Well, s-expressions confer many advantages (and of course, some disadvantages - it's good to have a choice!)

- It makes it easy to write code that writes code, which is useful because it affords "compile-time" abstractions with no runtime performance penalty (in lisp terms, "macros").

- If you're comfortable with a structure editor, it enormously lowers the friction involved in refactoring.

- It allows everything to be an expression:

  json.loads(with f as open("file.json"): f.read()) #doesn't work
  (json.loads (with [f (open "file.json")] (f.read))) ;works

- It effectively removes all restrictions based around things fitting on a single line - lambdas are the canonical example.

Or in actual Lisp:

    (tagbody
      10 (print "hello world")
      20 (print "Hey!")
         (go 10))

In many cases Python generators are better than lists: https://wiki.python.org/moin/Generators

E.g. consider xrange() vs (Python 2) range().

The only real advantage I saw in the article is the addition of macros

Needs relative line numbering from vim.

This is a humor article, right?

(Hell is debugging someone else's LISP macros. I have a very old LISP program, a theorem prover, I've tried to convert from Franz LISP, a Maclisp dialect, to Common LISP. I worked on it years ago. I just can't fix some of the bugs. The original authors of the part that doesn't work right are long dead.)

    def prepare_target(y):
        if hasattr(y, "values")
            return target.values.reshape(-1,1)
        else:
            return target.reshape(-1,1)

Shouldn't that be

    def prepare_target(y):
        if hasattr(y, "values")
            return y.values.reshape(-1,1)
        else:
            return y.reshape(-1,1)

I went down this path until I tried to run pdb or profilers on mixed language stuff, result was not great.

Python is already fairly OK, use decorators instead of def macro, metaclasses if you need to get into head-scratching territory etc. Use the 4 argument form of the type function, belabor __new__ etc it will still be readable instead of a pile of nail clippings

I think I'd rather work with macros than metaclass magic.

I've used both, and a big difference is that the normal Python tools work for metaclasses, but I'm not sure if you can do step through debugging of a macro?

Hy is what got me into lisp dialects and parted the clouds on the bliss of simplicity of the syntax and made me see that I had been living like a savage with C-style languages and OO slavery.

Give it a try! It is really fun and significantly lowers the barrier off entry to the land of lisp!

Is there a guide/overview/doc/tutorial/whatever of how Hy is implemented?

I'm curious how hy modules can be imported in python directly.

Python has API that allows you to replace parts of import system with arbitrary Python code.

If you are talking about the import hooks, I think those require the imported file to have valid python syntax. The import hooks work on the python AST (I think)

I think you are correct, they monkey-patched importlib

https://github.com/hylang/hy/blob/master/hy/importer.py#L132

As I recall, patching was simply the most expedient approach. Otherwise, for the changes we needed to make, we would've had to copy a lot of source from the standard loader implementation in CPython for only a few simple changes.

https://github.com/hylang/hy/pull/1672

Can you distribute packages with hy?

Yep. Check out the GitHub list: https://github.com/hylang/hy/network/dependents?dependent_ty...

the original was published on https://0bin.net/paste/xmJWIlIv+Ws+Fbjs#zCyc4Yc4T+YISv3MHwMT...

Thank you paultag