agda

(As an excuse: the title mimics the title of Why do we need monads? ) There are containers (and indexed ones) (and hasochistic ones) and descriptions . But containers are problematic and to my very small experience it's harder to think in terms of containers than in terms of descriptions. The type of non-indexed containers is isomorphic to Σ — that's quite too unspecific. The shapes-and-positions description helps, but in ⟦_⟧ᶜ : ∀ {α β γ} -> Container α β -> Set γ -> Set (α ⊔ β ⊔ γ) ⟦ Sh ◃ Pos ⟧ᶜ A = ∃ λ sh -> Pos sh -> A Kᶜ : ∀ {α β} -> Set α -> Container α β Kᶜ A = A ◃ const (Lift ⊥) we are

Dependent types are often advertised as a way to enable you to assert that a program is correct up to a specification. So, for example, you are asked to write a code that sorts a list - you are able to prove that code is correct by encoding the notion of "sort" as a type, and writing a function such as List a -> SortedList a . But how do you prove that the specification, SortedList , is correct? Wouldn't it be the case that, the more complex your specification is, the more likely it would be that your encoding of that specification as a type is incorrect? This is the static, type-system

There are two conventions I've found in Coq's SSReflect extension that seem particularly useful but which I haven't seen widely adopted in newer dependently-typed languages (Lean, Agda, Idris). Firstly, where possible predicates are expressed as boolean-returning functions rather than inductively defined datatypes. This brings decidability by default, opens up more opportunities for proof by computation, and improves checking performance by avoiding the need for the proof engine to carry around large proof terms. The main disadvantage I see is the need to use reflection lemmas to manipulate

I've been studying dependent types and I understand the following: Why universal quantification is represented as a dependent function type. ∀(x:A).B(x) means “for all x of type A there is a value of type B(x) ” . Hence it's represented as a function which when given any value x of type A returns a value of type B(x) . Why existential quantification is represented as a dependent pair type. ∃(x:A).B(x) means “there exists an x of type A for which there is a value of type B(x) ” . Hence it's represented as a pair whose first element is a particular value x of type A and whose second element is a

There is an Idris tutorial, an Agda tutorial and many other tutorial style papers and introductory material with never ending references to things yet to learn. I'm kind of crawling in the middle of all these and most of the time I'm stuck with mathematical notations and new terminology appearing suddenly with no explanation. Perhaps my math sucks :-) Is there any disciplined way to approach dependent type programming? Like when you want to learn Haskell, you start with "Teach yourself a Haskell", when you want to learn Scala, you start with Odersky's book, for Ruby you read that weird

I recently completed a university course which featured Haskell and Agda (a dependent typed functional programming language), and was wondering if it was possible to replace lambda calculus in these with combinatory logic. With Haskell this seems possible using the S and K combinators, thus making it point-free. I was wondering what the equivalent was for Agda. I.e., can one make a dependently typed functional programming language equivalent to Agda without using any variables? Also, is it possible to somehow replace quantification with combinators? I don't know if this is a coincidence but

I am trying to write a proof for an equality in results of a function with a HIT domain. Because the function is defined over a HIT, the proof of equality also has to handle path cases. In those cases, Agda reports a ton of constraints on the higher-dimensional path I'm required to construct; for example: Goal: fromList (toList m) ≡ εˡ m i ———————————————————————————————————————————————————————————— i : I m : FreeMonoid A AIsSet : isSet A A : Type ℓ ℓ : Level ———— Constraints ——————————————————————————————————————————— (hcomp (λ { j ((~ i ∨ i) = i1) → (λ { (i = i0) → fromList (toList ε ++

I have defined Stream of positive rational like this. one : ℤ one = + 1 --giving a rational as input it will return next rational (in some down tailing method) next : pair → pair next q = if (n eq one) then (mkPair (+ m Data.Integer.+ one) 1) else (mkPair (n Data.Integer.- one) (m Nat.+ 1)) where n = getX q m = getY q --it will generate all rational from (1,1) rational : Stream pair rational = iterate next (mkPair one 1) --it will get all the rational which are greater than the given rational. RQ : pair → Stream pair → Stream pair RQ q (x ∷ xs) = (x add q) ∷ ♯ (RQ q (♭ xs)) --This is a stream