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

Literate Agda Semantics - Syntax #1103

Closed
wants to merge 1 commit into from
Closed

Conversation

Gabriella439
Copy link
Contributor

Related to: #959

This is the first step towards an executable reference implementation by
creating an Agda project which contains the Agda type for the AST.

The Agda project is built by CI, in order to catch any errors.

Note that the long-term goal is to standardize a normalization-by-evaluation
approach for the semantics in order to make it easier for
implementers to build efficient implementations. However, in the short-term
I'm translating the semantics as literally as possible to Haskell
code and then I'll do a separate pass later on to switch to
normalization-by-evaluation.

Related to: #959

This is the first step towards an executable reference implementation by
creating an Agda project which contains the Agda type for the AST.

The Agda project is built by CI, in order to catch any errors.

Note that the long-term goal is to standardize a normalization-by-evaluation
approach for the semantics in order to make it easier for
implementers to build efficient implementations.  However, in the short-term
I'm translating the semantics as literally as possible to Haskell
code and then I'll do a separate pass later on to switch to
normalization-by-evaluation.
@Gabriella439
Copy link
Contributor Author

This is an Agda alternative to #1102 in response to #1102 (comment). I'll let people comment on whether they prefer Agda or Haskell before expressing my own preference after a few days.

@Nadrieril
Copy link
Member

I understood that part of the appeal of Agda was the possibility of using special syntax to make the Agda code resemble the Dhall expression it describes. For example defining an _&&_ operator instead of And. Do you think this would be a good idea or would you find it confusing?
I don't feel familiar enough with Agda but my limited experience of proof-oriented languages is that they can make normal programming quite cumbersome. Do you expect this to happen for Dhall? For example I imagine parsing could be tricky.

Copy link
Collaborator

@mheiber mheiber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat!

I'm curious for your thoughts on taking advantage of mixfix, and added one note about a constructor that might be missing, but this is some classy Agda.

-- let x = a in b
If : Expression → Expression → Expression → Expression
-- if t then l else r
Merge : Expression → Expression → Expression → Expression
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this may be missing a constructor here for merge without type annotation.

standard/Syntax.lagda.md Show resolved Hide resolved
standard/Syntax.lagda.md Show resolved Hide resolved
standard/Syntax.lagda.md Show resolved Hide resolved
@mheiber
Copy link
Collaborator

mheiber commented Nov 16, 2020

I don't feel familiar enough with Agda but my limited experience of proof-oriented languages is that they can make normal programming quite cumbersome. Do you expect this to happen for Dhall? For example I imagine parsing could be tricky.

Agda is (in theory at least) a PL (rather than just a prover). It's easy to turn off the termination checker for particular functions using {-# TERMINATING #-}](https://agda.readthedocs.io/en/v2.5.3/language/termination-checking.html), which eliminates the most annoying part of working with a language capable of proving things.

I'm sure there are very few libraries for actual programming compared to Haskell, though. Programming with holes is delightful, but it stinks that the screen goes black-and-white as soon as you have a syntax error. What did you have in mind with regard to parsing being tricky?

@sjakobi
Copy link
Collaborator

sjakobi commented Nov 16, 2020

How could the imports spec be implemented in Agda? Is there an Agda library that can be used to make HTTP(S) requests?

@Nadrieril
Copy link
Member

Nadrieril commented Nov 16, 2020

I'm sure there are very few libraries for actual programming compared to Haskell, though. What did you have in mind with regard to parsing being tricky?

Mostly termination checking, but I didn't know we could just disable it. But also if there's no parsing library that would be an issue. I only see agdarsec, which doesn't seem to report errors out of the box, so that could be a problem.

@mheiber
Copy link
Collaborator

mheiber commented Nov 16, 2020

How could the imports spec be implemented in Agda? Is there an Agda library that can be used to make HTTP(S) requests?

good question. GHC FFI is one option.

Here's an example from the standard library, where they wrap readFile and friends:
https://github.com/agda/agda-stdlib/blob/de33b0fae0f0500da54501980e488c67e5633c05/src/IO/Primitive.agda#L81

There's also a JS FFI which could be fun if one wants this to run in the browser.

@mheiber
Copy link
Collaborator

mheiber commented Nov 16, 2020

... also if there's no parsing library that would be an issue. I only see agdarsec, which doesn't seem to report errors out of the box, so that could be a problem.

I hunted around and didn't see anything that looked like a serious alternative to agdaparsec. But I think the intent of that blog post was that the author thinks error-reporting emerges naturally without needing a special mechanism, but I still can't say with confidence that it's an easy and pleasant time to parse with Agda.

@Nadrieril
Copy link
Member

Nadrieril commented Nov 16, 2020

If the main appeal of Agda is fancy syntax, for me this does not offset the unfamiliarity and the lack of well-supported parsing and HTTP libraries. For that matter I expect that CBOR will have to be implemented entirely manually, down to using the Haskell FFI for binary reading/writing.
EDIT: a possibility would be to use Haskell for all the IO and agda for the typechecking/normalization. But I'm still not sure it would be worth the effort.

@Gabriella439
Copy link
Contributor Author

@mheiber: The main reason I didn't use Agda's mixfix support is that the original requirement for doing this is to make it easier for implementation authors to understand the code and port it to their respective language. For example, some of these maintainers are struggling with the natural deduction notation because it's unfamiliar to them and they don't know how to translate it to ordinary functions in their respective languages.

@gallais
Copy link

gallais commented Nov 17, 2020

If the main appeal of Agda is fancy syntax

My guess is that the goal is to start enforcing some invariants as
the formalisation progresses. You can for instance statically enforce
that the scope checker produces well-scoped terms. This is what
idris2 does by indexing terms over their local contexts and it
roots out a lot of bugs related to manipulating de Bruijn indices.

For that matter I expect that CBOR will have to be implemented
entirely manually, down to using the Haskell FFI for binary
reading/writing.

The nice thing about Agda's FFI is that you can easily map Agda's
inductive types to their Haskell counterpart. So as long as the
formalisation is in sync with the Haskell code you can reuse any
function written in Haskell (including a parser, serialiser, etc.)
by postulating it on the Agda side.

The only limitation is that these postulated functions won't reduce
at compile time (but will at runtime).

@mheiber
Copy link
Collaborator

mheiber commented Nov 17, 2020

@mheiber: The main reason I didn't use Agda's mixfix support is that the original requirement for doing this is to make it easier for implementation authors to understand the code ...

Thanks for explaining @Gabriel439 , I realized too late that I made a suggestion about a solution without taking the time to read issue carefully (#959). Sorry about that!

@Gabriella439
Copy link
Contributor Author

@mheiber: No worries 🙂

@mheiber
Copy link
Collaborator

mheiber commented Nov 18, 2020

Update: proposal to go with the Haskell implementation instead, which is accumulating 👍 : #1102 (comment)

@Gabriella439
Copy link
Contributor Author

Alright, I'll close this in favor of #1102, for the reasons stated in #1102 (comment)

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

Successfully merging this pull request may close these issues.

None yet

6 participants