Core Hy Implementation Issues

[allison-casey]

As has been mentioned before, there are a number of issues with Hy's implementation that are holding it back from a 1.0 release. I thought I'd start a running list of those issues to facilitate some discussion, help keep track of progress, and maybe get some new faces to take a crack at them. Here's what I've identified so far:

• Autoimports have caused a number of headaches Get rid of autoimports via new namespaces #1407 Automatic imports can shadow the user's assignments in the REPL #791
• Arguments aren't always evaluated left to right Arguments aren't always evaluated left to right #1342

Namespaced symbols has been brought up a few times #1407 #277 but may not be needed any more due to improvements to macro processing in #1682 which brings up another issue (pun intended). Issues needs to be cleaned up, there are a number of them that have already been fixed in other pull requests or are no longer relevant due to changes in Hy since they were made.

[allison-casey]

@Kodiologist Assuming you're okay with this, can I pin this with a help wanted label? There's been some more activity with Hy recently (which has been awesome btw) and it'd be nice to get more eyes on this.

[Kodiologist]

I'm not a huge fan of the visual clutter of pins, and longstanding difficult issues are usually those that need attention from relatively experienced Hy developers, like you and me, rather than newbies.

My personal list of things I want to be resolved before 1.0 is:

• Fix automatic imports, as you said.
• Clean up the standard library.
• Make sure that (most) code examples in the documentation are automatically tested.
• Change funcparserlib to get more informative syntax errors (Parse errors should say what tokens are legal at the stopped position vlasovskikh/funcparserlib#52).
• Improve the content and organization of the documentation.

As for the other things you brought up:

• Getting left-to-right argument evaluation order per Python would likely be a huge pain. For the time being, I'm comfortable with Hy having an undefined argument evaluation order, like C and many other programming languages.
• Namespacing symbols seems like a solution that's ultimately more complicated than the problem it's trying to solve.
• Finding and removing outdated issues is a continuing process that I've done over the years. Help with this is always good. Adding xfail tests for outstanding untested bugs is also helpful.

[allison-casey]

Clutter of pins is valid. Then can I go ahead and delete the 1.0.0 milestone and close the Grand Language Cleanup milestone as they haven't been touched in years and contain items that don't seem relevant anymore? In their stead, i'll propose a 1.0.0 github project where we can keep and expand on what we've talked about here (what "cleaning up the stdlib" looks like etc) without cluttering the issue tracker (i'll close this issue and move it to the project if we do go with that route).

• I agree with you on the left-to-right issue, I haven't run into it at all since i've been using Hy. I might take a stab at it down the road once the higher priority items are taken care of though.
• I tend to agree, namespacing seems nice for sure, but with the improvements to macro requires i'm not quite sure i see what the benefit is. I think the lack of clarity on my part might just be the issue tracker needing a once over.
• I'll start going through and labeling issues i find that I think can be closed. I haven't come across xfail tests before, but I like the idea from what I'm reading. Once we pare down the open issues, I'll take a look at adding them

[Kodiologist]

That sounds reasonable.

[allison-casey]

Went ahead and made the project board, feel free to add any existing issues/notes you have in mind or expand on the notes with more details. Going to go ahead and close this