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

Optional argument type not printed #7866

Closed
vicuna opened this issue Oct 25, 2018 · 6 comments
Closed

Optional argument type not printed #7866

vicuna opened this issue Oct 25, 2018 · 6 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Oct 25, 2018

Original bug ID: 7866
Reporter: @lpw25
Status: new
Resolution: open
Priority: normal
Severity: minor
Category: typing
Monitored by: antron @nojb

Bug description

In some cases the type of an optional argument cannot be printed.

# type 'a opt = 'a option;;
type 'a opt = 'a option

# let foo (type a) ?(x : a opt) () = ();;
val foo : ?x:<hidden> -> unit -> unit = <fun>

This is because the type of the argument becomes 'a opt instead of 'a option. I suspect that the proper fix is to represent the types of optional arguments as 'a instead of 'a option.

@vicuna
Copy link
Author

vicuna commented Oct 25, 2018

Comment author: @alainfrisch

cannot be printed.

I assume that the trouble is that the printer does not have access to the environment in order to unify the argument type with 'a option in order to extract 'a. Is that right? Could one use the environment provided by wrap_printing_env?

I suspect that the proper fix is to represent the types of optional arguments as 'a instead of 'a option.

Do you mean splitting:

| Tarrow of arg_label * type_expr * type_expr * commutable
(** [Tarrow (Nolabel, e1, e2, c)] ==> [e1 -> e2]
[Tarrow (Labelled "l", e1, e2, c)] ==> [l:e1 -> e2]
[Tarrow (Optional "l", e1, e2, c)] ==> [?l:e1 -> e2]

in two constructors (or putting the first type_expr "under" the three constructors), so that the first type_expr can be given a different meaning?

@vicuna
Copy link
Author

vicuna commented Oct 25, 2018

Comment author: @lpw25

Is that right?

Essentially, although I would phrase it more in terms of wanting type printing to work without needing to perform invasive operations like unification on the types.

Do you mean[...]?

I had in mind making the first type_expr part of the label type, and giving it a slightly different meaning in the optional case. It just seems a cleaner representation to me, but its probably a fairly invasive change.

@vicuna vicuna added the typing label Mar 14, 2019
@github-actions
Copy link

github-actions bot commented May 7, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 7, 2020
@lpw25 lpw25 removed the Stale label May 7, 2020
@lpw25 lpw25 self-assigned this May 7, 2020
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 10, 2021
@gasche
Copy link
Member

gasche commented May 10, 2021

(reproduced on 4.12)

@github-actions github-actions bot removed the Stale label May 12, 2021
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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

3 participants