I'm the one who wants his bloody program to syntax check correctly, whatever it takes. That's who. :-)
Did you read my first reply to this thread? I wrote a module that shows how you can prevent Perl from running this code and it uses the very features you decry.
No, you pointed me to an Acme (joke ) module of some sort, which I took for a troll attempt. Then you clinched it in my mind by saying it was based on source code filters: unless the source filter parses the perl code before passing it on to the parse, it can't properly decipher all of perls elaborate parsing rules. Given that people have spent many years on a compiler (and alternative parser!) for perl, and their best efforts only for many, but not all cases, I was initially reluctant to assume that you've whipped up a source filter that demonstrably works better. If you have, my apologies; I'd be eager to learn more about it.
Patches welcome. Wrongheaded patches not. Anonyperl fork permissible. Well, to do what I want all by myself, I'd have to re-write the parser, because that's simpler than trying to understand that monstrosity, and all it's corner cases. I'd have to take chunks out of the language to make it BNF or otherwise parseable in a way I could understand. I'd have to get the support and trust of a user community to prove that my changes aren't fundamentally flawed, and then I'd have to submit it to years of open source testing. The Anonyperl fork is a lot of work.
The perl maintainers already understand the source code to their language; so they can skip most of those steps. They've got a language that they understand the code to, and have formally code reviewed and peer analyzed all the lines of code within it, and know what they do. I can't hope to match those accomplishements alone, and I'm not sure it's wise to try. Perhaps, the Anonyperl fork is just spelled "Python". I'd really rather see perl made nicer (at least trustable!) but given the vehemence I'm seeing against it, I guess it won't happen. :-(
Perhaps when proof-carrying code and compile-time provability proves itself workable for real-world problems that do dangerous things such as reading data with contents unknown at compile and analysis time.
They've already proven themselves workable and quite invaluable for an important subset of real world problems known as control systems. You know, systems where the values you get are known: and had better be right in all cases, or someone might die. Formal static analysis certainly doesn't replace careful code review and testing, but it most certainly has it's place in the real world, for some very important tasks.
Completely untrue and misinformed. I have written such tools. jjore has written such tools. Alias has written such tools.
If they work, and they're proven, by all means point me to them. I was under the impression that most of the work done was ad hoc "pray that this works" source code filter style stuff: useful only a certain percentage of the time, for a certain set of well written code. My co-worker's code is (obviously!) not well written, nor even trustworthy.
Besides that, you're no one. Why not you?
Well, that's a fair question. But to be honest, I haven't invested multiple years of my life learnning and memorizing the ins and outs of perl's source code, like many the perl maintainers have. I'm also not the one advocating that people use perl for business use, like they are on places like perl.com. Given that they're cheerleading for the product, I think it's fair to point out what I see as fundamental flaws in the product; and tell the people I see as the most capable of addressing them with the minimum of time and effort.
Maybe I do need to write tools like that. Maybe I just need to move to another language. I still really just want a trusted, tested, code reviewed and community tested syntax checker that is 100% (or 99.999%, in the real world) reliable. I thought this was a reasonable goal; I get a free syntax check with every compiled language on the planet, after all. Most of those languages predate Perl.
If software development had waited until practical provability were possible, I'd be sending this message by turning cranks on a gear-driven machine. Think about the features you have to remove from a general-purpose near-Turing device to perform static flow analysis -- then think about how unsuitable such a device is for general purpose computing.
I don't follow. As you said, progress in incremental: that doesn't mean it has to work backwards! Syntax checking in other compiled languages has been around longer than Perl itself!
As I said, yes ,I'd certainly like all those nice, theoretical, formal analysis tools. As I said, that's too much pie in the sky to ask for. Again, as I said, I'll settle for a decent syntax checker; and that's been possible for general purpose computing for decades.
For some reason known only to themselves, the language designers choose to give me features they knew I couldn't trust and therefore probably wouldn't use in exchange for taking away one of the few features that they knew I really need (a trusted syntax check); and I can't help but resent them for it slightly. :-(
Perl for many years was billed as a "secure" language; but the truth is, a syntax check used to refactor suspect code can trigger an exploit, unless clunky methods such as code filters are used to try to mitigate this risk.
I wouldn't be so bitter if I wasn't facing real world problems introduced by this very language design choice, but I am. It's not just a theoretical issue; it's a practical one, and I stand by my stance that the perl designers made a bad choice, and should fix it however they need to.
In reply to Re^8: Syntax checking without BEGIN blocks
by Anonymous Monk
in thread Syntax checking without BEGIN blocks
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |