> On Dec 27, 2022, at 1:13 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>> It should be possible to port this, but I question if it is worth
>> the effort.
>
> I think it's worth the effort in order to help empower our users to make
> changes to their grammars. Otherwise we're back to grammars whose
> source is legally-speaking Free but that most of ours users wouldn't
> know how to change.
The “DSL” used to describe language grammar is reasonably straightforward, and our manual explains it to some degree (see the end of section 37.1 Tree-sitter Language Definitions). Though one probably need some additional knowledge on writing parsers to work on the grammar.
The problem is that the "cli" written in Rust is the parser generator. I looked into trying tree-sitter last summer, but gave up when I discovered the Rust tool chain isn't available for cygwin.
A cursory inspection doesn't show me why the author goes to the length of using _javascript_ and nodejs, since all the real work appears to be in Rust.
I suspect that Stefan and Eli would prefer a solution that decoupled the use of libtreesitter from the tool that generates the shared library with the parser tables (and whatever else is required) that the tree sitter library loads.
Generating GLR automata is well-understood, but tree-sitter appears to have some additional functionality in its parser generation. How much of that is required for libtreesitter to function is another question that would need to be understood.
This is where the culture of free software, where the process of building software is expected to be inclusive of the user-developer's local system, and corporate open-source, which requires repeatable processes and controlled build environments, are at logger heads. Chromium (and its component projects) is not encumbered by a software license, but it's build process is a nightmare for any individual that wants to validate or control, at least in principle, all software running on their system. I'm only using Chromium as an example with which I'm somewhat familiar. It sounds like Rust incorporates some bias towards "continuous integration" builds as well.
Lynn