What is this?

What is this?

[skaller]

Can anyone see this error?
--------------------------------------------------------
File "py_interp.ml", line 477, characters 6-545:
This expression has type int but is here used with type unit
---------------------------------------------------------
[exception SystemExit of int]
.....

  method run_file filename : int =
      try
        ignore (environment # set_attr (PyString "__name__") (PyString
"__main__"));
        ignore (environment # set_attr (PyString "__file__") (PyString
filename));
        Py_exec_module.exec_file (self:>interpreter_t)
          (Py_exec.py_exec (self:>interpreter_t)
(environment:>environment_t)) 
          filename
        ;
        0
      with 
      | SystemExit n -> n
      | x -> 
        print_endline ("Error Near line " ^ (string_of_int (fst
source_reference)));
        flush stdout;
        self#py_raise x;
        0 (* dummy value *)

-------------------------------------------------------

This method is NOT called anywhere in the module.
I cannot see where the inference engine gets the
idea that the expression should have type unit.


[That message is really annoying. It should read
" .. but is used _somewhere else_ with type .."
since it always means that. It would be nice
to know where that somewhere else is, since half the
time, that is where the error is]

--
John Skaller, mailto:skaller@maxtal.com.au
1/10 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
downloads: http://www.triode.net.au/~skaller

Re: What is this?

[skaller]

I wrote:
> 
> Can anyone see this error?
[]
> This expression has type int but is here used with type unit
[]
>   method run_file filename : int =
[]
>         Py_exec_module.exec_file (self:>interpreter_t)
                                    ^^^^^^^^^^^^^^^^^^^

I have found the error. While I updated the interface for the module
correctly, (that is, the class type) I did not update the 
abstract interface containing the more abstract class type
to which the 'self' is coerced in the indicated term: in the class type
'interpreter_t',
method 'run_file' has return type 'unit'. Because the inference engine
has not
yet deduced the type of 'run_file' for class type 'py_interpreter', it
uses
the information from the coercion to assume it returns 'unit', then
reports
an error when later finding it actually returns an 'int'.

-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850

Re: What is this?

[Benoit de Boursetty]

On Tue, 16 Nov 1999, skaller wrote:

> Can anyone see this error?
> --------------------------------------------------------
> File "py_interp.ml", line 477, characters 6-545:
> This expression has type int but is here used with type unit
> ---------------------------------------------------------
> [exception SystemExit of int]
> .....
>
>   method run_file filename : int >       try
>         ignore (environment # set_attr (PyString "__name__") (PyString
> "__main__"));
>         ignore (environment # set_attr (PyString "__file__") (PyString
> filename));
>         Py_exec_module.exec_file (self:>interpreter_t)
>           (Py_exec.py_exec (self:>interpreter_t)
> (environment:>environment_t))
>           filename
>         ;
>         0
>       with
>       | SystemExit n -> n
>       | x ->
>         print_endline ("Error Near line " ^ (string_of_int (fst
> source_reference)));
>         flush stdout;
>         self#py_raise x;
>         0 (* dummy value *)
>
> -------------------------------------------------------
>
> This method is NOT called anywhere in the module.
> I cannot see where the inference engine gets the
> idea that the expression should have type unit.
>
>
> [That message is really annoying. It should read
> " .. but is used _somewhere else_ with type .."
> since it always means that. It would be nice
> to know where that somewhere else is, since half the
> time, that is where the error is]

I can't see the error, but I suggest you comment out most of the code. If
you begin with

 try
   0
 with SystemExit n -> n
  | x -> 0

and uncomment things afterwards, you can find where the problem is by
dichotomy. Since you have 6 lines of code, it shouldn't take you more than
3 tries :)

Benoît de Boursetty.