August 2001 - Libraries

RE: Proposed change to Dynamic library: mark it unsafe
by Simon Marlow 22 Aug '01

22 Aug '01

> Wouldn't be possible to make Dynamic derivable or something (better: > with a magic default definition of typeOf, so the instance can be > made after the type definition)? Yes, I'd like to do this in GHC at some point. Simon

1 0

Re: Proposed change to Dynamic library: mark it unsafe
by Marcin 'Qrczak' Kowalczyk 21 Aug '01

21 Aug '01

20 Aug 2001 15:46:04 -0600, Alastair David Reid <reid(a)cs.utah.edu> pisze: > An obvious fix would be to change the method name from "typeOf" to > "unsafeTypeOf" - reflecting the fact that a bad definition breaks type > safety and can lead to segmentation faults. But this wrongly labels > uses of typeOf as being unsafe when it's definitions which are > (potentially) unsafe. Wouldn't be possible to make Dynamic derivable or something (better: with a magic default definition of typeOf, so the instance can be made after the type definition)? If the compiler could figure out a good definition itself, it would not only solve the safety problem, but made using Dynamic easier: I always have to look up how a Dynamic instance should look like. Yes, it requires magic in the compiler, but Dynamic is already unimplementable in standard Haskell. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Proposed change to Dynamic library: mark it unsafe
by Simon Marlow 21 Aug '01

21 Aug '01

> Proposal: > > Replace the class: > > class Typeable a where typeOf :: a -> Type > > with: > > typeOf :: Typeable a => a -> Type > typeOf = unsafeTypeOf > > class Typeable a where unsafeTypeOf :: a -> Type > > All existing calls of typeOf should be left as they are. > All existing instance declarations should be changed to define > unsafeTypeOf instead. Hmmm. I normally associate something called 'unsafeBlah' with being unsafe to use, not unsafe to define, so this seems a little odd. But I don't have any better suggestions, and I agree that there ought to be at least some indication that there's potential unsafety here. > We also need to clarify the rules for writing correct definitions. > I propose the following concise (but non-constructive) rules: > > 1) New instances must preserve the invariant that for all values x and > y with monomorphic types, > > typeOf x == typeOf y iff x and y have the same type. > > It is not sufficient for the types of x and y to have the same > representation or to be isomorphic - they have to be considered > identical by the Haskell type system. [This last sentence is > redundant but may be helpful.] > > 2) For any (possibly bottom) value x whose type is an instance of > Typeable, > > typeOf x /= _|_ and does not raise an exception > > Examples of valid and invalid definitions would also be useful. Fully agree. The documentation is in CVS and you have commit access, I believe :-) (at least for the old libs, I haven't brought any docs across to the new libraries yet). Cheers, Simon

1 0

Proposed change to Dynamic library: mark it unsafe
by Alastair David Reid 20 Aug '01

20 Aug '01

This morning, there was a bug report on the ghc bug list reporting that they were able to crash ghci using a bad instance of typeOf (a method in Dynamic/Typeable). The report recognised that the problem was in the instance decl but wasn't sure exactly what was wrong or what the rules were. This report got me thinking... The Haskell libraries are fairly consistent about using the word "unsafe" on any function which could break type safety, referential transparency, etc. if misused. An exception to this is the typeOf method which the Dynamic library blindly assumes you have defined correctly. Lacking the hint that this is an "unsafe" feature, beginners could well believe that any definition they use will work (meaning "not crash Haskell") when, in fact, there are a bunch of subtle issues in how it interacts with polymorphism. An obvious fix would be to change the method name from "typeOf" to "unsafeTypeOf" - reflecting the fact that a bad definition breaks type safety and can lead to segmentation faults. But this wrongly labels uses of typeOf as being unsafe when it's definitions which are (potentially) unsafe. We can avoid this problem by separating definitions from uses. Proposal: Replace the class: class Typeable a where typeOf :: a -> Type with: typeOf :: Typeable a => a -> Type typeOf = unsafeTypeOf class Typeable a where unsafeTypeOf :: a -> Type All existing calls of typeOf should be left as they are. All existing instance declarations should be changed to define unsafeTypeOf instead. We also need to clarify the rules for writing correct definitions. I propose the following concise (but non-constructive) rules: 1) New instances must preserve the invariant that for all values x and y with monomorphic types, typeOf x == typeOf y iff x and y have the same type. It is not sufficient for the types of x and y to have the same representation or to be isomorphic - they have to be considered identical by the Haskell type system. [This last sentence is redundant but may be helpful.] 2) For any (possibly bottom) value x whose type is an instance of Typeable, typeOf x /= _|_ and does not raise an exception Examples of valid and invalid definitions would also be useful. -- Alastair Reid reid(a)cs.utah.edu http://www.cs.utah.edu/~reid/

1 0

Random library???
by Marcelo de Souza Sampaio 18 Aug '01

18 Aug '01

