From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: ANN: Simple components for Ada v.4.42 Date: Mon, 16 Sep 2019 09:44:40 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <7d04e6c3-9547-445c-a5cd-778fa97b62d1@googlegroups.com> NNTP-Posting-Host: 3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader01.eternal-september.org comp.lang.ada:57156 Date: 2019-09-16T09:44:40+02:00 List-Id: On 2019-09-16 08:58, briot.emmanuel@gmail.com wrote: > On Monday, September 16, 2019 at 8:48:36 AM UTC+2, Dmitry A. Kazakov wrote: >> The new version provides an implementation of JSON (RFC 7158) > > I would be curious to know the differences compared to what GNATCOLL.JSON provides, if you know ? It would be nice if the Ada world did not have too many packages competing here. > (Although I was the GNATCOLL maintainer for a long time, I did not write the JSON package, so this is really an open question :-) > > Various things which I find limiting in GNATCOLL.JSON: performance is not really good because there are a lot of memory allocations (your short description seems to indicate this might be an area where your package improves things); gnatcoll treats arrays and objects completely differently, one without tagged types and the other with; simple types systematically have to be converted explicitly to a json object with Create;... The difference as far as I can tell: 1. My JSON parser sits on top of table-driven parser with does all work. The implementation merely defines a table with JSON operations ("[]", "{}", ":"). 2. Parts of the input object are allocated in an external pool. The pool allocation policy is strictly LIFO, so an arena can be used to free JSON object once consumed. IMO there is no reason to keep JSON objects any longer. No tagged objects used. 3. No mutable JSON objects and construction methods are provided as I see no reason for having them for such a primitive thing. It is far more easier just to output JSON stuff using Ada I/O facilities or Strings_Edit. The only less trivial thing is JSON-escaped strings. For them a procedure Put and function Image are provided. > The GNATCOLL.JSON parser can be extended to support YAML (I have some local patches to support comments and optional quotes for strings, but not the indentation-based structures), but it would be nice if this was provided out of the box... YAML looks a completely different thing. Any relation to JSON seems purely historical. It would be no problem to write a table-driven parser for YAML, if there were demand. I am kind of sceptical regarding YAML usefulness. Not that JSON has much merits either, but at least it is actively used with HTTP REST API and JavaScript. YAML is like XML a wrong solution to a non-existent problem. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de