Namespace: Difference between revisions

From APL Wiki
Jump to navigation Jump to search
(APL+Win)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
A '''[[wikipedia:namespace|namespace]]''' is an encapsulation mechanism for names used within a program. Namespaces were added to [[APL2]] in 1987,<ref name="swain">Rexford H. Swain. [https://doi.org/10.1145/206913.207005 Namespaces: APL/W vs. APL2] at [[APL95]].</ref> and to [[Dyalog APL]] in 1994. They are also present in [[J]], where they may be used for [[object-oriented programming]]. As they are now common across many programming languages, more recent array languages such as [[Rowan]] may include namespace designs inspired by other languages (in this case [[wikipedia:R (programming language)|R]]). Because code can be evaluated within a particular namespace, namespaces serve as a way to combine the context for a set of [[function]]s or other operations without interfering with other parts of a program that do not need this context.
A '''[[wikipedia:namespace|namespace]]''' is an encapsulation mechanism for names used within a program. Namespaces were added to [[APL2]] in 1987,<ref name="swain">Rexford H. Swain. [https://doi.org/10.1145/206913.207005 Namespaces: APL/W vs. APL2] at [[APL95]].</ref>, to [[Dyalog APL]] in 1994, and to [[APL+Win]] in 2006.<ref>[[APLNow]]. [http://www.apl2000.com/productwin.php#info3 APL+Win Version 6.0]. 2006.</ref> They are also present in [[J]], where they may be used for [[object-oriented programming]]. As they are now common across many programming languages, more recent array languages such as [[Rowan]] may include namespace designs inspired by other languages (in this case [[wikipedia:R (programming language)|R]]). Because code can be evaluated within a particular namespace, namespaces serve as a way to combine the context for a set of [[function]]s or other operations without interfering with other parts of a program that do not need this context.


Depending on dialect namespaces may be accessible by one or more of the following two methods: indirectly by name (or, in [[J]], number), or directly by a value known as a [[namespace reference]]. Unlike traditional APL arrays, which are immutable, a namespace is mutable: the values in it can be changed even while it remains the "same" namespace (constructs such as [[indexed assignment]] allow an APLer to create a new array by modifying an existing one, but it is not considered the same array, and other references to it do not reflect any change). This means that namespace references, if they are used, are semantically different from older APL types. Nonetheless, it is possible to place namespace references into arrays or manipulate them as ordinary data.
Depending on dialect namespaces may be accessible by one or more of the following two methods: indirectly by name (or, in [[J]], number), or directly by a value known as a [[namespace reference]]. Unlike traditional APL arrays, which are immutable, a namespace is mutable: the values in it can be changed even while it remains the "same" namespace (constructs such as [[indexed assignment]] allow an APLer to create a new array by modifying an existing one, but it is not considered the same array, and other references to it do not reflect any change). This means that namespace references, if they are used, are semantically different from older APL types. Nonetheless, it is possible to place namespace references into arrays or manipulate them as ordinary data.


== History ==
== History ==
The concept of namespaces in APL was proposed as early as 1981 by Ron Murray, based on encapsulation concepts called "modules" or "packages" developed in the 1970s.<ref>Ronald C. Murray. [https://doi.org/10.1145/800142.805363 Namespaces: Semipermeable membranes for APL applications] at [[APL81]].</ref> Murray credits Jim Ryan for the use of the term "Namespace". In 1987, [[IBM]] introduced namespaces to [[APL2]] as a form of name scope (IBM used the term "namescope" for a workspace or function scope) that could be manipulated directly by the programmer.<ref name="swain"/> Unlike the later [[Dyalog APL]] namespaces, IBM's are independent of any workspace, and stored separately. Dyalog's namespaces were added in [[Dyalog APL 7.0|version 7.0]],<ref>[[John Scholes]]. [http://archive.vector.org.uk/art10007730 Meeting: Dyalog APL Namespaces]. [[Vector journal]] Volume 11, No.1. 1994-07.</ref> released in 1994, largely to make it easier to handle Dyalog's Windows GUI environment. In [[Dyalog APL 9.0]], namespace references were added, allowing these namespaces to be manipulated as values. Dyalog's namespaces would later become the basis of its [[object-oriented programming]] system implementation, although namespaces, classes, and objects are different kinds of values within the language.
The concept of namespaces in APL was proposed as early as 1981 by Ron Murray, based on encapsulation concepts called "modules" or "packages" developed in the 1970s.<ref>Ronald C. Murray. [https://doi.org/10.1145/800142.805363 Namespaces: Semipermeable membranes for APL applications] at [[APL81]].</ref> Murray credits Jim Ryan for the use of the term "Namespace".


In 1987, [[IBM]] introduced namespaces to [[APL2]] as a form of name scope (IBM used the term "namescope" for a workspace or function scope) that could be manipulated directly by the programmer.<ref name="swain"/> Unlike the later [[Dyalog APL]] namespaces, IBM's are independent of any workspace, and stored separately.
Dyalog's namespaces were added in [[Dyalog APL 7.0|version 7.0]],<ref>[[John Scholes]]. [http://archive.vector.org.uk/art10007730 Meeting: Dyalog APL Namespaces]. [[Vector journal]] Volume 11, No.1. 1994-07.</ref> released in 1994, largely to make it easier to handle Dyalog's Windows GUI environment. In [[Dyalog APL 9.0]], namespace references were added, allowing these namespaces to be manipulated as values. Dyalog's namespaces would later become the basis of its [[object-oriented programming]] system implementation, although namespaces, classes, and objects are different kinds of values within the language.
Namespaces, called MOM objects, were added in [[APL+Win]] 6.0 released in 2006, two-part compound names (like <syntaxhighlight lang=apl inline>myMom.daughterVar</syntaxhighlight>) in APL+Win 7.0, released in 2007, and arbitrarily long compound names (like <syntaxhighlight lang=apl inline>myMom.daughterVar.grandDaughter</syntaxhighlight>) in APL+Win 18.0, released in 2018.
== External links ==
=== Tutorials ===
* [https://chat.stackexchange.com/rooms/52405/conversation/lesson-16-apl-objects-namespaces APL Cultivation]
=== Documentation ===
* [https://help.dyalog.com/latest/#Language/Introduction/Namespaces/Namespaces.htm Dyalog]
== References ==
== References ==
<references/>
<references/>
{{APL features}}[[Category:APL objects]]
{{APL features}}[[Category:Kinds of array]][[Category:Types]]

Latest revision as of 14:59, 21 February 2024

A namespace is an encapsulation mechanism for names used within a program. Namespaces were added to APL2 in 1987,[1], to Dyalog APL in 1994, and to APL+Win in 2006.[2] They are also present in J, where they may be used for object-oriented programming. As they are now common across many programming languages, more recent array languages such as Rowan may include namespace designs inspired by other languages (in this case R). Because code can be evaluated within a particular namespace, namespaces serve as a way to combine the context for a set of functions or other operations without interfering with other parts of a program that do not need this context.

Depending on dialect namespaces may be accessible by one or more of the following two methods: indirectly by name (or, in J, number), or directly by a value known as a namespace reference. Unlike traditional APL arrays, which are immutable, a namespace is mutable: the values in it can be changed even while it remains the "same" namespace (constructs such as indexed assignment allow an APLer to create a new array by modifying an existing one, but it is not considered the same array, and other references to it do not reflect any change). This means that namespace references, if they are used, are semantically different from older APL types. Nonetheless, it is possible to place namespace references into arrays or manipulate them as ordinary data.

History

The concept of namespaces in APL was proposed as early as 1981 by Ron Murray, based on encapsulation concepts called "modules" or "packages" developed in the 1970s.[3] Murray credits Jim Ryan for the use of the term "Namespace".

In 1987, IBM introduced namespaces to APL2 as a form of name scope (IBM used the term "namescope" for a workspace or function scope) that could be manipulated directly by the programmer.[1] Unlike the later Dyalog APL namespaces, IBM's are independent of any workspace, and stored separately.

Dyalog's namespaces were added in version 7.0,[4] released in 1994, largely to make it easier to handle Dyalog's Windows GUI environment. In Dyalog APL 9.0, namespace references were added, allowing these namespaces to be manipulated as values. Dyalog's namespaces would later become the basis of its object-oriented programming system implementation, although namespaces, classes, and objects are different kinds of values within the language.

Namespaces, called MOM objects, were added in APL+Win 6.0 released in 2006, two-part compound names (like myMom.daughterVar) in APL+Win 7.0, released in 2007, and arbitrarily long compound names (like myMom.daughterVar.grandDaughter) in APL+Win 18.0, released in 2018.

External links

Tutorials

Documentation

References

APL features [edit]
Built-ins Primitives (functions, operators) ∙ Quad name
Array model ShapeRankDepthBoundIndex (Indexing) ∙ AxisRavelRavel orderElementScalarVectorMatrixSimple scalarSimple arrayNested arrayCellMajor cellSubarrayEmpty arrayPrototype
Data types Number (Boolean, Complex number) ∙ Character (String) ∙ BoxNamespaceFunction array
Concepts and paradigms Conformability (Scalar extension, Leading axis agreement) ∙ Scalar function (Pervasion) ∙ Identity elementComplex floorArray ordering (Total) ∙ Tacit programming (Function composition, Close composition) ∙ GlyphLeading axis theoryMajor cell searchFirst-class function
Errors LIMIT ERRORRANK ERRORSYNTAX ERRORDOMAIN ERRORLENGTH ERRORINDEX ERRORVALUE ERROREVOLUTION ERROR