- Haskell-Cafe - Haskell.org

RE: binary files in haskell
by Simon Marlow 07 Feb '01

07 Feb '01

> > How about this slightly more general interface, which works > with the new > > FFI libraries, and is trivial to implement on top of the > primitives in > > GHC's IOExts: > > > > hPut :: Storable a => Handle -> a -> IO () > > hGet :: Storable a => Handle -> IO a > > What about endianess? In which format are Floats or even just Bools > stored? For a file which probably shall be read from > different machines > this is not clear at all. The behaviour is defined by the Storable instances for each type. The endianness for writing say an Int32 would be the same as the host architecture, for instance. If you want to work with just bytes, you can always just use hPut and hGet at type Word8. Overloading with Storable gives you more flexibility, since if you have a way to serialise an object in memory for passing to a foreign function, you also have a way to store it in binary format in a file (modulo problems with pointers, of course). In the long term, we'll want to be able to serialise more than just Storable objects (c.f. the other overloaded binary I/O libraries out there), and possibly make the output endian-independent - but after all there's no requirement that Haskell's Int has the same size on all implementations, so there's no guarantee that binary files written on one machine will be readable on another, unless they only use explicitly sized types or Integer. Perhaps these should be called hPutStorable and hGetStorable so as not to prematurely steal the best names. > I think John is right that there needs to be a primitive interface for > just writing bytes. You can then build anything more > complicated on top > (probably different high-level ones for different purposes). > > I just see one problem with John's proposal: the type Byte. It is > completely useless if you don't have operations that go with it; > bit-operations and conversions to and from Int. The FFI > already defines > such a type: Word8. So I suggest that the binary IO library > explicitely > reads and writes Word8's. yup, that's what I had in mind. Cheers, Simon

2 1

Re: binary files in haskell
by malcolm-haskell＠cs.york.ac.uk 06 Feb '01

06 Feb '01

John Meacham wrote: > I wrote up a proposal for a binary file IO mechanism to be added > as a 'blessed addendum' to the standard at best and as a commonly > implmented extension (in hslibs) at least.. I have looked at your proposal. If you would like it to be widely available, you will need to write an implementation of the library, or find someone who can write it for you. Type signatures are great as documentation, but they are not directly executable. :-) Regards, Malcolm

1 0

Haskell Implemetors Meeting
by Timothy Docker 06 Feb '01

06 Feb '01

> We agreed that it would be a Jolly Good Thing if GHC could > be persuaded to produce GHC-independent Core output, > ready to feed into some other compiler. For example, > Karl-Filip might be able to use it. > ANDREW will write a specification, and implement it. A quick question. What is meant by "Core output"? Subsequent posts seem to suggest this is some "reduced Haskell", in which full Haskell 98 can be expressed. Am I completely off beam here? Tim Docker

1 0

Knight
by Christoph M. 05 Feb '01

05 Feb '01

Hi ! Yes, I meant the Knight's Tour problem. Could anybody post me a solve of this problem in haskell ? Thanks a lot, Christoph

2 1

Provider / Haskell-CGI's
by Claudius Heitz 03 Feb '01

03 Feb '01

Hello! Does anybody know a provider, where I can run Haskell-CGI's? I mean, in standard webhosting package? And are there any in Germany? TIA! Claudius _______________________________________________________________________________ Alles unter einem Dach: Informationen, Fun, E-Mails. Bei WEB.DE: http://web.de Die große Welt der Kommunikation: E-Mail, Fax, SMS, WAP: http://freemail.web.de

1 0

Fundeps and quantified constructors
by Tom Pledger 03 Feb '01

03 Feb '01

