Another clm problem

Richard A. O'Keefe ok@atlas.otago.ac.nz
Wed, 3 Mar 1999 13:31:41 +1300 (NZDT)


	>Here's the problem I ran into with Clean 1.3 on Solaris.
	>        clm Neural2
->
	>        Command line error: unknown flag -i

	I have never seen this error before.  The compiler (cocl) no
	longer supports -i in Clean 1.3.2, but probably did in Clean
	1.3.  May be you are using clm from Clean 1.3 and cocl from 1.3.2.
	
Not possible.  At the time I got that error, I had never even _tried_ to
install Clean 1.3.2.  Now that I've got the PATH business sorted out, I
_have_ installed Clean 1.3.2 with no further trouble, and the bug has
gone away.

	>The program does no IO.  It's my neural net program stuffed into one
	>file and trimmed down a bit.  I was hoping that seeing it all as one
	>file might help the compiler a bit.
	
	This may help if:
	
	- Overloaded functions are exported (a function type with a '|'
	  in a .dcl file).  If the caller and callee are in the same
	  module, the compiler can generate a specialized version of the
          function.

I have no overloaded functions.

	- Functions that return a tuple with lazy elements are exported.
	  The compiler could generate a specialized version with more
	  evaluated or unboxed tuple elements.

Hmm.  Does that mean that it's worth my while declaring

    f :: .... -> *(!T1, !T2)

instead of

    f :: ... -> *(T1, T2)

	- Functions that return functions are exported.  Again the
	  compiler may generate a specialized version.

Unusually for me, none of the code in this program does this.

	- Not all strictness information is exported (use -lset or
	  Strict Export Types to detect this).

Ah!  I should warn you that I'm looking at man/man1/clm.1
	.TH CLM 1 "January 8 1998" "Version 1.3.1"
and it says
	.IP -lst
	show types of functions for which not all strictness
	information has been exported.
It does _not_ mention any '-lset' option.  This was also true in
the 1.3 manual.  I have tried using '-lst' in each version of clm
I've had that claimed to have it, and never had any luck.

Time to fix the manual page.

	- The function is used once.  The compiler can use strictness
	  and unboxing information from the call to prevent eval's and
	  (un)boxing.
	
This _does_ happen.  I measured a 1% speedup, but that's within
measurement error, alas.

Thank you for this information.