[MLton] funny error message

[skaller]

On Mon, 2005-09-26 at 14:08 -0700, Stephen Weeks wrote:

>  If one
> uses MLton for any length of time, one quickly learns that it takes a
> long time before the first type error is reported, and no time at all
> for subsequent errors. 

What do you mean 'a long time'??

I regularly did (on my old 700Mhz PC) 10 minute compiles,
fixed ONE error, and recompiled the whole project.

When I worked on the C++ telco project, compiles 
OF ONE SUBCOMPONENT took 1-2 hours (on a 12 CPU Solaris
machine ..)

i do not consider that 'a long time'. When I learned
programming, 24 hour turnaround was the rule... if you
were totally insane you could sometimes get up at 6 am
in the morning and get two compiles a day done!

>  Further subsequent errors messages are
> generally pretty good.  So, it is clearly a win for MLton to report
> those subsequent messages. 

No, it isn't clear: I would not want this.
I just don't want to deal with more than one error at a time,
unless I really do have a really slow compiler.

Perhaps I'm too used to Ocaml: with polymorphic variants,
a single error can be 100-500 lines (NOT kidding).
I would never even SEE the first error if there were two
of them!

But Ocaml compiler is lightning fast, and it does separate
compilation, so we're talking subsecond compile times.

Dang it, this is TOO FAST! I don't have time to make
a cup of coffee while it is compiling! :)

>  Personally, I often use MLton on itself, a
> >100K line program that sometimes takes 30 seconds before the first
> type error is reported. 

HAHAH .. 30 seconds???? I won't even make it into the kitchen
to put the jug on .. :)

>  In this situation and others, I often
> successfuly process 5-10 error messages in a batch with no difficulty.
> I and other MLton users would needlessly waste a lot of time if we had
> to recompile for each error.
> 
> If someone wants to use MLton and only ever read the first message
> they can.

Please put a switch that limits the number of errors reported!
So weird people like me (when the x86_64 version comes out)
can stop it spewing all over the screen!

Yup, I am weird .. I hate multiple error with a vengeance,
I consider it one of the worst design stupidities of gcc:
regularly tells me it can't find an include file and spews
a heap of errors about undefined symbols -- and until
recently no way to stop it. This is really bad, the errors
go off the top of the console and I cannot see the error
causing the problem -- I have to run the compile again
and press Ctrl-S to stop it .. or pipe it into "less",
the latter being hard to do if the compile is done
from inside a script: in either case, I have to recompile,
and in the latter case that is a pain because I may
have to re-run a build script from the start.

So I want it to STOP on the first error, so the bottom
of the console shows me what went wrong. Spewing a heap
of errors actually eliminates the first error diagnostic,
which is often the one causing the others.  Hence: counterproductive.

Yup, I'm weird. I don't use debuggers. Some people swear
by them, I hate them. I just add print statements. It always
works, on all systems, and is easy, and tells me what I want
to know. Debuggers take skill to learn, differ between systems,
often can't tell you what you need to know, and are themselves
often buggy.

So people differ .. just don't assume there is no downside
to spewing multiple errors out. Yeah, I used to use IDE's
but I never learned Emacs, and Vim is too painful to bother
setting up to capture compiler output -- so I run my compiles
in a terminal  .. and the really brain dead versions
have a limited scrollback (eg xterm) -- once the error is scrolled too
far off the screen, there is no way to ever see it again.

Another point: it is REALLY bad if the errors are mixed in  
with bunch of warnings. If you stop on error, then the
error is always (a) the only one and (b) the last diagnostic.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net