> On 2 Mar 2017, at 06:52, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> Personally, I've always disliked the SAX approach, where reads are forced=
 on you. I much prefer the reader approach, where you read at whatever pace=
 you like. It's rather more like an iterator in that respect.
>=20
> Such an approach makes it very easy on the code doing the reading, since =
it can do things like pass the reader to other code to interpret those para=
meters. Doing this with a SAX interface requires basically writing a state =
machine into a type. And why would you want to encourage that kind of codin=
g?
>=20
> You can get the same effects of a SAX interface with a Reader-like approa=
ch. Rather than standardizing the struct that interprets the JSON, you stan=
dardize the Reader as a Concept. A Reader has functions to read the next da=
tum, tell you want that datum is, etc. And you can standardize a similar Wr=
iter Concept, which has interfaces for writing the data.
>=20
> So you get all of the benefits you outline, but without the huge detrimen=
t of using SAX to process stuff.

I wonder if the SAX approach when combined with coroutines could provide th=
e kind of decoupling you are looking for. We (the authors of taocpp/json an=
d the PEGTL, which is the underlying parser library) are already waiting fo=
r coroutines to be able to play with pull-like interfaces instead of push-l=
ike interfaces. I do wonder about the efficiency, though. Anyways, for now,=
 we are using the SAX-like interface and I'd like to see some real code of =
an alternative, as your above statement are too theoretical for me. Do you =
have a link to a library which uses such an approach?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1C39BD01-B470-41D3-8F49-4781D9BBB3BE%40gmx.de.

.

------=_Part_269_52680429.1488473175623
Content-Type: multipart/alternative;
 boundary="----=_Part_270_2103257806.1488473175623"

------=_Part_270_2103257806.1488473175623
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 1:07:29 AM UTC-5, Daniel Frey wrote:
>
> > On 2 Mar 2017, at 06:52, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >
> > Personally, I've always disliked the SAX approach, where reads are
> forced on you. I much prefer the reader approach, where you read at
> whatever pace you like. It's rather more like an iterator in that respect.
> >
> > Such an approach makes it very easy on the code doing the reading, since
> it can do things like pass the reader to other code to interpret those
> parameters. Doing this with a SAX interface requires basically writing a
> state machine into a type. And why would you want to encourage that kind of
> coding?
> >
> > You can get the same effects of a SAX interface with a Reader-like
> approach. Rather than standardizing the struct that interprets the JSON,
> you standardize the Reader as a Concept. A Reader has functions to read the
> next datum, tell you want that datum is, etc. And you can standardize a
> similar Writer Concept, which has interfaces for writing the data.
> >
> > So you get all of the benefits you outline, but without the huge
> detriment of using SAX to process stuff.
>
> I wonder if the SAX approach when combined with coroutines could provide
> the kind of decoupling you are looking for. We (the authors of taocpp/json
> and the PEGTL, which is the underlying parser library) are already waiting
> for coroutines to be able to play with pull-like interfaces instead of
> push-like interfaces. I do wonder about the efficiency, though. Anyways,
> for now, we are using the SAX-like interface and I'd like to see some real
> code of an alternative, as your above statement are too theoretical for me.
> Do you have a link to a library which uses such an approach?


I haven't investigated JSON parsers, but Reader/StAX-style APIs are
significant in the XML parsing world. C# lives by them; XMLReader
<https://msdn.microsoft.com/en-us/library/system.xml.xmlreader(v=vs.110).aspx>
and XMLWriter
<https://msdn.microsoft.com/en-us/library/system.xml.xmlwriter(v=vs.110).aspx>
are the foundation of their XML processing systems. Even LibXML2 has a reader
interface <http://xmlsoft.org/examples/index.html#xmlReader>.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/142054fa-3614-4afc-a817-aa012377b48f%40isocpp.org.

------=_Part_270_2103257806.1488473175623
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 1:07:29 AM UTC-5, Daniel Fre=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; On 2 Mar 2017, at=
 06:52, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"5BTdJB7jCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; Personally, I&#39;ve always disliked the SAX approach, where reads=
 are forced on you. I much prefer the reader approach, where you read at wh=
atever pace you like. It&#39;s rather more like an iterator in that respect=
..
<br>&gt;=20
<br>&gt; Such an approach makes it very easy on the code doing the reading,=
 since it can do things like pass the reader to other code to interpret tho=
