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
xxxxxx@bothner.com   http://per.bothner.com/