tree-sitter / tree-sitter-haskell

Haskell grammar for tree-sitter.
MIT License
151 stars 36 forks source link

Keep repo files in-line with other grammars #122

Closed amaanq closed 3 months ago

amaanq commented 3 months ago

I'm not sure what the tools, extra stuff in test besides corpus files, and flake stuff are, but they're not needed and trying to run some of the custom "tests" didn't even work - so simply get rid of it.

It can be added back if it's usable via the cli - parser tests and query tests can be done so with the cli, so I'm not sure what this was for.

Also updated the scanner to use the alloc and array headers for relevant operations, as well as streamline the workflows + correct bindings that needed to specify the scanner file.

tek commented 3 months ago

you have got to be kidding

guess that's me being done with this org. if someone wants future changes, you'll have to cherry-pick from my personal account

cc @clason

clason commented 3 months ago

Sorry about that; I have nothing to do with these changes. (I'm just a downstream maintainer of nvim-treesitter and not related to this org. I just wanted to pick your brain on the other PR.)

tek commented 3 months ago

I know, just notifying you about moving my maintainership to a different repo, in case it makes a difference for nvim-treesitter

amaanq commented 3 months ago

you have got to be kidding

guess that's me being done with this org. if someone wants future changes, you'll have to cherry-pick from my personal account

cc @clason

Hey @tek, I probably should have waited for you to comment on this before merging, so I do want to genuinely apologize to you for not doing so. I felt a little slighted by your choice to continue developing on main while not checking in parser.c (hence why I wanted to comment on your PR before merging when it was marked ready, but that only lasted a day or so). I totally get where you're coming from with that, but every grammar upstream (in this org) has a convention about this currently, and that is to just check in parser.c. Had you asked me or Max, we do have plans to get rid of the need for this eventually, as noted in Max's 1.0 checklist, but the tooling and infra is not there yet. We do want to move to GH releases for parser.c artifacts, and the CLI will be augmented to handle this for authors pretty well, but again, we're just not there yet.

I would really like to continue working with you on developing the grammar, and I know you've done a fantastic job thus far maintaining it - so I'm really sorry if I offended you with what I did here (late night tiredness + wanting to get it in, yeah bad move). I do want to ask though, a lot of these files did not seem to function for the repo itself, but rather for you for local development/testing? At least the rust crates seemed like they were a bit unnecessary and the parse-test one didn't pass successfully as well. The tools stuff I'm not so sure about, and I probably should've waited to ask you.

Are you on Matrix or some related messaging platform by any chance? I'd love to continue chatting there and make amends, I really do want to coordinate development better with you so that consumers from every angle can benefit from your work, that's really my main goal :grin:, but if you choose to leave and develop in your own fork, well, I can't stop you, but it'd be a shame

tek commented 3 months ago

since you appear to have the intention to make grammar repos uniform, it just makes sense for development to happen in a separate environment.

so best I can offer is to mirror changes back to this repo – I can't work if there's a chance that all of my tooling is just deleted

ObserverOfTime commented 3 months ago

Honestly, some of the tests can be added back with some refactoring: rust tests should be moved to lib.rs (using format!("{:#}", root_node) instead of the custom function) and parse tests should either be added to the corpus or moved to examples and parsed in CI. Arbitrary queries don't have an official method of testing quite yet.

The tooling can be added back if documented, otherwise gitignored and used by you locally if no one else needs it.

sergv commented 3 months ago

@amaanq I'm just trying to form full picture about future of this repo and where to find tresitter Haskell grammar. Given that you made sweeping changes is it to be expected that you'll maintain the grammar going forwards, fix existing bugs/inconsistencies/etc?