Greetings!

The first compile deduces (nil fixnum) for the signature, which is
then noticed as being changed by the second compile.  This is correct
at the current level of functionality.

Your earlier reported problem of our-getcharn is apparently due to
some proclaims somewhere asserting a return type of t when the caller
is compiled, but then which is overriden as return fixnum when the
function is actually compiled.  The easiest workaround is likely to
get rid of the proclaim for our-getcharn, or to make sure our-getcharn
is compiled befoe the caller in the same running image.  I'm working
on a more comprehensive solution.  Recompiles from partially
macroexpanded source stored on the plist are triggered when
conflicting call signatures are loaded.  Thought/suggestions on this
approach always most appreciated.  Its almost working here now.

Take care,

Robert Boyer <[EMAIL PROTECTED]> writes:

> Here's a mysterious warning.
> 
> Bob
> 
> GCL (GNU Common Lisp)  2.7.0 ANSI    May 20 2006 13:25:20
> >(defun foo () (char-code (char "abc" 1)))
> (compile 'foo)
> (defun foo () (code-char (char-code (char "abc" 1))))
> (compile 'foo)
> 
> FOO
> >
> ;; Compiling /tmp/gazonk_22282_0.lsp.
> #<compiled-function FOO>
> NIL
> NIL
> 
> >
> FOO
> 
> >
> ;; Compiling /tmp/gazonk_22282_0.lsp.
> ; (DEFUN FOO ...) is being compiled.
> >>>>>>>>>>>>>>>>>;; Warning: ret type mismatch in auto-proclamation (INTEGER 
> >>>>>>>>>>>>>>>>>-2147483648
>                                                     2147483647) -> T
> 
> 
> 
> 

-- 
Camm Maguire                                            [EMAIL PROTECTED]
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel

Reply via email to