<div dir="ltr"><div>hey dimtrii, i'm sure theres other pieces, thats just the one i'm spec<br></div><div><br></div><div>robust engineering is for robustness. not for assuming sane users or nonadversarial inputs <br></div><div><br></div><div>relatedly/on that topic, you should probably consider using the float parser in the scientific package rather than <br></div><div><a href="https://hackage.haskell.org/package/tomland-1.3.2.0/docs/src/Toml.Parser.Value.html#floatP">https://hackage.haskell.org/package/tomland-1.3.2.0/docs/src/Toml.Parser.Value.html#floatP</a>, theres some easy to design malicious inputs otherwise (talking about robustness made me look to see if you were using what for parsing floats! ) </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 12, 2021 at 8:11 AM Dmitrii Kovanikov <<a href="mailto:kovanikov@gmail.com">kovanikov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The TOML format is optimized for human-readability, not space efficiency. And it has some data redundancy, which makes it great for the application configuration use-case but not so great as a serialization format. If you are using TOML to serialise data or you need to parse 3-10 GB of application configuration, there's a chance that something can be improved without streaming TOML parsing.<div><br></div><div>So streaming TOML parser looks like a very specific use-case that doesn't justify taking someone's package and making it the official TOML parser.</div><div><br></div><div>Best regards,</div><div>Dmitrii</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Mar 2021 at 12:40, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hey Dmitrii,</div><div dir="auto">I believe emily has in mind fully incremental streaming support. Which requires a wildly different internal architecture than all the stuff in the aeson inspired design family </div><div dir="auto"><br></div><div dir="auto"><div><a href="https://github.com/cartazio/streaming-machine-json" target="_blank">https://github.com/cartazio/streaming-machine-json</a></div>Is an example of a constant space json parser with fully incremental consumption and emissions. </div><div dir="auto"><br></div><div dir="auto">An predecessor  was used in a work prject 5 years ago and it could handle multi gig json monsters like a champ.  I never released it to hackage because I want to have a better / more reusable design.  Parsing the same 3-10gb json with aeson was impossible on a machine that had hundreds of gigs of ram. :) </div><div dir="auto"><br></div><div dir="auto">I believe emily has in mind similar levels of robustness </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 12, 2021 at 7:08 AM Dmitrii Kovanikov <<a href="mailto:kovanikov@gmail.com" target="_blank">kovanikov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi everyone,<div><br></div><div>I feel extremely sad about this discussion for multiple reasons. But regarding the technical agenda:</div><div><br></div><div>> I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`.</div><div><br></div><div>This does sound very disappointing to me and I don't fully understand the needs. Because:</div><div><br></div><div>* tomland is the official TOML parsing library in Haskell according to the <a href="https://github.com/toml-lang/toml/wiki" target="_blank">TOML spec wiki</a></div><div>* tomland fully supports the spec version 0.5.0, and the latest spec 1.0.0 was published relatively recently. And to my knowledge, it is the only Haskell library that supports the latest spec.</div><div>* tomland is the most popular TOML parsing library according to <a href="https://packdeps.haskellers.com/reverse" target="_blank">reverse dependencies</a> on Hackage</div><div>* tomland is based on explicit values, but nevertheless it provides deriving via Generics</div><div><br></div><div>I feel very confused about this situation. And again I feel like people the Haskell committees members are not willing to recognise other's people work and would rather rewrite everything from scratch instead of collaborating with existing projects created by people outside of committees. Even outside the Haskell community (the TOML org), tomland was acknowledged as the official TOML library, but not in the Haskell community itself.</div><div><br></div><div>At least, the following steps could be taken first:</div><div><br></div><div>* Why not open issues to tomland (or other libraries) and discuss the features you want? We maintain tomland for multiple years. The latest release was Feb 12 2021 (a month ago!). We constantly improve the implementation, fix parsing issues, improve interface and error-handling. Attempting to rewrite all this from scratch instead of collaborating with existing maintainers feels very unfriendly.</div><div>* If you want to have the official TOML parsing library under the `toml` namespace on Hackage, again, why not ask the maintainers if they consider moving the library? And only after this discussion act accordingly.</div><div>* If you are concerned about the lack of people working on the `tomland` library (which I don't fully understand, because in Kowainik we always have at least two people maintaining packages), then why not ask to add as a maintainer, instead of rewriting another library? Or even ask to move to the official `haskell` organization on GitHub, if you want to have more people maintaining the official package.</div><div><br></div><div>I mean, how am I supposed to feel motivated working on Haskell open-source projects, if my work can be just discarded at any time, the official library will be appointed without even communicating this desire? If I weren't subscribed to this thread, I probably wouldn't even know that something is going behind backs. We've put a lot of effort into tomland. We literally spent years of maintenance, UX improvements, bug fixes, writing tutorials and blog posts about the library and its implementation. And it is still not enough just to be respected and even give the chance to reply to the users needs?</div><div><br></div><div>That sounds very concerning to me. I don' feel like Haskell tech can move forward if people's (specifically if they are not associated with any Haskell leaders) work is disrespected.</div><div><br></div><div>Best regards,</div><div>Dmitrii</div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 12 Mar 2021 at 07:02, amindfv--- via Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Mar 12, 2021 at 06:28:44AM +0000, Emily Pillmore wrote:<br>
> Tom,<br>
> <br>
> Look, I don't want to debate syntax and semantics here, but "burning need/desire/ambition" etc ( <a href="https://idioms.thefreedictionary.com/burning+desire" rel="noreferrer" target="_blank">https://idioms.thefreedictionary.com/burning+desire</a> ) is an extremely common colloquialism that doesn't imply an emergency, just a strongly felt urge.  I can't apologize for my wording, but I'm sorry for the situation nonetheless.<br>
<br>
I also don't want to debate semantics but I can tell you "I have a burning need" on a Hackage takeover has a different connotation of urgency than "I have a burning desire to write a toml parsing library and to have it be named 'toml'". I still feel duped and now condescended to as well. I do nonetheless appreciate your apology for the situation.<br>
<br>
> > <br>
> > It's now seeming more just like a desire for the package name.<br>
> > <br>
> > <br>
> <br>
> I'm going to look at `toml-parser` in the meantime, but no toml library does what I have in mind (namely a full fledged implementation of the spec, streaming, deriving etc.), nor do many of them provide bidirectional serialization save `tomland`. To reiterate Carter's point, hackage names are a community resource, and they deserve to be thought through carefully, so yes, the package name is part of the request. I do alot of community service to make sure things that take up precious Hackage real-estate are treated well, which is why `toml` posed an opportunity.<br>
<br>
I'm actually open to the idea of using a simple name like "toml" for a best-in-class Haskell library, but I'd want to see proof that it is clearly the best in terms of implementation and adoption. I of course think my plans for toml parsing are the most wonderful, but if a consensus favorite package emerges and it's not mine I will step aside.<br>
<br>
> <br>
> To that point, anything you put out is something I am interested in investing time and effort into making a standard. Do you have any code currently, or is this a TODO on your list? Going through your hackage libraries, I see no source repository listings, issue trackers, or even an email to reach you by.<br>
<br>
I do have code, yes. As mentioned earlier I'm in the middle of a rewrite. If there's more to discuss maybe we should move this conversation off-list as it's no longer about a package takeover?<br>
<br>
Tom<br>
<br></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div>
</blockquote></div>
</blockquote></div>