Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion to finalise interval literals



Juergen,

I agree and think this would be a step in the right direction.

All the standard needs to say is that no matter the representation of an interval, internal, or external, and during the conversion from one representation to another, containment must always be guaranteed.

Then leave it up to the language and compiler folks to deal with the syntax and semantics that they and their customers most like to make life easy and transparent for themselves.

Cheers,

Bill



On 6/7/13 11:02 AM, Jürgen Wolff von Gudenberg wrote:
P1788
as already stated in one of my last emails, I think interval literals should not be required. They will involve languages and compilers, and ,hence, augment the workload in dissemination the of standard.

so change the "shall" into a "should"
Juergen

Am 05.06.2013 11:51, schrieb John Pryce:
P1788
Though motion 44 passed, there hasn't been IMO sufficient discussion on the form of interval literals. I propose this, to crystallise people's objections if any, get helpful modifications, and hopefully lead to a consensus.
John Pryce

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