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

Generally sounds like a good idea to me (not for this release, tho).

As a minor variation on this, the pinhole property of an image could
either be #f or a pair of numbers and the existence of a pinhole could
trigger drawing it (always). So your animation code would strip the
pinhole at the end, via a remove-pinhole function. Drawing a pinhole
would probably be a matter of drawing a horizontal and a vertical
black line with 50% opacity going thru the whole image that intersects
the coordinates of the pinhole. Something like that.

This would also make it easier to explain (thinking of the docs) since
you could put all pinhole-related discussion at the end.

Oh, and probably it would be nice to have a function called
center-pinhole that takes an image and puts the pinhole in the middle,
since I imagine it would get used a lot (in favor of the more verbose
(align-pinhole i 'center 'center)).

And to repeat what I wrote before, I think you want to have the
current overlay/underlay/beside/above functions "pinhole" as x-place
and/or y-place arguments instead of adding the overlay/pinhole
function.

Robby

On Wed, Jan 13, 2010 at 10:12 AM, Carl Eastlund <carl.eastlund at gmail.com> wrote:
> 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.
>