- Haskell-Cafe - Haskell.org

Haskell Implemetors Meeting
by Timothy Docker 05 Feb '01

05 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. 04 Feb '01

04 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 02 Feb '01

02 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 31 Jan '01

31 Jan '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

Type Pattern-Matching for Existential Types
by Ashley Yakeley 31 Jan '01

31 Jan '01

At 2001-01-30 19:52, Fergus Henderson wrote: >On 30-Jan-2001, Ashley Yakeley <ashley(a)semantic.org> wrote: >> At 2001-01-30 02:37, Fergus Henderson wrote: >> >> >class BaseClass s where >> > downcast_to_derived :: s -> Maybe Derived >> >> Exactly what I was trying to avoid, since now every base class needs to >> know about every derived class. This isn't really a practical way to >> build an extensible type hierarchy. > >Right. > >I don't know of any way to do that in Hugs/ghc without the problem that >you mention. Really it needs language support, I think. >(I have no idea if you can do it in O'Haskell.) It can't be done in O'Haskell either... Given that we have existential types, it would be nice to have a pattern-matching mechanism to get at the inside value. Something like... -- data Any = forall a. Any a get :: Any -> Maybe Char get (Any (c::Char)) = Just c -- bad get _ = Nothing -- ...but as it stands, this is not legal Haskell, according to Hugs: ERROR "test.hs" (line 4): Type error in application *** Expression : Any c *** Term : c *** Type : Char *** Does not match : _0 *** Because : cannot instantiate Skolem constant This, of course, is because the '::' syntax is for static typing. It can't be used as a dynamic pattern-test. Question: how big of a change would it be to add this kind of pattern matching? Is this a small issue, or does it have large and horrible implications? -- Ashley Yakeley, Seattle WA

4 4

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

31 Jan '01

At 2001-01-30 23:11, Johan Nordlander wrote: >However, this whole idea gets forfeited if it's possible to look behind >the abstraction barrier by pattern-matching on the representation. Isn't this information-hiding more appropriately achieved by hiding the constructor? -- data IntOrChar = MkInt Int | MkChar Char data Any = forall a. MkAny a -- Surely simply hiding MkInt, MkChar and MkAny prevents peeking? -- Ashley Yakeley, Seattle WA

2 1