Re: [GHC] #937: ghc-pkg should splice $topdir on Windows
#937: ghc-pkg should splice $topdir on Windows --+- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Multiple Os: Windows | --+- Changes (by simonmar): * owner: = simonmar Comment: mine -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/937 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Broken link
Hi, on http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad-Writer.html there is a broken link. The correct link is http://web.cecs.pdx.edu/~mpj/pubs/springschool.html currently. What's the recent state of the planned migration from CVS to darcs? Is there an overview of the Project somewhere? schneegloeckchen ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1093: Windows: haddock-html fields are wrong in package.conf
#1093: Windows: haddock-html fields are wrong in package.conf
-+--
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.6.1
Component: Build System | Version: 6.6
Severity: normal|Keywords:
Difficulty: Easy (1 hr) |Testcase:
Architecture: Unknown | Os: Windows
-+--
{{{
$ c:/ghc/ghc-6.6/bin/ghc-pkg field network haddock-html
haddock-html: $topdir\html\libraries\network
}}}
it should be
{{{
haddock-html: $topdir\doc\html\libraries\network
}}}
Note the doc\.
After #937 is fixed, this is still preventing setup haddock from working
in Cabal on Windows.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1093
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1094: Windows: haddock-html fields are wrong in package.conf
#1094: Windows: haddock-html fields are wrong in package.conf
-+--
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.6.1
Component: Build System | Version: 6.6
Severity: normal|Keywords:
Difficulty: Easy (1 hr) |Testcase:
Architecture: Unknown | Os: Windows
-+--
{{{
$ c:/ghc/ghc-6.6/bin/ghc-pkg field network haddock-html
haddock-html: $topdir\html\libraries\network
}}}
it should be
{{{
haddock-html: $topdir\doc\html\libraries\network
}}}
Note the doc\.
After #937 is fixed, this is still preventing setup haddock from working
in Cabal on Windows.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1094
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1095: Windows: haddock-html fields are wrong in package.conf
#1095: Windows: haddock-html fields are wrong in package.conf
-+--
Reporter: simonmar | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 6.6.1
Component: Build System | Version: 6.6
Severity: normal|Keywords:
Difficulty: Easy (1 hr) |Testcase:
Architecture: Unknown | Os: Windows
-+--
{{{
$ c:/ghc/ghc-6.6/bin/ghc-pkg field network haddock-html
haddock-html: $topdir\html\libraries\network
}}}
it should be
{{{
haddock-html: $topdir\doc\html\libraries\network
}}}
Note the doc\.
After #937 is fixed, this is still preventing setup haddock from working
in Cabal on Windows.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1095
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1089: Somewhat bad type error message
#1089: Somewhat bad type error message
-+--
Reporter: kirsten | Owner:
Type: bug | Status: closed
Priority: lowest | Milestone:
Component: Compiler (Type checker) |Version: 6.6
Severity: trivial | Resolution: wontfix
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Multiple
Os: Multiple |
-+--
Changes (by simonpj):
* resolution: = wontfix
* status: new = closed
Comment:
Thanks for the suggestions, but I don't really see how to improve this.
Sometimes it's really, really heplful to have the localised mis-match,
rather than
{{{
Can't match (Tree Int - [[Maybe a]] - [Tree (Maybe a)])
with (Tree Int - [[a]] - [Tree (Maybe a)}
}}}
when it's hard to do a visual diff. I suppose I could leave out the
rigid part if that would be less confusing.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1089
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1090: Bad monomorphism-restriction-related type error message
#1090: Bad monomorphism-restriction-related type error message -+-- Reporter: kirsten | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler (Type checker) |Version: 6.6 Severity: trivial | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -+-- Changes (by simonpj): * resolution: = wontfix * status: new = closed Comment: Again, I really don't see how to fix this. If there really was an instance for `Num [Char]` then the program really would be legal. Still I have to agree that it's not a terribly friendly message. Keep reporting them. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1090 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell] ANNOUNCE: Happy version 1.16
Am Montag, 8. Januar 2007 18:25 schrieb Sven Panne: FYI: I've just uploaded a binary RPM for openSUSE 10.2 (x86_64) and the corresponding source RPM. Currently I don't have access to openSUSE x86, but simply using rpmbuild -ba happy-1.16-1.src.rpm should build a 32bit RPM on those machines [...] Ooops, typo: One can use rpmbuild --rebuild happy-1.16-1.src.rpm. Fixing the web pages, too... Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: state of HaXml?
On 1/4/07, Norman Ramsey [EMAIL PROTECTED] wrote: There seems to be a misunderstanding here: readFile in itself is not the solution. readFile is defined thus: readFile name= openFile name ReadMode = hGetContents and the original code was this: load fn = do handle - IO.openFile fn IO.ReadMode contents - IO.hGetContents handle IO.hClose handle return $ XP.xmlParse fn contents Sure, you can replace the openFile/hGetContents pair by readFile, but the real problem is the presence of the hClose. Removing that will solve your problem (but note that you now have no control over when the file is actually closed). Can I just leave it hanging and rely on the garbage collector to close it in the fullness of time? Actually, hGetContents closes the handle when it gets an EOF. If it never does get EOF (because you never use all of the data), the garbage collector *might* close the handle, but I haven't heard of a garbage collector that was aware of the value of resources other than RAM (that is, they don't go out of their way to run finalizers and free up handles to OS resources). Java has the same problem, though I'm not sure if its file handles *have* finalizers, and Python does too, except the refcounting in CPython right now hides it. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: lhs2tex-1.12
lhs2TeX version 1.12 We are pleased to announce a new release of lhs2TeX, a preprocessor to generate LaTeX code from literate Haskell sources. lhs2TeX includes the following features: * Highly customized output. * Liberal parser -- no restriction to Haskell 98. * Generate multiple versions of a program or document from a single source. * Active documents: call Haskell to generate parts of the document (useful for papers on Haskell). * A manual explaining all the important aspects of lhs2TeX. Changes (w.r.t. lhs2TeX 1.11) - * Compatible with ghc-6.6. * Compatible with cabal-1.1.6; traditional configure/make installation should still work. Thanks to Brian Smith for submitting a patch to improve the Cabal experience on Windows. Requirements and Download - A source distribution is available from http://www.iai.uni-bonn.de/~loeh/lhs2tex/ It has been verified to build on Linux and MacOSX, but should also work on Windows. Binaries will be made available on request. You need a recent version of GHC (6.4.2 is tested, older versions might work) to build lhs2TeX, and, of course, you need a TeX distribution to make use of lhs2TeX's output. The program includes a configuration that is suitable for use with LaTeX. In theory, there should be no problem to generate code for other TeX flavors, such as plainTeX or ConTeXt. Happy lhs2TeXing, Andres Loeh and Ralf Hinze [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Beta Gtk2Hs Getting Started
On Mon, 2007-01-08 at 16:11 -0200, Alex Queiroz wrote: Hallo, On 1/8/07, Hans van Thiel [EMAIL PROTECTED] wrote: Hello All, The beta of the 'Gtk2Hs:Getting Started' short tutorial for beginners, Haskell GUI for Dummies, if you like :-) can be viewed at http://j-van-thiel.speedlinq.nl/gtk2hs/gtk2hsGetStart.html Nitpicking: Glade does not belong to GTK+, neither does libglade, which are independent projects. Thanks, I didn't know that. What other widget libraries are supported at this time? Regards, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Beta Gtk2Hs Getting Started
Hallo, On 1/8/07, Hans van Thiel [EMAIL PROTECTED] wrote: Thanks, I didn't know that. What other widget libraries are supported at this time? Only GTK+. :-) -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] question about database interfaces
Hi All, I've found the list of database libraries at http://www.haskell.org/haskellwiki/Libraries_and_tools/Database_interfaces but I haven't found much guidance in choosing among them. So I'm wondering -- in practice, what do people actually use? Is there a more-or-less generally accepted standard database library for Haskell? Thanks, Eric -- not about to see your light ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] question about How to Write a Haskell Program tutorial
Donald Bruce Stewart wrote: mvanier: First off, I apologize if this has come up before. As far as I can tell, the mailing list archives don't have a search function. I'm running ghc-6.6 and haddock-0.8, both compiled from source. I'm working my way through the How to Write a Haskell Program tutorial (which is a great idea, thanks guys!), and everything works fine until I get to the part about creating the haddock documentation. When I run: $ runhaskell Setup.hs haddock I get this: Preprocessing executables for haq-0.0... Running Haddock for haq-0.0... Warning: cannot use package haq-0.0: ghc-pkg failed With verbosity: $ runhaskell Setup.hs haddock -v I get this: Preprocessing executables for haq-0.0... Running Haddock for haq-0.0... /usr/local/packages/haskell-misc/bin/haddock --html --odir=dist/doc/html/haq --title=haq --use-package=haq-0.0 --use-package=base-2.0 dist/build/tmp/Haq.hs Warning: cannot use package haq-0.0: ghc-pkg failed Ah yes, I get this too when using ghc 6.6. With ghc 6.4.2 the haddock goes through fine. Updating haddock to 0.8 and the ghc-pkg error is still there. But the docs seem to be generated ok: Main Synopsis main :: IO () Documentation main :: IO () main runs the main program Produced by Haddock version 0.8 Simon, know what's going on? Fixed. The error is non-fatal (as you noticed) and was introduced in a recent version of Cabal. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Monad Set via GADT
Concerning (1) yes, this is a recent and substantial improvement in GHC (HEAD only). Concerning (3), this is a plain bug. I've just fixed it in the HEAD. I very much doubt I'll fix it in 6.6, because type inference in the HEAD now works rather differently. Thanks for the example; I've added it to the test suite! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim | Apple | Sent: 09 January 2007 01:52 | To: haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] Monad Set via GADT | | On 1/3/07, Roberto Zunino [EMAIL PROTECTED] wrote: | 1) Why the first version did not typececk? | 2) Why the second one does? | 3) If I replace (Teq a w) with (Teq w a), as in | SM :: Ord w = Teq w a - Set.Set w - SetM a | then union above does not typecheck! Why? I guess the type variable | unification deriving from matching Teq is not symmetric as I expect it | to be... | | These are very interesting questions that I forgot about until | reminded by Haskell Weekly News. Thanks, HWN! | | 1) Class constraints can't be used on pattern matching. They ARE | restrictive on construction, however. This is arguably bug in the | Haskell standard. It is fixed in GHC HEAD for datatypes declared in | the GADT way, so as not to break H98 code: | | http://article.gmane.org/gmane.comp.lang.haskell.cvs.all/29458/match=gadt+class+context | | 2) The second one works because Class constraints can be used when | pattern matching existentials. | | 3) I imagine this might have something to do with the coercions that | System FC uses. With one ordering, a coercion might occur that in | another one is unnecessary. This coercion might allow the use of Ord w | by using it before the coercion from S.Set a to S.Set w. | | #3 is just a guess. | | Jim | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about database interfaces
Eric Sessoms wrote: Hi All, I've found the list of database libraries at http://www.haskell.org/haskellwiki/Libraries_and_tools/Database_interfaces but I haven't found much guidance in choosing among them. , which is what most people are So I'm wondering -- in practice, what do people actually use? Is there a more-or-less generally accepted standard database library for Haskell? No, there isn't an accepted standard. For low-level database access (read: using SQL strings), HDBC, HSQL and Takusen are the currently useful libraries as far as I know. There is also HaskellDB, which attempts to free you from writing SQL and instead present a high-level, type-safe back-end independent interface. /Björn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Redefining superclass default methods in a subclass
One of the great things about John's class-alias proposal is that John worked out a lot of details and captured them in a web page, rather than it getting buried in an email thread. If you have ideas to refine his proposal, it'd be good to see if, with him, you can come up with a unified design, and again capture it in a Wiki page or something. For myself, I have not fully grokked either proposal, nor gotten a feel for their cost-benefit ratio. But the more well-articulated a design is, the more likely it is for someone (at GHC HQ or elsewhere) to have a go at implementing it. And of course one or two well-refined proposals are more attractive to implement than half a dozen intriguing but overlapping ones. So this message is really to encourage you to collaborate on writing up type-system proposals, at least ones that you care about. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roberto | Zunino | Sent: 04 January 2007 22:44 | To: Brian Hulley | Cc: Haskell-cafe | Subject: Re: [Haskell-cafe] Redefining superclass default methods in a subclass | | Brian Hulley wrote: | Hi, | Looking at some of the ideas in | http://www.haskell.org/haskellwiki/The_Other_Prelude , it struck me that | the class system at the moment suffers from the problem that as | hierarchies get deeper, the programmer is burdened more and more by the | need to cut-and-paste method definitions between instances because | Haskell doesn't allow a superclass (or ancestor class) method default to | be redefined in a subclass. | | The class aliases proposal lists several similar shortcomings of the | current class system. | | http://repetae.net/john/recent/out/classalias.html | | Perhaps there is some reason this can't be done? | | Some random thoughts: | | How one would write instances? Using your Monad class, does | instance Monad F where |return = ... |(=) = ... | automatically define an instance for Applicative? | | If it does: What if there already is such an instance? Which one gets | used for ()? The user-defined one or the Monad default? Is separate | compilation still possible? (If there is no instance right now, one | might pop out in another module...) | | If it does not: How can one define it, without copy-and-pasting the default? | | Zun. | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: question about database interfaces
Eric wrote: So I'm wondering -- in practice, what do people actually use? Is there a more-or-less generally accepted standard database library for Haskell? In practice I am using HDBC for a PostgreSQL database and it is very easy to use and works great. http://gopher.quux.org:70/devel/hdbc T ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Redefining superclass default methods in a subclass
Simon Peyton-Jones wrote: One of the great things about John's class-alias proposal is that John worked out a lot of details and captured them in a web page, rather than it getting buried in an email thread. If you have ideas to refine his proposal, it'd be good to see if, with him, you can come up with a unified design, and again capture it in a Wiki page or something. I've started a page at http://www.haskell.org/haskellwiki/Class_system_extension_proposal John - I haven't added anything about your class alias proposal because you've copyrighted your proposal and I don't want to do the wrong thing ;-) Can you add a section for your proposal (or containing a link to your proposal) on his page? Please could everyone who has any other ideas about class system extensions add them to the page above so that we have a central location. Hopefully it will gradually become clear what all the issues are and perhaps a path for trying to implement some extensions in order of difficulty. Thanks, Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Redefining superclass default methods in a subclass
Brian Hulley wrote: Simon Peyton-Jones wrote: One of the great things about John's class-alias proposal is that John worked out a lot of details and captured them in a web page, rather than it getting buried in an email thread. If you have ideas to refine his proposal, it'd be good to see if, with him, you can come up with a unified design, and again capture it in a Wiki page or something. I've started a page at http://www.haskell.org/haskellwiki/Class_system_extension_proposal John - I haven't added anything about your class alias proposal because you've copyrighted your proposal and I don't want to do the wrong thing ;-) Can you add a section for your proposal (or containing a link to your proposal) on his page? ^^^ Apologies for typo - should be this page Best regards, Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] hacking ghci
I'd suggest #2. It's exactly the reason that GHC is available as a library, and it makes your work much more independent of GHC. If you find it doesn't have the API you need, we can work to improve it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Walter Moreira | Sent: 08 January 2007 06:21 | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] hacking ghci | | Hi Haskellers. A short while ago I asked about the possibility to have | the output of ghci in color. Thanks to Donald Stewart who set up a | wiki page to continue the attempt. Other people suggested HsColour and | GUI's (thanks too). I'm not so interested in highlighting the snippets | of code which ghci displays, but to use different colors for the | different types of output: different colors for the prompt, input, | warnings, exceptions, normal output, etc. | | Are any of these ideas viable?: | | 1. Hack the code of Interactive.hs in the GHC distribution and |substitute the calls to 'putStr[Ln]' by some thin wrapper which can |write with colors, according to a command line option (--color or |--colour, for example), maybe using HsColour. This looks easy |enough and I'd be willing to do it, but it's intrusive, and one has |to mantain a different version of ghci in parallel with the main |ghci. | | 2. Use GHC as library (from 6.6 on) and write a similar application as |ghci, with more emphasis in the 'interactive' part of the name (in |the same way as the relation between Python and the IPython |extended shell). This is more work and more duplicate efforts, but |it may be worthly, perhaps. | | 3. Write a wrapper which communicates with ghci via pipes. I read some |attempts about this somewhere, and people suggested an approach as |in #2. | | I haven't mentioned the GUI applications, since I would like to just | have something in the spirit of ghci (command line oriented), but with | colors or with configurable output. Which approach do you people | think it is best? | | Sorry for the long message. Cheers, | Walter | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] restricted existential datatypes
hi, I am wondering whether it would be possible to use the existing haskell type system to simulate a certain feature. Namely, I am trying to apply ideas from [1] to existential datatypes. First I will describe the problem and later say something about the context in which it arose. I am using existential boxes like data Box cxt = forall a . Sat (cxt a) = Box a here Sat is taken from [1]: class Sat a where dict :: a The result is a box type which can have variable context imposed on its contents. What I noticed is that sometimes I want to write functions that operate on the Box and make use of some part of the context without knowing the context completely. Such a function would look something like this: f :: (Contains cxt ShowCxt) = Box cxt - String f (Box a) = show a The type is meant to say that the context of the box must contain Show as one of the classes. I would imagine the Contains class to be something like class Contains cxt subCxt where subDict :: cxt a - subCxt a Now inside f I would like to have the real (Show a) context available. So I'd have an instance (Sat cxt a, Contains cxt ShowCxt) = Show a where show = -- the show function extracted from (subDict dict) This instance of course does not work in ghc, because cxt is hanging in the air - I get an error whenever it tries to infer (Show a). The question I'd like to ask is whether there is some trickery to circumvent this problem. In the f function I'd like to be able to hint to the compiler that I want Show to be derived from cxt which is attached to the Box, but I see no way of doing that. (This by the way seems connected to http://www.mail-archive.com/haskell@haskell.org/msg19564.html). Now a couple of words about where I stumbled upon this problem. I am writing a program that is supposed to use plugins. The plugins operate among other things on Boxes as above. Now some plugins would like to demand some additional capabilities from the Box that cannot be foreseen at the spot where Box is defined. Parametrizing over context seems a very natural solution to me - leading to the problem above. I would be very thankful for any suggestions! Cheers, Misha Aizatulin 1. John Hughes, Restricted Data Types in Haskell, September 4, 1999 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] State monad strictness - how?
I can't seem to figure out how to achieve strictness in the context of the State monad. Consider: import Control.Monad.State try count = print final where (_,final) = runState prog 0 prog = sequence_ (replicate count tick) tick :: State Int Int tick = do n - get put (n+1) return n (try 100) overflows the stack. It doesn't help to use: put $! (n+1) The only way I've been able to get the necessary strictness is to add use of ($!) in the definition of (=): data SState s a = SState (s - (a,s)) instance Monad (SState s) where return x = SState (\s - (x,s)) m = f = SState (\s - let SState m' = m (x,s1) = m' s SState f' = f x (y,s2) = f' $! s1 in (y,s2)) runSState (SState m) s = m s sget = SState (\s - (s,s)) sput s' = SState (\s - ((),s')) stry count = print final where (_,final) = runSState prog 0 prog = sequence_ (replicate count stick) stick :: SState Int Int stick = do n - sget sput (n+1) return n Is there no way to get strictness using the standard State monad? Dean___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] restricted existential datatypes
Misha, This feels like you would compose dictionary types in heterogeneous lists and then have a type-driven lookup from the dictionary list; this would be very similar to the lookup operation for TICs in the HList lib, only that the driving type is of kind *-* and that the traversing instances eventually need to be constrained by the Sat constraint for the driving type. Do you think, this could work? Best, Ralf f :: (Contains cxt ShowCxt) = Box cxt - String f (Box a) = show a The type is meant to say that the context of the box must contain Show as one of the classes. I would imagine the Contains class to be something like class Contains cxt subCxt where subDict :: cxt a - subCxt a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] restricted existential datatypes
Did I say TICs? Assuming that you want to tuple up many constraints, I should have said TIPs of course. The SYB3 code distribution actually exercises some related chaining of contexts; cf. PairCtx. However, what's missing is the obliviousness dimension for irrelevant constraints. So you may want something like: class Sat ctx a = SatMember ctx ctx' a Let us know whether something like this works. Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
