DenkzeitWiki

Suchen:

Aktuelle Änderungen Printable View Änderungen Bearbeiten

Python3000 > SourceSafe > Middleware > Reflection > ReflectionAndIntrospection > ActorModel > Namespaces > JavaScript > BruceEckel > CheeseShop > Terracotta > PythonIDEs > LispMacrosClear Trail
Main /

Lisp Macros

GrowingALanguage

HygienicMacros
ClojureMacros

Lisp
Homoiconicity

CodeGeneration
DSL
LispForDsls
BottomUpProgramming

LazyEvaluation

AbstractSyntaxTrees

Lisp macros are a full-fledged code-generation system, while C #define macros are simple string substitutions.


In other words, with macros you can tailor the language to do exactly what you want to do, in a single command. Without macros the best you can do is neatly arrange stock language constructs to map more or less closely to what you are trying to do.


Macros are just another way to write something once, and use it over and over again.[1]


Macros are like metaprogramming at compile time (or interpretation-time—Lisp lets you decide if you want to compile the code first or not).




 -> Lisp macros allow the abstraction of special forms.




I don't like macros any more. I'm right. Everyone who disagrees with me is wrong. End of story. [2]













Preprocessors

  1. Lexical (C, C++, ...)
  2. Syntactical (Lisp, OCaml, ...)
    1. AbstractSyntaxTrees

Macros and Functions

  1. Parameters of a macro don't get evaluated before being passed to the macro
  2. The macro is expanded to lisp-forms. Which are then evaluated.

The consensus on the ll1 thread seemed to be that macros and functions aren't very different, except that macros can be more convenient--until Steele came up with a couple macros that depended on having access to the lexical form of the code body. Macros that symbolically differentiated the function being computed, for example.[3]



Edit - BackLinks - Tags - Page Hist - Print - Changes - Home - Orphans - Help

Zuletzt geändert am 30.12.2011 20:10 Uhr und seit 7. April 2005 2589 aufgerufen.