se parameters. Doing this with a SAX interface requires basically writing a=
 state machine into a type. And why would you want to encourage that kind o=
f coding?
<br>&gt;=20
<br>&gt; You can get the same effects of a SAX interface with a Reader-like=
 approach. Rather than standardizing the struct that interprets the JSON, y=
ou standardize the Reader as a Concept. A Reader has functions to read the =
next datum, tell you want that datum is, etc. And you can standardize a sim=
ilar Writer Concept, which has interfaces for writing the data.
<br>&gt;=20
<br>&gt; So you get all of the benefits you outline, but without the huge d=
etriment of using SAX to process stuff.
<br>
<br>I wonder if the SAX approach when combined with coroutines could provid=
e the kind of decoupling you are looking for. We (the authors of taocpp/jso=
n and the PEGTL, which is the underlying parser library) are already waitin=
g for coroutines to be able to play with pull-like interfaces instead of pu=
sh-like interfaces. I do wonder about the efficiency, though. Anyways, for =
now, we are using the SAX-like interface and I&#39;d like to see some real =
code of an alternative, as your above statement are too theoretical for me.=
 Do you have a link to a library which uses such an approach?</blockquote><=
div><br>I haven&#39;t investigated JSON parsers, but Reader/StAX-style APIs=
 are significant in the XML parsing world. C# lives by them; <a href=3D"htt=
ps://msdn.microsoft.com/en-us/library/system.xml.xmlreader(v=3Dvs.110).aspx=
">XMLReader</a> and <a href=3D"https://msdn.microsoft.com/en-us/library/sys=
tem.xml.xmlwriter(v=3Dvs.110).aspx">XMLWriter</a> are the foundation of the=
ir XML processing systems. Even LibXML2 has a <a href=3D"http://xmlsoft.org=
/examples/index.html#xmlReader">reader interface</a>.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/142054fa-3614-4afc-a817-aa012377b48f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/142054fa-3614-4afc-a817-aa012377b48f=
%40isocpp.org</a>.<br />

------=_Part_270_2103257806.1488473175623--

------=_Part_269_52680429.1488473175623--

.

> On 2 Mar 2017, at 20:41, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> I have a working understanding of SAX-style interfaces. My problem with S=
AX-style interfaces is that it forces you to implement a state machine, bec=
ause all data is routed through a single object.

No.

> Pull APIs allow you to structure your code in a way that is structured. Y=
ou get in a value. You test what it is. You then pass call a function to pr=
ocess that kind of data, passing it the StAX reader. That function reads mo=
re values, recursively descending through the JSON in a manner reminiscent =
of a recursive descent parser.

A pull interface like the one you linked as an example needs to track state=
 of the current path, etc. and thus has a lot more overhead than the code I=
 have right now.

> Push APIs require you to route all of this processing work through a sing=
le object. And therefore, it has to store which state its currently on, so =
that it can send that state the data in question. It's just a big pain to d=
eal with, one which doesn't use the C++ stack effectively.

Wrong. Have you even looked at the examples I linked?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/E082A12D-F61E-4EE7-8276-188FD805DC96%40gmx.de.

.

------=_Part_366_213637999.1488487065530
Content-Type: multipart/alternative;
 boundary="----=_Part_367_512809982.1488487065530"

------=_Part_367_512809982.1488487065530
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 3:01:12 PM UTC-5, Daniel Frey wrote:
>
> > On 2 Mar 2017, at 20:41, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >
> > I have a working understanding of SAX-style interfaces. My problem with
> SAX-style interfaces is that it forces you to implement a state machine,
> because all data is routed through a single object.
>
> No.
>

Um... yes? Your examples show precisely that interface. Every time the
parser reaches a new JSON value, you get a function call in that object.
And therefore, it must forward that information to the place where it will
actually be processed.


>
> > Pull APIs allow you to structure your code in a way that is structured.
> You get in a value. You test what it is. You then pass call a function to
> process that kind of data, passing it the StAX reader. That function reads
> more values, recursively descending through the JSON in a manner
> reminiscent of a recursive descent parser.
>
> A pull interface like the one you linked as an example needs to track
> state of the current path, etc. and thus has a lot more overhead than the
> code I have right now.
>

Current path to what? Pull APIs don't need to "track" anything except where
it currently is in the file/string/data stream/etc.

I've actually written an XML Writer (in Lua), and the only state it had was
a stack of element names. And that's *only* because XML requires you to put
element names in the closing tag. For JSON, it wouldn't even have that;
it'd be virtually stateless, aside from any of the pretty-printng stuff.

> Push APIs require you to route all of this processing work through a
> single object. And therefore, it has to store which state its currently on,
> so that it can send that state the data in question. It's just a big pain
> to deal with, one which doesn't use the C++ stack effectively.
>
> Wrong. Have you even looked at the examples I linked?
>

If you're referring to this post
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/JNZzOvC7llo/AmwJs-LhCQAJ>,
those are examples of trivial things that don't need state, or whose state
is trivial. "stringify" and "prettify" do the same operation on the same
things, no matter where they appear in the JSON hierarhcy. Yes, SAX shines
in such circumstances.

But these are not *useful* circumstances for parsing JSON files. Generally
speaking, the way you interpret data depends on how that data was
interpreted before you.

Show me what your code would have to look like to be able to parse a JSON
langauge of decent complexity, like glTF
<https://en.wikipedia.org/wiki/GlTF>. I *guarantee* you that you're going
to have to build some form of state machine.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6e134f9-282b-40f0-874a-46df85c97f83%40isocpp.org.

------=_Part_367_512809982.1488487065530
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 3:01:12 PM UTC-5, Daniel Fre=
y wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; On 2 Mar 2017, at=
 20:41, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"ADouHJ0QCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; I have a working understanding of SAX-style interfaces. My problem=
 with SAX-style interfaces is that it forces you to implement a state machi=
ne, because all data is routed through a single object.
<br>
<br>No.<br></blockquote><div><br>Um... yes? Your examples show precisely th=
at interface. Every time the parser reaches a new JSON value, you get a fun=
ction call in that object. And therefore, it must forward that information =
to the place where it will actually be processed.<br>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
<br>&gt; Pull APIs allow you to structure your code in a way that is struct=
ured. You get in a value. You test what it is. You then pass call a functio=
n to process that kind of data, passing it the StAX reader. That function r=
eads more values, recursively descending through the JSON in a manner remin=
iscent of a recursive descent parser.
<br>
<br>A pull interface like the one you linked as an example needs to track s=
tate of the current path, etc. and thus has a lot more overhead than the co=
de I have right now.<br></blockquote><div><br>Current path to what? Pull AP=
Is don&#39;t need to &quot;track&quot; anything except where it currently i=
s in the file/string/data stream/etc.<br><br>I&#39;ve actually written an X=
ML Writer (in Lua), and the only state it had was a stack of element names.=
 And that&#39;s <i>only</i> because XML requires you to put element names i=
n the closing tag. For JSON, it wouldn&#39;t even have that; it&#39;d be vi=
rtually stateless, aside from any of the pretty-printng stuff.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">&gt; Push APIs require you to=
 route all of this processing work through a single object. And therefore, =
it has to store which state its currently on, so that it can send that stat=
e the data in question. It&#39;s just a big pain to deal with, one which do=
esn&#39;t use the C++ stack effectively.
<br>
<br>Wrong. Have you even looked at the examples I linked?<br></blockquote><=
div><br>If you&#39;re referring <a href=3D"https://groups.google.com/a/isoc=
pp.org/d/msg/std-proposals/JNZzOvC7llo/AmwJs-LhCQAJ">to this post</a>, thos=
e are examples of trivial things that don&#39;t need state, or whose state =
is trivial. &quot;stringify&quot; and &quot;prettify&quot; do the same oper=
ation on the same things, no matter where they appear in the JSON hierarhcy=
.. Yes, SAX shines in such circumstances.<br><br>But these are not <i>useful=
</i> circumstances for parsing JSON files. Generally speaking, the way you =
interpret data depends on how that data was interpreted before you.<br><br>=
Show me what your code would have to look like to be able to parse a JSON l=
angauge of decent complexity, like <a href=3D"https://en.wikipedia.org/wiki=
/GlTF">glTF</a>. I <i>guarantee</i> you that you&#39;re going to have to bu=
ild some form of state machine.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a6e134f9-282b-40f0-874a-46df85c97f83%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a6e134f9-282b-40f0-874a-46df85c97f83=
%40isocpp.org</a>.<br />

------=_Part_367_512809982.1488487065530--

------=_Part_366_213637999.1488487065530--

.