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 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 > 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 > > > >