[plt-dev] 2htdp/image: Where oh where have my pinholes gone?

Okay, I'll make a proposal that hopefully gives us enough cake to both
eat and have.

Add the following primitives to 2htdp/image (some are, of course, familiar):

(put-pinhole i x y) ;; produce an image with i's appearance, and
pinhole at (x,y)
(move-pinhole i dx dy) ;; for i with pinhole (x,y), produce i with
pinhole (x+dx,y+dy)
(align-pinhole i ax ay) ;; align pinhole of i at top/middle/bottom,
left/middle/right, etc.
(image-pinhole-x i) ;; get pinhole x coord
(image-pinhole-y i) ;; get pinhole y coord
(overlay/pinhole i1 i2 is ...) ;; overlay images on their pinholes

The above allows arbitrary "pinhole math" to line up images.  It also
allows someone who has "graduated" to using pinholes to achieve all
the non-pinhole combinations using just the pinholes.

Preserve the following equalities for the existing combination functions:

(overlay is ...) =
  (put-pinhole (overlay/pinhole (put-pinhole i 0 0) ...) 0 0)
(overlay/xy i1 x y i2) =
  (put-pinhole (overlay/pinhole (put-pinhole i1 x y) (put-pinhole i2 0 0)) 0 0)
(overlay/align ax ay is ...) =
  (put-pinhole (overlay/pinhole (align-pinhole is ax ay) ...) 0 0)

They don't need to be implemented that way, but the behavior should be
like that: the normal over/underlay functions (a) always ignore the
pinhole of the source images, and (b) always produce an image with
pinhole at (0,0).

Most importantly, though, any program that doesn't use the explicit
"pinhole" primitives should never produce an image with a pinhole
anywhere other than (0,0).

Once a program gets around to using pinholes, they are important and
should be respected by equality.  Otherwise you can combine two sets
of images that are pairwise "equal" but get different result images.
However, for the reasons Matthias described below, an image with a
pinhole on it should be visually distinguishable from one without, or
with a different pinhole.  So I propose that, at the REPL or in
check-expect dialogs, a pinhole should be given an explicit rendering.
 There should be a box around the image, and it should either have
sort of "targeting" marks at the x and y positions of the pinhole, or
it should just have text similar to "pinhole = (10,-30)".  On an
animation canvas, of course, this should not show up.

This raises the question of whether "with a pinhole" recognizes images
with an explicit pinhole of (0,0) from images with no pinhole at all;
it is not the most critical thing, but I think for a program that sets
pinholes consistently, it would be nice to always have the border, and
thus distinguish "no pinhole" from "pinhole at (0,0)", if only in this
one place.

I think this proposable is implementable, and I think it addresses the
issues I have seen, both for people who want pinholes and for people
who want pinhole-free image programming.

How does this sound?  Do we like it?  Do we think pinholes are useful
enough to try to fit them into the 2htdp design constraints?

Carl Eastlund

On Wed, Jan 13, 2010 at 10:23 AM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> To clarify:
>
> Say you run a test like this:
>
>  (check-expect (image-producing-function 1 "true")
> expression-that-creates-expected-image)
>
> and it fails. Naturally, you do this in the REPL:
>
>> (image-producing-function 1 "true")
> some-image
>> expression-that-creates-expected-image
> an-image-that-looks-exactly-like-some-image
>
> ;; you're confused and you run an equality check:
>
>> (equal? (image-producing-function 1 "true")
>> expression-that-creates-expected-image)
> false
>
> Now you're really confused, and you're angry, because clearly there must be
> a bug in this damn software that your instructor imposes on you even though
> everyone knows that in a first course you should learn Java or at least C++,
> well may be Basic. So you stomp into your professors office and yell. At
> that point he pulls out a standard function -- not in the released library
> mind you -- and shows you're just not thinking properly:
>
>> (image+pinhole (image-producing-function 1 "true"))
> some-image
>> (image+pinhole expression-that-creates-expected-image)
> an-image-that-looks-different-from-some-image
>
> So now that you have been shown off again, you know what's going on. This
> guy is just trying to humiliate you. You are going to write a bad eval for
> him and you're going to bad-mouth this stupid software wherever you can.
>
> ;; ---
>
> The above account is fictional. All possible connections between the
> characters and real-life people is coincidence.