[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: #\a octothorpe syntax vs SRFI 10

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/