>I suggest something like

I ended up adding quite big comments on what I expect different
implementations of window systems do in these cases, hopefully, they
can make things clearer.

>I'd prefer that the format-specific procedures be the "also recommended" ones

I do not think that I agree. Having to implement JPEG loading in 2100
may sound funny, but I do believe that portability is important,
and for things to be portable, they have to be as concrete as possible
for the user, and as abstract as possible for the implementer. Code
written for srfi-203 in 2020 should not become invalid "just because
JPEG went out of fashion by 2040 and nobody thought about adding it".

>also recommended

I added the image-file->painter to the SRFI. I do not think that
making a procedure that is not guaranteed to give the same result on
two different implementations (that may not agree on supported file
formats) a "default loader" is a good idea. Moreover, there is no
"default loader" in this srfi anyway. The only strictly required image
file painter is "rogers", which is not guaranteed to load anything
from the disk.

>Maybe such a simple structure and its operations should just be described at the head of the specification.

It's a way tougher question to answer than it may seem.
In principle, yes, it should. The problem (again) is that SICP thinks
about drawing from a pedagogical perspective, rather than utilitarian.
Both the structure and the operations are described in the SICP in the
detail sufficient to implement them, and this is in fact one of the
exercises.

Moreover, there are actually _two_ implementations agreeing to the
same get/set interface (a list of three lists, and a list and a pair),
this is Exercise 2.47.

SICP, however, has a leaky abstraction here. This chapter speaks about
"painters" accepting "frames" (sets of points, origin and two axes),
but does not specify, which setters/getters the painters are expected
to use.

This SRFI "buys into" one of the implementations (three lists), as I
didn't find how to do this in a more abstract way, but I do not want
to imply that this implementation is the "correct one".

In principle, this is the case where OOP would have been the correct
answer, or just supplying the getter function as a value to the
painters.

On Sat, 5 Sep 2020 at 03:36, Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>
> 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 push 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

--
Yours sincerely, Vladimir Nikishkin