[Caml-list] ocaml-4.00.0 compilation problem with first class modules and optional parameters

[Caml-list] ocaml-4.00.0 compilation problem with first class modules and optional parameters

[Jacques-Pascal Deplaix]

Hi,

I have met some compilation problem when I tried to compile ocsimore
with ocaml-4.00.0:

  Error: This expression has type
    ?href_action:Wiki_syntax_types.link_action ->
    ?link_action:Wiki_syntax_types.link_action ->
    Wiki_syntax_types.desugar_param -> string -> string Lwt.t
  but an expression was expected of type
    Wiki_syntax_types.desugar_param -> string -> string Lwt.t

It's really a weird error. I tried to reproduce it in a small test-case
but I didn't succeed.

I made a patch for it in ocsimore, but it's really dirty/useless:
http://ocsigen.org/darcsweb/?r=ocsimore;a=commitdiff;h=20120903152205-a85e5-00b22d6e2abc7c666a7700d70e3190e6aefbfd7e.gz

If someone can tell me if it's an ocaml bug or something else.

Cheers,
Jacques-Pascal Deplaix

Re: [Caml-list] ocaml-4.00.0 compilation problem with first class modules and optional parameters

[Jacques Garrigue]

On 2012/09/04, at 5:39, Jacques-Pascal Deplaix wrote:

> Hi,
> 
> I have met some compilation problem when I tried to compile ocsimore
> with ocaml-4.00.0:
> 
>  Error: This expression has type
>    ?href_action:Wiki_syntax_types.link_action ->
>    ?link_action:Wiki_syntax_types.link_action ->
>    Wiki_syntax_types.desugar_param -> string -> string Lwt.t
>  but an expression was expected of type
>    Wiki_syntax_types.desugar_param -> string -> string Lwt.t
> 
> It's really a weird error. I tried to reproduce it in a small test-case
> but I didn't succeed.
> 
> I made a patch for it in ocsimore, but it's really dirty/useless:
> http://ocsigen.org/darcsweb/?r=ocsimore;a=commitdiff;h=20120903152205-a85e5-00b22d6e2abc7c666a7700d70e3190e6aefbfd7e.gz
> 
> If someone can tell me if it's an ocaml bug or something else.
> 
> Cheers,
> Jacques-Pascal Deplaix

OCaml 4.00 is much more agressive in propagating expected types when typing
expressions. Unfortunately, there was a conflict between this upward propagation,
and the somehow adhoc behaviour which removes optional arguments from
a function passed as argument to a function or record/variant constructor not expecting
optional arguments.

Specifically, this is this behavior:

val f : (unit -> unit) -> unit
val g : ?x:int -> ?y:bool -> unit -> unit

let () = f g

This code triggers automatic discarding of the optional arguments of g,
so that the type matches the expected one.

But for this we need to first infer the type of the argument, to see that
it doesn't match the expected one.

I was not aware that this feature was widely used, and the behavior in 4.00.0
is to restrict this feature to expressions where upward propagation doesn't
make sense anyway:
* identifiers
* function applications
* message sending
* record field extraction
* wrapping of "let open" around any of those

Since "let module" is not included, this breaks the code in ocsimore...

This is actually the same problem as reported in http://caml.inria.fr/mantis/view.php?id=5748

The clean fix in your case is to move the "let module" outside of the application:

let module Plugin = (val p: WikiPlugin) in desugar_content (desugar_string Plugin.wikiparser)

If you don't care about compatibility with 3.12, you can even write:

| WikiPlugin (module Plugin) ->
                 desugar_content (desugar_string Plugin.wikiparser)


I'm pondering what to do about this.
Since this feature is described in the tutorial part of the reference manual, I suppose this
qualifies as a bug. However, combining this behavior with upward propagation is difficult.

Not propagating types to function arguments seems fine, but for variant and record
constructors this is less clear-cut.
Another option is to extend the  syntactic cases where the behavior is triggered, including
"let" and "let module", but the above PR#5748 is about inlined functions, which could benefit
from propagation.

Jacques Garrigue

Re: [Caml-list] ocaml-4.00.0 compilation problem with first class modules and optional parameters

[Jacques-Pascal Deplaix]

Oh, I forgot to thank you.
So, thank you for your answer.

On 09/04/2012 04:54 AM, Jacques Garrigue wrote:
> OCaml 4.00 is much more agressive in propagating expected types when typing
> expressions. Unfortunately, there was a conflict between this upward propagation,
> and the somehow adhoc behaviour which removes optional arguments from
> a function passed as argument to a function or record/variant constructor not expecting
> optional arguments.
>
> Specifically, this is this behavior:
>
> val f : (unit -> unit) -> unit
> val g : ?x:int -> ?y:bool -> unit -> unit
>
> let () = f g
>
> This code triggers automatic discarding of the optional arguments of g,
> so that the type matches the expected one.
>
> But for this we need to first infer the type of the argument, to see that
> it doesn't match the expected one.
>
> I was not aware that this feature was widely used, and the behavior in 4.00.0
> is to restrict this feature to expressions where upward propagation doesn't
> make sense anyway:
> * identifiers
> * function applications
> * message sending
> * record field extraction
> * wrapping of "let open" around any of those
>
> Since "let module" is not included, this breaks the code in ocsimore...
>
> This is actually the same problem as reported in http://caml.inria.fr/mantis/view.php?id=5748
>
> The clean fix in your case is to move the "let module" outside of the application:
>
> let module Plugin = (val p: WikiPlugin) in desugar_content (desugar_string Plugin.wikiparser)
>
> If you don't care about compatibility with 3.12, you can even write:
>
> | WikiPlugin (module Plugin) ->
>                  desugar_content (desugar_string Plugin.wikiparser)
>
>
> I'm pondering what to do about this.
> Since this feature is described in the tutorial part of the reference manual, I suppose this
> qualifies as a bug. However, combining this behavior with upward propagation is difficult.
>
> Not propagating types to function arguments seems fine, but for variant and record
> constructors this is less clear-cut.
> Another option is to extend the  syntactic cases where the behavior is triggered, including
> "let" and "let module", but the above PR#5748 is about inlined functions, which could benefit
> from propagation.
>
> Jacques Garrigue