Abstract type: Difference between revisions
Content added Content deleted
m (→{{header|J}}) |
m (→{{header|J}}) |
||
Line 988:
[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 types" rather than "use types" which triggers a need for standardization which mostly means prohibiting some of the most annoying generalizations, which is then followed by other people objecting to those choices... and there is no stopping these trends, which leaves many 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 specific 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.
(You can find a variety of languages with rather elaborate implementations of types, but as a general rule those elaborate type systems are either (a) inadequate to represent J arrays, or (b) adequate to represent J arrays but with painfully slow implementations for many typical use cases - especially involving large data sets. That said, you can also find cases where these languages perform well - especially if you tailor the problem to the language or vice versa.)
| |||