profile
viewpoint

dhall-lang/dhall-lang 2365

Maintainable configuration files

Nadrieril/dhall-rust 87

Maintainable configuration files, for Rust users

Ekleog/todiff 1

A differ for todo.txt files

Faerix/family-tree 0

Visualisation de l'arbre généalogique de FaëriX

Nadrieril/abnf 0

A nom-based ABNF parser.

Nadrieril/angular-puzzle15 0

A little puzzle game in AngularJS

Nadrieril/apertium-pluralize 0

Gets the singular and plural forms of a word/group of words

Nadrieril/auto-pairs 0

Vim plugin, insert or delete brackets, parens, quotes in pair

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

 The above expression first desugars to: { x = { y = a, z = b } } ``` +Additionally, the language supports *record-like* syntax for updating a record+using the `with` keyword, like this:++```dhall+record with { x.y.z = a }+```++... which desugars to:++```dhall+record // { x = record.x // { y = record.x.y // { z = a } } }+```++The right argument to the `with` keyword resembles the same syntax as a record,+but the similarity is only superficial.  For example, the following expression:++```dhall+record with { x = { y = { z = a } } }+```++... is not the same as the previous example, since it desugars to:++```dhall+record // { x = { y = { z = a } } }+```++... which is not the same thing.++In other words, expanding out the dotted label syntax is not a+behavior-preserving change because the `with` keyword gives special treatment+to the dotted labels.

I mean that semantically we want ... with { x = { y = 1 } } to replace all of the x field, but ... with { x.y = 1 } to only replace x's y field. Your conflyence problem seems for me to arise from mixing those two ideas. In fact if we did that then I think the first desugaring wouln't give

(λ(x : { b : Bool }) → { a = x }) { b = False }

but rather

(λ(x : { b : Bool }) → { a = ({ b = True, c = 1 } with x })) { b = False }

And I believe this gets us confluence back

Gabriel439

comment created time in a day

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

 The above expression first desugars to: { x = { y = a, z = b } } ``` +Additionally, the language supports *record-like* syntax for updating a record+using the `with` keyword, like this:++```dhall+record with { x.y.z = a }+```++... which desugars to:++```dhall+record // { x = record.x // { y = record.x.y // { z = a } } }+```++The right argument to the `with` keyword resembles the same syntax as a record,+but the similarity is only superficial.  For example, the following expression:++```dhall+record with { x = { y = { z = a } } }+```++... is not the same as the previous example, since it desugars to:++```dhall+record // { x = { y = { z = a } } }+```++... which is not the same thing.++In other words, expanding out the dotted label syntax is not a+behavior-preserving change because the `with` keyword gives special treatment+to the dotted labels.

There's also the fact that the dotted fields are treated differently than their desugaring. That's what I assumed the reason was

Gabriel439

comment created time in a day

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

