Thoughts on the recent hyrule changes

[eshrh]

Personally, I like a lot of these changes from the alphas, but i find it really annoying now that a lot of super useful macros and functions got moved to hyrule. Specifically, macros like #% (->/->>) ncut (loop/recur) are macros that I use in nearly every single hy program I write, and it's inconvenient and ugly to have to import them from hyrule. On alpha 4, my programs have several token imports not to add any extra functionality, but just to make my code not hair-pulling to type out.

For example, I'm not really sure how a macro like #% isn't considered absolutely essential in a functional style of mapping or filtering by lambdas. Similarly, either #: or ncut are both essential for any kind of complex data manipulation.

I guess it would be fine if hyrule came with a hy installation, but now I feel like I have to avoid using those because I don't want an extra dependency. It could be like python's functools - nice but technically unnecessary functionality moved to a different package but part of the stdlib. I understand that things were moved out of hy.contrib and into hyrule specifically to make them not default, so there was some reason behind it, but I just don't really like the final experience as an end user.

Combined with the recent but less important changes like removing predicates in favor of isInstance, and making pyops not default, it does feel to me in a way that the rich, default lispy library of functions and utilities that make formulating ideas elegant, simple and concise (that users are encouraged to use) is being gutted into an austere and more boring core. From what I've seen, these changes are made to make the internal dependency web simpler and the codebase neater, but I don't think this should come at the expense of the programming experience. To summarize, I think my biggest problem is that moving elegant functionality out of default hy effectively discourages its use, and I'm not sure if that was considered.

Maybe I wouldn't think this way if I knew more about why the changes were made or was more familiar with the code, so please keep in mind that these are just some thoughts from someone who hasn't written much hy at all.

[Kodiologist]

I don't understand why adding a single require form to your code and saying pip install hyrule feels like a burden or discourages use. ("Inconvenient"? "Ugly"? Isn't requiring macros and importing objects as convenient and pretty as it could possibly be?) I'm also not clear why you don't want to add a dependency if the alternative that you do want is to depend on all the same code, just in a different Python package, namely Hy itself rather than Hyrule.

From what I've seen, these changes are made to make the internal dependency web simpler and the codebase neater

The predicates were removed because there were a million of them, with no clear dividing line between which should exist and which shouldn't. We kept the only one of them that was nontrivial, coll?.

(For what it's worth, I had no idea that anybody used or cared about all those predicates. There wasn't a peep of protest in #1992 or #2095. If you want a hand in Hy's future, be sure to watch issues and PRs closely. That's where the decision-making happens.)

Removing the implicit pyops import was for namespace cleanliness. That, plus the moves into Hyrule, plus the renaming of gensym to hy.gensym etc., guarantees that the only thing brought into scope in Hy programs implicitly, other than Hy's internal temporary variables, is the name hy itself.

Sidebar: if you find yourself using #% , map, and filter a lot, you may benefit from making heavier use of the comprehension forms, which are typically both more concise and easier to read. We provide more traditional functional approaches as an option, in the name of TMTOWTDI, but they're usually a worse option.

[Kodiologist]

Is what's getting you down having to name each macro you want to require? You can always say (require hyrule *). This brings up all the same namespace-pollution problems as previous versions of Hy, of course, but it's an option that will continue to work with new versions. And it's convenient for interactive use.

[eshrh]

I'm also not clear why you don't want to add a dependency if the alternative that you do want is to depend on all the same code

This is my main problem, not so much that things are being moved to hyrule. I do think it feels like a burden. For instance, now that ->> is part of hyrule, I get that sense that it isn't "idiomatic" to use ... because it's exactly the core language's set of syntax and functions that defines what "idiomatic" code looks like. This is a lisp after all, its trivial to define some macro-based dsl and then make code depend on it, but it's still the core language features that make this unidiomatic hy.

It's not the requires that bother me at all, its the package not being installed by default. I'm proposing (require hy.hyrule *) instead of (require hyrule *).

Perhaps there's some minimalism dogma I can't shake, but when I'm writing code and I encounter a situation where I'd really like to say, slice an array by column, I'd rather just deal with it and write it the annoying way instead of adding a dependency to slice it neatly.

if you find yourself using #% , map, and filter a lot, you may benefit from making heavier use of the comprehension forms, which are typically both more concise and easier to read.

I guess I can't really say anything about this, it's an entirely different discussion. My point is that moving #% etc to a nondefault package is saying that using those traditional functional patterns is not idiomatic.
I'm more used to clojure and other lisps where doing this kind of lambda mapping/folding/filtering is common. I'm fine with hy declaring something to be not idiomatic, I'm just not sure whether this was the intended purpose of moving things out.

If you want a hand in Hy's future, be sure to watch issues and PRs closely. That's where the decision-making happens

I'll be doing so in the future, but like I mentioned in the first post I'm pretty new to hy! I didn't make an issue for this specifically because this was probably already discussed there.

[Kodiologist]

moving #% etc to a nondefault package is saying that using those traditional functional patterns is not idiomatic

I think you're reading too much into how the code is organized. The point is not to suggest that we prefer you use things that are in core Hy over things in Hyrule. The point is to make development of the compiler easier and get you a mature stable release (version 1.0) faster, without retarding the development of Hy's standard library. In a nutshell, we put things in Hy if we have to, and Hyrule if we can. We expect that most nontrivial Hy programs will use Hyrule, the same way that most nontrivial Python programs (and Hy programs) use Python's standard library.

Anyway, don't sweat too much about what's "idiomatic". Remember that the point of Lisp is that it's a programmable programming language. You're not expected to learn the "industry best practices" and use those. You're expected to tweak the language to your taste, so that it fits how you want to solve the problem you're solving. Lisp comes from the world of hackers and scientists, not corporate code monkeys.

Perhaps there's some minimalism dogma I can't shake

I think being a good programmer means knowing when to make use of libraries. It's good to not want to be like the Node.js people and have eleventy thousand dependencies for a to-do list application, but you don't want to insist on reinventing the wheel every time, either.