Just now, Robby Findler wrote:
> On Thu, Sep 29, 2011 at 1:25 PM, Eli Barzilay <e...@barzilay.org> wrote:
> > Just now, Robby Findler wrote:
> >> On Thu, Sep 29, 2011 at 1:15 PM, Eli Barzilay <e...@barzilay.org> wrote:
> >> > Just now, Robby Findler wrote:
> >> >> I don't think that what I said implies this. A compatibility layer
> >> >> using Neil's new library is what was offered (or so I thought). I
> >> >> think we just want something that has the same Racket-level UI and
> >> >> something reasonably close in the pictures you get out, as discussed
> >> >> earlier.
> >> >
> >> > If it's just that layer (rather than keeping the C code in), then it's
> >> > not completely compatible anyway. (And I don't see a point in keeping
> >> > a "strict" backward compatibility if it's not strict anyway.)
> >>
> >> We seem to be miscommunicating. I'm saying that it seems likely that
> >> people have scripts and things that use the API of the plot library
> >> to build graphs and things in various places. I'm saying that it
> >> seems unlikely that people have programs that depend on a
> >> pixel-perfect rendering.
> >
> > The issue is not pixel placements, it's keeping the C code that was
> > ripped out of gnuplot.
>
> So I guess I don't understand. Why would we want to keep that? (I
> can see why we would want to get rid of it.)
Because you wanted to have a completely compatible interface?
(Excluding pixels.)
My point was that if you don't keep it (which I very strongly prefer),
then you don't have a compatible interface to plot anyway, and
changing the name from `plot' to `plot/compat' makes more sense.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
