Content deleted Content added
m punctuation |
m section heading: WP:MOS |
||
Line 2:
== Historical movement ==
The first paper usually<ref name="Standish1975">Standish, Thomas A., "Extensibility in Programming Language Design", ''SIGPLAN Notices'' 10 no. 7 (July 1975), pp. 18–21.</ref><ref name="Sammet1969">Sammet, Jean E., ''Programming Languages: History and Fundamentals'', Prentice-Hall, 1969, section III.7.2</ref> associated with the extensible programming language movement is [[Douglas McIlroy|M. Douglas McIlroy's]] 1960 paper on [[Macro (computer science)|macros]] for higher-level programming languages.<ref name="McIlroy1960">McIlroy, M.D., "Macro Instruction Extensions of Computer Languages", ''Communications of the ACM'' 3 no. 4 (April 1960), pp. 214–220.</ref> Another early description of the principle of extensibility occurs in Brooker and Morris's 1960 paper on the [[Compiler-compiler|Compiler-Compiler]].<ref name="Brooker&Morris1962">Brooker, R.A. and Morris, D., "A General Translation Program for Phrase Structure Languages", ''Journal of the ACM'' 9 no. 1 (January 1962), pp. 1–10. The paper was received in 1960.</ref> The peak of the movement was marked by two academic symposia, in 1969 and 1971.<ref name="Christensen&Shaw1969">Christensen, C. and Shaw, C.J., eds., Proceedings of the Extensible Languages Symposium, ''SIGPLAN Notices'' 4 no. 8 (August 1969).</ref><ref name="Schuman1971">Schuman, S.A., ed., Proceedings of the International Symposium on Extensible Languages, ''SIGPLAN Notices'' 6 no. 12 (December 1971).</ref> By 1975, a survey article on the movement by Thomas A. Standish<ref name="Standish1975"/> was essentially a post mortem.
=== Character of the
As typically envisioned, an extensible programming language consisted of a base language providing elementary computing facilities, and a meta-language capable of modifying the base language. A program then consisted of meta-language modifications and code in the modified base language.
Line 23 ⟶ 21:
* Metaphrase modifies the interpretation rules used for pre-existing expressions. It corresponds to the modern notion of [[Reflection (computer science)|reflection]].
=== Death of the
Standish attributed the failure of the extensibility movement to the difficulty of programming successive extensions. An ordinary programmer might build a single shell of macros around a base language, but if a second shell of macros was to be built around that, the programmer would have to be intimately familiar with both the base language and the first shell; a third shell would require familiarity with the base and both the first and second shells; and so on. (Note that shielding the programmer from lower-level details is the intent of the [[Abstraction (computer science)|abstraction]] movement that supplanted the extensibility movement.)
Line 30 ⟶ 27:
== Modern movement ==
In the modern sense, a system that supports extensible programming will provide ''all'' of the features described below.
=== Extensible
This simply means that the source language(s) to be compiled must not be closed, fixed or static. It must be possible to add new keywords, concepts and structures to the source language(s). While it is acceptable for some fundamental and intrinsic language features to be immutable, the system must not rely solely on those language features. It must be possible to add new ones.
=== Extensible
In extensible programming, a compiler is not a monolithic program that converts source code input into binary executable output. The compiler itself must be extensible to the point that it is really a collection of plugins that assist with the translation of source language input into ''anything''. For example, an extensible compiler will support the generation of object code, code documentation, re-formatted source code, or any other desired output. The architecture of the compiler must permit its users to "get inside" the compilation process and provide alternative processing tasks at every reasonable step in the compilation process.
Line 53 ⟶ 49:
* assist with the flow of information between internal and external passes as they both transform and translate the AST into new ASTs or other representations
=== Extensible
At runtime, extensible programming systems must permit languages to extend the set of operations that it permits. For example, if the system uses a [[byte-code]] interpreter, it must allow new byte-code values to be defined. As with extensible syntax, it is acceptable for there to be some (smallish) set of fundamental or intrinsic operations that are immutable. However, it must be possible to overload or augment those intrinsic operations so that new or additional behavior can be supported.
=== Content
Extensible programming systems should regard programs as data to be processed. Those programs should be completely devoid of any kind of formatting information. The visual display and editing of programs to users should be a translation function, supported by the extensible compiler, that translates the program data into forms more suitable for viewing or editing. Naturally, this should be a two-way translation. This is important because it must be possible to easily process extensible programs in a ''variety'' of ways. It is unacceptable for the only uses of source language input to be editing, viewing and translation to machine code. The arbitrary processing of programs is facilitated by de-coupling the source input from specifications of how it should be processed (formatted, stored, displayed, edited, etc.).
=== Source
Extensible programming systems must support the debugging of programs using the constructs of the original source language regardless of the extensions or transformation the program has undergone in order to make it executable. Most notably, it cannot be assumed that the only way to display runtime data is in ''structures'' or ''arrays''. The debugger, or more correctly 'program inspector', must permit the display of runtime data in forms suitable to the source language. For example, if the language supports a data structure for a [[business process]] or [[work flow]], it must be possible for the debugger to display that data structure as a [[fishbone chart]] or other form provided by a plugin.
== References
{{reflist}}
== See also ==
* [[:Category:Extensible syntax programming languages]]
* [[Adaptive grammar]]
* [[Concept programming]]
== External links ==
=== General ===
# [http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=247&page=1 Greg Wilson's Article in ACM Queue]
Line 84 ⟶ 78:
# [http://www.jetbrains.com/mps/ MPS] — JetBrains Metaprogramming system
=== Programming
# [http://xlr.sourceforge.net/index.html XLR: Extensible Language and Runtime]
# [http://nemerle.org/Macros Nemerle Macros]
| |||