On Sep 28, 2011, at 12:01 PM, Neil Toronto wrote: > 1. Obviously, Module 2's path should be 'plot'. Right? And its documentation > needs a note that it's deprecated. (I'll do that.)
Yes. It needs a link at the top of the page that points to the expanded capabilities of Module 1 (docs). > 2. Should Module 2 send a deprecation warning to stderr or the log when > 'require'd? I wouldn't bother. > 3. Should Module 1's path be 'racket/plot'? I've also thought of 'new-plot' > (which is a cute pun on "gnuplot" but inconsistent with other names) and > 'rackplot' (which is consistent with 'racklog' and 'rackunit'). Could also go > with "omgraph" or whatever. I'm open to suggestions. I like rackplot. > 4. I didn't write a 'plot/extend' replacement because it would have been > painful and bit convoluted. Also, nearly everything 'plot/extend' provides is > more easily done using either the old 'plot' or Module 1. As of now, it will > just quietly disappear. Is that okay? > 5. I'll have general questions about how to put things in the collects. I > could probably answer them all by looking at a GOOD example. What, in your > opinion, is the archetypal collects library, which would show me How It > Should Be Done? Do not look at 2htdp and hdtp, because teachpacks are different :-) > Last thing: I haven't replaced the 'fit' function, because it has nothing to > do with plotting or the plotting C library! I don't know why it's in 'plot' > in the first place. The C library behind 'fit' will have to stay for now, so > there will still be a bit of a C mess that makes Eli throw up. > > I can replace that too - eventually. I think it would be best to separate > concerns for now. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
