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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id C526F7F615 for ; Mon, 19 Dec 2016 19:51:13 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lf0-f49.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of ivg@ieee.org designates 209.85.215.49 as permitted sender) identity=mailfrom; client-ip=209.85.215.49; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f49.google.com) identity=helo; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lf0-f49.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AmbahkhbAlTzVdvsbbTkYvbv/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZoMW9bnLW6fgltlLVR4KTs6sC0LuN9f+/EjVZsd6oizMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVr?= =?us-ascii?q?O+/7BpDdj9it1+C15pbffxhEiCCzbL52Ihi6twfcu8sZjYd/N6o8yQbCr2dVde?= =?us-ascii?q?hR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG87+MPktR/Y?= =?us-ascii?q?TQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD+/4apnVAPkhS?= =?us-ascii?q?EaPDMi7mrZltJ/g75aoBK5phxw3YjUYJ2ONPFjeq/RZM4WSXZdUspUUSFKH4Gy?= =?us-ascii?q?YJYVD+cZP+lYoYnzqVUNoxWjGwejGPjixSVUinLsx6A2z/gtHAPA0Qc9H9wOqn?= =?us-ascii?q?PUrNDtOakRT+C61q/IxijCYfNRxTf975bIfQwhofGNQbJwatfaxE4uFwPbgVWd?= =?us-ascii?q?so3lMC2L2esTqWSb6PBgVe22hmMhtgp/rD+vxsI2hYnIgIIY0lHE9SNjwIY0P9?= =?us-ascii?q?K0UkB7YcS8HJtftiGaK4t2Qt45TG1ypCk6zbgGtJimdyYJ0JQq3wDTZ+CDfoSS?= =?us-ascii?q?4R/uVPydLSlliH9lYr6yiBK//E69wePmTMa0ykxFri9dn9nMqH8N0xvT59CCSv?= =?us-ascii?q?Rn/0eh3S+D1wTd6u1YOEw0m6XWJpo7zr4/kZoTtkvDHivol0nskKCWcUAk9vCp?= =?us-ascii?q?6+ThfLrmuoeRO5Fohgz6KKgjmcyyDf4mPgQTX2WX4+ux2bn78U38WrpKj/k2kq?= =?us-ascii?q?fDsJDdIMQWvq+5AxFa0os46hawESmp38oCkXkANlJFdwqLj5L1NFHWPPD4EfC/?= =?us-ascii?q?jkywnzhxwvDGOqTtApHMLnjYjLfsZq196k5ZyAor199T/ZNUCrcbIPLyQED9rt?= =?us-ascii?q?LYDgVqezCzlsnuAs9824dWYmmPD7WUKuuGvlaC/OMiJ6+Xb48YojvnA/cg7v/q?= =?us-ascii?q?y3Q+nAlOU7Ou2M42dnm+VtthP0KHanrtnsxJRWYUsSI/QeHnzlqYXmgAND6JQ6?= =?us-ascii?q?sg62RjW8qdBoDZS9Xo2eTZ0Q=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAAACK1hYhzHXVdFDGhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBARUBAQEBAgEBAQEIAQEBAYMMAQEBAQF5gQYHpCGHdodzhSWCCiqFeAK?= =?us-ascii?q?BewdBEgEBAQEBAQEBAQEBEgEBAQgNCQkdMIIzGgGCGgEBAQMBIwQZAQE3AQQLC?= =?us-ascii?q?wsHBioCAiEBEgEFAQ4OBhMIE4g2Aw8IDi6bWD+LGmiBbDyDDAEBBYQcDYNQAQE?= =?us-ascii?q?BAQYBAQEBAQEBGQgShiSEWYJIO4FqgleCXZADhHCFTTWGUoZwg3KCRYkLhH2JY?= =?us-ascii?q?oQ3gkkUHoEUDxcCbGcrEwODDCwgggYgNAEBiQgBAQE?= X-IPAS-Result: =?us-ascii?q?A0BPAAACK1hYhzHXVdFDGhoBAQEBAgEBAQEIAQEBARUBAQE?= =?us-ascii?q?BAgEBAQEIAQEBAYMMAQEBAQF5gQYHpCGHdodzhSWCCiqFeAKBewdBEgEBAQEBA?= =?us-ascii?q?QEBAQEBEgEBAQgNCQkdMIIzGgGCGgEBAQMBIwQZAQE3AQQLCwsHBioCAiEBEgE?= =?us-ascii?q?FAQ4OBhMIE4g2Aw8IDi6bWD+LGmiBbDyDDAEBBYQcDYNQAQEBAQYBAQEBAQEBG?= =?us-ascii?q?QgShiSEWYJIO4FqgleCXZADhHCFTTWGUoZwg3KCRYkLhH2JYoQ3gkkUHoEUDxc?= =?us-ascii?q?CbGcrEwODDCwgggYgNAEBiQgBAQE?= X-IronPort-AV: E=Sophos;i="5.33,374,1477954800"; d="scan'208,217";a="205143751" Received: from mail-lf0-f49.google.com ([209.85.215.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 19 Dec 2016 19:51:12 +0100 Received: by mail-lf0-f49.google.com with SMTP id t196so60458356lff.3 for ; Mon, 19 Dec 2016 10:51:12 -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=CCynWnQZo/6ESfzMvWMt+hSsL56pHaOJP6yJ2v++n4Q=; b=aXuhi+M7pUyJSlokTVy2oUL0FwshCNn03a8ZJ14p9Z/pPf0E4Ckk16ETClSUvDz42e dASxSLBJAhIlMQA23ZXILb2Gqkd4CGdzUrLw5eD67FZIRPqIx0Y1JdFK1aCZXIshBeuK 4Vy8GSxqhOWhWfR7ZjBZRzlyPeQm7Dz5oyuTG8HjUPI08miofIvqb/TR+I7b/XRWtOpc SYSwTCJ09Vxw2/GqoTO5WDTXS8fnJe5EzPgDRn7e/21KxmQw0WcWIHxvO6KNPCl/yFvO tRLlOKx5pLIZ1xTmH6CnOB6PU7Ir56QrCoFi67qAb+X+qo3G/QMFho83WR87nQ+xlK4/ Jzrw== 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=CCynWnQZo/6ESfzMvWMt+hSsL56pHaOJP6yJ2v++n4Q=; b=DOKW21hVBNCVASIz3ckPi2fu0JvRF8dJ6V+qLiViSc/tmyNH+k/5jAVOVfsCj+EqR5 380eIGemAr0y57sQUI+qqIsEK7Q6K2zpplPEy3upZ/UU+BtQe1oQWZMBPG6IVV6s8WL9 UYDB++IaexA9lKZ+rcPOwRuNYu0X1V1Vxb0+jRdYeUH1AAt0rMq6FZObstKDkYvHbZ8V 8UDwc77EssRw6879d9+a91/ZcPjLMMCm8Qr3fJ4M/7M0lS/oaRNXR0b0gOP90JjdT47O meuT3ceiZszV54m7Y0TAuZgFg2cDbwjGGt+sGkDv4yncQ3iEoe536m4Fj9P/q6ojDS7V +k3Q== X-Gm-Message-State: AKaTC00HPwYDU3hYvzDhJ2zuXcJvsBA6FM5sJ3/YA6oH6mGNba3e7/qRqxcv5WZ0Jg5Gcae9D2RnDk3jvibDdBiu X-Received: by 10.25.16.105 with SMTP id f102mr4843399lfi.99.1482173471332; Mon, 19 Dec 2016 10:51:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.93.99 with HTTP; Mon, 19 Dec 2016 10:51:10 -0800 (PST) In-Reply-To: References: From: Ivan Gotovchits Date: Mon, 19 Dec 2016 13:51:10 -0500 Message-ID: To: Gabriel Scherer Cc: caml-list , Pierre Weis Content-Type: multipart/alternative; boundary=001a113f929c414031054407674a Subject: Re: [Caml-list] Deprecation of tabulation boxes --001a113f929c414031054407674a Content-Type: text/plain; charset=UTF-8 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 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 > --001a113f929c414031054407674a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, the discussion literally says, we don't understa= nd tabulation, and it looks like nobody is using it, so let's just thro= w it away :)

