Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support TOML spec v1.0.0 #373

Open
chshersh opened this issue Mar 27, 2021 · 2 comments
Open

Support TOML spec v1.0.0 #373

chshersh opened this issue Mar 27, 2021 · 2 comments
Labels
parser Everything related to `Text -> Toml`

Comments

@chshersh
Copy link
Contributor

The latest spec is released here:

Need to check what changed since 0.5.0. Probably, will be easier to do together with #372.

@chshersh chshersh added the parser Everything related to `Text -> Toml` label Mar 27, 2021
@chshersh chshersh pinned this issue Mar 27, 2021
@dariodsa
Copy link
Collaborator

  • Allow heterogenous values in arrays.
# Mixed-type arrays are allowed
numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]
contributors = [
  "Foo Bar <[email protected]>",
  { name = "Baz Qux", email = "[email protected]", url = "https://example.com/bazqux" }
]
  • Allow raw tab characters in basic strings and multi-line basic string

  • Added examples for invalid float values

# INVALID FLOATS
invalid_float_1 = .7
invalid_float_2 = 7.
invalid_float_3 = 3.e+20
  • Leading zeroes in exponent parts of floats are permitted
flt7 = 6.626e-034
An exponent part is an E (upper or lower case) followed by an integer part (which follows the same rules as decimal integer values but may include leading zeros).
  • keys
    • Since bare keys are allowed to compose of only ASCII integers, it is possible to write dotted keys that look like floats but are 2-part dotted keys. Don't do this unless you have a good reason to (you probably don't).
  3.14159 = "pi"
  This line maps to the following JSON
  { "3": { "14159": "pi" } }
  • Clarify that indentation before keys is ignored.
fruit. color = "yellow"    # same as fruit.color
fruit . flavor = "banana"   # same as fruit.flavor
  • Clarify that indentation between array values is ignored.
integers3 = [
  1,
  2, # this is ok
]
  • Clarify that indentation before table headers is ignored.
[ g .  h  . i ]    # same as [g.h.i]
[ j . "ʞ" . 'l' ]  # same as [j."ʞ".'l']
  • Clarify that line-ending backslashes must be unescaped in multi-line strings.
str3 = """\
       The quick brown \
       fox jumps over \
       the lazy dog.\
       """
  • Clarify that control characters are not permitted in comments.
Control characters other than tab (U+0000 to U+0008, U+000A to U+001F, U+007F) are not permitted in comments.
  • Clarify that inline tables are immutable.
 Inline tables fully define the keys and sub-tables within them. New keys and sub-tables cannot be added to them.
  • Clarify that trailing commas are not allowed in inline tables.
A terminating comma (also called trailing comma) is not permitted after the last key/value pair in an inline table.
  • Clarify that comments and newlines are allowed before commas in arrays.
Arrays can span multiple lines. ... Any number of newlines and comments may precede values, commas, and the closing bracket.

I think that for start that should be enough. The specification didn't change too much, it only specified some things more thoroughly.

@brandonchinn178
Copy link

brandonchinn178 commented Apr 2, 2022

@chshersh any idea when v1 support might be added? Really looking forward to using this library, but heterogenous array support is pretty important to my use-case right now. Or, anything I could do to help?

Also it seems like there's at least one more addition for v1.0.0: plain foo.bar.baz keys seem to be synonymous with a baz key in a [foo.bar] table (alluded to in the Table section)

fruit.apple.color = "red"
# Defines a table named fruit
# Defines a table named fruit.apple

fruit.apple.taste.sweet = true
# Defines a table named fruit.apple.taste
# fruit and fruit.apple were already created

so maybe the TOML type shouldn't distinguish between "pairs" and "tables"? Namely, the following should be exactly equivalent:

# one
fruit.name = "apple"

# two
[fruit]
name = "apple"

I'm still getting familiar with this library, but it seems like these two methods would be queried differently using the combinators in this library?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parser Everything related to `Text -> Toml`
Projects
None yet
Development

No branches or pull requests

3 participants