Comparing Lisp to Python, what you consider more important: speed or macros.
in [Lisp]
|
Prev: Comparing Lisp to Python, what you consider more important: speed or macros.
Next: Comparing Lisp to Python, what you consider more important:speed or macros.
From: Tim X on 29 Apr 2010 19:39 grucidipo <gruzcidol(a)yahoo.es> writes: > On 29 abr, 16:06, Nick Keighley <nick_keighley_nos...(a)hotmail.com> > wrote: >> On 28 Apr, 20:27, grucidipo <gruzci...(a)yahoo.es> wrote: >> >> > I find easier to program in Python than in Lisp, but Lisp has Macros >> > and it can optimise for speed. >> >> > Here are some subjective numbers: >> >> > Easy to program & Standard Library & Speed & Macros >> > or similar >> >> > Python: 0,8 0,8 0,5 0.4 >> > Lisp : 0,5 0,5 0,8 0,8 >> >> > I would like to know what weight other Lisper give to theses >> > factors. I know that it depend of what type of application you are >> > developing, but I am curious what other think about this. >> >> why did Python score 0.4 for macros? Does python have some sort of >> macro facility? > > Python has eval, so you could construct a macro using strings and > eval. There is not standard library for macros in Python, but I think > using eval is a good tool to build a library for using macros. The > point is that people using Python don't think macros are useful for > them, so I don't know any library for making macros with python. I suspect you are only seeing macros form a very basic limited dimension if you believe you can create a macro facility equivalent to CL macros using python's eval. There are many pwoerful things that you can do with macros that you simply cannot do with eval, som eof which are related to the fact that CL macros are evaluated at compile time and not run time. I don't believe true CL style macros are something that can be tacked onto a language. What you appear to be refering to are macros more along the lines of what other non-lisp languages have, which tend to be both more limited and more dangerous with the only thing in common with CL being their name You cold test this by going through Paul Graham's On Lisp and see if you can implement all the macros he talks about in that book using your python 'eval' based mechanism. I suspect all you will be able to do is an inefficient and difficult to debug approximation of some of the more basic examples. This would also be the reason why python programmers don't see the benfit of macros. If you are only seeing them as a basic convenience library on top of eval, you will likely see them as being just a bit of syntactic sugar that gets in the way of debugging. Tim -- tcross (at) rapttech dot com dot au
From: Tim Bradshaw on 30 Apr 2010 05:21 On 2010-04-29 19:44:15 +0100, grucidipo said: > Python has eval, so you could construct a macro using strings and > eval. There is not standard library for macros in Python, but I think > using eval is a good tool to build a library for using macros. The > point is that people using Python don't think macros are useful for > them, so I don't know any library for making macros with python. C environments have effectively-standard libraris which support I/O, calling external programs such as a C compiler, and dynamic linking. Does this mean C has macros? Are there language implementations which do not have macros in this stupid sense?
From: Tim Bradshaw on 1 May 2010 08:56 On 2010-05-01 06:18:50 +0100, Scott L. Burson said: > It is also absolutely the case that people can go crazy with macros > just as they can go crazy with, say, operator overloading. I've > definitely heard, over the years, of instances where this has > occurred. While well-designed macros can very much improve > readability of code (as others here have pointed out), poorly-designed > ones can make a real mess. I think an important point is that, while you can clearly produce well-designed languages with macros, it's hard to do anything good with operator overloading. The reason for that is that there is some fixed, finite set of operators, so you unless what you want to do is very like what they are already used for, you end up with all sorts of weirdness (using the bit-shift operator to do I/O for instance). It's rather as if CL had 20 or 30 different generic functions, but you could never define more, you just had to define new methods on the existing ones. That would suck as a language design.
From: J Kenneth King on 3 May 2010 12:36 "Scott L. Burson" <gyro(a)zeta-soft.com> writes: > On Apr 29, 6:42 am, J Kenneth King <ja...(a)agentultra.com> wrote: >> grucidipo <gruzci...(a)yahoo.es> writes: >> > I agree, macros are a big win, but the problem I see is that they are >> > not easy to standardise, you can construct a new language with macros >> > and for others reading your code can be difficult. >> >> I cannot abide the "construct a new language" argument. >> >> Macros are a part of Lisp. They don't modify the language of Lisp. >> They don't create new languages inside of Lisp. n> > Oh, I beg to differ. (And I'm very surprised no one else has > challenged this.) How many conversations have we had here about using > macros to create domain-specific languages? I did that myself just a > few months ago -- used macros to create a specialized variant of CL > for use in my pet AI project -- it has firstclass continuations and > some other stuff. > > It is also absolutely the case that people can go crazy with macros > just as they can go crazy with, say, operator overloading. I've > definitely heard, over the years, of instances where this has > occurred. While well-designed macros can very much improve > readability of code (as others here have pointed out), poorly-designed > ones can make a real mess. > > Power can always be misused. The question is whether we refuse it, or > learn to use it well. > > -- Scott It is a matter of logical perspective I was trying to get at. You are right in every sense. However, I don't think that distinction was being made. The poster I was responding to stated that macros can construct a new language. This statement has some logical inconsistencies. Macros are a part of the ontology of Lisp. When you program using macros, you're not programming in new language that is no longer Lisp. Therefore the poster's statement is false.
From: Peter Keller on 3 May 2010 12:58
J Kenneth King <james(a)agentultra.com> wrote: > grucidipo <gruzcidol(a)yahoo.es> writes: [snip] > I cannot abide the "construct a new language" argument. > > Macros are a part of Lisp. They don't modify the language of Lisp. > They don't create new languages inside of Lisp. So, here's a question: Using macros, can one implement a reasonable syntactic and semantic subset of python? (And I don't just mean writing a python compiler in lisp, but using lisp to change its own definition). Or does one mean "construct a new language" as a DSL in the lisp syntax? -pete |