berkus
/
kdl
mirror of https://github.com/kdl-org/kdl.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

update readme and add/remove related tests

This commit is contained in:
Kat Marchán 2024-11-27 17:27:03 -08:00
parent 4881523a9c
commit c81fa4d252
No known key found for this signature in database
GPG Key ID: AEB529C08A3C7E9E
5 changed files with 10 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
README.md
View File

@ -159,10 +159,10 @@ node3 #"C:\Users\zkat\raw\string"#
You don't have to quote strings unless any the following apply: You don't have to quote strings unless any the following apply:
* The string contains whitespace. * The string contains whitespace.
* The string contains any of `[]{}()\/#";`. * The string contains any of `[]{}()\/#";`.
* The string is one of `true`, `false`, or `null`. * The string is one of `true`, `false`, `null`, `inf`, `-inf`, or `nan`.
* The strings starts with a digit, or `+`/`-`/`.`/`-.`,`+.` and a digit. * The strings starts with a digit, or `+`/`-`/`.`/`-.`,`+.` and a digit.
* The string contains an equals sign (including unicode equals signs `﹦`, (aka "looks like a number")
`＝`, and `🟰`). * The string contains an equals sign.
In essence, if it can get confused for other KDL or KQL syntax, it needs In essence, if it can get confused for other KDL or KQL syntax, it needs
quotes. quotes.
@ -296,8 +296,8 @@ smile 😁
// Identifiers are very flexible. The following is a legal bare identifier: // Identifiers are very flexible. The following is a legal bare identifier:
<@foo123~!$%^&*.:'|?+> <@foo123~!$%^&*.:'|?+>
// And you can also use unicode, even for the equals sign! // And you can also use unicode!
ノード　お名前＝☜(ﾟヮﾟ☜) ノード　お名前=ฅ^•ﻌ•^ฅ
// kdl specifically allows properties and values to be // kdl specifically allows properties and values to be
// interspersed with each other, much like CLI commands. // interspersed with each other, much like CLI commands.
@ -335,9 +335,9 @@ SDLang, but that had some design choices I disagreed with.
#### Ok, then, why not SDLang? #### Ok, then, why not SDLang?
SDLang is designed for use cases that are not interesting to me, but are very SDLang is an excellent base, but I wanted some details ironed out, and some
relevant to the D-lang community. KDL is very similar in many ways, but is things removed that only really made sense for SDLang's current use-cases, including
different in the following ways: some restrictions about data representation. KDL is very similar in many ways, except:
* The grammar and expected semantics are [well-defined and specified](SPEC.md). * The grammar and expected semantics are [well-defined and specified](SPEC.md).
* There is only one "number" type. KDL does not prescribe representations. * There is only one "number" type. KDL does not prescribe representations.

1
tests/test_cases/expected_kdl/unicode_equals_signs.kdl
View File

@ -1 +0,0 @@
node p1=val1 p2=val2 p3=val3

1
tests/test_cases/expected_kdl/unicode_silly.kdl Normal file
View File

@ -0,0 +1 @@
ノード　お名前=ฅ^•ﻌ•^ฅ

4
tests/test_cases/input/unicode_equals_signs.kdl
View File

@ -1,4 +0,0 @@
node \
p1﹦val1 \ // U+FE66
p2＝val2 \ // U+FF1D
p3🟰val3 // U+1F7F0

1
tests/test_cases/input/unicode_silly.kd Normal file
View File

@ -0,0 +1 @@
ノード　お名前=ฅ^•ﻌ•^ฅ