Abstract type: Difference between revisions

Content added Content deleted
Line 984:
J does not support abstract types, as defined here. In J, types are typically treated as a necessary evil, which should be minimized, disguised, hidden, neglected or ignored wherever practical. (2=1+1 regardless of the type of 1 and the type of 2, but 2 and '2' are very different things.) And allowing user defined types would complicate this approach.
 
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, andbut nevertheless, the intersections of these domains mayoften orenough mayare 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 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.]