C macros are text substituation which is ran as a preprocessor and has a fairly simple and limited language (you could easily write your own code generator which is better, in most turing-complete language).
Lisp macros are code generators themselves. You run actual code which generates stuff for you at compile-time (which you can actually invoke at any time, even from your own program, unless you disabled that functionality for some reason). They can be seen as compiler-hooks which let you make code transformations before it is passed to the lower-level parts of the compiler.
Lisp macros are written in plain Lisp like any other pieces of code and they also output plain Lisp code and can contain macros themselves (and so on recursively - the macros are compiled as well).
You could of course use a different language to generate code for your favorite language, but you will have to do a lot more work and may have to work around various issues which you wouldn't if the language was designed to support that type of code generation from the start.
compiling lisp is stupid. If you want to optimize stuff for a compiler, just write C. I think if you're writing lisp you should be fully aware that you don't much care about performance. lisp machines lost. deal with it.
>>6,8
My Lisp code tends to be on average 2-4 times slower than the C version I would write and 10+ times shorter (most of the time). I think this is a very good trade-off for my needs. If I were to interpret it, it would be orders of magnitude slower. I tend not to use Lisp as a scripting language, but as a high-performance high-level language which lets me go low-level (it's a similar niche that SEPPLES attempts to fill, but unlike SEPPLES, my Lisp code is very generic and reusable, not to mention considerably easier to debug and maintain).
Making things hard to compile is inevitably the result of making them hard to understand. If you can't know whether something is a procedure call or a macro, you make it impossible to analyze not only for compilers but also for programmers.
>>10
idiot. The duality of syntax between macros and functions is a major thing in Common Lisp, which has second-class compiler-hook macros. It's actually what informs tons of designs in CL, like ((foo)) not being valid/funcall, lots about the CLOS works, the package system, etc.
your whole point is stupid anyway. Compilers don't think more like people do than interpreters do. I'd claim the opposite, actually.
>>11
High-performance interpreters are still slower than compilers, but they will perform better if you actually use some form of FEXPRs. I don't know much about picolisp, so I won't pretend to. I know my CL and R5RS Scheme inside-out, and am familiar with some other dialects, but that's about it.
What I meant by "perform better" basically means that a compiler + FEXPRs tends to mean really slow and crappy code (since you're forcefully invoking the compiler all the time at runtime). An interpreter will be faster since it doesn't have to run such heavy machinery at the sight of every FEXPR (it just interprets it). However, interpreters are SLOW, even the best ones are slow compared to running the code in a compiler, however if you're using FEXPRs, that means an interpreter is faster because a compiler would be constantly compiling stuff at runtime (instead of doing it once at runtime). If you're generating code all the time at runtime during your normal program operation, of course a compiler will be slower than an interpreter, but that's not how you write CL or Scheme, that's how you write *insert various very old purely interpreted Lisps and a few recent dialects derived from those concepts*.
Name:
Anonymous2011-09-06 3:51
Any LISP macro (regardless of type) just produce more pages of LISP code.
There is nothing magical and C code is faster than LISP. C macros are used to reduce code density, not to increase complexity of the language.
>>15 increase complexity
This is because your feeble mind cannot comprehend such ABSTRACT BULLSHITE, ergo, you will never be good at using C, Lisp, or any language for that matter.
Name:
Anonymous2011-09-06 12:41
>>15 C macros are used to reduce code density, not to increase complexity of the language.
no.
C macros are used for the same things Lisp macros are used for. They're just worse at all those purposes.
Name:
Anonymous2011-09-06 15:44
>>6
That's weird.
I thought SBCL compiled on the fly.
Name:
Anonymous2011-09-06 17:21
>>6
That's weird.
I thought SBCL compiled on the fly.