New draft (#2) of SRFI 226: Control Features Arthur A. Gleckler (10 Sep 2022 01:26 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (30 Sep 2022 07:32 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (30 Sep 2022 19:15 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (30 Sep 2022 20:08 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (30 Sep 2022 21:22 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (01 Oct 2022 13:14 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (01 Oct 2022 18:56 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (01 Oct 2022 21:10 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (03 Oct 2022 11:39 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (03 Oct 2022 13:21 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (03 Oct 2022 14:59 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (07 Oct 2022 16:22 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (07 Oct 2022 21:36 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (08 Oct 2022 00:13 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (09 Oct 2022 16:07 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (09 Oct 2022 20:30 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (10 Oct 2022 06:26 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (10 Oct 2022 16:48 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (12 Oct 2022 06:27 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (13 Oct 2022 00:02 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (13 Oct 2022 06:40 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (13 Oct 2022 15:31 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (13 Oct 2022 15:51 UTC)
Re: New draft (#2) of SRFI 226: Control Features Arthur A. Gleckler (30 Sep 2022 23:35 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (27 Oct 2022 06:01 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Feeley (29 Oct 2022 02:54 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (29 Oct 2022 08:13 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Feeley (29 Oct 2022 12:49 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (29 Oct 2022 13:49 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (29 Oct 2022 18:49 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (03 Nov 2022 17:02 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (04 Nov 2022 19:54 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (29 Oct 2022 15:38 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (29 Oct 2022 16:31 UTC)
Re: New draft (#2) of SRFI 226: Control Features John Cowan (29 Oct 2022 21:52 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (30 Oct 2022 08:35 UTC)
Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen (28 Oct 2022 15:17 UTC)

Re: New draft (#2) of SRFI 226: Control Features Marc Nieper-Wißkirchen 10 Oct 2022 06:26 UTC

Am So., 9. Okt. 2022 um 22:29 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Oct 9, 2022 at 12:07 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>>
>> By not exporting the record type itself but only its type predicate
>> you would model an abstract record type in R6RS.
>
>
> By an abstract type I mean one for which it is possible to create subtypes but not instances, as in C++. Java, or Python.

I know; that's why I wrote only to export the type predicate (but not
a constructor).

That said, the notion of an abstract type doesn't make much sense in
the SRFI 76/R6RS/SRFI 99/SRFI 131/SRFI 136/SRFI 150 model of records
and inheritance.  Assume that you had a record type "foo", which is
abstract (in the above sense) and which you can inherit from.

Then you just have to write

(define-record-type foo2
  (parent foo))

and you end up with an equivalent record type that is no longer
abstract but whose instances are more or less equivalent to instances
of "foo".

In the context of C++ or Java, abstract base classes make sense
because they have virtual methods that have to be overridden to create
a non-abstract child type (so the above "foo2" example would not
work).  With Scheme records, the closest analog would be like this:

(define-record-type abstract-base
  (fields method)
  (protocol
    (lambda (p)
      (lambda (method)
        (p (assert method))))))

(define abstract-base-do
  (lambda (this . args)
    (apply (abstract-base-method this) this args)))

(define-record-type concrete-class
  (fields x)
  (protocol
    (lambda (n)
      (lambda (x)
       ((n method-implementation) x)))))

(define method-implementation
  (lambda (this y)
    (+ (concrete-class-x this) y)))

>> As far as an epoch is concerned, on the lowest level, I would not talk
>> about this notion but would model the physical notion of Newtonian
>> time. Maybe this is my main problem with SRFI 19 in the context of
>> SRFI 226. SRFI 19 does not model Newtonian time; instead, it models
>> representations (in terms of units) of the physical time observable.
>
>
> It's true that SRFI 19 and friends don't deal in Newtonian time.  Rather, they are a finite approximation to Leibnizian time, in which there is no "absolute, true and mathematical time", but only relative (not relativistic) time: time is what we infer from events, rather than events being situated in time.  Note however that Newton himself said that his absolute time "by another name is called duration".  So SRFI 19's time is perfectly respectable philosophically.

I meant "Newtonian time" in the physical sense of the word (as opposed
to time being a part of Minkowskian or general spacetime), so the
philosophies of Newton or Leibniz do not necessarily apply.  In any
case, I understand Leibniz's point of view differently. I would
Leibniz's point of view instead call Mach's principle (at least one
form of it) applied to time alone (and not spacetime). What Leibniz
says is that there is no independent time observable; instead, time is
an observable dependent on other observables. For example, if I have
an unchanging body in an otherwise empty universe, Leibniz would say
that there is no time because there is no observable from which it
could be derived. Now if the ball rolls on a line, a time observable
can be constructed by equating time with the ball's position on the
line.

>> It would be the same as asking about the unit of measurement of some
>> length like the distance between the earth and the sun.
>
>
> I don't understand this analogy.

With SRFI 19, you can ask for the type of a time value (e.g. UTC
time), i.e. for the epoch. (But then we don't talk about (absolute)
time itself, but obviously about a derived concept, namely a
particular representation.)

[...]

>> It's again a question of representation and not of the underlying
>> abstract entity. And even in the context of a representation, it is
>> usually easier to work with single numbers (e.g. multiples of the
>> jiffy) than with pairs of numbers.
>
>
> Jiffies are often too long.  I use nanoseconds because that is the unit of Posix file times, even though times are not kept as precisely as that on any actual file system.

Nanoseconds would be fine with me as well. But what's the purpose of
jiffies in R7RS then?

[...]