seconded by Vladik Kreinovich, the discussion period now
begins, and will end after Wednesday, June 26, 2013.
I append the motion and rationale.
Discussion on this motion will proceed according to the rules for
position papers (quorum and simple majority).
Juergen: Please place the motion and associated information
in the appropriate place on the web page, as
you have aptly done in the past.
Acting secretary: Please record the transaction in the minutes.
As usual, please contact me if you need the password to the private
area of the P-1788 web site.
Best regards,
Baker (acting as chair, P-1788)
P.S. Note the discussion period extends through the time for
our in-person P-1788 meeting in Edmonton.
---------------------------------------------------------------
======
Motion
======
The syntax and semantics of interval literals shall be
- as specified in Draft 7.1 circulated as
20130402Level1and2textV7.1Sent.pdf;
- with the addition of the singleton interval form [x] which is
equivalent to [x,x].
The standard will not at this stage include a facility for named
constants such as pi to be included in the definition of an
interval literal.
=========
Rationale
=========
People of repute have supported the 3 different forms of number
literal and 4 forms of interval literal, so I think they will
prove useful in practice. The [x] form is a trivial addition,
very common in the literature (and used by the Sun interval
languages).
I'm less certain of allowing more than one kind of number
literal in one interval literal, e.g.
<22/7 +- 0x6p-3>
(encloses \pi, I think). E.g. can parsing problems occur?
I'm also not sure the proposed syntax is locale-proofable.
Locale experts please help.
So people looking for nasty examples would be helpful.
The reason for omitting named constants is that when proposed
before, people thought "Ah, that means we can have constant
expressions as well". If one allows (exact real) pi as an
endpoint, say, then surely one needs pi/4? pi/6? But where does
one stop? What about 1.23+tan(pi/7)? With only a few operations
allowed, one can produce expressions whose sign is incredibly
hard to determine, or undecidable I believe.
So any such feature should await a revision of the standard IMO.
---------------------------------------------------------------