Essays/Type
"Type" as a four letter word, means many things.
In the context of computer programming, type initially refers to the concepts related to the significance assigned to a sequence of bits in computer memory. Those might represent integers, or letters, or some other kind of numeric (or non-numeric) information.
Meanwhile, the practices of mathematics formalism have gradually extended the meaning of "type" to encompass nearly all of a programming language which deals with a "type". Needless to say, this makes for rather stilted conversation -- especially in the context of translating concepts between programming languages.
The treatment here will be considerably less ambitious.
In current J implementations, typically deal with two different concepts of "type". And, like the distinctions imposed by our mathematically formalistic friends, the distinction between these concepts blurs if examined too closely:
- Array type
- Syntactic type
Here, "array type" refers to the type of items of a J array. '1 2 3' is a different type from 1 2 3 -- the bits in computer memory used to represent these values are different, and the operations we can perform on these values are different. However, in terms of syntax, these are both 'nouns' in the language.
Syntactic type is "simpler" -- we have 'nouns', 'verbs', 'adverbs', and 'conjunctions' (and, we have a few other artifacts like parenthesis).
However, if we looked under the covers, we would see that these are still all represented in memory and the tools used to manipulate memory have overlaps which show up in the underlying data structures (in the current J engine these 'syntactic types' are represented using basically the same data structures used to represent J arrays).
But that's not all -- symbols / "variables" are similar entities and the things referred to by them also get roughly grouped under this same conceptual "type" umbrella. This, roughly speaking, includes J's locatives (roughly speaking, the "classes", "objects" and "stack frames" of other languages).
That said (again: roughly speaking), a distinction which J brings to the table, which is often missing from other languages, is an organization which tends to favor memory adjacency -- cache coherence, homogeneous arrays.
Here's a summary of the types used in the current J implementation ("current" currently means during the J904 development cycle).
| C | syntactic type | description | visible? | examples |
|---|---|---|---|---|
| B | noun | boolean | yes | 0, 1 |
| C | noun | literal (character) | yes | 'a', '0' |
| I | noun | integer | yes | _3, 00, 4 |
| D | noun | double (IEEE floating point) | yes | _3.1, 0.0, 9e99, _ |
| Z | noun | complex | yes | _1j_1, 0j0, 0j9.4e49 |
| A | noun | boxed | yes | a: |
| X | noun | extended precision integer | yes | 123456789876543210123456789x, 0x, _3x |
| Q | noun | rational number | yes | 1r3, 0r1, 1r0, _31r41 |
| noun | pyx | almost | ||
| B | noun | sparse boolean | yes | |
| C | noun | sparse literal | yes | |
| I | noun | sparse integer | yes | |
| D | noun | sparse floating | yes | |
| Z | noun | sparse complex | yes | |
| SB | noun | symbol | yes | |
| C2 | noun | unicode (2-byte characters) | yes | |
| C4 | noun | unicode4 (4-byte characters) | yes | |
| DX | noun | extended floating point | no | |
| ZX | noun | extended complex | no | |
| NM | varies | name | yes | |
| none | end of parsing stack marker | no | ||
| V | adverb | adverb | yes | |
| assignment | yes | |||
| locale (symbol table) | yes | |||
| control word (assignment) | ||||
| V | verb | verb | yes | |
| ( | left parenthesis | yes | ||
| V | conjunction | conjunction | yes | |
| ) | right parenthesis | yes | ||
| =. | assignment in explicit definition | yes | ||
| A | sparse boxed |
Here, the C column represents the type of items (or "atoms") of these arrays. Only noun types can contain a sequence of more than one item (noun types can also contain zero items, but some of these types, used during parsing, also contain no items). That said, the concept of atomicity does extend to verbs, as parsing involves a "valence" concept borrowed from chemistry, and verb, adverb, and/or conjunction definitions can contain additional definitions (but structured hierarchically -- slightly analogous to boxing -- rather than sequentially)
Note that extended floating point and extended complex are only represented here because they are needed for a few intermediate results in the j engine (during intolerant comparison).
Conceptually, the "sparse" types could be more analogous to the "boxed" type -- with a single "sparse" type which contains typed information. That said, j engine's current support for "sparse" types is... somewhat sparse, as sparse types cannot be contained in boxes: sparse types are a storage optimization for large arrays which are mostly populated with default values, while boxed arrays are typically smaller.