*To*: Andreas Lochbihler <andreas.lochbihler at kit.edu>*Subject*: Re: [isabelle] Defining Union Types*From*: Christian Sternagel <christian.sternagel at uibk.ac.at>*Date*: Wed, 27 Jul 2011 14:38:01 +0200*Cc*: Christian Sternagel <christian.sternagel at uibk.ac.at>, Tobias Nipkow <nipkow at in.tum.de>, cl-isabelle-users at lists.cam.ac.uk*In-reply-to*: <4E30052D.60308@kit.edu>*References*: <CAAPnxw1oeghO4nx43XsDD4z4X5ZW2D02ejnfK=vLb_JEx=Bz2A@mail.gmail.com> <4E2E53A8.7090705@in.tum.de> <4E2E66A4.2040406@gmail.com> <4E2F1FD5.7020408@in.tum.de> <4E2FF4C6.1030109@uibk.ac.at> <4E30052D.60308@kit.edu>*User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0

On 07/27/2011 02:31 PM, Andreas Lochbihler wrote:

> But what is really needed? Haskell does not offer Projl/r at allbut lefts, rights and paritionEithers.In IsaFoR we use Sum_Type.Projr and Sum_Type.Projl. It would just feel "more official" if you didn't have to use the cumbersome prefix.Sum_Type.Projr and Sum_Type.Projl are the destructor view on datatypes, which are necessarily partial. But most formalisations in Isabelle follow the constructor view and use case expressions for destruction, for which there is a reasonable setup (simp rules, split rules, etc.). For example, (Sum_Type.Projl x) is (almost) equivalent to (case x of Inl y => y) and (Sum_Type.Projr x) to (case x of Inr y => y).A not entirely related idea is the setup of an (executable) error monad using "+" (which is used heavily in IsaFoR for example).I would recommend not to use sum types for such things, but introduce a new type with an error element. This has the advantage that split rules and the like can be applied more precisely. If sum types are used for other notions in a formalisation, too, the general simplification and split rules might slow break down proof automation because they also apply to the other parts.To this end I once tried to setup such a monad to use for partial functions (I was heading towards a parsec-like parser combinator library; side remark: there are not many deep properties I wanted to proof about this combinators, but it is just nice to be able to write also your parser in Isabelle when you use code generation) but failed to complete since different error cases (i.e., Inl's containing different error messages) are not equal. Maybe this could be generalized using some equivalence relation?I suppose that the error messages are irrelevant to the proofs, so they need not be part of the logic. If the error monad is a type constructor of its own (rather than a sum type), you can identify all error cases in the logic and handle the error messages in the code generator only. Here's the idea: datatype 'a err = Error | OK 'a definition Raise_error :: "String.literal => 'a err" where "Raise_error msg = Error" code_datatype Raise_error OK In the logic, all errors are the same "Error" value, but the generated code uses Raise_error as constructor which also stores the error message. Hence, the logical problem with different error messages no longer occurs.

cheers chris

Andreascheers chrisTobias Am 26/07/2011 09:03, schrieb Christian Sternagel:Talking of the sum type... I think it would be good to have it more easily accessible. Currently, e.g., I have to write "Sum_Type.Projr" to get the right projection. As far as I can see it is mainly for internal use of some packages. But something like Haskell's Either would be useful for the library (together with a bunch of useful functions and lemmas). cheers chris On 07/26/2011 07:42 AM, Tobias Nipkow wrote:It is written "+" and defined in theory Sum_Type, which is part of Main. It is hardly advertised because in most cases it is nicer to define your own special datatype. Tobias Am 26/07/2011 03:57, schrieb Alfio Martini:Dear Isabelle Users, Do we have in Isabelle something like a union (sum) type constructor with the corresponding injections? I went through the tutorial and did not find use or reference to it. If there is, can anyone point to an application or a written example of this? I assume there must be a simple way to do it. Many thanks!

**References**:**[isabelle] Defining Union Types***From:*Alfio Martini

**Re: [isabelle] Defining Union Types***From:*Tobias Nipkow

**Re: [isabelle] Defining Union Types***From:*Tobias Nipkow

**Re: [isabelle] Defining Union Types***From:*Christian Sternagel

**Re: [isabelle] Defining Union Types***From:*Andreas Lochbihler

- Previous by Date: Re: [isabelle] Defining Union Types
- Next by Date: Re: [isabelle] Defining Union Types
- Previous by Thread: Re: [isabelle] Defining Union Types
- Next by Thread: Re: [isabelle] Defining Union Types
- Cl-isabelle-users July 2011 archives indexes sorted by: [ thread ] [ subject ] [ author ] [ date ]
- Cl-isabelle-users list archive Table of Contents
- More information about the Cl-isabelle-users mailing list