From asr at eafit.edu.co Sat Jun 2 22:06:26 2018 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Sat, 2 Jun 2018 15:06:26 -0500 Subject: [Agda-dev] [ANNOUNCE] Agda 2.5.4 Message-ID: Dear all, The Agda Team is very pleased to announce the release of Agda 2.5.4. GHC supported versions =============== Agda 2.5.4 has been tested with: GHC 7.10.3, 8.0.2, 8.2.2 and 8.4.2 (Linux, macOS and Windows) GHC 8.4.3 (Linux and macOS) Note that GHC 8.4.* requires cabal-install ? 2.2.0.0. Installation ======= cabal update && cabal install Agda Standard library ========== For the time being, you can use the `experimental` branch of the standard library which is compatible with Agda 2.5.4. This branch is available at https://github.com/agda/agda-stdlib/tree/experimental What is new, language changes, incompatibilities and closed issues ======================================== https://hackage.haskell.org/package/Agda-2.5.4/changelog Enjoy Agda 2.5.4. -- Andr?s on behalf of the Agda Team From ulf.norell at gmail.com Wed Jun 20 11:21:28 2018 From: ulf.norell at gmail.com (Ulf Norell) Date: Wed, 20 Jun 2018 11:21:28 +0200 Subject: [Agda-dev] New branch policy (issue #3104) Message-ID: After talking to Andrea, we have decided that the next release of Agda will be 2.6.0 and include `--cubical`. With this decision we also took the opportunity to change how we use the branches. Going forward all development should happen on `master` unless it's some new big feature like cubical. So, `stable-2.5` is frozen and we'll use `master` in the same way we've used `stable-2.5` previously. Taking over the role of `master` will be a new branch `future` where new experimental features should go. Until we actually have any new features on `future` you can (should) ignore it, but once we do, `master` should be merged into `future` whenever you make a change (just like for `stable-2.5`/`master` previously). Watch this space for when that happens. / Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pborthelle at hadoly.fr Tue Jun 26 00:36:54 2018 From: pborthelle at hadoly.fr (peio borthelle) Date: Mon, 25 Jun 2018 23:36:54 +0100 Subject: [Agda-dev] Using the size solver to get proto-cumulativity Message-ID: <4c747ba24bd6d082cd1954b6aec797701c417755.camel@hadoly.fr> Hi, new here! This is a follow-up from irc (i'm lapinot). So basically i wondered if it had already been investigated to give levels the same kind of interface as the current sizes (and if it has, what are the pitfalls). To explain a bit more what i mean, the crucial point is probably having a subtyping relationship but only for levels. I guess it would look like: postulate LevelUniv : LevelUniv Level : LevelUniv Level<= : Level -> LevelUniv lzero : Level lsuc : Level -> Level lub : Level -> Level -> Level Together with a subtyping relationships `if a <= b, Level<= a <: Level<= b`, `if a : Level, a : Level<= a` and `LevelUniv <: Set`. I guess that we could then create a type of explicitely cumulative sets: CSet : (a : Level) -> Set (lsuc a) CSet a = Sigma (Level<= a) (\ b -> Set b) Incidentally we could also get rid of the most annoying instances of `Lift`-hell that arise when trying to give smaller than intended sets as parameters to some structure. data Ugly (a : Level) : Set (lsuc a) where con : Set a -> Foo -- throws in wrapping/unwrapping, clutters the output type (affects next definitions) ugly : {a b} -> Set a -> Ugly (a lub b) ugly X = con (Lift X) -- no wrapping, clean interface data Nice (a : Level) : Set (lsuc a) where con : {b : Level<= a} -> Set b -> Foo Note that this whole thing may be actually hard if the generated constraints are hard to solve, but until now i failed to see how they could be different than the one for the sizes. There was some point about uniqueness of the solutions, i'm not sure how this is handled by the sizes (is size uniqueness required?). Yet it might be pretty reasonable to select the smallest solution. If this approach works, it may be interesting to unify sizes and levels to a more abstract ordinal (heck we might even add `lim : (a : Ord) -> (Ord< a -> Ord) -> Ord`!). I guess that nothing stops us from using the same type to index sets (which is already a core language type, thus magic) and to help solving termination. Cheers, peio From guillaume.allais at ens-lyon.org Tue Jun 26 09:37:02 2018 From: guillaume.allais at ens-lyon.org (Guillaume Allais) Date: Tue, 26 Jun 2018 09:37:02 +0200 Subject: [Agda-dev] Using the size solver to get proto-cumulativity In-Reply-To: <4c747ba24bd6d082cd1954b6aec797701c417755.camel@hadoly.fr> References: <4c747ba24bd6d082cd1954b6aec797701c417755.camel@hadoly.fr> Message-ID: <646e3e6c-39c4-3a3a-4679-f62a9144470b@ens-lyon.org> Hi all, Bounded level polymorphism would be amazing for stuff like IO. At the moment we have this coinductive definition which mandates that all actions live at the same level: data IO {a} (A : Set a) : Set (suc a) where ? lift?? : (m : Prim.IO A) ? IO A ? return : (x : A) ? IO A ? _>>=_? : {B : Set a} (m : ? (IO B)) (f : (x : B) ? ? (IO A)) ? IO A ? _>>_?? : {B : Set a} (m? : ? (IO B)) (m? : ? (IO A)) ? IO A Because the primitive actions in the stdlib are defined at zero, this means that everything needs to be at level 0 (or you need to define your own new level-polymorphic versions of the primitives by going back to the low-level IO.Primitive internals). Ideally you'd indeed want (note that I'd prefer `Set<` to `Set<=` as this would allow us to make `IO` an endofunctor on `Set a` which would make it fit inside the `RawMonad` interface): data IO {a} (A : Set a) : Set a where ? lift?? : (m : Prim.IO A) ? IO A ? return : (x : A) ? IO A ? _>>=_? : {B : Set< a} (m : ? (IO B)) (f : (x : B) ? ? (IO A)) ? IO A ? _>>_?? : {B : Set< a} (m? : ? (IO B)) (m? : ? (IO A)) ? IO A I have no idea about the added complexity in terms of inference though. I just know I'd love to have something like this! :D Cheers, -- gallais On 26/06/18 00:36, peio borthelle wrote: > Hi, new here! This is a follow-up from irc (i'm lapinot). > > So basically i wondered if it had already been investigated to give levels the same > kind of interface as the current sizes (and if it has, what are the pitfalls). To > explain a bit more what i mean, the crucial point is probably having a subtyping > relationship but only for levels. I guess it would look like: > > postulate > LevelUniv : LevelUniv > Level : LevelUniv > Level<= : Level -> LevelUniv > lzero : Level > lsuc : Level -> Level > lub : Level -> Level -> Level > > Together with a subtyping relationships `if a <= b, Level<= a <: Level<= b`, `if a : > Level, a : Level<= a` and `LevelUniv <: Set`. I guess that we could then create a > type of explicitely cumulative sets: > > CSet : (a : Level) -> Set (lsuc a) > CSet a = Sigma (Level<= a) (\ b -> Set b) > > Incidentally we could also get rid of the most annoying instances of `Lift`-hell that > arise when trying to give smaller than intended sets as parameters to some structure. > > data Ugly (a : Level) : Set (lsuc a) where > con : Set a -> Foo > > -- throws in wrapping/unwrapping, clutters the output type (affects next definitions) > ugly : {a b} -> Set a -> Ugly (a lub b) > ugly X = con (Lift X) > > -- no wrapping, clean interface > data Nice (a : Level) : Set (lsuc a) where > con : {b : Level<= a} -> Set b -> Foo > > > Note that this whole thing may be actually hard if the generated constraints are hard > to solve, but until now i failed to see how they could be different than the one for > the sizes. There was some point about uniqueness of the solutions, i'm not sure how > this is handled by the sizes (is size uniqueness required?). Yet it might be pretty > reasonable to select the smallest solution. > > If this approach works, it may be interesting to unify sizes and levels to a more > abstract ordinal (heck we might even add `lim : (a : Ord) -> (Ord< a -> Ord) -> > Ord`!). I guess that nothing stops us from using the same type to index sets (which > is already a core language type, thus magic) and to help solving termination. > > Cheers, > peio > _______________________________________________ > Agda-dev mailing list > Agda-dev at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/agda-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From Jesper at sikanda.be Tue Jun 26 11:15:21 2018 From: Jesper at sikanda.be (Jesper Cockx) Date: Tue, 26 Jun 2018 11:15:21 +0200 Subject: [Agda-dev] Using the size solver to get proto-cumulativity In-Reply-To: <4c747ba24bd6d082cd1954b6aec797701c417755.camel@hadoly.fr> References: <4c747ba24bd6d082cd1954b6aec797701c417755.camel@hadoly.fr> Message-ID: Hi Pelo, Thanks for your mail! It's indeed an attractive idea in theory to merge sizes and levels into a common type of ordinals. Unfortunately there are currently still quite a few open issues related to sized types and size subtyping in particular (see https://github.com/agda/agda/labels/sized-types), so I would be reluctant to carry out such a merger at the moment. There are also a few subtle differences between the typing rules for sizes and for levels; for example the size solver instantiates unsolved sizes to infinity, but this would make no sense for levels. Instead, for levels we want to find the *smallest* consistent assignment. During the last Agda meeting, I experimented with adding cumulativity to Agda, but I got stuck on the problem that in the presence of subtyping, we cannot trust the constraint solver to produce well-typed solutions. For example, we may have a metavariable `_X : Set0` and a constraint `_X =?= Set0 : Set1` (note that this constraint is well-typed since both `_X : Set1` and `Set0 : Set1`). However, we should *not* instantiate `_X := Set`, since we don't have `Set : Set`. So to properly implement subtyping we need some way to 'downcast' metavariable solutions to their actual type. I started experimenting with a solution to this problem using `checkInternal` (see the --double-check flag on master for the current status), but a more direct approach for downcasting could work as well. Once this problem is solved, there is still the *real* problem, namely how to find the smallest consistent solution for a system of level metavariables and (in)equalities between them. Here your proposal of reusing the size solver could work, but the solver would have to be extended to deal with the `lub` constructor. This is especially hard if `lub` can occur on the right side on an inequality, since there are two possible solutions: if `a =< lub b c`, then either `a =< b` or `a =< c`, but we don't know which one. To avoid this problem, we could maybe enforce some style of using levels that prevents the creation of such constraints, e.g. don't use `lub` in the return type of a function. In Coq they have recently solved the problem of having cumulativity + explicit universe polymorphism (see https://www.irif.fr/~sozeau/research/publications/drafts/unification-jfp.pdf). However, there are some caveats for adopting this approach in Agda: - Coq doesn't care about uniqueness of metavariable solutions as much as Agda, so a solver for Agda would have to be more conservative. - In Coq, universe metavariables cannot depend on ordinary variables/terms since levels cannot be computed from terms, but in Agda they can. This makes it hard to implement a solver that deals *just* with levels without worrying about arbitrary terms. - The implementation of Coq's solver is quite complex, so it would take nontrivial effort to implement the same thing for Agda. All of this is certainly not meant to discourage you from looking into this approach further, quite the opposite :) If you (or anyone else) are interested in helping out, I would recommend to first look into the current problems with subtyping we already have for sized types, since they will only become worse once we add other kinds of subtyping such as cumulativity. Cheers, Jesper ps: I'm very interested in working more on this stuff. If you want me to elaborate more on some part of this mail, just ask! On Tue, Jun 26, 2018 at 12:36 AM, peio borthelle wrote: > Hi, new here! This is a follow-up from irc (i'm lapinot). > > So basically i wondered if it had already been investigated to give levels > the same > kind of interface as the current sizes (and if it has, what are the > pitfalls). To > explain a bit more what i mean, the crucial point is probably having a > subtyping > relationship but only for levels. I guess it would look like: > > postulate > LevelUniv : LevelUniv > Level : LevelUniv > Level<= : Level -> LevelUniv > lzero : Level > lsuc : Level -> Level > lub : Level -> Level -> Level > > Together with a subtyping relationships `if a <= b, Level<= a <: Level<= > b`, `if a : > Level, a : Level<= a` and `LevelUniv <: Set`. I guess that we could then > create a > type of explicitely cumulative sets: > > CSet : (a : Level) -> Set (lsuc a) > CSet a = Sigma (Level<= a) (\ b -> Set b) > > Incidentally we could also get rid of the most annoying instances of > `Lift`-hell that > arise when trying to give smaller than intended sets as parameters to some > structure. > > data Ugly (a : Level) : Set (lsuc a) where > con : Set a -> Foo > > -- throws in wrapping/unwrapping, clutters the output type (affects next > definitions) > ugly : {a b} -> Set a -> Ugly (a lub b) > ugly X = con (Lift X) > > -- no wrapping, clean interface > data Nice (a : Level) : Set (lsuc a) where > con : {b : Level<= a} -> Set b -> Foo > > > Note that this whole thing may be actually hard if the generated > constraints are hard > to solve, but until now i failed to see how they could be different than > the one for > the sizes. There was some point about uniqueness of the solutions, i'm not > sure how > this is handled by the sizes (is size uniqueness required?). Yet it might > be pretty > reasonable to select the smallest solution. > > If this approach works, it may be interesting to unify sizes and levels to > a more > abstract ordinal (heck we might even add `lim : (a : Ord) -> (Ord< a -> > Ord) -> > Ord`!). I guess that nothing stops us from using the same type to index > sets (which > is already a core language type, thus magic) and to help solving > termination. > > Cheers, > peio > _______________________________________________ > Agda-dev mailing list > Agda-dev at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/agda-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: