- Haskell-Cafe - Haskell.org

Re: Question aboutthe use of an inner forall
by Jon Cast 19 Aug '02

19 Aug '02

"Scott J." <jscott(a)planetinternet.be> wrote: > A question: s is not a type variable as a isn't it? I mean a can be > of type Integer while s cannot. Guessing at your question: a has no type (and neither does s); it /is/ a type. In Haskell, types have kinds. And, both a and s have kind *. Now then, the user can instantiate a to Integer, yes. And the user cannot instantiate s to anything---that's what the `forall' is for. runST will (theoretically) instantiate s to something. That could be Integer if the language implementors felt like it. The user of runST certainly has to be prepared for the possibility. Does that come close to answering your question? > Regards, > Scott Jon Cast

2 1

Question aboutthe use of an inner forall
by Scott J. 17 Aug '02

17 Aug '02

Hi, It goes about the State tansformer monad ST s a. I think how it works but as a logician the use of an internal forall is difficult to swallow. Let's first see a statement in Haskell. One can type foo :: a -> b as a function We can be not sloppy (but this gives unnecessary clutter in the program I think) and type it as: forall a,b foo :: a -> b Now this is a statement in logic, it can be true or false. However what for heaven's sake should I think of runST :: forall a ( forall s ST s a) -> a ? In logic forall x forall y statement(x.y) is equivalent to: forall y forall x statement(x,y). Why the use of the inner forall in runST?This is not a normal function declaration in mathematics. Since Haskell is Hindley-Milner typed and can't use an inner forall . Why the use an inner forall. Has imagination dried up (sorry, if this seems impolite)? Thx Scott

1 0

RE: question about parsing integers and floats with Parsec
by Harris, Andrew 16 Aug '02

16 Aug '02

Hi - After a bit of monkeying around, it seems the following parser works to detect both integers and floats, both positive and negative. I'm sure you wizards have many better ways of doing this. Anyway here it is for your amusement: import Parsec import qualified ParsecToken as P import ParsecLanguage (emptyDef) lexer = P.makeTokenParser emptyDef integer = P.integer lexer float = P.float lexer genericgrab :: Parser (Either Integer Double) genericgrab = try ( do { n <- char '-' ; f <- float ; return (Right (-f)) } ) <|> try ( do { f <- float ; return (Right f) } ) <|> try ( do { f <- integer ; return (Left f) } ) -andrew > -----Original Message----- > From: Harris, Andrew [mailto:Andrew.Harris@jhuapl.edu] > Sent: Thursday, August 15, 2002 6:55 PM > To: 'haskell-cafe(a)haskell.org' > Subject: question about parsing integers and floats with Parsec > > > Hi - > > This isn't a pure "Haskell" question, but I'm trying to use the > Parsec library to parse out space separated numbers, which > could be integers > or floats and either positive or negative. I was using the > "naturalOrFloat" > lexeme parser from the ParsecToken module, until I realized > that it doesn't > seem to handle negative integers. I've been poking with > trying to pair the > integer and float lexeme parsers with try() blocks, but I > ain't no parsing > expert and am not making good progress. > > Any help/hints would be appreciated! > > thanks, > -andrew > > --- > Andrew Harris andrew.harris(a)jhuapl.edu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

question about parsing integers and floats with Parsec
by Harris, Andrew 16 Aug '02

16 Aug '02

Hi - This isn't a pure "Haskell" question, but I'm trying to use the Parsec library to parse out space separated numbers, which could be integers or floats and either positive or negative. I was using the "naturalOrFloat" lexeme parser from the ParsecToken module, until I realized that it doesn't seem to handle negative integers. I've been poking with trying to pair the integer and float lexeme parsers with try() blocks, but I ain't no parsing expert and am not making good progress. Any help/hints would be appreciated! thanks, -andrew --- Andrew Harris andrew.harris(a)jhuapl.edu

2 1

RE: Text in Haskell: a second proposal
by Simon Marlow 15 Aug '02

15 Aug '02

[ moving to haskell-i18n(a)haskell.org ] > For ISO-8859-1 each Char is exactly one Word8, so surely it > would work fine with partial reads? > > decodeCharISO88591 :: Word8 -> Char; > > encodeCharISO88591 :: Char -> Word8; > > decodeISO88591 :: [Word8] -> [Char]; > decodeISO88591 = fmap decodeCharISO88591; > > encodeISO88591 :: [Char] -> [Word8]; > encodeISO88591 = fmap encodeCharISO88591; Sorry, I thought you were just using ISO8859-1 as an example. > >This is better: it doesn't force you to use lazy I/O, and when > >specialised to the IO monad it might get decent performance. The > >problem is that in general I don't think you can assume the lack of > >state. For example: UTF-7 has a state which needs to be retained > >between characters, and UTF-16 and UTF-32 have an endianness > state which > >can be changed by a special sequence at the beginning of the > file. Some > >other encodings have states too. > > But it is possible to do this in Haskell... > > The rule for the many functions in the standard libraries seems to be > "implement as much in Haskell as possible". Why is it any > different with the file APIs? I think we've lost track of the discussion here... I'll try to summarise. I think character encoding/decoding should be built-in to the I/O system. I also think there should be a low-level I/O interface that doesn't do any encoding, and high-level interfaces to the various encodings. Now, you can by all means specify the high-level I/O in terms of the low-level I/O + encodings, but I strongly suspect that implementing it that way will be expensive. Character I/O in Haskell is *already* very slow (see Doug Bagely's language shootout for evidence), and I don't want to add another factor of 2 or more to that. The point is that by building encoding into the I/O interface the implementor gets the opportunity to optimise. Cheers, Simon

1 0

RE: Analyzing Efficiency
by Simon Marlow 14 Aug '02

14 Aug '02

> I've come up with three different methods of approach to > solve the same > problem in haskell. I would like to compare the three in > terms of reductions, > memory usage, and overall big O complexity. > > What's the quickest way to gather these stats? I usually use the ghc > compiler, but also have hugs installed. The big O complexity > probably has to > be done by hand, but maybe there's a tool out there to do it > automagically. Apart from the "normal" ways (profiling, Unix 'time', GHC's +RTS -sstderr), here's another one I've been using recently: cachegrind. It's the wonderful cache profiling extension by Nick Nethercote that comes with Julian Seward's Valgrind. The great thing is that you don't even need to recompile the program - you just do 'cachegrind <program>', and it runs (very slowly) and outputs reliable cache statistics including how many instructions were executed. Get it from http://developer.kde.org/~sewardj/ Oh, it only works on Linux BTW. Cheers, Simon

1 0

Analyzing Efficiency
by Shawn P. Garbett 14 Aug '02

14 Aug '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've come up with three different methods of approach to solve the same problem in haskell. I would like to compare the three in terms of reductions, memory usage, and overall big O complexity. What's the quickest way to gather these stats? I usually use the ghc compiler, but also have hugs installed. The big O complexity probably has to be done by hand, but maybe there's a tool out there to do it automagically. Shawn - -- You're in a maze of twisty little statements, all alike. Public Key available from http://www.garbett.org/public-key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9WU0BDtpPjAQxZ6ARAkTKAJ9qixYy5MT5QGyJ/95NGLNgVTECCQCfVVVV GHELk++jO8XzaWUbp/mb9Og= =MYjn -----END PGP SIGNATURE-----

2 1

RE: Text in Haskell: a second proposal
by Ashley Yakeley 14 Aug '02

14 Aug '02

At 2002-08-13 04:13, Simon Marlow wrote: >That depends what you mean by efficient: these functions represent an >extra layer of intermediate list between the handle buffer and the final >[Char], and furthermore they don't work with partial reads - the input >has to be a lazy stream gotten from hGetContents. For ISO-8859-1 each Char is exactly one Word8, so surely it would work fine with partial reads? decodeCharISO88591 :: Word8 -> Char; encodeCharISO88591 :: Char -> Word8; decodeISO88591 :: [Word8] -> [Char]; decodeISO88591 = fmap decodeCharISO88591; encodeISO88591 :: [Char] -> [Word8]; encodeISO88591 = fmap encodeCharISO88591; >> A monadic stream-transformer: >> >> decodeStreamUTF8 :: (Monad m) => m Word8 -> m Char; >> >> hGetChar h = decodeStreamUTF8 (hGetWord8 h); >> >> This works provided each Char corresponds to a contiguous block of >> Word8s, with no state between them. I think that includes all the >> standard character encoding schemes. > >This is better: it doesn't force you to use lazy I/O, and when >specialised to the IO monad it might get decent performance. The >problem is that in general I don't think you can assume the lack of >state. For example: UTF-7 has a state which needs to be retained >between characters, and UTF-16 and UTF-32 have an endianness state which >can be changed by a special sequence at the beginning of the file. Some >other encodings have states too. But it is possible to do this in Haskell... The rule for the many functions in the standard libraries seems to be "implement as much in Haskell as possible". Why is it any different with the file APIs? -- Ashley Yakeley, Seattle WA

1 0

Newbie question on "statefullness"
by Alex Peake 13 Aug '02

13 Aug '02

I am new to Haskell. I want to do something very simple (I thought) but got lost in the world of Monads. I want to implement something like the C idea of: n += i So how does one doe this in Haskell? Thanks, Alex

8 11

Re: Analyzing Efficiency
by Shawn P. Garbett 13 Aug '02

13 Aug '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 August 2002 01:37 pm, you wrote: > > I would like to compare the three in terms of reductions, memory > > usage, and overall big O complexity. > > I wouldn't use number of reductions as a guide if I was you. Number of reductions does make a difference in this case, because it's a simple test problem with three equivalent implementations (in the same compiler). Nothing to create confusion like a system call, well actually all three solutions must call a set of IO calls in the same order. So I think it would make a good baseline comparison. I do agree that it's not a good general measurement of efficiency, and really doesn't reflect the scalability of the solution either (whereas big O notation would). Thanks for the heads up though. The other tips and hints you gave me are exactly what I was looking for. No I just need a huge data set to pump into so it does a significant amount of garbage collection, and memory management... Shawn Garbett - -- You're in a maze of twisty little statements, all alike. Public Key available from http://www.garbett.org/public-key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9WVM5DtpPjAQxZ6ARAn2XAJ98Y4jNmnCocHzHEFpUM/vN3kTGmACfTnkf Vk3m8x1OYHGyckskR4DDKQo= =OWav -----END PGP SIGNATURE-----

1 0