Hubbry Logo
Macro (computer science)Macro (computer science)Main
Open search
Macro (computer science)
Community hub
Macro (computer science)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Macro (computer science)
Macro (computer science)
Macro (computer science)
View on Wikipedia
from Wikipedia
jEdit's macro editor

In computer programming, a macro (short for "macro instruction"; from Greek μακρο- 'long, large'[1]) is a rule or pattern that specifies how a certain input should be mapped to a replacement output. Applying a macro to an input is known as macro expansion.

The input and output may be a sequence of lexical tokens or characters, or a syntax tree. Character macros are supported in software applications to make it easy to invoke common command sequences. Token and tree macros are supported in some programming languages to enable code reuse or to extend the language, sometimes for domain-specific languages.

Macros are used to make a sequence of computing instructions available to the programmer as a single program statement, making the programming task less tedious and less error-prone.[2][3] Thus, they are called "macros" because a "big" block of code can be expanded from a "small" sequence of characters. Macros often allow positional or keyword parameters that dictate what the conditional assembler program generates and have been used to create entire programs or program suites according to such variables as operating system, platform or other factors. The term derives from "macro instruction", and such expansions were originally used in generating assembly language code.

Keyboard and mouse macros

[edit]

Keyboard macros and mouse macros allow short sequences of keystrokes and mouse actions to transform into other, usually more time-consuming, sequences of keystrokes and mouse actions. In this way, frequently used or repetitive sequences of keystrokes and mouse movements can be automated. Separate programs for creating these macros are called macro recorders.

During the 1980s, macro programs – originally SmartKey, then SuperKey, KeyWorks, Prokey – were very popular, first as a means to automatically format screenplays, then for a variety of user-input tasks. These programs were based on the terminate-and-stay-resident mode of operation and applied to all keyboard input, no matter in which context it occurred. They have to some extent fallen into obsolescence following the advent of mouse-driven user interfaces and the availability of keyboard and mouse macros in applications, such as word processors and spreadsheets, making it possible to create application-sensitive keyboard macros.

Keyboard macros can be used in massively multiplayer online role-playing games (MMORPGs) to perform repetitive, but lucrative tasks, thus accumulating resources. As this is done without human effort, it can skew the economy of the game. For this reason, use of macros is a violation of the TOS or EULA of most MMORPGs, and their administrators spend considerable effort to suppress them.[4]

Application macros and scripting

[edit]

Keyboard and mouse macros that are created using an application's built-in macro features are sometimes called application macros. They are created by carrying out the sequence once and letting the application record the actions. An underlying macro programming language, most commonly a scripting language, with direct access to the features of the application may also exist.

The programmers' text editor Emacs (short for "editing macros") follows this idea to a conclusion. In effect, most of the editor is made of macros. Emacs was originally devised as a set of macros in the editing language TECO; it was later ported to dialects of Lisp.

Another programmers' text editor, Vim (a descendant of vi), also has an implementation of keyboard macros. It can record into a register (macro) what a person types on the keyboard and it can be replayed or edited just like VBA macros for Microsoft Office. Vim also has a scripting language called Vimscript[5] to create macros.

Visual Basic for Applications (VBA) is a programming language included in Microsoft Office from Office 97 through Office 2019 (although it was available in some components of Office prior to Office 97). However, its function has evolved from and replaced the macro languages that were originally included in some of these applications.

XEDIT, running on the Conversational Monitor System (CMS) component of VM, supports macros written in EXEC, EXEC2 and REXX, and some CMS commands were actually wrappers around XEDIT macros. The Hessling Editor (THE), a partial clone of XEDIT, supports Rexx macros using Regina and Open Object REXX (oorexx). Many common applications, and some on PCs, use Rexx as a scripting language.

Macro virus

[edit]
Main article: Macro virus (computing)

VBA has access to most Microsoft Windows system calls and executes when documents are opened. This makes it relatively easy to write computer viruses in VBA, commonly known as macro viruses. In the mid-to-late 1990s, this became one of the most common types of computer virus. However, during the late 1990s and to date, Microsoft has been patching and updating its programs.[citation needed] In addition, current anti-virus programs immediately counteract such attacks.

Parameterized and parameterless macro

[edit]

A parameterized macro is a macro that is able to insert given objects into its expansion. This gives the macro some of the power of a function.

As a simple example, in the C programming language, this is a typical macro that is not a parameterized macro, i.e., a parameterless macro: 

 #define PI   3.14159

This causes PI to always be replaced with 3.14159 wherever it occurs. An example of a parameterized macro, on the other hand, is this: 

 #define pred(x)  ((x)-1)

What this macro expands to depends on what argument x is passed to it. Here are some possible expansions: 

 pred(2)    →  ((2)   -1)
 pred(y+2)  →  ((y+2) -1)
 pred(f(5)) →  ((f(5))-1)

Parameterized macros are a useful source-level mechanism for performing in-line expansion, but in languages such as C where they use simple textual substitution, they have a number of severe disadvantages over other mechanisms for performing in-line expansion, such as inline functions.

The parameterized macros used in languages such as Lisp, PL/I and Scheme, on the other hand, are much more powerful, able to make decisions about what code to produce based on their arguments; thus, they can effectively be used to perform run-time code generation.

Text-substitution macros

[edit]
See also: General-purpose macro processor, Assembly language § Macros, and Algorithm

Languages such as C and some assembly languages have rudimentary macro systems, implemented as preprocessors to the compiler or assembler. C preprocessor macros work by simple textual substitution at the token, rather than the character level. However, the macro facilities of more sophisticated assemblers, e.g., IBM High Level Assembler (HLASM) can't be implemented with a preprocessor; the code for assembling instructions and data is interspersed with the code for assembling macro invocations.

A classic use of macros is in the computer typesetting system TeX and its derivatives, where most functionality is based on macros.[6]

MacroML is an experimental system that seeks to reconcile static typing and macro systems. Nemerle has typed syntax macros, and one productive way to think of these syntax macros is as a multi-stage computation.

Other examples:

Some major applications have been written as text macro invoked by other applications, e.g., by XEDIT in CMS.

Embeddable languages

[edit]

Some languages, such as PHP, can be embedded in free-format text, or the source code of other languages. The mechanism by which the code fragments are recognised (for instance, being bracketed by <?php and ?>) is similar to a textual macro language, but they are much more powerful, fully featured languages.

Procedural macros

[edit]

Macros in the PL/I language are written in a subset of PL/I itself: the compiler executes "preprocessor statements" at compilation time, and the output of this execution forms part of the code that is compiled. The ability to use a familiar procedural language as the macro language gives power much greater than that of text substitution macros, at the expense of a larger and slower compiler. Macros in PL/I, as well as in many assemblers, may have side effects, e.g., setting variables that other macros can access.

Frame technology's frame macros have their own command syntax but can also contain text in any language. Each frame is both a generic component in a hierarchy of nested subassemblies, and a procedure for integrating itself with its subassembly frames (a recursive process that resolves integration conflicts in favor of higher level subassemblies). The outputs are custom documents, typically compilable source modules. Frame technology can avoid the proliferation of similar but subtly different components, an issue that has plagued software development since the invention of macros and subroutines.

Most assembly languages have less powerful procedural macro facilities, for example allowing a block of code to be repeated N times for loop unrolling; but these have a completely different syntax from the actual assembly language.

Syntactic macros

[edit]

Macro systems—such as the C preprocessor described earlier—that work at the level of lexical tokens cannot preserve the lexical structure reliably. Syntactic macro systems work instead at the level of abstract syntax trees, and preserve the lexical structure of the original program. The most widely used implementations of syntactic macro systems are found in Lisp-like languages. These languages are especially suited for this style of macro due to their uniform, parenthesized syntax (known as S-expressions). In particular, uniform syntax makes it easier to determine the invocations of macros. Lisp macros transform the program structure itself, with the full language available to express such transformations. While syntactic macros are often found in Lisp-like languages, they are also available in other languages such as Prolog,[7] Erlang,[8] Dylan,[9] Scala,[10] Nemerle,[11] Rust,[12] Elixir,[13] Nim,[14] Haxe,[15] and Julia.[16] They are also available as third-party extensions to JavaScript[17] and C#.[18]

