[racket] overlay and overlay/xy

I shifted entirely to using 2htdp/image this semester; now all
the pinhole stuff is gone and we can do "image arithmetic" with various
combinations of overlay, underlay, above, and beside, which is great.

The problem is, overlay/xy now sticks out like a weird wart on the
system, and it's profoundly counterintuitive to my students (and me,
actually), in at least two important ways:

1) One might expect the following two expressions to yield the same
result:

  (overlay    red-circ     black-sq)
  (overlay/xy red-circ 0 0 black-sq)

but they don't.  All the base image arithmetic functions default to
aligning at the middle, but overlay/xy doesn't.  Which means that if
(overlay a b) is almost what you want, but just requires a nudge of a
few pixels, you can't just start with an overlay/xy with offset of 0 0
and tweak from there.

This expectation doesn't only come from the time-honoured "guess based
on the function name" strategy; it's also based on the description in
the documentation:

  Constructs an image by overlaying i1 on top of i2 after shifting i2 over
  by x pixels to the right and y pixels down.

which would lead you to believe that it's just like overlay, except with
an offset.  The docs could be clarified here, but that just raises the
further question, "why is overlay/xy based on a top-left alignment but
overlay based on a middle-middle alignment?"  Who knows?

2) The semantics of the offset are backwards.  Or at least, they feel
backwards.  When my students typed

  (overlay/xy red-circ 10 0 black-sq)

they expected the red circle to be overlaid atop the black square and
offset to the right by ten pixels; but in fact it is the reverse.  The
natural interpretation of this is *not* "oh it's the black square that
got shifted to the right", but rather, "why is the red circle shifted to
the left when I gave it a positive offset?"  That's because it's the
red circle being overlaid, so you expect it's also the red circle that
gets shifted.  (The confusion here is only magnified by a confound with
the y-increases-down property of the graphics system.)  I assume this is
effectively a holdover from version 1 of the library, where it was the
the second image overlaid upon the first, and thus it made sense for the
second image to be the one that was offset, but it's still confusing
(although here at least the documentation is correct).


The net effect is that the only reliable way to use overlay/xy is to try
a bunch of different numbers until one looks right, which is a big pain
but less of a pain than having to figure out the weird offsets and
backwards semantics of the function.  I'm trying to decide if I can just
tell them to avoid overlay/xy entirely, but I don't think I can---although 
place-image is great, sometimes you need an offset without cropping.

-- 
-=-Don Blaheta-=-dblaheta at monm.edu-=-=-<http://www.monmsci.net/~dblaheta/>-=-
"On two occasions I have been asked [by members of Parliament!], `Pray,
Mr.  Babbage, if you put into the machine wrong figures, will the right
answers come out?'  I am not able rightly to apprehend the kind of
confusion of ideas that could provoke such a question."
							--Charles Babbage