Re: minor doc quibble
My Scottish grandmother taught me that these were the same thing. ;-) -greg w. On Thu, 2001-11-01 at 20:32, Ashley Yakeley wrote: GHC User's Guide sec. 6.4 s/Stingier/Thriftier/ 'stingy': doesn't give much 'thrifty': doesn't take much -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs -- Gregory Wright Chief Technical Officer PacketStorm Communications, Inc. 20 Meridian Road Eatontown, New Jersey 07724 1 732 544-2434 ext. 206 1 732 544-2437 [fax] [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Stack overflow
The [1..] generates [1,1+1,1+1+1,1+1+1+1, ...] Those thunks all go into the heap. Then last grabs the last one and evaluates it, so they all go on the stack. Result death. The Int instance for Enum is a bit naughty in GHC: it is strict. That is [bottom..] is bottom rather than being [bottom,bottom,bottom...]. (Actually the Report is vague on this point; sigh.) So the Int instance evaluates as it goes, while the Integer instance does not. Maybe we should make the Integer instance strict too. Simon | -Original Message- | From: Ian Lynagh [mailto:[EMAIL PROTECTED]] | Sent: 02 November 2001 14:32 | To: [EMAIL PROTECTED] | Subject: Stack overflow | | | | With | | main = putStrLn $ show $ last $ zip [1..] (replicate 10 'a') | | I get | | Stack space overflow: current size 1048576 bytes. | Use `+RTS -Ksize' to increase it. | | If I Change the [1..] to ([1..] :: [Int]) then it works fine. | | | Ian | | | ___ | Glasgow-haskell-bugs mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-bugs | ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Stack overflow
Hi!
OK, so the Int instance for Enum is a bit naughty in that [bottom..] is
bottom. But then one can argue that all instances of Enum should be
naughty in this respect.
The argument is as follows and uses the default declaration of enumFrom in
the Enum class (I've added some types with the intention to clarify a bit
what's happening):
[bottom..] :: [Integer]
= { Syntactic sugar, section 3.10 }
enumFrom bottom :: [Integer]
= { Using the default definition of enumFrom in the Enum class }
map toEnum ([fromEnum bottom ..] :: [Int])
= { fromEnum is strict }
map toEnum ([bottom..] :: [Int])
= { according to Simon }
map toEnum (bottom :: [Int])
= { map is strict in it's second argument }
bottom
Note that I've assumed that fromEnum is strict. I'd say this is a pretty
reasonable assumption.
The key thing here is that the Report assumes that there is an instance
Enum Int which it uses in the default declarations. One could wish that
the report gave some more detail about the Int instance of Enum at least.
Then one could use that to derive the behavour of the other instances,
using the default definitions like I did above.
The bottom (:-) line, from how I interpret the Report, is that the
instances of Int and Integer should at least have the same behaviour in
this respect. But exactly how they should behave is up to the
implementor. I'd vote for the strict version.
Cheers,
/Josef
On Fri, 2 Nov 2001, Simon Peyton-Jones wrote:
The [1..] generates [1,1+1,1+1+1,1+1+1+1, ...]
Those thunks all go into the heap. Then last grabs
the last one and evaluates it, so they all go on the
stack. Result death.
The Int instance for Enum is a bit naughty in GHC:
it is strict. That is [bottom..] is bottom rather than
being [bottom,bottom,bottom...]. (Actually the
Report is vague on this point; sigh.)
So the Int instance evaluates as it goes, while the
Integer instance does not. Maybe we should
make the Integer instance strict too.
Simon
| -Original Message-
| From: Ian Lynagh [mailto:[EMAIL PROTECTED]]
| Sent: 02 November 2001 14:32
| To: [EMAIL PROTECTED]
| Subject: Stack overflow
|
|
|
| With
|
| main = putStrLn $ show $ last $ zip [1..] (replicate 10 'a')
|
| I get
|
| Stack space overflow: current size 1048576 bytes.
| Use `+RTS -Ksize' to increase it.
|
| If I Change the [1..] to ([1..] :: [Int]) then it works fine.
|
|
| Ian
|
|
| ___
| Glasgow-haskell-bugs mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-bugs
|
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Stack overflow
Yes, I agree with this, and I'd already snuck it into the
rewrite of the Enum section that I had to do anyhow.
Would you like to read the section (6.3.4) and see if
you think it is better specified now?
Simon
| -Original Message-
| From: Josef Svenningsson [mailto:[EMAIL PROTECTED]]
| Sent: 02 November 2001 15:54
| To: Simon Peyton-Jones
| Cc: Ian Lynagh; [EMAIL PROTECTED]
| Subject: RE: Stack overflow
|
|
| Hi!
|
| OK, so the Int instance for Enum is a bit naughty in that
| [bottom..] is bottom. But then one can argue that all
| instances of Enum should be naughty in this respect. The
| argument is as follows and uses the default declaration of
| enumFrom in the Enum class (I've added some types with the
| intention to clarify a bit what's happening):
|
| [bottom..] :: [Integer]
| = { Syntactic sugar, section 3.10 }
| enumFrom bottom :: [Integer]
| = { Using the default definition of enumFrom in the Enum
| class } map toEnum ([fromEnum bottom ..] :: [Int]) = {
| fromEnum is strict } map toEnum ([bottom..] :: [Int]) = {
| according to Simon } map toEnum (bottom :: [Int]) = { map is
| strict in it's second argument } bottom
|
| Note that I've assumed that fromEnum is strict. I'd say this
| is a pretty reasonable assumption.
|
| The key thing here is that the Report assumes that there is
| an instance Enum Int which it uses in the default
| declarations. One could wish that the report gave some more
| detail about the Int instance of Enum at least. Then one
| could use that to derive the behavour of the other instances,
| using the default definitions like I did above.
|
| The bottom (:-) line, from how I interpret the Report, is
| that the instances of Int and Integer should at least have
| the same behaviour in this respect. But exactly how they
| should behave is up to the implementor. I'd vote for the
| strict version.
|
| Cheers,
|
| /Josef
|
|
| On Fri, 2 Nov 2001, Simon Peyton-Jones wrote:
|
| The [1..] generates [1,1+1,1+1+1,1+1+1+1, ...]
| Those thunks all go into the heap. Then last grabs
| the last one and evaluates it, so they all go on the
| stack. Result death.
|
| The Int instance for Enum is a bit naughty in GHC:
| it is strict. That is [bottom..] is bottom rather than
| being [bottom,bottom,bottom...]. (Actually the
| Report is vague on this point; sigh.)
|
| So the Int instance evaluates as it goes, while the
| Integer instance does not. Maybe we should
| make the Integer instance strict too.
|
| Simon
|
|
|
| | -Original Message-
| | From: Ian Lynagh [mailto:[EMAIL PROTECTED]]
| | Sent: 02 November 2001 14:32
| | To: [EMAIL PROTECTED]
| | Subject: Stack overflow
| |
| |
| |
| | With
| |
| | main = putStrLn $ show $ last $ zip [1..] (replicate 10 'a')
| |
| | I get
| |
| | Stack space overflow: current size 1048576 bytes.
| | Use `+RTS -Ksize' to increase it.
| |
| | If I Change the [1..] to ([1..] :: [Int]) then it works fine.
| |
| |
| | Ian
| |
| |
| | ___
| | Glasgow-haskell-bugs mailing list [EMAIL PROTECTED]
| | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-bugs
| |
|
| ___
| Glasgow-haskell-bugs mailing list [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
|
|
|
|
| ___
| Glasgow-haskell-bugs mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-bugs
|
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Stack overflow
On Fri, 2 Nov 2001, Simon Peyton-Jones wrote: Yes, I agree with this, and I'd already snuck it into the rewrite of the Enum section that I had to do anyhow. Would you like to read the section (6.3.4) and see if you think it is better specified now? Yes, it's cool! No objections. I also noticed that you added a comment in appendix A about the status of the default-method definitions. I suspect it was added because of my argument for the Integer instance of the Enum class. Anyway I think the comment is very sensible. Thanks for the heroic work you're putting in to this. Keep it up. Cheers, /Josef ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ÖйúÓÅÐã²úÆ·³ö¿Ú½»Ò×»á
Title: CN898.COM 1000ÍòÖйúÈË·ÃÎÊ 1000Íòº£ÍâÈË²Î¹Û 130¶à¸ö¹ú¼ÒµØÇøµÄ100ÍòÍâÉÌÔÚÊÀ½ç¸÷µØ²Î¼Ó ¡¾2001-2006ÖйúÓÅÐã²úÆ·³ö¿Ú½»Ò׻᡿ Chinese Excellent Export Commodities Online Fair 2001-2006 ½²ÇóʵЧ¡¢×¢ÖØ¿ì½Ý ½»Ò×»áÈ·±£Ã¿Ò»¸ö½»Ò×µ¥Î»È«ÄêÓëÒ»¶¨ÊýÁ¿µÄ²»Í¬ÍâÉÌǢ̸¶©»õ¡¢½»Ò×»òºÏ×÷£¡ ½»Ò×»áÍøÖ·£ºhttp://www.CN898.com/fair ½»Ò×»áµç×ÓÐÅÏ䣺[EMAIL PROTECTED] ½»Ò×»áÈÈÏß×Éѯ£º0755-3523107 3523110 3523106 3523117 ½»Ò׻ᴫÕ棺0755-3523115 ½»Ò×»á×éί»áÖйú´¦£ºÉîÛÚÊÐÉî¹úÁ¦µç×ÓÉÌÎñÓÐÏÞ¹«Ë¾ ÉîÛÚÊÐÖÐÐÄÇøÉ̱¨¶«Â·ÕñÒµ´óÏÃA-13C¡£ Óʱࣺ518034 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Yuck. If this isn't enough to convince people that hsc2hs is not an appropriate tool (at least in the context of the Prelude and hslibs/), than I don't know what is. It commits to a particular platform at too early a stage -- details of C header files are often best left toC source files for C compilers to process and deal with, not Haskell. If possible, keeping your Haskell sources plat-indep. is a good goal to have, and I don't see any fundamental reasons why that can't be done here (indeed, the previous Prelude cbits/ setup was fairly close to achieving this). So, bringing back the solution of having manually written C wrapper functions which platform-independent Haskell source files will call out to, would be preferable (in short, avoid the use of hsc2hs *or any other extra tool* alltogether). I'm willing to make the necessary changes. --sigbjorn As another data point, this is also an issue when booting under OpenBSD x86. I suspect anyone with a version of the glibc headers on a Linux box different to those used to bake the supplied .hc / .hs files are also at risk of running into problems. - Original Message - From: Simon Marlow [EMAIL PROTECTED] To: Ian Lynagh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, October 29, 2001 03:08 Subject: RE: Building GHC 5.02 on Solaris x86 Doh, I have several times got further than I thought but didn't realise it as I didn't notice it had made a ghc-5.02 binary! Here's my latest problem, anyway - I don't suppose it could be caused by the hc files being generated under a different OS with different magic numbers could it? Ah yes, I forgot about that. Ken Shan came across the same problem when porting to Alpha. To generate a Solaris-friendly set of hc files for the libraries you need to do this: for each .hsc file, take the C output from hsc2hs on a Linux box (use --no-compile to get the _hsc_make.c file), and compile/run it on your Solaris box to get the .hs file. Take the .hs file back to Linux to generate the .hc file. You will probably have to generate a full set of .hc files, including the compiler. That means doing a 2-stage build on Linux using the .hs files generated on Solaris as above. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
So, bringing back the solution of having manually written C wrapper functions which platform-independent Haskell source files will call out to, would be preferable (in short, avoid the use of hsc2hs *or any other extra tool* alltogether). I'm willing to make the necessary changes. You started by objecting to using a tool that commits your code to a platform too early. I'm in complete agreement. But now you seem to be objecting to using any tools at all. This seems excessive. Why not do one of: 1) Don't write the tool in Haskell 2) Write in Haskell but execute it using a more easily ported Haskell implementation (i.e., Hugs or NHC) 3) Write it in Haskell but include platform independent machine generated code in the distributions. [I lean towards 3 since it avoids the embarressment of 1 and 2] (This is all on the assumption that the amount of code we're talking about is significant enough to care. I have the impression that it is but could be wrong.) -- Alastair ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC 5.02 on Solaris x86
Alastair David Reid [EMAIL PROTECTED] writes: So, bringing back the solution of having manually written C wrapper functions which platform-independent Haskell source files will call out to, would be preferable (in short, avoid the use of hsc2hs *or any other extra tool* alltogether). I'm willing to make the necessary changes. You started by objecting to using a tool that commits your code to a platform too early. I'm in complete agreement. But now you seem to be objecting to using any tools at all. This seems excessive. Why not do one of: [..suggestions on what kind of tool to provide..] (This is all on the assumption that the amount of code we're talking about is significant enough to care. I have the impression that it is but could be wrong.) Yep, I'm of the humble(?) opinion that it is not. Minimising your tool dependencies is always something to keep in mind too. But let not that be the main point - the main point was that this problem needs to be addressed, tool or no tool. I offered a no-tool solution which has worked well in the past. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: interpreter features
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 02 November 2001 10:11, Manuel M. T. Chakravarty wrote: Definitely. An environment like this is pretty trivial todo in Emacs. In fact, the Emacs Haskell mode does most of that already anyway. Well, I use emacs, but didn't really got that working with GHCi. It did work with hugs though. I see you are hesitant about adding features to the interpreter but I'd certainly be happy to see more. My suggestion was just an easy way to do it. One thing I'd like a real interpreter to do is the possibility to view entities defined so far, and to modify them. A finer grained interpretation mode that is. Thanks, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74q45fAeuFodNU5wRAuM+AJ0c7tprhD6RmqRANaktgOI9/7wkvQCeM6Ol M2A5S/6gX2hcu2yvrm6tSnw= =gWq/ -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Christmas Shopping and Theatre (optional) break in London from £38.75 pppn!
Title: Christmas Shopping and a Show!! For details of this amazing offer CLICK HERE Christmas Shopping and Theatre (optional) break in London from £38.75 pppn - breakfast! We have 5* down to 2* hotels available - at up to 50% discount! Top Shows such as Buddy and Blood Brothers at over 20% reduction in price on the top tickets! Come to London for the weekend (9th & 10th November), shop at some of the best stores in the World, eat at some of the finest restaurants and just... "get away from it all"! For details of the hotels, a list of shows and prices, go to our web site at www.hotelbookings4u.com ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Student Programming Projects
Hi. Next Semester, I am supposed to teach a short course in Haskell. Can anyone recommend interesting programming projects which can be completed in about a month? I posted this message a while ago and got a few suggestions that sounded like they would maintain student interest. Alas, my disk drive crashed soon thereafter. So if you have given me suggestions before, please do so again. I was particularly intrigued by the suggestions put forth by someone who complained that someone else's suggested projects were too theoretical. We need to try to capture the students' imaginations here and many of them prefer concrete thought to abstract thought. Again. Thank you very much. Barbara Nostrand -- +--+--+ | Dr. Barbara Nostrand | Department of Computer Science | | Assistant Professor | SUNY College at Potsdam | | Computer Science and Engineering | Potsdam, New York| | (315) 267-2216 | 13676| +--+--+ | Ignored domains: bestbiz.net, pop.net, hotmail.com, aibusiness.com | | vdi.net, usa.net, tpnet.pl, myremarq.com | | netscape.net, excite.com, bigfoot.com, public.com | | com.tw, eranet.net, yahoo.com, success.net | | mailcity.com, net.tw, twac.com, netcenter.com | | techie.com, msn.com| +-+ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Why is (monad) elegance so costly?
Hi, I feel embarrased when I post newbie questions after one year of decent Haskell programming. But it feels much better to ask than to suffer in ignorance. My newbie question is: Could anyone explain why the second version of the following function is better. Is there a tutorial kind of paper(or related) that gives programmer-view of closures? In particular when they are created, what do they contain and where and how they should be avoided to make program faster. Thank you very much, Saswat You can see what is going on if you give the flag -ddump-simpl to GHC, and then look for the function Main.eval. You'll see that eval has a shape like eval (Var x) = let ... in \env - ... eval (Add u v) = let ... in \env - ... This is bad, because eval is building a function closure for the \env, instead of taking its two arguments together as does simplEval. We'd prefer eval (Var x) env = let ... in ... eval (Add u v) env = let .. in ... ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Transmitting parameters
At 2001-11-01 22:10, raul sierra alcocer wrote: What mechanism of transmiting parameters does Haskell implement? By value. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Transmitting parameters
At 2001-11-01 22:10, raul sierra alcocer 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. -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Transmitting parameters
On Friday, 2 November 2001 07:10 Raul Sierra Alcocer wrote: Hi, What mechanism of transmiting parameters does Haskell implement? Thank you, Raul Anyway, it does not make sense to distinct between call-by-value and call-by-reference in the traditional way since variables cannot be modified in Haskell (which means that they aren't really variable). Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: 'Forall' Polymorphism Question
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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED]] | 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 | [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell | ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Robustness of instance Read Char
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:[EMAIL PROTECTED]]
| Sent: 15 October 2001 11:45
| To: [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]
| 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
| [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
|
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Type checking question
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Type checking question
Hello, Adrian wrote: 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? The problem is that GHC can not find out (From the two Nothing objects) which instance of AdjustmentClass to use. Different instances might lead to different IO Text objects, so choosing a default is impossible. For example: show ([] :: [Int]) == [] and show ([] :: [Char]) == \\ Therefore, you have to tell GHC the exact type of textNew Nothing Nothing with a type annotation, just like in the examples with show above: txt - textNew (Nothing :: Maybe SomeDefaultAdjustmentClass) Nothing In this case, supplying the type of one of the two Nothing values is enough (GHC can find out the other one must be the same). 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? This is indeed one solution. This way, you tell GHC a dummy instance is possible; unlike the show-situation where it is impossible). Using type annotations is another solution, but it is not as comfortable if you are supplying textNew often with just twice Nothing. If it's just a few cases, I prefer this option. As a last alternative, only useful if you use textNew Nothing Nothing often, is to write a special function for this case (in all other cases, GHC can infer the right type so we don't need a special function): textNewNothing = textNew (Nothing :: Maybe SomeDefaultAdjustmentClass) Nothing Regards, Rijk-Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell 98 Revised
Haskellers! It's that time of the month. I'm putting out the November release of the Revised Haskell 98 Report. As ever, I earnestly seek your feedback. Especially I'd like to know whether I have stumbled in rewriting the section about Enum in the light of recent email. http://research.microsoft.com/~simonpj/haskell98-revised My plan is to iterate just once more (early Dec), and then freeze the report at Christmas. I'm getting tired! Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Scope of imported names
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98 Revised
On Fri, Nov 02, 2001 at 09:30:36AM -0800, Simon Peyton-Jones wrote: Haskellers! Hi Simon :-) It's that time of the month. I'm putting out the November release of the Revised Haskell 98 Report. As ever, I earnestly seek your feedback. Especially I'd like to know whether I have stumbled in rewriting the section about Enum in the light of recent email. http://research.microsoft.com/~simonpj/haskell98-revised http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/index.html says Revised: October 2001 - am I seeing the latest version? Actually, http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/syntax-iso.html has November 2001 at the bottom so I guess I am. 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. My plan is to iterate just once more (early Dec), and then freeze the report at Christmas. I'm getting tired! :-) Thanks Ian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Scope of imported names
Fri, 2 Nov 2001 09:30:37 -0800, Simon Peyton-Jones [EMAIL PROTECTED] 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 * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ QRCZAK ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: HXML 0.1, an(other) XML parser for Haskell
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 [EMAIL PROTECTED] with any questions, comments, or bug reports. --Joe English [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
