Re: [Caml-list] Deprecation of tabulation boxes

[Ivan Gotovchits <ivg@ieee.org>]

[-- Attachment #1: Type: text/plain, Size: 8415 bytes --]

Hi,

Thanks for the great news, we're looking forward to the new tabulation
support (and the paper)!

Have a great year,
Ivan Gotovchits



On Sun, Jan 1, 2017 at 12:58 PM, Pierre Weis <pierre.weis@inria.fr> wrote:

> Hi Ivan, hi Gabriel,
>
> Sorry for the late answer: I generally have no time to read the
> Caml-list...
>
> As Gabriel said, I deprecated the tabulation boxes after a discussion about
> their not so smooth integration with other features of the Format module.
> And
> as you mentioned it, the discussion can be summerize as ``we do not
> understand the feature and do not use it'', and so probably nobody use it.
>
> I should have been more careful and wait to check if some users in the
> field
> were using tabulation boxes in their code.
>
> The problem about tabulation boxes is that they cannot be easily mixed with
> other boxes; on the other hand, if you do know the fact, they are perfectly
> usable to do exactly what you are doing with tabulation boxes, i.e. basic
> and simple tabular printing. That's exactly why those boxes have been
> introduced in Format in the first place: to print text file using lines
> with
> fixed fields separated with spaces or tabs (basic tab-tab-return line
> format).
>
> However, the code for tabulation boxes is still there and still up and
> running. So reverting its status is easy and should not break anything: it
> could be done anytime.
>
> During last year, Richard Bonichon and I wrote a paper about Format, its
> features, usage, internals and principles, to be presented at the next
> JFLA'2017 conference. During this work, we had long brain storming sessions
> about the new features I'm planning to introduce in the module and in
> particular a new tabular printing feature that would subsume tabulation
> boxes, since tabular printing would be fully integrated to the regular box
> management (and would have a proper format string extension to express
> tabular printing). This is still paper work, but we are confident to get a
> draft of the code during 2017.
>
> So, now that we know that some people indeed use the tabulation box
> feature,
> I propose to revert its status. When the new tabular printing feature will
> be
> there, people could easily port their code to the new feature and we could
> definitely deprecate the old tabulation boxes.
>
> PS: I wish you the best for this new year :)
>
> --
> Pierre Weis
>
> INRIA Paris, http://bat8.inria.fr/~weis/
>
>
> > Well, the discussion literally says, we don't understand tabulation, and
> it
> > looks like nobody is using it, so let's just throw it away :)
> >
> > We're using tabulation, and they are quite useful. Yep, I agree, that the
> > interface for setting the marks is kind of awkward,
> > it would be nice if there would be a `pp_setup_tabs : _ formatter -> int
> > list -> unit` function, that would push into the stack a new tabular box
> > with
> > the specified tabulations.
> >
> > What concerning your solution with the alignment, it is less general and
> > doesn't work in our case. First of all, the pretty printing functions,
> that
> > are printing
> > into the columns are not specified with `%s`, but with `%a` (e.g.,
> address,
> > memory string, assembly string). Second, the printing functions are not
> > actually
> > defined in the same module. The tabs are initialized in the frontend,
> that
> > defines it based on the architecture (address size, maximum length of
> > instruction, etc),
> > and pretty printers are registered separately, and they just rely on a
> > fact, that we have three columns, the first is for address, the second is
> > for memory, then assembly, etc).
> > This design simplifies the actual instruction printers, by consolidating
> > the common code in the formatter setup procedure.
> >
> > So, it is still not clear to me, why the tabulations are wrong. If they
> do
> > complicate the code base and raise the support cost, then it is
> > understandable, why you would like to remove it
> > from the standard library. But in this case, it would be nice, to move
> this
> > code out as a separate library, as just removing a feature, that was in
> the
> > language for years (I would say even forever,
> > if we will start the history from caml-light), without providing any
> > substitution is... not nice :)
> >
> >
> > [1]: http://caml.inria.fr/pub/docs/manual-caml-light/node15.5.html
> >
> >
> >
> > On Mon, Dec 19, 2016 at 1:20 PM, Gabriel Scherer <
> gabriel.scherer@gmail.com>
> > wrote:
> >
> > > You may be interested in the discussion
> > >   https://github.com/ocaml/ocaml/pull/229
> > > which discussed a few ways in which the proposed tabulation interface
> > > may be inconvenient. It is after this discussion that Pierre Weis
> > > decided to deprecate tabulation boxes -- I believe that the reason is
> > > that tabulation and formatting never mixed very well.
> > >
> > > Note that if you can decide in advance a maximal size for a given
> > > "column" of your formatted output, you can use the left or
> > > right-justification features of formatting conversions to print
> > > aligned text:
> > >
> > > let data = [("x", "foo"); ("loop", "bar")]
> > >
> > > let () =
> > >   print_newline ();
> > >   data |> List.iter (fun (lab, instr) -> Printf.printf "%5s: %s\n" lab
> > > instr)
> > > (*
> > >     x: foo
> > >  loop: bar
> > > *)
> > >
> > > let () =
> > >   print_newline ();
> > >   data |> List.iter (fun (lab, instr) -> Printf.printf "%-5s: %s\n" lab
> > > instr)
> > > (*
> > > x    : foo
> > > loop : bar
> > > *)
> > >
> > > let () =
> > >   let len = List.fold_left (fun m (lab, _) -> max m (String.length
> > > lab)) 0 data in
> > >   print_newline ();
> > >   data |> List.iter (fun (lab, instr) -> Printf.printf "%*s: %s\n" len
> > > lab instr)
> > > (*
> > >    x: foo
> > > loop: bar
> > > *)
> > >
> > > On Mon, Dec 19, 2016 at 12:59 PM, Ivan Gotovchits <ivg@ieee.org>
> wrote:
> > > > Greetings,
> > > >
> > > > The tabulation boxes are marked as deprecated since 4.03.0. I've
> tried to
> > > > google for
> > > > any reasons that justify the removal but found only a note by Pierre
> > > Weis in
> > > > the Matis issue tracker[1]:
> > > >
> > > >
> > > >> The proposed printf-like syntax is fine, but tabulation boxes are
> now
> > > >> deprecated.
> > > >> Indeed, tabulation boxes interaction with other pretty-printing
> boxes
> > > have
> > > >> never been sorted out and tabulation boxes usage is orthogonal to
> the
> > > rest
> > > >> of the Format module.
> > > >> If considered useful, tabulation boxes could be implemented out of
> the
> > > >> Format module.
> > > >
> > > >
> > > > First of all the tabulation boxes can't be implemented outside of the
> > > format
> > > > module since the tab stops are actually stored in the stack of
> tabulation
> > > > boxes. If this data field would be removed from the formatter we will
> > > need
> > > > to pass an extra argument to all pretty-printers that use the
> tabulation
> > > > break, or use some global variable. Neither solution can be
> considered
> > > > acceptable.
> > > >
> > > > Speaking about the usefulness. The tabulation boxes are useful for
> > > printing
> > > > assembly outputs. And since compiler writing is sort of an
> application
> > > area
> > > > for OCaml, it shouldn't be considered as a rare case. It is also very
> > > useful
> > > > for printing Fortran code, that can be considered an assembler for
> the
> > > > numeric computing. It also just allows printing nicely formatted
> texts,
> > > that
> > > > it the main purpose of the Format library. As an example, tabulation
> > > boxes
> > > > are used in BAP and CIL frameworks.
> > > >
> > > > To summarize, the deprecation will eventually make few project
> > > > non-compilable. And there is no clear substitution for the deprecated
> > > > feature.
> > > >
> > > > Given that, I would like to hear the justifications for the
> deprecation
> > > of
> > > > tabulation boxes and suggested workarounds.
> > > >
> > > > One possible workaround, that I could see, is making the `formatter`
> type
> > > > extensible with existential boxes or, more generally, with
> existential
> > > > attributes. In that case, we will indeed be able to implement
> tabulation
> > > > boxes outside of the format module.
> > > >
> > > > Best wishes,
> > > > Ivan Gotovchits
> > > >
> > > > [1]: https://caml.inria.fr/mantis/view.php?id=4665
> > >
>

[-- Attachment #2: Type: text/html, Size: 10999 bytes --]