[v3] Tiny project, state of v3 etc

--===============0554524324292816493==
Content-Type: multipart/alternative; boundary="0000000000003606a6061bf54cac"

--0000000000003606a6061bf54cac
Content-Type: text/plain; charset="UTF-8"

Hello,

It's been a minute since I last explored Boost, Spirit, v3, etc, and I have
a tiny project for which I am interested to consider Spirit, maybe v3, as
one possible solution. Downloading the latest Boost 1.85 for starters, and
will dev against that, for now; unless there is a better, considered more
stable version.

Apologies for the digest here, but there are some nuances I should outline
approaching the question: might Boost Spirit, v2 or v3, possibly be able to
help, I'm uncertain. Highlighting key considerations:

- dotnet runtimes are the goal, decimal coordinates are a must for
precision reasons, literally to the centimeter measurements, including
fraction parts.
- Regex, antlr4 prototypes are under consideration; regex currently with
the lead in that race, antlr4 having some problems recognizing
decimal numerics.
- Spirit based approach would start from C++ and adapt either into C++ to
C# SWIG, or perhaps just land directly in a Visual C++ CLR project.
- Other nuances including anticipated coordinate input stream formats and
such, inclusion of axis identification, etc.

In a bit more depth:

Currently, mentioned below, I have been experimenting with an Antlr4 based
approach, but have been running into some difficulties with numeric
recognition, especially in the anticipated use cases.

Ultimately I need some 3D (dotnet) decimal (not float, definitely not
double) coordinates to be parsed, or at least made possible via C++ Interop
SWIG or C++ CLR. One key thing I should mention, the following forms should
be doable, if possible. I can tailor tests one way or another, if
necessary, but this is the aim, i.e. decimal coordinates, positive, and
negative versions should also be supported: "1.2", ".2", "1.", "1".

This is very key, although C++ float is probably my only choice there, I do
not know. Precision is an absolute must, floating point precision issues
cannot be tolerated. These are ultimately decimal coordinates in a 3D user
space, the dimensions are precise centimeters, so floating point errors
cannot be tolerated. Maybe float is best, double I think is straight out.
Unless perhaps there is a C++ CLR decimal equivalent I can consider.

One version of a parser is just the numbers in sequence, space delimited,
very easy I suspect, even with crude (or more sophisticated) whitespace
skippers, i.e. along these lines. "# # #", oversimplified of course and the
use cases are a bit more involved than that.

The next version is slightly more involved, 3D coordinate pairs, i.e. "X=#
Y=# Z=#", along these lines. In the first version, coordinate
identification should be positional in nature. In this version, of course,
I may produce an axis enum based coordinate identification.

Internally, I think it might be best to have internal productions
synthesizing a C++ DSL along these lines. And provide a listener strategy
coordinating, perhaps with C++ boost signals indicating when certain rules
have been triggered. At least that's the thought right now; not married to
it, unless anyone has a better suggestion off the cuff.

My aim is to either package the parser and SWIG it into C#, if at all
possible. Does not need to be fancy SWIG, but there are a couple of
architecturally established interfaces, abstract classes, along these
lines, which I would be extending. But I think the integration can be
somewhat contained, so the conventions do not necessarily need to align
that way, at least based on my Antlr4 results.

Or, failing SWIG, if it is even possible to think about it, jumping
directly into a Visual C++ CLR style project.

In summary, might Spirit, either v2 or v3, possibly work there? I do not
expect the rules, synthesis, etc, to be that complex. It will be trickier,
perhaps, to message a listener from the parser, but not insurmountable, I
think.

Thoughts?

Cheers, best,

Michael W. Powell

Some possibly useful links:

https://learn.microsoft.com/en-us/dotnet/api/system.decimal
https://swig.org
https://www.boost.org/users/history/version_1_85_0.html
https://www.boost.org/doc/libs/1_85_0/libs/spirit/repository/doc/html/index.html
https://www.boost.org/doc/libs/1_85_0/libs/spirit/doc/html/index.html

--0000000000003606a6061bf54cac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>It&#39;s been a minute since I l=
ast explored Boost, Spirit, v3, etc, and I have a tiny project for which I =
am interested to consider Spirit, maybe v3, as one possible solution. Downl=
oading the latest Boost 1.85 for starters, and will dev against that, for n=
ow; unless there is a better, considered more stable version.</div><div><br=
></div><div>Apologies for the digest here,=C2=A0but there are some nuances =
I should outline approaching the question: might Boost Spirit,=C2=A0v2 or v=
3, possibly be able to help, I&#39;m uncertain. Highlighting key considerat=
ions:</div><div><br></div><div>- dotnet runtimes are the goal, decimal coor=
dinates are a must for precision reasons, literally to the centimeter measu=
rements, including fraction parts.</div><div>- Regex, antlr4 prototypes are=
 under consideration; regex currently with the lead in that race,=C2=A0antl=
