They’re both Lisps that can import Python, but Hissp has a very different approach and philosophy.
I’m not sure how closely you’ve been following Hy after you left the project, but for the benefit of other readers, I’ll go into a little more detail. As you say, I was also a major contributor to the open-source Hy project, and am still part of the core development team. For a time I was one of the more active members, but my activity has since diminished. I realized that correcting some of Hy’s deeper flaws might require a pretty deep rewrite, but building consensus with the few remaining active members of Hy’s team proved too difficult. Hy is obviously a much older project than Hissp with more contributors and more time to develop. While my experience with Hy informs my design of Hissp, Hissp is not a fork of Hy’s source code, but a completely new project with a fundamentally different architecture.
The biggest difference is that Hy compiles to Python abstract syntax trees (or “AST”, an intermediate stage in the compilation of Python code to Python bytecode). In contrast, the Lissp language uses Hissp as its AST stage instead, and compiles that to Python code, which Python then compiles normally. Hy compiles to a moving target—Python’s AST API is not stable. This helps to make Hissp’s compiler simpler than Hy’s.
Hissp code is made of ordinary Python tuples that serve the same role as linked lists in other Lisps, or Hy’s model objects. Using these directly in Python (“readerless mode”) is much more natural than writing code using Hy’s model objects, although using the Lissp (or Hebigo) language reader makes writing these tuples even easier than doing it directly in Python.
Hissp is designed to be more modular than Hy. It supports two different readers (Lissp and Hebigo) with the potential for more. These compile different languages that represent the same underlying Hissp-tuple AST. The separate Hebigo language is indentation based, while the included Lissp reader uses the traditional s-expressions.
Hy code requires the hy package as a dependency. You need Hy’s import hooks just to load Hy code. But Hissp only requires hissp to compile the code. Once that’s done, the output has no dependencies other than Python itself. (Unless you import some other package, of course.) This may make Hissp more suitable for integration into other projects where Hy would not be a good fit due to its overhead. Hissp has already attracted some interest from the symbolic-pymc project for this reason.
Hy’s compiler has a special form for every Python statement and operator and has to do a lot of work to create the illusion that its statement special forms behave like expressions. This complicates the compiler a great deal, and doesn’t even work right in some cases, but allows Hy to retain a very Python-like feel. The decompiled AST also looks like pretty readable Python. Not quite what a human would write, but a good starting point if you wanted to translate a Hy project back to Python.
But after writing Drython, I realized that the expression subset of Python is sufficient for a compilation target. There is no need to do the extra work to make statements act like expressions if you only compile to expressions to begin with. It turns out that Hissp only required two special forms: quote and lambda. This makes Hissp’s compiler much simpler than Hy’s. But the lack of statements makes it feel a bit more like Scheme and a bit less like Python. And, of course, the expression-only output is completely unpythonic.
Another major difference is Hissp’s qualified symbols. This allows macros to easily import their requirements from other modules. Macro dependencies are much harder to work with in Hy. I suggested a similar solution, but it has not been implemented in Hy so far.
I haven’t covered every feature of Hissp, so there are more differences. See the tutorial and FAQ for a bit more thorough overview.
They’re both Lisps that can import Python, but Hissp has a very different approach and philosophy.
I’m not sure how closely you’ve been following Hy after you left the project, but for the benefit of other readers, I’ll go into a little more detail. As you say, I was also a major contributor to the open-source Hy project, and am still part of the core development team. For a time I was one of the more active members, but my activity has since diminished. I realized that correcting some of Hy’s deeper flaws might require a pretty deep rewrite, but building consensus with the few remaining active members of Hy’s team proved too difficult. Hy is obviously a much older project than Hissp with more contributors and more time to develop. While my experience with Hy informs my design of Hissp, Hissp is not a fork of Hy’s source code, but a completely new project with a fundamentally different architecture.
The biggest difference is that Hy compiles to Python abstract syntax trees (or “AST”, an intermediate stage in the compilation of Python code to Python bytecode). In contrast, the Lissp language uses Hissp as its AST stage instead, and compiles that to Python code, which Python then compiles normally. Hy compiles to a moving target—Python’s AST API is not stable. This helps to make Hissp’s compiler simpler than Hy’s.
Hissp code is made of ordinary Python tuples that serve the same role as linked lists in other Lisps, or Hy’s model objects. Using these directly in Python (“readerless mode”) is much more natural than writing code using Hy’s model objects, although using the Lissp (or Hebigo) language reader makes writing these tuples even easier than doing it directly in Python.
Hissp is designed to be more modular than Hy. It supports two different readers (Lissp and Hebigo) with the potential for more. These compile different languages that represent the same underlying Hissp-tuple AST. The separate Hebigo language is indentation based, while the included Lissp reader uses the traditional s-expressions.
Hy code requires the
hypackage as a dependency. You need Hy’s import hooks just to load Hy code. But Hissp only requireshisspto compile the code. Once that’s done, the output has no dependencies other than Python itself. (Unless you import some other package, of course.) This may make Hissp more suitable for integration into other projects where Hy would not be a good fit due to its overhead. Hissp has already attracted some interest from the symbolic-pymc project for this reason.Hy’s compiler has a special form for every Python statement and operator and has to do a lot of work to create the illusion that its statement special forms behave like expressions. This complicates the compiler a great deal, and doesn’t even work right in some cases, but allows Hy to retain a very Python-like feel. The decompiled AST also looks like pretty readable Python. Not quite what a human would write, but a good starting point if you wanted to translate a Hy project back to Python.
But after writing Drython, I realized that the expression subset of Python is sufficient for a compilation target. There is no need to do the extra work to make statements act like expressions if you only compile to expressions to begin with. It turns out that Hissp only required two special forms:
quoteandlambda. This makes Hissp’s compiler much simpler than Hy’s. But the lack of statements makes it feel a bit more like Scheme and a bit less like Python. And, of course, the expression-only output is completely unpythonic.Another major difference is Hissp’s qualified symbols. This allows macros to easily import their requirements from other modules. Macro dependencies are much harder to work with in Hy. I suggested a similar solution, but it has not been implemented in Hy so far.
I haven’t covered every feature of Hissp, so there are more differences. See the tutorial and FAQ for a bit more thorough overview.