gilch
gilch
https://github.com/woodrush/py2hy I don't think it's up to date though. See #876.
I thought #920 was supposed to fix this, but it seems to be broken again. After that PR, we had ```Python => (if 1 1 (if 2 (setv x 2)...
That doesn't seem right. The equivalent `cond` has also regressed: ```Python => (cond [1 1] [2 (setv x 2)] [3 3]) if 1: _hy_anon_var_2 = 1 else: if 2: x...
Special-casing a macro name seems bad. It might be better to move `if` into the compiler. But then, how did `cond` work before? Maybe we could re-implement `cond` in terms...
Or maybe we could rewrite the `if` macro to be non-recursive. That might be easier. But then what if the user wanted to implement his own branching macro based on...
Python also has an embeddable repl in the standard library, and not just the debugger. It's in the `code` module. The easiest way to start it up is with `code.interact()`....
Here's a candidate `apply` macro. ```Hy (defmacro apply [expr args &optional [kwargs {}]] `(~@(if (isinstance expr HyExpression) expr [expr]) #* ~args #** ~kwargs)) ``` Python's distinction between args and kwargs...
> Maybe the solution is a another [`apply`] version with different ordering. On second thought, you can use a `->>` anywhere in a `->` to thread in the tail for...
I just realized that the `as->` macro works even without `apply`. ```Hy => (-> (range 10) iter , (* 2) (as-> it (zip #* it)) list) ``` ```Python it =...
> a new HyModel type ... the compiler's job to join Exactly what I was thinking.