From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: ANN: Simple components for Ada v.4.42
Date: Mon, 16 Sep 2019 09:44:40 +0200
Date: 2019-09-16T09:44:40+02:00 [thread overview]
Message-ID: <qlneha$10v6$1@gioia.aioe.org> (raw)
In-Reply-To: 7d04e6c3-9547-445c-a5cd-778fa97b62d1@googlegroups.com
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
next prev parent reply other threads:[~2019-09-16 7:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 6:48 ANN: Simple components for Ada v.4.42 Dmitry A. Kazakov
2019-09-16 6:58 ` briot.emmanuel
2019-09-16 7:44 ` Dmitry A. Kazakov [this message]
2019-10-03 18:58 ` Olivier Henley
2019-10-03 19:58 ` Dmitry A. Kazakov
2019-10-03 21:16 ` Olivier Henley
2019-10-03 21:29 ` Olivier Henley
2019-10-04 7:56 ` Dmitry A. Kazakov
2019-09-16 8:18 ` J-P. Rosen
2019-09-16 19:10 ` Dmitry A. Kazakov
2019-10-03 23:53 ` onox
2019-10-04 7:56 ` Dmitry A. Kazakov
2019-10-04 10:52 ` Olivier Henley
2019-10-04 12:15 ` Dmitry A. Kazakov
2019-10-03 15:43 ` Olivier Henley
2019-10-03 17:51 ` Dmitry A. Kazakov
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox