From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 7327B800B6 for ; Tue, 3 Jan 2017 16:33:17 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lf0-f42.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.215.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ivg@ieee.org designates 209.85.215.42 as permitted sender) identity=mailfrom; client-ip=209.85.215.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f42.google.com) identity=helo; client-ip=209.85.215.42; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lf0-f42.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AOnMvgBYvUrFJmPd2oU6F/Gf/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZpcy/bnLW6fgltlLVR4KTs6sC0LuK9fm7EjNcqdbZ6TZZL8wKD0dEwe?= =?us-ascii?q?wt3CUeQ+e9QXXhK/DrayFoVO9jb3RCu0+BDE5OBczlbEfTqHDhpRQbGxH4KBYn?= =?us-ascii?q?br+tQt2ap42N2uuz45zeZRlTzHr4OOsqbUb+kQKEjsgbm5FvYpk8ywCB9mNJdv?= =?us-ascii?q?5MyCV3KFOItxf6/Ma5upB5pXd+ofUkou9eWKOyUKMkSqJTDDU6KChh5dPknRjO?= =?us-ascii?q?QAbJ4WETBDZF2iFUChTIuUmpFqz6tTH3468kgHGX?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAADdwmtYhyrXVdFDGhYGAQEEAQEKA?= =?us-ascii?q?QEXAQEEAQEKAQGCfw0BAQEBAX6BDAeNUJRGh3uHeIUogggqhXgCgUAHPxQBAQE?= =?us-ascii?q?BAQEBAQEBARIBAQEIDQkJHTCCMwQBFQEEghYBAQEDASMEGQEBJhEBBAsLCwcGK?= =?us-ascii?q?gICIQESAQUBDg4GExoBiDoDCwUIDi2iDD+LGmiBazqDCAEBBYQdDYMJAQEBAQY?= =?us-ascii?q?BAQEBAQEBGQgShjODW4EGgk47gWqCHziCXZAHhHKFVDWGVIZxg3mBdVGCToUzg?= =?us-ascii?q?Q+Ef4lzIYQagkkUHoEUDxBpDWwuEgODFikPEQuBfCA0AQGGbYFPAQEB?= X-IPAS-Result: =?us-ascii?q?A0AnAADdwmtYhyrXVdFDGhYGAQEEAQEKAQEXAQEEAQEKAQG?= =?us-ascii?q?Cfw0BAQEBAX6BDAeNUJRGh3uHeIUogggqhXgCgUAHPxQBAQEBAQEBAQEBARIBA?= =?us-ascii?q?QEIDQkJHTCCMwQBFQEEghYBAQEDASMEGQEBJhEBBAsLCwcGKgICIQESAQUBDg4?= =?us-ascii?q?GExoBiDoDCwUIDi2iDD+LGmiBazqDCAEBBYQdDYMJAQEBAQYBAQEBAQEBGQgSh?= =?us-ascii?q?jODW4EGgk47gWqCHziCXZAHhHKFVDWGVIZxg3mBdVGCToUzgQ+Ef4lzIYQagkk?= =?us-ascii?q?UHoEUDxBpDWwuEgODFikPEQuBfCA0AQGGbYFPAQEB?= X-IronPort-AV: E=Sophos;i="5.33,455,1477954800"; d="scan'208,217";a="252698379" Received: from mail-lf0-f42.google.com ([209.85.215.42]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 Jan 2017 16:33:15 +0100 Received: by mail-lf0-f42.google.com with SMTP id y21so287253749lfa.1 for ; Tue, 03 Jan 2017 07:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qHckq8lVqXca2diaqvPGKKIfgCRRh+KWI/Iq/+m7G/0=; b=XOSUcy9mUpRf6q0kwj6usMswu0XxvtNxr2aBeH7RMPoIJ3aIOnHpxWHKMb5+FRB/E7 bqvDKhvY0MOo+Bzs2MwESy7bHPnl93QN55QVe4ODibylX0VdST0LcjHqpU0ouyYF02ys JWp70yHZjO1fds43bfIQYKHEoCq2OmodWqE8Y2RxoL6kgUg+46h2MRkjr88s+wcLWR/R GX8EPthx45aAMYF48zhh040LW4kzueJTHuI3An48gkqQNtalwBZd1GFy8PODNv8yOZcs PqRN/xqD+jBGhjM4GRvy8iUh880/W4s89sBeDHi5QPCa120lgddrSCxcD9hmY5dmkwcv hHlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qHckq8lVqXca2diaqvPGKKIfgCRRh+KWI/Iq/+m7G/0=; b=UKkUiKTxFaFZ96pacXyF3berSfMrBsFOqyOYnBVdvw7a0s2OCW3imb8EDgm51O17NP ezWWjaO8oQ+l4kaG7T7MXhw6QNycYT5unDjLp48syoEIST4ZiRBC+ARszbNdAEvoKxyI qwAB6VF2lbH9jNxggdOlx76wxDDjZOBU7QX7CdHJRyRubQ4HqaU6QWb+iSibH00TdgEh QmMHOCayBDGteHHCUWUQK5tKQHxXYCqLL5X9QRhTs20/KO+lwWfpdf3GMBM8pahB2c80 lNIR5FaA8c+nFHjBRRiFaTd56J1S6cIwzatNpTqvQvT3ZvNENbeUnO8909pNB+94CC+M WXfg== X-Gm-Message-State: AIkVDXIJDm7gG/TWICdXFYf3qwKXADGoyWoY6FmY3Ou6g0VEB9tXyOupMxwOHgyqds5abVugfgE0YGGUET68dOJ3 X-Received: by 10.46.70.1 with SMTP id t1mr23722145lja.29.1483457594753; Tue, 03 Jan 2017 07:33:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.93.99 with HTTP; Tue, 3 Jan 2017 07:33:14 -0800 (PST) In-Reply-To: <20170101175849.GA21907@yquem.inria.fr> References: <20170101175849.GA21907@yquem.inria.fr> From: Ivan Gotovchits Date: Tue, 3 Jan 2017 10:33:14 -0500 Message-ID: To: Pierre Weis Cc: Gabriel Scherer , caml-list , Richard.Bonichon@gmail.com Content-Type: multipart/alternative; boundary=f403045f7486f99ed4054532625e Subject: Re: [Caml-list] Deprecation of tabulation boxes --f403045f7486f99ed4054532625e Content-Type: text/plain; charset=UTF-8 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 > > > > --f403045f7486f99ed4054532625e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the great news, we'r= e looking forward to the new tabulation support (and the paper)!
=
Have a great year,
Ivan Gotovchits

<= /div>


On Sun, Jan 1, 2017 at 12:58 PM, Pierre Weis <= ;pierre.weis@inri= a.fr> wrote:
Hi Ivan, hi Ga= briel,

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. A= nd
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 fiel= d
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 wit= h
fixed fields separated with spaces or tabs (basic tab-tab-return line forma= t).

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<= br> 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 sess= ions
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<= br> 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<= br> 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<= br> 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 tabulatio= n, 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, t= hat 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 tabula= r box
> with
> the specified tabulations.
>
> What concerning your solution with the alignment, it is less general a= nd
> doesn't work in our case. First of all, the pretty printing functi= ons, that
> are printing
> into the columns are not specified with `%s`, but with `%a` (e.g., add= ress,
> memory string, assembly string). Second, the printing functions are no= t
> 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<= br> > 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 consolidati= ng
> the common code in the formatter setup procedure.
>
> So, it is still not clear to me, why the tabulations are wrong. If the= y 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 i= n 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
> >=C2=A0 =C2=A0https://github.com/ocaml/ocaml/pul= l/229
> > which discussed a few ways in which the proposed tabulation inter= face
> > may be inconvenient. It is after this discussion that Pierre Weis=
> > decided to deprecate tabulation boxes -- I believe that the reaso= n 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 =3D [("x", "foo"); ("loop"= , "bar")]
> >
> > let () =3D
> >=C2=A0 =C2=A0print_newline ();
> >=C2=A0 =C2=A0data |> List.iter (fun (lab, instr) -> Printf.p= rintf "%5s: %s\n" lab
> > instr)
> > (*
> >=C2=A0 =C2=A0 =C2=A0x: foo
> >=C2=A0 loop: bar
> > *)
> >
> > let () =3D
> >=C2=A0 =C2=A0print_newline ();
> >=C2=A0 =C2=A0data |> List.iter (fun (lab, instr) -> Printf.p= rintf "%-5s: %s\n" lab
> > instr)
> > (*
> > x=C2=A0 =C2=A0 : foo
> > loop : bar
> > *)
> >
> > let () =3D
> >=C2=A0 =C2=A0let len =3D List.fold_left (fun m (lab, _) -> max = m (String.length
> > lab)) 0 data in
> >=C2=A0 =C2=A0print_newline ();
> >=C2=A0 =C2=A0data |> List.iter (fun (lab, instr) -> Printf.p= rintf "%*s: %s\n" len
> > lab instr)
> > (*
> >=C2=A0 =C2=A0 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 b= y 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-p= rinting boxes
> > have
> > >> never been sorted out and tabulation boxes usage is orth= ogonal to the
> > rest
> > >> of the Format module.
> > >> If considered useful, tabulation boxes could be implemen= ted out of the
> > >> Format module.
> > >
> > >
> > > First of all the tabulation boxes can't be implemented o= utside 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 formatte= r we will
> > need
> > > to pass an extra argument to all pretty-printers that use th= e tabulation
> > > break, or use some global variable. Neither solution can be = considered
> > > acceptable.
> > >
> > > Speaking about the usefulness. The tabulation boxes are usef= ul for
> > printing
> > > assembly outputs. And since compiler writing is sort of an a= pplication
> > 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 assembl= er for the
> > > numeric computing. It also just allows printing nicely forma= tted texts,
> > that
> > > it the main purpose of the Format library. As an example, ta= bulation
> > boxes
> > > are used in BAP and CIL frameworks.
> > >
> > > To summarize, the deprecation will eventually make few proje= ct
> > > non-compilable. And there is no clear substitution for the d= eprecated
> > > 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 `fo= rmatter` type
> > > extensible with existential boxes or, more generally, with e= xistential
> > > attributes. In that case, we will indeed be able to implemen= t tabulation
> > > boxes outside of the format module.
> > >
> > > Best wishes,
> > > Ivan Gotovchits
> > >
> > > [1]: https://caml.inria.fr/mantis/view.php?id=3D4665
> >

--f403045f7486f99ed4054532625e--