Early Lisp macros

[edit]

Before Lisp had macros, it had so-called FEXPRs, function-like operators whose inputs were not the values computed by the arguments but rather the syntactic forms of the arguments, and whose output were values to be used in the computation. In other words, FEXPRs were implemented at the same level as EVAL, and provided a window into the meta-evaluation layer. This was generally found to be a difficult model to reason about effectively.[19]

In 1963, Timothy Hart proposed adding macros to Lisp 1.5 in AI Memo 57: MACRO Definitions for LISP.[20]

Anaphoric macros

[edit]
Main article: Anaphoric macro

An anaphoric macro is a type of programming macro that deliberately captures some form supplied to the macro which may be referred to by an anaphor (an expression referring to another). Anaphoric macros first appeared in Paul Graham's On Lisp and their name is a reference to linguistic anaphora—the use of words as a substitute for preceding words.

Hygienic macros

[edit]
Main article: Hygienic macro

In the mid-eighties, a number of papers[21][22] introduced the notion of hygienic macro expansion (syntax-rules), a pattern-based system where the syntactic environments of the macro definition and the macro use are distinct, allowing macro definers and users not to worry about inadvertent variable capture (cf. referential transparency). Hygienic macros have been standardized for Scheme in the R5RS, R6RS, and R7RS standards. A number of competing implementations of hygienic macros exist such as syntax-rules, syntax-case, explicit renaming, and syntactic closures. Both syntax-rules and syntax-case have been standardized in the Scheme standards.

Recently, Racket has combined the notions of hygienic macros with a "tower of evaluators", so that the syntactic expansion time of one macro system is the ordinary runtime of another block of code,[23] and showed how to apply interleaved expansion and parsing in a non-parenthesized language.[24]

A number of languages other than Scheme either implement hygienic macros or implement partially hygienic systems. Examples include Scala, Rust, Elixir, Julia, Dylan, Nim, and Nemerle.

Applications

[edit]
Evaluation order
Macro systems have a range of uses. Being able to choose the order of evaluation (see lazy evaluation and non-strict functions) enables the creation of new syntactic constructs (e.g. control structures) indistinguishable from those built into the language. For instance, in a Lisp dialect that has cond but lacks if, it is possible to define the latter in terms of the former using macros. For example, Scheme has both continuations and hygienic macros, which enables a programmer to design their own control abstractions, such as looping and early exit constructs, without the need to build them into the language.
Data sub-languages and domain-specific languages
Next, macros make it possible to define data languages that are immediately compiled into code, which means that constructs such as state machines can be implemented in a way that is both natural and efficient.[25]
Binding constructs
Macros can also be used to introduce new binding constructs. The most well-known example is the transformation of let into the application of a function to a set of arguments.

Felleisen conjectures[26] that these three categories make up the primary legitimate uses of macros in such a system. Others have proposed alternative uses of macros, such as anaphoric macros in macro systems that are unhygienic or allow selective unhygienic transformation.

The interaction of macros and other language features has been a productive area of research. For example, components and modules are useful for large-scale programming, but the interaction of macros and these other constructs must be defined for their use together. Module and component-systems that can interact with macros have been proposed for Scheme and other languages with macros. For example, the Racket language extends the notion of a macro system to a syntactic tower, where macros can be written in languages including macros, using hygiene to ensure that syntactic layers are distinct and allowing modules to export macros to other modules.

Macros for machine-independent software

[edit]

Macros are normally used to map a short string (macro invocation) to a longer sequence of instructions. Another, less common, use of macros is to do the reverse: to map a sequence of instructions to a macro string. This was the approach taken by the STAGE2 Mobile Programming System, which used a rudimentary macro compiler (called SIMCMP) to map the specific instruction set of a given computer into machine-independent macros. Applications (notably compilers) written in these machine-independent macros can then be run without change on any computer equipped with the rudimentary macro compiler. The first application run in such a context is a more sophisticated and powerful macro compiler, written in the machine-independent macro language. This macro compiler is applied to itself, in a bootstrap fashion, to produce a compiled and much more efficient version of itself. The advantage of this approach is that complex applications can be ported from one computer to a very different computer with very little effort (for each target machine architecture, just the writing of the rudimentary macro compiler).[27][28] The advent of modern programming languages, notably C, for which compilers are available on virtually all computers, has rendered such an approach superfluous. This was, however, one of the first instances (if not the first) of compiler bootstrapping.

Assembly language

[edit]

While macro instructions can be defined by a programmer for any set of native assembler program instructions, typically macros are associated with macro libraries delivered with the operating system allowing access to operating system functions such as

  • peripheral access by access methods (including macros such as OPEN, CLOSE, READ and WRITE)
  • operating system functions such as ATTACH, WAIT and POST for subtask creation and synchronization.[29] Typically such macros expand into executable code, e.g., for the EXIT macroinstruction,
  • a list of define constant instructions, e.g., for the DCB macro—DTF (Define The File) for DOS[30]—or a combination of code and constants, with the details of the expansion depending on the parameters of the macro instruction (such as a reference to a file and a data area for a READ instruction);
  • the executable code often terminated in either a branch and link register instruction to call a routine, or a supervisor call instruction to call an operating system function directly.
  • Generating a Stage 2 job stream for system generation in, e.g., OS/360. Unlike typical macros, sysgen stage 1 macros do not generate data or code to be loaded into storage, but rather use the PUNCH statement to output JCL and associated data.

In older operating systems such as those used on IBM mainframes, full operating system functionality was only available to assembler language programs, not to high level language programs (unless assembly language subroutines were used, of course), as the standard macro instructions did not always have counterparts in routines available to high-level languages.

History

[edit]

In the mid-1950s, when assembly language programming was the main way to program a computer, macro instruction features were developed to reduce source code (by generating multiple assembly statements from each macro instruction) and to enforce coding conventions (e.g. specifying input/output commands in standard ways).[31] A macro instruction embedded in the otherwise assembly source code would be processed by a macro compiler, a preprocessor to the assembler, to replace the macro with one or more assembly instructions. The resulting code, pure assembly, would be translated to machine code by the assembler.[32]

Two of the earliest programming installations to develop macro languages for the IBM 705 computer were at Dow Chemical Corp. in Delaware and the Air Material Command, Ballistics Missile Logistics Office in California.

Some consider macro instructions as an intermediate step between assembly language programming and the high-level programming languages that followed, such as FORTRAN and COBOL.

By the late 1950s the macro language was followed by the Macro Assemblers. This was a combination of both where one program served both functions, that of a macro pre-processor and an assembler in the same package.[32][failed verification] Early examples are FORTRAN Assembly Program (FAP)[33] and Macro Assembly Program (IBMAP)[34] on the IBM 709, 7094, 7040 and 7044, and Autocoder[35] on the 7070/7072/7074.

In 1959, Douglas E. Eastwood and Douglas McIlroy of Bell Labs introduced conditional and recursive macros into the popular SAP assembler,[36] creating what is known as Macro SAP.[37] McIlroy's 1960 paper was seminal in the area of extending any (including high-level) programming languages through macro processors.[38][36]

Macro Assemblers allowed assembly language programmers to implement their own macro-language and allowed limited portability of code between two machines running the same CPU but different operating systems, for example, early versions of MS-DOS and CP/M-86. The macro library would need to be written for each target machine but not the overall assembly language program. Note that more powerful macro assemblers allowed use of conditional assembly constructs in macro instructions that could generate different code on different machines or different operating systems, reducing the need for multiple libraries.[citation needed]