I am a new user. I using Hugs for windows version: february 2001. I tried to use a random library to obtain a int random number, but i don't know how. Anybody can help me! Thanks!!!! Marcelo de Souza Sampaio

1 0

RE: I Hate IO
by Simon Marlow 16 Aug '01

16 Aug '01

> I really like the idea of a source and sink class, among > other things it > would allow things like a sink which spit out a cryptographic hash of > everything that went through it discarding the data itself. > or one which > droped everything to an in-heap list. or even one that split the data > into two and sent it to multiple sinks... such a framework > would be very > useful in real world programming. It sounds like what we really need is a way to build your own Handles, so you can define these kind of filters. Anyone want to suggest an interface? > also, Haskell really really needs a standard 'Byte' type rather than > confusing Char, but I have ranted about this before, I am glad to see > other people think the same thing... :).. Word8 is the standard byte type. You can read bytes from a file like this (untested): readNBytes :: Handle -> Int -> IO [Word8] readNBytes h n = allocaBytes n $ \(p :: Ptr Word8) -> hGetBuf h p n peekArray p n allocaBytes and peekArray are part of the standard FFI libraries, and hGetBuf is originally from GHC's IOExts, but I don't see a reason why it shouldn't be part of the standard IO interface (in fact I've exported it from System.IO in the core libraries). Cheers, Simon

1 0

Re: I Hate IO
by Ketil Malde 16 Aug '01

16 Aug '01

Alastair David Reid <reid(a)cs.utah.edu> writes: > > My solution would be to have the API "random-access" based, and then > > have a type that provided the current stream-based interface (which > > I would use for your example): > Operating systems, IO libraries, etc. like sequential access because > they can play all sorts of tricks with reading ahead, buffering, > etc. to overcome the latency of the physical disk and the overhead of > performing a system call. This makes a huge difference to > performance. It works because most access is sequential. Perhaps one solution is to have normal file IO as it is, focusing on sequential streams, along with sockets, pipes and what have you. And provide an entirely different construct for random access. Much like in C where you'd use getc(), fgets(), getline(), and so on for sequential access, but probably mmap() instead of fseek() if you want random access. Maybe. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: I Hate IO
by Simon Marlow 16 Aug '01

16 Aug '01

> I can only tell you what's useful for me as an API user. > Since there are > peculiar little differences between different kinds of > sockets, my ideal > would be every type of socket to have its own API functions, and then > common patterns brought together with classes. Ok, so the main alternatives are between - One API with a superset of the operations available on Handles. Some operations fail for some kinds of Handles. - A separate type and API for each kind of handle, defining only the operations available on that handle. Operations which several types of handle share are unified using classes. I agree the second option is conceptually cleaner, but I'm not sure I'm motivated enough to change given that the impact in terms of breaking existing code would be high. That's my opinion - perhaps others feel differently. There may be some useful middle ground that doesn't involve going the whole way, such as just separating streams and files. > >Why isn't writeEnd the same as close? > > On a TCP connection, one can still receive data after sending > an end. My > "close" is intended to be the last thing done with the > connection as an > object destructor: if called before sending and receiving > end, it would > simply forcibly close the connection. At least the current API should have a way of doing this - it only has SocketPrim.shutdown which you can't use on a Handle. > >Is there anything that is always a Source but not a Sink (or vice > >versa)? > > Oh yes, lots of things. Standard input/output/error for instance. One > might write code that did something like pipe from a Source > to a Sink, > and then one might want a Source constructed from a constant > array. Or > something. Stream-based encoding algorithms such as UTF-8 > might make use > of them: > > encodeUTF8:: SourceChar -> SourceWord8 Yes, I can see that being able to plug together arbitrary sources and sinks could be useful. You don't have to separate sources and sinks to do this though - if Handle were a class, then you could define new instances for a constant array Handle, or an encoding layer on top of a raw Handle. Cheers, Simon

3 2

Re: I Hate IO
by Ashley Yakeley 15 Aug '01

15 Aug '01

