Re: number syntax

[willc%tekchips.tek.csnet@CSNET-RELAY.ARPA]

After studying the recent proposal by David Bartley and Mark Meyer, I'm
afraid I have to object to using it in the report.  I probably just don't
understand it, and I might change my mind if they'll explain it to me
better.  I don't have much problem with the syntactic changes they propose.
The main problem I have with their proposal is that it addresses the syntax,
which I don't much care about, but doesn't address the semantic properties
like exactness and integer-ness.  I have repeated most of their proposal
(indented two spaces) in order to point out the parts I object to.

  (4) CL provides only the #C(real real) notation for complex numbers; R^3RS
  provides infix notations for both polar and rectangular forms.  For
  compatibility with CL, R^3RS should support the #C notation and the infix
  forms should be non-essential extensions.

Shouldn't the #C syntax be inessential also, since integer-only
implementations are allowed?  Shouldn't all productions with decimal
points or slashes be inessential as well?

  (5) CL integers may optionally terminate in a decimal point; R^3RS permits
  such a number to be treated as floating point and it is debated whether it
  is to be considered exact.  This is a serious problem, since many
  procedures are defined to accept only integer values.  Is the call
  (INTEGER->CHAR 55.) valid?  We propose that this be a non-essential
  feature in R^3RS.

It seems to me that most procedures that are currently defined to accept
only integer values should have been defined to accept only exact integer
values.  Our concept of an integer needs to be tightened up.  I propose
that INTEGER? be defined to be compatible with

    (define integer?
      (lambda (x)
        (and (real? x) (= x (truncate x)))))

With a definition such as this it seems likely that 55. will be an integer.
The real question is whether it is exact.  I haven't been able to answer
that question on the basis of the proposal.

  We propose the following syntax for numbers in Scheme.  (Recall that
  letter case is insignificant in the grammar and that the rules for <ureal
  R>, <prefix R>, etc., should be replicated for R = 2, 8, 10, and 16.)

  <number>  -->  <real>  |  #c( <real>  <real> )

  <real>  -->  <prefix R> <sign> <ureal R>

  <prefix R>  -->  <exactness> <radix R>
  
  <exactness>  -->  <empty>  |  #i  |  #e

  <radix 2>  -->  #b
  <radix 8>  -->  #o
  <radix 10>  -->  <empty>  |  #d
  <radix 16>  -->  #x

  <sign>  -->  <empty>  |  +  |  -

  <ureal R>  -->  <integer R>  |  <ratio R>  |  <flonum R>

  <integer R>  -->  <digit R>+ #* 

  <ratio R>  -->  <digit R>+ #* / <digit R>+ #*

  <flonum R>  -->  . <digit R>+ #* <expon>
     |  <digit R>+ . <digit R>* #* <expon>
     |  <digit R>+ #* . #* <expon>

  <expon>  -->  <empty>  |  <expon-marker> <sign> <digit>+

I believe the <digit>+ in the above production was intended to be
<digit 10>+.

  <expon-marker>  -->  e  |  f  |  d  |  l  |  s

  <digit 2>  -->  0  |  1
  <digit 8>  -->  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7
  <digit 10>  -->   <digit 8>  |  8  |  9
  <digit 16>  -->   <digit 10>  |  a  |  b  |  c  |  d  |  e  |  f


  Although we have incorporated <exactness> and the use of `#' above, they
  should be stated to be non-essential features of Scheme.  

  Nonessential feature: integers with optional decimal points.  

  <integer R>  -->  <digit R>+ #* .

This production is redundant, since all the strings it generates are
generated by the third production for <flonum R>.  I judge by this
and other redundancies that the name of the non-terminal is intended
to carry semantic freight, but I can't tell what semantics is intended.
This is my fundamental objection to the proposal:  it is a syntax
without a semantics.

  Nonessential feature:  integers and ratios with exponents.

  <integer R>  -->  <digit R>+ #* <expon>
  <ratio R>  -->  <digit R>+ #* <expon> / <digit R>+ #* <expon>

Similarly the production above for <integer R> is redundant, since it is
exactly the same as the first production for <flonum R>.

  Nonessential number productions representing complex numbers.  We worry
  that the forms <real>+<ureal>i and <real>-<ureal>i can be hard to parse.
  Perhaps combining the suffix `i' with the infix `+' or `-' would be
  palatable to those who want this feature.

  <number>  -->  <real> +i <ureal>
     |   <real> -i <ureal>
     |   <real> @ <real>

I'm not sure that this syntax is any easier to parse than the old syntax,
but it isn't any worse.

  Regards,
  David Bartley
  Mark Meyer
  -------

Peace, Will Clinger