In the 1980s and early 1990s, desktop PCs were only running at a few MHz and assembly language routines were commonly used to speed up programs written in C, Fortran, Pascal and others. These languages, at the time, used different calling conventions. Macros could be used to interface routines written in assembly language to the front end of applications written in almost any language. Again, the basic assembly language code remained the same, only the macro libraries needed to be written for each target language.[citation needed]

In modern operating systems such as Unix and its derivatives, operating system access is provided through subroutines, usually provided by dynamic libraries. High-level languages such as C offer comprehensive access to operating system functions, obviating the need for assembler language programs for such functionality.[citation needed]

Moreover, standard libraries of several newer programming languages, such as Go, actively discourage the use of syscalls in favor of platform-agnostic libraries as well if not necessary, to improve portability and security.[39]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Macro (computer science)

View on Grokipedia
from Grokipedia
In , a macro is a rule or pattern that specifies how a certain input sequence—often a sequence of characters, , or syntactic elements in —is mapped to a replacement output, enabling programmers to define abstractions, automate repetitive tasks, and extend programming languages without altering the core or interpreter. Macros originated in the early days of computing during the 1950s, with initial implementations in assembly languages to simplify the writing of repetitive machine instructions; , a pioneering computer scientist, proposed that macro languages should be independent of the host programming language to enhance flexibility. By the 1960s, macro processors had evolved into more sophisticated tools, such as Christopher Strachey's General Purpose Macrogenerator (GPM) for the Atlas computer, which itself was implemented in only 250 machine instructions and could generate full programs, and Doug McIlroy's work at on macro techniques for higher-level languages. This evolution continued into the 1970s with systems like M6 and m4, the latter developed by and as a general-purpose macro processor still in use today. Macros are broadly classified into two main types: textual macros, which perform simple string substitution before compilation, and syntactic macros, which operate on the to enable more powerful code transformations. Textual macros, exemplified by the , include object-like macros that resemble constants (e.g., #define PI 3.14159) and function-like macros that mimic functions (e.g., #define MAX(a,b) ((a) > (b) ? (a) : (b))), where the replaces the macro name with its expansion to reduce code duplication and improve readability. In contrast, syntactic macros, prominent in languages like and Scheme, treat macros as functions that manipulate syntax during compilation, allowing programmers to create domain-specific languages or new control structures, such as defining a while loop in a functional . Modern languages continue to leverage macros for —writing that generates other —with Rust's declarative and procedural macros enabling traits like automatic derivation of methods (e.g., #[derive(Debug)]), and similar features in languages like and Julia for enhancing expressiveness and performance. While macros offer benefits like conciseness and portability across , they can introduce challenges such as difficulties due to expansion opacity and potential for unintended side effects in function-like forms. Overall, macros remain a foundational tool for language extensibility, influencing design and practices.

Fundamentals

Definition and Purpose

In computer science, a macro is a rule or pattern that specifies how a certain input sequence, such as a command or code snippet, should be mapped to an output sequence, such as expanded instructions, with the expansion automated during compilation, interpretation, or execution. This mechanism allows for the abstraction of repetitive or complex operations into simpler invocations, treating the macro as a shorthand for the underlying sequence. The primary purposes of macros include reducing tedium in programming or user tasks by automating repetitive actions, enabling abstraction for complex operations that would otherwise require verbose code, and facilitating code reuse and portability across different contexts. For instance, macros can shorten verbose code in languages like C by defining constants or inline expressions, or automate user interface actions such as sequences of keystrokes in applications. Keyboard macros serve as a simple example of this in user applications, while syntactic macros enable advanced code transformations in languages like Lisp. Macros offer benefits such as improved programmer productivity through reduced manual repetition, enhanced code readability by hiding implementation details, and better via modular abstractions that promote reuse. However, they introduce trade-offs, including potential errors during expansion that can lead to subtle bugs, challenges in due to the pre-compilation substitution process, and increased code size from inlining, which may complicate optimization. The general workflow of a macro involves three key stages: definition, where the mapping rule is specified (e.g., via a directive like #define ); invocation, where the macro name is used in the source code as a placeholder; and expansion, where the processor or interpreter replaces the with the corresponding output sequence, often performing substitutions for parameters if applicable. This process occurs before full compilation or execution, ensuring the expanded code integrates seamlessly into the program.

Classification of Macros

Macros in computer science are broadly classified into several primary categories based on their mechanisms and application domains. macros, such as keyboard and mouse macros, automate sequences of input actions like keystrokes or cursor movements, operating at a low level to simulate device interactions across applications without requiring deep integration with the host software. In contrast, textual macros perform simple text-substitution, replacing predefined patterns with fixed or parameterized strings during preprocessing, as seen in macros where mnemonic abbreviations expand to machine instructions. Syntactic macros extend this by transforming the (AST) of , enabling structure-aware modifications that preserve program semantics, while procedural macros go further by executing arbitrary to generate or manipulate program fragments dynamically. Within these categories, macros can be further distinguished by scope and . Parameterless macros involve fixed expansions without inputs, suitable for constant substitutions, whereas parameterized macros accept arguments to enable reusable, context-dependent transformations. addresses variable binding: hygienic macros isolate generated identifiers to prevent unintended name capture in the surrounding code, promoting safer expansions, in opposition to anaphoric macros that deliberately share lexical context for more expressive but riskier integrations. Hybrid forms arise in embeddable languages, where macros integrate seamlessly with the host language's runtime or compilation environment, allowing code generation that blends macro expansion with interpreted or compiled execution. Key distinctions among macro types include expansion timing—runtime for dynamic adaptation in macros, versus compile-time for textual and syntactic macros to optimize performance—and power level, ranging from basic replacement in textual macros to (DSL) extension in procedural ones.

User Interface and Application Macros

Keyboard and Mouse Macros

Keyboard and mouse macros consist of recorded sequences of keystrokes, mouse clicks, movements, or drags that can be replayed on demand to automate repetitive interactions with graphical (GUIs). These macros simulate input at the device level, capturing and reproducing actions such as text, navigating menus, or performing precise cursor operations without requiring direct code-level intervention. Unlike higher-level scripting, they focus on low-level input events, making them accessible for non-programmers to handle routine UI tasks efficiently. Implementation typically involves either direct recording of user actions or scripted definitions using specialized tools. For instance, , a free open-source scripting language for Windows (current version v2.0.19 as of January 2025), enables users to create macros by recording inputs via add-ons like Pulover's Macro Creator or by writing simple scripts that send simulated keystrokes and mouse events to target windows. On Windows, the Microsoft Mouse and Keyboard Center supports macro recording directly within its interface, allowing users to assign sequences to programmable hardware buttons on compatible mice and keyboards, with playback triggered by hardware presses. In macOS, Automator's "Watch Me Do" action provides a built-in recording mode that captures mouse and keyboard events during a demonstration, compiling them into a replayable that can be triggered via shortcuts or schedules. On Linux, tools like AutoKey allow similar recording and playback of keyboard and mouse events using Python scripting. These tools often support two modes: direct capture, which records raw events for exact replay, and scripted modes, which allow editing for conditional logic or loops. Common use cases span gaming, productivity, and accessibility applications. In gaming, macros bind complex sequences—such as rapid-fire key combinations or coordinated mouse movements—to a single trigger, enabling players to execute intricate maneuvers without manual repetition. For productivity, they automate form filling in applications like web browsers or office software, where a macro might simulate tabbing through fields and entering predefined data to streamline data entry tasks. In accessibility scenarios, macros simplify interactions for users with motor impairments by mapping multi-step gestures to single inputs, such as replacing a series of clicks and drags with one keystroke to enhance usability in standard GUIs. Despite their utility, keyboard and macros face limitations related to hardware dependencies and adaptability. They are inherently tied to specific operating systems and input devices, often failing across platforms or with varying screen resolutions due to absolute coordinate reliance in recordings. Moreover, they struggle with dynamic interfaces where UI elements shift, such as in responsive web pages, requiring manual scripting extensions for robustness against changes like window resizing or layout updates. These constraints highlight the need for hybrid approaches combining recording with visual or structural UI recognition for more reliable .

Application Macros and Scripting

Application macros and scripting refer to programmable sequences defined within specific software applications using their built-in APIs or dedicated s to automate complex workflows and tasks. These macros go beyond simple recordings by allowing users to write custom code that interacts directly with the application's object model, enabling manipulation of data, user interfaces, and internal states. For instance, in spreadsheet software like , (VBA) serves as the primary , embedded within the Office suite to create macros that perform calculations, format data, or generate reports programmatically. Similarly, applications such as Photoshop and InDesign utilize ExtendScript, an extension of , to script operations like batch image processing or document layout automation. Implementation of application macros typically involves event-driven scripting, where code responds to user actions, application events, or triggers such as file openings or button clicks. Developers access the application's GUI elements through object-oriented APIs, allowing scripts to read, modify, or create components like worksheets in Excel or layers in . In integrated development environments (IDEs), scripting consoles provide similar capabilities; for example, IntelliJ IDEA's IDE Scripting Console uses languages like or Kotlin to automate refactoring, code generation, or project inspections without developing full plugins. Macros are often stored in dedicated files—such as .bas modules in VBA or .jsx files in ExtendScript—and can be executed via menus, keyboard shortcuts, or automated schedules, integrating seamlessly with the host application's runtime environment. These macros offer significant advantages through their context-aware nature, adapting to the current state of the application, such as dynamic data ranges in a or selected objects in a . Extensibility is a key benefit, as scripting supports control structures like loops, conditional statements, and handling, enabling sophisticated that scales with user needs—for example, VBA scripts can loop through thousands of rows to apply conditional formatting, while ExtendScript can iterate over image batches for resizing and exporting. This integration also facilitates inter-application communication, such as transferring data between Excel and Outlook or coordinating actions across apps via BridgeTalk messaging. Overall, they enhance productivity by reducing manual effort in repetitive tasks and allowing customization tailored to domain-specific workflows. Despite these benefits, application macros and scripting present challenges, particularly , where reliance on proprietary APIs ties users to a specific software , complicating migrations to alternative tools due to incompatible scripting syntax or object models. Maintenance issues arise as application updates frequently alter APIs or behaviors, requiring script revisions to ensure compatibility; for instance, VBA macros developed for older Excel versions may fail in newer releases without adjustments. Security restrictions further complicate deployment, as macro-enabled files demand explicit user trust settings to mitigate risks of malicious execution, often leading to organizational policies that disable scripting by default. These factors can increase long-term costs and limit portability across platforms.

Textual Macros

Parameterless Text-Substitution Macros

Parameterless text-substitution macros, also referred to as object-like macros, consist of a single identifier that the preprocessor replaces with a fixed sequence of tokens, without accepting any input parameters. These macros are defined using a directive such as #define in languages like C, where the identifier is followed by the expansion text, enabling straightforward symbolic representation of constants or repeated code fragments. The initial implementation of such macros in the C preprocessor, developed in the early 1970s, provided basic string replacement capabilities as a foundational feature for code abstraction. In practice, parameterless macros are commonly employed to define numeric constants or short phrases that appear frequently in . For instance, in C programming, the directive #define PI 3.14159 instructs the to substitute every occurrence of PI with 3.14159, as shown in the following example:

#define PI 3.14159 double circumference = 2 * PI * radius;

#define PI 3.14159 double circumference = 2 * PI * radius;

After preprocessing, this expands to double circumference = 2 * 3.14159 * radius;, eliminating the need to hardcode the value and reducing errors from manual repetition. Similarly, in build systems like GNU Make, parameterless macros function as simple variables for text substitution; for example, defining CC = gcc allows $(CC) to expand to gcc in rules, such as

program: main.o $(CC) -o program main.o

program: main.o $(CC) -o program main.o

which becomes

program: main.o gcc -o program main.o

program: main.o gcc -o program main.o

. These examples illustrate their role in configuration files and scripts, where they promote consistency without altering the underlying logic. The expansion process occurs during the preprocessing stage, a lexical phase before compilation, where the preprocessor scans the source file line by line, replacing each macro invocation with its defined token sequence while preserving the original syntax. This substitution supports multi-line expansions via backslash-escaped newlines, allowing more complex fixed blocks, such as:

#define NUMBERS 1, \ 2, \ 3 int array[] = { NUMBERS };

#define NUMBERS 1, \ 2, \ 3 int array[] = { NUMBERS };

which expands to int array[] = { 1, 2, 3 };. By centralizing repeated elements, these macros reduce , enhance readability, and facilitate , as changes to the expansion propagate across the entire . Empirical studies of usage confirm that object-like macros are prevalent for defining constants, comprising a significant portion of macro definitions in large projects to avoid scattering literal values. Despite their simplicity, parameterless macros introduce rigidity due to their fixed expansions, preventing adaptation to varying contexts without redefinition. A key drawback is the potential for unintended substitutions arising from name clashes; if a macro identifier coincides with a variable or function name in the , the may expand it erroneously, leading to compilation errors or altered semantics. For example, defining #define MAX 100 could unexpectedly replace a function named MAX in void func(int MAX), resulting in invalid after expansion. Such issues underscore the need for careful naming conventions to avoid global interference, as macros lack scoping mechanisms. This foundational approach later evolved into parameterized variants to address these limitations by incorporating input handling for greater flexibility.

Parameterized Text-Substitution Macros

Parameterized text-substitution macros, also known as function-like macros, extend parameterless macros by accepting formal parameters that enable dynamic substitution of arguments into a predefined template during preprocessing. These macros are defined using the #define directive followed by the macro name, a parenthesized list of parameters, and the replacement text, allowing for reusable code snippets that mimic function calls without runtime overhead. For instance, , the macro #define MAX(a, b) ((a) > (b) ? (a) : (b)) substitutes the provided arguments a and b into the conditional expression, expanding to the appropriate comparison when invoked as MAX(x, y). The expansion process involves several mechanics to handle argument substitution accurately. Upon invocation, actual arguments replace the formal parameters in the macro body, after which the resulting text is rescanned for further macro expansions, adhering to strict rules to prevent unintended interactions. Token pasting, using the ## operator, concatenates adjacent tokens—often involving macro parameters—to form new identifiers; for example, #define PASTE(a, b) a##b expands PASTE(foo, bar) to foobar, useful for generating variable names dynamically. Similarly, stringification with the # operator converts a macro parameter into a without further expansion; #define STR(x) #x turns STR(hello) into "hello", aiding in or by enclosing arguments in quotes. However, arguments with side effects, such as function calls, pose risks if evaluated multiple times in the expansion; for example, #define SQUARE(x) ((x) * (x)) applied to SQUARE(i++) increments i twice, unlike a true function that evaluates once. In practice, parameterized macros are widely used in and C++ for defining inline computations, constants, and simple utilities that avoid function call overhead while promoting . Common applications include min/max functions, like the MAX example, or generic patterns such as swapping variables with #define SWAP(a, b) do { typeof(a) _t = (a); (a) = (b); (b) = _t; } while(0), which ensures and single evaluation through temporary variables. In older systems without templates or generics, such macros facilitated portable code generation, such as conditional includes or platform-specific adaptations, enhancing maintainability in pre-standardized environments. Despite their utility, several complicate their use. Expansion order follows a depth-first approach, where nested macros expand fully before outer ones, potentially leading to misnesting if parentheses are mismatched; for instance, improper grouping in arguments can alter operator precedence unexpectedly. Debugging expanded code is challenging due to the preprocessor's textual nature, though tools like the -E compiler flag reveal the fully expanded source for inspection. Additionally, is limited to prevent infinite loops—GCC enforces a 200-level depth, exceeding the C standard's minimum of 15—to safeguard compilation stability. These issues underscore the need for careful design, often favoring inline functions in modern C++ over macros for better type checking and safety.

Macros in Embeddable Languages

Macros in embeddable languages refer to lightweight domain-specific languages (DSLs) integrated into host languages , allowing users to define custom abstractions through textual substitution mechanisms that expand during preprocessing . These macros enable the of extensible within scripting or configuration environments without requiring modifications to the core parser of the host language. For instance, the m4 macro processor serves as a general-purpose embeddable macro system for Unix tools, where it preprocesses input files by expanding macro definitions before passing them to the target application. Similarly, Jinja, a templating engine for Python, incorporates macros as reusable blocks that facilitate dynamic content generation in and configuration files. Implementation of these macros typically involves tight integration with the host language's parser, where expansion occurs at parse time to substitute defined patterns with their corresponding text. This process ensures that macros act as preprocessors, transforming or templates into valid host language constructs prior to compilation or execution. A notable example is noweb, a tool that embeds macros for tangling and weaving documentation and code, allowing authors to define custom extraction rules that expand during to separate prose from executable code. Such integration maintains the host language's syntax while permitting user-defined extensions, often leveraging simple for substitution. Text-substitution serves as the underlying mechanism for these expansions, providing a straightforward way to parameterize and reuse code snippets. The primary benefits of macros in embeddable languages include clear , where domain-specific logic can be encapsulated without altering the host language's core, and ease of customization for end-users in specialized applications. This approach promotes , as macros allow for the injection of boilerplate reduction or conditional logic directly into templates or scripts, enhancing maintainability in environments like . For example, the ECPG in enables macro-like directives such as EXEC SQL DEFINE for reusable query patterns that expand at preprocessing time, simplifying complex database interactions while preserving SQL's native syntax. In configuration languages, YAML parsers with macro support, like those in Ansible's Jinja2 integration, permit variable substitutions and loops that expand macros to generate dynamic infrastructure definitions, improving scalability in deployment .

Syntactic and Procedural Macros

Syntactic Macros

Syntactic macros represent a advanced form of in , where macros manipulate the (AST) of to enable structural transformations beyond simple text replacement. Unlike earlier textual macros that substitute strings directly, syntactic macros treat code as data, allowing programmers to define new syntactic constructs that integrate seamlessly with the host . This capability is most notably realized in Lisp-family languages, such as , where the defmacro special form defines a macro by specifying a name, parameters, and a body that computes the expansion. The process of syntactic macro expansion involves capturing the macro invocation as an , which serves as a direct representation of the AST in homoiconic languages like . The macro's body then evaluates this input to generate a new , which is inserted in place of the original form during compilation or interpretation. To mitigate issues like variable capture—where identifiers from the macro unintentionally bind to those in the surrounding context— techniques are employed, such as generating unique symbols (e.g., via gensym in ) or using built-in hygienic expansion in languages like Scheme and Racket. This ensures that the expanded code preserves the intended scoping without accidental identifier collisions. One key advantage of syntactic macros lies in their support for , enabling the creation of domain-specific languages (DSLs) tailored to particular problem domains. For instance, Common Lisp's loop macro provides a declarative syntax for complex s, expanding to efficient combinations of do, if, and other primitives, thereby abstracting repetitive control structures. Similarly, macros like with-open-file manage resource acquisition and release, generating try-finally blocks to ensure files are closed even if errors occur, thus promoting safer and more concise code for I/O operations. These examples illustrate how syntactic macros extend the language's expressiveness without altering its core semantics. However, syntactic macros introduce challenges, particularly in , as the expanded code can obscure the original intent, making it difficult to trace errors back to the macro . Tools like macro steppers or expanders help by visualizing the transformation sequence, but the process remains non-trivial for complex macros. Additionally, since macro bodies operate within the full power of the host language, expansions can be Turing-complete, potentially leading to non-terminating computations during macro processing if not carefully designed.

Procedural Macros

Procedural macros represent an advanced form of in which macros are treated as functions executed at to generate code dynamically based on input tokens or attributes, producing output code snippets that are inserted into the program. This approach enables arbitrary computation during expansion, distinguishing it from simpler substitution mechanisms. In implementation, procedural macros receive a TokenStream—a sequence of syntactic tokens from the source code—as input, process it using the host language's logic, and return a new TokenStream as output, which the integrates seamlessly. They operate during the compilation phase, after parsing but before type checking of the generated code, ensuring the output undergoes full validation. Procedural macros are categorized into three primary stages or forms: derive macros, invoked via the #[derive] attribute to automate trait implementations for data structures; attribute macros, which expand custom attributes applied to items like functions or modules; and function-like macros, called similarly to regular functions to generate code inline. For instance, in Rust, a derive macro might be defined as follows:

rust

use proc_macro::TokenStream; use quote::quote; use syn::{parse_macro_input, DeriveInput}; #[proc_macro_derive(HelloMacro)] pub fn hello_macro_derive(input: TokenStream) -> TokenStream { let ast = parse_macro_input!(input as DeriveInput); let name = &ast.ident; let gen = quote! { impl HelloMacro for #name { fn hello_macro() { println!("Hello, Macro! My name is {}!", stringify!(#name)); } } }; gen.into() }

use proc_macro::TokenStream; use quote::quote; use syn::{parse_macro_input, DeriveInput}; #[proc_macro_derive(HelloMacro)] pub fn hello_macro_derive(input: TokenStream) -> TokenStream { let ast = parse_macro_input!(input as DeriveInput); let name = &ast.ident; let gen = quote! { impl HelloMacro for #name { fn hello_macro() { println!("Hello, Macro! My name is {}!", stringify!(#name)); } } }; gen.into() }

This example parses the input struct or enum, extracts its name, and generates an implementation block for a custom trait. Key use cases for procedural macros include automating the generation of for trait implementations, such as Debug or Clone in , where derive macros produce efficient, tailored code without manual repetition. In Scala, similar facilities via macros enable compile-time derivation of instances, for example, generating serialization code for encoding in libraries that inspect case class structures to produce encoders and decoders. The primary benefits of procedural macros lie in their ability to ensure in generated code, as the verifies the output just like handwritten code, and their support for modular design, allowing third-party extensions to language features without core modifications. They promote and reduce verbosity for complex patterns, such as custom or routing definitions. Limitations include increased compile-time overhead from executing the macro logic, which can extend build durations for large projects, and the added in authoring and , as macro code runs in a separate procedural context with limited access to the broader program state compared to syntactic approaches. Additionally, they necessitate isolation in dedicated crates or modules to prevent runtime interference.

Hygienic and Anaphoric Macros

Hygienic macros are a class of syntactic macros designed to prevent unintended variable capture during expansion, ensuring that identifiers introduced by the macro do not accidentally bind to variables in the surrounding code. This property, known as , is achieved through automatic renaming of bound identifiers to unique symbols, typically using techniques like scope sets or mark propagation. The concept was formalized in the 1986 paper "Hygienic Macro Expansion" by Kohlbecker, , Felleisen, and Duba, which introduced an to enforce hygiene by tracking binding relationships during macro transformation. In languages like Scheme, hygienic macros are implemented via syntax-rules, a declarative macro system that treats binders and references as scoped units, automatically generating fresh names to avoid name clashes. This approach promotes modularity by isolating macro-generated code from the lexical context, reducing bugs from accidental interactions and enabling safer . For example, in Racket—a dialect of Scheme—a hygienic macro defining a local binding like let ensures that internal variables do not interfere with external ones. Consider a macro dbl that doubles its argument using a temporary y:

racket

(define-syntax dbl (syntax-rules () [(dbl x) (let ([y 1]) (* 2 x y))]))

(define-syntax dbl (syntax-rules () [(dbl x) (let ([y 1]) (* 2 x y))]))

When used as (let ([y 7]) (dbl 3)), the expansion becomes (let ([y 7]) (let ([y1 1]) (* 2 3 y1))), where y1 is a renamed hygienic variant, preserving the outer y binding. This automatic hygiene simplifies macro authoring, as programmers need not manually manage identifier uniqueness, leading to more reliable and maintainable extensions in block-structured languages. In contrast, anaphoric macros deliberately share bindings between the macro's expansion and the caller's scope, using anaphors—implicit references like the symbol it—to create concise, context-dependent constructs. This intentional capture allows for expressive shortcuts but requires careful use to avoid unintended side effects. Anaphoric macros originated in Lisp traditions, where they leverage the language's homoiconicity to inject shared variables, as detailed in Paul Graham's 1993 book "On Lisp." A classic example is aif, an anaphoric if that binds the test result to it for use in consequent and alternate clauses:

lisp

(defmacro aif (test then &optional else) `(let ((it ,test)) (if it ,then ,else)))

(defmacro aif (test then &optional else) `(let ((it ,test)) (if it ,then ,else)))

Usage like (aif (find-if #'evenp nums) (print it)) avoids recomputing the test and referencing it explicitly, streamlining for common patterns. Hygienic and anaphoric macros represent opposing philosophies within syntactic macro systems: hygiene prioritizes safety through isolation via namespaces or renaming algorithms, making it the default in modern Scheme implementations for robust modularity. Anaphora, conversely, embraces explicit scoping for brevity and expressiveness, often implemented by leaking bindings in unhygienic macros, though it demands programmer vigilance to prevent capture errors. While hygiene mitigates risks in large-scale codebases, anaphora shines in domain-specific idioms, with implementations balancing the two through optional unhygienic escapes in hygienic systems.

Domain-Specific Macros

Assembly Language Macros

Assembly language macros provide a mechanism in macro assemblers for defining reusable blocks of code that expand directly into machine instructions, enabling abstraction and automation at the low level. These macros typically support parameters to customize the generated code, such as register names or immediate values, and are processed during the assembly phase to produce object code without runtime overhead. In tools like the (MASM), macros incorporate advanced features including looping, arithmetic operations, and string manipulation to generate complex instruction sequences. Similarly, the GNU Assembler (GAS) uses directives like .macro and .endm to define macros that output assembly instructions, supporting optional parameters with defaults or requirements. Implementation of assembly macros relies on , where the assembler substitutes the macro definition at each invocation site, replacing parameters with actual values to form valid instructions. Local labels are often employed to avoid naming conflicts across multiple expansions, particularly in GAS's alternative macro mode (.altmacro), which generates unique identifiers for each instance. For example, a GAS macro to reserve a block of might be defined as follows:

.macro reserve size .space \size .endm

.macro reserve size .space \size .endm

Invoking reserve 16 expands to .space 16, allocating 16 bytes of uninitialized . Another common use defines reusable subroutines or initialization routines; for instance, a parameterized macro in MASM could generate a loop to clear a block:

CLEAR_MEM MACRO dest, count LOCAL loop_start mov cx, count loop_start: mov byte ptr [dest], 0 inc dest loop loop_start ENDM

CLEAR_MEM MACRO dest, count LOCAL loop_start mov cx, count loop_start: mov byte ptr [dest], 0 inc dest loop loop_start ENDM

This expands inline upon invocation like CLEAR_MEM buffer, 100, producing the corresponding x86 instructions without creating a separate procedure call. Such expansions facilitate the creation of blocks or instruction patterns tailored to hardware specifics, like handlers or peripheral configurations. Historically, assembly macros emerged in the early as part of macro assemblers to enhance productivity, originating from efforts at and implementations like for the in 1963. They played a key role in improving portability by abstracting assembler-specific syntax differences, allowing code to be adapted across variants from different vendors without full rewrites. Macros also reduced repetitive opcodes by encapsulating common sequences, such as arithmetic operations or I/O routines, which streamlined development in resource-constrained environments like the ARPANET system in 1969. In modern contexts, assembly macros remain vital in embedded systems for hardware-specific optimizations, where they enable precise control over interrupts, timing-critical code, and without the abstraction layers of higher languages. For example, in microcontroller programming with assemblers like those for AVR or , macros define atomic operations like enabling interrupts (INTR_ON MACRO asm("sei") END) to ensure in real-time applications. Optimizing compilers, such as those for embedded targets, often output assembly code incorporating predefined macros from system headers to fine-tune , balancing code size and execution speed in constrained devices like automotive controllers or IoT sensors.

Macros for Machine-Independent Software

Macros for machine-independent software employ conditional or parameterized mechanisms to abstract differences in operating systems, hardware architectures, and compilers, thereby enabling a single codebase to compile and run across diverse platforms. These macros typically operate at the level or within build systems, using feature detection to select appropriate code paths or configurations. A prominent example is the GNU tool, which leverages the M4 macro processor to generate configure scripts that probe the build environment for platform-specific attributes, such as available headers, functions, or libraries, and adjust the build accordingly. Implementation often involves feature tests that expand macros into compatible code variants. In C programming, conditional compilation directives like #ifdef and #if defined() are used to detect platform characteristics via predefined macros, such as _WIN32 for Windows or __linux__ for Linux, allowing the preprocessor to include OS-specific implementations. For instance, to handle endianness variations—where byte order differs between big-endian (e.g., PowerPC) and little-endian (e.g., x86) systems—a macro can perform a compile-time or runtime check: #define IS_BIG_ENDIAN (*(char*)&(int){1} == 0), which tests the byte representation of the integer 1 and expands to byte-swapping code only if necessary, ensuring portable data handling in files or networks. API shims further enhance portability by mapping platform-specific functions to a unified interface through macro expansion. In cross-platform C code, a macro like #ifdef _WIN32 #define READDIR(dirent, dir) FindNextFileA((HANDLE)(dir)->handle, &(dirent)) #else #define READDIR(dirent, dir) readdir((dir)) #endif abstracts directory reading between Windows' FindNextFileA and POSIX's readdir, allowing the same source to compile on both without modification. Build systems integrate these techniques; for example, employs its scripting language with functions akin to macros (e.g., target_compile_definitions) to detect features via check_include_file tests and generate platform-independent build files, supporting targets from systems to Windows and embedded devices. The primary benefits include maintaining a unified that reduces development effort for multi-platform support, as seen in large projects like the or software, where portability is achieved without duplicating source files. This approach minimizes errors from manual porting and leverages automated detection to adapt to evolving hardware, such as new CPU architectures. However, challenges arise in maintaining these conditionals, as proliferating #ifdef blocks can obscure code logic and increase complexity. Additionally, unused expansions in conditional paths may introduce minor binary bloat if not stripped during linking, though this is typically negligible compared to the gains in .

Modern Language-Specific Macros

In contemporary programming languages, macros have advanced to support sophisticated , enabling developers to extend syntax and automate boilerplate while maintaining safety and expressiveness. These features address post-2010 needs for safer, more ergonomic code generation in systems and scientific computing contexts. Rust distinguishes between declarative macros, which use pattern-matching via macro_rules! to transform syntax declaratively, and procedural macros, which execute arbitrary code at to generate or analyze syntax trees. Procedural macros encompass derive macros, a subtype that automatically implements traits for structs and enums; for instance, the #[derive(Serialize)] attribute from the Serde library generates code for and other formats, reducing manual implementation errors. Derive macros were first stabilized in Rust edition 2015 with version 1.15 on February 2, 2017, and procedural macros beyond derives stabilized in edition 2018 with version 1.30 on October 25, 2018. The 2024 edition, released with version 1.85.0 on February 20, 2025, updated macro fragment specifiers so that expr now matches const and _ expressions, introducing expr_2021 for previous behavior compatibility. Julia employs expression-based macros that manipulate abstract syntax trees (ASTs) to create custom syntax for , particularly useful in numerical and scientific domains. The @time macro, for example, wraps code to measure execution time and memory usage, providing without altering the original expression's semantics. This approach allows seamless integration of domain-specific languages, such as for linear operations, directly into Julia code. In , Sweet.js provides hygienic macros through a source-to-source transpiler, enabling syntax extensions like or custom control structures while preserving variable scoping. Elixir builds on its Lisp heritage with hygienic macros by default, using quote to capture unevaluated expressions as ASTs and unquote to inject dynamic values, facilitating safe code generation for concurrent and distributed systems. Emerging trends in language-specific macros emphasize tight integration with type systems for safer expansions, as in Rust's derive macros that leverage trait bounds to ensure generated code respects type constraints. Macros also enhance cross-platform ecosystems, such as Rust's use in via the wasm-bindgen macro, which automates bindings between Rust and for browser-based applications. Additionally, they bolster library ecosystems by automating repetitive patterns, like trait derivations in Rust crates, promoting reusable and maintainable codebases without sacrificing performance.

Security Considerations

Macro Viruses

Macro viruses are a type of that embeds malicious code within the macros of office application files, such as documents or Excel spreadsheets, exploiting macro languages like (VBA) to execute harmful actions. These viruses leverage the automation capabilities of application macros to infect documents and spread across systems. The rise of macro viruses occurred in the 1990s alongside the proliferation of macro-rich office applications, marking a significant shift in malware targeting productivity software rather than operating systems. The first known macro virus, WM/Concept, emerged in July 1995 and targeted Microsoft Word by infecting the Normal.dot template, allowing it to propagate to new documents created on infected systems. This virus demonstrated the potential for self-replication within document files and soon became one of the most widespread viruses at the time. A prominent example is the Melissa virus, which appeared in March 1999 and rapidly spread via email attachments containing infected Word documents, overwhelming corporate email servers and causing widespread disruptions. In terms of mechanics, macro viruses typically auto-execute upon opening an infected file, as the macro code is triggered by built-in events like document load in applications such as Word or Excel. Propagation often occurs through email attachments, where the virus emails copies of itself to contacts listed in the victim's address book, facilitating rapid dissemination without user intervention. Payloads can include data theft, such as harvesting email addresses for further spread, file corruption, or downloading additional malware, all executed via the macro's access to system resources. To mitigate macro viruses, modern versions disable macros by default, requiring explicit user enablement for execution. Additional protections include digital signatures, which verify macro authenticity from trusted publishers before allowing execution, and , a sandboxing feature that opens potentially unsafe files in an isolated read-only mode to prevent automatic code running. further detects and blocks known macro virus signatures during file scans.

Code Injection and Expansion Risks

Untrusted macro expansion in programming languages like C and Rust can introduce significant security risks, particularly through code injection and unintended side effects during compilation. In C, the preprocessor's textual substitution mechanism allows macros to generate code that may evaluate arguments multiple times, leading to subtle defects exploitable in security-critical contexts, such as buffer overflows if a macro inadvertently alters array bounds or pointer arithmetic. For instance, a macro defined as #define ABS(x) (((x) < 0) ? -(x) : (x)) used with ABS(++n) increments n twice, potentially causing off-by-one errors in loops that manage memory, which attackers could leverage if combined with untrusted inputs. Similarly, malicious #include directives from tainted sources can inject arbitrary code snippets, amplifying supply-chain vulnerabilities in header libraries. In , procedural macros pose even greater risks due to their ability to execute arbitrary Rust code at build time, enabling direct into the compiled binary. If a dependency contains a malicious procedural macro, it can generate unsafe code or exfiltrate secrets during expansion, as the macro runs with the privileges of the build environment, including file and network access. An example involves a proc macro that parses untrusted input to derive traits; tainted inputs could coerce the generation of unsafe blocks, bypassing 's guarantees and introducing vulnerabilities like use-after-free. This is exacerbated in supply-chain attacks, where compromised crates on crates.io propagate malicious macros to downstream projects. As of early 2025, such risks persist, with ongoing discussions in the Rust community about enhanced sandboxing to address supply-chain threats. To mitigate these risks, developers should prioritize input validation in macros that process external data, ensuring strict parsing to prevent injection of malicious constructs. In C, best practices include avoiding function-like macros altogether in favor of inline or static functions, which provide single-evaluation semantics and , reducing the chance of exploitable side effects. For Rust, sandboxing procedural macros—such as through WebAssembly-based execution—limits their access to system resources, while tools like Clippy can lint macro expansions for hidden unsafety or suspicious patterns during development. Additionally, IDE integrations with macro hygiene checks help detect potential injection points early. As of October 2025, broader concerns involve AI-generated , which can include macro definitions produced by tools like code assistants that inadvertently embed vulnerabilities; reports indicate AI-assisted coding contributes to one-in-five reported breaches overall. These risks are heightened in open-source derives, where AI-suggested procedural macros may overlook hygiene, leading to unvalidated expansions in shared libraries. While related to macro viruses in contexts, these compile-time threats focus on static exploits rather than runtime propagation.

Historical Development

Early Origins

The concept of macros in emerged in the late and as a means to simplify programming through text substitution and , particularly in the era of limited and manual input methods like punched cards. Early forms appeared in the form of open subroutines, which expanded inline rather than calling closed routines, effectively acting as proto-macros to avoid overhead. For instance, the computer, operational from 1949 at the , supported open subroutines that programmers could define and expand on the fly to conserve storage, reducing the tedium of entering repetitive instruction sequences via paper tape. This approach addressed the practical challenges of early stored-program machines, where every instruction counted toward resource limits. In the early 1950s, assembly language development further formalized macro-like features for instruction shorthand and code generation. Grace Hopper, working at Remington Rand, played a pivotal role by proposing in 1951 a library of subroutines stored on punched cards that could be automatically incorporated into programs as needed, an idea that evolved into the notion of open subroutines or macro expansions. The IBM 701's assembler, developed by Nathaniel Rochester and introduced in 1954, incorporated symbolic notation and basic abbreviation mechanisms that served as precursors to full macros, enabling programmers to define shorthand for common instruction patterns and thereby streamline scientific computations on vacuum-tube machines. These innovations marked the transition from pure machine code to more expressive assembly tools, significantly easing the labor of programming large-scale calculations. By the late and into the , macros began appearing in higher-level contexts, building on subroutine libraries. 1.5, released in 1959 by John McCarthy and colleagues at MIT, introduced user-defined functions via expressions, with FEXPRs allowing unevaluated argument passing—a mechanism that functioned as proto-macros by enabling runtime code transformation without automatic evaluation. In planning systems, the STRIPS framework, developed in the early 1970s at , extended this through ABSTRIPS, which automatically generated macro-operators from prior solution plans to abstract sequences of actions, improving efficiency in robot problem-solving tasks. Assembly language macros continued to evolve in the , exemplified by Digital Equipment Corporation's MACRO-11 assembler for the PDP-11 minicomputers, which supported conditional and parametric macro definitions to generate code snippets, drastically cutting down on the punch-card volume required for complex programs. This tool, integral to real-time systems and embedded applications, highlighted macros' role in mitigating the physical and error-prone nature of in an era before widespread interactive computing. Hopper's early advocacy for reusable code modules influenced these developments, laying groundwork for macros as a foundational in programming languages.

Evolution and Modern Advances

The standardization of the in the ANSI X3.159-1989 standard formalized macro definitions and expansion rules, enabling portable textual substitution across C implementations. Concurrently, the m4 macro processor, originally developed in 1975 by and as a general-purpose tool for UNIX, was extended by the GNU m4 implementation released in 1990 by René Seindal, influencing build systems and configuration scripts through the and beyond. In the early 1990s, Scheme's Revised^4 Report (R4RS), published in 1991, introduced optional hygienic macros via the define-syntax form, addressing variable capture issues in macro expansion and promoting safer syntactic extensions. This innovation, building briefly on Lisp's foundational , emphasized to prevent unintended bindings during expansion. During the 2000s, saw incremental macro extensions in libraries and implementations, enhancing domain-specific languages while maintaining its defmacro-based system from the 1994 ANSI standard. The 2010s brought further shifts toward hygienic and procedural approaches: Julia incorporated expression-based macros from its 2012 release, allowing runtime-like code generation with hygiene checks. Rust introduced procedural macros in 2015 via RFC 1566, enabling compile-time syntax manipulation through token streams for safer, attribute-driven derivations. Projects like Sweet.js (2013) extended hygienic macros to , using to mitigate lexical pitfalls in non-Lisp environments. By the 2020s, trends emphasized safe , with a pronounced shift toward for security and , as detailed in historical analyses of macro systems.

References

  1. https://gcc.gnu.org/onlinedocs/cpp/Macros.html
  2. https://courses.cs.washington.edu/courses/cse341/13sp/lec15slides.pdf
  3. https://www.gnu.org/software/m4/manual/html_node/History.html
  4. https://academic.oup.com/comjnl/article-pdf/28/1/29/1268711/280029.pdf
  5. https://www.cs.ucdavis.edu/~devanbu/teaching/260/weise-crew.pdf
  6. https://learn.microsoft.com/en-us/cpp/preprocessor/macros-c-cpp?view=msvc-170
  7. https://doc.rust-lang.org/book/ch19-06-macros.html
  8. https://www.computerhope.com/jargon/m/macro.htm
  9. https://www.geeksforgeeks.org/compiler-design/macro-processor/
  10. https://www2.ccs.neu.edu/racket/pubs/oopsla20-bkf.pdf
  11. https://www.cs.odu.edu/~zeil/cs330/web/website/Lectures/containers/pages/ar01s03s01.html
  12. https://www.cs.ccsu.edu/~kjell/cs254/ch11/ch11_41.html
  13. https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node99.html
  14. https://www.cs.umd.edu/~ben/papers/Potter1999Pixel.pdf
  15. https://itc.ktu.lt/index.php/ITC/article/view/11931/6598
  16. https://doi.org/10.1145/3354584
  17. https://www.autohotkey.com/docs/v2/
  18. https://support.microsoft.com/en-us/topic/how-do-i-create-macros-bd0f29dc-5b89-3616-c3bf-ddeeb04da2fb
  19. https://autokey.github.io/
  20. https://dl.acm.org/doi/10.1145/3397329
  21. https://dl.acm.org/doi/10.1145/3746059.3747663
  22. https://learn.microsoft.com/en-us/office/vba/library-reference/concepts/getting-started-with-vba-in-office
  23. https://extendscript.docsforadobe.dev/introduction/scripting-for-specific-applications/
  24. https://www.jetbrains.com/help/idea/ide-scripting-console.html
  25. https://www.outsystems.com/application-development/vendor-lock-in-challenges-and-concerns/
  26. https://gcc.gnu.org/onlinedocs/cpp/Object-like-Macros.html
  27. https://softwareengineering.stackexchange.com/questions/309389/what-is-the-origin-of-the-c-preprocessor
  28. https://www.gnu.org/software/make/manual/html_node/Using-Variables.html
  29. https://gcc.gnu.org/onlinedocs/cpp/
  30. https://www.programiz.com/c-programming/c-preprocessor-macros
  31. https://homes.cs.washington.edu/~mernst/pubs/c-preprocessor-tse2002.pdf
  32. https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html
  33. https://gcc.gnu.org/onlinedocs/cpp/Function-like-Macros.html
  34. https://gcc.gnu.org/onlinedocs/cpp/Macro-Arguments.html
  35. https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html
  36. https://gcc.gnu.org/onlinedocs/cpp/Stringizing.html
  37. https://gcc.gnu.org/onlinedocs/cpp/Duplication-of-Side-Effects.html
  38. https://learn.microsoft.com/en-us/cpp/c-runtime-library/recommendations-for-choosing-between-functions-and-macros?view=msvc-170
  39. https://gcc.gnu.org/onlinedocs/cpp/Implementation-limits.html
  40. https://www.postgresql.org/docs/current/ecpg-preproc.html
  41. https://www.cs.cmu.edu/~dst/LispBook/book.pdf
  42. https://www2.ccs.neu.edu/racket/pubs/tfp10-ef.pdf
  43. https://lispcookbook.github.io/cl-cookbook/iteration.html
  44. https://www2.ccs.neu.edu/racket/pubs/cf-sp09.pdf
  45. https://docs.scala-lang.org/scala3/reference/metaprogramming/macros.html
  46. https://prl.khoury.northeastern.edu/img/kffd-tr-1986.pdf
  47. https://sep.turbifycdn.com/ty/cdn/paulgraham/onlisp.pdf
  48. https://learn.microsoft.com/en-us/cpp/assembler/masm/microsoft-macro-assembler-reference?view=msvc-170
  49. https://sourceware.org/binutils/docs/as/Macro.html
  50. https://walden-family.com/texland/macro-memories-v07.pdf
  51. https://users.ece.utexas.edu/~valvano/embed/chap12/chap12.htm
  52. https://userpages.cs.umbc.edu/tinoosh/cmpe311/notes/AVRAssemblerExamples.pdf
  53. https://www.gnu.org/software/autoconf/manual/autoconf.html
  54. https://developer.ibm.com/articles/au-endianc/
  55. http://jdebp.uk/FGA/predefined-macros-platform.html
  56. https://cmake.org/cmake/help/latest/manual/cmake-language.7.html
  57. https://doc.rust-lang.org/reference/macros.html
  58. https://blog.rust-lang.org/2018/12/21/Procedural-Macros-in-Rust-2018/
  59. https://doc.rust-lang.org/edition-guide/rust-2024/macro-fragment-specifiers.html
  60. https://docs.julialang.org/en/v1/manual/metaprogramming/
  61. https://www.sweetjs.org/
  62. https://hexdocs.pm/elixir/macros.html
  63. https://hexdocs.pm/elixir/quote-and-unquote.html
  64. https://www.techtarget.com/searchsecurity/definition/macro-virus
  65. https://us.norton.com/blog/malware/macro-viruses
  66. https://www.virusbulletin.com/virusbulletin/2015/06/throwback-thursday-macro-viruses-part-1-september-1999
  67. https://www.fbi.gov/news/stories/melissa-virus-20th-anniversary-032519
  68. https://www.sangfor.com/glossary/cybersecurity/what-is-macro-virus
  69. https://support.microsoft.com/en-us/office/protect-yourself-from-macro-viruses-a3f3576a-bfef-4d25-84dc-70d18bde5903
  70. https://www.sentinelone.com/cybersecurity-101/threat-intelligence/what-is-a-macro-virus/
  71. https://support.microsoft.com/en-us/office/what-is-protected-view-d6f09ac7-e6b9-4495-8e43-2bbcdbcb6653
  72. https://wiki.sei.cmu.edu/confluence/display/c/PRE12-C.+Do+not+define+unsafe+macros
  73. https://internals.rust-lang.org/t/security-breach-with-rust-macros/14703
  74. https://github.com/rust-lang/unsafe-code-guidelines/issues/278
  75. https://internals.rust-lang.org/t/sandbox-build-rs-and-proc-macros/16345
  76. https://doc.rust-lang.org/book/appendix-04-useful-development-tools.html
  77. https://www.itpro.com/software/development/ai-generated-code-is-now-the-cause-of-one-in-five-breaches-but-developers-and-security-leaders-alike-are-convinced-the-technology-will-come-good-eventually
  78. http://www.ancientgeek.org.uk/misc/edsac/221216_Programming_the_EDSAC_%28CCS%29.pdf
  79. https://www.ijcai.org/Proceedings/73/Papers/045.pdf
  80. https://bitsavers.org/pdf/dec/pdp11/handbooks/PDP-11_Handbook1979.pdf
  81. https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub160.pdf
  82. http://gnu.ist.utl.pt/software/m4/manual/html_node/History.html
  83. https://groups.csail.mit.edu/mac/classes/6.001/FT98/manuals/r4rs/r4rs.pdf
  84. https://rust-lang.github.io/rfcs/1566-proc-macros.html
  85. https://dl.acm.org/doi/10.1145/3386330
Add your contribution
Related Hubs
User Avatar
No comments yet.