From andre.scholz at mathematik.tu-chemnitz.de Mon Mar 3 01:23:04 2008 From: andre.scholz at mathematik.tu-chemnitz.de (=?iso-8859-1?q?Andr=E9_Scholz?=) Date: Mon, 3 Mar 2008 01:23:04 +0100 Subject: [Hets-devel] Modularer Aufbau von Ontologien Message-ID: <200803030123.04219.andre.scholz@mathematik.tu-chemnitz.de> Hallo, ich ?bersetze gerade eine Ontologie von OWL-DL nach CASL-DL und bin auf folgendes Problem gesto?en: Ich habe diese Spezifikation: spec S1 = sorts Vehicle < Thing sorts Boat, Car, Plane < Vehicle forall x : Boat . not(x in Car \/ x in Plane) forall x : Car . not(x in Plane) spec S2 = S1 with Car |-> NormalCar then sorts Car < Vehicle sorts NormalCar, SpecialCar < Car forall x : NormalCar . not(x in SpecialCar) Wie gebe ich an, dass SpecialCar (oder das neue Car in S2) disjunkt zu Boat und Plane sind, ohne Boat und Plane explizit angeben zu m?ssen? Mein Ziel ist es, in S1 neue Vehicle-Subsorten angeben zu k?nnen, ohne diese auch in S2 mit angeben zu m?ssen. Sch?ne Gr??e Andr? Scholz P.S.: Ist die devel-Liste oder die user-Liste die richtige Anlaufstelle f?r diese Art Fragen? From Till.Mossakowski at dfki.de Mon Mar 3 10:39:40 2008 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Mon, 03 Mar 2008 10:39:40 +0100 Subject: [Hets-devel] Modularer Aufbau von Ontologien In-Reply-To: <200803030123.04219.andre.scholz@mathematik.tu-chemnitz.de> References: <200803030123.04219.andre.scholz@mathematik.tu-chemnitz.de> Message-ID: <47CBC75C.2070503@dfki.de> Hi Andr?, the right list is hets-users, and both lists are in English (I hope that this is not a problem for you). You want to add new subsorts of Vehicle in S1 and have these automatically disjoint to Car in S2. But Car also is a new subsort of Vehicle (although in S2, not in S1). Hence the subsorts of Boat and Plane of Vehicle in S1 are of a special status; at least, they are different from the subsort Car of Vehicle declared in S2. Hence, you have to make this special status (of "non-car-ness") explicit, say: spec S1 = sorts Vehicle < Thing sorts Boat, Car, Plane < Vehicle sorts NonCar < Vehicle sorts Boat, Plane < NonCar forall x : Boat . not(x in Car \/ x in Plane) forall x : Car . not(x in Plane) spec S2 = S1 with Car |-> NormalCar then sorts Car < Vehicle sorts NormalCar, SpecialCar < Car forall x : NormalCar . not(x in SpecialCar) forall x : Car . not(x in NonCar) Greetings, Till Andr? Scholz schrieb: > Hallo, > > ich ?bersetze gerade eine Ontologie von OWL-DL nach CASL-DL und bin auf > folgendes Problem gesto?en: Ich habe diese Spezifikation: > > spec S1 = > sorts Vehicle < Thing > sorts Boat, Car, Plane < Vehicle > forall x : Boat . not(x in Car \/ x in Plane) > forall x : Car . not(x in Plane) > > spec S2 = S1 with Car |-> NormalCar > then > sorts Car < Vehicle > sorts NormalCar, SpecialCar < Car > forall x : NormalCar . not(x in SpecialCar) > > Wie gebe ich an, dass SpecialCar (oder das neue Car in S2) disjunkt zu Boat > und Plane sind, ohne Boat und Plane explizit angeben zu m?ssen? > Mein Ziel ist es, in S1 neue Vehicle-Subsorten angeben zu k?nnen, ohne diese > auch in S2 mit angeben zu m?ssen. > > Sch?ne Gr??e > Andr? Scholz > > P.S.: Ist die devel-Liste oder die user-Liste die richtige Anlaufstelle f?r > diese Art Fragen? > _______________________________________________ > Hets-devel mailing list > Hets-devel at mailhost.informatik.uni-bremen.de > http://www.informatik.uni-bremen.de/mailman/listinfo/hets-devel > -- Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From Christian.Maeder at dfki.de Mon Mar 3 10:56:45 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 03 Mar 2008 10:56:45 +0100 Subject: [Hets-devel] Modularer Aufbau von Ontologien In-Reply-To: <200803030123.04219.andre.scholz@mathematik.tu-chemnitz.de> References: <200803030123.04219.andre.scholz@mathematik.tu-chemnitz.de> Message-ID: <47CBCB5D.3040003@dfki.de> Andr? Scholz wrote: > Hallo, > > ich ?bersetze gerade eine Ontologie von OWL-DL nach CASL-DL und bin auf > folgendes Problem gesto?en: Ich habe diese Spezifikation: > > spec S1 = > sorts Vehicle < Thing > sorts Boat, Car, Plane < Vehicle > forall x : Boat . not(x in Car \/ x in Plane) > forall x : Car . not(x in Plane) > > spec S2 = S1 with Car |-> NormalCar > then > sorts Car < Vehicle > sorts NormalCar, SpecialCar < Car > forall x : NormalCar . not(x in SpecialCar) > > Wie gebe ich an, dass SpecialCar (oder das neue Car in S2) disjunkt zu Boat > und Plane sind, ohne Boat und Plane explizit angeben zu m?ssen? This looks impossible to me, unless you say in S1 something like: free type NonCars = sort Boat | sort Plane > Mein Ziel ist es, in S1 neue Vehicle-Subsorten angeben zu k?nnen, ohne diese > auch in S2 mit angeben zu m?ssen. (exchange S1 and S2?) I would not add a further subsort to Vehicle, but simply split the sort Car from S1 into two further subsorts NormalCar and SpecialCar > > Sch?ne Gr??e > Andr? Scholz > > P.S.: Ist die devel-Liste oder die user-Liste die richtige Anlaufstelle f?r > diese Art Fragen? Yes, but we have some non-german members. Cheers Christian From glauber.sp at gmail.com Tue Mar 4 19:13:52 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Tue, 4 Mar 2008 15:13:52 -0300 Subject: [Hets-devel] About type errors within subtyping Message-ID: Hi Hets developers. I'm trying to code Haskell Prelude and I've got in trouble with Enum spec and types. I'm not sure if it's a problem with partial functions or with type hierarchy. Before I write down the error, I'd like to know if the specifications from Hets/Hets-lib/HasCASL/ are already verified with Hets and/or proved with Isabelle. When I open List specification with hets, the graph has unproved nodes. If I just import it, nothing unproved appears. I guess this happens because it is just an import and hets assumes the imported specs are already correct. Is this right? If the specs from there are not proved/verified, so I should prove if before writing Prelude? Or I should assume it is correct and later I prove it, when I indeed know more about Hets et al.? Now, the problems I've got... Within the code: ------CODE----------- logic HasCASL from Basic/Numbers get Int from Basic/MachineNumbers get INTEGER |-> FPInt spec INTEGER = FPInt[FPIntInstanciation] spec Enum = Int and List then class Enum { var a: Enum fun successor: a -> a fun predecessor: a -> a fun toEnum: Int -> a fun fromEnum: a -> Int var b: a . successor = toEnum (1 + (fromEnum b)) } ------END OF CODE------- there are rejections of sub typing (if I could understand correctly hets output): ------------ERRORS---------------- ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Int), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Nat), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Pos), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, untypeable term (with type: Nat * Nat) '(1, fromEnum b)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Int), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Pos' of '((op 1 : Int), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Pos' of '((op 1 : Nat), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Pos), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Pos' of '((op 1 : Pos), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, untypeable term (with type: Nat * Pos) '(1, fromEnum b)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Int), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Pos' of '((op 1 : Int), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Nat), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Pos' of '((op 1 : Nat), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Nat < Pos' of '((op 1 : Nat), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, rejected 'Int < Nat' of '((op 1 : Pos), (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, untypeable term (with type: Pos * Nat) '(1, fromEnum b)' *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.24, no constraint resolution for 'successor = toEnum (1 + fromEnum b)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.24, simplification failed for '{a : Enum, _v64_v61_v7_a : Enum, (_v64_v61_v7_a -> _v64_v61_v7_a) : Enum, __->__ < __->?__ }' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.24, simplification failed for '{a : Enum, _v70_v67_v7_a : Enum, (_v70_v67_v7_a -> _v70_v67_v7_a) : Enum, Nat < Int, __->__ < __->?__ }' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.24, simplification failed for '{a : Enum, _v76_v73_v7_a : Enum, (_v76_v73_v7_a -> _v76_v73_v7_a) : Enum, Pos < Int, __->__ < __->?__ }' -----------END OF ERRORS-------------- If I change the definition of successor to: . successor = toEnum (__+__(Int*Int) 1 (fromEnum b)) this errors occur: --------_ERRORS---------------- in type of '(op __+__ : Int * Int -> Int)' typename 'Int' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:176.32) is not unifiable with type '_v12 ->? _v11 ->? Int' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, in type of '(op __+__ : Nat * Nat -> Nat)' typename 'Nat' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:64.27) is not unifiable with type '_v12 ->? _v11 ->? Int' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, in type of '(op __+__ : Nat * Pos -> Pos)' typename 'Pos' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:135.32) is not unifiable with type '_v12 ->? _v11 ->? Int' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, in type of '(op __+__ : Pos * Nat -> Pos)' typename 'Pos' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:134.32) is not unifiable with type '_v12 ->? _v11 ->? Int' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, untypeable term (with type: _v13 ->? _v12 ->? _v11 ->? Int) '__+__' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.47, untypeable term (with type: _v12 ->? _v11 ->? Int) '__+__ (Int * Int)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.49, untypeable term (with type: _v11 ->? Int) '(__+__ (Int * Int)) 1' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.62, untypeable term (with type: Int) '(__+__ (Int * Int)) 1 (fromEnum b)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.14-124.63, untypeable term (with type: ? _v3_a * ? _v3_a) '(successor, toEnum ((__+__ (Int * Int)) 1 (fromEnum b)))' *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.24, no typing for 'successor = toEnum ((__+__ (Int * Int)) 1 (fromEnum b))' -----------END OF ERRORS-------------------- I'd appreciate if anyone can tell me what I'm doing wrong. Sorry by the noob question and the long message, but I could not solve this with the papers I've already read. Thanks in advance, Glauber From Christian.Maeder at dfki.de Tue Mar 4 20:29:56 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue, 04 Mar 2008 20:29:56 +0100 Subject: [Hets-devel] About type errors within subtyping In-Reply-To: References: Message-ID: <47CDA334.1000305@dfki.de> Glauber Cabral wrote: > Hi Hets developers. > > I'm trying to code Haskell Prelude and I've got in trouble with Enum > spec and types. I'm not sure if it's a problem with partial functions > or with type hierarchy. It looks like bad error messages (see below) > Before I write down the error, I'd like to know if the specifications > from Hets/Hets-lib/HasCASL/ are already verified with Hets and/or > proved with Isabelle. the Hets-lib/HasCASL/*.het libraries are only statically checked but not proven. Even Hets-lib/Basic/*.casl are not proven, but they far more stable and have passed some consistency checks. > When I open List specification with hets, the > graph has unproved nodes. If I just import it, nothing unproved > appears. This is odd indeed. We have to look into it. For me the red edge disappears, too, after Edit-Proofs-Automatic (in the spec below). > I guess this happens because it is just an import and hets > assumes the imported specs are already correct. Is this right? No, imported specs are not assumed to be correct. > If the specs from there are not proved/verified, so I should prove if > before writing Prelude? Or I should assume it is correct and later I > prove it, when I indeed know more about Hets et al.? It'll be interesting to proof something at all. Maybe the implications in Hets-lib/HasCASL/List.het are a good start. > Now, the problems I've got... > > Within the code: > > ------CODE----------- > logic HasCASL > > from Basic/Numbers get Int > from Basic/MachineNumbers get INTEGER |-> FPInt > > spec INTEGER = FPInt[FPIntInstanciation] > spec Enum = Int and List then FPIntInstanciation (and List) are unknown specs here > class Enum > { > var a: Enum > fun successor: a -> a > fun predecessor: a -> a > fun toEnum: Int -> a > fun fromEnum: a -> Int > var b: a > . successor = toEnum (1 + (fromEnum b)) The error here is, that "successor" should be applied to "b". Try . successor b = toEnum (1 + (fromEnum b)) > there are rejections of sub typing (if I could understand correctly > hets output): no, certain typings are only rejected because subtypes of overloaded functions don't match, which is no problem if at least one combination type checks. > ------------ERRORS---------------- > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.48, > rejected 'Int < Nat' of '((op 1 : Int), > (fun fromEnum : forall a : Enum . a -> Int) (var b : a))' These hints are not useful here. [...] > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.24, > no constraint resolution for 'successor = toEnum (1 + fromEnum b)' That's the actual error. Somehow the result type of "toEnum" (or "successor") cannot be determined, in particular no result type variable of class (aka constraint) "Enum" can be found. Since "toEnum" is polymorphic, the result type may be different from "a". [...] > -----------END OF ERRORS-------------- > > If I change the definition of successor to: > > . successor = toEnum (__+__(Int*Int) 1 (fromEnum b)) "__+__(Int*Int) 1 (fromEnum b)" is interpreted as "__+__" applied to three argument, although it may only be applied to a tuple. This fails before detecting that "Int" is not a value (that could be multiplied as "Int*Int") So correct is: __+__(1, fromEnum b) or (op __+__ : Int*Int -> Int)(1, fromEnum b) > this errors occur: > > --------_ERRORS---------------- > in type of '(op __+__ : Int * Int -> Int)' > typename 'Int' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:176.32) > is not unifiable with type '_v12 ->? _v11 ->? Int' > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, > in type of '(op __+__ : Nat * Nat -> Nat)' > typename 'Nat' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:64.27) > is not unifiable with type '_v12 ->? _v11 ->? Int' > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, > in type of '(op __+__ : Nat * Pos -> Pos)' > typename 'Pos' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:135.32) > is not unifiable with type '_v12 ->? _v11 ->? Int' > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, > in type of '(op __+__ : Pos * Nat -> Pos)' > typename 'Pos' (/home/glauber/Hets/Hets-lib/Basic/Numbers.casl:134.32) > is not unifiable with type '_v12 ->? _v11 ->? Int' > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.61) The above messages show the possible type of "__+__". > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.36, > untypeable term (with type: _v13 ->? _v12 ->? _v11 ->? Int) '__+__' This is the message, saying that '__+__' cannot be given 3 curried arguments. > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.47, > untypeable term (with type: _v12 ->? _v11 ->? Int) > '__+__ (Int * Int)' > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.49, > untypeable term (with type: _v11 ->? Int) '(__+__ (Int * Int)) 1' > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.34-124.62, > untypeable term (with type: Int) > '(__+__ (Int * Int)) 1 (fromEnum b)' > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.14-124.63, > untypeable term (with type: ? _v3_a * ? _v3_a) > '(successor, toEnum ((__+__ (Int * Int)) 1 (fromEnum b)))' > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:124.24, > no typing for > 'successor = toEnum ((__+__ (Int * Int)) 1 (fromEnum b))' > -----------END OF ERRORS-------------------- > > I'd appreciate if anyone can tell me what I'm doing wrong. > Sorry by the noob question and the long message, but I could not solve > this with the papers I've already read. Well, the error messages for the HasCASL type system are difficult to digest. Cheers Christian from Basic/Numbers get Nat spec FPIntInstanciation = Nat then op WordLength: Nat = 29 logic HasCASL from Basic/Numbers get Int from Basic/MachineNumbers get INTEGER |-> FPInt from HasCASL/List get List spec INTEGER = FPInt[FPIntInstanciation] spec Enum = Int and List then class Enum { var a: Enum fun successor: a -> a fun predecessor: a -> a fun toEnum: Int -> a fun fromEnum: a -> Int var b: a . successor b = toEnum (1 + fromEnum b) } From glauber.sp at gmail.com Tue Mar 4 21:34:08 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Tue, 4 Mar 2008 17:34:08 -0300 Subject: [Hets-devel] About type errors within subtyping In-Reply-To: <47CDA334.1000305@dfki.de> References: <47CDA334.1000305@dfki.de> Message-ID: Hi. After hours reviewing the code, it was really a noob error. I've totally forgotten the operand 'b' of sucessor. I was so worried trying to decode the errors and correct the definition that I didn't see there was no operand. It solved the problem, of course. It was very good to learn what the hints really mean. Thanks a lot for this explanation! About the libraries, I'm trying to code the Prelude as my master thesis as Till suggests in one of his papers. I thought hets-lib was already proved, so I should prove the Prelude that I'm coding. Now that you've told me that the libs are not proved, I've got in doubt if I can prove my Prelude code without proving the other libs. Is it possible, as I will import lots of libs from hets-lib? Thanks a lot, Glauber From Till.Mossakowski at dfki.de Wed Mar 5 09:31:08 2008 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Wed, 05 Mar 2008 09:31:08 +0100 Subject: [Hets-devel] About type errors within subtyping In-Reply-To: References: <47CDA334.1000305@dfki.de> Message-ID: <47CE5A4C.7000305@dfki.de> Hi Glauber, you can always assume the things in Hets-lib to be proven, even if they are not yet proven. Hets supports this separation of concerns. Theorems are always proved locally in the theory T they belong to, but immediately can be used in theories importing T (even if not yet proved). Of course, there is a risk to rely on "theorems" that later on turn out to be false, but with the standard libraries, the theorems should be rather obvious. Greetings, Till Glauber Cabral schrieb: > Hi. > After hours reviewing the code, it was really a noob error. I've > totally forgotten the operand 'b' of sucessor. I was so worried trying > to decode the errors and correct the definition that I didn't see > there was no operand. > It solved the problem, of course. > It was very good to learn what the hints really mean. > Thanks a lot for this explanation! > > About the libraries, I'm trying to code the Prelude as my master > thesis as Till suggests in one of his papers. I thought hets-lib was > already proved, so I should prove the Prelude that I'm coding. Now > that you've told me that the libs are not proved, I've got in doubt if > I can prove my Prelude code without proving the other libs. Is it > possible, as I will import lots of libs from hets-lib? > > Thanks a lot, > Glauber > _______________________________________________ > Hets-devel mailing list > Hets-devel at mailhost.informatik.uni-bremen.de > http://www.informatik.uni-bremen.de/mailman/listinfo/hets-devel > -- Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From A.M.Gimblett at swansea.ac.uk Wed Mar 5 12:36:36 2008 From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett) Date: Wed, 5 Mar 2008 11:36:36 +0000 Subject: [Hets-devel] Hets web-based interface: frequency of builds? Message-ID: <20080305113636.GB14931@cspcag2.swan.ac.uk> Hi all, Regarding the web-based interface to Hets at: http://www.informatik.uni-bremen.de/cgi-bin/cgiwrap/maeder/hets.cgi What is the frequency with which the version of Hets behind this is built? I notice today's date on that page - is it, then, a nightly build from SVN trunk? Many thanks! -Andy -- Andy Gimblett Computer Science Department Swansea University http://www.cs.swan.ac.uk/~csandy/ From glauber.sp at gmail.com Wed Mar 5 14:04:28 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Wed, 5 Mar 2008 10:04:28 -0300 Subject: [Hets-devel] About type errors within subtyping In-Reply-To: <47CE5A4C.7000305@dfki.de> References: <47CDA334.1000305@dfki.de> <47CE5A4C.7000305@dfki.de> Message-ID: Hi Till. Thanks for the answer. The argument to use hets-libs without proving is that has standard libraries that are known very well and used and so can be proved later, when the tools are more stable/mature. Is this correct? One more question: Until now, I didn't have to use Isabelle at all. Do you see something in the Prelude lib that will force me to use Isabelle? My purpose to the thesis was to code Prelude in HasCASL and prove it and as I'm still in the beginning, I'm not sure if something in Prelude will force me to use Isabelle to prove the lib (all the specs until now are small and hets has given green nodes to them). I'm just trying to realize the complexity of this purpose. Regards, Glauber On Wed, Mar 5, 2008 at 5:31 AM, Till Mossakowski wrote: > Hi Glauber, > > you can always assume the things in Hets-lib to be proven, > even if they are not yet proven. > Hets supports this separation of concerns. Theorems are > always proved locally in the theory T they belong to, > but immediately can be used in theories importing T > (even if not yet proved). > Of course, there is a risk to rely on "theorems" that > later on turn out to be false, but with the standard > libraries, the theorems should be rather obvious. > > Greetings, > Till > > Glauber Cabral schrieb: > > > > Hi. > > After hours reviewing the code, it was really a noob error. I've > > totally forgotten the operand 'b' of sucessor. I was so worried trying > > to decode the errors and correct the definition that I didn't see > > there was no operand. > > It solved the problem, of course. > > It was very good to learn what the hints really mean. > > Thanks a lot for this explanation! > > > > About the libraries, I'm trying to code the Prelude as my master > > thesis as Till suggests in one of his papers. I thought hets-lib was > > already proved, so I should prove the Prelude that I'm coding. Now > > that you've told me that the libs are not proved, I've got in doubt if > > I can prove my Prelude code without proving the other libs. Is it > > possible, as I will import lots of libs from hets-lib? > > > > Thanks a lot, > > Glauber > > _______________________________________________ > > Hets-devel mailing list > > Hets-devel at mailhost.informatik.uni-bremen.de > > http://www.informatik.uni-bremen.de/mailman/listinfo/hets-devel > > > > > -- > Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 > DFKI Lab Bremen Fax +49-421-218-9864226 > Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de > Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till > > Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH > principal office, *not* the address for mail etc.!!!: > Trippstadter Str. 122, D-67663 Kaiserslautern > management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff > supervisory board: Prof. Hans A. Aukes (chair) > Amtsgericht Kaiserslautern, HRB 2313 > From Till.Mossakowski at dfki.de Wed Mar 5 14:42:03 2008 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Wed, 05 Mar 2008 14:42:03 +0100 Subject: [Hets-devel] About type errors within subtyping In-Reply-To: References: <47CDA334.1000305@dfki.de> <47CE5A4C.7000305@dfki.de> Message-ID: <47CEA32B.80106@dfki.de> Hi Glabuer, > Thanks for the answer. The argument to use hets-libs without proving > is that has standard libraries that are known very well and used and > so can be proved later, when the tools are more stable/mature. > Is this correct? exactly. > One more question: Until now, I didn't have to use Isabelle at all. Do > you see something in the Prelude lib that will force me to use > Isabelle? > My purpose to the thesis was to code Prelude in HasCASL and prove it > and as I'm still in the beginning, I'm not sure if something in > Prelude will force me to use Isabelle to prove the lib (all the specs > until now are small and hets has given green nodes to them). > I'm just trying to realize the complexity of this purpose. Currently, Isabelle is the only proof support for HasCASL. Within Isabelle, you can call automatic provers like SPASS with the sledgehammer tactic. One could also think of realizing this possibility directly in Hets, via a coding of higher-order logic in first-order logic. But anyway you will need Isabelle for induction proofs. Induction appears everywhere when reasoning about datatypes. Hets provides some form of induction with SPASS, but this usually requires the careful invention of a lot of lemmas (apart from the problem that we haven't realised the above mentioned coding yet). So you will need induction in Isabelle. This is more complex than just pressing a button, but with some mathematical skills it is doable. Greetings, Till Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From glauber.sp at gmail.com Wed Mar 5 15:38:45 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Wed, 5 Mar 2008 11:38:45 -0300 Subject: [Hets-devel] About type errors within subtyping In-Reply-To: <47CEA32B.80106@dfki.de> References: <47CDA334.1000305@dfki.de> <47CE5A4C.7000305@dfki.de> <47CEA32B.80106@dfki.de> Message-ID: Hi Till. I've already read the Isabelle tutorial to take a look at the problems I should have to deal with and I saw how complicated is to choose the correct induction rule to proves. That's why I asked... I know I'll have to study a lot to use Isabelle correctly and I guess that should be the most difficult part of the purpose. Well, learn Hets is difficult too, but It is interesting. The only worry is about asking too many questions here because I can't find explanations about the tool anywhere outside the manual, but I guess that's why the list exists (I hope not to bother a lot, anyway). II'll keep coding Prelude as it should force me to use Isabelle latter and learn a little about all the specification process. Thanks a lot! Best Regards, Glauber On Wed, Mar 5, 2008 at 10:42 AM, Till Mossakowski wrote: > Hi Glabuer, > > > > Thanks for the answer. The argument to use hets-libs without proving > > is that has standard libraries that are known very well and used and > > so can be proved later, when the tools are more stable/mature. > > Is this correct? > > exactly. > > > > One more question: Until now, I didn't have to use Isabelle at all. Do > > you see something in the Prelude lib that will force me to use > > Isabelle? > > My purpose to the thesis was to code Prelude in HasCASL and prove it > > and as I'm still in the beginning, I'm not sure if something in > > Prelude will force me to use Isabelle to prove the lib (all the specs > > until now are small and hets has given green nodes to them). > > I'm just trying to realize the complexity of this purpose. > > Currently, Isabelle is the only proof support for HasCASL. > Within Isabelle, you can call automatic provers like SPASS > with the sledgehammer tactic. One could also think of realizing > this possibility directly in Hets, via a coding of higher-order > logic in first-order logic. But anyway you will need Isabelle > for induction proofs. Induction appears everywhere when reasoning > about datatypes. Hets provides some form of induction with SPASS, > but this usually requires the careful invention of a lot of lemmas > (apart from the problem that we haven't realised the above mentioned > coding yet). > So you will need induction in Isabelle. This is more complex than > just pressing a button, but with some mathematical skills it > is doable. > > Greetings, > Till > > > > Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 > DFKI Lab Bremen Fax +49-421-218-9864226 > Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de > Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till > > Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH > principal office, *not* the address for mail etc.!!!: > Trippstadter Str. 122, D-67663 Kaiserslautern > management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff > supervisory board: Prof. Hans A. Aukes (chair) > Amtsgericht Kaiserslautern, HRB 2313 > From glauber.sp at gmail.com Thu Mar 6 20:01:58 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Thu, 6 Mar 2008 16:01:58 -0300 Subject: [Hets-devel] Error when importing String library Message-ID: Hi ! Once again I'm with doubts about hets error messages. In the code below, if I comment out the String import, it works OK; if I try to import String, I get an error in the defintion of compare. It seems the tool doesn't recognize the application of the function to both arguments and expect me to input a mixfix token between x and y in: . compare x y = I tried to look for name clashes, but I didn't find another compare function. I was reading again the HasCASL paper and I got another question: Should every function I declare be lazy, as in Haskell? If so, all the types should be ?Type in all function definitions because all the functions are lazy in Haskell by default? ________CODE___ logic HasCASL %%All imported types should start with I from Basic/SimpleDatatypes get Boolean |-> IBoolean from HasCASL/Metatheory/Ord get Ord |-> IOrd from Basic/StructuredDatatypes get String spec Bool = {IBoolean with Boolean |-> Bool, Not__ |-> not__, __And__ |-> __&&__, __Or__ |-> __||__ } then op otherwise: Bool . otherwise = True end spec Eq = class Eq { var a: Eq fun __==__: Pred (a * a) fun __/=__: Pred (a * a) vars x,y: a . x /= y = not (x == y) . x == y = not (x /= y) } end spec Ord = IOrd and Eq then free type Ordering ::= LT | EQ | GT type instance Ordering: Eq . LT /= EQ . LT /= GT . EQ /= GT class Ord < Eq { var a: Ord fun compare: a -> a -> Ordering fun __<__: Pred (a * a) fun __>__: Pred (a * a) fun __>=__: Pred (a * a) fun min: a -> a -> a fun max: a -> a -> a vars x,y: a %% Define compare . compare x y = case x == y of True -> EQ | False -> case x <= y of True -> LT | False -> GT %% Define <, <=, >, >= . x <= y = compare x y /= GT . x < y = compare x y == LT . x >= y = compare x y /= LT . x > y = compare x y == GT %% %% Define min, max . max x y = case x <= y of True -> y | False -> x . min x y = case x <= y of True -> x | False -> y } end ________END OF CODE____ ________ERROR MESSAGE________ Analyzing spec Ord ### Hint /home/glauber/GlauberMSc/erro.het:37.12, refined class 'Ord' ### Hint /home/glauber/GlauberMSc/erro.het:39.16, is type variable 'a' ### Hint /home/glauber/GlauberMSc/erro.het:46.18, not a class 'a' ### Hint /home/glauber/GlauberMSc/erro.het:46.20, not a class 'a' *** Error /home/glauber/GlauberMSc/erro.het:48.21-50.12, expected further mixfix token: ["/\\","<=>","=","=>","=e="] *** Error /home/glauber/GlauberMSc/erro.het:54.31-54.38, expected further mixfix token: [":","/=","/\\","<","<="] *** Error /home/glauber/GlauberMSc/erro.het:55.30-55.37, expected further mixfix token: [":","/=","/\\","<","<="] *** Error /home/glauber/GlauberMSc/erro.het:56.31-56.38, expected further mixfix token: [":","/=","/\\","<","<="] *** Error /home/glauber/GlauberMSc/erro.het:57.30-57.37, expected further mixfix token: [":","/=","/\\","<","<="] *** Error /home/glauber/GlauberMSc/erro.het:60.18-61.12, expected further mixfix token: ["/\\","<=>","=","=>","=e="] *** Error /home/glauber/GlauberMSc/erro.het:62.18-63.12, expected further mixfix token: ["/\\","<=>","=","=>","=e="] ________END OF ERROR MESSAGE________ Thanks in advance. Glauber From Christian.Maeder at dfki.de Thu Mar 6 20:43:11 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 06 Mar 2008 20:43:11 +0100 Subject: [Hets-devel] Error when importing String library In-Reply-To: References: Message-ID: <47D0494F.4030404@dfki.de> Glauber Cabral wrote: > Hi ! > Once again I'm with doubts about hets error messages. In the code > below, if I comment out the String import, it works OK; if I try to > import String, I get an error in the defintion of compare. It seems > the tool doesn't recognize the application of the function to both > arguments and expect me to input a mixfix token between x and y in: . > compare x y = > I tried to look for name clashes, but I didn't find another compare function. Right, that's a bug that I've discovered only recently, too. It is fixed since March (http://trac.informatik.uni-bremen.de:8080/hets/changeset/9666) Download http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/versions/hets-2008-03-05.bz2 (or "mac", "intel-mac", "solaris", "pc-solaris" instead of "linux") The problem is/was the line in Basic/StructuredDatatypes.casl (that I've added once for HasCASL): %prec {[__/__]} <> {__ __} which made the invisible application identifier "__ __" disallow another "__ __" application as argument by transitivity. (as if "%prec {__ __} <> {__ __}" had been given) So "compare x y" became illegal. (same for "min" or "max") Since my patch an %assoc annotation is now considered for equal identifiers first. And "__ __" is left-associative! Cheers Christian [...] > fun compare: a -> a -> Ordering > fun min: a -> a -> a > fun max: a -> a -> a > . x <= y = compare x y /= GT > . x < y = compare x y == LT > . x >= y = compare x y /= LT > . x > y = compare x y == GT > . max x y = case x <= y of True -> y > | False -> x > . min x y = case x <= y of True -> x > | False -> y > expected further mixfix token: ["/\\","<=>","=","=>","=e="] > *** Error /home/glauber/GlauberMSc/erro.het:54.31-54.38, > expected further mixfix token: [":","/=","/\\","<","<="] > *** Error /home/glauber/GlauberMSc/erro.het:55.30-55.37, > expected further mixfix token: [":","/=","/\\","<","<="] > *** Error /home/glauber/GlauberMSc/erro.het:56.31-56.38, > expected further mixfix token: [":","/=","/\\","<","<="] > *** Error /home/glauber/GlauberMSc/erro.het:57.30-57.37, > expected further mixfix token: [":","/=","/\\","<","<="] > *** Error /home/glauber/GlauberMSc/erro.het:60.18-61.12, > expected further mixfix token: ["/\\","<=>","=","=>","=e="] > *** Error /home/glauber/GlauberMSc/erro.het:62.18-63.12, > expected further mixfix token: ["/\\","<=>","=","=>","=e="] From Till.Mossakowski at dfki.de Thu Mar 6 20:53:29 2008 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Thu, 06 Mar 2008 20:53:29 +0100 Subject: [Hets-devel] Error when importing String library In-Reply-To: References: Message-ID: <47D04BB9.4010905@dfki.de> Hi Galuber, > I was reading again the HasCASL paper and I got another question: > Should every function I declare be lazy, as in Haskell? If so, all the > types should be ?Type in all function definitions because all the > functions are lazy in Haskell by default? Yes, that is right. ?Type should be used everywhere. The only exception are strict constructors, declared in Haskell with !type. Greetings, Till -- Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From glauber.sp at gmail.com Fri Mar 7 00:56:28 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Thu, 6 Mar 2008 20:56:28 -0300 Subject: [Hets-devel] Error when importing String library In-Reply-To: <47D04BB9.4010905@dfki.de> References: <47D04BB9.4010905@dfki.de> Message-ID: The new hets worked and I've already changed the types to lazy ones. Thanks. Glauber On Thu, Mar 6, 2008 at 4:53 PM, Till Mossakowski wrote: > Hi Galuber, > > > > I was reading again the HasCASL paper and I got another question: > > Should every function I declare be lazy, as in Haskell? If so, all the > > types should be ?Type in all function definitions because all the > > functions are lazy in Haskell by default? > > Yes, that is right. ?Type should be used everywhere. > The only exception are strict constructors, declared in Haskell with > !type. > > Greetings, > Till > -- > Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 > DFKI Lab Bremen Fax +49-421-218-9864226 > Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de > Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till > > Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH > principal office, *not* the address for mail etc.!!!: > Trippstadter Str. 122, D-67663 Kaiserslautern > management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff > supervisory board: Prof. Hans A. Aukes (chair) > Amtsgericht Kaiserslautern, HRB 2313 > From glauber.sp at gmail.com Mon Mar 10 15:06:02 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Mon, 10 Mar 2008 11:06:02 -0300 Subject: [Hets-devel] About typing error Message-ID: Hi hets developers ! Here I am again with a typing error that I could 't understand. My code is posted at http://paste.la/318 because it was too long to be sent here, I guess. The error is about line 228 (eqString definition for x:@:xs), but there are Hints about Char spec and I'm not sure if the contents pointed out by these hits cause the problems found in the String spec. The line numbers in the messages are equal to those of paste.la. In line 228 there is a %% in the middle of the definition but the error message below was generated without these chars. Just delete them. ---------ERROR------------------ Analyzing spec Char ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:183.12, not a class 'Char' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:183.15, not a class 'Char' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:194.25, rebound variable 'False' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:194.25, rebound variable 'False' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:201.14-201.19, rejected 'Char < Nat' of '((var x : Char), (var y : Char))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:201.14-201.19, untypeable term (with type: Nat * Nat) '(x, y)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:202.14-202.18, rejected 'Char < Nat' of '((var x : Char), (var y : Char))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:202.14-202.18, untypeable term (with type: Nat * Nat) '(x, y)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:203.14-203.19, rejected 'Char < Nat' of '((var x : Char), (var y : Char))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:203.14-203.19, untypeable term (with type: Nat * Nat) '(x, y)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:204.14-204.18, rejected 'Char < Nat' of '((var x : Char), (var y : Char))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:204.14-204.18, untypeable term (with type: Nat * Nat) '(x, y)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:212.13, in type of '(op max : Nat * Nat -> Nat)' typename 'Nat' (/home/arquivos/Hets/Hets/Hets-lib/Basic/Numbers.casl:70.27) is not unifiable with type '_v185 ->? _v186' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:212.19) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:212.28-212.33, rejected 'Char < Nat' of '((var x : Char), (var y : Char))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:212.28-212.33, untypeable term (with type: Nat * Nat) '(x, y)' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:214.13, in type of '(op min : Nat * Nat -> Nat)' typename 'Nat' (/home/arquivos/Hets/Hets/Hets-lib/Basic/Numbers.casl:68.27) is not unifiable with type '_v206 ->? _v207' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:214.19) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:214.28-214.33, rejected 'Char < Nat' of '((var x : Char), (var y : Char))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:214.28-214.33, untypeable term (with type: Nat * Nat) '(x, y)' Analyzing spec String ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:225.20, no kind found for 'String' expected: {Ord} found: {Type} ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:225.31, no kind found for 'String' expected: {Ord} found: {Type} ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:225.42, no kind found for 'Bool' expected: {Ord} found: {Type} ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.12, not a kind '? String' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.17, no kind found for 'String' expected: {Ord} found: {Type} ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.14, not a kind '? String' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.17, no kind found for 'String' expected: {Ord} found: {Type} ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.26, not a kind '? Char' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.28, not a kind '? Char' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.39, not a kind '? String' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.46, no kind found for 'String' expected: {Ord} found: {Type} ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.43, not a kind '? String' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.46, no kind found for 'String' expected: {Ord} found: {Type} ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:228.8-228.82, rejected 'Unit < Bool' of '(((op eqString : ? String -> ? String -> ? Bool) ((op __:@:__ : Char * String -> String) ((var x : ? Char), (var xs : ? String)))) ((op __:@:__ : Char * String -> String) ((var y : ? Char), (var ys : ? String)))) = ((fun __==__ : forall a : Eq . Pred (? a * ? a)) ((op first : String ->? Char) ((op __:@:__ : Char * String -> String) ((var x : ? Char), (var xs : ? String))), (op first : String ->? Char) ((op __:@:__ : Char * String -> String) ((var y : ? Char), (var ys : ? String)))))' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:228.8-228.131, untypeable term (with type: ? Unit * ? Unit) '((eqString (x :@: xs)) (y :@: ys) = first (x :@: xs) == first (y :@: ys), (eqString (rest (x :@: xs))) (rest (y :@: ys)))' *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:228.64, no typing for '(eqString (x :@: xs)) (y :@: ys) = first (x :@: xs) == first (y :@: ys) /\ (eqString (rest (x :@: xs))) (rest (y :@: ys))' -----------END OF ERROR------------------- I'd be very grateful if you explain a little more of these hint messages. If I understood, Bool and String should have a class declaration like Bool References: Message-ID: <47D54D67.1070702@dfki.de> Glauber Cabral wrote: > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:228.8-228.82, > rejected 'Unit < Bool' of '(((op eqString : ? String -> ? String -> ? Bool) > ((op __:@:__ : Char * String -> String) > ((var x : ? Char), (var xs : ? String)))) > ((op __:@:__ : Char * String -> String) > ((var y : ? Char), (var ys : ? String)))) > = ((fun __==__ : forall a : Eq . Pred (? a * ? a)) > ((op first : String ->? Char) > ((op __:@:__ : Char * String -> String) > ((var x : ? Char), (var xs : ? String))), > (op first : String ->? Char) > ((op __:@:__ : Char * String -> String) > ((var y : ? Char), (var ys : ? String)))))' The function "==" is declared to be a "Pred", which is a function to (the builtin type) "Unit" whereas "Bool" is a new user defined type. So types do not match. I've no idea how to best fix this, but I think the classes Eq and Ord should be redefined to use Bool, too! > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:228.8-228.131, > untypeable term (with type: ? Unit * ? Unit) > '((eqString (x :@: xs)) (y :@: ys) > = first (x :@: xs) == first (y :@: ys), > (eqString (rest (x :@: xs))) (rest (y :@: ys)))' > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:228.64, > no typing for > '(eqString (x :@: xs)) (y :@: ys) > = first (x :@: xs) == first (y :@: ys) > /\ (eqString (rest (x :@: xs))) (rest (y :@: ys))' (instead of calling first and rest, the components x, y, xs, and ys can be compared directly.) > I'd be very grateful if you explain a little more of these hint > messages. If I understood, Bool and String should have a class > declaration like Bool should have found Ord. Is it correct? Should every spec from now have > a class declaration like this? The (irrelevant) hints not a kind '? String' ### Hint /home/maeder/Hets/test/Glauber3.het:227.46, no kind found for 'String' expected: {Eq} found: {Type} ### Hint /home/maeder/Hets/test/Glauber3.het:227.46, no kind found for 'String' expected: {Ord} found: {Type} only indicate that proper variables with a type and not type-variables with kinds are declared following "var". (It finds "Type", because that is the default if nothing is found, but I'll keep that in mind for improving the message) HTH Christian From Christian.Maeder at dfki.de Tue Mar 11 11:18:26 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue, 11 Mar 2008 11:18:26 +0100 Subject: [Hets-devel] About typing error In-Reply-To: References: Message-ID: <47D65C72.7080501@dfki.de> Hi Cabral, you wrote: > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.43, > not a kind '? String' Only this hint says that a proper variable and not a type variable with its kind is defined. > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.46, > no kind found for 'String' > expected: {Ord} > found: {Type} This hint comes from the specialization of "?" in HasCASL/Metatheory/Ord.het type instance ?a: Ord If you look at the signature you can see: type ? : +Ord -> Ord In "? String" the type "String" is not of class "Ord", hence the hint. But "?" has also the (builtin) kind "+Type -> Type", so "? String" is still correctly kinded. HTH Christian P.S. the comment in my previous mail applied to a modified copy, where I've also added var a : Eq type instance ?a: Eq From glauber.sp at gmail.com Tue Mar 11 15:17:40 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Tue, 11 Mar 2008 11:17:40 -0300 Subject: [Hets-devel] About typing error In-Reply-To: <47D65C72.7080501@dfki.de> References: <47D65C72.7080501@dfki.de> Message-ID: Hi Maeder, Thanks for the explanation. I'm rewriting the specs you suggested to use functions, not Pred. I used Pred because I read an example in the paper that describes HasCASL and thought that I should always use Pred in place of functions into Bool. Now I see it's not true. Glauber Cabral On Tue, Mar 11, 2008 at 7:18 AM, Christian Maeder wrote: > Hi Cabral, > > > you wrote: > > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.43, > > not a kind '? String' > > Only this hint says that a proper variable and not a type variable with > its kind is defined. > > > > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:226.46, > > no kind found for 'String' > > expected: {Ord} > > found: {Type} > > This hint comes from the specialization of "?" in HasCASL/Metatheory/Ord.het > > type instance ?a: Ord > > If you look at the signature you can see: > > type ? : +Ord -> Ord > > In "? String" the type "String" is not of class "Ord", hence the hint. > > But "?" has also the (builtin) kind "+Type -> Type", so "? String" is > still correctly kinded. > > HTH Christian > > P.S. the comment in my previous mail applied to a modified copy, where > I've also added > > var a : Eq > type instance ?a: Eq > > From glauber.sp at gmail.com Tue Mar 11 16:42:03 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Tue, 11 Mar 2008 12:42:03 -0300 Subject: [Hets-devel] About typing error In-Reply-To: References: <47D65C72.7080501@dfki.de> Message-ID: Hi Maeder. I've been rewriting Eq and Ord to use Bool, but I guess I need to rewrite Bool to use lazy types because I've got this error: ------CODE------------- from Basic/SimpleDatatypes get Boolean |-> IBoolean spec Bool = {IBoolean with Boolean |-> Bool, Not__ |-> Not__, __And__ |-> __&&__, __Or__ |-> __||__ } then op otherwise: ?Bool . otherwise = True end spec Eq = Bool then class Eq { var a: Eq fun __==__: ?a -> ?a -> ?Bool fun __/=__: ?a -> ?a -> ?Bool vars x,y: ?a . x == x = True . x == y = False . x /= x = False . x /= y = True } end ------END OF CODE--------- Line 42 is: . x == x = True -----ERROR------------ Analyzing spec Eq ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:36.16, is type variable 'a' ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:39.18, expected tuple argument for '__==__' ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:40.18, expected tuple argument for '__/=__' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.18, not a kind '? a' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.20, not a kind '? a' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:42.14-42.25, in type of '((fun __==__ : forall a : Eq . ? a -> ? a -> ? Bool) ((var x : ? a), (var x : ? a)), (op True : Bool))' typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) is not unifiable with type '? (a * a) -> ? Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:42.14-42.25, untypeable term (with type: ? _v3_a * ? _v3_a) '(x == x, True)' *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:42.15, no typing for 'x == x = True' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:43.14-43.25, in type of '((fun __==__ : forall a : Eq . ? a -> ? a -> ? Bool) ((var x : ? a), (var y : ? a)), (op False : Bool))' typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) is not unifiable with type '? (a * a) -> ? Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:43.14-43.25, untypeable term (with type: ? _v17_a * ? _v17_a) '(x == y, False)' *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:43.15, no typing for 'x == y = False' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:44.14-44.25, in type of '((fun __/=__ : forall a : Eq . ? a -> ? a -> ? Bool) ((var x : ? a), (var x : ? a)), (op False : Bool))' typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) is not unifiable with type '? (a * a) -> ? Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:44.14-44.25, untypeable term (with type: ? _v31_a * ? _v31_a) '(x /= x, False)' *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:44.15, no typing for 'x /= x = False' ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, in type of '((fun __/=__ : forall a : Eq . ? a -> ? a -> ? Bool) ((var x : ? a), (var y : ? a)), (op True : Bool))' typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) is not unifiable with type '? (a * a) -> ? Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, untypeable term (with type: ? _v45_a * ? _v45_a) '(x /= y, True)' *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.15, no typing for 'x /= y = True' -----END OF ERROR-------- As I could see, True is not lazy and so the types could'n be unified. Is this correct? Thanks, Glauber From Christian.Maeder at dfki.de Tue Mar 11 17:11:57 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue, 11 Mar 2008 17:11:57 +0100 Subject: [Hets-devel] About typing error In-Reply-To: References: <47D65C72.7080501@dfki.de> Message-ID: <47D6AF4D.9040700@dfki.de> Hi Glauber, (sorry for mixing up your first- and surname.) Glauber Cabral wrote: > fun __==__: ?a -> ?a -> ?Bool > fun __/=__: ?a -> ?a -> ?Bool HasCASL mixfix identifiers are not compatible with curried functions like in Haskell or Isabelle, but they need tuple arguments as in CASL: > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:39.18, > expected tuple argument for '__==__' > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:40.18, > expected tuple argument for '__/=__' this is the corresponding warning. > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, > in type of '((fun __/=__ : forall a : Eq . ? a -> ? a -> ? Bool) > ((var x : ? a), (var y : ? a)), > (op True : Bool))' > typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) > is not unifiable with type '? (a * a) -> ? Bool' > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, > untypeable term (with type: ? _v45_a * ? _v45_a) '(x /= y, True)' > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.15, > no typing for 'x /= y = True' The application of the curried "__/=__" to a tuple as a single first argument leaves a function that expects another tuple of the same type as second argument > As I could see, True is not lazy and so the types could'n be unified. > Is this correct? No, usually laziness is ignored when types are unified. Cheers Christian P.S. I recommend to re-define the Boolean datatype in HasCASL, because ops Not__ : Boolean -> Boolean; __And__, __Or__ : Boolean * Boolean -> Boolean are all total functions. From Christian.Maeder at dfki.de Fri Mar 14 14:12:35 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri, 14 Mar 2008 14:12:35 +0100 Subject: [Hets-devel] Hets Meeting Tuesday 18th afternoon (Bremen only) Message-ID: <47DA79C3.7070305@dfki.de> Dear Hets Developers, we are going to meet next Tuesday to discuss the coming hets release-0.9. http://trac.informatik.uni-bremen.de:8080/hets/roadmap Usually only four of us meet, but other (or new) developers are also welcome to join us (but don't have to). Maybe only a few points are interesting for you, though. We start at 2 o'clock p.m. in room Cartesium 2.043 Cheers Christian From csliam at swansea.ac.uk Mon Mar 17 16:23:30 2008 From: csliam at swansea.ac.uk (Liam O'Reilly) Date: Mon, 17 Mar 2008 15:23:30 +0000 Subject: [Hets-devel] CASL translation to IsabelleHOL Message-ID: <47DE8CF2.5020003@swansea.ac.uk> Dear Hets Developers, I have been using Hets for the Development of theorem prover for CSP-CASL. I use Hets to translate CASL specifications into IsabelleHOL code. I have noticed that new versions of Hets give me empty Isabelle code for CASL specifications that used to generate Isabelle code. I have used the translation CASL2SubCFOL; CFOL2IsabelleHOL for the following examples. ===================== Example 1 - CASL Specification: spec test1= sorts S, T op c: T op f: S -> T end Example 1 - Translation to IsabelleHOL: {} Example 2 - CASL Specification: spec test2= sorts S, T op c: T op f: S -> T axiom forall x:S . f(x) = c end Example 2 - Translation to IsabelleHOL: typedecl S typedecl T consts X_f :: "S => T" ("f/'(_')" [3] 999) c :: "T" instance S:: type .. instance T:: type .. Ax1 [rule_format] : "ALL x. f(x) = c" ========================== The first specification yields no IsabelleHOL code, whilst the second yields reasonable IsabelleHOL code. I expected the first specification to yield the same IsabelleHOL code as the second minus the final axiom statement Ax1 [rule_format] : "ALL x. f(x) = c". Previous versions used to generate the code I was expecting. Is this reasonable behaviour and if so why? Thanks Liam From Christian.Maeder at dfki.de Mon Mar 17 16:48:36 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 17 Mar 2008 16:48:36 +0100 Subject: [Hets-devel] CASL translation to IsabelleHOL In-Reply-To: <47DE8CF2.5020003@swansea.ac.uk> References: <47DE8CF2.5020003@swansea.ac.uk> Message-ID: <47DE92D4.5090806@dfki.de> Liam O'Reilly wrote: > Dear Hets Developers, > > I have been using Hets for the Development of theorem prover for CSP-CASL. > > I use Hets to translate CASL specifications into IsabelleHOL code. I > have noticed that new versions of Hets give me empty Isabelle code for > CASL specifications that used to generate Isabelle code. > > I have used the translation CASL2SubCFOL; CFOL2IsabelleHOL for the > following examples. The proper comorphism is CASL2HasCASL;PCoClTyConsHOL2IsabelleHOL, but that is not the problem. > ===================== > Example 1 - CASL Specification: > spec test1= > sorts S, T > op c: T > op f: S -> T > end > > Example 1 - Translation to IsabelleHOL: > {} While we'll have to find out, why this happens if translating via the GUI, you may translate using "hets -v2 -o thy ..." > Example 2 - CASL Specification: > spec test2= > sorts S, T > op c: T > op f: S -> T > axiom forall x:S . f(x) = c > end > > Example 2 - Translation to IsabelleHOL: > typedecl S > typedecl T > > consts > X_f :: "S => T" ("f/'(_')" [3] 999) > c :: "T" > > instance S:: type .. > instance T:: type .. > > Ax1 [rule_format] : "ALL x. f(x) = c" > ========================== > > The first specification yields no IsabelleHOL code, whilst the second > yields reasonable IsabelleHOL code. I expected the first specification > to yield the same IsabelleHOL code as the second minus the final axiom > statement Ax1 [rule_format] : "ALL x. f(x) = c". This happens indeed, if you create the thy-Files via hets -v2 -o thy ... > Previous versions used to generate the code I was expecting. > Is this reasonable behaviour and if so why? No, we'll look into it. (We cannot properly test the GUI automatically.) Thanks for your report Christian From Christian.Maeder at dfki.de Mon Mar 17 17:38:37 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 17 Mar 2008 17:38:37 +0100 Subject: [Hets-devel] CASL translation to IsabelleHOL In-Reply-To: <47DE8CF2.5020003@swansea.ac.uk> References: <47DE8CF2.5020003@swansea.ac.uk> Message-ID: <47DE9E8D.2020400@dfki.de> Liam O'Reilly wrote: > Example 1 - Translation to IsabelleHOL: > {} In fact, that is only a matter of wrong pretty printing based on a wrong test for emptiness. Christian "instance Pretty G_theory" in Static.GTheory and "is_subsig Isabelle = const $ const True" in Isabelle.Logic_Isabelle From glauber.sp at gmail.com Tue Mar 25 12:20:07 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Tue, 25 Mar 2008 08:20:07 -0300 Subject: [Hets-devel] About typing error In-Reply-To: <47D6AF4D.9040700@dfki.de> References: <47D65C72.7080501@dfki.de> <47D6AF4D.9040700@dfki.de> Message-ID: Hi Maeder, Till and haskell devs. Sorry by the long time to this reply. I've trying to find some papers that talk about partial/total functions in Haskell but I didn't find anyone yet. I've got in doubt about Maeder' suggestion about re-define Boolean because it has total functions. I'm not sure if all functions in Haskell are partial or if the suggestion is related to bottom value. Do you know any paper that describes the model of functions in Haskell? That is, when functions are partial (or if all of them are partial because of the bottom value)? I was thinking... If all functions are partial, should all specs be redefined to use partial functions, in special the numerical specifications? If it is true, I guess almost anything can be imported and almost everything must be redefined. Does it make any sense? Thanks in advance, Glauber Cabral On Tue, Mar 11, 2008 at 1:11 PM, Christian Maeder wrote: > Hi Glauber, > > (sorry for mixing up your first- and surname.) > > > Glauber Cabral wrote: > > fun __==__: ?a -> ?a -> ?Bool > > fun __/=__: ?a -> ?a -> ?Bool > > HasCASL mixfix identifiers are not compatible with curried functions > like in Haskell or Isabelle, but they need tuple arguments as in CASL: > > > > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:39.18, > > expected tuple argument for '__==__' > > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:40.18, > > expected tuple argument for '__/=__' > > this is the corresponding warning. > > > > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, > > in type of '((fun __/=__ : forall a : Eq . ? a -> ? a -> ? Bool) > > ((var x : ? a), (var y : ? a)), > > (op True : Bool))' > > typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) > > is not unifiable with type '? (a * a) -> ? Bool' > > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) > > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, > > untypeable term (with type: ? _v45_a * ? _v45_a) '(x /= y, True)' > > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.15, > > no typing for 'x /= y = True' > > The application of the curried "__/=__" to a tuple as a single first > argument leaves a function that expects another tuple of the same type > as second argument > > > > As I could see, True is not lazy and so the types could'n be unified. > > Is this correct? > > No, usually laziness is ignored when types are unified. > > Cheers Christian > > P.S. I recommend to re-define the Boolean datatype in HasCASL, because > > ops Not__ : Boolean -> Boolean; > __And__, __Or__ : Boolean * Boolean -> Boolean > > are all total functions. > From Till.Mossakowski at dfki.de Tue Mar 25 13:15:34 2008 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Tue, 25 Mar 2008 13:15:34 +0100 Subject: [Hets-devel] About typing error In-Reply-To: References: <47D65C72.7080501@dfki.de> <47D6AF4D.9040700@dfki.de> Message-ID: <47E8ECE6.1030803@dfki.de> Dear Glauber, sorry that we have not discussed this issue earlier with you. It is a quite fundamental issue. A Haskell function f : s -> t becomes f : ?s --> ?t in HasCASL (i.e. a partial non-strict continuous function). You obtain cpos and continuous functions from the specifcation Recursion. Indeed, this means that you have to define many things newly from scratch. Note that in the axioms, you don't need to care about non-strictness or continuity, i.e. you can write: logic HasCASL from HasCASL/Recursion get Recursion spec sp1 = Recursion then sorts s,t,u op f:?s --> ?t; g:?t-->?u; h:?s-->?u forall x:s . h(x) = g(f(x)) end Moreover, you should try to achieve maximum generality. That is, if you can use ?s->?t instead of ?s-->?t, then I would do so, because it is more general (any partial non-strict continuous function also is a partial non-strict function). However, some higher-order may require a continuous function as argument, so then you might need the more special profile. The next issue is datatypes. To define the Haskell lazy lists in HasCASL, you write: from HasCASL/Recursion get Recursion spec sp2 = Recursion then var a : Cpo free domain List a ::= nil | cons (?a) (? List a)? end However, free domains are not implemented in Hets yet. Christian, can you implement them? Currently, you can use a "free type" instead of the "free domain"; then the specification at least parses. But you get cons : forall a : Cpo . ? a -> ? List a ->? List a instead of cons : forall a : Cpo . ? a --> ? List a -->? List a so a quick workaround to get the correct typing for experiments could be just to add this profile of cons manually. Greetings, Till Glauber Cabral schrieb: > Hi Maeder, Till and haskell devs. > > Sorry by the long time to this reply. > I've trying to find some papers that talk about partial/total > functions in Haskell but I didn't find anyone yet. > > I've got in doubt about Maeder' suggestion about re-define Boolean > because it has total functions. > I'm not sure if all functions in Haskell are partial or if the > suggestion is related to bottom value. > > Do you know any paper that describes the model of functions in > Haskell? That is, when functions are partial (or if all of them are > partial because of the bottom value)? > > I was thinking... If all functions are partial, should all specs be > redefined to use partial functions, in special the numerical > specifications? If it is true, I guess almost anything can be imported > and almost everything must be redefined. Does it make any sense? > > Thanks in advance, > Glauber Cabral > > On Tue, Mar 11, 2008 at 1:11 PM, Christian Maeder > wrote: >> Hi Glauber, >> >> (sorry for mixing up your first- and surname.) >> >> >> Glauber Cabral wrote: >> > fun __==__: ?a -> ?a -> ?Bool >> > fun __/=__: ?a -> ?a -> ?Bool >> >> HasCASL mixfix identifiers are not compatible with curried functions >> like in Haskell or Isabelle, but they need tuple arguments as in CASL: >> >> >> > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:39.18, >> > expected tuple argument for '__==__' >> > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:40.18, >> > expected tuple argument for '__/=__' >> >> this is the corresponding warning. >> >> >> > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, >> > in type of '((fun __/=__ : forall a : Eq . ? a -> ? a -> ? Bool) >> > ((var x : ? a), (var y : ? a)), >> > (op True : Bool))' >> > typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) >> > is not unifiable with type '? (a * a) -> ? Bool' >> > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) >> > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, >> > untypeable term (with type: ? _v45_a * ? _v45_a) '(x /= y, True)' >> > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.15, >> > no typing for 'x /= y = True' >> >> The application of the curried "__/=__" to a tuple as a single first >> argument leaves a function that expects another tuple of the same type >> as second argument >> >> >> > As I could see, True is not lazy and so the types could'n be unified. >> > Is this correct? >> >> No, usually laziness is ignored when types are unified. >> >> Cheers Christian >> >> P.S. I recommend to re-define the Boolean datatype in HasCASL, because >> >> ops Not__ : Boolean -> Boolean; >> __And__, __Or__ : Boolean * Boolean -> Boolean >> >> are all total functions. >> > _______________________________________________ > Hets-devel mailing list > Hets-devel at mailhost.informatik.uni-bremen.de > http://www.informatik.uni-bremen.de/mailman/listinfo/hets-devel > -- Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313 From glauber.sp at gmail.com Tue Mar 25 13:23:38 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Tue, 25 Mar 2008 09:23:38 -0300 Subject: [Hets-devel] About equality and instance declarations Message-ID: Hi Hets developers! First of all, sorry by the haskell devs in the last email. That was a little mistake with "replace all" function in the editor. I've got some questions about default logical connectors and equality test. My code is in http://www.paste.la/485 . About the equality test, in spec Eq (line 40) I define fun __==__. Later, for example, in spec Ord (line 75), I use __==__. I'm almost convinced that this latter use is of that definition and not of the default equality. The same about the relations defined in the Ord spec: when I import Ord, I'm almost sure the uses of <, <=, >, >= are of the functions defined in Ord, not the default ones. The doubt arises in the Char spec. In line 259. I'm not sure if the equation says what I wanted to: I should use the default comparison to compare ord(x) and ord(y) and based on this, define the instance declaration of __<__. I'm not sure which profile was taken to each side and hets don't show types hits when the match is successful, only when there are no matches. A possible solution to this, I guess, was to use the operations with their profiles, but if I do so, I think I'll have do to so later on and everybody else that import my libraries would have to do this, too. Is it correct? Another question is about (not, /\, \/) and (Not, &&, ||) that I've defined in new spec Bool (line 77 has an example). I've really gotten confused about which one to use. If I use the second ones, I think I'm not using HasCASL language correctly. If I use the first ones, I'm not sure if I'm using the library correctly. I guess it's a question about reserved words (and its semantic) and new defined ops (and its similar or equal semantic). As both means (at least to me) the same thing, I'm not sure when each one should be used. I'm sure they are don't mean the same thing, but I couldn't realize the meaning of both yet. About the instance declarations, I've read in the HasCASL new definition paper that I'm not forced, as in Haskell, to define the operations of the instance. I may only declare a type to be instance of a class (I've done this to Bool:Eq and others so the hints about not finding the correct subtype -- or subclas -- realations has gone). The problem is that I'm not sure when the correct profile will be chosen. I've created the SpecNum spec to centralize the numerical type instances declarations (I'm not sure if it's better to do the declarations in Int and Integer specs, yet). In llines 163 to 171, I almost got crazy to realize the correct types and to find out how to relate the operations already defined with the functions of the instance declaration. I'm not sure if that code is correct neither if it was necessary (I could only make de type instance declaration, I guess, but I don't know if the correct ops should be chosen. Is there any paper that explains type instance declaration a little bit more? Or the answers to my questions are in the CASL reference manual? I've just read the tutorial, not the reference yet because I though latter would be too much theoretical and not have answers but just make new questions appear. Is it a good idea to read it now, ot there are other papers to solve the questions? If you can suggest me some other reading, I'd appreciate a lot. Thanks in advance, Glauber Cabral From glauber.sp at gmail.com Tue Mar 25 13:55:28 2008 From: glauber.sp at gmail.com (Glauber Cabral) Date: Tue, 25 Mar 2008 09:55:28 -0300 Subject: [Hets-devel] About typing error In-Reply-To: <47E8ECE6.1030803@dfki.de> References: <47D65C72.7080501@dfki.de> <47D6AF4D.9040700@dfki.de> <47E8ECE6.1030803@dfki.de> Message-ID: Hi Till. I've read about recursion and free domain in "HasCASL: Integrated Higher-Order Specification and Program Development" but then I found HasCASL/List definition and I've used it. I thought free domain should only be used when coding inside program keyword. And know I'm not sure if everything I've coded should have definitions with the program keyword. Another question: Should everything I'm specifying follow the 3 items of page 52 (Animating executable HasCASL specifications in Haskell), because I'm specifying things that already are haskell code? That is, all types be instances of Cpo and/or Cppo, etc? I guess I need to read this paper again because some fundamental points are not clear to me yet. Sometimes I'm not sure if I'm specifying in CASL or HasCASL and if I'm doing it write. I've already read some codes from the library to try to fix this in mind, but it's still not clear. I'll start reading this today. Thanks for the advices! Glauber Cabral On Tue, Mar 25, 2008 at 9:15 AM, Till Mossakowski wrote: > Dear Glauber, > > sorry that we have not discussed this issue earlier with you. > It is a quite fundamental issue. > A Haskell function f : s -> t becomes f : ?s --> ?t in HasCASL > (i.e. a partial non-strict continuous function). You obtain > cpos and continuous functions from the specifcation Recursion. > Indeed, this means that you have to define many things newly from > scratch. > Note that in the axioms, you don't need to care about non-strictness > or continuity, i.e. you can write: > > logic HasCASL > from HasCASL/Recursion get Recursion > spec sp1 = Recursion then > sorts s,t,u > op f:?s --> ?t; g:?t-->?u; h:?s-->?u > forall x:s > . h(x) = g(f(x)) > end > > Moreover, you should try to achieve maximum generality. That is, if > you can use ?s->?t instead of ?s-->?t, then I would do so, because > it is more general (any partial non-strict continuous function > also is a partial non-strict function). However, some > higher-order may require a continuous function as argument, > so then you might need the more special profile. > > The next issue is datatypes. To define the Haskell lazy lists in > HasCASL, you write: > > from HasCASL/Recursion get Recursion > spec sp2 = Recursion then > var a : Cpo > free domain List a ::= nil | cons (?a) (? List a)? > end > > However, free domains are not implemented in Hets yet. > Christian, can you implement them? > Currently, you can use a "free type" instead of the "free domain"; > then the specification at least parses. But you get > cons : forall a : Cpo . ? a -> ? List a ->? List a > instead of > cons : forall a : Cpo . ? a --> ? List a -->? List a > so a quick workaround to get the correct typing for experiments > could be just to add this profile of cons manually. > > Greetings, > Till > > Glauber Cabral schrieb: > > > > Hi Maeder, Till and haskell devs. > > > > Sorry by the long time to this reply. > > I've trying to find some papers that talk about partial/total > > functions in Haskell but I didn't find anyone yet. > > > > I've got in doubt about Maeder' suggestion about re-define Boolean > > because it has total functions. > > I'm not sure if all functions in Haskell are partial or if the > > suggestion is related to bottom value. > > > > Do you know any paper that describes the model of functions in > > Haskell? That is, when functions are partial (or if all of them are > > partial because of the bottom value)? > > > > I was thinking... If all functions are partial, should all specs be > > redefined to use partial functions, in special the numerical > > specifications? If it is true, I guess almost anything can be imported > > and almost everything must be redefined. Does it make any sense? > > > > Thanks in advance, > > Glauber Cabral > > > > On Tue, Mar 11, 2008 at 1:11 PM, Christian Maeder > > wrote: > >> Hi Glauber, > >> > >> (sorry for mixing up your first- and surname.) > >> > >> > >> Glauber Cabral wrote: > >> > fun __==__: ?a -> ?a -> ?Bool > >> > fun __/=__: ?a -> ?a -> ?Bool > >> > >> HasCASL mixfix identifiers are not compatible with curried functions > >> like in Haskell or Isabelle, but they need tuple arguments as in CASL: > >> > >> > >> > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:39.18, > >> > expected tuple argument for '__==__' > >> > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:40.18, > >> > expected tuple argument for '__/=__' > >> > >> this is the corresponding warning. > >> > >> > >> > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, > >> > in type of '((fun __/=__ : forall a : Eq . ? a -> ? a -> ? Bool) > >> > ((var x : ? a), (var y : ? a)), > >> > (op True : Bool))' > >> > typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) > >> > is not unifiable with type '? (a * a) -> ? Bool' > >> > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) > >> > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, > >> > untypeable term (with type: ? _v45_a * ? _v45_a) '(x /= y, True)' > >> > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.15, > >> > no typing for 'x /= y = True' > >> > >> The application of the curried "__/=__" to a tuple as a single first > >> argument leaves a function that expects another tuple of the same type > >> as second argument > >> > >> > >> > As I could see, True is not lazy and so the types could'n be unified. > >> > Is this correct? > >> > >> No, usually laziness is ignored when types are unified. > >> > >> Cheers Christian > >> > >> P.S. I recommend to re-define the Boolean datatype in HasCASL, because > >> > >> ops Not__ : Boolean -> Boolean; > >> __And__, __Or__ : Boolean * Boolean -> Boolean > >> > >> are all total functions. > >> > > _______________________________________________ > > Hets-devel mailing list > > Hets-devel at mailhost.informatik.uni-bremen.de > > http://www.informatik.uni-bremen.de/mailman/listinfo/hets-devel > > > > > -- > Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 > DFKI Lab Bremen Fax +49-421-218-9864226 > Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de > Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till > > Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH > principal office, *not* the address for mail etc.!!!: > Trippstadter Str. 122, D-67663 Kaiserslautern > management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff > supervisory board: Prof. Hans A. Aukes (chair) > Amtsgericht Kaiserslautern, HRB 2313 > From Christian.Maeder at dfki.de Tue Mar 25 14:48:14 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue, 25 Mar 2008 14:48:14 +0100 Subject: [Hets-devel] About equality and instance declarations In-Reply-To: References: Message-ID: <47E9029E.9050003@dfki.de> Glauber Cabral wrote: > Another question is about (not, /\, \/) and (Not, &&, ||) that I've > defined in new spec Bool (line 77 has an example). The built-in operators are correct for specifications, whereas the user defined operators (as executable functions) should be used in programs (that may come in later by using the keyword "program"). Both variants may be correct. Christian From Till.Mossakowski at dfki.de Tue Mar 25 17:09:03 2008 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Tue, 25 Mar 2008 17:09:03 +0100 Subject: [Hets-devel] About typing error In-Reply-To: References: <47D65C72.7080501@dfki.de> <47D6AF4D.9040700@dfki.de> <47E8ECE6.1030803@dfki.de> Message-ID: <47E9239F.70508@dfki.de> Hi Glauber, you are right: the style with cpos and continuous functions is quite near to Haskell programs. You can also use the more abstract style with partial non-strict functions. However, when you want to specify the type of potentially infinite lazy lists, you need to use a free domain. If you use a free type, you will get only finite lists. The latter of course is OK in many situations, and you can also use finite lists to specify many of the usual Haskell functions on lists. Perhaps this even is a better starting point than trying to immediately capturing the full Haskell datatypes, including infinite objects (which can be much more difficult in terms of proofs). Greetings, Till Glauber Cabral schrieb: > Hi Till. > > I've read about recursion and free domain in "HasCASL: Integrated > Higher-Order Specification and Program Development" but then I found > HasCASL/List definition and I've used it. I thought free domain should > only be used when coding inside program keyword. And know I'm not sure > if everything I've coded should have definitions with the program > keyword. > > Another question: Should everything I'm specifying follow the 3 items > of page 52 (Animating executable HasCASL specifications in Haskell), > because I'm specifying things that already are haskell code? That is, > all types be instances of Cpo and/or Cppo, etc? > > I guess I need to read this paper again because some fundamental > points are not clear to me yet. Sometimes I'm not sure if I'm > specifying in CASL or HasCASL and if I'm doing it write. I've already > read some codes from the library to try to fix this in mind, but it's > still not clear. > > I'll start reading this today. > Thanks for the advices! > > Glauber Cabral > > On Tue, Mar 25, 2008 at 9:15 AM, Till Mossakowski > wrote: >> Dear Glauber, >> >> sorry that we have not discussed this issue earlier with you. >> It is a quite fundamental issue. >> A Haskell function f : s -> t becomes f : ?s --> ?t in HasCASL >> (i.e. a partial non-strict continuous function). You obtain >> cpos and continuous functions from the specifcation Recursion. >> Indeed, this means that you have to define many things newly from >> scratch. >> Note that in the axioms, you don't need to care about non-strictness >> or continuity, i.e. you can write: >> >> logic HasCASL >> from HasCASL/Recursion get Recursion >> spec sp1 = Recursion then >> sorts s,t,u >> op f:?s --> ?t; g:?t-->?u; h:?s-->?u >> forall x:s >> . h(x) = g(f(x)) >> end >> >> Moreover, you should try to achieve maximum generality. That is, if >> you can use ?s->?t instead of ?s-->?t, then I would do so, because >> it is more general (any partial non-strict continuous function >> also is a partial non-strict function). However, some >> higher-order may require a continuous function as argument, >> so then you might need the more special profile. >> >> The next issue is datatypes. To define the Haskell lazy lists in >> HasCASL, you write: >> >> from HasCASL/Recursion get Recursion >> spec sp2 = Recursion then >> var a : Cpo >> free domain List a ::= nil | cons (?a) (? List a)? >> end >> >> However, free domains are not implemented in Hets yet. >> Christian, can you implement them? >> Currently, you can use a "free type" instead of the "free domain"; >> then the specification at least parses. But you get >> cons : forall a : Cpo . ? a -> ? List a ->? List a >> instead of >> cons : forall a : Cpo . ? a --> ? List a -->? List a >> so a quick workaround to get the correct typing for experiments >> could be just to add this profile of cons manually. >> >> Greetings, >> Till >> >> Glauber Cabral schrieb: >> >> >>> Hi Maeder, Till and haskell devs. >> > >> > Sorry by the long time to this reply. >> > I've trying to find some papers that talk about partial/total >> > functions in Haskell but I didn't find anyone yet. >> > >> > I've got in doubt about Maeder' suggestion about re-define Boolean >> > because it has total functions. >> > I'm not sure if all functions in Haskell are partial or if the >> > suggestion is related to bottom value. >> > >> > Do you know any paper that describes the model of functions in >> > Haskell? That is, when functions are partial (or if all of them are >> > partial because of the bottom value)? >> > >> > I was thinking... If all functions are partial, should all specs be >> > redefined to use partial functions, in special the numerical >> > specifications? If it is true, I guess almost anything can be imported >> > and almost everything must be redefined. Does it make any sense? >> > >> > Thanks in advance, >> > Glauber Cabral >> > >> > On Tue, Mar 11, 2008 at 1:11 PM, Christian Maeder >> > wrote: >> >> Hi Glauber, >> >> >> >> (sorry for mixing up your first- and surname.) >> >> >> >> >> >> Glauber Cabral wrote: >> >> > fun __==__: ?a -> ?a -> ?Bool >> >> > fun __/=__: ?a -> ?a -> ?Bool >> >> >> >> HasCASL mixfix identifiers are not compatible with curried functions >> >> like in Haskell or Isabelle, but they need tuple arguments as in CASL: >> >> >> >> >> >> > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:39.18, >> >> > expected tuple argument for '__==__' >> >> > ### Warning /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:40.18, >> >> > expected tuple argument for '__/=__' >> >> >> >> this is the corresponding warning. >> >> >> >> >> >> > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, >> >> > in type of '((fun __/=__ : forall a : Eq . ? a -> ? a -> ? Bool) >> >> > ((var x : ? a), (var y : ? a)), >> >> > (op True : Bool))' >> >> > typename 'Bool' (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:23.26) >> >> > is not unifiable with type '? (a * a) -> ? Bool' >> >> > (/home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:41.23) >> >> > ### Hint /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.14-45.25, >> >> > untypeable term (with type: ? _v45_a * ? _v45_a) '(x /= y, True)' >> >> > *** Error /home/glauber/GlauberMSc/C?digo/Prelude/Prelude.het:45.15, >> >> > no typing for 'x /= y = True' >> >> >> >> The application of the curried "__/=__" to a tuple as a single first >> >> argument leaves a function that expects another tuple of the same type >> >> as second argument >> >> >> >> >> >> > As I could see, True is not lazy and so the types could'n be unified. >> >> > Is this correct? >> >> >> >> No, usually laziness is ignored when types are unified. >> >> >> >> Cheers Christian >> >> >> >> P.S. I recommend to re-define the Boolean datatype in HasCASL, because >> >> >> >> ops Not__ : Boolean -> Boolean; >> >> __And__, __Or__ : Boolean * Boolean -> Boolean >> >> >> >> are all total functions. >> >> >> > _______________________________________________ >> > Hets-devel mailing list >> > Hets-devel at mailhost.informatik.uni-bremen.de >> > http://www.informatik.uni-bremen.de/mailman/listinfo/hets-devel >> > >> >> >> -- >> Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 >> DFKI Lab Bremen Fax +49-421-218-9864226 >> Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de >> Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till >> >> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH >> principal office, *not* the address for mail etc.!!!: >> Trippstadter Str. 122, D-67663 Kaiserslautern >> management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff >> supervisory board: Prof. Hans A. Aukes (chair) >> Amtsgericht Kaiserslautern, HRB 2313 >> -- Till Mossakowski Cartesium, room 2.051 Phone +49-421-218-64226 DFKI Lab Bremen Fax +49-421-218-9864226 Safe & Secure Cognitive Systems Till.Mossakowski at dfki.de Enrique-Schmidt-Str. 5, D-28359 Bremen http://www.dfki.de/sks/till Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH principal office, *not* the address for mail etc.!!!: Trippstadter Str. 122, D-67663 Kaiserslautern management board: Prof. Wolfgang Wahlster (chair), Dr. Walter Olthoff supervisory board: Prof. Hans A. Aukes (chair) Amtsgericht Kaiserslautern, HRB 2313