[Haskell-cafe] [Haskell-community] technical thoughts on stack

[Joachim Durchholz]

Am 16.09.2016 um 04:49 schrieb Bardur Arantsson:
> On 2016-09-16 02:19, Christopher Allen wrote:
>> The YAML parser backing hpack and Stack supports a subset of yaml, so
>> the complexity isn't there.
>
> As I understand it, the point of using YAML in this case isn't that
> "there's a library for that". It's that it's *standard* such that other
> tools can read/write it and know for certain that what gets read/written
> is at the very least 'syntactically' correct.

That. The promise to the users of the language is: If you have YAML 
knowledge, you can reuse it anywhere, whether you're doing Haskell, 
Java, Cobol, or CMS.

 > As such, using some
> nebulous "subset of yaml" defined by an implementation[1] doesn't really
> make sense for interop purposes.

Interop isn't that important, because those files are going to be 
consumed by a single program mostly.

> (I'm honestly not sure how many *actually* fully conforming YAML parsers
> there are out there, but I'd place my bets of "not many" given the
> complexity of the spec. See http://yaml.org/spec/1.2/spec.html )

In the Java world, most parsers are at some 99.5% mark.
I.e. there are certain (usually well-documented) corner cases that don't 
work, and these corner cases are so rare that nobody cares enough about 
them to submit a PR.
Most corner cases have to do with multi-part YAMLs, and/or with start 
and end of the YAML part in a data stream.
YAML offers possibilities to specify arbitrary data types for 
subobjects, and while that's flexible, it's also a security nightmare 
and inherently dependent on the backend language, so different libraries 
tend to handle this differently. Also, it's a bit clunky, so people 
prefer to stick with lists of predefined data types (the list can be 
reconfigured so that is something you have to relearn for each 
application, but it's essentially just a list that you can consult, so 
people should be happy with that).

>> TOML isn't supported because a well-supported/known-good library
>> wasn't to hand, whereas the yaml one did. I don't think people would
>> mind changing over, but somebody has to do the work validating that
>> the one-still-maintained-of-two-libraries TOML library is suitable.
>
> Even though there are probably fewer implementations, TOML is aiming[2]
> to become a standard format, so it's (hopefully going to be) a standard
> and a much simpler one than YAML. That'll hopefully lead to more
> implementations over time, but who knows?

I'm sceptical.
TOML does not have much activity, some issues have been lying around 
since 2014 without a resolution, last activity was May 2016.

TOML is too simplicistic to be a standard format. No references, so no 
shared or cyclic data structures, no standard for binary data 
(essentially "choose whatever app-specific encoding you want"), no 
mechanism for application-specific data types (not a real restriction 
but requires the app to apply conversion, plus no way to restrict the 
key names).
It could be enough for Cabal, but it's not good enough to be universal, 
which condemns TOML to just a part of the ecosystem.