First steps with Hy, the Pythonic Lisp
tech-thoughts-blog.com
tech-thoughts-blog.com
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.
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 :)
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!
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.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/Does it have a tail-call->loop strategy? cpython, like JVM, doesn't have TCO.
http://stackoverflow.com/questions/13591970/does-python-opti...
I'd love ideas on doing TCO, but I don't think it's easily doable with a traditional method of implementing TCO
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.
>>> mycode = "a = int(raw_input()); print a * 2; return a"
>>> myfunc = FunctionType(compile(mycode, "<string>", "exec"), globals())
>>> myfunc()
4
8
4 >>> 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 functionFrankly, 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.