We're using tabulation, and they are quite us= eful. Yep, I agree, that the interface for setting the marks is kind of awk= ward,=C2=A0
it would be nice if there would be a `pp_setup_tabs := =C2=A0_=C2=A0formatter -> int list -> unit` function, that would push= into the stack a new tabular box with
the specified tabulations.= =C2=A0

What concerning your solution with the alig= nment, it is less general and doesn't work in our case. First of all, t= he pretty printing functions, that are printing=C2=A0
into the co= lumns are not specified with `%s`, but with `%a` (e.g., address, memory str= ing, 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),=C2=A0
and pretty printers are registered sepa= rately, 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).=C2=A0
=
This design simplifies the actual instruction printers, by consolidati= ng the common code in the formatter setup procedure.=C2=A0

So, it is still not clear to me, why the tabulations are wrong. If= they do complicate=C2=A0the code base and raise the support cost, then it = is understandable, why you would like to remove it=C2=A0
from the= standard library. But in this case, it would be nice, to move this code ou= t as a separate library, as just removing a feature, that was in the langua= ge for years (I would say even forever,=C2=A0
if we will start th= e history from caml-light), without providing any substitution is... not ni= ce :)=C2=A0



On Mon, Dec 19, 2016 at 1:20 PM, Gabriel Scherer <gabri= el.scherer@gmail.com> wrote:
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 =3D [("x", "foo"); ("loop", "ba= r")]

let () =3D
=C2=A0 print_newline ();
=C2=A0 data |> List.iter (fun (lab, instr) -> Printf.printf "%5s= : %s\n" lab instr)
(*
=C2=A0 =C2=A0 x: foo
=C2=A0loop: bar
*)

let () =3D
=C2=A0 print_newline ();
=C2=A0 data |> List.iter (fun (lab, instr) -> Printf.printf "%-5= s: %s\n" lab instr)
(*
x=C2=A0 =C2=A0 : foo
loop : bar
*)

let () =3D
=C2=A0 let len =3D List.fold_left (fun m (lab, _) -> max m (String.lengt= h
lab)) 0 data in
=C2=A0 print_newline ();
=C2=A0 data |> List.iter (fun (lab, instr) -> Printf.printf "%*s= : %s\n" len
lab instr)
(*
=C2=A0 =C2=A0x: 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 t= ried to
> google for
> any reasons that justify the removal but found only a note by Pierre W= eis 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 bo= xes 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 tabulat= ion
> 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 tabulati= on
> break, or use some global variable. Neither solution can be considered=
> acceptable.
>
> Speaking about the usefulness. The tabulation boxes are useful for pri= nting
> 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 v= ery 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 b= oxes
> 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<= br> > feature.
>
> Given that, I would like to hear the justifications for the deprecatio= n of
> tabulation boxes and suggested workarounds.
>
> One possible workaround, that I could see, is making the `formatter` t= ype
> extensible with existential boxes or, more generally, with existential=
> attributes. In that case, we will indeed be able to implement tabulati= on
> boxes outside of the format module.
>
> Best wishes,
> Ivan Gotovchits
>
> [1]: https://caml.inria.fr/mantis/view.ph= p?id=3D4665

--001a113f929c414031054407674a--