July 2003 - Haskell - Haskell.org

System.Directory (was RE: Proposal for a new I/O library design)
by Hal Daume 29 Jul '03

29 Jul '03

Hi guys, I'm not replying to anything in the message, but... > Is the idea > to abstract away from the syntax of pathnames on the platform (eg. > directory separator characters)? If so, I'm not sure it's worthwhile. > There are lots of differences between pathname conventions: case > sensitivity, arbitrary limits on the lengh of filenames, filename > extensions, and so on. Would there be any way to get some of these differences into the System.Directory structure? At least the following would be nice: > pathSeparator :: Char > '\\' on Windows, '/' on unices, ':' (I believe) on macs, etc... > directorySeparator :: Char > ';' on Windows, ':' on unices, i have no idea on macs > isCaseSensitive :: Bool > False on Windows, True on (all?) unices, i have no idea on macs given just these, i think we'd all be a lot happier. I also don't particularly care whether these are IO operations or just values (so long as they are constant, they might as well be values with unsafePerformIO wrapped around them if necessary). My current approach to figuring this out is to create a directory, change to that directory, get the current path name and try to parse it. This is bad for so many reasons I won't enumerate them here. ...unless this stuff is hiding somewhere else, please let me know (but System.Directory would probably be a good place for it to end up)... - Hal

2 1

RE: Existentials...
by Hal Daume 28 Jul '03

28 Jul '03

Sure it's possible :)...using the GMap library...heres an implementation: > module PushF where > > import GMap.Adhoc > import GMap.GenericLib > import GMap.Term > import Data.Dynamic > > data F a b = forall c. (Typeable c, Term c) => PushF (a -> c) (F c b) > | Bottom (a -> b) > > _tc_F = mkTyCon "F" > instance (Typeable a, Typeable b) => Typeable (F a b) where > typeOf (_ :: F a b) = mkAppTy _tc_F [typeOf (undefined::a), typeOf (undefined::b)] > > instance (Term a, Term b) => Term (F a b) where > gmapT f (Bottom x) = Bottom x > gmapT f (PushF g h) = PushF g (f h) > gfoldl f z (Bottom x) = z (Bottom x) > gfoldl f z (PushF g h) = z (PushF g) `f` h > > getInner :: (Typeable a, Typeable b, Typeable c, Term (F a b)) => F a b -> c -> Maybe (F c b) > getInner (x :: F a b) (c :: c) = something (isCToB (undefined::c) (undefined::b)) x > > isCToB :: (Typeable t, Typeable c, Typeable b) => c -> b -> t -> Maybe (F c b) > isCToB (c::c) (b::b) t = cast t if we define this as you have: > f1 :: Char -> Bool > f1 'a' = True > f1 _ = False > > f2 :: Bool -> String > f2 = show > > f3 :: String -> Int > f3 = length > > fs :: F Char Int > fs = f1 `PushF` (f2 `PushF` (f3 `PushF` (Bottom id))) then we can do the following: *PushF> Maybe.isJust (getInner fs 'a') True *PushF> Maybe.isJust (getInner fs "hello") True *PushF> Maybe.isJust (getInner fs True) True *PushF> Maybe.isJust (getInner fs (1::Int)) True *PushF> Maybe.isJust (getInner fs (1::Float)) False *PushF> Maybe.isJust (getInner fs ()) False hope this helps. - hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of Amr A Sabry > Sent: Monday, July 28, 2003 2:22 PM > To: haskell(a)haskell.org > Cc: sabry(a)cs.indiana.edu > Subject: Existentials... > > > Hi, > > I believe this can be done with enough type hacking but I am not sure > how... > > Consider the use existentials to implement a list of composable > functions using something like: > > data F a b = > forall c. PushF (a -> c) (F c b) > | Bottom (a -> b) > > For example: > > f1 :: Char -> Bool > f1 'a' = True > f1 _ = False > > f2 :: Bool -> String > f2 True = "true" > f2 False = "false" > > f3 :: String -> Int > f3 = length > > fs :: F Char Int > fs = PushF f1 (PushF f2 (PushF f3 (Bottom id))) > > Is it possible to write a function > f :: F a b -> T c -> F c b > where (T c) is some type for values of type 'c' or values representing > the type 'c' or whatever is appropriate. Thus if given the > representation of Bool, the function should return: > PushF f2 (PushF f3 (Bottom id)) > and if given the representation of String the function should return > PushF f3 (Bottom id) > and so on. > > I hope the question makes sense. Thanks. --Amr > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

Re: System.Directory (was RE: Proposal for a new I/O library design)
by Wolfgang Thaller 28 Jul '03

28 Jul '03

>> pathSeparator :: Char >> '\\' on Windows, '/' on unices, ':' (I believe) on macs, etc... Used to be ':' in Classic MacOS, and there are still some old routines in Apple's Carbon library that take ':'-separated paths. However, Apple always insisted that Pathnames should only be used for display purposes, mostly because a pathname did not always uniquely identify a file (!). Mac OS X uses "normal" unix-style paths for everything that concerns us. Also, the "Classic" Mac-style paths had different semantics (no "." or "..", etc.), so treating them would have been more difficult than just using a different separator. Fortunately, they're a thing of the past. >> directorySeparator :: Char >> ';' on Windows, ':' on unices, i have no idea on macs As there was no command line, no PATH, and no textual config files on classic Mac OS, there is no mac-specific directory separator, so it's ':'. (although I think that stealing yet another character from > >> isCaseSensitive :: Bool >> False on Windows, True on (all?) unices, i have no idea on macs It's not that easy. Case sensitivity is a property of a file system, not of the operating system. So if you mount a Windows or Mac OS volume on a Linux system, the filenames on that volume will still be case-insensitive (but case-preserving). On Mac OS X, the default file system type is HFS+ (a.k.a. Mac OS Extended), which is case insensitive, but you can also choose UFS (case sensitive). You could also have both, on two partitions. Of course, "False" for Windows and MacOS, "True" for everything else is a reasonable guess, but you can't rely on it. Right now I have no idea how to implement something like isCaseSensitive :: FilePath -> IO Bool which would determine whether a specific path would be case sensitive. Maybe it's worth the effort to think about it. > given just these, i think we'd all be a lot happier. I agree. If the last one can be implemented properly, that is. Cheers, Wolfgang

3 2

Existentials...
by Amr A Sabry 28 Jul '03

28 Jul '03

Hi, I believe this can be done with enough type hacking but I am not sure how... Consider the use existentials to implement a list of composable functions using something like: data F a b = forall c. PushF (a -> c) (F c b) | Bottom (a -> b) For example: f1 :: Char -> Bool f1 'a' = True f1 _ = False f2 :: Bool -> String f2 True = "true" f2 False = "false" f3 :: String -> Int f3 = length fs :: F Char Int fs = PushF f1 (PushF f2 (PushF f3 (Bottom id))) Is it possible to write a function f :: F a b -> T c -> F c b where (T c) is some type for values of type 'c' or values representing the type 'c' or whatever is appropriate. Thus if given the representation of Bool, the function should return: PushF f2 (PushF f3 (Bottom id)) and if given the representation of String the function should return PushF f3 (Bottom id) and so on. I hope the question makes sense. Thanks. --Amr

1 0

ANNOUNCE: Haddock version 0.5
by Simon Marlow 28 Jul '03

28 Jul '03

Haddock version 0.5 is released. Get it from here: http://www.haskell.org/haddock Not a great deal has changed from version 0.4, but you need the new version if you want to build it using recent versions of GHC. Also, several bugs have been fixed. This is the version of Haddock that we are using to generate docs for the hierarchical libraries that come with GHC. Cheers, Simon

2 1

Compositional Verification of UML Models
by M.M. Bonsangue 28 Jul '03

28 Jul '03

(We apologize for the reception of multiple copies) ************************ CALL FOR PAPER ***************************** Call for Papers Compositional Verification of UML Models Workshop of the UML 2003 Conference The definition of UML has been motivated by the need for a standard notation for modelling system architectures and behaviours at functional and implementation level. The main fqocus has been essentially on terminology, notation and syntax without addressing semantic, validation and methodology issues which are important for formal design and verification techniques. This workshop addresses the application of formal methods and techniques that exploit the architectural structure of UML models in a compositional manner. TOPICS The workshop topics include (but are not limited to): * semantic foundations of architectural and component-based design within UML * compositional techniques for the analysis embedded and real-time systems in UML * compositional model checking of UML behavioural models * compositional deductive methods based on OCL * methodologies based on compositional formal techniques FORMAT OF THE WORKSHOP The workshop will consist of presentations of the accepted papers, which will be the basis for an intensive discussion on the workshop topics. Extended abstracts of the presentations will be published after the workshop by Elsevier Science as a volume of the Electronic Notes in Theoretical Computer Science. For an up-to-date program and invited talks see the workshop web-site http://fmco.liacs.nl/compuml.html SUBMISSIONS Authors are invited to submit by August 25th an extended abstract not exceeding 20 pages electronically to F.S.de.Boer(a)cwi.nl. Submissions must be either in Postscript or PDF format and prepared for USLetter or A4 page sizes. Submissions will be evaluated by the program committee for inclusion in the proceedings, which will be published by Electronic Notes in Theoretical Computer Science series. Papers must contain original contributions, be clearly written, and include appropriate reference to and comparison with related work. Simultaneous submissions to other conferences are not allowed. IMPORTANT DATES 25 August Submission deadline 10 September Notification to authors 1 October Deadline for preliminary version 21 October Workshop date 21 November Deadline for final version PROGRAM COMMITTEE Frank de Boer (CWI, NL) Marcello Bonsangue (LIACS, NL) Werner Damm (OFFIS, DE) Susanne Graf (Verimag, France) David Harel (Weizmann Institute, Israel) Jozef Hooman (University of Nijmegen, NL) Bernhard Josko (OFFIS, DE) Amir Pnueli (Weizmann Institute, ISR) Willem-Paul de Roever (Kiel University, DE) Joseph Sifakis (Verimag, FR) ORGANIZERS Frank de Boer (CWI, NL) Marcello Bonsangue (LIACS, NL) Bernhard Josko (OFFIS, DE) SPONSORS This workshop is sponsored by the European R&D project OMEGA - Correct Development of Real-time Embedded Systems (http://www-omega.imag.fr) and the German-Dutch project Mobi-J (main sponsor of FMCO, http://fmco.liacs.nl)

1 0

Second International Symposium on Formal Methods for Components and Objects
by M.M. Bonsangue 28 Jul '03

28 Jul '03

(We apologize for the reception of multiple copies) *********************** CALL FOR PARTICIPATION ********************** Second International Symposium on Formal Methods for Components and Objects (FMCO 2003) DATES 4 - 7 November 2003 PLACE Lorentz Center, Leiden University, Leiden, The Netherlands URL http://fmco.liacs.nl/fmco03.html OBJECTIVES The objective of this symposium is to bring together researchers and practioners in the areas of software engineering and formal methods to discuss the concepts of reusability and modifiability in component-based and object-oriented software systems. FORMAT The symposium is a four days event in the style of the former REX workshops, organised to provide an atmosphere that fosters collaborative work, discussions and interaction. The program consists of keynote and technical presentations, and contains an exquisite social event. Speakers' contributions will be published after the symposium in Lecture Notes in Computer Science by Springer-Verlag. KEYNOTE SPEAKERS Desmond D'Souza (Kinetium, Austin, USA) E. Allen Emerson (University of Texas at Austin, USA) Andrew D. Gordon (Microsoft Research, UK) Yuri Gurevich (Microsoft Research, USA) Tony Hoare (Microsoft Research, UK) David Parnas (University of Limerick, IE) Joseph Sifakis (Verimag, FR) TECHNICAL PRESENTATIONS Albert Benveniste (IRISA/INRIA - Rennes, FR) Frank de Boer (CWI, NL) Egon Boerger (Pisa University, IT) Werner Damm (University of Oldenburg, DE) Razvan Diaconescu (IMAR, RO) Gregor Engels (University of Paderborn, DE) Jose Luiz Fiadeiro (University of Leicester, UK) Jan Friso Groote (Eindhoven University of Technology, NL) Jean-Marc Jezequel (IRISA, Rennes, FR) Bengt Jonsson (Uppsala University, SE) Yassine Lakhnech (University of Grenoble, FR) Rob van Ommering (Philips Research Laboratories, NL) Amir Pnueli (The Weizmann Institute of Science, ISR) Willem-Paul de Roever (University of Kiel, DE) Jan Rutten (CWI, Amsterdam, NL) Philippe Schnoebelen (CNRS, Cachan, FR) Natalia Sidorova (Eindhoven University of Technology, NL) Heike Wehrheim (University of Oldenburg, DE) Jeannette Wing (Carnegie Mellon University, USA) REGISTRATION Participation is limited to about 80 people, using a first-in first-served policy. To register, please fill in the registration form at http://fmco.liacs.nl/fmco03.html. The EARLY registration fee (BEFORE September 15, 2003) is 375 euro for regular participants and 250 euro for students It includes the participation to the symposium, a copy of the proceedings, all lunches and refreshments, and a social event (with dinner). ORGANIZING COMMITTEE F.S. de Boer (CWI and Utrecht University) M.M. Bonsangue (LIACS-Leiden University) S. Graf (Verimag) W.P. de Roever (CAU) For more information about participation and registration see the FMCO site above or consult either F.S. de Boer (frb(a)cwi.nl) or M.M. Bonsangue (marcello(a)liacs.nl)

1 0

RE: Proposal for a new I/O library design
by Simon Marlow 28 Jul '03

28 Jul '03

[ replies to libraries(a)haskell.org ] On the whole, I think this is a good direction to explore. I like the separation of Files from Streams: indeed it would remove much of the complication in the existing system caused by having Handles which can be both read and written. Also, it gives a nice way to integrate other objects such as Sockets into the I/O system, which can also have streams layered on top of them. I'm concerned about one implementation difficulty. Your File type is independent of the filesystem. That is, on Unix it corresponds to an inode. Creating a File must correspond to "opening" it (in Unix speak). Creating a stream corresponds to duplicating the file descriptor (you could probably avoid too many unnecessary dups by being clever). There's a potential implementation difficulty, though: lookupFileByPathname must open the file, without knowing whether the file will be used for reading or writing in the future. So I would suggest that operations which create a value of type File take a read/write flag too. > > type FilePos = Word64 > > type BlockLength = Int FilePos should be Integer. > > fCheckRead :: File -> FilePos -> BlockLength -> IO Bool > > fCheckWrite :: File -> FilePos -> BlockLength -> IO Bool What do these do? If they're supposed to return True if the required data can be read/written without blocking, then I suspect that they are not useful. > Fundamental operations on streams. "Maybe Octet" is supposed > to represent > "Octet or EOS," though I'm not sure this is enough for proper EOS > handling. I'd use the traditional 'isEOF' way of detecting end of file. On naming: it's probably not a good idea to use the 'is' prefix, since it is already used for predicates (meaning literally 'is' rather than an abbreviation for 'InputStream'). > > isGet :: InputStream -> IO (Maybe Octet) > > isPeek :: InputStream -> IO (Maybe Octet) > > isGetBlock :: InputStream -> BlockLength -> XXX -> IO BlockLength > > -- efficiency hack > > > > osPut :: OutputStream -> Octet -> IO () > > osPuts :: OutputStream -> [Octet] -> IO () > > osPutBlock :: OutputStream -> BlockLength -> XXX -> IO () > > osFlush :: OutputStream -> IO () You need operations to control buffering, too. Something like h{Set,Get}Buffering would be fine. You will also want a way to get back from an InputStream to the underlying object, eg. the (File,FilePos) pair if one exists. It's not pretty, but you certainly want a way to close a stream. Finalizers aren't reliable enough. How did you intend text encodings to work? I see several possibilities: textDecode :: TextEncoding -> [Octet] -> [Char] or decodeInputStream :: TextEncoding -> InputStream -> TextInputStream getChar :: TextInputStream -> IO Char etc. or setInputStreamCoding :: InputStream -> TextEncoding -> IO () getChar :: InputStream -> IO Char The first one is nice, but hard to optimise, and it will get complicated for encodings which have state. The second one is probably the best compromise. > > data Directory -- abstract I don't see a reason for changing the existing Directory support (System.Directory). Could you give some motivation here? Is the idea to abstract away from the syntax of pathnames on the platform (eg. directory separator characters)? If so, I'm not sure it's worthwhile. There are lots of differences between pathname conventions: case sensitivity, arbitrary limits on the lengh of filenames, filename extensions, and so on. > Convenient shortcuts for common cases. > > > lookupFileByPathname :: String -> IO File Here, I suggest we need lookupFileByPathname :: FilePath -> IOMode -> IO File > > lookupInputStreamByPathname :: String -> IO InputStream > > -- at least as likely to succeed as lookupFileByPathname and similarly createFileOutputStream :: FilePath -> IO OutputStream appendFile :: FilePath -> IO OutputStream Cheers, Simon

1 0

RE: dynamics on polymorphic datatype
by Hal Daume 26 Jul '03

26 Jul '03

If you only ever want to use dynamics on 'forall a. Foo a's, you can say: > module Foo where > import Data.Dynamic > data Foo a = Foo a > trFoo = mkTyCon "Foo" > forall_a = mkTyCon "a" > instance Typeable (Foo a) where > typeOf (x :: Foo a) = mkAppTy trFoo [mkAppTy forall_a []] You can use this: *Foo> typeOf (undefined :: Foo a) Foo a You can even introduce (so long as you have -fallow-overlapping-instances) specific other instances: > instance Typeable (Foo Int) where > typeOf _ = mkAppTy trFoo [typeOf (undefined :: Int)] > instance Typeable (Foo Bool) where > typeOf _ = mkAppTy trFoo [typeOf (undefined :: Bool)] But sadly you cannot use the original then: *Foo> typeOf (undefined :: Foo Int) Foo Int *Foo> typeOf (undefined :: Foo Bool) Foo Bool *Foo> typeOf (undefined :: Foo a) <interactive>:1: No instance for (Typeable (Foo a)) arising from use of `typeOf' at <interactive>:1 In the definition of `it': it = typeOf (undefined :: forall a. Foo a) i'm not sure why this happens (someone who knows the type system better than me can probably tell me). my guess is: it doesn't know what 'a' is, so it doesn't know whether to choose the generic instance or one of the overlapped instances (in case 'a' happened to be Int)...this seems to take away a lot of the power of overlapping instances, which i always saw as being able to define a "default" case. however, if you try something you haven't written an instance of, you do get this default case: *Foo> typeOf (undefined :: Foo Double) Foo a so, it kind of depends on what you want. probably you want exactly what didn't work; perhaps someone else has a more ingenious solution than mine... - hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume > -----Original Message----- > From: haskell-admin(a)haskell.org > [mailto:haskell-admin@haskell.org] On Behalf Of Wang Meng > Sent: Friday, July 25, 2003 9:13 PM > To: haskell(a)haskell.org > Subject: dynamics on polymorphic datatype > > > Hi All, > > I am trying to perform dynamic casting on polymorphic types. > Let's say I have a data type like: > > > data Foo a = Foo a > > Is there any way to use dynamics to convert a value of type Foo a to a > type reprentation? I try to use the toDyn in the dynamic libray, it > complains for ambigours a. Is there a solution to it? > > Thank you very much. > > > -W-M- > @ @ > | > \_/ > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

StrategyLib - need help
by Dmitry Astapov 26 Jul '03

26 Jul '03

I want to write generic traversal which prints everything on the way: uglyPrint :: (Term t, Show t) => t -> [(String)] uglyPrint = (map snd) . runIdentity . applyTU (full_tdTU uglyPrintStep) uglyPrintStep :: (Show t, Term t) => TU [(t, String)] Identity uglyPrintStep = constTU [] `adhocTU` (return . uglyPrintAny) uglyPrintAny x = [(x,show x)] ugliestPrintEver :: (Term t, Show t) => t -> IO () ugliestPrintEver x = do { putStrLn $ show x } Compiler (GHC 6.0) gives me: Ambiguous type variable `t' in these top-level constraints: `Term t' arising from use of `uglyPrintStep' at ... `Show t' arising from use of `uglyPrintStep' at ... All data types which are instances of Term are instances of Show as well - I know it. Question is - how to persuade GHC? I there any want to use typeclass restrictions with traversal, or there is no luck for me? -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D

3 4