MPR#7500: Remove Uchar.dump #1081

dbuenzli · 2017-03-05T10:17:06Z

and make the Uchar independent from the Format and Printf
modules. Previously this made it impossible to use the type in the
natural habitat that the String, Bytes and Buffer modules could be.

https://caml.inria.fr/mantis/view.php?id=7500

dra27

IANDG, but a breaking change at this stage for 4.05 seems unlikely. However, perhaps Format.print_dump_uchar and Format.pp_print_dump_uchar with a deprecation of Uchar.dump might be OK for 4.05? Further changes to the stdlib which rely on this change must obviously be at least 4.06.

dra27 · 2017-03-05T11:08:12Z

stdlib/format.mli

+    {{:http://www.unicode.org/versions/latest/appA.pdf}notational
+    convention for code points}.
+
+    @since 4.05 *)


I'd be very surprised if @damiendoligez will permit a breaking change this close to the 4.05 release - this'd be 4.06 (and below)

This is not a breaking change. However if people don't want this in 4.05 I can remove it.

I did mean the entire GPR (which is breaking) - I had the deprecation idea seconds later!

dra27 · 2017-03-05T11:08:25Z

stdlib/format.mli

@@ -520,6 +528,9 @@ val pp_print_as : formatter -> int -> string -> unit
 val pp_print_int : formatter -> int -> unit
 val pp_print_float : formatter -> float -> unit
 val pp_print_char : formatter -> char -> unit
+val pp_print_dump_uchar : formatter -> Uchar.t -> unit
+(** @since 4.05 see {!print_dump_uchar}. *)


Same as previous

dbuenzli · 2017-03-05T11:27:07Z

IANDG, but a breaking change at this stage for 4.05 seems unlikely

A review of the all the public uses of Uchar.dump on github indicates that only my libraries are affected. As @gasche mentioned on mantis I think the sooner we get rid of it, the better.

xavierleroy · 2017-03-05T11:44:31Z

With all due respect I believe Uchar.dump was a bad API and Format.pp_print_dump_uchar is nearly as bad. If I understand correctly the need is to produce a printable representation of uchars for debugging and other purposes. In which case the function should take a Uchar.t and return a string. Call it Uchar.to_string or Uchar.escaped for example. The actual printing is left to the user.

Why tie this production of a printable representation with the printing on a formatter? A lot of OCaml users never use the Format module...

dbuenzli · 2017-03-05T11:59:14Z

Call it Uchar.to_string or Uchar.escaped for example.

Neither of these names would make sense in my opinion, the first one would be ambiguous in the context of Unicode characters and the second one would be inconsistent with what String.escape does.

A lot of OCaml users never use the Format module...

#install_printer does.

dbuenzli · 2017-03-05T12:36:22Z

Just to make things clear I'm all for having a better name than pp_print_dump_uchar, but this better name has to be unambiguous.

For all it's badness one virtue of it is that it is sufficiently curious that a reader won't take it for what it's not (e.g. things like pp_print_ascii_uchar or _uchar_to_ascii would be ambiguous). The actual printing follows Unicode notational convention, but this notation doesn't have a particular name.

gasche · 2017-03-05T17:40:03Z

I think it would make sense to separate the change in two:

removing UChar.dump, which I would be in favor of doing as soon as possible. If we decide to do the change in 4.05, I would like to merge the change in the next few days.
deciding what is the best interface for this feature (and in which module to go), which may take a bit more time to converge (if it's ready for 4.05, fine, but we can also have it in trunk)

This split would mean that it would be possible to be release with UChar.dump removed but without an equivalent function somewhere. I think that the feature is easy enough for the user to reimplement for this not to be so much of an issue.

dbuenzli · 2017-03-05T18:10:30Z

Ok, I'll wait for @damiendoligez's decision about either removal or deprecation before proceeding as you suggest.

I'll just mention that:

deciding what is the best interface for this feature (and in which module to go), which may take a bit more time to converge (if it's ready for 4.05, fine, but we can also have it in trunk)

This is not really about an interface. It's just a name for a pretty printer that can be used either for printing your own datastructures or for quickly turning:

# Uchar.max;;
- : Uchar.t = <abstr>

into

# Uchar.max;;
- : Uchar.t = U+10FFFF

via an #install_printer. (If you want to know why I didn't actually set it up by default in the toplevel the reason is that if I'm not mistaken, currently, by default, when not <abstr> right hand sides of equations are always valid OCaml values, something that is not the case with this pretty-printer).

I think that the feature is easy enough for the user to reimplement for this not to be so much of an issue.

Anyone seriously using Uchar will need at some point (and if you want a string you have Format.asprintf) I thought that the time when the OCaml stdlib wasn't supporting its own mechanisms were gone.

xavierleroy · 2017-03-05T18:24:36Z

I stand by my claim that the functionality should be exposed as a function in Uchar with type t -> string. Name it however you want. A dependency-free implementation is easy, just declare "caml_format_int" as an external.

gasche · 2017-03-05T18:39:23Z

I see Daniel's point that it is convenient to have pp_print_* functions in the Format module for various datatypes of interest, but looking at the list of current such functions it seems that we have pp_print_* functions for built-in types only, not for Int32 or Int64 for example. One could argue for extending this to stdlib-defined types in general, but I'm not sure that this is the best design -- in particular, this makes Format depend on everything on earth, which may cause further dependency issues down the road.

and make the Uchar independent from the Format and Printf modules. Previously this made it impossible to use the type in the natural habitat that the String, Bytes and Buffer modules could be.

dbuenzli · 2017-03-05T20:38:24Z

So I amended the commit to simply remove Uchar.dump.

Regarding:

I stand by my claim that the functionality should be exposed as a function in Uchar with type t -> string. Name it however you want. A dependency-free implementation is easy, just declare "caml_format_int" as an external.

The module already declares caml_format_int. I'll let someone else do that and find the good name as 1) I have no interest in such a function 2) find it inferior to a formatter

One could argue for extending this to stdlib-defined types in general, but I'm not sure that this is the best design -- in particular, this makes Format depend on everything on earth, which may cause further dependency issues down the road.

If one wants to improve the usability of the toplevel and the stdlib this should be given a serious thought at some point. Type directed usage of formatters in the wider ecosystem is an established idiom (libraries that provide toplevel and printf debugging support on their values, for usage in testing frameworks to print offending values, for usage in logging frameworks, or, tupled with corresponding parsers, to support textual interaction with humans).

alainfrisch · 2017-03-06T14:54:51Z

Since this PR is now only about removing Uchar.dump, let's focus on this part (and not a future replacement). I support this change, even for inclusion in 4.05.

alainfrisch · 2017-03-06T14:55:37Z

I think we need @damiendoligez input before merging the PR in 4.05.

damiendoligez · 2017-03-07T12:18:09Z

I'm OK with merging this in 4.05 and I agree with Xavier: the basic functionality is a Uchar.t -> string function on top of which the formatter functions should be built, not the other way around.

and make the Uchar independent from the Format and Printf modules. Previously this made it impossible to use the type in the natural habitat that the String, Bytes and Buffer modules could be.

damiendoligez · 2017-03-07T13:22:28Z

Cherry-picked to 4.05 (commit 07e4594).

and make the Uchar independent from the Format and Printf modules. Previously this made it impossible to use the type in the natural habitat that the String, Bytes and Buffer modules could be.

ELLIOTTCABLE · 2018-06-22T19:33:19Z

Does this mean there's no functionality in 4.05 / 4.06 to produce a debugging-representation of a Uchar.t?

dra27 · 2018-06-22T19:44:11Z

@ELLIOTTCABLE - there’s still Uchar.to_int so you can still write let dump ppf u = Format.fprintf ppf "U+%04X" (Uchar.to_int u)

dra27 reviewed Mar 5, 2017

View reviewed changes

MPR#7500: remove Uchar.dump

f22579a

and make the Uchar independent from the Format and Printf modules. Previously this made it impossible to use the type in the natural habitat that the String, Bytes and Buffer modules could be.

dbuenzli force-pushed the remove-uchar-dump branch from 615cf6b to f22579a Compare March 5, 2017 20:36

dbuenzli changed the title ~~MPR#7500: move Uchar.dump to Format.[pp_]print_dump_uchar~~ MPR#7500: Remove Uchar.dump Mar 5, 2017

dbuenzli mentioned this pull request Mar 5, 2017

Add Fmt.Dump.uchar dbuenzli/fmt#21

Closed

alainfrisch added the consider-for-release label Mar 6, 2017

damiendoligez merged commit 991ffbe into ocaml:trunk Mar 7, 2017

dbuenzli deleted the remove-uchar-dump branch March 7, 2017 12:48

dbuenzli mentioned this pull request Oct 9, 2018

Remove Float.of_string[_opt]. #2098

Closed

vicuna mentioned this pull request Mar 14, 2019

Remove Uchar.dump #7500

Closed

stedolan added a commit to stedolan/ocaml that referenced this pull request Mar 21, 2023

More assertions for local alloc and letrec (ocaml#1081)

b0e1527

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MPR#7500: Remove Uchar.dump #1081

MPR#7500: Remove Uchar.dump #1081

dbuenzli commented Mar 5, 2017 •

edited

Loading

dra27 left a comment

dra27 Mar 5, 2017

dbuenzli Mar 5, 2017

dra27 Mar 5, 2017

dra27 Mar 5, 2017

dbuenzli commented Mar 5, 2017

xavierleroy commented Mar 5, 2017

dbuenzli commented Mar 5, 2017 •

edited

Loading

dbuenzli commented Mar 5, 2017

gasche commented Mar 5, 2017

dbuenzli commented Mar 5, 2017

xavierleroy commented Mar 5, 2017

gasche commented Mar 5, 2017

dbuenzli commented Mar 5, 2017

alainfrisch commented Mar 6, 2017

alainfrisch commented Mar 6, 2017

damiendoligez commented Mar 7, 2017

damiendoligez commented Mar 7, 2017

ELLIOTTCABLE commented Jun 22, 2018

dra27 commented Jun 22, 2018 •

edited

Loading

MPR#7500: Remove Uchar.dump #1081

MPR#7500: Remove Uchar.dump #1081

Conversation

dbuenzli commented Mar 5, 2017 • edited Loading

dra27 left a comment

Choose a reason for hiding this comment

dra27 Mar 5, 2017

Choose a reason for hiding this comment

dbuenzli Mar 5, 2017

Choose a reason for hiding this comment

dra27 Mar 5, 2017

Choose a reason for hiding this comment

dra27 Mar 5, 2017

Choose a reason for hiding this comment

dbuenzli commented Mar 5, 2017

xavierleroy commented Mar 5, 2017

dbuenzli commented Mar 5, 2017 • edited Loading

dbuenzli commented Mar 5, 2017

gasche commented Mar 5, 2017

dbuenzli commented Mar 5, 2017

xavierleroy commented Mar 5, 2017

gasche commented Mar 5, 2017

dbuenzli commented Mar 5, 2017

alainfrisch commented Mar 6, 2017

alainfrisch commented Mar 6, 2017

damiendoligez commented Mar 7, 2017

damiendoligez commented Mar 7, 2017

ELLIOTTCABLE commented Jun 22, 2018

dra27 commented Jun 22, 2018 • edited Loading

dbuenzli commented Mar 5, 2017 •

edited

Loading

dbuenzli commented Mar 5, 2017 •

edited

Loading

dra27 commented Jun 22, 2018 •

edited

Loading