Is this a bug?

Is this a bug?

[Thomas Fischbacher]

If we look at the following piece of code:

===>
type dof_region_spec = (string * bool * (int option array)) array;;
type opt_field_restriction = dof_region_spec option;;

let make_field ?(name="Field") ?restriction ?constant_value mwe =
   let restriction:opt_field_restriction = restriction in
	failwith "FOO";;
<===

...then make_field types as:

===>
val make_field :
   ?name:string -> ?restriction:<hidden> -> ?constant_value:'a -> 'b -> 'c
<===

The <hidden> actually should not show up here. What is going on?

-- 
best regards,
Thomas Fischbacher
tf@functionality.de

Re: [Caml-list] Is this a bug?

[Eric Cooper]

It certainly seems to be a bug.  Here's a smaller example:
    type intopt = int option
    let foo ?flag () = let (_ : intopt) = flag in ()
prints as
    val foo : ?flag:<hidden> -> unit -> unit = <fun>

It still seems to be typed correctly:

# foo ~flag:17 ();;
- : unit = ()
# foo ~flag:"x" ();;
This expression has type string but is here used with type int
# let bar ?(flag=0) () = ();;
val bar : ?flag:int -> unit -> unit = <fun>
# [foo; bar];;
- : (?flag:<hidden> -> unit -> unit) list = [<fun>; <fun>]

The bug is also present when you run "ocamlc -i ..."

-- 
Eric Cooper             e c c @ c m u . e d u

Re: [Caml-list] Is this a bug?

[Jacques Garrigue]

From: Thomas Fischbacher <tf@functionality.de>
> If we look at the following piece of code:
> 
> ===>
> type dof_region_spec = (string * bool * (int option array)) array;;
> type opt_field_restriction = dof_region_spec option;;
> 
> let make_field ?(name="Field") ?restriction ?constant_value mwe =
>    let restriction:opt_field_restriction = restriction in
> 	failwith "FOO";;
> <===
> 
> ...then make_field types as:
> 
> ===>
> val make_field :
>    ?name:string -> ?restriction:<hidden> -> ?constant_value:'a -> 'b -> 'c
> <===
> 
> The <hidden> actually should not show up here. What is going on?

You could call it a printer "bug", but it's probably not worth fixing.
The problem is that opt_field_restriction hides the "option" type
constructor. To recover it one would have to expand it, but the
printer is not supposed to do type expansion (it must show the types
as they are).

So I would be tempted to say that a reasonable fix would be to replace
<hidden> by <option hidden>, to make things clearer?

Note that this is purely a printer problem. The type-checker itself
shall work correctly.

Jacques Garrigue

Re: [Caml-list] Is this a bug?

[Thomas Fischbacher]

Jacques Garrigue wrote:

> You could call it a printer "bug", but it's probably not worth fixing.

It is highly annoying if one tries to autogenerate .mli files with
ocamlc -i.

-- 
best regards,
Thomas Fischbacher
tf@functionality.de

Re: [Caml-list] Is this a bug?

[Jacques GARRIGUE]

From: Thomas Fischbacher <tf@functionality.de>
> Jacques Garrigue wrote:
> 
> > You could call it a printer "bug", but it's probably not worth fixing.
> 
> It is highly annoying if one tries to autogenerate .mli files with
> ocamlc -i.

OK, I've fixed it for simple cases.
It should be considerably harder to see this <hidden>.

Jacques Garrigue

is this a bug ?

[Christophe Raffalli]

hello,

--------------------------------
let f b l = match l with
   [] | [_] -> 1
| [a;_] | [_;a] when a = b-> 2
| _ -> 3

let _ =
   print_int (f 1 [1;2]);
   print_int (f 1 [2;1]);
   print_newline ()
--------------------------------

Do you think this code should have a useless pattern warning and print "23" instead of "22" ?

If someone tell me this is a bug then I fill a bug report ...


-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------