nubie nubie writes: | So I want to have a polymorphic Collection type, just because. | | > class Collection c e | c -> e where | > empty :: c | > put :: c -> e -> c | | > data SomeCollection e = forall c . Collection c e => MakeSomeCollection c | | Hugs (February 2000) doesn't like it. It says | Variable "e" in constraint is not locally bound | | I feel that e *is* bound, sort of, because c is bound and there's a | fundep c->e. That line of reasoning establishes that e is constrained on the right hand side of the "=". However, it's still bound (by an implicit "forall e") on the left hand side of the "=". The problem is that e can leak details about c to parts of the program outside the "forall c". It's still a problem if you remove the "| c -> e" fundep. A more common use of a "Collection c e | c -> e" class is: data SomeCollection e = --some data structure involving e instance SomeContext e => Collection (SomeCollection e) e where --implementations of empty and put, for the aforementioned --data structure, and entitled to assume SomeContext Is that collection type polymorphic enough for your purposes? : | The following things work as expected: | | > data IntCollection = forall c . Collection c Int => MakeIntCollection c | > data AnyCollection = forall c e . Collection c e => MakeAnyCollection c Neither of them has a type variable tunnelling through the local quantifier. HTH. Tom

1 0

Various software and a question
by Ian Lynagh 02 Feb '01

02 Feb '01

Hi all First a brief question - is there a nicer way to do something like #ifdef __GLASGOW_HASKELL__ #include "GHCCode.hs" #else > import HugsCode #endif than that (i.e. code that needs to be different depending on if you are using GHC or HUGS)? Secondly, I don't know if this sort of thing is of interest to anyone, but inspired by the number of people who looked at the MD5 stuff I thought I might as well mention it. I've put all the Haskell stuff I've written at http://c93.keble.ox.ac.uk/~ian/haskell/ (although I'm new at this game so it may not be the best code in the world). At the moment this consists of a (very nearly complete) clone of GNU ls, and MD5 module and test program and the smae for SHA1 and DES. The ls clone needs a ptch to GHC for things like isLink (incidentally, would it be sensible to try and get this included with GHC? It is basically a simple set of changes to the PosixFiles module, but needs __USE_BSD defined (which I guess is the reason it is not in there, but it could have it's own file?)). Have fun Ian, wondering how this message got to be so long

2 1

Source tar ball for Simon Marlow's Haskell Web Server??
by Bill Halchin 01 Feb '01

01 Feb '01

Hello, I looked on www.haskell.org for the Simon Marlow's Web Server, but couldn't find. Did I overlook it? Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Re: Type Pattern-Matching for Existential Types
by Ashley Yakeley 01 Feb '01

01 Feb '01

At 2001-01-30 22:16, Lennart Augustsson wrote: >It has large and horrible implications. To do dynamic type tests you need >to carry around the types at runtime. This is not something that Haskell >does (at least you don't have to). Hmm. In this: -- data Any = forall a. Any a a1 = Any 3 a2 = Any 'p' -- ...are you saying that a1 and a2 do not have to carry types at runtime? -- Ashley Yakeley, Seattle WA

3 2

Re: Type Pattern-Matching for Existential Types
by C.Reinke 31 Jan '01

31 Jan '01

> > > data Any = forall a. Any a > > > > > > get :: Any -> Maybe Char > > > get (Any (c::Char)) = Just c -- bad > > > get _ = Nothing .. > It can also be questioned from a software engineering standpoint. Much > of the purpose with existential types is to provide information hiding; > that is, the user of an existentially quantified type is not supposed to > know its concrete representation. The merits of an information hiding > dicipline is probably no news to anybody on this list. This discussion reminds me of an old paper by MacQueen: David MacQueen. Using dependent types to express modular structure. In Proc. 13th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 277--286, January 1986. He discusses some of the disadvantages of using plain existential quantification for modular programming purposes and proposes an alternative based on dependent sums, represented as pairing the witness type with the expression in which it is used, instead of existentials, where there is no witness for the existentially quantified type. See CiteSeer for some of the follow-on work that references MacQueen's paper: http://citeseer.nj.nec.com/context/32982/0 Some of that work tried to find a balance between having no witness types and carrying witness types around at runtime. In this context, Claudio Russo's work might be of interest, as he proposes to avoid the problems of existentials without going into (value-)dependent types: http://www.dcs.ed.ac.uk/home/cvr/ Claus

1 0