Carview!

CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 cross-origin-resource-policy: cross-origin etag: W/"f0b033312542da7593ac596518934a25c05eeffcabc3b21278834f8fa5bc3850" date: Fri, 16 Jan 2026 01:52:07 GMT content-type: application/atom+xml; charset=UTF-8 server: blogger-renderd expires: Fri, 16 Jan 2026 01:52:08 GMT cache-control: public, must-revalidate, proxy-revalidate, max-age=1 x-content-type-options: nosniff x-xss-protection: 0 last-modified: Wed, 13 Mar 2024 16:33:09 GMT content-encoding: gzip content-length: 4293 x-frame-options: SAMEORIGIN alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 tag:blogger.com,1999:blog-329224622024-03-13T16:33:09.075+00:00Setoids and CatsRobinhttps://www.blogger.com/profile/05420921538604886480noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-32922462.post-1156272784004201462006-08-22T19:35:00.000+01:002006-08-22T19:53:04.016+01:00Formalising a High-Performance MicrokernelThese guys have made a prototype of an embedded OS microkernel in Haskell (which they then attached to an ARM CPU simulator so that it could execute programs), "verified the API design" by translating the Haskell implementation into Isabelle/HOL (a formal proof assistant), and then actually implemented the microkernel in C. Cool stuff! <blockquote><div class="head"> <h2>Formalising a High-Performance Microkernel</h2> <div class="authors"> <a href="https://www.cse.unsw.edu.au/%7Ekevine/">Kevin Elphinstone</a>, <a href="https://www.doclsf.de/index.html">Gerwin Klein</a> and <a href="https://www.cse.unsw.edu.au/%7Erafalk/">Rafal Kolanski</a> </div> </div> <h2>Abstract</h2> <div class="abstract"> This paper argues that a pragmatic approach is needed for integrating design and formalisation of complex systems. We report on our approach to designing the seL4 operating system microkernel API and its formalisation in Isabelle/HOL. The formalisation consists of the systematic translation of significant parts of the functional programming language Haskell into Isabelle/HOL, including monad-based code. We give an account of the experience, decisions and outcomes in this translation as well as the technical problems we encountered together with our solutions. The longer-term goal is to demonstrate that formalisation and verification of a large, complex, OS-level code base is feasible with current tools and methods and is in the order of magnitude of traditional development cost. </div> <h2>Online Copy</h2> <div class="download"> Available as <a href="https://www.doclsf.de/papers/vstte06.pdf">[PDF]</a> </div> </blockquote>Robinhttps://www.blogger.com/profile/05420921538604886480noreply@blogger.com0tag:blogger.com,1999:blog-32922462.post-1155934525289558672006-08-18T21:54:00.000+01:002006-08-18T23:27:45.323+01:00Types-as-values suggest setoids-as-metatypesIn this blog, I will be (to start with, at least) mainly talking about my work on simulating dependent types in <a href="https://www.haskell.org/">Haskell</a>, and using these simulated dependent types to prove theorems and to prove properties of code. Genuine dependent types (as in, e.g., <a href="https://pvs.csl.sri.com/">PVS</a>) refer to one or more values. Since Haskell does not allow mixing of types and values, it is not possible to have genuine dependent types in Haskell; however, we can simulate them. The basic idea is to "lift" individual values to the type level - something like this, for example (this code snippet uses a Glasgow extension to Haskell - hence the compiler options pragma): {-# OPTIONS_GHC -fglasgow-exts #-} -- Zero exists data Zero = Zero -- The successor of n exists iff n is a natural number data Succ n = Succ (Nat n) data Nat n where -- Zero is a natural number   NatZero :: Nat Zero -- If m is a natural number, then so is its successor   NatSucc :: Nat m -> Nat (Succ m) Because Zero and Succ Zero and so on are type-level representations of values (in particular, the values 0 and 1) I call them metaterms. Because Nat is a type constructor that classifies metaterms, I call it a metatype. So terms are "lifted" to metaterms, and types are "lifted" to metatypes, in my approach. However, the approach I'm following is a little more complicated than the code sample shown above. The reason why has to do with equality (a thorny topic that I'll be elaborating on in my next post). I initially thought that it would be sufficient to treat metaterms of most metatypes as equal iff their representations as Haskell types were treated as identical by the compiler. Clearly, a metaterm such as Succ (Succ Zero) should be treated as equal only to itself, I thought. However, there is one clear exception which doesn't fit this pattern, which I encountered early on: functions. As a <a href="https://en.wikipedia.org/wiki/Formal_methods">formal methods</a> person, I would like to be able to specify arbitrary <a href="https://en.wikipedia.org/wiki/Postcondition">postconditions</a> of functions. However, a typical postcondition - because it is just a <a href="https://en.wikipedia.org/wiki/Relation_%28mathematics%29">relation</a> between the inputs and outputs of a function - can be constructed in many different, equivalent ways. We would like to be able to abstract away from the particular representation of postconditions, and consider two postconditions to be equal iff they represent "the same" relation between inputs and outputs. When are two relations the same? If we model a relation as a set of tuples, we can consider two relations to be the same if they are modelled by the same set. However, we have to be careful about the definition of equality used for the elements of the tuples. The relation might, for example, be between two functions - in which case we would want to consider a function with a postcondition of "f(x) == 2x" as equal to a function with a postcondition of "f(x) == x+x". In other words, when considering equality of higher-order functions, we need to apply our notion of equality recursively to postconditions. So my next idea was to create a <a href="https://en.wikibooks.org/wiki/Haskell/GADT">generalised abstract data type</a> for equality, with two branches: one for ordinary, "identical type-level representation" equality, and one for equality of functions. You would use this GADT, which I called Equiv, as a universal equality relation. Of course, this hack wasn't good enough. It quickly became evident that the problem I had with functions carried over to many other data types - functors, categories, etc. So what to do? It wouldn't be modular to require developers to just add a new branch to Equiv whenever they wanted a custom equality relation defined over a new metatype. How ugly, and how unworkable - existing code would have to be updated every time a new branch was added, and it would expose irrelevant details to the whole system. My solution was to mandate that every metatype in my system was to represent a setoid of values. A setoid is simply a set together with an equivalence relation defined over that set. This way, every metatype carries around with it a definition of the precise conditions that need to be satisfied in order for two metaterms of that metatype to be considered equivalent. And in what I think is a nice piece of syntactic hackery (made possible by Haskell's ability to define not just operators on values, but also type operators), the notion of reflexivity: a a1 a1 -- "a1 is equal to a1 under the equivalence relation given by a" is quite literally equated with the meta-typing relation I have created ::* a1 ::* a -- "a1 is of (meta)type a" This is because the definition of ::* is a type synonym that looks like this (after expanding macros): type (::*) (a1 :: *) (r :: * -> * -> *) = r a1 a1 This does not cause any problems, because by definition, a value is equal to itself under the equivalence relation of the setoid iff the value is a member of the setoid. As a happy consequence, we don't need to state, and nor do we need to prove, the reflexivity law for equality relations - because it is true for all setoids by definition! However, my problems with equality weren't over - of which more next time.Robinhttps://www.blogger.com/profile/05420921538604886480noreply@blogger.com0

Original Source | Taken Source