Hacker News new | past | comments | ask | show | jobs | submit login

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

    (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
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)
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
(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))
      ,(mapcar (lambda (x) `(linenumber ,(setq line-start (+ line-start line-inc)) (print ,x))) strings)
      (goto line-start))))

Or in actual Lisp:

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

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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact