From till at informatik.uni-bremen.de Tue Nov 2 12:58:22 2004 From: till at informatik.uni-bremen.de (Till Mossakowski) Date: Tue, 02 Nov 2004 12:58:22 +0100 Subject: [Hets-devel] Re: FatalError In-Reply-To: <41877001.7010105@tzi.de> References: <41877001.7010105@tzi.de> Message-ID: <4187765E.2060605@informatik.uni-bremen.de> Dear Christian, I cc this to hets-devel, since the Result monad is *the* central monad for error handling, which means that nearly every analysis function in Hets should have result type "Result a" for some a. I think the main difference between regular and fatal errors is that regular errors have a result (that is, the maybeResult component is of form Just x), while fatal errors have no result (the maybeResult component is Nothing). These two cases behave differently w.r.t. the bind operation >>= of the monad. A fatal error, i.e. a "Nothing" freezes the state and ignores every subsequent action, while an ordinary error allows for further computations. Hence I think we should keep the difference. Greetings, Till -- from Common/Result.hs data Result a = Result { diags :: [Diagnosis] , maybeResult :: (Maybe a) } deriving (Show) instance Monad Result where return x = Result [] $ Just x Result errs Nothing >>= _ = Result errs Nothing Result errs1 (Just x) >>= f = Result (errs1++errs2) y where Result errs2 y = f x fail s = fatal_error s nullPos Christian Maeder wrote: > Hallo, > > Den Fall "FatalError" will ich aus Result.hs entfernen. Die > Unterscheidung (zu "Error") ist kaum nachvollziehbar. Ein Result mit > Nothing hat mit "fatal" nichts zu tun, da diese F?lle h?ufig ignoriert > werden k?nnen (und weitere Fehler gesucht werden k?nnen). > > Irgendwelche Einw?nde? > > In GUI/hets_cgi.hs: else if "*** FatalError" == take > 14 hdiags then hdiags:str > > wird ein Fehlerstring abgefragt. Kann das einfach zu Error ge?ndert werden? > > Gru? Christian -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till at tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till From maeder at tzi.de Tue Nov 2 13:23:30 2004 From: maeder at tzi.de (Christian Maeder) Date: Tue, 02 Nov 2004 13:23:30 +0100 Subject: [Hets-devel] Re: FatalError In-Reply-To: <4187765E.2060605@informatik.uni-bremen.de> References: <41877001.7010105@tzi.de> <4187765E.2060605@informatik.uni-bremen.de> Message-ID: <41877C42.5000208@tzi.de> Till Mossakowski wrote: > I think the main difference between regular and fatal errors is that > regular errors have a result (that is, the maybeResult component > is of form Just x), while fatal errors have no result (the maybeResult > component is Nothing). These two cases behave differently w.r.t. the > bind operation >>= of the monad. A fatal error, i.e. a "Nothing" freezes > the state and ignores every subsequent action, while an ordinary error > allows for further computations. I agree, but the fatality of a "Result" is sufficiently characterized by "Nothing", since the DiagKind is (almost) nowhere inspected and only eventually printed as "FatalError". In order to avoid this "fat" output for my errors, I tend to construct my own Results with "Error" and "Nothing" and decide later on if I collect more errors (or stop by using >>=). > Hence I think we should keep the difference. Hence I propose to avoid redundant (multiple and possibly contradicting) indications of fatality. Greetings Christian From till at informatik.uni-bremen.de Tue Nov 2 14:19:25 2004 From: till at informatik.uni-bremen.de (Till Mossakowski) Date: Tue, 02 Nov 2004 14:19:25 +0100 Subject: [Hets-devel] Re: FatalError In-Reply-To: <41877C42.5000208@tzi.de> References: <41877001.7010105@tzi.de> <4187765E.2060605@informatik.uni-bremen.de> <41877C42.5000208@tzi.de> Message-ID: <4187895D.3050606@informatik.uni-bremen.de> Dear Christian, > I agree, but the fatality of a "Result" is sufficiently characterized by > "Nothing", since the DiagKind is (almost) nowhere inspected and only > eventually printed as "FatalError". In order to avoid this "fat" output > for my errors, I tend to construct my own Results with "Error" and > "Nothing" and decide later on if I collect more errors (or stop by using > >>=). > >> Hence I think we should keep the difference. > > > Hence I propose to avoid redundant (multiple and possibly contradicting) > indications of fatality. OK, agreed. This means to remove the DiagKind FatalError, but to keep two different operations fpr producing errors: fatal_error :: String -> Pos -> Result a plain_error :: a -> String -> Pos -> Result a Greetings, Till -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen till at tzi.de P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till From maeder at tzi.de Fri Nov 26 16:28:41 2004 From: maeder at tzi.de (Christian Maeder) Date: Fri, 26 Nov 2004 16:28:41 +0100 Subject: [Hets-devel] Re: Hets compiliert nicht In-Reply-To: <41A747DD.9050706@informatik.uni-bremen.de> References: <41A747DD.9050706@informatik.uni-bremen.de> Message-ID: <41A74BA9.7000707@tzi.de> if that (see below) happens do: make clean_genRules make if make fails with: Makefile:107: sources_hetcats.mk: Datei oder Verzeichnis nicht gefunden perl utils/create_sources.pl hetcats-make sources_hetcats.mk Error: Couldn't create sources!! make: *** [sources_hetcats.mk] Fehler 7 simply repeat your make command. HTH Christian Till Mossakowski wrote: > Bei mir bricht es mittendrin ab: > > Compiling ATC.Grothendieck ( ./ATC/Grothendieck.hs, ./ATC/Grothendieck.o ) > > ./ATC/Grothendieck.hs:12: > Warning: Module `ATC.Graph' is imported, but nothing from it is used > (except perhaps instances visible in `ATC.Graph') > Module imports form a cycle for modules: > ATC.AS_Structured > till at sohn-rethel:~/CASL/HetCATS>