November 2001 - Haskell

RE: Scope of imported names
by Simon Peyton-Jones 02 Nov '01

02 Nov '01

Karl-Filip wrote (on 22 Oct): | What I'm driving at is this: I propose that top level | bindings shadow imported names and that qualified names can | not be used to refer to declarations in the same module. [His message had a lot more in it, of course, but this is the nub.] There followed a short exchange with Wolfgang Lux, then quiet. I've thought about this, and it's not a change that I would be prepared to make now. By a long way. This stuff about ambiguity, qualified names, and so on has been hammered out at great length, and now is not the time to start again. Karl-Filip made another point: | Section 5.5.2 relates to name clashes and has an interesting | example towards the end: | | module F where | | sin :: Float -> Float | sin x = (x::Float) | | f x = Prelude.sin (F.sin x) | | where the type signature refers to the local "sin" rather | than the imported although none of them is visible | unqualified. These rules are quite tricky to understand, I | think. They are also different in spirit from the rules for | instance declarations in section 4.3.2 where the binding | occurrences for the names of the methods must be qualified if | the unqualified method name is not in scope. In the "sin" example | it is allowed to resolve the | name clash using the "extra" knowledge that it is illegal to | provide type signatures for imported names, wheras in the | case for instance declarations we may not use the | corresponding "extra" knowledge that only methods in | the instance'd class may be bound by the bindings. I must say that I do agree with this. It's a significant complication in the syntax of the language to permit qualified names in a binding position, in instance declarations only. For example, it leads to the productions for "funlhs" and "qfunlhs" which are identical except that one has "var" where the other has "qvar". These aren't small productions either; they have 6 clauses. And, as Karl-Filip says, it's inconsistent with the type signature stuff. I will therefore propose the following simplification: remove the stuff from 4.3.2 about having a qualified name for the class method; after all, an instance declaration is only *allowed* to have declarations for the class methods That would simplify the syntax, and make the language more consistent. Any objections? Simon

1 0

Re: Robustness of instance Read Char
by Sigbjorn Finne 02 Nov '01

02 Nov '01

