[plt-scheme] Error reporting and batch compilation (was: fluid-let-syntax may get flushed)
Lo, on Friday, August 13, Matthias Felleisen did write:
> On Aug 13, 2004, at 8:11 AM, Noel Welsh wrote:
> >
> > --- "Richard C. Cobbe" <cobbe at ccs.neu.edu> wrote:
> >
> >> Case in point: the test cases for my PLT redex implementation of
> >> Jacques take forever to execute, largely because they pull in
> >> SchemeUnit, which in turn pulls in all of the framework stuff.
> >> Compiling to .zos helps somewhat, but then you're back to the batch
> >> model.
> >
> > Interesting. So if SchemeUnit didn't pull in the framework stuff
> > (which is only needed for the GUI) you would be happier? I'm sure
> > this could be arranged, if you are willing to use the text-ui. An
> > incremental testing solution would be a nice thing, but this might
> > solve your problem with less work.
That would solve this one instance, sure, but not the general problem.
I've got another project I'm working on (the updated implementation of
ClassicJava, for those who care) where the AST module takes forever to
execute, because of all the contracts it defines. Again, compiling to
.zos helps significantly, but then it's not really interactive
development any more. (Though (lib "cm.ss") looks like it may help.)
> Tools like SchemeUnit would definitely benefit from an extreme
> model-view separation especially if you can implement both a textual
> and a gui interface and then post the three components on PLaneT.
This model-view separation exists (although one might argue that it's
somewhat primitive), it's just that the text interface isn't very good.
> P.S. I'd actually think that the GUI interface would become a tool one
> day.
It is; Ryan wrote it. It broke N versions of DrScheme ago, though, and
Ryan hasn't had a chance to fix it yet. I don't think he has any plans
to fix it, either, since I gather he wasn't able to get all the
necessary support from DrScheme. In particular, IIRC, the break button
doesn't help when a test case diverges. But you'll need to ask him for
details.
Richard