Type hierarchy definition in Isabelle -
i build kind of type hierarchy in isabelle:
b of type ( b::a ) c , d of type of b (c,d ::b) e , f of type of c (e,f ::c)
what best way encode in isabelle? there direct way define hierarchy, or need workaround. should look?
ps: suppose a..f abstract , functions defined on each type)
thanks
(1st note: in opinion, you've been using it, word "abstract" doesn't have clear meaning. isabelle keywords used define types can used define, see it, either abstract or concrete types, or types can considered both, such 'a list
.)
(2nd note: here, take consideration comparisons, in other questions, object-oriented programming. programming languages , languages of logic, should noted, mere observer.)
terms have types, , types have types (or sorts, say)
for myself, becomes big blur, , in mind stop differentiating between terms , types, answers such rene thiemann's bring mind.
still, not knowing much, can consider phrase "type hierarchy" synonymous "type class hierarchy", , further synonymous "sort hierarchy". allows me happily provide answer question, though acceptance others precarious.
of course, in isabelle vocabulary, types , sorts aren't synonymous, in isabelle/hol, inseparable because every hol term has sort. (a dangerous claim, since type prop
used in hol, , maybe still don't understand empty sort is.):
- section 3.3.4 type classes, sorts , arities, page 54
- isabelle.in.tum.de/website-isabelle2014/dist/isabelle2014/doc/isar-ref.pdf#page.54
- the difference between empty sort ,
'a::type
- stackoverflow.com/questions/25811989/whats-the-difference-between-the-empty-sort-a-and-a-sort-of-type-a
inheritance, isabelle's got it
it's through locales isabelle provides inheritance (among other ways?), type class (or includes), among other things, locale:
- section 3 type classes locales, page 7, classes.pdf
- section 3 import, page 5, locales.pdf
- quote: "with locales, kind of inheritance achieved through import of locales".
- http://isabelle.in.tum.de/website-isabelle2014/dist/isabelle2014/doc/locales.pdf#page.5
i create 5 type classes meet requirements, @ least simplistically. each 1 has own identity function. +
symbol the magical inheritance symbol.
declare [[show_sorts, show_consts]] (*the 5 type classes.*) class ca = fixes ida :: "'a => 'a" assumes ida_is_id: "ida x = x" class cb = ca + fixes idb :: "'a => 'a" assumes idb_is_id: "idb x = x" class cc = cb + fixes idc :: "'a => 'a" assumes idc_is_id: "idc x = x" class cd = cb + fixes idd :: "'a => 'a" assumes idd_is_id: "idd x = x" class ce = cc + fixes ide :: "'a => 'a" assumes ide_is_id: "ide x = x" class cf = cc + fixes idf :: "'a => 'a" assumes idf_is_id: "idf x = x"
it works:
(*any of type class cb, cc, cd, , cf can used ca can used.*) term "ida (x::'a::ca)" term "ida (x::'a::cb)" term "ida (x::'a::cc)" term "ida (x::'a::cd)" term "ida (x::'a::ce)" term "ida (x::'a::cf)"
more examples of inheritance:
(*use of idc shows ce inherited of what's in cc.*) term "idc :: ('a::cc => 'a::cc)" term "idc :: ('a::ce => 'a::ce)" term "idc (x::'a::ce)" (*but here, there's type sort clash, because cc didn't inherit ce. *) term "ide :: ('a::cc) => ('a::cc)"
now, add concreteness instantiating nat
type class cf
:
(*it took me on hour see using 'ida_ca' instead of 'ida_nat'. 99% of battle can learning syntax.*) instantiation nat :: "{cf}" begin definition ida_nat :: "nat => nat" "ida_nat == id" definition idb_nat :: "nat => nat" "idb_nat == id" definition idc_nat :: "nat => nat" "idc_nat == id" definition idf_nat :: "nat => nat" "idf_nat == id" instance (*proof. use 'proof' , see 4 subgoals: need 4 id functions.*) by(default, auto simp add: ida_nat_def idb_nat_def idc_nat_def idf_nat_def) end (*when instantiated nat cf, had instantiate nat ca, cb, , cc, because had not done so. normally, adding useful 'fixes' , 'assumes' each type class, , proving useful theorems them.*) value "ida (0::nat)" value "idb (0::nat)" value "idc (0::nat)" value "idf (0::nat)" (*you have show type satisfies of 'fixes' , 'assumes' of type class. additional proved theorems, free. that's great benefit of type classes. may have 20 types instantiate type class, have prove 'extraneous' theorems once, being type class, based on 'fixes' , 'assumes' (and other things defined other keywords).*)
i still try, periodically, learn how use isabelle vocabulary correctly. so, looking @ keyword subclass
:
subclass
, page 97 isar-ref.pdf- isabelle.in.tum.de/website-isabelle2014/dist/isabelle2014/doc/isar-ref.pdf#page.97
i might prove cf
subclass of ca
, make point:
context cf begin subclass ca .. end
is ca
subclass of cf
or vice-versa? well, wouldn't have committed if hadn't of replaced c
, d
in definition subclass in isar-ref.pdf, find out.
it's not object-oriented classes, c++ doesn't compare ml functional programming
the nature of being exposed languages, whether logic or programming, find out none of them give everything, , end wanting of them give separately.
you may able define objects in c++ easily, try define algebraic data types in c++.
you kind of can:
- wiki algebraic data type
- en.wikipedia.org/wiki/algebraic_data_type
- open , efficient type switch c++
- parasol.tamu.edu/~yuriys/pm/
but it's not ridiculously easy isabelle/hol, similar haskell, , pattern matching abilities of workarounds i've tried not close.
but, hey, i'm eventual convergence of these things want.
Comments
Post a Comment