>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 :).
>(3) canvas-refresh needs to be clarified. "A Scheme object which can be used for drawing operations" might be clearer
I am hesitant about calling it a scheme object. For example, the reference implementation returns a uuid-generated string. While a string is certainly a scheme object, it's emm... not some kind of a scheme object specific to drawing...
I am not sure how to describe this properly.
It is expected that every implementation will have a different way of representing these objects.
> 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.
>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.) SICP is very explicit about this. When drawing procedures are called, they draw.
> if there are multiple canvases?
SICP doesn't specify this. In the sample implementation, the canvas ' name and dimensions are parameter objects (as in r7rs), so parameterizing them lets you work with multiple canvases.
The default name for the canvas is generated at library loading time. Not use if it is a good idea, as it will be littering the disk with files, but at least the user is not obliged to use the default canvas.
>it seems like it would be easy to create a version of
the language with no global state
Kawa does something like this. I would actually be very grateful to anyone who would do a Kawa version of the SICP's language on top of Kawa's drawing library. I had it on my todo list (kawa seems fun to try any way), but so far was too busy with the ICFP. All code contributions welcome.
>`rogers' seems far too specific to be useful
Sorry, I can't do anything about that. That's what SICP has and uses in the examples.
>Providing image-file->painter and showing an example with "rogers.jpg" or the like is probably all that's needed to show how to implement `rogers'
That is how it is implemented in the sample implementation actually.
>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?
On the other hand, I would like the code to be as portable as possible. Mandating _one concrete_ encoding method means that demos which work with these files also work on other schemes implementing this srfi pedantically. image-file->painter would be vaguer.
>Are these supposed to be included in the SRFI, or are they internal
to the sample implementation?
They are internal. I'd encourage the implementations to provide them, but SICP never uses them, so I can't require that.
>it's a very limited core which
would need significant extension to be used for any other purpose
SICP is one of the biggest applications of Scheme. It is a bit sad, but at least partially true.
Also, codifying a one-fits-all drawing language seems a very hard task, given the range of setups on which Scheme works. It is probably possible, but my level of abstract thinking is just not enough.
In particular, I would like to avoid codifying anything related to canvas-name and canvas-size at all, because some systems just have a single display, and some don't even have any pixels.
>Feel free to add any or all of the above prose to the
SRFI 203 Rationale.
I added the part that explains the SRFI-96 analogy. Thank you for contributing.