profile
viewpoint

dhall-lang/dhall-lang 2879

Maintainable configuration files

Nadrieril/dhall-rust 180

Maintainable configuration files, for Rust users

Ekleog/todiff 2

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

push eventdhall-lang/dhall-lang

Gabriel Gonzalez

commit sha 71a308e656af61f1773043d332dc72efc2bf748e

Haskell implementation of `shift` / `subst` (#1115) This builds upon #1102 by adding a literate Haskell implementation of shifting and substitution. Note that once we switch to normalization-by-evaluation these two utilities will eventually disappear, but I started with them since they are the most self-contained functions in the standard.

view details

push time in 12 hours

delete branch dhall-lang/dhall-lang

delete branch : gabriel/haskell_shift_subst

delete time in 12 hours

PR merged dhall-lang/dhall-lang

Haskell implementation of `shift` / `subst`

This builds upon #1102 by adding a literate Haskell implementation of shifting and substitution. Note that once we switch to normalization-by-evaluation these two utilities will eventually disappear, but I started with them since they are the most self-contained functions in the standard.

+669 -32

0 comment

6 changed files

Gabriel439

pr closed time in 12 hours

push eventdhall-lang/dhall-lang

Gabriel Gonzalez

commit sha f23b5b9b1f2bba5cc859bf088e7343ceccfa6e58

Upgrade Nixpkgs (#1114) The motivation of this change is to pick up [newer Nixpkgs code](https://github.com/NixOS/nixpkgs/pull/102392) necessary to support `store.dhall-lang.org`. See: https://discourse.dhall-lang.org/t/rfc-proxy-dhall-lang-org/144 This also consolidates all of our Nixpkgs references into a single reference to simplify future upgrades.

view details

Gabriel Gonzalez

commit sha b2344e922a3cebc4f5b055abe52d3ec50be6eab1

Fix Hydra builds (#1117) Hydra started to get stuck after being upgraded in #1114. Specifically, builds would get stuck on the "Receiving outputs" step. The reason this was happening was because of how we were instructing Hydra to build things on the local machine. The correct way to do this is to specify `localhost`, because Hydra has special logic to handle that. If you specify the current machine by any other hostname then Hydra will treat it as if it is a remote machine and then get stuck attempting to take the same lock twice (once for its own store and once for the "remote" machine's store, which happens to be the same store). Also, now that we don't `ssh` into our own machine we don't need to generate a key pair for the `hydra-queue-runner` user, and we also don't need to install the public key for our host as a known host.

view details

Gabriel Gonzalez

commit sha a9950b1775f6c9ed4dc0b7284016480058a2cdb5

Merge branch 'master' into gabriel/haskell_shift_subst

view details

push time in 13 hours

pull request commentNadrieril/dhall-rust

If can return a type

Oh, I think it's because I use https://github.com/nix-community/nix-direnv Since you also use nix, maybe you should check it out ๐Ÿ˜„

basile-henry

comment created time in 3 days

pull request commentNadrieril/dhall-rust

If can return a type

Well, I started using direnv (I would manually open a nix-shell before). And I don't want to accidentally commit it's state directory.

Admittedly it probably wasn't the right PR to do this in ๐Ÿ˜…

basile-henry

comment created time in 3 days

PR opened Nadrieril/dhall-rust

Reviewers
If can return a type standard-compliance

Implements https://github.com/dhall-lang/dhall-lang/pull/1090

And I believe this is all we need to be compliant with the upcoming standard v20.0.0: https://github.com/dhall-lang/dhall-lang/pull/1116 :smile:

+6 -11

0 comment

5 changed files

pr created time in 3 days

issue commentdhall-lang/dhall-lang

Add config file for formatting defaults

@mheiber: What if we made the behavior configurable via environment variables?

That would probably work. I don't think it's a great experience, though. Everyone's editors and shells would have to be direnv-aware in order to get the homogeneity I'm looking for.

I don't think I'd use such a feature. But if there's a lot of demand for it, I'm happy to update the PR to use environment variables instead.

mheiber

comment created time in 4 days

issue commentdhall-lang/dhall-lang

Relax the restriction that list literals can only contain elements of type Type.

what we need is โœจ universe polymorphism โœจ

ocharles

comment created time in 4 days

issue commentdhall-lang/dhall-lang

Add config file for formatting defaults

@mheiber: What if we made the behavior configurable via environment variables?

mheiber

comment created time in 4 days

issue commentdhall-lang/dhall-lang

Import resolution independent of type checking

@basile-henry: Yeah, I think separating import resolution errors from other errors is a good idea. I actually thought we already had an issue to track decoupling the two, but I couldn't find it

basile-henry

comment created time in 4 days

push eventdhall-lang/dhall-lang

Gabriel Gonzalez

commit sha 12029e338ef45e53849694859f80210d9717f955

Fix description of `Text/replace` change โ€ฆ as suggested by @basile-henry Co-authored-by: Basile Henry <bjm.henry@gmail.com>

view details

push time in 4 days

issue commentdhall-lang/dhall-lang

Relax the restriction that list literals can only contain elements of type Type.

Well, that, or implicit arguments to specify the type of the type being applied to the list

ocharles

comment created time in 4 days

push eventdhall-lang/dhall-lang

Gabriel Gonzalez

commit sha b2344e922a3cebc4f5b055abe52d3ec50be6eab1

Fix Hydra builds (#1117) Hydra started to get stuck after being upgraded in #1114. Specifically, builds would get stuck on the "Receiving outputs" step. The reason this was happening was because of how we were instructing Hydra to build things on the local machine. The correct way to do this is to specify `localhost`, because Hydra has special logic to handle that. If you specify the current machine by any other hostname then Hydra will treat it as if it is a remote machine and then get stuck attempting to take the same lock twice (once for its own store and once for the "remote" machine's store, which happens to be the same store). Also, now that we don't `ssh` into our own machine we don't need to generate a key pair for the `hydra-queue-runner` user, and we also don't need to install the public key for our host as a known host.

view details

push time in 4 days

PR merged dhall-lang/dhall-lang

Fix Hydra builds

Hydra started to get stuck after being upgraded in #1114. Specifically, builds would get stuck on the "Receiving outputs" step.

The reason this was happening was because of how we were instructing Hydra to build things on the local machine. The correct way to do this is to specify localhost, because Hydra has special logic to handle that. If you specify the current machine by any other hostname then Hydra will treat it as if it is a remote machine and then get stuck attempting to take the same lock twice (once for its own store and once for the "remote" machine's store, which happens to be the same store).

+2 -52

0 comment

2 changed files

Gabriel439

pr closed time in 4 days

delete branch dhall-lang/dhall-lang

delete branch : gabriel/fix_hydra

delete time in 4 days

issue commentdhall-lang/dhall-lang

Relax the restriction that list literals can only contain elements of type Type.

@ocharles: Yeah, the only way this would work is if List became a keyword that had to be saturated with the element type instead of a built-in

ocharles

comment created time in 4 days

pull request commentdhall-lang/dhall-lang

Improve `Prelude.JSON.render` output

... or even remove `Text/show` as a built-in after deprecation.

I would be fine with removing Text/show so long as text escaping ends up in the Prelude. I think it's important to have a quick and easy Text.escapeFor.Dhall and/or Text.escapeFor.Json or whatnot, because I currently can just slap Text/show on the problem and assume it works rather than having to remember every single thing that needs to be escaped for Json and invariably forgetting one.

Gabriel439

comment created time in 4 days

issue commentdhall-lang/dhall-lang

Relax the restriction that list literals can only contain elements of type Type.

I suppose one follow-on complication is:

List is a function from a Type to another Type:

โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
ฮ“ โŠข List : Type โ†’ Type

Would no longer be true. Perhaps at this point we're stuck.

ocharles

comment created time in 4 days

issue openeddhall-lang/dhall-lang

Relax the restriction that list literals can only contain elements of type Type.

The type inference rules for list literals states

Note that the above rules forbid List elements that are Types. More generally, if the element type is not a Type then that is a type error.

Is there a good reason to have this restriction? What is the problem of changing

ฮ“ โŠข t : Tโ‚€   ฮ“ โŠข Tโ‚€ : Type   ฮ“ โŠข [ tsโ€ฆ ] : List Tโ‚   Tโ‚€ โ‰ก Tโ‚
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
ฮ“ โŠข [ t, tsโ€ฆ ] : List Tโ‚€

to

ฮ“ โŠข t : Tโ‚€   ฮ“ โŠข [ tsโ€ฆ ] : List Tโ‚   Tโ‚€ โ‰ก Tโ‚
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
ฮ“ โŠข [ t, tsโ€ฆ ] : List Tโ‚€

?

created time in 4 days

Pull request review commentdhall-lang/dhall-lang

Version 19.0.0 โ†’ 20.0.0

 file.  For more info about our versioning policy, see [versioning.md](standard/versioning.md). +## `v20.0.0`++Breaking changes:++* [`Text/replace` waits to replace interpolated `Text`](https://github.com/dhall-lang/dhall-lang/pull/1084)++  `Text/replace` will now not reduce if the `Text` literal to replace has any+  interpolated subexpressions.++  For example, before this change, the following expression:++  ```dhall+  ฮป(x : Text) โ†’ Text/replace "a" "b" "a${x}"+  ```++  โ€ฆ would normalize to:++  ```dhall+  ฮป(x : Text) โ†’ Text/replace "a" "b" "b${x}"

I think before that change it normalized even further than that:

  ฮป(x : Text) โ†’ "b${x}"
Gabriel439

comment created time in 5 days

issue closeddhall-lang/dhall-lang

Missing recursive merge simplification?

What do people think about

ฮป(x : {}) โ†’ ฮป(y : {}) โ†’ x โˆง y

changing to

ฮป(x : {}) โ†’ ฮป(y : {}) โ†’ {=}

?

We already have simplifications for if the left or right hand side are the empty record, it seems logical to me to have one more case for when they are both empty.

closed time in 5 days

ocharles

issue commentdhall-lang/dhall-lang

Missing recursive merge simplification?

Sorry, my previous comment was a little incorrect. You're right in your response, but I just wanted to mention that in my implementation of Dhall (which is presumably not standards conformant), I desugar โˆง while elaborating, and I elaborate into a subset of Dhall that doesn't even have โˆง. I can do this because there is no computational content to โˆง, it is purely type-directed syntactic sugar. For reference, https://hub.darcs.net/ocharles/dhalli/browse/lib/Dhalli/Elaboration.hs#810.

That said, this is outside the scope of how Dhall as a standardised language works, so I should probably open another issue talking about this broader idea.

ocharles

comment created time in 5 days

issue commentdhall-lang/dhall-lang

Missing recursive merge simplification?

Hmm, I see. My implementation does actually do both of those simplifications because I just treat this operator as type directed syntactic sugar

ocharles

comment created time in 5 days

issue commentdhall-lang/dhall-lang

Missing recursive merge simplification?

We already have simplifications for if the left or right hand side are the empty record

These simplifications only apply when one of the records is a concrete value. They don't work for example in this case:

โŠข ฮป(x : {}) โ†’ ฮป(y : {a : Bool}) โ†’ x โˆง y

ฮป(x : {}) โ†’ ฮป(y : { a : Bool }) โ†’ x โˆง y

To perform the simplification you propose we'd have to preserve type information during normalization.

ocharles

comment created time in 5 days

issue openeddhall-lang/dhall-lang

Missing recursive merge simplification?

What do people think about

ฮป(x : {}) โ†’ ฮป(y : {}) โ†’ x โˆง y

changing to

ฮป(x : {}) โ†’ ฮป(y : {}) โ†’ {=}

?

We already have simplifications for if the left or right hand side are the empty record, it seems logical to me to have one more case for when they are both empty.

created time in 5 days

PR opened dhall-lang/dhall-lang

Improve `Prelude.JSON.render` output

Now that we have language support for Text/replace we don't need to use Text/show any longer. In particular, one of the limitations of Text/show was that we were using it both to render valid Dhall values and also to render valid JSON strings, which constrained it to produce weird output for $ (\u0024). However, now that we have Text/replace we can use a JSON-specific escaping strategy.

This also implies that we can make two further improvements (not included in this pull request):

  • We could standardize the behavior of Text/show in terms of Text/replace

    โ€ฆ or even remove Text/show as a built-in after deprecation.

  • We can now improve the behavior of Text/show to escape $ as \$ instead of \u0024

    โ€ฆ now that it's no longer used for escaping JSON strings.

+45 -10

0 comment

8 changed files

pr created time in 5 days

create barnchdhall-lang/dhall-lang

branch : gabriel/improve_json_render

created branch time in 5 days

push eventdhall-lang/dhall-lang

Gabriel Gonzalez

commit sha b3644a5d3119c8b3bef15de6eac3b47e0b5a5fd9

Simplify things further Now that we don't `ssh` into our own machine we don't need to generate a key pair for the `hydra-queue-runner` user, and we also don't need to install the public key for our host as a known host.

view details

push time in 5 days

PR opened dhall-lang/dhall-lang

Fix Hydra builds

Hydra started to get stuck after being upgraded in #1114. Specifically, builds would get stuck on the "Receiving outputs" step.

The reason this was happening was because of how we were instructing Hydra to build things on the local machine. The correct way to do this is to specify localhost, because Hydra has special logic to handle that. If you specify the current machine by any other hostname then Hydra will treat it as if it is a remote machine and then get stuck attempting to take the same lock twice (once for its own store and once for the "remote" machine's store, which happens to be the same store).

+1 -1

0 comment

1 changed file

pr created time in 5 days

more