3 ms·
> That's some mighty fine left brain thinking there( especially for a Monday morning ), but does it in anyway affect any practical aspect of Perl? The first co
by ExpiredLink 11y ago
> That's some mighty fine left brain thinking there( especially for a Monday morning ), but does it in anyway affect any practical aspect of Perl?
The first comment.
- ah- 11y agoBuilding advanced tools like a static analyzer is much harder / partly impossible because you can't parse it without running it.
- sgrove 11y agoAbstract interpretation/symbolic execution should still work, but it would require basically reimplementing the semantics of perl, yes.
- Someone 11y agoThat still may be of little help in, say, a perl IDE, as the meaning of a program _can_ depend on the input it reads. "But that will not happen in practice" If you think that to be the case, use a language that _can_ be parsed. That makes life easier for implementers of IDE's, refactoring tools, etc. and costs you nothing (given the "that will not happen in practice" claim)
- fibo 11y agoTake a look at PPI - Parse, Analyze and Manipulate Perl (without perl) module: https://metacpan.org/pod/PPI https://metacpan.org/pod/PPI Infact it says: "only Perl can parse Perl". On the other hand JavaScript has esprima that is written in JavaScript, and also other languages like Python can parse themselfs. As a Perl programmer, I don't know if it is a pro or a cons. For example Perl::Critic cannot parse some costructs, cause they are too complicated. What I usually do, as in many other contexts, I try to understand what is the subset of features I need to use.