(kawa pictures) square-limit pictures

(kawa pictures) square-limit pictures

[Sudarshan S Chawathe]

I just put up a rather trivial "project" on GitLab that uses the (kawa
pictures) library to recreate the classic square-limit pictures example
from the SICP textbook:

  https://gitlab.com/chaw/square-limit

It was a fun trip down memory lane for me, and perhaps it will interest
others too.

Regards,

-chaw

Re: (kawa pictures) square-limit pictures

[Per Bothner]

On 10/30/2016 08:55 AM, Sudarshan S Chawathe wrote:
> I just put up a rather trivial "project" on GitLab that uses the (kawa
> pictures) library to recreate the classic square-limit pictures example
> from the SICP textbook:
>
>   https://gitlab.com/chaw/square-limit

Neat.  What do you think of the idea of taking
the SICP functions and moving them into a new library?
Perhaps named (kawa pictures sicp) ?
Or maybe just (sicp pictures) ?
Racket uses (require sicp-pict)

Unfortunately, I haven't found any clear copyright
statement for the code in SICP, but I think there
implied permission - and also fair use should apply.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: (kawa pictures) square-limit pictures

[Sudarshan S Chawathe]

> From: Per Bothner <per@bothner.com>
> Date: Sun, 30 Oct 2016 09:39:11 -0700

> Neat.  What do you think of the idea of taking the SICP functions and
> moving them into a new library?  Perhaps named (kawa pictures sicp) ?
> Or maybe just (sicp pictures) ?  Racket uses (require sicp-pict)

I think it's a great idea.

An issue related (I think) to the choice of names is how closely the
library follows the original SICP pictures language v. how closely it
tries to match Kawa's composable pictures style.  Here I am thinking
about, for instance, the implementation of "below" using SICP's explicit
notion of painting into frames (and frame transformations) v. using
Kawa's re-center and vbox.  When I first started writing the
square-limit example, I went with the first option, but then decided
that is probably not in the spirit of the Kawa pictures library.  There
is probably value in having both methods.

I will take a look at how the Racket library does things.

Regards,

-chaw

Re: (kawa pictures) square-limit pictures

[Per Bothner]

On 10/30/2016 11:54 AM, Sudarshan S Chawathe wrote:

> An issue related (I think) to the choice of names is how closely the
> library follows the original SICP pictures language v. how closely it
> tries to match Kawa's composable pictures style.  Here I am thinking
> about, for instance, the implementation of "below" using SICP's explicit
> notion of painting into frames (and frame transformations) v. using
> Kawa's re-center and vbox.  When I first started writing the
> square-limit example, I went with the first option, but then decided
> that is probably not in the spirit of the Kawa pictures library.  There
> is probably value in having both methods.

I've considered adding a procedure to help bridge the SICP
model and the Kawa model.  Something like:

(transform-to RECT PICTURE)

This would be equivalent to some (with-transform TRANSFORM PICTURE)
such that the bounds of the result matches RECT.

More generally RECT could be a parallelogram.  (Note a rotated rectangle is
a parallelogram but is not considered a rectangle.) In that case the
bounds of the transform would not match RECT, but would have the
same bounds as RECT.

The RECT corresponds to the "frame" of SICP.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: (kawa pictures) square-limit pictures

[Sudarshan S Chawathe]

> I've considered adding a procedure to help bridge the SICP
> model and the Kawa model.  Something like:
> 
> (transform-to RECT PICTURE)
> 
> This would be equivalent to some (with-transform TRANSFORM PICTURE)
> such that the bounds of the result matches RECT.

This procedure would be nice to have.

> More generally RECT could be a parallelogram.  (Note a rotated rectangle is
> a parallelogram but is not considered a rectangle.) In that case the
> bounds of the transform would not match RECT, but would have the
> same bounds as RECT.
> 
> The RECT corresponds to the "frame" of SICP.

On a related note, regarding Racket's sicp-pict package you noted
earlier: Based on a quick look at the source code, it seems to use a
bitmapped drawing canvas as the basis for segments->picture from SICP,
with the other SICP procedures being mostly verbatim (with some flipped
names, such as frame-edge1 instead of edge1-frame, I assume to conform
to current Scheme naming conventions).

I'm thinking of writing something similar with Kawa.  Actually I have a
lot of it done, but I'm working on how best to hook things into the Kawa
graphics interface.  (The way I did it earlier was a bad hack.)

Regards,

-chaw