This page is part of the web mail archives of SRFI 58 from before July 7th, 2015. The new archives for SRFI 58 contain all messages, not just those from before July 7th, 2015.
Aubrey Jaffer wrote:
Scheme's name for 0, 1, 2, ... is "nonnegative integers". Using abbreviations for terms which were never used in the reports demotes Scheme to a secondary status: You can understand Scheme after you have learned a *real* programming language.
Er - we're talking about adding new names to the *language*, not to the report. So the question is whether the name for "exact non-negative integer" would better be "nonnegative-integer" or "unsigned-integer". I don't feel strongly about it: the former uses "mathematical" terminology; the latter is more common when talking about computer data types. You don't normally talk about "16-bit" numbers in mathematics; you're now in the realm of computer data types, and in that realm "unsigned" is more common than "non-negative". Common Lisp does use the type specifiers signed-byte and unsigned-byte: The type 'unsigned-byte' or the type '(unsigned-byte *)' is the same as the type '(integer 0 *)', the set of non-negative integers.
Taylor Campbell proposed INTEGER16 and INTEGER16+ (or INTEGER-16 and INTEGER-16+).
No. Please don't be too creative. If you're going to use an abbreviation, it's better to pick one in common use ("uint16") or very similar ("uinteger16") rather than inventing new meanings for punctuation.
I disagree because of the "u", which students learning their first computer language will have no clue about.
You don't teach them type specifiers early anyway, at least not representation-oriented ones like uint16. If they get far enough that teaching them uint16 makes sense, then at that point they need to understand the standard "signed" vs "unsigned" terminology.
How about ninteger or n-integer or nn-integer?
Better than integer16+ or integer+16. (Of the 3, I prefer nn-integer.) But uinteger16 is better.
| > As discussed earlier, shorter names necessarily omit some of the | > numerical attributes. The fully specified Scheme names would be:| | > inexact-IEEE-64-bit-floating-point-real-array| > inexact-IEEE-32-bit-floating-point-real-array| | Right, but I'd still argue that "float-32" is a better abbreviated| name than "real-32". Then what word would you use to replace COMPLEX?
complex-32/complex-64. My reasoning is that few implementations will support non-floating complex values, but they will support both floating and exact integer values. Thus "complex" refers to the default/normal representation for complex numbers, but there is no default/normal representation for real numbers.
NUMBER, COMPLEX, REAL, RATIONAL, and INTEGER are the Scheme "numerical types" (R5RS:6.2.1). SRFI-58's prefixes contain the numerical type; a very strong argument would be required to justify replacing some but not all of these numerical types.
Both "real" and "complex" are "abstract types". We're now talking about names to give to concrete *representation* types. Thus "integer" might be a union of fixnum or bignum, but "integer16" is a specific representation type. "real" is often a union of floating-point, exact fraction, bignum, or fixnum; I think it would be better to use "float32" rather than "real32" for a specific representation type, but that's just my sense of things. "complex" is a union of "real" and zero or more (real, imaginary)-pair representations. Using "complex32" for a (float32,float32)-pair does seem more natural and less confusing to me than using "real32" instead of "float32", but I don't feel very strongly about it. Either way, coming up with short names is a matter of compromise. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/