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

[demerphq]

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...}

[BrowserUk]

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