So Hy has different forms used than either Common Lisp, Scheme, or Clojure?

That just makes me frustrated. I know Lisp is the urlang from which all dynamic languages come from, I know that it's mutable into your personal tastes, but can we please standardize on a previously used set of forms? I respect and encourage people's desires to make a toylang, but if you want to promote it into "language for other people", things like portability become more important. I'm a common lisp guy, so obviously those are the best. ;-) But more importantly, I can run Common Lisp from before I was born. And I love that longjevity of my code and other people's code.

http://docs.hylang.org/en/latest/

This started out as a joke for PyCon / teaching folks how to use Python AST, and it's grown to be kinda useful for a few things -- Macros aren't there yet, and the language is immature / special-snowflake about some things, but it's generally saneish.

Since we do target Python AST we don't control the runtime (at all), since hy stored as a .pyc (or even use pdb to debug lisp in Python, wat) it's really (really) hard to build up a traditional lisp.

C'mon over and hack with us!

Ah, thanks for the history. That provides context. I am afraid my contributions would be to provide rewrites and so forth to attempt to adhere to a subset of Common Lisp.

If he had just implemented a toy Scheme which adheres to R4RS or R%RS, then he could have leveraged the work of many people working on small Lisps.

We don't have control of the runtime - the runtime is actually just Python -- in fact, a generated Hy .pyc can run on a system without Hy installed on it - so keeping it compliant to anything would just be insane.

We're also taking from Python's work - working with MongoDB or using requests + clint to write a 2 minute API wrapper is like 5 lines of code in hy :)

The readability of Scheme and the speed of Python?

I'll have you know this will now become one of the official Hy mottos

Interesting to see Clojure's syntax of using vectors ( '[]' ) in some places where previous LISPs have used lists being adopted here, at least for defn.

Author also uses defn instead of defun, he's probably a Clojure...Ista? Clojurer?

Clojurians were sometimes used too.

I've heard Clojurist the most, but I'm not sure if that's the official demonym.

I like "Clojurer" 'cuz it reminds me of "conjurer"

Chosen for Clojury duty.

That's right, I sure am :)

> As far as I know, the only way to access elements of the dictionary is through functions. I fear these methods are deprecated in future versions in favor of the square brackets [] notation.

I presume ``(.__getitem__ obj key)`` would work, or at least ``(obj.__getitem__ key)``.

``dict.get(key)`` is not deprecated. It's quite different to ``obj[key]`` (i.e. ``dict.__get__(obj, key)``) and is very useful:

    >>> help(dict.get)
    Help on method_descriptor:

    get(...)
        D.get(k[,d]) -> D[k] if k in D, else d.  d defaults to None.

In case anyone wants to learn more:

Repo:

    https://github.com/hylang/hy (star it, fork it)

Lightning Talk from PyCon:

    http://blog.pault.ag/day/2013/04/02

Hour long Boston Python talk:

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

  Slides:

    http://hy.slides.pault.ag/#/step-1

Docs (needs work, PRs welcome):

    http://docs.hylang.org/en/latest/

Why not just Clojure?

Does it have a tail-call->loop strategy? cpython, like JVM, doesn't have TCO.

http://stackoverflow.com/questions/13591970/does-python-opti...

Hey there, hy author here - the issue is TCO requires (basically) a GOTO like command, the Python AST doesn't have this -- which is depressing, yes.

I'd love ideas on doing TCO, but I don't think it's easily doable with a traditional method of implementing TCO

I wrote something similar to hy once before but never finished--was called ruse. I solved the TCO problem with trampolines.

I'll admit this excites me a little. I'll definitely be having a play.

defn nested in defn seems totally wrong from a LISP (or Clojure) viewpoint. Isn't there a let or letfn? (Please note that I have no idea of Python)

It's not from a Scheme viewpoint, and specifically SICP, which is where he's starting from.

Frankly, I'd prefer if it were idiomatic to locally defn inside Clojure defns, letfn is not hardly so elegant or clear. One of a number of areas where I find Clojure needlessly less tasteful and elegant than Scheme, but all are at least tolerable.

in Python one function definition inside another is totally normal, and (to my knowledge) the statement doesn't generate a global binding, so that the inner-defined function is not accessible from outside the outer one. In other words, python's def appears to be syntactic sugar for variable assignment within whatever scope you're already in, except of course that there is no nonsugared form. Which would make it analogous to let, I believe.

Technically, in Python nothing prevents you from writing something like:

    foo = lambda x: x*2 

If only that lambda statements are limited (by design?) to only a single return expression.

As far as Hy goes, lambdas won't have this limitation.

I totally write code like this all the time, when I need a quick one-liner that I don't really care about. A little more then a technicality.

Totally. Hy will even auto-expand a lambda to a function if it's not sane Pythonically :)

In a way, there is:

  >>> mycode = "a = int(raw_input()); print a * 2; return a"
  >>> myfunc = FunctionType(compile(mycode, "<string>", "exec"), globals())
  >>> myfunc()
  4
  8
  4

This SyntaxErrors for me.

    >>> from types import *
    >>> mycode = "a = int(raw_input()); print a * 2; return a"
    >>> myfunc = FunctionType(compile(mycode,"<string>","exec"), globals())
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<string>", line 1
    SyntaxError: 'return' outside function
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<string>", line 1
    SyntaxError: 'return' outside function