-
Notifications
You must be signed in to change notification settings - Fork 211
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
Use "in" as a field name (despite its keyword status) #31
Comments
There isn't a way to name a field For example, the https://github.com/Gabriel439/Haskell-Dhall-Library/blob/master/src/Dhall.hs#L428 So it would make sense to do the same for the However, that change alone would require that you need to compile your own custom |
It would also be handy to have a way to put dashes in record names, such as While a transformation function could work, it may also be beneficial to allow some sort of escaped or quoted record field name, perhaps like the |
I like the idea of quoted record field names. That should be pretty easy to implement and it solves this problem cleanly |
In Scala you can use backticks, I personally like that as syntax
|
So for @scott-fleischman's use case, I can actually just add |
So I have some new reservations about this proposal after attempting a first pass at implementing this. Let's assume for simplicity that we begin from @markus1189's proposal and use backticks to escape identifiers. The next decision is: what set of characters do you permit within backticks? There are three choices that I'm ware of:
So my inclination here is to still rely on field modifiers instead of verbatim identifiers to solve the original problem, but to add |
Part of #31, requested by @scott-fleischman You can now use `-` in identifier names for all but the first character. That means that this is now legal code: ``` { resolver = "lts-8.1", extra-deps = [ "pipes-4.3.1" ] } ``` This primarily serves people who want to use "kebab-case" for their identifier names Normally languages do not support dash in identifier names due to ambiguity with the subtraction operator. For example, an identifier like `extra-deps` could be interpreted as `extra` minus `deps`. However, Dhall does not support subtraction and only supports unary negation so there is no ambiguity.
I think the argument for the 2) approach is that you can have a pipeline into a format that is not dhall: |
So for each |
Actually, I've changed my mind on this. I'll support the second option since it seems like an unusually common use case that shouldn't require going to the Haskell API |
You can now escape an field or variable name using backticks, like this: ```haskell let `let` = 2 in let `in` = True in { `True` = `let` , `Type` = λ(`Kind` : Bool) → `Kind` && `in` } ``` The main purpose of this is to support arbitrary record field names when marshalling Dhall into other file formats (such as JSON). For example, this Dhall configuration file: ```haskell { swagger = "2.0" , parameters = { foo = { name = "foo" , `in` = "path" , type = "string" } } ... } ``` ... can be used to generate this JSON file: ```json swagger: "2.0" parameters: foo: name: "foo" in: "path" type: "string" ```
Alright. I created a pull request that implements @markus1189's proposed syntax: #43 Let me know if that solves your use case |
Is there any way to produce a record with a field name "in"? (I fear not, since it's a keyword for
let
expressions.) I was playing with the idea of using Dhall to produce a YAML file (withdhall-to-yaml
) for use with Swagger (http://swagger.io), which as part of defining parameters that an API endpoint can accept, uses an object key "in" to specify where a parameter can occur.For example,
to produce
The text was updated successfully, but these errors were encountered: