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.