On Tue, Mar 19, 2024 at 5:02?PM demerphq <demerphq@gmail.com> wrote:
>
> So, /if/ we were to embrace something like standard perl, AND we were to
> extend the language to have a standardized way of annotating the extensions
> that the language supports then I think we could have our cake and eat it
> too.
>
> I also think it is great that Perl can support additional keywords, etc,
> etc. All we would need to make this statically analyzable would be a
> standard way to annotate that a module did this. The point being that I
> dont want to remove your ability to extend the language I want to see perl
> decide on a standard way that we do so.
>
Once we're suggesting that we should support annotations so that extensions
can be analyzed too, then why do we need to give up on syntactic
convenience? All of the weird syntactic rules that sawyer has mentioned so
far are correctly parsed by my tree-sitter-perl (
https://github.com/tree-sitter-perl/tree-sitter-perl), except for the one
that was incorrect (`a \n =>` is still autoquoted). And when you use
tree-sitter for syntax highlighting (which you can do today in nvim and
other editors), then you can visually see any subtle things (b/c functions
and strings are highlighted differently). Heck, it even highlights hashes
and arrays differently, b/c it doubles down on the value of sigils (I
remember that damian managed to parse this using PPR in a 1000-something
line regex?. when you use an actual parser, then you can handle these
things).
In fact, i think that the whole notion of building perl tooling with perl
being parsed by perl is all incorrect. We benefit a lot more if we build
things that can interact with the wider tooling ecosystem (b/c that's a
thing). Using tree-sitter, there are numerous projects that enable semantic
search (like ast-grep https://ast-grep.github.io/, which allows you to type
code + find similar code. i've been expermineting with it, and it's
literally magic). Using these tools, you get to compile perl to a syntax
tree, and can do linting, and replacing. Except you can do that today. And
it gets better as the project as a whole gets better.
Of course, everything is a work in progress, and tree-sitter-perl's
coverage isn't 100% yet (i haven't made it bug-compatible re sublexing yet,
for example), but I think it's a much better path forward re tooling.
>
> So, /if/ we were to embrace something like standard perl, AND we were to
> extend the language to have a standardized way of annotating the extensions
> that the language supports then I think we could have our cake and eat it
> too.
>
> I also think it is great that Perl can support additional keywords, etc,
> etc. All we would need to make this statically analyzable would be a
> standard way to annotate that a module did this. The point being that I
> dont want to remove your ability to extend the language I want to see perl
> decide on a standard way that we do so.
>
Once we're suggesting that we should support annotations so that extensions
can be analyzed too, then why do we need to give up on syntactic
convenience? All of the weird syntactic rules that sawyer has mentioned so
far are correctly parsed by my tree-sitter-perl (
https://github.com/tree-sitter-perl/tree-sitter-perl), except for the one
that was incorrect (`a \n =>` is still autoquoted). And when you use
tree-sitter for syntax highlighting (which you can do today in nvim and
other editors), then you can visually see any subtle things (b/c functions
and strings are highlighted differently). Heck, it even highlights hashes
and arrays differently, b/c it doubles down on the value of sigils (I
remember that damian managed to parse this using PPR in a 1000-something
line regex?. when you use an actual parser, then you can handle these
things).
In fact, i think that the whole notion of building perl tooling with perl
being parsed by perl is all incorrect. We benefit a lot more if we build
things that can interact with the wider tooling ecosystem (b/c that's a
thing). Using tree-sitter, there are numerous projects that enable semantic
search (like ast-grep https://ast-grep.github.io/, which allows you to type
code + find similar code. i've been expermineting with it, and it's
literally magic). Using these tools, you get to compile perl to a syntax
tree, and can do linting, and replacing. Except you can do that today. And
it gets better as the project as a whole gets better.
Of course, everything is a work in progress, and tree-sitter-perl's
coverage isn't 100% yet (i haven't made it bug-compatible re sublexing yet,
for example), but I think it's a much better path forward re tooling.