- Haskell - Haskell.org

RE: Haskell 98 Revised
by Simon Peyton-Jones 05 Nov '01

05 Nov '01

Gentle Haskellers Yes! The layout rule bites again. Ian writes: | Finally, ghci, hi and hugs seem to accept | | > module Foo where | > instance Fractional Int where | > foo = 5 In fact, GHC and Hugs have different interpretations: Hugs treats the 'foo' as part of the 'where', whereas GHC does not. Meanwhile the current draft of the report seems just wrong. The annotated program is: module Foo where {1} <1> instance Fractional Int where {1} <1> foo = 5 So when the algorithm hits the {1} on line 2, no case matches except the catch-all case, so {1} makes it through into the output, which is A Bad Thing. None of these pseudo-lexemes should get through to the output. The "obvious" result is: module Foo where { instance Fractional Int where {} ; foo = 5 } To fix this, it seems to me that all we need do is to add the following second clause to L L ({n}:ts) (m:ms) = { : (L ts (n:m:ms)) if n > m, (Note 3) = { : } : L ts (m : ms) otherwise This makes sure that the {n} case always has an outcome, and implicitly inserts { } where the layout does not increase. This is an old chestnut, but all the more reason for knocking it on the head (to mix metaphors). Simon

2 2

RE: Haskell 98 Revised
by Simon Peyton-Jones 05 Nov '01

05 Nov '01

| http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-repor t-html/index.html | says "Revised: October 2001" - am I seeing the latest version? Yes you are -- my mistake. | You still have | lexeme -> ... | qop | ... | in the lexical syntax but have | qop -> qvarop | qconop | in the context-free syntax - is this deliberate? It really sucks IMO. Your message about this is still in my "to deal with" pile. Last time I looked I didn't see an obvious solution, but now I look again, it seem simple. (Procrastination sometimes works.) Proposal: in the syntax for "lexeme", replace "qop" by "qvarsym | qconsym". So the syntax for lexeme becomes lexeme -> qvarid | qconid | qvarsym | qconsym | literal | special | reservedop | reservedid I think this restores the stratification between the lexical structure (no whitespace allowed) and the syntactic structure (whitespace allowed between lexemes). It also makes the syntax for "lexeme" look more symmetrical. Do you agree? Simon

2 1

Type checking question
by Adrian Hey 05 Nov '01

05 Nov '01

Hello, I've been playing around with GTK+HS recently. This makes extensive use of Haskell classes, so I sometimes get strange type errors like this one.. textNew (creates a new text widget) has type: textNew :: AdjustmentClass adj => Maybe adj -> Maybe adj -> IO Text But when I try to create one using: txt <- textNew Nothing Nothing GHC complains: Main.hs:82: Ambiguous type variable(s) `a' in the constraint `GtkAdjustment.AdjustmentClass a' arising from use of `textNew' at Main.hs:82 in a `do' expression pattern binding: txt <- textNew Nothing Nothing My first thought was that I need a type signature for txt, but seeing as txt has to be type IO Text, I dont think that's possible (because 'adj' is not referenced). Is that correct? So, what should one do in this situation? Something like this perhaps.. myNothing :: Maybe dummyAdjustmentClassInstance myNothing = Nothing txt <- textNew myNothing myNothing I'm pretty sure that would do it, but it seems like an ugly solution. Is there a better way? Thanks -- Adrian Hey

2 2

readFile
by bracaman＠box.sk 04 Nov '01

04 Nov '01

Hello all. It's me again :) This time I'd like to ask someone to explain me why this happens. I have this piece of code: test = do writeFile "/tmp/hsout" "first" h <- readFile "/tmp/hsout" writeFile "/tmp/hsout" "second" putStr h So, when i've done this i thought that (putStr h) would print the string "first". But it didn't, it printed the string "second". My question is why? And how can i do to print the first string instead of the first one. Thank you, Jo�o ------------------------------------ geek code inside :: powered by linux

1 0

Re: URGENT: File exists
by Ashley Yakeley 03 Nov '01

03 Nov '01

At 2001-11-03 02:56, bracaman(a)box.sk wrote: >I need to create a function that checks if a file exists. My intention is >to do something like: > > teste :: String -> Bool (Beeing the String the FilePath) This cannot be done safely. Consider making a function with type test :: String -> IO Bool ... -- Ashley Yakeley, Seattle WA

1 0

ANNOUNCE: HXML 0.1, an(other) XML parser for Haskell
by Joe English 03 Nov '01

03 Nov '01

2 Nov 2001 Announcing HXML, an(other) XML parser for Haskell. This implementation should have better space behaviour than HaXml's parser, and may be used as a drop-in replacement in existing HaXml programs. HXML is available at: <URL: http://www.flightlab.com/~joe/hxml/ > The current version is 0.1, and is slightly post-alpha quality. Tested with GHC 5.02, NHC98 1.10, and various recent versions of Hugs. Please contact Joe English <jenglish(a)flightlab.com> with any questions, comments, or bug reports. --Joe English jenglish(a)flightlab.com

1 0

Re: Scope of imported names
by Marcin 'Qrczak' Kowalczyk 02 Nov '01

02 Nov '01

Fri, 2 Nov 2001 09:30:37 -0800, Simon Peyton-Jones <simonpj(a)microsoft.com> pisze: > | 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. > 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? I don't have a strong opinion in either way, ok for me to make this change, but I don't agree that it would be more consistent. Instances don't contain binding occurrences of method names! They are not exported from the module which contains the instance. Well, instances are exported semantically, but not names of methods. You can't have a fixity declaration there. You can't have a type signature, although it's sometimes written in a comment (perhaps it should be permitted?). It's true that it's unambiguous because of the class they are written in. And they syntactically looks like binding occurrences to create an illusion that it's overloading... But in fact they contribute code to the same function which happens to dispatch the implementation on the type it is used at. At least this is how I think about it. I've recently implemented a toy language where providing implementations of generic functions is done by executing a particular function, giving it three arguments: the generic function, the type, and the implementation. It's clearly not a binding occurrence - the function must have already existed before. Similarly in Haskell. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK

1 0

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