From Till.Mossakowski at dfki.de Thu Oct 11 10:33:34 2007 From: Till.Mossakowski at dfki.de (Till Mossakowski) Date: Thu, 11 Oct 2007 10:33:34 +0200 Subject: [Hets-devel] Adding a logic to hets In-Reply-To: <59593.83.143.40.158.1192050177.squirrel@mail.mimuw.edu.pl> References: <59593.83.143.40.158.1192050177.squirrel@mail.mimuw.edu.pl> Message-ID: <470DDFDE.2050906@dfki.de> Dear Artur, you are right, the types SYMB_ITEMS etc. are not parameterized. These types are quite small. There is always the tradeoff between the need to re-implement similar things and the complexity added by making things parametric using type variables. However, we can re-discuss this issue. Perhaps there are enough arguments in favour of parameterizing SYMB_ITEMS etc. as well. What do the others think? Greetings, Till Artur Zawlocki schrieb: > Dear Till, > I started playing with the source code trying to add a logic extending > Casl. The extension adds new kind of symbols to signatures (event symbols) > and new kinds of formulas (temporal formulas with Until, Since and so on). > For formulas, signatures, morphisms the extension was straightforward > thanks to the type variables in datatypes but then I stumbled upon > datatypes for symbol maps (SYMB, TYPE etc.) that are not parametrised. Is > it an omission or is there a reason why they are not polymorphic? It seems > that in order to cover event symbols I need to redefine types and > functions for symbol maps. > > Best regards, > Artur Zaw?ocki > > > -- 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 Thu Oct 11 12:35:33 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 11 Oct 2007 12:35:33 +0200 Subject: [Hets-devel] Adding a logic to hets In-Reply-To: <470DDFDE.2050906@dfki.de> References: <59593.83.143.40.158.1192050177.squirrel@mail.mimuw.edu.pl> <470DDFDE.2050906@dfki.de> Message-ID: <470DFC75.5010100@dfki.de> Hi Artur, Till Mossakowski wrote: > However, we can re-discuss this issue. Perhaps there are enough > arguments in favour of parameterizing SYMB_ITEMS etc. as well. > Artur Zawlocki schrieb: >> Dear Till, >> I started playing with the source code trying to add a logic extending >> Casl. The extension adds new kind of symbols to signatures (event symbols) I don't know how your event symbols will look like. But assuming you only need "event " (and even "event : ") it should suffice to plainly extend the (enumeration) types CASL.AS_Basic_CASL.SYMB_KIND and CASL.Morphism.Kind. Cheers Christian From zawlocki at mimuw.edu.pl Thu Oct 11 14:30:53 2007 From: zawlocki at mimuw.edu.pl (Artur Zawlocki) Date: Thu, 11 Oct 2007 14:30:53 +0200 (CEST) Subject: [Hets-devel] Adding a logic to hets In-Reply-To: <470DFC75.5010100@dfki.de> References: <59593.83.143.40.158.1192050177.squirrel@mail.mimuw.edu.pl> <470DDFDE.2050906@dfki.de> <470DFC75.5010100@dfki.de> Message-ID: <4865.83.143.40.158.1192105853.squirrel@mail.mimuw.edu.pl> On Thu, October 11, 2007 12:35 pm, Christian Maeder wrote: > Hi Artur, > > Till Mossakowski wrote: >> However, we can re-discuss this issue. Perhaps there are enough >> arguments in favour of parameterizing SYMB_ITEMS etc. as well. > >> Artur Zawlocki schrieb: >>> Dear Till, >>> I started playing with the source code trying to add a logic extending >>> Casl. The extension adds new kind of symbols to signatures (event >>> symbols) > > I don't know how your event symbols will look like. But assuming you > only need "event " (and even "event : ") Semantics aside, they are like predicate symbols, i.e. I have "evt E : Nat" in signatures and "E(0)" is an atomic formula, so I can use CASL.AS_Basic_CASL.PRED_TYPE in some cases, e.g. I have data TYPE = O_type CaslAS.OP_TYPE | ..(as for CASL).. | E_type CaslAS.PRED_TYPE (where CaslAS is an alias for CASL.AS_Basic_CASL). > it should > suffice to plainly extend the (enumeration) types > CASL.AS_Basic_CASL.SYMB_KIND and CASL.Morphism.Kind. Yes, and CASL.AS_Basic_CASL.TYPE and CASL.Sign.SymbType, and all types that depend on them, and all functions manipulating values of those types, which includes those exported from CASL.SymbolMapAnalysis, even though they are already parametrised with (CASL.Morphism.Ext f e m). Would you recommend simply copying relevant type and function definitions from CASL/ and extending them with appropriate clauses for events, or is there a more elegant way to do this? Perhaps I do not have to distinguish event symbols from predicate symbols as far as symbol maps are concerned -- I will take a closer look at the code later on. Thanks for a quick reply. Cheers, Artur From Christian.Maeder at dfki.de Thu Oct 11 15:17:44 2007 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu, 11 Oct 2007 15:17:44 +0200 Subject: [Hets-devel] Adding a logic to hets In-Reply-To: <4865.83.143.40.158.1192105853.squirrel@mail.mimuw.edu.pl> References: <59593.83.143.40.158.1192050177.squirrel@mail.mimuw.edu.pl> <470DDFDE.2050906@dfki.de> <470DFC75.5010100@dfki.de> <4865.83.143.40.158.1192105853.squirrel@mail.mimuw.edu.pl> Message-ID: <470E2278.6090500@dfki.de> Artur Zawlocki wrote: > Semantics aside, they are like predicate symbols, i.e. I have "evt E : > Nat" in signatures and "E(0)" is an atomic formula, so I can use > CASL.AS_Basic_CASL.PRED_TYPE in some cases, e.g. I have > > data TYPE = O_type CaslAS.OP_TYPE > | ..(as for CASL).. > | E_type CaslAS.PRED_TYPE No, I would not want to extend this type TYPE, since the parser cannot distinguish predicate types for events or plain predicates anyway. >> it should >> suffice to plainly extend the (enumeration) types >> CASL.AS_Basic_CASL.SYMB_KIND and CASL.Morphism.Kind. > > Yes, and CASL.AS_Basic_CASL.TYPE and CASL.Sign.SymbType, and all types > that depend on them, and all functions manipulating values of those types, CASL.Sign.SymbType would need to be extended or changed to: SymbType = SymbType Kind [SORT] > which includes those exported from CASL.SymbolMapAnalysis, even though > they are already parametrised with (CASL.Morphism.Ext f e m). Would you > recommend simply copying relevant type and function definitions from CASL/ No, please don't copy the whole code (i.e. CASL.SymbolMapAnalysis)! I'll help you to integrate your extensions into CASL. > and extending them with appropriate clauses for events, or is there a more > elegant way to do this? Perhaps I do not have to distinguish event symbols > from predicate symbols as far as symbol maps are concerned -- I will take > a closer look at the code later on. Yes, have a look, too. Christian