-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updates for compatibility with recent Hy changes #9
Updates for compatibility with recent Hy changes #9
Conversation
…hanges. XXX: There appear to be breaking changes in how reader/tags are used in this library and parsed/lexed by Hy. Essentially, tags can't take empty arguments: e.g. `(blah #s)` fails (apparently because `)` is taken as an argument to `#s`), but `(blah #s None)` doesn't.
Regrettably, all iterators returned by `rest` are explicitly evaluated as lists. This was done to work around Hy issues involving `islice` in macros, and it needs to re-assessed. Also, now that there are no built-in cons cells, all the logic that used them needs to be reworked. This commit only makes minor changes that allow the code to compile.
Unification was failing in cases where `cdr` was expected to return an element instead of a collection with a single element. Specifically, `(cdr (cons 1 2))` should return `2` instead of `(2)`, while `(cdr (, 1 2))` should return `(2)`. Extending Python's `list` (`UserList`, really) seemed like an easy way to re-introduce `cons` and allow one to treat `cons` pairs as generic Python lists. As well, it wasn't clear how one could easily distinguish `cons` from other Python collections otherwise, which is used to produce the aforementioned `cdr` behavior.
The current issue(s) can be demonstrated by the following: (fresh [x]
(≡ x 2)
(project [x]
(≡ q (type x)))) Attempting to evaluate this (whether in a Expanded, the above is (after removing "_;" prefixes from some symbol names) (do
(setv let|1319 {}
(get let|1319 "x") (LVar (gensym 'x)))
(all (≡ (get let|1319 "x") 2)
(fn [s|1320]
(do
(require [hy.contrib.walk [let :as let|1321]])
(let|1321 [__x (get let|1319 "x")
(get let|1319 "x") (reify __x s|1320)]
((all (≡ q (type (get let|1319 "x"))))
s|1320)))))) where the relevant line is (let|1321 [__x (get let|1319 "x")
(get let|1319 "x") (reify __x s|1320)] Apparently |
I think the root problem has to do with macro expansion and the use of Consider the following: (require [hy.contrib.walk [let]])
(defmacro fresh-good [a b]
`(do (let [~a 1] ~b)))
(defmacro/g! fresh-bad [a b]
`(do
(require [hy.contrib.walk [let :as ~g!let]])
(~g!let [~a 1] ~b)))
(defmacro project-good [y]
`(do (let [~y 2] ~y)))
(defmacro/g! project-bad [y]
`(do
(require [hy.contrib.walk [let :as ~g!let]])
(~g!let [~y 2] ~y))) The functions labeled Evaluating them analogous to how we would above, we can confirm that the output also corresponds: ;; Reference case
=> (fresh-good a (project-good a))
_hyx_XsemicolonXletXvertical_lineX1665 = {}
_hyx_XsemicolonXletXvertical_lineX1665['a'] = 1
_hyx_XsemicolonXletXvertical_lineX1666 = {}
_hyx_XsemicolonXletXvertical_lineX1666['a'] = 2
_hyx_XsemicolonXletXvertical_lineX1666['a']
2
;; Direct correspondence case
=> (fresh-bad a (project-bad a))
File "<input>", unknown location
HyMacroExpansionError: bind targets must be symbols
;; Test case 1
=> (fresh-bad a (project-good a))
_hyx_XsemicolonXletXvertical_lineX1762 = {}
_hyx_XsemicolonXletXvertical_lineX1762['a'] = 1
_hyx_XsemicolonXletXvertical_lineX1763 = {}
_hyx_XsemicolonXletXvertical_lineX1763['a'] = 2
_hyx_XsemicolonXletXvertical_lineX1763['a']
2
;; Test case 2
=> (fresh-good a (project-bad a))
File "<input>", unknown location
HyMacroExpansionError: bind targets must be symbols These examples hint toward the inner Since Besides reverting the use of |
From your description, I think the problem is that It probably needs to handle |
@gilch, just put in a PR for this functionality: hylang/hy#1664 |
FYI: A lot of the remaining test failures are related to |
The tests were changed from implicit cons expressions like `[1 2 z]` to `(cons 1 2 z)`, which is now equivalent to Scheme's `'(1 2 . z)` under our new `cons`. This also makes the tests read almost exactly like their sources in The Reasoned Schemer.
All right, all the tests should pass now, but I had to enforce a stricter use of |
Updated the The remaining Travis failures are for versions of Python no longer supported by Hy; @algernon, should we remove those versions and add Pythons 3.5, 3.6, 3.7? |
Thank you for the incredible amount of work you put in this! <3 |
@algernon, anytime! I'll take a crack at updating hydiomatic next, then the basics of some symbolic math and proof assistant/type theory capabilities via miniKanren (in Hy, using this project, of course). Ultimately, I plan to work Theano (and maybe SymPy) into the mix. If you're interested, I can provide more details (Gitter, IRC?); regardless, would gladly have your input on these follow-up projects. |
I lurk on IRC (in The only problem is, I'm not very active around Hy nowadays. I eventually merge PRs but that's about it. Just the other day, I was pondering about transferring monaxhyd and adderall to someone else (or even 'hylang/`)... |
@algernon, I can help with managerial things, if you'd like. Personally, I think miniKanren-like concepts and DSLs are — and will be — sorely needed in certain areas of work, and a project like this (through Hy) is a much better approach than shoe-horning miniKanren and/or Python. That said, I'm convinced this project is well worth maintaining. Also, I had wondered why |
What's the deal with that Travis failure? That |
This PR renames/replaces #8..