+{-  This test protects against a likely implementation mistake which would return+    the following incorrect result:++        { a = { b = 1, d = 3 } }++    This can happen if an implementation incorrectly desugars the code to+    something that is equivalent to:++        let r = { a.b = 1 }++        in  r // { a = r.a // { b = 1 } }+              // { a = r.a // { d = 3 } }++    ... when the correct behavior is to desugar to something equivalent to:++        let r0 = { a.b = 1 }++        let r1 = r0 // { a = r0.a // { b = 1 } }++        in  r1 // { a = r1.a // { d = 3 } }

They don't have to, but they could, depending on the implementation. Or they could point to a thunk that will be lazily normalized but shared. At least there would be a possibility of sharing, whereas with the current standardization there isn't. Also the output of desugaring is currently exponential in the number of fields in the with rhs AFAIU, so using lets would at least speed up parsing and typechecking

Gabriel439

comment created time in a day

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

+{- This test ensures that `with` is purely syntactic sugar, meaning that it is+   desugared before encoding and therefore is encoded as the desugared expression+   in the CBOR encoding.+-}+{ x = 1 } with { x = 2 }

Maybe also precedence tests of with versus \\ and similar related operations ?

Gabriel439

comment created time in 2 days

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

+{- This test ensures that `with` is purely syntactic sugar, meaning that it is+   desugared before encoding and therefore is encoded as the desugared expression+   in the CBOR encoding.+-}+{ x = 1 } with { x = 2 }

Could you add parser tests for cases with multiple overrides, and the case with dotted field syntax ?

Gabriel439

comment created time in 2 days

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

 equivalent-expression    = application-expression   *(whsp equivalent whsp appli ; would be ambiguity: `./ab` could be interpreted as "import the file `./ab`",
 ; or "apply the import `./a` to label `b`"
 application-expression =
-    first-application-expression *(whsp1 import-expression)
+    first-application-expression *(whsp1 with-expression)
 
 first-application-expression =
     ; "merge e1 e2"
-      merge whsp1 import-expression whsp1 import-expression
+      merge whsp1 with-expression whsp1 with-expression
     
     ; "Some e"
-    / Some whsp1 import-expression
+    / Some whsp1 with-expression
     
     ; "toMap e"
-    / toMap whsp1 import-expression
+    / toMap whsp1 with-expression
     
-    / import-expression
+    / with-expression
+
+; Even though updates are parsed the same as a record literal, they are
+; semantically different from record literals.  Specifically, the dotted label
+; syntax is not desugared to nested records.
+with-expression =
+      import-expression *( whsp1 "with" whsp1 "{" whsp [ "," whsp ] non-empty-record-literal whsp "}" )

Since that makes with a keyword, we probably want to add it to the keywords rule too ? We may still want to allow with as a valid record label however, like we do for Some

Gabriel439

comment created time in 2 days

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

+{-  This test protects against a likely implementation mistake which would return+    the following incorrect result:++        { a = { b = 1, d = 3 } }++    This can happen if an implementation incorrectly desugars the code to+    something that is equivalent to:++        let r = { a.b = 1 }++        in  r // { a = r.a // { b = 1 } }+              // { a = r.a // { d = 3 } }++    ... when the correct behavior is to desugar to something equivalent to:++        let r0 = { a.b = 1 }++        let r1 = r0 // { a = r0.a // { b = 1 } }++        in  r1 // { a = r1.a // { d = 3 } }

Why not specify that desugaring should construct let expressions ? This would alow sharing computation and would prevent blowup after desugaring ciomplex with expressions

Gabriel439

comment created time in 2 days

Pull request review commentdhall-lang/dhall-lang

Add support for `with` keyword

 equivalent-expression    = application-expression   *(whsp equivalent whsp appli ; would be ambiguity: `./ab` could be interpreted as "import the file `./ab`",
 ; or "apply the import `./a` to label `b`"
 application-expression =
-    first-application-expression *(whsp1 import-expression)
+    first-application-expression *(whsp1 with-expression)
 
 first-application-expression =
     ; "merge e1 e2"
-      merge whsp1 import-expression whsp1 import-expression
+      merge whsp1 with-expression whsp1 with-expression
     
     ; "Some e"
-    / Some whsp1 import-expression
+    / Some whsp1 with-expression
     
     ; "toMap e"
-    / toMap whsp1 import-expression
+    / toMap whsp1 with-expression
     
-    / import-expression
+    / with-expression
+
+; Even though updates are parsed the same as a record literal, they are
+; semantically different from record literals.  Specifically, the dotted label
+; syntax is not desugared to nested records.
+with-expression =
+      import-expression *( whsp1 "with" whsp1 "{" whsp [ "," whsp ] non-empty-record-literal whsp "}" )

Is there a reason for preventing with{...} (i.e. no space after with) ? I prefer maximally optional spaces because that speeds up typing and I can just dhall format afterwards.

Gabriel439

comment created time in 2 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 5f720252a00bf2a45fef7f4c0855b79bd3932600

Move improved_slice_patterns to its own repo

view details

push time in 6 days

push eventNadrieril/improved_slice_patterns

Nadrieril

commit sha 120406af35c90880ca03556129d30a224b4e911c

Cut release

view details

push time in 6 days

push eventNadrieril/improved_slice_patterns

Nadrieril

commit sha 5ff2438c802a33117702d10d8c5c4d14c6251c63

Publish to new repo

view details

push time in 6 days

create barnchNadrieril/improved_slice_patterns

branch : master

created branch time in 6 days

created repositoryNadrieril/improved_slice_patterns

Match on `Vec`s and iterators using the syntax of slice_patterns, taking ownership

created time in 6 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha dcaf7c2d525a3d9105170f5b7cd960bc4fe49e68

Forgot to commit Cargo.lock

view details

push time in 6 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 42862723e6a34a4808fe6a8540a34eb7542e9ee4

Cut release

view details

push time in 6 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha c09a2e3beb67aff520fd1d94f8d5069c1b7dfbf1

Oops

view details

push time in 6 days

delete branch Nadrieril/dhall-rust

delete branch : catchup-spec

delete time in 7 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha ce4665bdfcbcb4e34e760acef83bd4de3fbef530

Update spec to version 13

view details

Nadrieril

commit sha 26ed5a1d4d43573ac8ad2f8de9e4dd411650aa9a

Expose fewer pub things

view details

Nadrieril

commit sha 86508a3ad59a0bfc1e24448d0a0126b1a1c645e1

Add support for duplicate record fields

view details

Nadrieril

commit sha 0e07c9cd012efaeae7e1c50a3499a13aef4d2b61

Disallow Natural literals with leading zeros

view details

Nadrieril

commit sha 6642077368497583113d685d351ec93d230ffcad

Add support for dotted field syntax

view details

Nadrieril

commit sha f24879c16d82d2ecb2294596ffa45573f02185d0

Support spec v14

view details

Nadrieril

commit sha e5f0602e431bc602f9e1f0045f48056ce6465481

Update dhall-lang submodule

view details

Nadrieril Feneanar

commit sha 92b5604c1049a771239a70ab14c393e8e1807c68

Merge pull request #132 from Nadrieril/catchup-spec Catchup spec

view details

push time in 7 days

PR merged Nadrieril/dhall-rust

Catchup spec

Catchup to latest version of the dhall spec

+111 -89

0 comment

17 changed files

Nadrieril

pr closed time in 7 days

push eventNadrieril/dhall-lang

Nadrieril Feneanar

commit sha e2d08ebf5fb5770b57d0681131bed4289d0bb623

Some small grammar fixes (#871) * `Some` is a keyword and must be escaped * Fix order of branches in grammar for PEG parsers * `missing//foo` parses as an identifier * Allow `Some` in records and unions * Tweak variable name to respect spec

view details

Simon Jakobi

commit sha 8b9653b7319ccd0983933240927c78eafe2daff4

Prelude: Add Function.identity (#865) … as discussed with @SiriusStarr in #862.

view details

Nadrieril Feneanar

commit sha 032039316c2fb438aff3951f959f1d2f2df170d4

`dhall-rust` is now a complete language binding 🎉 (#868) * Mark dhall-rust as complete * Add dhall-rust to the list of actively maintained language bindings

view details

Ari Becker

commit sha 294da0fdadc3882c73b57f4aa0ed96f1e3ba378d

Add Natural, Integer types to the JSON package (#873) * Add Natural, Integer types to the JSON package ------ Fixes [#872](https://github.com/dhall-lang/dhall-lang/issues/872) * Fixes ------ * Change to use Integer/nonNegative in renderInteger, as per @sjakobi's suggestion * Remove Natural from JSON type * Make it clear that JSON.number is an alias for JSON.double Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com> Co-authored-by: Simon Jakobi <simon.jakobi@gmail.com>

view details

Gabriel Gonzalez

commit sha 868e99ac1b09d689a759da7a5fd747aec12a1b9c

Clarify process for merging changes after edits (#876) Motivated by this discussion: https://github.com/dhall-lang/dhall-lang/pull/875#issuecomment-570818061 We've had a few cases recently where new contributors are unsure what the process is if they make changes in response to review. In particular, they aren't sure if the clock resets after any changes or if new changes need to be re-approved. This proposed that the 3-day/7-day waiting periods are relative to the original submission, and any edits after that only warrant a 24 hour waiting period for subsequent edits (and changes don't require re-approval).

view details

Gabriel Gonzalez

commit sha 48db9e1ff1f8881fa4310085834fbc19e313ebf0

Version 12.0.0 → 13.0.0 (#875)

view details

Adrian Sieber

commit sha a72d3ad2c6c636de580c901452c3187e9da04420

Fix link to prelude (#882) Otherwise the link doesn't work on the docs.dhall-lang.org website

view details

Jochen Schneider

commit sha 8068fb78d6d1b439e5850f6d96ca8f323393b361

Mention comments in cheatsheet (#883)

view details

Gabriel Gonzalez

commit sha 94e449740a53ec9fbf13b1a630c84d49324dfdcf

Update `dhall-haskell` to 1.29.0 (#885)

view details

Gabriel Gonzalez

commit sha 543d91e27d67f583b095cbb02babae3f2a944789

Add myself as a user with root privileges on `dhall-lang.org` (#886) This is the first step in making it easier for other people to manage this machine. The full set of steps I plan after this are: * Switch from using NixOps to using NixOS * Install a service to automatically have `dhall-lang.org` track `master` If you would like to also maintain this machine you can create a pull request like this one to add yourself as an administrative user.

view details

Gabriel Gonzalez

commit sha fda6d22ac4e4977bef6a7559fea22a01d75118c3

Configure dhall-lang.org to automatically track `master` (#887) This changes dhall-lang.org to no longer be managed via NixOps. Instead, it will automatically install the system built by the `machine` attribute built from the `master` branch every hour.

view details

Simon Jakobi

commit sha 004eaedf6c762d0960f0aacf37d17da7c7a0177e

docs: Add migration plan for Optional/fold and Optional/build deprecations (#880)

view details

Gabriel Gonzalez

commit sha b20476014e508be2218adbafa656996d0fd217bc

Fix typo in title of "Safety guarantees" page (#889)

view details

Gabriel Gonzalez

commit sha 8cf71d94bd63710faae018aac0920b937b977b11

Relocate dhall-lang.org website to this repository (#892) This moves the code for the dhall-lang.org website from the `dhall-haskell` repository to this repository, for two main reasons: * To make it easier for new contributors to discover and contribute to the website * So that changes to dhall-lang.org are automatically deployed after they are merged into `master`

view details

Gabriel Gonzalez

commit sha ba21fa005a5f1e25ed875bc65e7452692e67b887

Update `dhall-json` tutorial (#895) ... to reflect changes in `dhall-json` behavior since the last tutorial Fixes https://github.com/dhall-lang/dhall-lang/issues/894

view details

Tristan de Cacqueray

commit sha c993f6a36092f6391bf808b27e75a876d23c2225

Add auto section labels to docs for cross reference (#888) This change enables the autosection label sphinx extension to simplifies cross reference. This change also fix incorrect gfm links.

view details

Gabriel Gonzalez

commit sha 3301f2e2a408d9e3953185c51c1a07c668db47b7

Add support for duplicate record fields (#896) The motivation for this change is enable a subsequent change to the language to add support for Nix/Cue/TOML-like short-hand syntax for records. Specifically, we'd like to be able to write records using this "short-hand syntax": ```dhall { a.b = 1, a.c = True, b = "Hi!" } ``` ... and have that desugar to: ```dhall { a = { b = 1, c = True }, b = "Hi!" } ``` I'm standardizing support for duplicate record fields in a separate step for two reasons: * For ease of implementation It's easier to implement, standardize, and to reason about the behavior of the "short-hand syntax" by decoupling it into two orthogonal changes to the language (of which this is the first change) * To ensure the upcoming short-hand syntax behaves correctly in corner cases I'll illustrate what I mean by the latter point. As I mentioned above, all three of Nix, Cue, and TOML support a short-hand syntax: ```nix { a.b = 1; a.c = true; b = "Hi!"; } ``` ```toml a.b = 1 a.c = true b = "Hi!" ``` ```cue // Cue a: b: 1 a: c: true b: "Hi!" ``` However, TOML and Nix both fail on the following case: ```nix { a.b = 1 a = { c = 1 } } ``` ```toml a.b = 1 [a] c = 1 ``` ... which (as a NixOS user) this restriction has both surprised me and bitten me on numerous occasions when trying to set NixOS configuration options. Not only this Nix/TOML behavior a poor user experience, but it also creates theoretical issues, because you can no longer safely rewrite this: ```dhall { a.b = x, … } ``` ... to this: ```dhall { a = { b = x }, … } ``` ... because the `…` could be `a.c = 1`. In fact, it's actually harder to implementing things the wrong way! Simplifying the implementation also fixes every corner case. Cue, on the other hand, does not have the above problem, because Cue does exactly what this change proposes. When Cue encounters a duplicate field, the interpreter recursively merges them and throws an error if there are any field conflicts (just like Dhall's `∧` operator). See the tests for additional examples and comments on how this should behave in various cases.

view details

Tristan de Cacqueray

commit sha 953c36039fb4f5867ec4ebb12fbcc388ce6569a1

Add map folding tutorial (#824) This change adds a tutorial to implement map and fold to generate list of text.

view details

Christopher Johnstone

commit sha c9accedbee5dde2e6cb2a5d0d5d41289482d0425

Documentation: Updated the dhall-yaml integration hyperlink (#900) Updates the hyperlink URL for dhall-yaml to actually point at dhall-yaml instead of dhall-json.

view details

Philip Potter

commit sha a1f2dc019907ec001f28abbd05ca397bddb0975d

Disallow Natural literals with leading zeros (#898) Currently, we allow parsing literals like `042` as decimal Natural literals. This is uncommon (dhall format will remove leading zeros). It also makes things marginally more tricky for implementations, because standard libraries often provide functions for parsing C-style numeric literals, which will handle a leading `0x` correctly, but will assume that a leading 0 marks an octal literal, so `042` actually means the same as `34`. For an example function like this, see Go's [strconv.ParseInt][]. This commit updates the ABNF to require Natural literals to have a leading nonzero digit, except for 0 itself. It also removes the one instance of a leading 0 literal in the tests. I didn't change hexadecimal literals: 0x00ff is still allowed. I think this is fine. [strconv.ParseInt]: https://golang.org/pkg/strconv/#ParseInt

view details

push time in 7 days

PR opened Nadrieril/dhall-rust

Catchup spec

Catchup to latest version of the dhall spec

+111 -89

0 comment

17 changed files

pr created time in 7 days

create barnchNadrieril/dhall-rust

branch : catchup-spec

created branch time in 7 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha db1375eccd1e6943b504cd54ed17eb8f4d19c25f

Remove most reliance on types stored in Value

view details

Nadrieril

commit sha 5870a46d5ab5810901198f03ed461d5c3bb5aa8a

Remove move type propagation through Value

view details

Nadrieril

commit sha 27031b3739ff9f2043e64130a4c5699d0f9233e8

Add Hir as untyped alternative to TyExpr

view details

Nadrieril

commit sha 6c90d356c9a4a5bbeb88f25ad0ab499ba1503eae

Remove most TyExpr from normalization

view details

Nadrieril

commit sha 5688ed654eee258bf8ffc8761ce693c73a0242d5

Remove extra types stored in Value

view details

Nadrieril

commit sha bbcb0c497dcf922d19bd529ceb936aff9d71a732

Introduce environment for import resolution

view details

Nadrieril

commit sha 5c342a5688fe7a4bb337ce0622968226d524022e

Resolve by ref instead of by mut

view details

Nadrieril

commit sha a709c65eb28f1b6a666f15bfc2255da7bc7105ab

Resolve variables alongside import resolution

view details

Nadrieril

commit sha 21db63d3e614554f258526182c7ed89a2c244b65

Take Hir for typecheck

view details

Nadrieril

commit sha ad085a20bc257d03a52708d920cfc65f0e9051e6

Remove all types from Value

view details

Nadrieril

commit sha f6732982c522dd579d378ab4820001d5ae107c43

Automate conversion between envs

view details

Nadrieril

commit sha 35cc98dc767247f4881866de40c7d8dd82eba8a5

Remove types from NzEnv

view details

Nadrieril

commit sha c3ed75dc4b354becac0821e4288105dc2a300c4c

Remove need for Embed This was an archaic leftover from copying the Haskell datatypes anyway

view details

Nadrieril

commit sha 5a2538d174fd36a8ed7f4fa344b9583fc48bd977

Remove the Embed variant from ExprKind

view details

Nadrieril

commit sha cab75190e86e8fd4ccc209499c0e7f300a669022

Simplify ExprKind visitor

view details

Nadrieril

commit sha 40bee3cdcb9ac0c76996feeceb6ca160a6bd8b42

Introduce LitKind to factor out common enum nodes

view details

Nadrieril

commit sha 7b649b8647c60f1c02050805520f307edff0a94f

Only store type at root node in tyexpr

view details

Nadrieril

commit sha f29a40fb55b898b3a3cc51f198e8522eaecf0777

Simplify conversions to/from TyExpr

view details

Nadrieril

commit sha e25b67906ce68e8726e8139c1d1855f3ab2518ce

Rework annotation and Sort handling

view details

Nadrieril

commit sha 350d1cf7d9c114b1334b2743071b0b99ea64c1ec

TyExpr always carries a type

view details

push time in 8 days

delete branch Nadrieril/dhall-rust

delete branch : hir

delete time in 8 days

PR merged Nadrieril/dhall-rust

Decouple main expression types

Yet another massive refactor. This time, I decoupled typechecking from normalization: Value does not need to laboriously keep track of types anymore. Now we can normalize without typechecking if we want, though I don't know if that's a desirable property. I also renamed intermediate expression types; now we have Expr, Hir, Tir (for typecheck) and Nir (for normalization). This not only simplifies quite a few things, it also again makes the code easier to follow and amend. Name resolution is now done as part of the resolve phase, that previously only did import resolution. I should document all that at some point, but I'm having too much fun refactoring for now.

+2237 -2480

0 comment

57 changed files

Nadrieril

pr closed time in 8 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 7cbfc1a0d32766a383d1f48902502adaa2234d2f

Avoid re-typechecking after import

view details

push time in 8 days

PR opened Nadrieril/dhall-rust

Decouple main expression types

Yet another massive refactor. This time, I decoupled typechecking from normalization: Value does not need to laboriously keep track of types anymore. Now we can normalize without typechecking if we want, though I don't know if that's a desirable property. I also renamed intermediate expression types; now we have Expr, Hir, Tir (for typecheck) and Nir (for normalization). This not only simplifies quite a few things, it also again makes the code easier to follow and amend. Name resolution is now done as part of the resolve phase, that previously only did import resolution. I should document all that at some point, but I'm having too much fun refactoring for now.

+2238 -2480

0 comment

57 changed files

pr created time in 8 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 8264df65c21b5ad508c5faf96c4a1f9d732449cc

Move hir and resolve into a module

view details

Nadrieril

commit sha 8da4445e6d06cf79d43112042b69c798f86884f3

Extract resolve-relevant envs together

view details

Nadrieril

commit sha 06714f925a6588ef5c262bb7a9cf3f9e40f13120

Factor out desugaring from resolve

view details

Nadrieril

commit sha 73571249f9bcf8efe84708a4a9f8665af62e44f0

Remove some unused code

view details

Nadrieril

commit sha 2f65c02a995f6b6d4c755197fc074782f6bb100d

Rename TyExpr to Tir

view details

Nadrieril

commit sha cd5e172002ce724be7bdd52883e121efa8817f20

Rename Value to Nir

view details

Nadrieril

commit sha da69fe3eef7e001a1a0bdd2a2f3ebefccc3426e3

Remove spans from Nir That info was too unreliable: we need clean tracking mechanisms if we want to improve error messages

view details

Nadrieril

commit sha ebe43bd6f1fd6feb1564ab9837399de7808b67b5

Borrow relevant Hir from Tir

view details

Nadrieril

commit sha 50a9dc4b9af19a35a983fe17108453d1d82d80ed

Remove useless `normalize` option from ToExprOptions

view details

Nadrieril

commit sha a3990858840a737d7831be45953b38bd67361fb7

Discard import headers while we don't use them

view details

Nadrieril

commit sha e91dc5ca8d66a79223b7ad100ef060f493e5beee

Avoid re-typechecking after import

view details

push time in 8 days

issue commentrust-lang/annotate-snippets-rs

Understanding SourceAnnotation.range

Ah yeah, .lines() doesn't distinguish \r\n and \n endings, which is good, but .chars() does, which messes up character counts. I'm afraid there might be no way of using .lines() there. Specifically, this line https://github.com/rust-lang/annotate-snippets-rs/blob/7e73a1bdaa75986dafb33454bd1207fd84e576e9/src/display_list/from_snippet.rs#L186 assumes that a line ending is one char, and this length is later added to current_index (with an additional increment, I don't know why) there https://github.com/rust-lang/annotate-snippets-rs/blob/7e73a1bdaa75986dafb33454bd1207fd84e576e9/src/display_list/from_snippet.rs#L198 Together, those lines effectively count each end of line as two chars, as I had observed

lpil

comment created time in 8 days

pull request commentdhall-lang/dhall-lang

Fix keyword ordering for simple-label rule

Well-spotted ! Could you add a parser test that checks this ?

garetht

comment created time in 10 days

issue commentnvzqz/static-assertions-rs

More Assertions

Here is a sad version of what you ask:

macro_rules! void {
    ($ty:ty: $tr:path) => {{
        struct True;
        struct False;
        trait DoesImpl<M> {
            fn marker() {}
        }
        impl<T: ?Sized> DoesImpl<False> for T {}
        impl<T: ?Sized + $tr> DoesImpl<True> for T {}

        const _: () = {
            // Fails if `$ty: $tr` is in scope globally, because then it can't infer `M`
            let _ = <$ty as DoesImpl<_>>::marker;
        };
        // Fails if `$ty: $tr` is not in scope locally
        let _ = <$ty as DoesImpl<True>>::marker;

        unreachable!()
    }};
}

It will only typecheck in the case where the type does not implement the trait, but the bound $ty: $tr is in scope anyways. I find this solution disappointing however: I'd love to be able to exploit the contradiction str: Sized + !Sized to construct a term of type !...

nvzqz

comment created time in 10 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 51cf6a28fa56031dbeae0ff378f0ef84eff7fd3e

Oops

view details

Nadrieril

commit sha d65d639ff93691adbf0a208edb99736003bc64bd

Factor some tck code to avoid needing get_type_tyexpr

view details

Nadrieril

commit sha 5057144ed99bc4e1a76a0840dd39fc1bd862665c

Desugar Completion during resolution

view details

Nadrieril

commit sha aa867b21f57f9bef2ec2b9d8450736f9111189ee

Introduce proper Type struct

view details

Nadrieril

commit sha 130de8cea49c848a06174c61c747d9414a5c71b7

Start requiring Universe to build a Type

view details

Nadrieril

commit sha 80722b6da21a79cc2f00b2944244b28a04c5e169

Oops, leftover #![allow(dead_code)]

view details

Nadrieril

commit sha c451c18103b871e563b12c524bc3feec5451154c

Avoid recomputing universes in tck

view details

push time in 11 days

issue commentdhall-lang/dhall-lang

Simplifications to aid Integer arithmetic

@Gabriel439 I meant that <Neg=1> would represent the number -2, so it would be a real bijection. Then there would be a usability problem because that's kind of a confusing behavior if you're not a logician I guess.

There's definitely more noise to standardize this version, but it feel cleaner to me because it captures the structure of what we want. We'd have e.g.

Integer/unpack (Integer/negate x) === merge { Neg=UnpackedInt.Pos, Zero=UnpackedInt.Zero, Pos=UnpackedInt.Neg } (Integer/unpack x)

Integer/unpack (Natural/toInteger x) === merge { Zero=UnpackedInt.Zero, Pos=UnpackedInt.Pos } (Natural/unpack x)

Hmm, I'm realizing that for the negate+toInteger to simplify we'd need some kind of merging of successive merges too. It would be trickier to ensure confluence I guess, and blow up code size. My intuition was that this specific interaction between Integer/unpack and Natural/toInteger would be enough to capture all the simplifications we might think of, whereas the interaction between Integer/clamp and Natural/toInteger above would clearly need a special case for when there's a negate in between, and more generally I'd expect more special cases if we added more integer-related builtins. I think I'm definitely making the mistake to believe there's a set of rules we can choose that would give us maximal simplifications. But of course optimizing code is full of heuristics and tradeoffs...

sjakobi

comment created time in 12 days

pull request commentdhall-lang/dhall-lang

Don't parse single-quote strings too greedily

Ah wait no of course single-quote-char can parse a single quote. So yeah, you're analysis and proposed solution seems right to me

philandstuff

comment created time in 12 days

pull request commentdhall-lang/dhall-lang

Don't parse single-quote strings too greedily

Hmm, I also use a PEG parser, I'll need to try this test. I thought that single-quote-char made sure it couldn't parse single quotes ? I'll have to check that when I'm not on my phone

philandstuff

comment created time in 12 days

pull request commentdhall-lang/dhall-lang

Don't parse single-quote strings too greedily

Hmm, I also use a PEG parser, I'll need to try this test. I thought that single-quote-char made sure it couldn't parse single quotes ? I'll have to check that when I'm not on my phone

philandstuff

comment created time in 12 days

Pull request review commentdhall-lang/dhall-lang

Documentation: Cheatsheet improvements

 *   Unions      ```dhall-    < Foo | Bar : Natural >.Foo, < Foo | Bar : Natural >.Bar 1 : < Foo | Bar : Natural >+    let FooBar = < Foo | Bar : Natural > -    merge { Foo = False, Bar = Natural/even } < Foo | Bar : Natural >.Bar 2 = True+    let isEven = \(foobar: FooBar) -> +        merge {+            Foo = False,+            Bar = Natural/even+        } foobar++    in [isEven FooBar.Foo, isEven (FooBar.Bar 3), isEven (FooBar.Bar 4)]

We have === in Dhall that probably expresses what we'd want. We can't run it as such in the repl though, it needs to be preceded by assert :, like as follows:

let _ = assert : (True || False === True)
in foo
note

comment created time in 13 days

issue commentdhall-lang/dhall-lang

Simplifications to aid Integer arithmetic

If we had a more natural function than Integer/clamp, like for example Integer/unpack : Integer -> <Neg: Natural | Zero | Pos: Natural>, then the first simplification could entail the second. In fact I take that as a further nudge that we should prefer more powerful builtins at the expense of usability, and let Preludes take care of supplying more usable wrappers.

sjakobi

comment created time in 13 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 7b649b8647c60f1c02050805520f307edff0a94f

Only store type at root node in tyexpr

view details

Nadrieril

commit sha f29a40fb55b898b3a3cc51f198e8522eaecf0777

Simplify conversions to/from TyExpr

view details

Nadrieril

commit sha e25b67906ce68e8726e8139c1d1855f3ab2518ce

Rework annotation and Sort handling

view details

Nadrieril

commit sha 350d1cf7d9c114b1334b2743071b0b99ea64c1ec

TyExpr always carries a type

view details

push time in 14 days

push eventNadrieril/keyboard-layout

Nadrieril

commit sha fb5cb1c964972216dda285f7f35efa14ae31f151

Add keylog report

view details

Nadrieril

commit sha 47eb097727fbf5777b2173c527fcc8e852488087

Cleanup keylog

view details

Nadrieril

commit sha 8390480ca7d46f1bbd3a69d9c1c03f74fca6ca3c

Experiment with symbols

view details

Nadrieril

commit sha 4e5021c8ac8b2ff184e570284c681476f89e2f08

Cleanup keylog more

view details

Nadrieril

commit sha a79c52b09391ec3b55f97ee1f427a261a1076e10

Dedup keylog

view details

Nadrieril

commit sha 8eda4210eeff62ae71f42f154832c6fbb623a7c4

More layout experiments

view details

push time in 14 days

create barnchNadrieril/dhall-rust

branch : hir

created branch time in 16 days

pull request commentNixOS/nixpkgs

syncserver: remove pkgs/module/dependencies

No, as much as I would like to, I don't have the bandwith to maintain a couple of outdated python libraries and all of their dependencies

Mic92

comment created time in 16 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha e4b3a879907b6dcc75d25847ae21a23d0201aae1

Upgrade Rust toolchain

view details

push time in 18 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha ca93f39201f6f8be9bc1466eed7323d0426e135c

Track output of import errors

view details

Nadrieril

commit sha 81504a7ee24f22820c6bc85823c879d488710d11

Massively deduplicate test harness

view details

Nadrieril

commit sha 8abb6c24cd26b64d708a74faaa28cc9294dc3466

Move ui outputs to a sensible place

view details

Nadrieril

commit sha 5d0f37d89f23512c2676b1f2d0235f25269c53ab

Add option to overwrite test files

view details

Nadrieril

commit sha 02cacfd0360a0acea959c5a9b6d1b7fb0241db81

Remove distinction between failure and error tests

view details

Nadrieril

commit sha 4c2a28b844b18d7b67278a1c8f628d9a95ea37c4

Track error output of parsing and binary decoding tests

view details

Nadrieril Feneanar

commit sha 75889ac64e2d04dfd7c00fc59e29e4530e69cc9a

Merge pull request #130 from Nadrieril/improve-tests Improve the test harness

view details

push time in 18 days

delete branch Nadrieril/dhall-rust

delete branch : improve-tests

delete time in 18 days

PR merged Nadrieril/dhall-rust

Improve the test harness

This removes a lot of duplication from the test harness, and adds output tracking to all types of failure tests, so that we can track work on error messages (which currently suck)

+633 -184

0 comment

173 changed files

Nadrieril

pr closed time in 18 days

PR opened Nadrieril/dhall-rust

Improve the test harness

This removes a lot of duplication from the test harness, and adds output tracking to all types of failure tests, so that we can track work on error messages (which currently suck)

+633 -184

0 comment

173 changed files

pr created time in 18 days

create barnchNadrieril/dhall-rust

branch : improve-tests

created branch time in 18 days

issue commentdhall-lang/dhall-lang

can’t partially-apply built-in merge function

Given the previous discussion, in particular this point:

For point 1, the type of merge { A = λ(x : Bool) → if x then 1 else 0 } can be either

* `< A > → Bool → Natural` or

* `< A : Bool > → Natural`.
  and this generalizes to an arbitrary number of fields in the record, so long as they all have the same type.

is this issue still possible or may we close it ?

sellout

comment created time in 18 days

issue commentdhall-lang/dhall-lang

Proposal: return to standard RFC 3986 URLs

Do we have a roadmap for the removal of old URLs from the standard ?

philandstuff

comment created time in 18 days

pull request commentNixOS/nixpkgs

syncserver: remove pkgs/module/dependencies

Ah well, that sad :( ut if it's broken and upstream is not working on Python3, then I guess we have no choice

Mic92

comment created time in 19 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 5abc0628058a318782c46614d943c034711845c6

Add forgotten test outputs

view details

push time in 21 days

delete branch Nadrieril/dhall-rust

delete branch : missing-features

delete time in 21 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 5e50ad90b01ef5f589515280668187b722bfcb5f

Implement typechecking of toMap

view details

Nadrieril

commit sha 7ff5974052e3e18109acbe6e4f0588698d6129ba

Typecheck projection by type

view details

Nadrieril

commit sha de7664d9dda95dd16742bc30e16a967c43d687ee

Typecheck record completion

view details

Nadrieril

commit sha 853807b68a8ec8928a4d497fc7ce2b3676036eed

Normalize toMap

view details

Nadrieril

commit sha c27d8ff15988b914d21135dadffe9871441c127f

Implement some record simplifications

view details

Nadrieril Feneanar

commit sha ce289aeb3db3085a327e3a509f69edcea0f86be0

Merge pull request #129 from Nadrieril/missing-features Implement some missing features

view details

push time in 21 days

PR merged Nadrieril/dhall-rust

Implement some missing features

Closes #96; did a bit of #123 and #94 too

+361 -106

0 comment

14 changed files

Nadrieril

pr closed time in 21 days

issue closedNadrieril/dhall-rust

`toMap` keyword

This is a totally unimplemented feature. Steps required:

  • [x] Add a new ToMap node to ExprF to represent the new syntax
  • [x] Update the parser to handle the new syntax
  • [ ] Implement typechecking, and enable the relevant tests
  • [ ] Implement normalization, and enable the relevant tests

closed time in 21 days

Nadrieril

PR opened Nadrieril/dhall-rust

Implement some missing features

Closes #96; did a bit of #123 and #94 too

+361 -106

0 comment

14 changed files

pr created time in 21 days

issue commentNadrieril/dhall-rust

Tracking issue for great type error messages

Most of the groundwork is done, now there's mostly a need of writing nice error messages.

Nadrieril

comment created time in 21 days

create barnchNadrieril/dhall-rust

branch : missing-features

created branch time in 21 days

delete branch Nadrieril/dhall-rust

delete branch : nice-errors-everywhere

delete time in 23 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha bde4104d061ab87d4af85a083c549ae174797710

Add basic pretty type errors to all errors

view details

Nadrieril

commit sha f3bdd5ab32e112483da4c81d64ec14a116bf06cf

Workaround panic in a serde_dhall example Unsure what's causing it, most probably mixing of spans from different inputs

view details

Nadrieril Feneanar

commit sha eb9129312edf574948df777acb340189dc147724

Merge pull request #128 from Nadrieril/nice-errors-everywhere Add basic pretty type errors to all errors

view details

push time in 23 days

PR merged Nadrieril/dhall-rust

Add basic pretty type errors to all errors

At least now type errors all point to a location in the source file. More work is needed to make them user-friendly though.

+484 -183

0 comment

85 changed files

Nadrieril

pr closed time in 23 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha f3bdd5ab32e112483da4c81d64ec14a116bf06cf

Workaround panic in a serde_dhall example Unsure what's causing it, most probably mixing of spans from different inputs

view details

push time in 23 days

PR opened Nadrieril/dhall-rust

Add basic pretty type errors to all errors

At least now type errors all point to a location in the source file. More work is needed to make them user-friendly though.

+482 -183

0 comment

85 changed files

pr created time in 23 days

create barnchNadrieril/dhall-rust

branch : nice-errors-everywhere

created branch time in 23 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 488bce275f104384282a0867aeaad011ae8cf48c

Add local test files on top of dhall-lang tests

view details

push time in 25 days

delete branch Nadrieril/dhall-rust

delete branch : nicer-type-errors

delete time in 25 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha 70eede4fd012f49dfab0e2e27fb3a4e4bbff6325

Implement once nice error using annotate_snippets

view details

Nadrieril

commit sha 92bbea48f9a0380a614f2687c73d55a67ff9294e

More nice errors plus some refactor

view details

Nadrieril

commit sha d8c3ced0f1acb1924c801fadbfd3077dede9b0dd

More errors

view details

Nadrieril

commit sha 47167b874179bd6e659f0a596defcfe854369618

Let rustfmt format string literals

view details

Nadrieril

commit sha 4f98c23963e82eaf08c9d7291d0988d13571d337

Fix spans for unions and records

view details

Nadrieril

commit sha b6625eccbf3f2d1bcfe1a88f4d556439281e91de

Use Spans consistently by value

view details

Nadrieril

commit sha f3681f7a32ddb78db4d564769b50b697c54ebeac

Tweak errors

view details

Nadrieril Feneanar

commit sha b7b5a0d27eb0cccdcd0c532a7042b3514eacbe40

Merge pull request #127 from Nadrieril/nicer-type-errors Enable multiple locations for type errors

view details

push time in 25 days

PR merged Nadrieril/dhall-rust

Enable multiple locations for type errors

Closes #116. The infrastructure is there, now we "just" need to write the messages ><

+539 -144

0 comment

27 changed files

Nadrieril

pr closed time in 25 days

issue closedNadrieril/dhall-rust

Enable multiple locations for type errors

RIght now, errors look like this:

 --> 1:6
  |
1 | [] : List Type␊
  |      ^--^
  |
  = Type error: Wrong type of function argument
 --> 1:11
  |
1 | [] : List Type␊
  |           ^--^
  |
  = This argument has type Kind
[unknown location] But the function expected an argument of type Type

This is reasonably pretty, and uses internally the pest Error type for pretty-printing.

However this is limited to highlighting only one location at a time. For errors like the example above, it would be better to be able to highlight several locations at a time. Ideally, we'd get:

 --> 1:6
  |
1 | [] : List Type␊
  |      ^^^^ ____
  |      |    |
  |      |    this argument has type `Kind`
  |      |
  |      this function expects an argument of type `Type`
  |
  = Type error: Wrong type of function argument

More realistically, something like:

 --> 1:6
  |
1 | [] : List Type␊
  |      ^^^^ this function expects an argument of type `Type`
  |
1 | [] : List Type␊
  |           ^^^^ this argument has type `Kind`
  |
  = Type error: Wrong type of function argument

would be quite good.

closed time in 25 days

Nadrieril

PR opened Nadrieril/dhall-rust

Enable multiple locations for type errors

Closes #116. The infrastructure is there, now we "just" need to write the messages ><

+539 -144

0 comment

27 changed files

pr created time in 25 days

push eventNadrieril/dhall-rust

Nadrieril

commit sha d8c3ced0f1acb1924c801fadbfd3077dede9b0dd

More errors

view details

Nadrieril

commit sha 47167b874179bd6e659f0a596defcfe854369618

Let rustfmt format string literals

view details

Nadrieril

commit sha 4f98c23963e82eaf08c9d7291d0988d13571d337

Fix spans for unions and records

view details

Nadrieril

commit sha b6625eccbf3f2d1bcfe1a88f4d556439281e91de

Use Spans consistently by value

view details

Nadrieril

commit sha f3681f7a32ddb78db4d564769b50b697c54ebeac

Tweak errors

view details

push time in 25 days

create barnchNadrieril/dhall-rust

branch : nicer-type-errors

created branch time in 25 days

delete branch dhall-lang/dhall-lang

delete branch : Nadrieril-patch-1

delete time in 25 days

push eventdhall-lang/dhall-lang

Nadrieril Feneanar

commit sha cff5f97aa968d6e7e8ef28628399c2fa9bed338f

Fix typing rule for merging `Optional`s (#899) * Fix typing rule for merging `Optional`s The current rule for typechecking merge on `Optional`s normalizes the argument in order to know if it's a `None` or a `Some`, and uses that to typecheck the resulting `merge` expression. Not only is that unnecessary work, I think it's actually wrong. The correct behavior is not to construct a value of type `< None | Some : A >` manually, but to assume one is present in the context. For example, I believe the current rule fails to typecheck the following: ```dhall λ(x : Optional Bool) → merge { None = 0, Some = λ(_ : Bool) → 1 } x ``` because it will try and fail to normalize `x` to either `None` or `Some`. * Add regression test

view details

push time in 25 days

PR merged dhall-lang/dhall-lang

Fix typing rule for merging `Optional`s

The current rule for typechecking merge on Optionals is the following:

Γ ⊢ o : Optional A
o ⇥ None A
Γ ⊢ merge t < None | Some : A >.None : T
────────────────────────────────────────
Γ ⊢ merge t o : T


Γ ⊢ o : Optional A
o ⇥ Some a
Γ ⊢ merge t (< None | Some : A >.Some a) : T
────────────────────────────────────────────
Γ ⊢ merge t o : T

It normalizes the argument in order to know if it's a None or a Some, and uses that to typecheck the resulting merge expression. Not only is that unnecessary work, it's actually incorrect. For example, the current rule fails to typecheck the following:

λ(x : Optional Bool) → merge { None = 0, Some = λ(_ : Bool) → 1 } x

because it will try and fail to normalize x to either None or Some.

The correct behavior is not to construct a value of type < None | Some : A > manually, but to assume one is present in the context. This PR implements this idea.

+7 -12

0 comment

3 changed files

Nadrieril

pr closed time in 25 days

push eventdhall-lang/dhall-lang

Tristan de Cacqueray

commit sha 953c36039fb4f5867ec4ebb12fbcc388ce6569a1

Add map folding tutorial (#824) This change adds a tutorial to implement map and fold to generate list of text.

view details

Christopher Johnstone

commit sha c9accedbee5dde2e6cb2a5d0d5d41289482d0425

Documentation: Updated the dhall-yaml integration hyperlink (#900) Updates the hyperlink URL for dhall-yaml to actually point at dhall-yaml instead of dhall-json.

view details

Philip Potter

commit sha a1f2dc019907ec001f28abbd05ca397bddb0975d

Disallow Natural literals with leading zeros (#898) Currently, we allow parsing literals like `042` as decimal Natural literals. This is uncommon (dhall format will remove leading zeros). It also makes things marginally more tricky for implementations, because standard libraries often provide functions for parsing C-style numeric literals, which will handle a leading `0x` correctly, but will assume that a leading 0 marks an octal literal, so `042` actually means the same as `34`. For an example function like this, see Go's [strconv.ParseInt][]. This commit updates the ABNF to require Natural literals to have a leading nonzero digit, except for 0 itself. It also removes the one instance of a leading 0 literal in the tests. I didn't change hexadecimal literals: 0x00ff is still allowed. I think this is fine. [strconv.ParseInt]: https://golang.org/pkg/strconv/#ParseInt

view details

Nadrieril Feneanar

commit sha 6db9078d4be96c316351674e690235a7bcbae1db

Merge branch 'master' into Nadrieril-patch-1

view details

push time in 25 days

pull request commentdhall-lang/dhall-lang

Restyle `docs.dhall-lang.org`

We can't see our beautiful logo anymore :(

Gabriel439

comment created time in a month

issue commentrust-lang/annotate-snippets-rs

Understanding SourceAnnotation.range

Experiment confirms that indexing is indeed by char and not by byte index. Furthermore somehow \n is counted as two chars on its own, but counts as one char as part of \r\n (so that line endings always count as two chars). This is the function I use to convert from byte idxs to a char index, that works with both \n and \r\n line endings:

fn char_idx_from_byte_idx(input: &str, idx: usize) -> usize {
    let char_idx = input
        .char_indices()
        .enumerate()
        .find(|(_, (i, _))| *i == idx)
        .unwrap()
        .0;
    // Unix-style newlines are counted as two chars (see
    // https://github.com/rust-lang/annotate-snippets-rs/issues/24).
    let nbr_newlines =
        input[..idx].chars().filter(|c| *c == '\n').count();
    let nbr_carriage_returns =
        input[..idx].chars().filter(|c| *c == '\r').count();
    char_idx + nbr_newlines - nbr_carriage_returns
}
lpil

comment created time in a month

issue commentrust-lang/annotate-snippets-rs

Understanding SourceAnnotation.range

I've got a similar problem: on a file with Unix line endings, the annotation gets shifted by one for each line. If I convert the file to dos line endings, then the annotation is correctly positioned. It seems like annotate-snippets counts the end of line char as two chars maybe ? Unicode in the source file also messes up annotations, so it could be a difference between char-indexing and byte-indexing.

lpil

comment created time in a month

pull request commentdhall-lang/dhall-lang

Add support for dotted field syntax

Could you add a parser test for the case where dotted fields and duplicate fields interact ? For now you only have a normalization test

Gabriel439

comment created time in a month

push eventNadrieril/dhall-rust

Nadrieril

commit sha d035e6ea0783cc270b70238bbbc1387fe511e576

TypecheckContext doesn't need PartialEq

view details

Nadrieril

commit sha 89003e1652a41419a1b6dd14f0a8a0769911a7cc

TypecheckContext doesn't need Rc It's almost never cloned anymore

view details

Nadrieril

commit sha e97e0c8e9905582aef826504b59a1844c8f67613

Make TypecheckContext a named struct

view details

Nadrieril

commit sha 5542797c77a9dfcdffec539f1a82341a450291a2

s/TypecheckContext/TyCtx/

view details

Nadrieril

commit sha ce706817dcb5cb951c566410de92a4f85aae5361

Tiny clarification

view details

Nadrieril

commit sha 015b76ce47af5b1b31661a934aee13843215c6b0

Construct T/Build closures in Expr space

view details

Nadrieril

commit sha c85d8d011445a619aca60c1e4fc2b2657ca9d646

Implement PartialEq manually for ValueKind

view details

Nadrieril

commit sha 3603fbf9d321602a2df51e7b3f7a69425bd4d304

Revert "Implement PartialEq manually for ValueKind" This reverts commit 88c31554561bd7a600560af0e6bc97c48649f43f.

view details

Nadrieril

commit sha 8edbeadbd0dc06a75ffb8bf3b0a54a62e3acc5fc

Parameterize ValueKind by its subnodes

view details

Nadrieril

commit sha 8e2da26650e202f9ccb1531fc8a88cfd89e54b6d

Implement traverse_ref for ValueKind

view details

Nadrieril

commit sha 654d752c65f0e221d225ed045a0aee62f223855e

Introduce a notion of binder

view details

Nadrieril

commit sha bc3599b815c6f9cad2f4efd30c009cbe8f765ca1

Assign a unique id to each binder

view details

Nadrieril

commit sha 8cbec8c75d9e52091bdfe28b60b6ee698d9c1392

Store corresponding binder id in AlphaVar

view details

Nadrieril

commit sha 4dc195c8d8a2ef03621fb73d15df2c66ad68be2c

Use binder ids for Value equality

view details

Nadrieril

commit sha 03da8fd6399f09c6282e0cd3930b6e39cc089043

Simplify Value::to_expr

view details

Nadrieril

commit sha a030560e60c4ff1c724216f4a5640722eb89b227

Use binder ids to reconstruct variables in expr output

view details

Nadrieril

commit sha 763a810358f15a8bac6973ac4b273f517729cc84

Oops, this endeavour is doomed

view details

Nadrieril

commit sha fc1d7b758008643447f17bc9d05adb128d1567cc

Remove binder ids The underlying purpose of them turned out to be unsound

view details

Nadrieril

commit sha f7a8d967b02bc20c093d501746ed3de53cc7da13

Simplify Shift and Subst instances

view details

Nadrieril

commit sha 72d1e3c339cf550fa5af9981af6078a813feb80a

Remove Shift/Subst traits

view details

push time in a month

delete branch Nadrieril/dhall-rust

delete branch : no-shift

delete time in a month

PR merged Nadrieril/dhall-rust

Rewrite normalization and typechecking with environments

This is a long trial-and-error PR of madness, where I tried to incrementally remove all uses of shift and subst_shift and replace them with a cleaner system with environments and closures. I took a lot of ideas from dhall-haskell in the process. This removes a ton of magic and unpredictability. Previously for example, an expression bound by a let could be recomputed many times if it was used under a lambda. I've also reorganized the file structure a bit while I was at it. I feel like this is a huge gain in understandability and clarity.

+3154 -3371

0 comment

109 changed files

Nadrieril

pr closed time in a month

push eventNadrieril/dhall-rust

Nadrieril

commit sha aa93f18c8ef9ad13c6bb4ddef90b419b3ed546f4

Factor out custom Lazy struct

view details

Nadrieril

commit sha 0c0e7d4db15abf709fafc0c9b9db4d377ea3c158

Fix module paths in serde_dhall

view details

push time in a month

PR opened Nadrieril/dhall-rust

Rewrite normalization and typechecking with environments

This is a long trial-and-error PR of madness, where I tried to incrementally remove all uses of shift and subst_shift and replace them with a cleaner system with environments and closures. I took a lot of ideas from dhall-haskell in the process. This removes a ton of magic and unpredictability. Previously for example, an expression bound by a let could be recomputed many times if it was used under a lambda. I've also reorganized the file structure a bit while I was at it. I feel like this is a huge gain in understandability and clarity.

+3105 -3370

0 comment

107 changed files

pr created time in a month

push eventNadrieril/dhall-rust

Nadrieril

commit sha d8de45763037937b5c2dedbe5f7bb95a4e7bc7cd

Avoid unnecessary allocations of `Value`s

view details

Nadrieril

commit sha b79a9b81a803794a7a86d953ced24f0d3e2fd212

Only the Form must be in a RefCell

view details

Nadrieril

commit sha a87b22da10aa20cef939d3c3c7b56710a1f78c2c

Move Form::PartialExpr into Thunk

view details

Nadrieril

commit sha 884774dbf13fd0a0fb6936c4259527a30a285ff0

Replace Form with a pair of RefCells, in preparation for OnceCell

view details

Nadrieril

commit sha 2700af36adfac4390b9395ac2ed0e534b7eac887

Use OnceCell to enable returning &ValKind

view details

Nadrieril

commit sha ace2a1f2783f770dc801f74e9118d39c73eb158a

Get rid of all the manual Ref borrows

view details

Nadrieril

commit sha 4e2bb03bcf6355d49216c6886bf03e5aeaad16cc

Eval Thunk by move

view details

Nadrieril

commit sha 70af1a47bce9e6c8282d6e53cf82aeda9aab10de

Tweak ConstantClosure

view details

Nadrieril

commit sha 4312ad935d881f269fa7e9cc3d880fa763db957d

Use Rc equality to shortcut Value equality

view details

push time in a month

push eventNadrieril/dhall-rust

Nadrieril

commit sha db6c09f33c3c794e4b6ec8a7aa80978d945a9d7a

Remove dead code

view details

Nadrieril

commit sha 26d4975a4c94c2b9fd0c075ad94c2588e3cf24e8

Use NameEnv in tyexpr_to_expr

view details

Nadrieril

commit sha 22bec94618454f57773716870f5624579ab712ce

s/QuoteEnv/VarEnv/

view details

Nadrieril

commit sha 280b3174476ef8fe5a98f3614f4fe253fa243d8c

Finally get rid of all of the shift/subst_shift !

view details

Nadrieril

commit sha 489174a426e6057a68b6edd2e9b4387d09912a25

Move envs to their own files

view details

Nadrieril

commit sha a928c3c4f51d87fd942e8a81727962c00abf6808

Cleanup variable handling

view details

Nadrieril

commit sha 655f67fb29ca847f86c3e19338757e7b031d4f50

Move builtins-related code to its own module

view details

Nadrieril

commit sha 7743647137d1914c280e03d6aaee81e507cff97d

Remove old typecheck module

view details

Nadrieril

commit sha 5e3aaa40305a86ee90f889614c2b370184c4ef3a

Actually, no need for keeping extra args in apply_builtin

view details

Nadrieril

commit sha b55e291825e4e7c6899d9bf7051b816660fa43a3

Clean imports

view details

Nadrieril

commit sha 7dd2d64073b662acccb39601591c754279385308

No need for the current env to tck Foo/build closures

view details

Nadrieril

commit sha ec5fb594adf10b18a4457c3089ce4b00e2c50a39

Remove debug output in type errors

view details

Nadrieril

commit sha 17732b041dbd44f39ce3d04a289146db9882e865

Encapsulate partially applied builtin in a separate struct

view details

Nadrieril

commit sha adbf51213a0df5d645d3d9423f0b284f5aff9a4e

Remove use of take_mut

view details

Nadrieril

commit sha da55a72717b247444a31b1932f85ce4abec03c14

Tweak

view details

Nadrieril

commit sha cb86493012b268ec32ad85a42b54fb1a2adab7b0

s/as_whnf/kind/

view details

Nadrieril

commit sha 25bd09136742403d7f3d6c6143f72e6687f39457

Make unnormalized Values unobservable

view details

Nadrieril

commit sha 837298f26e07bb264a6b6f0286cbb811553b0477

Increase encapsulation for Closures

view details

Nadrieril

commit sha 4c4ec8614b84d72fee4d765857325b73dad16183

Remove NF marker; it was premature optimization

view details

Nadrieril

commit sha 67bbbafbc9730d74e20e5ac082ae9a87bdf2234e

Introduce Thunks and normalize lazily

view details

push time in a month

Pull request review commentdhall-lang/dhall-lang

Fix typing rule for merging `Optional`s

 An implementation could simply loop over the inferred record type.  `Optional`s can also be `merge`d as if they had type `< None | Some : A >`: --    Γ ⊢ o : Optional A-    o ⇥ None A-    Γ ⊢ merge t < None | Some : A >.None : T-    ────────────────────────────────────────-    Γ ⊢ merge t o : T---    Γ ⊢ o : Optional A-    o ⇥ Some a-    Γ ⊢ merge t (< None | Some : A >.Some a) : T-    ────────────────────────────────────────────+    +    Γ₀ ⊢ o : Optional A+    ↑(1, x, 0, (Γ₀, x : < None | Some : A >)) = Γ₁

I find it makes it harder to see what's happening, in an already non-trivial rule:

Γ₀ ⊢ o : Optional A
↑(1, _, 0, (Γ₀, _ : < None | Some : A >)) = Γ₁
Γ₁ ⊢ merge t _ : T
──────────────────────────────────
Γ ⊢ merge t o : T

So I'd rather keep it as is

Nadrieril

comment created time in a month

push eventdhall-lang/dhall-lang

Nadrieril

commit sha 9b3aa87128b424efeeae6ca26ec348be7e9cda9b

Add regression test

view details

push time in a month

delete branch Nadrieril/dhall-lang

delete branch : Nadrieril-patch-1

delete time in a month

create barnchNadrieril/dhall-lang

branch : Nadrieril-patch-1

created branch time in a month

PR opened dhall-lang/dhall-lang

Fix typing rule for merging `Optional`s

The current rule for typechecking merge on Optionals is the following:

Γ ⊢ o : Optional A
o ⇥ None A
Γ ⊢ merge t < None | Some : A >.None : T
────────────────────────────────────────
Γ ⊢ merge t o : T


Γ ⊢ o : Optional A
o ⇥ Some a
Γ ⊢ merge t (< None | Some : A >.Some a) : T
────────────────────────────────────────────
Γ ⊢ merge t o : T

It normalizes the argument in order to know if it's a None or a Some, and uses that to typecheck the resulting merge expression. Not only is that unnecessary work, I think it's actually wrong. The correct behavior is not to construct a value of type < None | Some : A > manually, but to assume one is present in the context. For example, I believe the current rule fails to typecheck the following:

λ(x : Optional Bool) → merge { None = 0, Some = λ(_ : Bool) → 1 } x

because it will try and fail to normalize x to either None or Some. This PR fixes that.

+5 -12

0 comment

1 changed file

pr created time in a month

create barnchdhall-lang/dhall-lang

branch : Nadrieril-patch-1

created branch time in a month

push eventNadrieril/dhall-rust

Nadrieril

commit sha 9e9b556ee2212540ba43d85249df8c763aa6da2b

Postpone fixing Foo/build builtins

view details

Nadrieril

commit sha b72f0968ac19058b9cc513ab0ed1785133232a3d

Implement basic typecheck with new approach

view details

Nadrieril

commit sha 70e6e3a06c05cfe7d8ca3d6f072e7182639c147f

Typecheck more cases

view details

Nadrieril

commit sha f2e8c414993d5c9fcc63f5c035f755712c01dad0

Enable comparing Closures for equality

view details

Nadrieril

commit sha 8c64ae33149db4edaaa89d2d187baf10a2b9f8bf

Make most type errors stringy

view details

Nadrieril

commit sha 574fb56e87c1a71dc8d7efbff2789d3cfabdc529

More typecheck

view details

Nadrieril

commit sha 6c51ad1da8dc4df54618af80b445bf49f771ec43

Moar typecheck

view details

Nadrieril

commit sha 5a835d9db35bf76858e178e1bd66e60128879629

Fix a bunch of bugs and more tck

view details

Nadrieril

commit sha 6d655b1c457d1e6cc9363bfa1c0e3ffd7ff03721

Start rewriting value comparison

view details

Nadrieril

commit sha 8ced62a2cdde95c4d67298289756c12f53656df0

Fix all sorts of variable shenanigans

view details

Nadrieril

commit sha 084e81956e99bc759012be7c171f4095c2e59d22

Thread env through nztion to fix Foo/build closures

view details

Nadrieril

commit sha 7683b0d762cf0df489ad4bc006e8db2358e81cf4

Implement assert & merge and fix more bugs

view details

Nadrieril

commit sha f31ccaa40df77b1ca8b37db46a819460c831006e

Fix more bugs

view details

Nadrieril

commit sha f88880004c7dcf5e67c4d5e2330e6e879523f27b

Use Normalized in serde_dhall

view details

Nadrieril

commit sha 1e466a20533d936f44430b1bc18508cd00e5ccd2

Use TyExpr in Typed

view details

Nadrieril

commit sha e410dbb428e621fe600be43ddecca1c7bff7cb2f

Fix insufficient normalization

view details

push time in a month

pull request commentdhall-lang/dhall-lang

Disallow Natural literals with leading zeros

Could you add a parser failure test for the case of a Natural with a leading 0 ?

philandstuff

comment created time in a month

pull request commentdhall-lang/dhall-lang

Add support for duplicate record fields

A more general comment is that we have no good way of explaining precisely the phases through which an expression passes as it's processed by an implementation. Someone might completely miss that this desugaring should be taking place because it's not menitoned in the grammar of the type inference rules. This for me is one more argument in favor of replacing the inference rules with an implementation in a mainstream language.

Gabriel439

comment created time in a month

create barnchNadrieril/dhall-rust

branch : no-shift

created branch time in a month

push eventNadrieril/dhall-rust

Nadrieril

commit sha 140b5d5ab24795a4053f7e5bdcd8b2343e35558e

release

view details

push time in a month

delete branch Nadrieril/dhall-rust

delete branch : improve-api

delete time in a month

more