"keywords" are valid identifiers

[hclarke]

it looks like true, false, and null are valid identifiers

that doesn't really conflict with anything, but it seems a bit weird?

options i see:

• explicitly disallow that
• allow any value as an identifier (not just stringy ones)
• leave it as-is

[zkat]

This is already disambiguated by the grammar so I'm not really concerned about it too much? Like, true=false might look weird but it's clear that it means one thing

[zkat]

I've actually been thinking about this, and I've started to want to work on something called fkdl, which would be built on top of KDL and provide Dhall-like features ("functions", variables, etc).

To do this, I've been thinking that yes, keywords should be banned from bare identifiers, and so should initial numbers (and strings, but that's already taken care of). I'm thinking even if I don't do FKDL right away, I want KDL to leave the doors open to it?

[larsgw]

going the other direction: thoughts on dropping the "identifiers can't start with a digit" rule?

At that point you could effectively have a list of numbers which is fine but possibly unintended? At least, I remember that being one of the original differences between KDL and other config languages (like SDLang).

To do this, I've been thinking that yes, keywords should be banned from bare identifiers, and so should initial numbers [...]. I'm thinking even if I don't do FKDL right away, I want KDL to leave the doors open to it?

I think I personally prefer keeping KDL simpler and FKDL a backwards-incompatible extension. Reserving keywords could be a hassle unless we have a comprehensive list soon, before widespread adaptation of KDL (:crossed_fingers:).

(and strings, but that's already taken care of)

Node names can still be specified with (quoted) strings right?

[hclarke]

i was also thinking of making a templating/configuration language
(it's been on my mind for a while. this project seems like a cool data language to target)

what sort of problems do you see with a dhall-like thing if you allowed those identifiers?
would you be banning fkdl keywords (like let or type or something)?

[zkat]

I think I personally prefer keeping KDL simpler and FKDL a backwards-incompatible extension.

That's definitely the idea. The tricky thing is designing KDL such that it leaves that door open

what sort of problems do you see with a dhall-like thing if you allowed those identifiers?
would you be banning fkdl keywords (like let or type or something)?

I'm actually having trouble coming up with actual problems, and I realize that's because KDL doesn't have anything like variables. Identifiers are exactly in two places: node names, and property names. That's it. For that purpose, pretty much the only restriction we really need is preventing = (because of properties), whitespace/newlines, {}, and ; (I think that's all we actually need to ban?). I do want to reserve a couple of symbols just for future use, such as [] and (), but that's it.

As far as how I picture a templating/configuration language working, I'm thinking of treating KDL as a very simple, s-expression style thing, and any language built such that logic happens within that syntax. I was thinking [] would make a great candidate for "variables" and "keywords" in such a language. But I'm a lisper and these things seem natural to me, rather than building a whole programming language syntax on top of KDL with keywords and the like:

[if] [$x == true] {
  user "zkat"
}

...or something ridiculous along those lines. :)

[hclarke]

yeah, that seems natural to me, too :)

i see two different paths to making fkdl:

• reserve some symbols, and have the fkdl parser use those (it implements read and eval)
• allow more things, and have fkdl use kdl's parser (it only implements eval, not read)

[hkolbeck-streem]

In my opinion true=false is confusing enough to disallow keywords (I've been calling them literals, not sure where I got that from) as identifiers. It seems like a small imposition to require quotes "true"=false.

Currently kdl4j disallows keywords as identifiers, but I'll fix that if folks solidify this.

[zkat]

I'm converting this to an issue to make sure it's resolved for #112