> > > : This returns a list of all the lines in a file that have some property.
> > > OK, that's _definitely_ just a filter: filter someproperty somefilename > > > Perhaps throw in a fold if you are trying to abstract "collect".
> > The net effect is a filter, but again, you need to stop thinking about the > > "what" and start thinking about the "how", otherwise, as I said, there's > > no reason to use anything other than machine language.
> Answer 1: literal translation into Python. The closest analogue of > with-collector etc would be Python's simple generators (yield keyword) > and do-with-file-lines is expressed in python with a for loop. So:
> def lines_with_some_property(some_file_name): > for l in some_file_name: > if some_property(l): > yield l
You left out the with-collector part.
But it's true that my examples are less convincing given the existence of yield (which I had forgotten about). But the point is that in pre-yield Python you were stuck until the langauge designers got around to adding it.
I'll try to come up with a more convincing short example if I find some free time today.
Joe Marshall <j...@ccs.neu.edu> writes: > You're missing the point. Suppose Erann and I were working on some > project and he had written the above macro. I don't have to know > the details of implementation (I'm assuming that I can trust Erann > not to write bogus code). Using the macro is *far* preferable to > something like:
Peter Seibel <pe...@javamonkey.com> writes: > Joe Marshall <j...@ccs.neu.edu> writes:
>> You're missing the point. Suppose Erann and I were working on some >> project and he had written the above macro. I don't have to know >> the details of implementation (I'm assuming that I can trust Erann >> not to write bogus code). Using the macro is *far* preferable to >> something like:
David Rush <dr...@aol.net> writes: > On Mon, 06 Oct 2003, Raymond Wiker <Raymond.Wi...@fast.no> wrote: >> Matthias <n...@spam.pls> writes: >>> (In certain cases macros) can easily be misused. > ... >>> You have to know if you want a sharp knife (which may hurt you when >>> misused) or a less sharper one (where it takes more effort to cut >>> with).
>> It is easier to hurt yourself with a blunt knife than a sharp >> one.
> Actually I've noticed that I usually cut myself when I *switch* from > a dull knife to a sharp one.
Grasp the sharp knife by the *handle* when switching.
gr...@cs.uwa.edu.au wrote in message <news:blr1cq$bb1$1@enyo.uwa.edu.au>... > In comp.lang.functional Erann Gat <my-first-name.my-last-n...@jpl.nasa.gov> wrote: > :> I can't see why a LISP programmer would even want to write a macro. > : That's because you are approaching this with a fundamentally flawed > : assumption. Macros are mainly not used to make the syntax prettier > : (though they can be used for that). They are mainly used to add features > : to the language that cannot be added as functions.
> Really? Turing-completeness and all that... I presume you mean "cannot > so easily be added as functions", but even that would surprise me. > (Unless you mean cannot be added _to_Lisp_ as functions, because I don't > know as much as I'd like to about Lisp's capabilities and limitations.)
Two words: code duplication.
Yes, anything that can be done with macros can also be done with functions, but if you do it with functions, you will end up with more code, and that code will be duplicated in every single source location in which that abstraction it utilized.
With a macro, the abstraction is defined once, and the source code reflects that abstraction everywhere that abstraction is used throughout your program. For large projects this could be hundreds of source locations.
Without a macro, you have multiple points of maintenance. If your abstraction changes, you have to edit scores or hundreds of source locations. With a macro, you redefine a single form, in one source location, and recompile the dependent code.
All turing complete languages are computationally equivalent. That doesn't mean you'll see me programming by punching holes in a paper tape any time soon though.
Finally, there is one thing that macros can do that ordinary functions cannot do easily - change the language's rules for functional evaluation. This can only be accomplished with functions if you're willing to write a set of functions that defer evaluation, by, say parsing input, massaging it appropriately, and then passing it to the compiler. At that point, however, you've just written your own macro system, and invoked Greenspun's 10th Law.
Peter Seibel <pe...@javamonkey.com> writes: > Joe Marshall <j...@ccs.neu.edu> writes:
> > You're missing the point. Suppose Erann and I were working on some > > project and he had written the above macro. I don't have to know > > the details of implementation (I'm assuming that I can trust Erann > > not to write bogus code). Using the macro is *far* preferable to > > something like:
David Rush <dr...@aol.net> writes: > On Mon, 06 Oct 2003, Raymond Wiker <Raymond.Wi...@fast.no> wrote: > > Matthias <n...@spam.pls> writes: > >> (In certain cases macros) can easily be misused. > ... > >> You have to know if you want a sharp knife (which may hurt you when > >> misused) or a less sharper one (where it takes more effort to cut > >> with).
> > It is easier to hurt yourself with a blunt knife than a sharp > > one.
> Actually I've noticed that I usually cut myself when I *switch* from > a dull knife to a sharp one.
I don't think the truism about cutting yourself with dull vs sharp knives means to say anything about superficial cuts. You don't lop your finger off with a sharp knife, because you're handling it carefully. With a dull knife, your best bet is to put your weight behind it; that's also a good way to lose a finger / dump core.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> > > > : This returns a list of all the lines in a file that have some property.
> > > > OK, that's _definitely_ just a filter: filter someproperty somefilename > > > > Perhaps throw in a fold if you are trying to abstract "collect".
> > > The net effect is a filter, but again, you need to stop thinking about the > > > "what" and start thinking about the "how", otherwise, as I said, there's > > > no reason to use anything other than machine language.
> > Answer 1: literal translation into Python. The closest analogue of > > with-collector etc would be Python's simple generators (yield keyword) > > and do-with-file-lines is expressed in python with a for loop. So:
> > def lines_with_some_property(some_file_name): > > for l in some_file_name: > > if some_property(l): > > yield l
> You left out the with-collector part.
> But it's true that my examples are less convincing given the existence of > yield (which I had forgotten about). But the point is that in pre-yield > Python you were stuck until the langauge designers got around to adding > it.
> I'll try to come up with a more convincing short example if I find some > free time today.
I'm afraid it's very hard to give any convincing examples of the utility of macros -- as long as you are sticking to trivial examples. On the other hand, you can't exactly post real world complex examples of how macros saved you time and LOC (we all have em) because reader's eyes would just glaze over. I think macros are just another one of CL's features that some most people just don't get until they actually use them. But here's a small one:
I wrote about 60 lines worth of macro based code (including a few reader macros) that allows me to write things like:
(with-dbconnection (sql-loop-in-rows "select col1, col2 from somewhere where something" :my-package row-var "pfx" ... ...some code... ...))
In the "some code" section, the result columns' values are accessed by #!pfx-colname (eg #!pfx-col1), or directly from row-var using #?pfx-colname (which returns the position). Also, error handling code can be automatically included by the macro code. How much time and effort (and possible bugs) has this saved me? Well at least 60+ lines or more of boilerplate every time I use this pattern.. Plus the expansions for #!colname include error checks/warnings etc. -- all hidden from view.
In article <llry2m99....@ccs.neu.edu>, Joe Marshall <j...@ccs.neu.edu> writes:
> ... > Freedom, horrible freedom! It so much harder to think than it is to > let other people do it for you.
reminds me of an argument an intel guy (probably sales) put forward in SIGPLAN in praise of the 8086 architecture (shortly after this abomination was introduced): he argued that instructions requiring their operands relieves programmers (and compilers) from the burden of having to chose registers
