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

User-defined grammars #613

Open
joneshf opened this issue Jun 29, 2019 · 6 comments
Open

User-defined grammars #613

joneshf opened this issue Jun 29, 2019 · 6 comments

Comments

@joneshf
Copy link
Collaborator

@joneshf joneshf commented Jun 29, 2019

Have we discussed the ability to describe grammars within the language? If so, link me to it and close this issue.

I haven't really thought out what I'm suggesting here, but I wonder if the ability to write a grammar in Dhall, and be able to parse Text into a value would be useful? Maybe something like:

Grammar/parse : Grammar a -> Text -> < error : Text, value : a >

The intent being that you're still dealing with structured data. Ideally, using Grammar a would naturally lead you to more structured values than plain old text manipulation does.

As for what level of grammars we'd be able to describe–regular, context-free, context-sensitive, recursively-enumerable–I don't have a requirement. I assume something that doesn't break totality would be a restriction. Text manipulation can stay restricted, I'm not wanting to change that.

I'm not stuck on any of the ideas I presented. Maybe the spirit of this idea would be useful?

@singpolyma

This comment has been minimized.

Copy link
Collaborator

@singpolyma singpolyma commented Jun 29, 2019

This would allow full text manipulation, pretty sure

@philandstuff

This comment has been minimized.

Copy link
Collaborator

@philandstuff philandstuff commented Jun 29, 2019

To expand @singpolyma’s comment: the first paragraph about text manipulation from your link says:

The only text manipulation allowed is concatenation. Other than that, Text values are opaque and there is no way to introspect them. For example, you cannot compare Text values for equality, nor can you compute their length.

But (context-free) grammars would provide a trivial way to compute length.

Further down the section, there is an example about how there’s no way in Dhall to construct an isWeekDay : Text -> Bool such that it returns True for valid weekday names and False otherwise. Again, grammars (even merely regular grammars) would trivially make this possible.

@joneshf

This comment has been minimized.

Copy link
Collaborator Author

@joneshf joneshf commented Jun 29, 2019

Sorry, I'm having a bit of trouble interpreting these responses. Do these responses mean this idea is not going to happen and we should close the issue? Are these responses providing additional information about this idea to encourage more discussion?

@philandstuff

This comment has been minimized.

Copy link
Collaborator

@philandstuff philandstuff commented Jun 29, 2019

I think a new feature which goes against a stated goal of the language probably needs a fairly strong case in favour to be added.

Some things that might help a case:

  • some concrete example use cases of things that this would enable (ideally, from real world experience)
  • a discussion of the design goal to be reversed and how any negative impact could be minimised
@Gabriel439

This comment has been minimized.

Copy link
Contributor

@Gabriel439 Gabriel439 commented Jun 29, 2019

So the main reason we try to discourage text manipulation is that we try to push validation to the edge of the system so that Dhall code deals entirely with strongly typed inputs.

The best analogy I can make is that there are two ways to write a type-safe head. Using Haskell syntax, one way is:

head :: [a] -> Maybe a

... where you propagate failures downstream. Thee other way is:

head :: NonEmpty a -> a

... where you propagate requirements upstream. Dhall strives to be like the latter idiom: imposing greater requirements on upstream by validating at import time.

The reason I bring this up is that we might be able to support text manipulation or grammars, but only at import-timee. In other words, something like:

./someImport as SomeGrammar

... where SomeGrammar is a Dhall expression that permits arbitrary text manipulation specifying how to convert ./someImport to a Dhall expression. If we had that, then we could implement support for importing JSON without requiring built-in support for those specific formats, while still not permitting normalization-time text manipulation.

I'm not exactly sure what such a grammar would look like, though.

@joneshf

This comment has been minimized.

Copy link
Collaborator Author

@joneshf joneshf commented Jul 2, 2019

Yeah, that makes sense.

As for what the grammar would look like, do you mean syntactically? It might flesh itself out if we can figure out how it might work. I assume you'd want to be able to define the structure of the text, and which parts of that structure translate into Dhall expressions. Maybe something like how bison/yacc work? Maybe it depends more on the expressive power of the grammar? I'm not really sure.

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

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.