Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

anonymous functions with optional arguments #5748

Closed
vicuna opened this issue Aug 31, 2012 · 4 comments
Closed

anonymous functions with optional arguments #5748

vicuna opened this issue Aug 31, 2012 · 4 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Aug 31, 2012

Original bug ID: 5748
Reporter: @mjambon
Assigned to: @garrigue
Status: closed (set by @mshinwell on 2017-03-07T13:40:55Z)
Resolution: not a bug
Priority: normal
Severity: minor
Platform: any
Version: 4.00.0
Target version: later
Category: typing
Related to: #6352
Monitored by: mehdi @ygrek Camarade_Tux @hcarty

Bug description

In OCaml 4.00, anonymous functions with optional arguments can no longer be passed to a higher order function that doesn't know expect optional arguments. Here is an example:

let f g = g () ;;

(* works in 3.12 and 4.00 *)
let g = fun ?opt () -> () in
f g
;;

Here is what no longer works in OCaml 4.00.0 but used to work in 3.12.1:

f (fun ?opt () -> ()) ;;

Error: This function should have type unit -> 'a
but its first argument is labelled ~?opt

This breaks some of our code where the anonymous function is generated by a Camlp4 macro.

@vicuna
Copy link
Author

vicuna commented Sep 4, 2012

Comment author: @garrigue

Repeating the message of the caml-list (feedback request at the end):

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

An inline function doesn't enter this category.

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 your report is about inlined functions, which could benefit
from propagation.

How much do you rely on that?
Another option, if we add "let" to the matched expression,
would be to "let-expand" your function:
f (let g ?x ?y () = ... in g)
this way it would match the pattern, and the let is eliminated by compilation anyway.
But this workaround does not work currently.

@vicuna
Copy link
Author

vicuna commented Sep 4, 2012

Comment author: @alainfrisch

Jacques: what do you call "upward" propagation? Propagating the expected types down the AST?

Wouldn't it be possible to trigger the erasure of an optional argument "on the fly" when reaching a lambda node, if the expected type asks for a function type without this optional argument?

That said, I'm not a big fan of the automatic erasure of optional arguments (it looks rather fragile, and not so useful).

@vicuna
Copy link
Author

vicuna commented Sep 4, 2012

Comment author: @mjambon

This problem occurs in two spots in a ~100K-line code base and I don't see much more need for it in the future.

The macro we're using is FILTER provided by mikmatch_pcre:

let f = FILTER int eos;;

val f : ?share:bool -> ?pos:int -> string -> bool =

List.filter (FILTER int eos) [ "-123"; "a"; "0"; "-1.2" ];;

  • : string list = ["-123"; "0"]

@vicuna
Copy link
Author

vicuna commented Mar 7, 2017

Comment author: @mshinwell

I think the lack of activity (more than four years) on this PR suggests that there isn't a problem in this area at present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants