<p dir="ltr">Do you also want the same elimination and computation rules as before?<br>
Again, that may be problematic when combined with univalence.</p>
<p dir="ltr">Assuming univalence, the type Contr of small contractible types is a proposition. Hence you can define a map f from the truncation of Bool to Contr sending true to Unit and false to Unit -> Unit.</p>
<p dir="ltr">Then, by the usual computation rule for truncation, you get f | true | = Unit.<br>
But | true | = | false |, hence</p>
<p dir="ltr"> Unit = f | true | = f | false | = Unit -> Unit</p>
<p dir="ltr">(all equalities are definitional here).</p>
<p dir="ltr">It's not a contradiction yet, but having Unit and Unit -> Unit definitionally equal is already quite strange.</p>
<p dir="ltr">Guillaume</p>
<div class="gmail_quote">On Jun 7, 2013 4:13 PM, "Martin Escardo" <<a href="mailto:m.escardo@cs.bham.ac.uk">m.escardo@cs.bham.ac.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Summary of discussion:<br>
---------------------<br>
<br>
* primTrustMe doesn't do what I wanted.<br>
<br>
I wanted to identify all elements of any given type, definitionally, so as to get an Agda implementation of hpropositional truncation that fully computes, by replacing a postulate in Dan's trick with primTrustMe.<br>
<br>
For my purposes, I will use Dan's trick, as originally stated by him, with a postulate for identifying all points of || X ||.<br>
<br>
* Advantage (Dan's original point in <a href="http://homotopytypetheory.org/2011/04/23/running-circles-around-in-your-proof-assistant/" target="_blank">http://homotopytypetheory.org/<u></u>2011/04/23/running-circles-<u></u>around-in-your-proof-<u></u>assistant/</a>): <br>
<br>
The elimination-rule equation for hpropositional truncation holds<br>
definitionally rather than just propositionally.<br>
<br>
This is precisely what I need to get my proofs accepted. (And what he and other people needed to get their proofs accepted in the presence of higher-inductive types (HIT's) for lines, circles, spheres etc.)<br>
<br>
* Disadvantage (again in Dan's original post):<br>
<br>
We lose canonicity if we use || - ||, because there is a<br>
postulate. (And we may gain SegFault if we attempt to fix this by<br>
using primTrustMe).<br>
<br>
I can live with that, using a postulate as Dan originally did, rather than my failed attempt with primTrustMe, waiting for the computational open problems in univalent foundations to be sorted out. primTrustMe can't solve them in this particular case, it seems.<br>
<br>
But I have the feeling that it should be trivial to extend Agda with a type constructor for hpropositional truncation so that canonicity is preserved (but primTrustMe doesn't seem to be the answer).<br>
<br>
Best,<br>
Martin<br>
<br>
<br>
On 07/06/13 13:00, Guillaume Brunerie wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jun 7, 2013 5:40 AM, "Martin Escardo" <<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.uk</a><br>
<mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a>>> wrote:<br>
><br>
><br>
><br>
> On 06/06/13 19:57, Guillaume Brunerie wrote:<br>
>><br>
>> This is a natural number which should normalise to 0 if you have<br>
>> canonicity, but it doesn't, even if you use primTrustMe.<br>
>> (on the other hand if you *compile* it, then it will compute to 0,<br>
><br>
><br>
> It is a bit disturbing that the normalization for type checking is<br>
different from the normalization given by compilation for running terms.<br>
<br>
One difference between normalization and compilation is that when you<br>
run a program you are guaranteed to be in the empty context whereas<br>
normalization also happens in non empty contexts.<br>
<br>
>> but<br>
>> combining that with univalence you can easily get a segfault)<br>
><br>
><br>
> I want to understand this more precisely, because univalence is<br>
compatible with hpropositional truncation. Perhaps you are just saying<br>
that we cannot have all points of the truncation to be definitionally<br>
equal under univalence: the type checking is right (because it doesn't<br>
believe me when I ask to be trusted), but the compilation is wrong (for<br>
univalent foundations).<br>
<br>
Univalence is compatible with truncation but not with primTrustMe.<br>
PrimTrustMe is based on the fact that in the empty context the only<br>
proof of equality should be refl, which is not compatible with univalence.<br>
<br>
Here is how I think you can get a segfault using the interval (I haven't<br>
managed to actually get the segfault because I don't understand how to<br>
compile an Agda program yet). You can probably adapt it to truncations<br>
if you want.<br>
<br>
Assuming univalence, the types Unit and Unit -> Unit are equivalent.<br>
Hence there is a dependent type over I whose fiber over 0 is Unit and<br>
whose fiber over 1 is Unit -> Unit.<br>
Then you can take the canonical element tt of Unit, transport it along<br>
the path of the interval (so that you get a function of type Unit -><br>
Unit) and apply it to tt.<br>
What I think will happen if you try to compile it is that the path of<br>
the interval will be compiled to refl, hence the transport is just the<br>
identity so the program will try to apply the "function" tt to the<br>
argument tt, which is obviously problematic.<br>
<br>
> Anyway, if trustMe does work as a postulate as claimed earlier, why<br>
is it needed/useful at all?<br>
<br>
My impression is that it can be used to get some unsafe coercion between<br>
arbitrary types, like Obj.magic in OCaml.<br>
<br>
Guillaume<br>
<br>
>> On Jun 6, 2013 3:20 PM, "Martin Escardo" <<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.uk</a><br>
<mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a>><br>
>> <mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a> <mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a>>>><br>
wrote:<br>
>><br>
>><br>
>><br>
>> On 06/06/13 16:16, Guillaume Brunerie wrote:<br>
>><br>
>> Are you planning to compile such code?<br>
>><br>
>><br>
>> Not necessarily, but I want to normalize closed terms of e.g.<br>
>> natural number type.<br>
>><br>
>> When I say that I want a definition that computes, I mean that the<br>
>> addition of this construction should preserve canonicity (say for<br>
>> closed terms of natural number type).<br>
>><br>
>> It doesn't really seem safe to me to compile all<br>
>> truncation-is-hprop to<br>
>> refl, especially when combined with univalence.<br>
>> As far as I understand, it only affects the compiler (not the<br>
>> normalisation procedure in the type checker), so maybe it's safe<br>
>> if you<br>
>> just want to type-check code.<br>
>><br>
>><br>
>> If I wanted to just type check, then postulates would be enough.<br>
>><br>
>> For the interval, given that the two endpoints are not<br>
>> definitionally<br>
>> equal, I don't think there is any difference with the version<br>
>> using a<br>
>> postulate (unless you compile the code, in which case<br>
strange things<br>
>> might happen)<br>
>><br>
>><br>
>> Well, I would be very surprised if it works, because the interval<br>
>> gives you functional extensionality, and it would be too easy to get<br>
>> that from data abstraction + primTrustMe in such a way that<br>
>> canonicity is preserved.<br>
>><br>
>> Best,<br>
>> Martin<br>
>><br>
>><br>
>><br>
>> On Jun 6, 2013 8:35 AM, "Martin Escardo"<br>
>> <<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.uk</a> <mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a>><br>
<mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a> <mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a>>><br>
>> <mailto:<a href="mailto:m.escardo@cs.bham.ac" target="_blank">m.escardo@cs.bham.ac</a>. <mailto:<a href="mailto:m.escardo@cs.bham.ac" target="_blank">m.escardo@cs.bham.ac</a>.><u></u>__uk<br>
>><br>
>> <mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a><br>
<mailto:<a href="mailto:m.escardo@cs.bham.ac.uk" target="_blank">m.escardo@cs.bham.ac.<u></u>uk</a>>>>> wrote:<br>
>><br>
>> Hi Dan,<br>
>><br>
>> On 05/06/13 17:41, Dan Licata wrote:<br>
>><br>
>> As far as I understand it,<br>
>> primTrustMe is a way of asserting an equality, which is<br>
>> slightly<br>
>> better<br>
>> than a postulate because when it has type x = x , it<br>
>> reduces to<br>
>> refl.<br>
>><br>
>> > [...]<br>
>><br>
>> I would guess that what you're doing below is OK: For<br>
>> the usual<br>
>> definition of ∥ X ∥ as a higher inductive type,<br>
>><br>
>> (x : ∥ X ∥) (p : Id x x) -> Id p refl<br>
>><br>
>> will be propositionally true, (∥ X ∥ is an hprop, and<br>
>> therefore an<br>
>> hset).<br>
>><br>
>><br>
>> Yes, that's precisely my intuition. But this intuition<br>
>> would work<br>
>> for the interval too, because it is an hprop and hence an<br>
>> hset, but<br>
>> I don't think this trick would work for the interval. Or<br>
>> would it?<br>
>><br>
>> Using primTrustMe will strictify certain instances of<br>
>> this (the<br>
>> ones where p is constructed by applying<br>
>> truncation-is-hprop to<br>
>> definitionally equal arguments) to definitional<br>
>> equalities. Off the<br>
>> top of my head, I don't see why that would go wrong.<br>
>><br>
>><br>
>> I agree. But it would be nice to hear from those who<br>
>> designed and<br>
>> implemented the feature.<br>
>><br>
>> On the other hand, using primTrustMe to implement the<br>
>> circle or<br>
>> something like that would be bad: if loop : Id{S1} base<br>
>> base<br>
>> is defined to be primTrustMe, it will reduce to refl.<br>
>><br>
>><br>
>> I agree too.<br>
>><br>
>> Best,<br>
>> Martin<br>
>><br>
>><br>
>> -Dan<br>
>><br>
>> On Jun05, Martin Escardo wrote:<br>
>><br>
>><br>
>> On 05/06/13 03:12, Guillaume Brunerie wrote:<br>
>><br>
>> I’m not sure I understand what you are trying<br>
>> to do.<br>
>><br>
>><br>
>> I am trying to use an unsound Agda feature to<br>
>> implement a sound<br>
>> construction (hpropositional reflection or<br>
truncation).<br>
>><br>
>> I don’t really know what primTrustMe is,<br>
>><br>
>><br>
>> Me neither, and this is why I asked the question<br>
>> here. The<br>
>> documentation<br>
>> <a href="http://code.haskell.org/Agda/____doc/release-notes/2-2-6.txt" target="_blank">http://code.haskell.org/Agda/_<u></u>___doc/release-notes/2-2-6.txt</a><br>
>> <<a href="http://code.haskell.org/Agda/__doc/release-notes/2-2-6.txt" target="_blank">http://code.haskell.org/Agda/<u></u>__doc/release-notes/2-2-6.txt</a>><br>
>><br>
>><br>
>> <<a href="http://code.haskell.org/Agda/__doc/release-notes/2-2-6.txt" target="_blank">http://code.haskell.org/Agda/<u></u>__doc/release-notes/2-2-6.txt</a><br>
>> <<a href="http://code.haskell.org/Agda/doc/release-notes/2-2-6.txt" target="_blank">http://code.haskell.org/Agda/<u></u>doc/release-notes/2-2-6.txt</a>>><br>
>> says:<br>
>><br>
>> "Note that the compiler replaces all uses of<br>
>> primTrustMe<br>
>> with the<br>
>> REFL builtin, without any check for<br>
definitional<br>
>> equality. Incorrect<br>
>> uses of primTrustMe can potentially lead to<br>
>> segfaults or<br>
>> similar<br>
>> problems."<br>
>><br>
>> However, It Doesn't say what the correct uses are<br>
>> meant to be.<br>
>><br>
>> but it seems to be some kind of postulate that<br>
>> every<br>
>> type is an<br>
>> hprop, which seems much worse than just<br>
>> postulating that<br>
>> a single<br>
>> type is an hprop.<br>
>><br>
>><br>
>> Yes, but notice that I use it privately,<br>
hopefully in a<br>
>> sound way.<br>
>><br>
>> What are you trying to achieve exactly?<br>
>><br>
>><br>
>> I am trying to (soundly) implement hpropositional<br>
>> truncation<br>
>> that<br>
>> computes, without *any* postulate at all.<br>
>><br>
>> Voevodsky's Coq implementation uses<br>
type-in-type (also<br>
>> unsound in<br>
>> general, but backed by sound resizing axioms in<br>
>> this case) and<br>
>> additionally postulates the axiom of function<br>
>> extensionality<br>
>> to show<br>
>> that the truncation really is an hproposition.<br>
>><br>
>> Here is an improved version of what I sent<br>
>> yesterday, with more<br>
>> explanations, and the main question repeated.<br>
>><br>
>> Best,<br>
>> Martin<br>
>><br>
>><br>
------------------------------<u></u>____--------------------------<u></u>--__--__-------<br>
>><br>
>> Here is what we want to achieve:<br>
>><br>
>> Given a type X, we want to construct a type ∥ X ∥:<br>
>><br>
>> X type<br>
>> ----------<br>
>> ∥ X ∥ type<br>
>><br>
>> We want any two elements of ∥ X ∥ to be<br>
propositionally<br>
>> equal, written<br>
>> hprop ∥ X ∥.<br>
>><br>
>> We have the introduction rule:<br>
>><br>
>> x : X<br>
>> ---------------<br>
>> ∣ x ∣ : ∥ X ∥<br>
>><br>
>> The elimination rule or induction principle, for<br>
>> any P : ∥ X<br>
>> ∥ → Set:<br>
>><br>
>> g : (h : ∥ X ∥) → hprop(P h) f : ((x : X) →<br>
>> P ∣ x ∣)<br>
>><br>
>> ------------------------------<u></u>____------------------------<br>
>><br>
>> elim g f : (h : ∥ X ∥) → P h<br>
>><br>
>> The computation rule:<br>
>><br>
>> elim g f ∣ x ∣ = f x<br>
>><br>
>> Thus this is a bracket type that allows us to get<br>
>> out of it,<br>
>> provided<br>
>> the target has at most one element (is an<br>
>> hproposition).<br>
>><br>
>> Here is the tentative implementation:<br>
>><br>
>> \begin{code}<br>
>><br>
>> module hpropositionalTruncationTentat<u></u>____ive where<br>
>><br>
>><br>
>> private<br>
>> postulate Level : Set<br>
>> postulate zero : Level<br>
>> postulate suc : Level → Level<br>
>><br>
>> {-# BUILTIN LEVEL Level #-}<br>
>> {-# BUILTIN LEVELZERO zero #-}<br>
>> {-# BUILTIN LEVELSUC suc #-}<br>
>><br>
>> data _≡_ {ℓ} {X : Set ℓ} (x : X) : X → Set ℓ where<br>
>> refl : x ≡ x<br>
>><br>
>> {-# BUILTIN EQUALITY _≡_ #-}<br>
>> {-# BUILTIN REFL refl #-}<br>
>><br>
>> \end{code}<br>
>><br>
>> This is unsound, but we try to use it to perform a<br>
>> sound<br>
>> construction:<br>
>><br>
>> \begin{code}<br>
>><br>
>> private<br>
>> primitive<br>
>> primTrustMe : ∀{ℓ} {X : Set ℓ} {x y : X} →<br>
x ≡ y<br>
>><br>
>> \end{code}<br>
>><br>
>> Notice that we keep the above private to the<br>
>> module, so that the<br>
>> unsoundness doesn't leak to modules that use this<br>
>> module but no<br>
>> unsound Agda features.<br>
>><br>
>> The first part is Dan Licata's trick. We<br>
implement the<br>
>> hpropositional<br>
>> truncation of ∥ X ∥ as X itself, or rather its<br>
>> isomorphic<br>
>> copy ∥ X<br>
>> ∥',<br>
>> which is kept private to the module:<br>
>><br>
>> \begin{code}<br>
>><br>
>> private<br>
>> data ∥_∥' (X : Set) : Set where<br>
>> ∣_∣' : X → ∥ X ∥'<br>
>><br>
>> ∥_∥ : Set → Set<br>
>> ∥_∥ = ∥_∥'<br>
>><br>
>> ∣_∣ : {X : Set} → X → ∥ X ∥<br>
>> ∣_∣ = ∣_∣'<br>
>><br>
>> hprop : Set → Set<br>
>> hprop X = (x y : X) → x ≡ y<br>
>><br>
>> truncation-rec : {X P : Set} → hprop P → (X → P) →<br>
>> ∥ X ∥ → P<br>
>> truncation-rec _ f ∣ x ∣' = f x<br>
>><br>
>> truncation-ind : {X : Set} {P : ∥ X ∥ → Set} → ((h<br>
>> : ∥ X ∥)<br>
>> → hprop(P h)) → ((x : X) → P ∣ x<br>
>> ∣) → (h : ∥ X<br>
>> ∥) → P h<br>
>> truncation-ind _ f ∣ x ∣' = f x<br>
>><br>
>> \end{code}<br>
>><br>
>> The above -rec and -ind are the non-dependent and<br>
>> dependent<br>
>> elimination rules respectively.<br>
>><br>
>> The crucial requirement is that ∥ X ∥ is to be an<br>
>> hproposition. We can<br>
>> achieve this with a postulate, but postulates don't<br>
>> compute.<br>
>> To try to<br>
>> get an implementation that fully computes, we<br>
>> privately use<br>
>> the above<br>
>> generally unsound feature:<br>
>><br>
>> \begin{code}<br>
>><br>
>> truncation-is-hprop : {X : Set} → hprop ∥ X ∥<br>
>> truncation-is-hprop _ _ = primTrustMe<br>
>><br>
>> \end{code}<br>
>><br>
>> Is that sound? The semantics of primTrustMe is not<br>
>> clearly<br>
>> given in<br>
>> the documentation.<br>
>><br>
>> NB. Of course, we can make one parameter of the<br>
>> elimination rule<br>
>> computationally irrelevant:<br>
>><br>
>> \begin{code}<br>
>><br>
>> Truncation-elim' : {X P : Set} → .(hprop P) → (X →<br>
>> P) → ∥ X ∥<br>
>> → P<br>
>> Truncation-elim' _ f ∣ x ∣' = f x<br>
>><br>
>> Truncation-elim : {X : Set} {P : ∥ X ∥ → Set} →<br>
>> .((h : ∥ X ∥)<br>
>> → hprop(P h)) → ((x : X) → P ∣ x ∣) → (h : ∥ X<br>
∥) → P h<br>
>> Truncation-elim _ f ∣ x ∣' = f x<br>
>><br>
>> \end{code}<br>
>> ______________________________<u></u>_____________________<br>
>><br>
>> Agda mailing list<br>
>> <a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>><br>
<mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>>><br>
>> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><br>
<mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><br>
<mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>>>__><br>
>> <a href="https://lists.chalmers.se/____mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/____<u></u>mailman/listinfo/agda</a><br>
>> <<a href="https://lists.chalmers.se/__mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/__<u></u>mailman/listinfo/agda</a>><br>
>> <<a href="https://lists.chalmers.se/__mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/__<u></u>mailman/listinfo/agda</a><br>
>> <<a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/<u></u>mailman/listinfo/agda</a>>><br>
>><br>
>><br>
>> ______________________________<u></u>_____________________<br>
>><br>
>> Agda mailing list<br>
>> <a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>><br>
<mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>>><br>
>> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><br>
<mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><br>
<mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>>>__><br>
>> <a href="https://lists.chalmers.se/____mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/____<u></u>mailman/listinfo/agda</a><br>
>> <<a href="https://lists.chalmers.se/__mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/__<u></u>mailman/listinfo/agda</a>><br>
>><br>
>> <<a href="https://lists.chalmers.se/__mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/__<u></u>mailman/listinfo/agda</a><br>
>> <<a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/<u></u>mailman/listinfo/agda</a>>><br>
>><br>
>> ______________________________<u></u>___________________<br>
>> Agda mailing list<br>
>> <a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>><br>
<mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>>><br>
>> <a href="https://lists.chalmers.se/__mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/__<u></u>mailman/listinfo/agda</a><br>
>> <<a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/<u></u>mailman/listinfo/agda</a>><br>
>><br>
> ______________________________<u></u>_________________<br>
> Agda mailing list<br>
> <a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a> <mailto:<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><u></u>><br>
> <a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/<u></u>mailman/listinfo/agda</a><br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
Agda mailing list<br>
<a href="mailto:Agda@lists.chalmers.se" target="_blank">Agda@lists.chalmers.se</a><br>
<a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/<u></u>mailman/listinfo/agda</a><br>
</blockquote></div>