Idea: project compat declaration

[paultag]

@hylang/core - going to need some feedback on this one

I'd like to suggest adding a compat stop-gap for Hy source code. This will be optional, and likely result in more crap sitting in core or the compiler.

I'm not sure about the details yet, but I'm wondering if we could add something to the package metadata in setup.py for projects (or a file in the package directory) to declare a "Hy compat level".

This would let people declare the major and minor (e.g. no patch level) version number of Hy that it needs. (e.g. compat: 0.10 or 0.11, not 0.11.10)

The idea here is that we'd support old minor releases for a few versions to ensure we can do a migration (but throw a few deprecation warnings), such as our recent keyword changes, and likely changes to (let) that will pop up soon. I'm assuming defun, car, cdr are up next.

This would add a few more codepaths in the compiler, and I have no idea if this is a good idea or not, but I don't like the idea of a minor bump breaking code in a way that requires tons of changes. If we could suggest adding a compat while they migrate, I'd be more open to changes like this.

After a few releases, I'm assuming we'd formally deprecate it, and raise an Exception if the compat is too far out of date (and we'd trim the code out). If we get a future compat, we should also likely error out.

[agentultra]

I don’t like the idea of versioning the language. We fail our users every time a user wants a feature that requires changing the parser. Adding to the pain of versioning the interpreter our code generator runs on is not a good idea. It’s a shot in the foot (“Python 2.7.1 + Hy 1.3? Python 3.2 + Hy 1.7? 2^m*n permutations to support, woo”).

In my not-so-humble opinion we should focus on reducing down our core primitives to their most hardened, well-understood forms. We should re-write as much of Hy as we can in Hy. We’ll win when we can build-up instead of maintaining everything top-down. Get the foundations right and we won’t have to force core developers into stewardship over another parser and grammar.

On Dec 30, 2014, at 12:32 PM, Paul‮etnomailgaT‭ notifications@github.com wrote:

@hylang/core - going to need some feedback on this one

I'd like to suggest adding a compat stop-gap for Hy source code. This will be optional, and likely result in more crap sitting in core or the compiler.

I'm not sure about the details yet, but I'm wondering if we could add something to the package metadata in setup.py for projects (or a file in the package directory) to declare a "Hy compat level".

This would let people declare the major and minor (e.g. no patch level) version number of Hy that it needs.

The idea here is that we'd support old minor releases for a few versions to ensure we can do a migration (but throw a few deprecation warnings), such as our recent keyword changes, and likely changes to (let) that will pop up soon. I'm assuming defun, car, cdr are up next.

This would add a few more codepaths in the compiler, and I have no idea if this is a good idea or not, but I don't like the idea of a minor bump breaking code in a way that requires tons of changes. If we could suggest adding a compat while they migrate, I'd be more open to changes like this.

After a few releases, I'm assuming we'd formally deprecate it, and raise an Exception if the compat is too far out of date (and we'd trim the code out). If we get a future compat, we should also likely error out.

—
Reply to this email directly or view it on GitHub.

[Foxboron]

I really think @agentultra is on something. How much can we reduce the compiler by doing clever macros with the new AST support as an example?

[cwebber]

I also don't think versioning Hy in-Hy is a good idea. I think that's going to result in a load of spaghetti and we are going to hate ourselves in the end for it. Need an older Hy? Use an older Hy.

@agentultra I think implementing as much of Hy in Hy is good, though I don't think we should drop all our support for "use native Python AST where possible" rather than implementing our own. I think we'll start to hit speed tradeoffs and lose some of the value of what Hy is.

But maybe we could have a certain section designated as the "hardened core" and have the option of using just that and building on top of it.

[algernon]

👎. Hy's still not 1.0, it is expected to break existing code from time to time. Supporting older syntax and stuff via language versioning is terrible. If something doesn't work with a newer Hy, either migrate, or use an older Hy version, I'd say.

Nowadays we try to not break many things, so the problem is far less pressing than it used to be.

[Kodiologist]

Looks like the nays have it.