[Agda] Absurd question
sanzhiyan at gmail.com
Fri May 24 16:02:00 CEST 2013
Not an implementor, but I'll add my explanation.
On Fri, May 24, 2013 at 12:37 AM, Martin Escardo <m.escardo at cs.bham.ac.uk>wrote:
> However, my first, original, definition of y:Y was
> y : Y
> y ()
That's the same as desugaring the \() manually, hence it'll get the same
In general functions defined by pattern matching, including absurd ones,
are compared by name like lambda-bound variables would. Being defined with
the same structure doesn't matter.
> If you replace that in the link I give below, the Agda file still
> type-checks. But we still have the problem I mentioned, that a definition
> of something using \() type checks, but its uses don't, unless \() is
> replaced by y.
Its use won't typecheck because you are trying to use a theorem that talks
about y to prove something about a definition using \() and they are not
equal because they are not compared structurally. It's more surprising for
the case where you use \() in both places, but each use of \() gets
desugared into its own definition so each one gets a distinct "name".
> BTW, Agda has a lot of "eta expansion" I mentioned in a previous message.
> You seem to be saying that my problem is a lack of absurd eta. But I am
> saying I don't necessarily see this as the problem. Further clarification
> by the Agda implementors would be really appreciated here.
Indeed, a more structural equality for pattern-matching definitions, like
in PiSigma , should also solve this, as proposed in another thread 
about the same problem, but in the context of coinduction.
>> 2013/5/23 Martin Escardo <m.escardo at cs.bham.ac.uk>:
>>> I have a problem with absurdity in Agda, which I can solve in an
>>> way, which forces me to change several definitions.
>>> I would like to both understand what the problem is, and why the
>>> way doesn't work.
>>> I have three types X,Y,Z, whose definition I omit here. I can define,
>>> absurd patterns,
>>> x : X
>>> x = \a ()
>>> y : Y
>>> y : \()
>>> z : Z
>>> z : \()
>>> These are types which have a parameter n:N that happens to be zero and so
>>> they trivialize in this special case, as they have occurrences of Fin n
>>> their definitions.
>>> Now I have three holes in a definition (of a fourth type), reported to
>>> types X,Y,Z. I can fill the holes with x,y,z, and the definition
>>> But if I instead fill the holes with \a (), \(), and \(), expanding the
>>> definitions of x,y,z, then type-checking fails.
>>> Moreover, if just one of the three holes is filled with the corresponding
>>> term, type checking still fails.
>>> Additionally, if I ask the emacs interface to fill the wholes with
>>> this succeeds, with expressions containing the string "absurd". But then
>>> resulting expression doesn't type check.
>>> And there is a more annoying fact. I have previous definition of
>>> else that uses \() and does type check. However, when I use it, things
>>> I instead need to use the same definition with replaced \() by y.
>>> This is very mysterious to me.
>>> I didn't manage to distil a simple instance of this to reproduce here.
>>> if you are brave enough, you can search for "AGDA PROBLEM" in any of the
>>> following links:
>>> Help is appreciated.
>>> Agda mailing list
>>> Agda at lists.chalmers.se
> Martin Escardo
> Agda mailing list
> Agda at lists.chalmers.se
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Agda