Re: [Scheme-reports] Comments on draft 6

[John Cowan <cowan@x>]

Vitaly Magerya scripsit:

> Thank you. I hope the rest won't get lost and forgotten over time.

They will either be done soon or converted into editorial tickets.

> There are multiple instances of "newly allocated" phrase in the
> report. Do you intend to change them all? (For the record I do not
> object the phrase itself, it is concise and clear, once you know what
> it means, I only wish it to be explained. This is a minor point in any
> case).

I have standardized on the terms "fresh location" and "newly allocated
object" (or list, string, vector, etc.) and defined both, the first in
Chapter 4 and the second in Chapter 6 (though there are a few uses of
"newly allocated" in Chapter 4).

> Maybe something along these lines could be added to lazy description
> on page 17: "(lazy <expression>) is conceptually similar to (delay
> (force <expression>)), with the difference that forcing the result
> of lazy will in effect result in tail call to (force <expression>),
> while forcing the result of (delay (force ...)) will not. Thus
> iterative lazy algorithms that may result in a long series of (delay
> (force ...)) chains can be rewritten using lazy to prevent consuming
> unbounded space during evaluation".

Added.

> I see. Maybe a similar note should be added somewhere? Something like
> "representation of record type bound to <name> is not utilized in this
> report, but it serves as means to identify the record type by further
> language extensions".

Added.

> > [0.0 and -0.0] are equal in the sense of =, but distinct in the
> > sense of eqv?.
>
> So is section 6.1, page 29 wrong to say that eqv? on numbers is the
> same as =?

It doesn't quite say that.  It says that if = returns #t, then eqv? also
returns #t unless the numbers are of different exactness, in which case
it returns #f.  Similarly, if = returns #f, then eqv? must return #f
unless both numbers are NaNs.  You're right that the draft requires 0.0
and -0.0 to be the same in the sense of eqv?, so I have filed ticket
#345 about whether eqv? should be required, forbidden, or permitted to
return #t when its arguments are 0.0 and -0.0 (that is, on systems which
provide -0.0 at all).

> Fair enough, and that question was less editorial than the others, so
> let me clarify. Specifying TAI is an unusual decision, and it seems
> to me that either using Unix time or not providing this function at
> all will be better, but I can only claim so if we agree on goals of
> introduction of this function.

I personally agree that Posix time would have been better, but was
outvoted.

> There are multiple things I would use current-second for. In the
> absence of proper date library I may try to derive wall clock time
> from current-second. Unfortunately to do this using TAI you'd need a
> constantly updating leap second table, and this is impractical.

Actually, such tables are available from IERS and from NIST and other
national time organizations over the Internet.  They need not be
continuously updated, only every month (or in practice every six
months).

> I may also use current-second to measure time intervals (as people
> often do with Unix time functions available in many languages), but
> this is conceptually wrong, because current-second is not monotonic by
> design: it jumps when user adjusts clock (whether is is TAI or Unix
> time). Besides, if we have current-jiffy, that is what should be used
> to measure time intervals.

Agreed.

> Given the problems with obtaining TAI and the ease of obtaining
> Unix time, I would not be surprised if implementations would define
> current-second as current-unix-time + 34, which is basically a bug
> (you'll need to change that to 35 at the end of this June).

Indeed, the report does not exactly encourage such behavior, but it says
that it may be the best that many implementations can do.

> I see. Is this an important optimization? Are there implementations
> that have similar functionality (i.e. fixnum-based monotonic timer)?

SRFI 18 does not require a fixnum or even integral result, but permits
an implementation-specified epoch without saying why.  I can think of no
other reason.

> I would have guessed that most just provide an inexact number of
> seconds, and not bother to save a memory allocation on this operation.

My multiple-Scheme test system is down right now.  Chibi provides
SRFI-18 and uses the Posix epoch, which currently is a fixnum.

-- 
John Cowan    cowan@x    http://ccil.org/~cowan
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports