caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Type inference and marshalling
@ 2011-07-05 13:59 malc
  2011-07-05 14:18 ` Wojciech Meyer
  2011-07-05 23:24 ` Jacques Garrigue
  0 siblings, 2 replies; 7+ messages in thread
From: malc @ 2011-07-05 13:59 UTC (permalink / raw)
  To: caml-list

Perhaps someone could explain why following behaves the way it does:

~$ ocaml
        Objective Caml version 3.11.2

# let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic i;;
Warning Y: unused variable j.
val f : in_channel -> unit = <fun>
# let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic j;;
Error: This expression has type int but an expression was expected of type
         int64

-- 
mailto:av1474@comtv.ru

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Caml-list] Type inference and marshalling
  2011-07-05 13:59 [Caml-list] Type inference and marshalling malc
@ 2011-07-05 14:18 ` Wojciech Meyer
  2011-07-05 14:54   ` Mathias Kende
  2011-07-05 23:24 ` Jacques Garrigue
  1 sibling, 1 reply; 7+ messages in thread
From: Wojciech Meyer @ 2011-07-05 14:18 UTC (permalink / raw)
  To: malc; +Cc: caml-list

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

I think that's because i is being unified with int64 type in the seek_in
call. So the type of i will be int64, and input_value polymorphic type
variable will be int64.
The unused binding j is not taken account and thrown away, so the type
system will not take into account + operator that will cause i to be int.
Why the unused binding is being thrown away before type checker, I don't
know, maybe somebody could explain possibly.
So from this is obvious why the second statement fails to type check.

Cheers;
Wojciech

On Tue, Jul 5, 2011 at 2:59 PM, malc <av1474@comtv.ru> wrote:

> Perhaps someone could explain why following behaves the way it does:
>
> ~$ ocaml
>        Objective Caml version 3.11.2
>
> # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in
> ic i;;
> Warning Y: unused variable j.
> val f : in_channel -> unit = <fun>
> # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in
> ic j;;
> Error: This expression has type int but an expression was expected of type
>         int64
>
> --
> mailto:av1474@comtv.ru
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

[-- Attachment #2: Type: text/html, Size: 1956 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Caml-list] Type inference and marshalling
  2011-07-05 14:18 ` Wojciech Meyer
@ 2011-07-05 14:54   ` Mathias Kende
  0 siblings, 0 replies; 7+ messages in thread
From: Mathias Kende @ 2011-07-05 14:54 UTC (permalink / raw)
  To: caml-list

Le mardi 05 juillet 2011 à 15:18 +0100, Wojciech Meyer a écrit :
> The unused binding j is not taken account and thrown away, so the type
> system will not take into account + operator that will cause i to be int.
> Why the unused binding is being thrown away before type checker, I don't
> know, maybe somebody could explain possibly.

This is not the reason for the acceptance of this input because the
following also typecheck (in 3.12.0):

  let f ic = 
    let i = input_value ic in
    let j = i + 1 in
    (j, i, LargeFile.seek_in ic i);

with (apparently wrong) type:

  val f : in_channel -> int * 'a * unit = <fun>

This looks like a bug in the type checker.

A smaller triggering program is: 

  let f () = 
    let i = input_value stdin in
    let j = i + 1 in
    i, j;;

Mathias




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Caml-list] Type inference and marshalling
  2011-07-05 13:59 [Caml-list] Type inference and marshalling malc
  2011-07-05 14:18 ` Wojciech Meyer
@ 2011-07-05 23:24 ` Jacques Garrigue
  2011-07-06  5:11   ` malc
  1 sibling, 1 reply; 7+ messages in thread
From: Jacques Garrigue @ 2011-07-05 23:24 UTC (permalink / raw)
  To: malc; +Cc: caml-list

On 2011/07/05, at 22:59, malc wrote:

> Perhaps someone could explain why following behaves the way it does:
> 
> ~$ ocaml
>        Objective Caml version 3.11.2
> 
> # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic i;;
> Warning Y: unused variable j.
> val f : in_channel -> unit = <fun>

The return type of input_value being 'a, which gets generalized by the
relaxed value restriction, i gets the polymorphic type "forall 'a. 'a".
So you can use it both as an int and an int64.
==> input_value is an unsafe function, you should always write a type
	annotation on its return type.

> # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic j;;
> Error: This expression has type int but an expression was expected of type
>         int64

j being the result of an integer addition, it has type int, and cannot be used
as int64.

Jacques

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Caml-list] Type inference and marshalling
  2011-07-05 23:24 ` Jacques Garrigue
@ 2011-07-06  5:11   ` malc
  2011-07-06  7:44     ` Jacques Garrigue
  0 siblings, 1 reply; 7+ messages in thread
From: malc @ 2011-07-06  5:11 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: caml-list

On Wed, 6 Jul 2011, Jacques Garrigue wrote:

> On 2011/07/05, at 22:59, malc wrote:
> 
> > Perhaps someone could explain why following behaves the way it does:
> > 
> > ~$ ocaml
> >        Objective Caml version 3.11.2
> > 
> > # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic i;;
> > Warning Y: unused variable j.
> > val f : in_channel -> unit = <fun>
> 
> The return type of input_value being 'a, which gets generalized by the
> relaxed value restriction, i gets the polymorphic type "forall 'a. 'a".
> So you can use it both as an int and an int64.
> ==> input_value is an unsafe function, you should always write a type
> 	annotation on its return type.

Sure i'm well aware of that, but to me "let j = i + 1" means that i has
type int and after that "LargeFile.seek ic i" makes no sense yet is
accepted by the type checker.

> 
> > # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic j;;
> > Error: This expression has type int but an expression was expected of type
> >         int64
> 
> j being the result of an integer addition, it has type int, and cannot be used
> as int64.
> 
> Jacques
> 
> 

-- 
mailto:av1474@comtv.ru

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Caml-list] Type inference and marshalling
  2011-07-06  5:11   ` malc
@ 2011-07-06  7:44     ` Jacques Garrigue
  2011-07-06  8:31       ` malc
  0 siblings, 1 reply; 7+ messages in thread
From: Jacques Garrigue @ 2011-07-06  7:44 UTC (permalink / raw)
  To: malc; +Cc: caml-list

On 2011/07/06, at 14:11, malc wrote:

> On Wed, 6 Jul 2011, Jacques Garrigue wrote:
> 
>> On 2011/07/05, at 22:59, malc wrote:
>> 
>>> Perhaps someone could explain why following behaves the way it does:
>>> 
>>> ~$ ocaml
>>>       Objective Caml version 3.11.2
>>> 
>>> # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic i;;
>>> Warning Y: unused variable j.
>>> val f : in_channel -> unit = <fun>
>> 
>> The return type of input_value being 'a, which gets generalized by the
>> relaxed value restriction, i gets the polymorphic type "forall 'a. 'a".
>> So you can use it both as an int and an int64.
>> ==> input_value is an unsafe function, you should always write a type
>> 	annotation on its return type.
> 
> Sure i'm well aware of that, but to me "let j = i + 1" means that i has
> type int and after that "LargeFile.seek ic i" makes no sense yet is
> accepted by the type checker.

But this is just the definition of let polymorphism...
If the type of a let-bound value  contains variables, they can be generalized
(with some restriction for soundness).
So i can perfectly have several types.
What makes no sense here is the return type of input_value,
yet this cannot be avoided since there is currently no mechanism
in ocaml to actually check the type of the value received.

I have no simple solution for this with the current standard library.
A potential way to avoid this problem would be to force the user to
provide a monomorphic type:

module type T = sig type t end

let input_value ic (type a) (t : (module T with type t = a)) : a =
  Pervasives.input_value ic

let f ic =
  let i =
    input_value ic (module struct type t = int end : T with type t = int) in
  let _ = i + 1 in seek_in ic i;;

This is verbose, but some syntactic sugar could be easily provided.
In the long term, safe input primitives are the solution.

Jacques Garrigue

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [Caml-list] Type inference and marshalling
  2011-07-06  7:44     ` Jacques Garrigue
@ 2011-07-06  8:31       ` malc
  0 siblings, 0 replies; 7+ messages in thread
From: malc @ 2011-07-06  8:31 UTC (permalink / raw)
  To: Jacques Garrigue; +Cc: caml-list

On Wed, 6 Jul 2011, Jacques Garrigue wrote:

> On 2011/07/06, at 14:11, malc wrote:
> 
> > On Wed, 6 Jul 2011, Jacques Garrigue wrote:
> > 
> >> On 2011/07/05, at 22:59, malc wrote:
> >> 
> >>> Perhaps someone could explain why following behaves the way it does:
> >>> 
> >>> ~$ ocaml
> >>>       Objective Caml version 3.11.2
> >>> 
> >>> # let f ic = let i = input_value ic in let j = i + 1 in LargeFile.seek_in ic i;;
> >>> Warning Y: unused variable j.
> >>> val f : in_channel -> unit = <fun>
> >> 
> >> The return type of input_value being 'a, which gets generalized by the
> >> relaxed value restriction, i gets the polymorphic type "forall 'a. 'a".
> >> So you can use it both as an int and an int64.
> >> ==> input_value is an unsafe function, you should always write a type
> >> 	annotation on its return type.
> > 
> > Sure i'm well aware of that, but to me "let j = i + 1" means that i has
> > type int and after that "LargeFile.seek ic i" makes no sense yet is
> > accepted by the type checker.
> 
> But this is just the definition of let polymorphism...

Thing is - the original code looked something like this:

let offset = input_value ic in
Printf.printf "%d" offset;
LargeFile.seek_in other_ic offset;

And it also worked... and caught me by surprise..

> If the type of a let-bound value  contains variables, they can be generalized
> (with some restriction for soundness).
> So i can perfectly have several types.
> What makes no sense here is the return type of input_value,
> yet this cannot be avoided since there is currently no mechanism
> in ocaml to actually check the type of the value received.
> 
> I have no simple solution for this with the current standard library.
> A potential way to avoid this problem would be to force the user to
> provide a monomorphic type:
> 
> module type T = sig type t end
> 
> let input_value ic (type a) (t : (module T with type t = a)) : a =
>   Pervasives.input_value ic
> 
> let f ic =
>   let i =
>     input_value ic (module struct type t = int end : T with type t = int) in
>   let _ = i + 1 in seek_in ic i;;
> 
> This is verbose, but some syntactic sugar could be easily provided.
> In the long term, safe input primitives are the solution.
> 

-- 
mailto:av1474@comtv.ru

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-07-06  8:31 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-05 13:59 [Caml-list] Type inference and marshalling malc
2011-07-05 14:18 ` Wojciech Meyer
2011-07-05 14:54   ` Mathias Kende
2011-07-05 23:24 ` Jacques Garrigue
2011-07-06  5:11   ` malc
2011-07-06  7:44     ` Jacques Garrigue
2011-07-06  8:31       ` malc

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).