[racket] Poll: Does anybody besides Doug use 'plot'?

On 10/01/2011 10:44 AM, Neil Van Dyke wrote:
> Neil Toronto wrote at 10/01/2011 12:15 PM:
>>> 2. Whether to call the new library "plot" (rather than, say, "plot2" or
>>> "newimprovedsuperplot2000").
>>
>> Yep. That's part of the main question.
> [...]
>> If the answer to #2 is "the new library is called 'plot'", then the
>> answer to #4 is "you have to change (require plot) to (require
>> plot/compat)". And then everything should work.
>
> Thanks, Neil T.
>
> If that's a big point of contention, then would everyone be happy either
> with one of the following?
>
> 1. Call the new library "plot2", and make "plot" be a compatibility
> layer for "plot2". Add pointers in strategic locations of "plot" parts
> of documentation, saying telling reader probably want to use "plot2" for
> new development.

That's what Robby wants. I've tried it that way as well. It works fine.

My main problem with it is when *future* users search for "plot" in the 
documentation. They'd get the pointers in strategic locations, yes, but 
users don't always read text. And the pointers would have to be in a lot 
of places.

> 2. Make the APIs for the old library and new library not conflict, by
> making any necessary changes to the new API, and put both APIs together
> in single library named "plot" that users get with "(require plot)".
> Document the old API parts as deprecated.

I had thought of this, but not seriously checked it out until you 
suggested it just now.

The main incompatibility is how "plot data" is represented. In the old 
library, it's a function from a plot-view% (a descendant of image-snip%) 
to void. There's no way for something like that to communicate its 
bounds to 'plot'. So in the new one, plot data is represented by a struct.

That difference is okay as long as nobody peeks at the plot data, just 
passing it off to 'plot', and combining them using 'mix'. I assume most 
users have done that.

There's wonkiness in the old API. The 'line' function, for example, 
plots functions, parametric functions, polar functions, and parametric 
functions with a polar mapping. Sometimes some keywords matter, based on 
the values of other keywords. It's overloaded and messy.

The 'plot3d' function has a keyword named '#:az', for "azimuth". No user 
needs to know that technical term. It's just the horizontal angle at 
which you view the plot. I called it '#:angle'.

The 'vector-field' function has a '#:style' keyword that determines how 
the arrows are scaled. I use '#:style' for pen and brush styles (dashes, 
cross-hatching, etc.).

There are quite a few little differences like that.

But there are enough similarities that I think I could do this option. 
I'd still want to have a compatibility module, just in case. The 
documentation would be tricky. I'd probably document only new, 
self-consistent functions and keywords, but have notes about extra 
keywords for compatibility, and a separate section on 
backward-compatible functions.

Hmm...

Neil T