[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.



 | Date: Sat, 01 Jan 2005 01:20:16 -0800
 | From: Per Bothner <per@xxxxxxxxxxx>
 | 
 | Aubrey Jaffer wrote:
 | 
 | > Are there type specifiers in common between Scheme implementations?
 | 
 | Not to my knowledge.  But it might be worthwhile looking at Schemes
 | that focus on compilation, including Stalin, Bigloo, and Kawa.
 | 
 | Common Lisp is of course has a little mini-language.  The Emacs
 | cl package emulates a subset of the Common Lisp specifiers.
 | 
 | > Here is a plan which, using the delimiter you suggested, indicates
 | > signed vs. unsigned with - versus +:
 | 
 | I think that's a little too cute.

It cuteness is the only objection anyone makes, I'll take that as
consensus.

 | I think just a single 'u' prefix is enough - and I don't think the
 | hyphen is needed: #nA:integer16 / #na:uinteger16.  Or just use the
 | short "int" instead of "integer" as in #nA:int16 / #nA:uint16.
 | That abbrevation is consistent with C/C++'s stdint.h.  Using a "u"
 | prefix is also used in C#: ushort/ubyte etc.  (Note I'd use the
 | unabbreviated "integer" for unbounded integers.)

The words "signed" and "unsigned" do not occur in R4RS or R5RS;
neither does "int".  Scheme owes nothing to C, except for looking so
fine in comparison.  I have rewritten SRFI-58 to use only Scheme
terminology.  The prospective new SRFI is at:
http://swiss.csail.mit.edu/~jaffer/srfi-58-new.html

 |  > inexact         64.bit real                     #nA:real-64
 |  > inexact         32.bit real                     #nA:real-32
 | 
 | These aren't general real numbers, but "inexact real numbers using
 | a floating-point representation."

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-complex-array
  inexact-IEEE-32-bit-floating-point-complex-array
  inexact-IEEE-64-bit-floating-point-real-array
  inexact-IEEE-32-bit-floating-point-real-array
  exact-64-bit-integer-array
  exact-32-bit-integer-array
  exact-16-bit-integer-array
  exact-8-bit-integer-array
  exact-64-bit-nonnegative-integer-array
  exact-32-bit-nonnegative-integer-array
  exact-16-bit-nonnegative-integer-array
  exact-8-bit-nonnegative-integer-array
  char-array
  boolean-array
  object-array

 | >                 char (string)                   #nA:char
 | 
 | Is that 8-bit chars or implemention-defined chars?

Those are Scheme chars (implementation-defined).  Multi-lingual
implementations might have several sizes seamlessly switched behind
the scenes depending on the characters written into them.

 | One could have #nA:char8, #nA:char16 (Unicode), #nA:char32.

Doesn't Unicode have 22.bits?

 | #nA:char would match an #nA:charW for some implementation-defined
 | W (which I guess might be 7 on a PDP-10 ...).
 | 
 | >                 boolean (bit-vector)            #nA:boolean
 | 
 | A boolean has values #f and #t.  A bit has values 0 or 1, and
 | is the same as a uint1.

ARRAY-REF of boolean arrays returns booleans.