Trying to get a NN code going

[Zuurbier, E. - AMSXE]

> the program gets a 'rule X in module Y does not match' error.
> This applies to both the SPARCstatation and the PowerMac.
> I know what the immediate cause is (calling an elementary matrix
> update function with arguments of the wrong sizes), but I don't
> know _where_ it is happening in the program or what the sizes
> actually are.
> 
> This is the first Clean program I've had where the compiler hasn't told
> me about all the bugs,
> 
I guess you don't expect any compiler to tell you about
'index out of range' errors. But on the other hand, if you get
'rule X in module Y does not match' I expect you had a
warning about that when you compiled it. If you hadn't,
Nijmegen might be interested in the bug.

>  and I'm wondering how other Clean programmers go
> about debugging their code.
> 
My Mac occasionaly blows up (a bomb, system error window).
I usually consider that a compiler bug, not a bug in my
application. If I don't have the time to wait for the next version,
I debug and may find a way around the bug.

>   In SML, I'd just whack in a few print
> commands and be away laughing.
> 
You can put in some print commands in Clean too. For instance
replace any expression x of class toString by (Debug "expr" x) where

Debug :: !.String !a -> a | toString a
Debug label a = KStrict file a
where	file	= fwrites (label+++"="+++toString a+++",") stderr
		
KStrict :: !.b .a -> .a
KStrict b a = a

If the expression does not belong to class toString, you can fiddle
with Debug, or use DebugL below.

DebugL :: !.String !u:a -> u:a
DebugL label a = KStrict file a
where	file	= fwrites label stderr

But still, debugging in Clean is a pain. Luckily it is not often
necessary, as the compiler spots so many errors. I recently
had a bug where the program turned out to be O(2^n) where
I expected it to be O(n). Clean's time profiler might have helped
but I haven't tried it. It turned out that I did a pattern match one
line too early. Nothing wrong with the semantics, but it was
very hard to find the cause. Things like these happen occasionally
with a compiler that is so smart, and a language that has so many
nice features, of which lazy evaluation is only one. This all
makes planning a programming project quite a bit harder:
Everything might go at the speed of light, or I waste much of that gain,
chasing a bug.

Regards Erik Zuurbier