Abstract type: Difference between revisions
m
→{{header|J}}
m (→{{header|J}}) |
|||
Line 955:
Note also: Types are sometimes thought of as being related to function domains. But, in the general case, domains of independently defined functions are independent of each other, and the intersections of these domains may or may not be empty.
[In fact, the real motivator for types is the need to allocate finite resources to represent numbers (or whatever else you choose to imagine is being represented). For example: 32 bit integers vs. 64 bit integers vs. 32 bit ieee-854 floating point and 64 bit ieee-854 floating point. Additionally, some operations are sensitive to other details related to these abstractions - the classic examples including overflow vs. carry (add with carry, addition overflow) which depend on the range of numbers involved (2s complement vs. unsigned vs. 1s complement). And then people get carried away trying to "generalize" rather "use" which triggers a need for standardization which mostly means prohibiting some of the most annoying generalizations, and other people objecting to those choices... there's no stopping these trends, which leaves people fascinated and perhaps horrified at the consequences.]
That said: it's useful to define a type, in the context of J, as "the set of values which may result from a parenthesized expression". And, if compilation to machine code is supported, it may also be useful to define constraint mechanisms to be used in expressions, so that machine code may be more easily generated.
| |||