Simon Peyton-Jones simonpj(a)microsoft.com writes: > [.. following up to Peter Thiemann's post on the slowness of Read(S) ..] > I do agree with you that it woud be better for the Read class > to use a Maybe result rather than a list of parses. But I'm not > sure your problem can be solved simply by making the Char > instance of Read better. .... For what it's worth, I played around with changing ReadS to do just that a couple of years ago, i.e., defining it as type ReadS a = String -> Maybe (a,String) The reductions in space&time were decent (at least 2x in some cases, if I remember correctly), but I didn't take the idea any further. It's a simple change - you can enable it by compiling GHC's PrelRead.lhs with the extra option -DNEW_READS_REP -- there's no 'deriving' support for this rep. of ReadS in the compiler itself tho. --sigbjorn

1 0

RE: Robustness of instance Read Char
by Simon Peyton-Jones 02 Nov '01

02 Nov '01

I do agree with you that it woud be better for the Read class to use a Maybe result rather than a list of parses. But I'm not sure your problem can be solved simply by making the Char instance of Read better. The point is that the parser has to read the *whole* string before it can be sure that it is syntactically well formed (e.g. no duff escape sequence in it) and hence it can't produce the result string till its sure that it can parse it. So it gets tummy ache. Better perhaps to roll your own Read class which produces output earlier. For that it would help if I finished up the generics support in GHC so that you could do something like "deriving Read" for your own new class. Simon | -----Original Message----- | From: Peter Thiemann [mailto:thiemann@informatik.uni-freiburg.de] | Sent: 15 October 2001 11:45 | To: haskell(a)haskell.org | Cc: thiemann(a)informatik.uni-freiburg.de | Subject: Robustness of instance Read Char | | | Folks, | | my code has unwillingly been forced to read a large string | generated by show. This turned out to be a robustness test | because the effect is a stack overflow (with Hugs as well as | with GHC) and, of course, this error happened in a CGI script. | | If you want to try the effect yourself, just take a file | "foo" of, say, 150k and type this into you hungry Hugs prompt: | | readFile "foo" >>= \s -> putStr (read (show foo)) | | Digging down into the prelude code (taken from Hugs's prelude | file), you find this: | | > instance Read Char where | > readsPrec p = readParen False | > (\r -> [(c,t) | ('\'':s,t) <- lex r, | > (c,"\'") <- | readLitChar s ]) | > readList = readParen False (\r -> [(l,t) | ('"':s, t) <- lex r, | > (l,_) <- readl s ]) | > where readl ('"':s) = [("",s)] | > readl ('\\':'&':s) = readl s | > readl s = [(c:cs,u) | (c ,t) <- | readLitChar s, | > (cs,u) <- | readl t ] | | which means that the parser reading this string has the | ability to fail and to backtrack *at every single character*. | While this might be | useful in the general case, it certainly causes our little | one-line program to die. | | Unfortunately, in my real program, the String is embedded in | a data type which is deriving Read, so that writing the | specific instance of read is a major pain. Two things would | help me in this situation: | | 1. some kind-hearted maintainer of a particularly | well-behaved Haskell | implementation might put in a more efficient definition in the | instance Read Char (or convince me that backtracking inside of | reading a String is a useful gadget). The following code will do: | | readListChar :: String -> [(String, String)] | readListChar = | return . readListChar' . dropWhile isSpace | | readListChar' ('\"':rest) = | readListChar'' rest | | readListChar'' ('\"':rest) = | ("",rest) | readListChar'' rest = | let (c, s') = head (readLitChar rest) | (s, s'') = readListChar'' s' | in (c:s, s'') | | {- clearly, taking the head should be guarded and a proper | error message generated -} | | 2. provide a way of locally replacing the offending instance of Read | with something else. [urgh, a language extension] | | Any suggestions or comments? | -Peter | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: 'Forall' Polymorphism Question
by Andrew Kennedy 02 Nov '01

02 Nov '01

Not quite. "A definition is impredicative if it refers to a collection which contains the object to be defined." (see http://www.xrefer.com/entry/552390) If you stratify a type system so that quantifiers only quantify over things at a lower "stratum" then (I think) it is predicative (= not impredicative). But you might have forall quantifiers at more than one level in your system, as is the case in some formalizations of ML's module system (Shao et al) where a predicative subset of the impredicative F_\omega is used. I'm also willing to be corrected! - Andrew. > -----Original Message----- > From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] > Sent: Wednesday, October 31, 2001 12:20 PM > To: Ashley Yakeley; Haskell List > Subject: RE: 'Forall' Polymorphism Question > > > Any system that allows a parametric type variable to > be instantiated by a for-all type is called "impredicative", > I think. Example: Maybe (forall a. a->a), or as you have > below (m (forall a. a->a)). > > I don't understand all (well, any) of the details, but I > understand that impredicative systems make type inference > nigh impossible. I don't know any programming language that > has impredicative types. Haskell certainly does not, nor any > extension I know of. > > I'm willing to be corrected! > > Simon > > | -----Original Message----- > | From: Ashley Yakeley [mailto:ashley@semantic.org] > | Sent: 31 October 2001 10:14 > | To: Haskell List > | Subject: 'Forall' Polymorphism Question > | > | > | I note that GHC by default gives this type for "return id": > | > | (return id) :: forall m a. (Monad m) => m (a -> a) > | > | Wouldn't this be more general: > | > | (return id) :: forall m. (Monad m) => m (forall a. a -> a) > | (return return) :: forall m. (Monad m) => m (forall m1 a. > | (Monad m1) > | => a -> m1 a) > | > | ...? > | > | Is this something GHC could ever do, or are there good > reasons why it > | would never work in Haskell? > | > | -- > | Ashley Yakeley, Seattle WA > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell >

1 0

Transmitting parameters
by raul sierra alcocer 02 Nov '01

02 Nov '01

Hi, What mechanism of transmiting parameters does Haskell implement? Thank you, Raul

2 1

Re: Transmitting parameters
by Lennart Augustsson 02 Nov '01

02 Nov '01

> >> >What mechanism of transmiting parameters does Haskell implement? > >> > >> By value. > > > >Yes, though one might equally say that they are passed by > >reference, since in > > > > Oh, yeah, they're passed by thunk. I forgot about the laziness. Well, Haskell does not really specify which mechanism to use. Most implementations use call-by-need (a variation of the old call-by-name). But any mechanism that is faithful to the semantics would, in principle, be all right. So call-by-name is all right. As is spawning a thread for the parameter (I don't know the name of this mechanism), as in pH. -- Lennart

1 0

ANNOUNCE: Generic Haskell version 0.99 (Amber)
by Andres Loeh 02 Nov '01

02 Nov '01

Generic Haskell version 0.99 (Amber) ==================================== We are happy to announce the first release of Generic Haskell, an extension of Haskell which facilitates generic programming. Generic Haskell includes the following features: * type-indexed values -- generic functions definable for all Haskell data types. * kind-indexed types -- for giving types to type-indexed values * type-indexed types -- types which are indexed over the type constructors underlying Haskell datatypes. The Generic Haskell compiler takes Generic Haskell source and produces Haskell code (which is in most cases Haskell 98 compliant). Download -------- The Generic Haskell compiler is available in source and binary distributions. Binaries for Linux, Windows, MacOSX, and Solaris are available. These are available from: http://www.generic-haskell.org/compiler.html The documentation is also available separately from that page. For more general information, point your browser to: http://www.generic-haskell.org Why Generic Haskell? -------------------- Software development often consists of designing datatypes, around which functionality is added. Some functionality is datatype specific, whereas other functionality is defined on almost all datatypes in such a way that it depends only on the structure of the datatype. A function that works on many datatypes in this way is called a generic function. Examples of generic functionality include storing a value in a database, editing a value, comparing two values for equality, pretty-printing a value. Since datatypes often change and new datatypes are introduced, we have developed Generic Haskell, an extension of the functional programming language Haskell that supports generic definitions, to save the programmer from (re)writing instances of generic functions. The design of Generic Haskell is based on recent work by Ralf Hinze. Pleasant programming, The Generic Haskell Team at Utrecht University (Dave Clarke, Ralf Hinze, Johan Jeuring, Andres Loeh, Jan de Wit) info(a)generic-haskell.org

1 0

Re: Transmitting parameters
by Ashley Yakeley 02 Nov '01

02 Nov '01

At 2001-11-02 02:21, Jon Fairbairn wrote: >> >What mechanism of transmiting parameters does Haskell implement? >> >> By value. > >Yes, though one might equally say that they are passed by >reference, since in > >g = let f x = x+x > z = factorial 1000 > in f z * z > >the 'first' instance of x forces z to be evaluated and >updated, the second instance of x uses this updated value, >and so does the final occurrence of z. Oh, yeah, they're passed by thunk. I forgot about the laziness. -- Ashley Yakeley, Seattle WA

1 0

Re: Transmitting parameters
by Ashley Yakeley 02 Nov '01

02 Nov '01

At 2001-11-01 22:10, raul sierra alcocer wrote: >What mechanism of transmiting parameters does Haskell implement? By value. -- Ashley Yakeley, Seattle WA

2 1