Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: Re: Re: Re: Macros, LFSPs and LFMs

by BrowserUk (Pope)
on Jun 15, 2003 at 12:30 UTC ( #266018=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Re: Re: Macros, LFSPs and LFMs
in thread Macros, LFSPs and LFMs

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



Comment on Re: Re: Re: Re: Re: Macros, LFSPs and LFMs
Re: Re: Re: Re: Re: Re: Macros, LFSPs and LFMs
by demerphq (Chancellor) on Jun 15, 2003 at 13:58 UTC

    I dont know that I agree with this. I suppose you may want to walk the parse tree in other circumstances, but I dont see why simple printing out the exact code that failed would be insufficient, and I think that would be reasonably doable with what we have already. Sure, it may not work on some far out there cases, but then again I wonder what the use of such an insane assertion would be. Anyway, im not knocking the idea if it comes along, but until its here im not going to spend much time in anticipation. As I said IMO, %99.99 of the things that most macro langauges do can be done as well or better by perl itself. All that a defined macro language does is provide consistancy. Which in of itself is probably a good thing (or maybe a bad thing if you read my other node), but my original point was merely that a LFSP need not have macros within it.


    ---
    demerphq

    <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

      I pretty much dismissed the original assertions (sic:) of this thread as a 'dramatic statement' -- on the part of the original author of the statement rather that the originator of the node--designed to court controversy and (over?) emphasis that authors point.

      I then moved on to thinking about whether perl 'needed' or would benefit from a macro facility. Initially, my reaction was one of distain, if not horror, as I well-remembered attempting to maintain C-sources where the author had decided that he preferred Pascal syntax to C's and defined macros:

      #define endif } #define endwhile } #define endfor } ## etc

      and I shrunk away from the idea that every piece of perl source I encountered might be written in some mix of other language syntax according to the authors whim.

      I was only when Aristotle gave his "insane assertion" example that I began to see a) the benefit of having the macro processor, b) the benefit and what I would consider absolute necessity, that if such a macro facility was made available, that it be implemented at the language parser level and not stuck-on the front as a source-code parser, text substitution mechanism.

      Once I grasped the benefit of not having to do the parsing myself, I began to see the distinction between the two that he and others were eluding to. You, and most others have probably already twigged to this, but I was slow on the uptake. Having arrived there, I now think I am pursuaded that whilst it could be (and probably would be) abused by some, that is no different to the fact that we can already write obfuscated perl.

      I'm slowly exploring the potential of the idea (in my head), but I think I'm pretty much now pursuaded that the benefits of having the facility would outweight the gotchas. I think. I guess time and P6 will finalise that conclusion for me:)


      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


Re^6: Macros, LFSPs and LFMs
by Aristotle (Chancellor) on Jun 16, 2003 at 13:37 UTC
    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.
    Stallman called, he wants his Emacs back. ;->

    Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://266018]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (12)
As of 2014-07-10 11:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (207 votes), past polls