2020-05-18 15:59:07 +03:00
|
|
|
module Builtin
|
|
|
|
|
|
|
|
-- The most primitive data types; things which are used by desugaring
|
|
|
|
|
|
|
|
-- Totality assertions
|
|
|
|
|
|
|
|
||| Assert to the totality checker that the given expression will always
|
|
|
|
||| terminate.
|
2020-06-01 22:37:28 +03:00
|
|
|
|||
|
|
|
|
||| The multiplicity of its argument is 1, so `assert_total` won't affect how
|
|
|
|
||| many times variables are used. If you're not writing a linear function,
|
|
|
|
||| this doesn't make a difference.
|
|
|
|
|||
|
2020-05-24 21:13:24 +03:00
|
|
|
||| Note: assert_total can reduce at compile time, if required for unification,
|
|
|
|
||| which might mean that it's no longer guarded a subexpression. Therefore,
|
|
|
|
||| it is best to use it around the smallest possible subexpression.
|
2020-05-18 15:59:07 +03:00
|
|
|
%inline
|
|
|
|
public export
|
2020-05-31 20:24:48 +03:00
|
|
|
assert_total : (1 _ : a) -> a
|
2020-05-18 15:59:07 +03:00
|
|
|
assert_total x = x
|
|
|
|
|
|
|
|
||| Assert to the totality checker that y is always structurally smaller than x
|
|
|
|
||| (which is typically a pattern argument, and *must* be in normal form for
|
|
|
|
||| this to work).
|
2020-06-01 22:37:28 +03:00
|
|
|
|||
|
|
|
|
||| The multiplicity of x is 0, so in a linear function, you can pass values to
|
|
|
|
||| x even if they have already been used.
|
|
|
|
||| The multiplicity of y is 1, so `assert_smaller` won't affect how many times
|
|
|
|
||| its y argument is used.
|
|
|
|
||| If you're not writing a linear function, the multiplicities don't make a
|
|
|
|
||| difference.
|
|
|
|
|||
|
2020-05-18 15:59:07 +03:00
|
|
|
||| @ x the larger value (typically a pattern argument)
|
|
|
|
||| @ y the smaller value (typically an argument to a recursive call)
|
|
|
|
%inline
|
|
|
|
public export
|
2020-05-31 20:24:48 +03:00
|
|
|
assert_smaller : (0 x : a) -> (1 y : b) -> b
|
2020-05-18 15:59:07 +03:00
|
|
|
assert_smaller x y = y
|
|
|
|
|
|
|
|
-- Unit type and pairs
|
|
|
|
|
|
|
|
||| The canonical single-element type, also known as the trivially true
|
|
|
|
||| proposition.
|
|
|
|
public export
|
|
|
|
data Unit =
|
|
|
|
||| The trivial constructor for `()`.
|
|
|
|
MkUnit
|
|
|
|
|
|
|
|
||| The non-dependent pair type, also known as conjunction.
|
|
|
|
public export
|
|
|
|
data Pair : Type -> Type -> Type where
|
|
|
|
||| A pair of elements.
|
|
|
|
||| @ a the left element of the pair
|
|
|
|
||| @ b the right element of the pair
|
Remove linearity subtyping
It's disappointing to have to do this, but I think necessary because
various issue reports have shown it to be unsound (at least as far as
inference goes) and, at the very least, confusing. This patch brings us
back to the basic rules of QTT.
On the one hand, this makes the 1 multiplicity less useful, because it
means we can't flag arguments as being used exactly once which would be
useful for optimisation purposes as well as precision in the type. On
the other hand, it removes some complexity (and a hack) from
unification, and has the advantage of being correct! Also, I still
consider the 1 multiplicity an experiment.
We can still do interesting things like protocol state tracking, which
is my primary motivation at least.
Ideally, if the 1 multiplicity is going to be more generall useful,
we'll need some kind of way of doing multiplicity polymorphism in the
future. I don't think subtyping is the way (I've pretty much always come
to regret adding some form of subtyping).
Fixes #73 (and maybe some others).
2020-12-27 22:58:35 +03:00
|
|
|
MkPair : {0 a, b : Type} -> (x : a) -> (y : b) -> Pair a b
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
||| Return the first element of a pair.
|
|
|
|
public export
|
|
|
|
fst : {0 a, b : Type} -> (a, b) -> a
|
|
|
|
fst (x, y) = x
|
|
|
|
|
|
|
|
||| Return the second element of a pair.
|
|
|
|
public export
|
|
|
|
snd : {0 a, b : Type} -> (a, b) -> b
|
|
|
|
snd (x, y) = y
|
|
|
|
|
|
|
|
-- This directive tells auto implicit search what to use to look inside pairs
|
|
|
|
%pair Pair fst snd
|
|
|
|
|
2020-06-12 13:18:12 +03:00
|
|
|
infix 5 #
|
|
|
|
|
Remove linearity subtyping
It's disappointing to have to do this, but I think necessary because
various issue reports have shown it to be unsound (at least as far as
inference goes) and, at the very least, confusing. This patch brings us
back to the basic rules of QTT.
On the one hand, this makes the 1 multiplicity less useful, because it
means we can't flag arguments as being used exactly once which would be
useful for optimisation purposes as well as precision in the type. On
the other hand, it removes some complexity (and a hack) from
unification, and has the advantage of being correct! Also, I still
consider the 1 multiplicity an experiment.
We can still do interesting things like protocol state tracking, which
is my primary motivation at least.
Ideally, if the 1 multiplicity is going to be more generall useful,
we'll need some kind of way of doing multiplicity polymorphism in the
future. I don't think subtyping is the way (I've pretty much always come
to regret adding some form of subtyping).
Fixes #73 (and maybe some others).
2020-12-27 22:58:35 +03:00
|
|
|
||| A pair type where each component is linear
|
2020-06-12 13:18:12 +03:00
|
|
|
public export
|
|
|
|
data LPair : Type -> Type -> Type where
|
Remove linearity subtyping
It's disappointing to have to do this, but I think necessary because
various issue reports have shown it to be unsound (at least as far as
inference goes) and, at the very least, confusing. This patch brings us
back to the basic rules of QTT.
On the one hand, this makes the 1 multiplicity less useful, because it
means we can't flag arguments as being used exactly once which would be
useful for optimisation purposes as well as precision in the type. On
the other hand, it removes some complexity (and a hack) from
unification, and has the advantage of being correct! Also, I still
consider the 1 multiplicity an experiment.
We can still do interesting things like protocol state tracking, which
is my primary motivation at least.
Ideally, if the 1 multiplicity is going to be more generall useful,
we'll need some kind of way of doing multiplicity polymorphism in the
future. I don't think subtyping is the way (I've pretty much always come
to regret adding some form of subtyping).
Fixes #73 (and maybe some others).
2020-12-27 22:58:35 +03:00
|
|
|
(#) : (1 _ : a) -> (1 _ : b) -> LPair a b
|
2020-06-12 13:18:12 +03:00
|
|
|
|
2020-05-18 15:59:07 +03:00
|
|
|
namespace DPair
|
2020-06-12 13:18:12 +03:00
|
|
|
||| Dependent pairs aid in the construction of dependent types by providing
|
|
|
|
||| evidence that some value resides in the type.
|
|
|
|
|||
|
|
|
|
||| Formally, speaking, dependent pairs represent existential quantification -
|
|
|
|
||| they consist of a witness for the existential claim and a proof that the
|
|
|
|
||| property holds for it.
|
|
|
|
|||
|
|
|
|
||| @ a the value to place in the type.
|
|
|
|
||| @ p the dependent type that requires the value.
|
2020-05-18 15:59:07 +03:00
|
|
|
public export
|
|
|
|
record DPair a (p : a -> Type) where
|
|
|
|
constructor MkDPair
|
|
|
|
fst : a
|
|
|
|
snd : p fst
|
|
|
|
|
2020-06-12 13:18:12 +03:00
|
|
|
||| A dependent variant of LPair, pairing a result value with a resource
|
|
|
|
||| that depends on the result value
|
|
|
|
public export
|
|
|
|
data Res : (a : Type) -> (a -> Type) -> Type where
|
|
|
|
(#) : (val : a) -> (1 r : t val) -> Res a t
|
|
|
|
|
2020-05-18 15:59:07 +03:00
|
|
|
-- The empty type
|
|
|
|
|
|
|
|
||| The empty type, also known as the trivially false proposition.
|
|
|
|
|||
|
|
|
|
||| Use `void` or `absurd` to prove anything if you have a variable of type
|
|
|
|
||| `Void` in scope.
|
|
|
|
public export
|
|
|
|
data Void : Type where
|
|
|
|
|
|
|
|
-- Equality
|
|
|
|
|
|
|
|
public export
|
|
|
|
data Equal : forall a, b . a -> b -> Type where
|
2020-07-10 18:01:58 +03:00
|
|
|
[search a b]
|
2020-05-18 15:59:07 +03:00
|
|
|
Refl : {0 x : a} -> Equal x x
|
|
|
|
|
|
|
|
%name Equal prf
|
|
|
|
|
2021-03-29 00:11:05 +03:00
|
|
|
infix 6 ===, ~=~
|
2020-05-18 15:59:07 +03:00
|
|
|
|
|
|
|
-- An equality type for when you want to assert that each side of the
|
|
|
|
-- equality has the same type, but there's not other evidence available
|
|
|
|
-- to help with unification
|
|
|
|
public export
|
|
|
|
(===) : (x : a) -> (y : a) -> Type
|
|
|
|
(===) = Equal
|
|
|
|
|
|
|
|
||| Explicit heterogeneous ("John Major") equality. Use this when Idris
|
|
|
|
||| incorrectly chooses homogeneous equality for `(=)`.
|
|
|
|
||| @ a the type of the left side
|
|
|
|
||| @ b the type of the right side
|
|
|
|
||| @ x the left side
|
|
|
|
||| @ y the right side
|
|
|
|
public export
|
|
|
|
(~=~) : (x : a) -> (y : b) -> Type
|
|
|
|
(~=~) = Equal
|
|
|
|
|
|
|
|
||| Perform substitution in a term according to some equality.
|
|
|
|
|||
|
|
|
|
||| Like `replace`, but with an explicit predicate, and applying the rewrite in
|
|
|
|
||| the other direction, which puts it in a form usable by the `rewrite` tactic
|
|
|
|
||| and term.
|
|
|
|
%inline
|
|
|
|
public export
|
|
|
|
rewrite__impl : {0 x, y : a} -> (0 p : _) ->
|
Remove linearity subtyping
It's disappointing to have to do this, but I think necessary because
various issue reports have shown it to be unsound (at least as far as
inference goes) and, at the very least, confusing. This patch brings us
back to the basic rules of QTT.
On the one hand, this makes the 1 multiplicity less useful, because it
means we can't flag arguments as being used exactly once which would be
useful for optimisation purposes as well as precision in the type. On
the other hand, it removes some complexity (and a hack) from
unification, and has the advantage of being correct! Also, I still
consider the 1 multiplicity an experiment.
We can still do interesting things like protocol state tracking, which
is my primary motivation at least.
Ideally, if the 1 multiplicity is going to be more generall useful,
we'll need some kind of way of doing multiplicity polymorphism in the
future. I don't think subtyping is the way (I've pretty much always come
to regret adding some form of subtyping).
Fixes #73 (and maybe some others).
2020-12-27 22:58:35 +03:00
|
|
|
(0 rule : x = y) -> (val : p y) -> p x
|
2020-05-18 15:59:07 +03:00
|
|
|
rewrite__impl p Refl prf = prf
|
|
|
|
|
|
|
|
%rewrite Equal rewrite__impl
|
|
|
|
|
|
|
|
||| Perform substitution in a term according to some equality.
|
|
|
|
%inline
|
|
|
|
public export
|
|
|
|
replace : forall x, y, p . (0 rule : x = y) -> p x -> p y
|
|
|
|
replace Refl prf = prf
|
|
|
|
|
|
|
|
||| Symmetry of propositional equality.
|
|
|
|
%inline
|
|
|
|
public export
|
|
|
|
sym : (0 rule : x = y) -> y = x
|
|
|
|
sym Refl = Refl
|
|
|
|
|
|
|
|
||| Transitivity of propositional equality.
|
|
|
|
%inline
|
|
|
|
public export
|
|
|
|
trans : forall a, b, c . (0 l : a = b) -> (0 r : b = c) -> a = c
|
|
|
|
trans Refl Refl = Refl
|
|
|
|
|
2020-11-27 18:29:19 +03:00
|
|
|
||| Injectivity of MkDPair (first components)
|
|
|
|
export
|
|
|
|
mkDPairInjectiveFst : MkDPair a pa === MkDPair b qb -> a === b
|
|
|
|
mkDPairInjectiveFst Refl = Refl
|
|
|
|
|
|
|
|
||| Injectivity of MkDPair (snd components)
|
|
|
|
export
|
|
|
|
mkDPairInjectiveSnd : MkDPair a pa === MkDPair a qa -> pa === qa
|
|
|
|
mkDPairInjectiveSnd Refl = Refl
|
|
|
|
|
2020-05-18 15:59:07 +03:00
|
|
|
||| Subvert the type checker. This function is abstract, so it will not reduce
|
|
|
|
||| in the type checker. Use it with care - it can result in segfaults or
|
|
|
|
||| worse!
|
|
|
|
public export
|
|
|
|
believe_me : a -> b
|
|
|
|
believe_me = prim__believe_me _ _
|
|
|
|
|
2020-12-13 19:06:18 +03:00
|
|
|
||| Assert to the usage checker that the given function uses its argument linearly.
|
|
|
|
public export
|
|
|
|
assert_linear : (1 f : a -> b) -> (1 val : a) -> b
|
|
|
|
assert_linear = believe_me id
|
|
|
|
where
|
|
|
|
id : (1 f : a -> b) -> a -> b
|
|
|
|
id f = f
|
|
|
|
|
|
|
|
|
2020-05-18 15:59:07 +03:00
|
|
|
export partial
|
|
|
|
idris_crash : String -> a
|
|
|
|
idris_crash = prim__crash _
|
2020-07-01 13:35:27 +03:00
|
|
|
|
2020-12-06 23:00:48 +03:00
|
|
|
public export %inline
|
2020-07-01 13:35:27 +03:00
|
|
|
delay : a -> Lazy a
|
|
|
|
delay x = Delay x
|
|
|
|
|
2020-12-06 23:00:48 +03:00
|
|
|
public export %inline
|
2020-07-01 13:35:27 +03:00
|
|
|
force : Lazy a -> a
|
|
|
|
force x = Force x
|
2020-07-30 20:40:04 +03:00
|
|
|
|
|
|
|
%stringLit fromString
|
|
|
|
|
|
|
|
||| Interface for types that can be constructed from string literals.
|
|
|
|
public export
|
2020-08-05 02:38:57 +03:00
|
|
|
interface FromString ty where
|
2021-05-06 18:32:51 +03:00
|
|
|
constructor MkFromString
|
2020-07-30 20:40:04 +03:00
|
|
|
||| Conversion from String.
|
|
|
|
fromString : String -> ty
|
|
|
|
|
|
|
|
%allow_overloads fromString
|
|
|
|
|
|
|
|
%inline
|
|
|
|
public export
|
2020-08-05 02:38:57 +03:00
|
|
|
FromString String where
|
2020-07-30 20:40:04 +03:00
|
|
|
fromString s = s
|
|
|
|
|
|
|
|
%defaulthint
|
|
|
|
%inline
|
|
|
|
public export
|
2020-08-05 02:38:57 +03:00
|
|
|
defaultString : FromString String
|
2020-07-30 20:40:04 +03:00
|
|
|
defaultString = %search
|