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

Allow for block types with optional labels #666

Open
johakoch opened this issue Mar 8, 2024 · 5 comments
Open

Allow for block types with optional labels #666

johakoch opened this issue Mar 8, 2024 · 5 comments

Comments

@johakoch
Copy link

johakoch commented Mar 8, 2024

For couper we use an hcl-based configuration language. The language defines some block types that have optional labels, e.g.:

api {
}
api "my_api" {
}

are both valid. (In this configuration language there are no block types with more than one label.)

We implemented this in a fork by allowing a third token optional following label, e.g.

type API struct {
	// ...
	Name                 string    `hcl:"name,label,optional"`
	// ...
}

, which is not conformant with gohcl/doc.go:

// Within each tag there are two comma-separated tokens. The first is the
// name of the corresponding construct in configuration, while the second
// is a keyword giving the kind of construct expected.

. (We could also have used another "second" token, like optional_label, to get the same effect, though.)

Do you think this may be of use for other hcl-based languages as well?

@apparentlymart
Copy link
Contributor

Hi @johakoch!

Looking in your fork, I see that you've implemented it only for the native syntax, in package hclsyntax.

For this to be merged upstream it would need to work in the JSON variant too, but that's not really possible because it makes the interpretation of the syntax ambiguous. That's why this isn't supported in HCL today.

If you only care about the native syntax and are willing to keep maintaining your fork then of course this is fine! But for this upstream HCL we expect language designers to use a different block type name for each block header signature, because that then gives the JSON syntax decoder a hook to understand which interpretation the author intended.

@johakoch
Copy link
Author

johakoch commented Mar 8, 2024

Hi @apparentlymart
Yes, we only support the HCL native syntax.

So we will keep a fork and try to maintain it as time allows.

Thanks anyway

@johakoch
Copy link
Author

Hi @apparentlymart
Could the optional label

api {
}

be a short form of an empty label

api "" {
}

, which could have a JSON representation of

{
  "api" {
    "": {
    }
  }
}

?

@apparentlymart
Copy link
Contributor

Hi @johakoch,

That seems tricky if a block type has more than one label. I think it's clearer for each block type to have a fixed number of labels, rather than having a surprising shorthand for just one specific situation. It's also harder for the decoder to give good feedback about incorrect usage if there is more than one possible interpretation of a given input, so we've tried to avoid that as much as possible.

(Older versions of Terraform had quite awful error messages in large part because older versions of HCL were too forgiving in having many different ways to describe the same data structure. HCL 2 traded that flexibility for giving HCL more information to use when reporting errors.)

@johakoch
Copy link
Author

johakoch commented Mar 19, 2024

Hi @apparentlymart

Yes, it would only be applicable for blocks that have at most one label. So I guess it's not possible in a generic way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants