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

Printing of the value of optional arguments in #trace #6610

Closed
vicuna opened this issue Oct 12, 2014 · 2 comments
Closed

Printing of the value of optional arguments in #trace #6610

vicuna opened this issue Oct 12, 2014 · 2 comments
Milestone

Comments

@vicuna
Copy link

vicuna commented Oct 12, 2014

Original bug ID: 6610
Reporter: herbelin
Status: closed (set by @damiendoligez on 2016-04-12T13:09:34Z)
Resolution: not a bug
Priority: normal
Severity: minor
Version: 4.01.0
Target version: 4.03.0+dev / +beta1
Category: tools (ocaml{lex,yacc,dep,debug,...})
Related to: #5975
Monitored by: @gasche

Bug description

Hi,

I'm not sure this is a bug or an intended feature. In the trace mechanism, optional arguments with a default value are printed using their internal representation in the option type rather than using their usage type, as in:

let f ?(a=true) x = if a then x else x;;
#trace f;;
f 1;;
(*
f <-- ?a:None
f -->
f* <--
f* -->
*)

Steps to reproduce

let f ?(a=true) x = if a then x else x;;
#trace f;;
f 1;;

@vicuna
Copy link
Author

vicuna commented Dec 17, 2014

Comment author: @damiendoligez

The representation is not really "internal" since it's exposed to the user for optional arguments without a default value.

Also, if I read #5975 correctly, the default value might not yet be computed at the point where you would want to print it.

@vicuna
Copy link
Author

vicuna commented Dec 18, 2014

Comment author: herbelin

I built my understanding of optional arguments empirically by reading code using optional arguments, without explicitly thinking at their internal representation. This was cases with a default value for which the abstraction w.r.t. the internal representation as an option type apparently worked well.

I now acknowledge that the current mechanism of optional arguments cannot be explained without referring to its implementation as syntactic sugar on top of the option type, renouncing to propose a true abstraction,

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

1 participant