Vladimir,

Thanks for your response.

On 2020-08-25 11:58 +0800, Vladimir Nikishkin wrote:
> >useful drawing operations can be done with this library without having to
> build a dozen procedures  on top
>
> Unfortunately, the essence of SICP is to "build a dozen of procedures on
> top" as a teaching method :).

Thanks, I think I understand the approach of this SRFI now (thanks also
to John for his SRFI 96 comparison).

> >(3) canvas-refresh needs to be clarified.  "A Scheme object which can be
> used for drawing operations" might be clearer
>
> It is expected that every implementation will have a different way of
> representing these objects.

That's clear.

> > What does "the canvas may not exist unless it has been drawn on" mean?
>
> In the sample implementation, it means "I have generated a unique file name
> to use later to draw, but haven't created the actual file yet. However, if
> a file with such a name had existed, I have deleted it."
> In an abstract implementation, it would mean something like "I checked that
> the graphical subsystem exists and works, but haven't created the actual
> window".
>
> I am not sure how to word this properly.

I suggest something like "The canvas may not actually be created until a
drawing operation occurs.  If canvas-refresh does create a canvas, however,
it is guaranteed to be empty."  This also gets rid of the slight ambiguity
in the current wording.

> >What do drawing procedures do if no canvas has been created
>
> They create it, I added this to the draft. (I'll puch it to my repo and
> will ask for a new draft to be published.)

Thanks for addressing this.  The sentence "if the canvas does not exist, it
is created" seems a little vague in its current position.  Does this apply
to canvas-cleanup, i.e. does it create a canvas to delete?

I think it's sufficient merely to add a note to rogers about canvas
creation.  You've already done this for draw-line and draw-bezier.

> >This is, in my opinion, too specific and should just be image-file->painter
>
> I would be delighted if implementations provided such an option. Shall I
> add it to the "recommended" part?

That's a possibility, but I'd prefer that the format-specific
procedures be the "also recommended" ones, and that the
general-purpose image-file->painter be the primary image loader.
image-file->painter could be specified by "image-file->painter reads
an image from the file denoted by file-name and returns a painter,
similar to that returned by `rogers', ...  file-name must be a file
containing data in some image format supported by the implementation."

I think it's safe to assume that JPEG will be around for a while, but
there's no difficulty in adding the general loader procedure.  The
sample implementation can be a simple wrapper around
jpeg-file->painter.  A crude and bad but portable example;

(define (image-file->painter file-name)
  (let ((len (string-length file-name)))
    (cond ((and (>= len 4)
                (or (string=? "jpg" (substring file-name (- len 3) len))
                    (string=? "JPG" (substring file-name (- len 3) len))
                    (string=? "jpeg" (substring file-name (- len 4) len))))
           (jpeg-file->painter file-name))
          (else (error "unsupported file" file-name)))))

I'm working on a small patch to fix some grammar issues in the document,
which should be ready soon.  Other than that, it looks good.

Regards,

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"For good or ill, when I went off to grad school, I studied
linguistics, so the only computer language I used there was LISP.
It was my own personal McCarthy era." --Larry Wall