Kodiologist

Joined 4 years ago

Karma
292
Submissions
36
Member since
May 3
http://arfer.net
View on Hacker News

Recent submissions

Comment · 1 year ago
I got it to work again with a user agent from Links: `Links (2.29; Linux 6.11.0-13-generic x86_64; GNU C 13.2; text)`.
Comment · 2 years ago
Admittedly, I've tried not to document the implementation. Yeah, they're pretty much simple dirty Common Lisp macros. Internally, they're functions that are called with the arguments converted to models (via `hy.as-model`), and then the return value is converted to a model. If a macro's first parameter is named `_hy_compiler`, it gets access to the current compiler object; this is undocumented since it's only meant for internal use. Reader macros have no parameters, but can access the current reader object as `&reader`. When it's defined, a reader macro is added to the current reader's dispatch table.
Comment · 2 years ago
Yeah, at a certain point I realized that both the maintenance and the use of the language became much slicker if unnecessary deviations from Python were minimized. After all, when I'm writing Hy code, I'm usually spending a lot more time referring to the documentation of Python or third-party Python libraries than the documentation of Hy. I felt there were a number of ways Python could be improved upon, but e.g. the old feature that let you spell `True` as `true` in deference to Clojure was just a needless complication.
Comment · 2 years ago
You can add all the same type annotations as in Python, but from what I've seen, type-checkers expect Python source text and don't just use standard Python introspection, so you'll need to use `hy2py` first to actually check your program's types.
Comment · 2 years ago
You're welcome. There are no actual breaking changes from 0.29.0, so you're already up to date if you got that far.
Comment · 2 years ago
Comment · 2 years ago
Comment · 2 years ago
Learning Python is not required to get started and do some simple stuff, but it is effectively required to master Hy.
Comment · 2 years ago
Hy-pothetically, yes, you could take Hy code in and spit Python code out via `hy2py`. I think at one point I considered supporting this officially, but then decided there was really no advantage.
Comment · 2 years ago
Now I know how those guys felt who were on the same episode of Ed Sullivan that introduced the Beatles.
Comment · 2 years ago
Comment · 2 years ago
Thanks. I enjoyed compiling a huge list of buzzwords to use for it.
Comment · 2 years ago
I see. That's pretty similar to the feature set of [pdb](https://docs.python.org/3/library/pdb.html). You may then logically ask "Does Hy support pdb?". The answer is "sort of". I've fixed one or two bugs, but we don't test it. I suspect there are various features of pdb that assume Python syntax and would need some hooks to get working properly with Hy.
Comment · 2 years ago
1. I don't know what a breakloop is. Hy uses Python's exception system, which is more like a traditional exception system than Common Lisp's condition system.

2. No, sorry.

Comment · 2 years ago
> Are there Python language features I can't use in Hy?

At the semantic level, no. I work to cover 100% of Python AST node types with Hy's core macros. It does take me a little bit to implement a new core macro after the CPython guys implement a new feature, but you can always use the `py` or `pys` macros to embed the Python you need, should it come to that.

> Or performance penalties in using Hy?

Compiling Hy (that is, translating it to Python AST) can be slow for large programs (I've seen it top out at about 3 seconds), but at runtime you shouldn't see a difference. Hy always produces bytecode, which can be used to skip the compilation step if the code is unchanged.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton