Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Macros, LFSPs and LFMs

by stefp (Vicar)
on Jun 11, 2003 at 16:16 UTC ( #265084=perlmeditation: print w/ replies, xml ) Need Help??

My recent post proclaimed in substance my faith on Perl6 macros as a device to cast in syntax common programmatic patterns which were not integrated in Perl6 standard syntax. It makes sense because a programmatic pattern may be common in some context but not worthwhile to capture in the standard language. It can also be a way to experiment syntactical devices that can eventually find their way in Perl6 standard syntax.

I was pointed to this artima weblog by a (not yet archived) post in ll1. It says that macro is one of the devices that distinguish LFSPs (Languages For Smart People) and LFMs (Languages for the masse) and goes to analyse their implications.

The blog author cites Gilad Bracha who advocates against the introduction of macros in Java because it is a LFM: The advantages of Java is that it easily serves as a lingua franca - everyone can read a Java program and understand what is going on. User defined macros destroy that property.

What do you think?

-- stefp stefp
Come to YAPC::Europe 2003 in Paris, 23-25 July 2003.

Comment on Macros, LFSPs and LFMs
Re: Macros, LFSPs and LFMs
by educated_foo (Vicar) on Jun 11, 2003 at 16:31 UTC
    I think the question should be re-posed in less loaded terms, since the whole "LFSP/LFM" thing rubs me the wrong way. As far as I can tell, it's another case of the usual ad hominem "my favorite language is X. X has Y, which is absent in many other languages. I think I'm smart. Therefore X is a 'language for smart people', and Y, its distinguishing feature, is a 'smart people' feature." I personally like macros, and enjoy Lisp, but I think of it as a "language for people who like programming languages in and of themselves." Sometimes it's "smart" to make up your own language to solve a problem, and sometimes it's "stupid" (I've tried it in both cases;).

    /s

Re: Macros, LFSPs and LFMs
by adrianh (Chancellor) on Jun 11, 2003 at 16:43 UTC

    I like being able to create domain specific languages - so I think decent macros are a great idea. It's something I miss in Perl5.

    In general I think that Perl6 is doing the right thing by building the infrastructure that allows language features to be added (pre/post handlers, macros, etc.) rather than adding everything into the core language.

    Macros and operator overloading seem to be things that start religous wars on the language front. Personally I am in the camp that says both things can make code simpler and therefore easier to understand for everybody, smart or otherwise.

    I've never seen any studies that show that these features cause comprehensibility problems, just lots of anecdotes and straw man examples. My personal experience has been the opposite.

    Yes, these features can be misused. A poorly designed set of macros can make it hard to understand what a program is doing, but you can get the same sort of problems from a poorly designed API.

    I don't agree with the whole LFSP/LFM divide. In my experience language adoption by the "masses" is driven by a large number of different factors - many of them having nothing to do with the features of the languages involved.

    Trying to justify why certain languages are popular/niche by only looking at the language features can be an exercise in futility.

Re: Macros, LFSPs and LFMs
by chromatic (Archbishop) on Jun 11, 2003 at 17:19 UTC
    everyone can read a Java program and understand what is going on

    Untrue, unless you're denying the existence of non-programmers or programmers who don't know OOP or programmers who've never worked with an Algol-derived syntax.

    I've said before that the notion that "the simpler the syntax, the more readable the code" is a false dilemma. You'll have complexity somewhere else. I don't care if a non-programmer can't read my code. I care if a decent Perl programmer can maintain my Perl code. I care if a decent C programmer can maintain my C code. I care if a decent Ruby programmer can maintain my Ruby code.

    Bring on macros! I'll use them to simplify my code as a whole. If I use them wisely, they'll make it easier to understand and maintain.

Re: Macros, LFSPs and LFMs
by VSarkiss (Monsignor) on Jun 11, 2003 at 18:00 UTC

    Well, the two viewpoints seem to be saying, "If you a programmer enough rope, he'll hang himself" and "If you a give a programmer enough rope, he'll build a rope bridge". (No slight intended: "she" works equally well in those.) I'm solidly in the latter camp.

    Part of the problem is that people automatically think of macros as the way they were implemented in C. But that's just one implementation, and not a good one at that. Perl source filters already give you a way to wreak worse havoc, but I haven't seen anybody abuse them, except for entertainment.

    The argument that "If the language had macros, everybody's code would look different" is a red herring, in my opinion. Most code already looks different in different shops, and it's not that big of a deal. The shops that like to re-invent wheels and "do things their way" do the same thing with goofy class libraries now. If you try to handcuff them by taking away language features, it just gets worse, not better, because then they come up with different workarounds.

Re: Macros, LFSPs and LFMs
by shotgunefx (Parson) on Jun 11, 2003 at 18:39 UTC
    Can't wait myself! It'll be nice to actually be able to extend without using source filters. Don't like them personally.

    -Lee

    "To be civilized is to deny one's nature."
Re: Macros, LFSPs and LFMs
by webfiend (Vicar) on Jun 11, 2003 at 19:20 UTC

    I'm looking forward to macros. I agree with other posts that the "LFSP/LFM" split can be arbitrary. If you're going to use that split, however, Perl is explicitly both. Beginners can use Perl baby talk to get stuff done, while advanced folks are doing brain-twisting stuff with tied variables, objects, and closures (oh my!). I'm reasonably certain that baby-talk Perl folks will shy away from macros until they feel ready.

    The only reservation I have is the possibility that naive developers will end up using a macro to reimplement a language feature that already exists. If they were doing this as an education exercise, it makes perfect sense. There's just this nagging feeling that somebody will put them in production code, and we'll be the ones who get to maintain / repair their code somewhere down the line :-)

Re: Macros, LFSPs and LFMs
by BrowserUk (Pope) on Jun 11, 2003 at 19:23 UTC

    The "should we, shouldn't we" debate seems to be yet another sterile academic debate from my perspective, but maybe I'm missing something. Whilst I remember making a few rods for my own back with the C macro facility, mostly related to writing macros that had side-effects, I have also seen them put to very good use.

    Does anyone with a strong opinion against adding macro facilities care to give a few reasons?

    On the other hand, I'd also like to see a few examples of what people would use a macro facility for in Perl. Assuming that p5 had a C-like

    #define name(arg[,arg]) {\ some code here\ }

    I think that's roughly the syntax

    What would you use it for?


    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


        Damrn it! You mean now I learnt perl I gotta learn french as well? :)


        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


      On the other hand, I'd also like to see a few examples of what people would use a macro facility for in Perl. Assuming that p5 had a C-like

      #define name(arg[,arg]) {\ some code here\ }

      I wouldn't use it for C-like purposes. C-like macros are not that powerful - you can only do basic textual substitutions. To quote Synopsis 6:

      Macros (keyword: macro) are routines whose calls execute as soon as they are parsed (i.e. at compile-time). Macros may return another source code string or a parse-tree.

      Returning a parse-tree is where it gets interesting. What we get here are LISPish macros. We'll be able to write code that's run at compile time to create our own syntax.

      Want a switch statement in Perl6? Just write one.

      Want to add AOP or Design by Contract support to Perl6? Just write some new syntax.

      Want to create a domain-specific language so you can write code that more directly reflects the problem domain? Yes - you guessed it - just write some new syntax!

      There's a discussion of macros on perl.perl6.language that you might find interesting. Also read the relevant bit of Apocalypse 6.

      Macros - can't wait ;-)

      Update: Just come across A Macro System for Perl?, which has some relevant material for those who are interested.

        Thanks muchly for that. Never having done anything with Lispish languages, much less it's macro facilities, I've never really encountered macros in this form.

        The perl.perl6.language thread was particularly useful. I'd read that bit on macros in Apo.6, but hidden amongst so much else, I think I must have closed my eyes and held my breath as it washed over me. Time to go back and read itagain. I think that LW summed up the pro's and cons of macros in this form with two statements--that probably shouldn't be taken out of context, but will serve me as anchors in my grep for further info and an opinion.

        This is the most dangerous kind of return value, and the least likely to produce coherent error messages with decent line numbers for the end user. But it's also very powerful. Hee, hee.

        A lot of Perl is fun, and macros are fun, but in general, you should never use a macro just for the fun of it. It's far too easy to poke someone's eye out with a macro.

        And as far as Macros - can't wait ;-) goes--I probably agree, but I'll reserve judgement until I form an opinion. This is one of those things that I find very difficult to grasp the significance of at a purely theoretical level, a couple of practical uses will probably convince me.

        I tend to be pretty impirical by nature. That's probably why I have such a hard time with pure math once you get beyond stuff you can at least model with a few empty loo-roll holders and some sticky-back plastic. I have vague memories of something about a blind French mathematican that proved that you can turn a sphere inside out (topologicaly speaking) without breaking the surface. I concluded that you would have to be blind to even concieve of such a notion:)


        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: Macros, LFSPs and LFMs
by demerphq (Chancellor) on Jun 14, 2003 at 23:14 UTC

    Macros are used in many languages to resolve issues that the language for one reason or another doesnt address directly, to fill in the cracks so to speak. I dont see why a language that has appropriate other features necessarily needs a defined macro mechanism. Some of the more common uses for macros are: Templating, Inlining and Conditional Compilation. If a language provides other means of accomplishing these tasks then I see no reason for the language to define a macro language. OTOH, if a language doesnt provide these features, then any arbitrary macro preprocessor will provide then if needed. And when I say any arbitrary macro preprocessor I mean anything from perl to borrowing the C preprocessor for the job.

    Which kind of leads me to my main point. Perl doesnt need a macro language because it is a better macro preprocessor than anything else out there all by itself. With closures and eval, source code filters and funky things like BEGIN/INIT blocks and friends, Perl doesnt need anything that a macro preprocessor can provide.

    Anybody who thinks that having a macro facility indicates that a L is FSP obviously hasn't noticed VB's macros.


    ---
    demerphq

    <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
      Perl doesnt need a macro language because it is a better macro preprocessor than anything else out there all by itself. With closures and eval, source code filters and funky things like BEGIN/INIT blocks and friends, Perl doesnt need anything that a macro preprocessor can provide.

      Yes it does. It needs the ability to get at the parse tree.

      Once we have the ability to read and write the parse tree at compile time (and change the grammar rules that make the parse tree) we have a lot more flexibility and power. This is what makes the addition of proper macros to Perl6 so exciting for me.

      Take a look at the source for Switch. Nearly 500 LOC, large chunks of it dealing with parsing Perl.

      Source filters are hard due to the "only perl can parse perl" problem. Adding new syntax is amazingly tricky to do in the general case because you have to deal with all the idiosyncratic elements of perl at the level of raw text.

      Once you have more than one source filter on a piece of code things basically become impossible because at least one of those filters is going to have to parse "illegal" perl.

      Anybody who thinks that having a macro facility indicates that a L is FSP obviously hasn't noticed VB's macros.

      Anybody who thinks VB is a good example of a macro system has never used Lisp or Pop-11 or Scheme or ... :-)

        I'm beginning to come around to the idea that a 'proper' macro processor could be useful, but I'm still struggling to think of good uses for it. Aristotle came up with one, allowing Assert() to provide meaningingful error messages about what failed, particularly useful if the condition being tested has multiple sub-conditions. His example was Assert( A eq B && C eq D); could fail with a message saying "A equaled B but C did not equal D" which could be handy, though a C-style Assert macro that took a text argument for output if the condition failed, used twice could achieve this, Then need to adjust the texts when the conditions change is better handled by the compiler than the programmer.

        Can you think of (and preferably pseudo-code:) an application that you would like to use immediately if P5 woke up tomorrow and had grown a macro-processor?


        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


        Ok, I dont diasgree with your general points here. And I wasnt using VB as an example of good macro system. Just pointing out that it isn't a indication that a language is FSP. :-)

        One issue I have however is that I dont think many people would consider parse tree access a necessary feature of a macro langauge. Yes of course it makes a lot of sense, but I dont think that many people would instantly think of parse tree access if you mentioned macros to them. And to a certain extent I think that macros that do have this type of power arent really macros any more, but rather some part of the language that provides some behaviour (and more no doubt) that traditionally was left to a macro preprocessor. For instance, would you consider an inline sub to be a macro? Howabout a Template Class?

        My point here is that the use of macros for language extension is indiciative that the language is missing needed features at an integrated level. If LW and co want to provide a general solution that involves very macro like things that have oodles of power and flexibility then fine, but I think the term "macro" is a loaded one and using it when you really mean "macro like subroutines with introspective features such as parse tree access" is inclined to lead towards confusion.

        I think also that in general that macros arent used for language extension. I think more often than not they are used for inlining and conditional compilation. Consider Aristotle made some points about Assert(). This example however is only a combination of inlining and conditional compilation, and as far as a source filter goes wouldnt be that hard to write (with a few minor constraints). As for Templating Ala C++ Template Classes, this also isnt particularly difficult to do in perl (albeit a touch klunky).

        Granted that real language extension like Switch and try{}catch{}, is hard. But to me the issue with these is that they are missing at all, not that Perl is missing a sufficiently powerful mechanism to write them ourselves. While I personally think that providing a general extend the language mechanism with macro like features to be a powerful approach, I can only wonder what the result will be. For instance with(). I think that because LW for some reason doesnt like it (no doubt for good reasons), we will end up with a number of modules providing it with slightly different syntax. Likewise for other features the language is missing. Eventually we could find that this langauge extension facility actually undermines the cohesion of the overall codebase. (I have 5 Perl6 programs, and I need 40 different syntax extensions installed for them to compile because each one uses a different set.) I look forward to seeing what happens.


        ---
        demerphq

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://265084]
Front-paged by tye
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2014-08-01 23:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Who would be the most fun to work for?















    Results (52 votes), past polls