r4 having some problems recognizing decimal=C2=A0numerics.</div><div>- Spir=
it based approach would start from C++ and adapt either into C++ to C# SWIG=
, or perhaps just land directly in a Visual C++ CLR project.</div><div>- Ot=
her nuances including anticipated coordinate input stream formats and such,=
 inclusion of axis identification, etc.</div><div><br></div><div>In a bit m=
ore depth:</div><div><br></div><div>Currently, mentioned below, I have been=
 experimenting with=C2=A0an Antlr4=C2=A0based approach,=C2=A0but have been =
running into some difficulties with numeric recognition, especially in the =
anticipated use cases.</div><div><br></div><div>Ultimately I need some 3D (=
dotnet) decimal (not float, definitely not double) coordinates to be parsed=
, or at least made possible via C++ Interop SWIG or C++ CLR. One key thing =
I should mention, the following forms should be doable, if possible. I can =
tailor tests one way or another, if necessary, but this is the aim, i.e. de=
cimal coordinates, positive, and negative versions should also be supported=
: &quot;1.2&quot;, &quot;.2&quot;, &quot;1.&quot;, &quot;1&quot;.</div><div=
><br></div><div>This is very key, although C++ float is probably my only ch=
oice there, I do not know. Precision is an absolute must,=C2=A0floating poi=
nt precision issues cannot be tolerated. These are ultimately decimal coord=
inates in a 3D user space, the dimensions are precise centimeters, so float=
ing point errors cannot be tolerated. Maybe float is best, double I think i=
s straight out. Unless perhaps there is a C++ CLR decimal equivalent I can =
consider.</div><div><br></div><div>One version of a parser is just the numb=
ers in sequence, space delimited, very easy I suspect, even with crude (or =
more sophisticated) whitespace skippers,=C2=A0i.e. along these lines. &quot=
;# # #&quot;, oversimplified of course and the use cases are a bit more inv=
olved than that.</div><div><br></div><div>The next version is slightly more=
 involved, 3D coordinate pairs, i.e. &quot;X=3D# Y=3D# Z=3D#&quot;, along t=
hese lines. In the first version, coordinate identification should be posit=
ional in nature. In this version, of course, I may produce an axis enum bas=
ed coordinate identification.</div><div><br></div><div>Internally, I think =
it might be best to have internal productions synthesizing a C++ DSL along =
these lines. And provide a listener strategy coordinating, perhaps with C++=
 boost signals indicating when certain rules have been triggered. At least =
that&#39;s the thought right now; not married to it,=C2=A0unless anyone has=
 a better suggestion off the cuff.</div><div><br></div><div>My aim is to ei=
ther package the parser and SWIG it into C#, if at all possible. Does not n=
eed to be fancy SWIG, but there are a couple of architecturally established=
 interfaces, abstract classes, along these lines, which I would be extendin=
g. But I think the integration can be somewhat contained, so the convention=
s do not necessarily need to align that way,=C2=A0at least based on my Antl=
r4 results.</div><div><br></div><div>Or, failing SWIG, if it is even possib=
le to think about it, jumping directly into a Visual C++ CLR style project.=
</div><div><br></div><div>In summary, might Spirit, either v2 or v3, possib=
ly work there? I do not expect the rules, synthesis, etc, to be that comple=
x. It will be trickier, perhaps, to message a listener from the parser, but=
 not insurmountable, I think.</div><div><br></div><div>Thoughts?<br></div><=
div><br></div><div><div>Cheers, best,</div><div><br></div><div>Michael W. P=
owell</div><div><br></div></div><div>Some possibly useful links:</div><div>=
<br></div><div><a href=3D"https://learn.microsoft.com/en-us/dotnet/api/syst=
em.decimal">https://learn.microsoft.com/en-us/dotnet/api/system.decimal</a>=
<br></div><div><a href=3D"https://swig.org">https://swig.org</a><br></div><=
div><a href=3D"https://www.boost.org/users/history/version_1_85_0.html">htt=
ps://www.boost.org/users/history/version_1_85_0.html</a><br></div><div><a h=
ref=3D"https://www.boost.org/doc/libs/1_85_0/libs/spirit/repository/doc/htm=
l/index.html">https://www.boost.org/doc/libs/1_85_0/libs/spirit/repository/=
doc/html/index.html</a><br></div><div><a href=3D"https://www.boost.org/doc/=
libs/1_85_0/libs/spirit/doc/html/index.html">https://www.boost.org/doc/libs=
/1_85_0/libs/spirit/doc/html/index.html</a><br></div><div><br></div></div>

--0000000000003606a6061bf54cac--


--===============0554524324292816493==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============0554524324292816493==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Spirit-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spirit-general

--===============0554524324292816493==--