search

toml-lang / toml.io

Source Code for toml.io
https://toml.io
MIT License
42 stars 44 forks source link

I guess we're making a semi-blessed JS TOML parser for the website! #2

Closed workingjubilee closed 4 years ago

workingjubilee commented 5 years ago

Following up on this:

@workingjubilee Yes please! haha I hadn't figured out how to actually do that yet, but I found this site: https://toolkit.site/format.html so I knew it was possible.

@mojombo had a good point that some types aren't directly translatable, like native datetimes. What do we do in those cases? Maybe just output a string version of the datetime? Or replace the content with a comment (even though it isn't technically legal in JSON)? Likewise do you take a datetime string in JSON and try and covert it to native datetime for TOML?

Originally posted by @cannikin in https://github.com/toml-lang/toml.io/issues/1#issuecomment-526330420

We can do "lossy data, but structural match" or "lossy structure, but data match" translation across JSON : TOML, the data-lossless one involving type annotations embedded in the JSON structure. By default, we can favor the first, cleanest translation (where JSON and TOML are 1 to 1), but when the translation would involve loss of type data like that, we can display an error state or perhaps a "warning state" I guess and point the user to an option to enable alternative translations. After all, we already have to intelligently handle JSON literals ("Uh, Ma'am, this is a hash table").

I think recognizing JSON strings that are exact matches for the subsets of the RFC3339 format that TOML supports and casting them to TOML datetimes is a sane default, because it's lossless as a result, but not if they are off by even a single whitespace(!), and that a similar logic of Maximal Strictness would serve well on all type casts. No guessing and no magic, really, just return to user and comment on the results, maybe offer choices if we can. And I think that's going to be easiest. Edited: I'm so sorry, I was mid-way through my coffee when I first posted this.

pradyunsg commented 5 years ago

Or... We can drop that section. 🙃

I'm ambivalent to whatever we do here.

cannikin commented 5 years ago

haha That's a possibility too. The reason I added it was when I start comping I wanted to include the TOML vs JSON vs YAML examples. I found a converter (first or second result in google for "toml converter") and I thought "the first result should be toml.io, not some random site". But that was probably my vanity speaking, not the pragmatic/lazy programmer speaking. ;)

eksortso commented 5 years ago

I wouldn't mind dropping that section. If we're pitching a human-readable, human-writable format (and we are), then letting people see what they can do, and letting it tumble around in their head for a bit, is what's important. The rest of the site can point them to the latest spec, solid implementations, and maybe live demos.

workingjubilee commented 5 years ago

Aw, OK! It is definitely more of a nice-to-have.

Though, of nice-to-haves, maybe "an automatic TOML validator" would come first, which is really just folding instaparse.mojombo.com into toml.io.

pradyunsg commented 4 years ago

Closing, since we've dropped that section. :)