|Problems? Is your data what you think it is?|
Perl can be hard to parse,
That was my initial reaction...until it dawned on me that Aristotle's use of A, B, C & D was deceptively simple. Indeed, the whole expression is just a placeholder meant to indicate an abitrarially complex set of two or more conditions that need to be true.
Imagine all the different types perl 'equality' expressions that "A eq B" and "C eq D" could represent, and all the different ways there are of combining two arbitrary booleans (as represented by '&&'). Then think about trying to write the filter that would be required to check for an arbitrary number of combinations of all of these possibilities, detect which bits pass and which bits fail, and generate meaningful errors to describe each of the possible failure modes.
I was tracing through that process in my mind, when it dawned on me that what you need to do is replicate the perl parsing process and get at the tokens perl finds.
And that is exactly what the 'proper' macro processor would do.
Perl would take care of doing all the parsing, but before it executed the optree it found, it gives you the opportunity to inspect its work and inject a few extra statements into it, Or delete a few. Or....
It took me a while to get there, but I think I finally got it:)
Perl already has all the nouse required to parse perl, exactly correctly. Why even consider trying to duplicate this process. Simply arrange for perl to do it in it's own inimitable style and then give you access to its finding in a clearly defined data-structure (the optree) and let you take it from there.
The application that I now envisage for this is an editor. I think I could see writing a few macros that would allow me to use perl itself as my editor/debugger. perl comes close already with -d. It only needs a little more work to present the source in a more human freindly way and you have a perl IDE that doesn't just parse perl and syntax highlight (accurately most of the time:), but that truely understands it. Basically perl becomes your editor. Now that's an application that would be worth having. Instead of presenting you with what it thinks perl will make of the source code, it presents you with what it actually made of the source code. Everything you would see would be like the output from Deparse. Perhaps conditionally adding in extra parens or not depending upon how you, the programmer chose to configure it. Ditto for the layout (style) it uses to present it on-screen.
Then I saw the killer application.
You would no longer type your perl into a text file, using an editor that made a better or worse attempt at highlighting it, or use a PerlTidy app to reformat text-based source files to your own standards.
You would type your source directly into perl itself.
It would parse it, and store not the source code representation it presents back to you, but it would save the program in object code format. When you ran it, you would give the object code format directly to the runtime interpreter. No re-parsing.
You would store and distribute perl scripts and modules in this object code format. Noone would ever see your personal coding style, because when they edited your code, they would load it into their copy of perl, configured to their preferences, and perl would deparse the object code format and present it back to the them in what ever style they had configured. Of course there would be an option to save the program to a text file, formatted according to whatever set of formating rules where in force at the time, but that would only be for presenting the code in books, or on-line discussions etc.
There would of course be people that would always keep copies in this form, just as there are people that always print their emails to read and archive them. But the primary form of perl scripts would be the unambiguous, no-syntax errors, editor-agnostic, devoid-of-personal-preferences-or-quirk, machine readable form.
Anyone interested? :)
Examine what is said, not who speaks."Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller