How can I use logical operators like AND, OR, NOT in CIL ?
There are no CIL opcodes for those operators; you need to implement them via conditional branching instead. For instance, a && b is the same as a ? b : false, and a || b is the same as a ? true : b, both of which are relatively easy to implement in IL (e.g. you can use the brtrue opcode to do a conditional jump based on the value of a).
Related
I am new to Coq. I noticed it was possible to define the empty set in Coq using
Inductive Empty_set : Set :=.
Is it also possible to define the function from the empty set to another general set/type ?
If so how ?
Yes. Just use pattern matching:
Definition of_Empty_set T (x : Empty_set) : T :=
match x with end.
Think about a function which accepts a Set, and returns its byte length, named byteLength:
byteLength : Set -> Maybe Nat
and if I want to implement this function directly, I need to pattern match on the type argument:
byteLength Char = Just 1
byteLength Double = Just 8
byteLength _ = Nothing
but the above code doesn't compile since pattern matching on Set/Type is not allowed.
so we have to define an Interface as a workaround
Interface ByteLength a where
byteLength : Nat
implement ByteLength Char where
byteLength = 1
and in a more general way, maybe we can use something like TypeRep to do the similar thing and pattern match on TypeRep. but TypeRep is also defined as an Interface.
I think using Interface and using forall is very different, since Interface means "for some types", and forall means "for all types".
I'm wondering Why these DT languages don't support pattern matching on Set/Type, is there some special reason which I don't know?
In Agda, Idris, Haskell, and many other languages quantification over types is parametric (as opposed to ad-hoc polymorphism where you are allowed to match on types). From an implementation point of view, this means the compiler can erase all types from the program, since a functions can never computationally depend on an argument of type Set. Being able to erase types is especially important in dependently typed languages since types can often become huge expressions.
From a more theoretical point of view, parametric polymorphism is nice because it allows us to deduce certain properties of a function by just looking at its type, described eloquently as "free theorems" by Phil Wadler. I could try to give you the gist of the paper, but you should really just go and read it instead.
Of course, sometimes ad-hoc polymorphism is required to implement a function, which is why Haskell and Idris have type classes (Agda has a similar feature called instance arguments, and Coq has canonical structures as well as type classes). For example, in Agda you can define a record like this:
record ByteLength (A : Set) : Set where
field
theByteLength : Nat
open ByteLength
byteLength : (A : Set) {{_ : ByteLength A}} -> Nat
byteLength A {{bl}} = bl .theByteLength
and then you can define the byteLength function for various types by defining instances:
instance
byteLengthChar : ByteLength Char
byteLengthChar .theByteLength = 1
byteLengthDouble : ByteLength Double
byteLengthDouble .theByteLength = 8
With this code, byteLength Char evaluates to 1 and byteLength Double evaluates to 8, while it will raise a type error for any other type.
Say I want to check
"A does not equal any of the following: A, B, C"
I could write my condition as
A != ALL('{A, B, C})`
I could also write it as
A != A and A != B and A != C
I know I'm not really using types correctly here (mostly for brevity) but the idea should be clear. Is one of these faster than the other? I'm not sure how to test these kind of things on databases yet :(
Both versions should produce the same execution plan, but if you want to get rid of the subjunctive in that sentence, you should check yourself using EXPLAIN.
By the way, I recommend that you use the SQL standard operator <> rather than !=.
How can I make a dependently typed functor (for lack of a better term) ? I want to do something like the following:
Module Type Element.
...
End Element.
Module Wrapper (E : Element).
...
End Wrapper.
Module DepentlyTypedFunctor (E : Element) (W : Wrapper E).
...
End DepentlyTypedFunctor.
The last definition doesn't work, and I guess I'm looking for the correct syntax, if possible at all. My motivation for this kind of definition is to define theorems inside DependentlyTypedFunctor that work for all Wrappers that contain any instance of Element, similar to how one could define a theorem for vectors, forall (E : Element) (W : Wrapper E), some_proposition E W.
I think you just meant to make Wrapper a Module Type. If it's not a module type, there's only one such module and you can just write DependentlyTypedFunctor over E. This might not be sufficient if you have opaque implementations of Element, though, in which case different instantiations of Wrapper might not be equal to each other.
If this is a problem, you might just want to use records instead of modules.
I'm still puzzled what the sort Set means in Coq. When do I use Set and when do I use Type?
In Hott a Set is defined as a type, where identity proofs are unique.
But I think in Coq it has a different interpretation.
Set means rather different things in Coq and HoTT.
In Coq, every object has a type, including types themselves. Types of types are usually referred to as sorts, kinds or universes. In Coq, the (computationally relevant) universes are Set, and Type_i, where i ranges over natural numbers (0, 1, 2, 3, ...). We have the following inclusions:
Set <= Type_0 <= Type_1 <= Type_2 <= ...
These universes are typed as follows:
Set : Type_i for any i
Type_i : Type_j for any i < j
Like in Hott, this stratification is needed to ensure logical consistency. As Antal pointed out, Set behaves mostly like the smallest Type, with one exception: it can be made impredicative when you invoke coqtop with the -impredicative-set option. Concretely, this means that forall X : Set, A is of type Set whenever A is. In contrast, forall X : Type_i, A is of type Type_(i + 1), even when A has type Type_i.
The reason for this difference is that, due to logical paradoxes, only the lowest level of such a hierarchy can be made impredicative. You may then wonder then why Set is not made impredicative by default. This is because an impredicative Set is inconsistent with a strong form of the axiom of the excluded middle:
forall P : Prop, {P} + {~ P}.
What this axiom allows you to do is to write functions that can decide arbitrary propositions. Note that the {P} + {~ P} type lives in Set, and not Prop. The usual form of the excluded middle, forall P : Prop, P \/ ~ P, cannot be used in the same way, because things that live in Prop cannot be used in a computationally relevant way.
In addition to Arthur's answer:
From the fact that Set is located at the bottom of the hierarchy,
it follows that Set is the type of the “small” datatypes and function types, i.e. the ones whose values do not directly or indirectly involve types.
That means the following will fail:
Fail Inductive Ts : Set :=
| constrS : Set -> Ts.
with this error message:
Large non-propositional inductive types must be in Type.
As the message suggests, we can amend it by using Type:
Inductive Tt : Type :=
| constrT : Set -> Tt.
Reference:
The Essence of Coq as a Formal System by B. Jacobs (2013), pdf.