At 2001-08-13 08:29, Marcin 'Qrczak' Kowalczyk wrote: >Fri, 10 Aug 2001 18:31:24 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > >> I can only tell you what's useful for me as an API user. Since there are >> peculiar little differences between different kinds of sockets, my ideal >> would be every type of socket to have its own API functions, and then >> common patterns brought together with classes. > >It makes harder to program polymorphically. In particular having >a heterogeneous datastructure requires wrapping different types >in either function closures or existential types, thus awkwardly >emulating the current interface. Do you have an example? Can't you simply substitute something like "(Connection c) => c" for "Handle"? >Items which are used interchangeably shouldn't have different types >in a language like Haskell which doesn't provide subtyping. Isn't that what classes are for? I've noticed that the more I use Haskell, the less I miss subtyping... classes and "data" unions are almost always sufficient. But perhaps you have an example which would really want subtyping, given an API for which every type of connection handle had its own type. ... >> But at the very least, separate out files from sockets. I'm really >> not sure why files have a "file pointer" stream-based API at all. > >Because it's convenient. Files are usually read sequentially. Files are mostly read in their entirety: but sometimes they are read in sequentially (e.g. parsers), and very occasionally read in "randomly" (e.g. pointer-based formats such as TIFF, or databases and the like). My solution would be to have the API "random-access" based, and then have a type that provided the current stream-based interface (which I would use for your example): -- data FileStream = MkFileStream { fsFile :: OpenFile, fsPointer :: Integer } instance Closable FileStream where ... instance Source FileStream where ... instance Sink FileStream where ... -- With the current API, one can provide a "random-access" based interface something like this: -- data OpenFile = MkOpenFile { ofHandle :: Handle, ofLock :: ThreadLock -- or whatever } readFileBlock :: OpenFile -> Integer -> Integer -> IO [Word8] readFileBlock file start length = synchronized (ofLock file) do { let {handle = ofHandle file}; hSeek handle AbsoluteSeek start; ... repeatedly call hGetChar handle ... } ... etc. -- ...provided a way of shortening a file was provided and the API used Word8s instead of Chars. This just seems a whole lot uglier. I don't know much about Haskell's multithreaded support, but if one wanted multiple threads using the same file, you'd need some kind of thread-locking (as suggested above). By contrast, with a "random-access" API it might even be possible to allow multiple simultaneous read operations. But I admit my preference is essentially aesthetic. Files are by nature accessible at any point, but we choose to pretend that they are streams (because that's convenient most of the time) and then we have to jump through hoops to make the streaminess go away when want actual direct access to arbitrary offsets. My preference for libraries is for interfaces that reveal the true nature of the object as accurately as possible, and to make explicit all the little patterns and conversions that programmers like to use. I believe Haskell is powerful enough to do this cleanly even without subtyping... the advantage is essentially the same advantage as strong typing: more errors are caught at compile-time. You can no longer write to standard input, or seek on a TCP connection, or get the remote IP address of an AppleTalk connection, etc. -- Ashley Yakeley, Seattle WA

2 1

Re: I Hate IO
by Marcin 'Qrczak' Kowalczyk 14 Aug '01

14 Aug '01

Mon, 13 Aug 2001 18:46:49 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > Do you have an example? Can't you simply substitute something like > "(Connection c) => c" for "Handle"? Fortunately usually it's enough to read the contents and pass it as a lazy String, instead of passing the Handle itself. This is what I've done in a program which reads data from either a socket or file. In this case it doesn't matter. If the handle had to be passed explicitly (say, because it's for output), having different types would work only sometimes. It would require encapsulating the portion of the program working on a handle into a polymorphic function, which is not always possible. For example if a collection of handles of different types is formed, it just wouldn't work. Putting objects of different types in a list requires wrapping them in a common type. Having a common class is not enough. In a language without subtyping types must more closely reflect the interface rather than the implementation. >>Items which are used interchangeably shouldn't have different types >>in a language like Haskell which doesn't provide subtyping. > > Isn't that what classes are for? Only sometimes. > I've noticed that the more I use Haskell, the less I miss > subtyping... classes and "data" unions are almost always sufficient. They are sometimes a better match than subtyping (e.g. parametrizing a gcd algorithm by a type) and sometimes they are not capable at all (e.g. heterogeneous collections when the set of possible types is open). I'm a big fan of Haskell's typing and I'm not a fan of OOP, but Haskell is sometimes not as expressible as the OO way. I have recently written an interpreter of a little language. The runtime allows the following values: imperative functions, terms, integers, and strings. Many other objects can be provided as functions (e.g. variables, dictionaries, file handles, dispatching on types of function arguments, lazy evaluation), as long as their interface only exchange objects of the above types. But adding floating point numbers would require changing the runtime (or stupid inefficiencies of exchanging numbers as strings), because they need binary methods. Even if you checked that a function nearby indeed represents a floating point number, you couldn't reach its value as a Double! About the only solution without changing the runtime for each new type which needs binary methods is to add a value holding a Dynamic. Classes won't help. Parametrization of objects of the interpreted language by a type of foreign (Haskell) objects it may contain doesn't make sense. It may contain objects of many types, and these types are not known statically. It wouldn't be a problem for a traditional OO language with checked downcasting. They are like Dynamic, only better integrated with the language, and with some interface hierarchy (you don't need to know the precise type, some its interface is enough). Function closures may overcome the problem of wrapping diverse types in a common intreface, but it's not always possible. It doesn't allow downcasting, you can only use the statically known interface. A similar problem is in raising exceptions in Haskell. Ghc has an exception holding a Dynamic precisely because the standard type system can't express an open set of exception types without parametrizing each action by exceptions it may throw. > I don't know much about Haskell's multithreaded support, but if > one wanted multiple threads using the same file, you'd need some > kind of thread-locking (as suggested above). By contrast, with a > "random-access" API it might even be possible to allow multiple > simultaneous read operations. You can have multiple Handles referring to the same physical file. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0