Re: [Haskell-cafe] Re: Haskell Weekly News: Issue 140 - November 22, 2009
On Tue, Nov 24, 2009 at 05:46, Richard O'Keefe wrote: For example, ai in Maori means to copulate, Really [1]? It's amazing what Google [2] will tell you these days. ;) [1] http://researchspace.auckland.ac.nz/handle/2292/343 [2] http://www.google.com/search?q=ai+maori Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
Robert Greayer robgrea...@gmail.com writes:
allow local modules.
module Foo where
module Bar where
data Bar = Bar { x :: Int, y :: Int }
module Baz where
data Baz = Baz { x :: Int, y :: Int }
f a b = Bar.x a + Baz.y b
Independent of TDNR I would welcome this. Maybe Ticket 2551 (Allow
multiple modules per source file) [1] should be reconsidered.
Although ticket 2551 is not exactly what Luke is suggesting (which would be
an extension to the language, whereas, if I'm not mistaken, 2551 is just a
change to where GHC can find modules, not nesting of modules).
I think this would be great, and have very few negative
consequences. Having multiple modules per file would make it a lot more
convenient to define tiny modules and use namespacing more actively.
E.g. if module Foo.Bar isn't found in Foo/Bar.hs GHC could look in
Foo.hs (which would just contain a concatenation of what would currently
reside in Foo.hs and Foo/Bar.hs). So, Foo.hs could contain:
module Foo.Bar where
data Bar = Bar { x :: Int, y :: Int }
module Foo.Baz where
data Baz = Baz { x :: Int, y :: Int }
module Foo where
import Foo.Bar as Bar
import Foo.Baz as Baz
f a b = Bar.x a + Baz.y b
Since modules are already hierarchical, and there is already a mechanism
for scoping/qualification, I'm not sure modifying the language to allow
nesting actually buys anything. Or?
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Idea for a very simple GUI llibrary
I dream of mostly generated bindings for Haskell to the native windowing toolkit. Eclipse's SWT proves, this is a viable path. See my proposal here: http://www.reddit.com/r/haskell_proposals/comments/9w7nk/adjust_the_swt_binding_generators_for_haskell/ Sam Martin sam.mar...@geomerics.com hat am 23. November 2009 um 19:04 geschrieben: Thinking of a parallel with Java for a second, is there a GUI library out there that's structured like Java Swing? Meaning, there is a GUI library that has a small platform-specific GUI foundation (e.g. a per platform implementation of the core AWT functionality) and the rest of the functionality is pure haskell? Supporting cross platform guis is often a bit ... complicated. Java attempted to resolve their debug-everywhere nightmare with AWT by making the per-platform bit as small as possible, and building everything else in Java. I guess in theory gtk and wxWidgets take on this support burden, but you do get some fairly hefty imperative apis as a result. Perhaps it would make sense to focus efforts on stabilising a small 'core gui' library that can act as the foundation stone for all manner of pure haskell gui libraries?* Or perhaps this already exists? Just a thought. Cheers, Sam___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
On Sun, Nov 22, 2009 at 7:13 PM, Ketil Malde ke...@malde.org wrote: E.g. if module Foo.Bar isn't found in Foo/Bar.hs GHC could look in Foo.hs (which would just contain a concatenation of what would currently reside in Foo.hs and Foo/Bar.hs). The obvious question arising here is what if module Foo.Bar *is* found in Foo/Bar.hs as well as in Foo.hs - is the latter ignored? It doesn't sound like an insurmountable problem but one of the nicest things about the current module system is its simplicity and predictability, both of which are somewhat attacked by this proposal. Also, it sounds like your proposal would disallow definition of multiple top-level modules in a file, because we wouldn't know where to look for them. This is not necessarily unreasonable, but it's an unexpected special case. Presumably having the modules together in a file would also mean that they could only be compiled together and would produce a single .o or .hi file. Then you might ask whether the ABI or whatever is necessarily broken by a change to *any* of the modules involved, in which case modularisation starts to become purely about name qualification. Thinking about that, it's worth noting that importing one module twice with two different names works fine. This is not to say I'm against the proposal, but it's probably not as clear-cut as it sounds. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 75, Issue 51
1) the uncensored version 2) Monadam* 3) Monada** 4) Monad*** 5) Mona Putting stars in place of letters in no way makes a word less offensive. Consider the word 'ing'. It's about context. I think it's wise that such a word have a star put in it in the weekly news or a journal article as it shows the author is less bombastic and doesn't want to use loud language - which counts for a lot in other's opinions. Johnny ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pointfree rank-2 typed function
Hello,
Given this program:
{-# LANGUAGE Rank2Types #-}
newtype Region s a = Region a
unRegion :: forall a s. Region s a - a
unRegion (Region x) = x
runRegionPointfull :: forall a. (forall s. Region s a) - a
runRegionPointfull r = unRegion r
Is it possible to write the rank-2 typed function 'runRegionPointfull'
in pointfree style?
Unfortunately the following doesn't typecheck:
runRegionPointfree :: forall a. (forall s. Region s a) - a
runRegionPointfree = unRegion
Couldn't match expected type `forall s. Region s a'
against inferred type `Region s a1'
In the expression: unRegion
In the definition of `runRegionPointfree':
runRegionPointfree = unRegion
Why can't the typechecker match `forall s. Region s a' and `Region s a1'?
Thanks,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
Ben Millwood hask...@benmachine.co.uk writes: E.g. if module Foo.Bar isn't found in Foo/Bar.hs GHC could look in Foo.hs (which would just contain a concatenation of what would currently reside in Foo.hs and Foo/Bar.hs). The obvious question arising here is what if module Foo.Bar *is* found in Foo/Bar.hs as well as in Foo.hs - is the latter ignored? I would suggest this situation to be an error, but ghc currently appears to handle ambiguitiy by picking the first one that fits (according to my experimentation with multiple source directories and the -i option). It doesn't sound like an insurmountable problem but one of the nicest things about the current module system is its simplicity and predictability, both of which are somewhat attacked by this proposal. As mentioned, there is already ambiguity, but of course this proposal would increase the number of paths to search. Also, it sounds like your proposal would disallow definition of multiple top-level modules in a file, because we wouldn't know where to look for them. Yes, I don't see how to do that either, unless you introduce a generalized --main-is option, or similar. (Speaking about which, one obvious exception would be that the file Foo.hs could contain the Main module in addition to any modules in the Foo.* hierarchy. So it'd allow more structure to single-file applications. For what it's worth.) Presumably having the modules together in a file would also mean that they could only be compiled together and would produce a single .o or .hi file. Not sure about that, you'd still be able to build multiple .o/hi's, and conditional compilation could be done by checksumming the indidual modules. Anyway, I think the main use-case here is for multiple small modules, so the impact on compile times might even be positive (for trivial modules, the compile time might be dominated by the IO operations). This is not to say I'm against the proposal, but it's probably not as clear-cut as it sounds. Thinking about it, I guess I'm really wanting to address a weakness in my development system (namely that it is cumbersome to work with a myriad of tiny files). And it occurs to me that the compiler might not be the appropriate place to do solve this. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Weekly News: Issue 140 - November 22, 2009
Incidentally, I've always wondered about the politically correct way of referring to this programming language (and related implementation in the above-mentioned type system) in academic circles; Is this a question of politically correctness? Since there's no discrimination or prejudice involved, I think it's more of a question of social rules. If you are using a word where it's going to be indexed, like article titles, I vote for beeing accurate. But outside that, it's difficult to answer this in a way that extends beyond one's own circle of friends. Censoring a bad word may be polite for some, and offensive for others, what could we do about that? Regarding brainfuck itself, I think beeing censored is part of the joke. In general, if a programming language-related term contains what is generally regarded as a profane word as a component, for what kinds of written material should I prioritize accuracy vs. propriety? If we decide to allow * inside conids and varids in Haskell, and have a rule that names clash when they differ only by a letter replaced by a *, we have gone too far. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Announcing Haskell 2010
On 24/11/2009 15:19, David Leimbach wrote: First off congratulations everyone! Second, Oh shit! Graham Hutton's excellent Haskell introduction book is now not valid Haskell 2010 due to N+K patterns? Right, but it's still valid Haskell 98, and we have no immediate plans at least in GHC to drop support for Haskell 98. It will probably not be the default in 6.14.1, though. Cheers, Simon I loaned that book to my boss and he's really enjoyed it. I guess I'll have to buy a revised copy. Can we get an update to it? :-) I realize N+K was considered dangerous On Tue, Nov 24, 2009 at 2:50 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: I'm very proud to announce a new revision of the Haskell language, Haskell 2010. Over the last couple of months the committee has been making final decisions about which extensions should be a part of this revision. The final list is: DoAndIfThenElse HierarchicalModules EmptyDataDeclarations FixityResolution ForeignFunctionInterface LineCommentSyntax PatternGuards RelaxedDependencyAnalysis LanguagePragma NoNPlusKPatterns You can read more about each one, including rationale for and against, on its relevant wiki page, which are linked from the tickets: http://hackage.haskell.org/trac/haskell-prime/query?status=newstatus=assignedstatus=reopenedstate=acceptedmilestone=Haskell+2010order=priority http://hackage.haskell.org/trac/haskell-prime/query?status=newstatus=assignedstatus=reopenedstate=acceptedmilestone=Haskell+2010order=priority Haskell 2010 is a small but significant step on the road that was started by the Haskell' committee 4 years ago, The process has not been a smooth one, and there have been several changes of direction, but the current process is actually producing concrete results that let us move the language forward in positive steps, so I feel we're on the right track. We all owe the current committee a big thank-you for sticking with the process this long: most of them didn't realise the magnitude of what they were signing up for at the beginning. The short list of changes above tells only a small part of the story, there is a wealth of wiki content and mailing-list discussion that future language revisions can draw on. So what now? * We will produce a revised version of the Haskell language report incorporating these changes. That will happen over the next few months. * Compilers can start implementing the changes, and flags to select the Haskell 2010 revision. In GHC we expect to have support in the next major release, i.e. 6.14.1. * Right now, we will start forming a Haskell 2011 committee to mange the process of deciding on changes for next year's revision. The current committee is still discussing how to go about finding a new committee (the plan is to at least have open nominations) but I expect to be able to announce more details very soon. * Everyone can participate in the Haskell 2011 process, by discussing and refining proposals. Information about how to do that is on the Haskell Prime wiki: http://hackage.haskell.org/trac/haskell-prime/wiki Remember: this is a community effort. The changes that get adopted in each revision are drawn from the pool of fully-specified proposals, and those proposals can be written by anyone. Thanks, Simon, on behalf of the Haskell 2010 committee ___ Haskell mailing list hask...@haskell.org mailto:hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HOpenGL and freeglut rendering problems
Hello. I'm new to this mailing list, so I apologize if this question is inappropriate for this list, but I've been looking for a solution to this problem for weeks and I've had no luck. I am trying to write a program with HOpenGL and freeglut, but I can't seem to get it to render. I'm running Ubuntu 9.10 on a DELL 1555 with an ATI Radeon HD 4500. Right now my program just creates a window with a black background. However, when I try to run the program I get the following error: Unable to create direct context rendering for window 'IGL' This may hurt performance. I've read that this is because of the fglrx driver. The driver uses indirect rendering for OpenGL, but freeglut requires direct rendering? Is there a way to force freeglut to function with indirect rendering? -Eitan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Pointfree rank-2 typed function
It used to be, because GHC used to implement so-called deep skolemisation.
See Section 4.6.2 of
http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/putting.pdf
Deep skolemisation was an unfortunate casualty of the push to add impredicative
polymoprhism. However, as I mentioned in an earlier email, I'm currently
planning to take impredicative polymorphism *out*, which means that deep
skolemisation might come back *in*.
Simon
| -Original Message-
| From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On
| Behalf Of Bas van Dijk
| Sent: 24 November 2009 13:34
| To: Haskell Cafe
| Subject: [Haskell-cafe] Pointfree rank-2 typed function
|
| Hello,
|
| Given this program:
|
|
| {-# LANGUAGE Rank2Types #-}
|
| newtype Region s a = Region a
|
| unRegion :: forall a s. Region s a - a
| unRegion (Region x) = x
|
| runRegionPointfull :: forall a. (forall s. Region s a) - a
| runRegionPointfull r = unRegion r
|
|
| Is it possible to write the rank-2 typed function 'runRegionPointfull'
| in pointfree style?
|
| Unfortunately the following doesn't typecheck:
|
| runRegionPointfree :: forall a. (forall s. Region s a) - a
| runRegionPointfree = unRegion
|
| Couldn't match expected type `forall s. Region s a'
|against inferred type `Region s a1'
| In the expression: unRegion
| In the definition of `runRegionPointfree':
| runRegionPointfree = unRegion
|
| Why can't the typechecker match `forall s. Region s a' and `Region s a1'?
|
| Thanks,
|
| Bas
| ___
| 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] Pointfree rank-2 typed function
On Tue, Nov 24, 2009 at 6:02 PM, Simon Peyton-Jones simo...@microsoft.com wrote: It used to be, because GHC used to implement so-called deep skolemisation. See Section 4.6.2 of http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/putting.pdf Deep skolemisation was an unfortunate casualty of the push to add impredicative polymoprhism. However, as I mentioned in an earlier email, I'm currently planning to take impredicative polymorphism *out*, which means that deep skolemisation might come back *in*. Ok nice because I'm very used to refactor code like: 'f x = g x' to 'f = g' for all f and g. Thanks, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pointfree rank-2 typed function
Simon Peyton-Jones wrote: It used to be, because GHC used to implement so-called deep skolemisation. See Section 4.6.2 of http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/putting.pdf Deep skolemisation was an unfortunate casualty of the push to add impredicative polymoprhism. However, as I mentioned in an earlier email, I'm currently planning to take impredicative polymorphism *out*, which means that deep skolemisation might come back *in*. Are there workarounds for uses of impredicative types, or do we lose the ability to express certain programs as a result? Thanks, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
* For record selectors, currently written (x r), writing r.x is exactly right Algol 68 used 'x of r', which I always found rather readable. COBOL has always used 'x of r' and 'x in r' with the same meaning. BCPL uses 'f O§F r' which may I believe also be written 'f::r'. Fortran uses 'r%x'. Knuth's The Art of Computer Programming uses X(R). Erlang uses 'x#type.r'. r.x is no more exactly right than x r or x OF r or anything else one might come up with. Is there any need to still limit ourselves to ASCII? Might we dare at long last to use the section sign § and write r§x? If any symbol is appropriate for getting part of something, surely section is! (If you want to call it Select, why, § is a modified capital S.) Best of all, § has no other uses in Haskell. (It isn't _quite_ as easy to type as dots are, but option 6 isn't _that_ hard to type.) Oh, and if you think dots are great, why, § has a fat dot right in the middle of it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell Weekly News: Issue 140 - November 22, 2009
On Nov 24, 2009, at 10:29 PM, Sean Leather wrote: On Tue, Nov 24, 2009 at 05:46, Richard O'Keefe wrote: For example, ai in Maori means to copulate, Really [1]? It's amazing what Google [2] will tell you these days. ;) Really! Check http://www.maoridictionary.co.nz/ In fact if you read [1], you will find There is also another lexical ai which is a verb with the meaning ‘to copulate’ on page 4. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell-mode.el mailing list (+ dpatch)
Is there anybody except me feeling the need for mailing list and issue tracker for emacs' haskell-mode? Mailing list is a forum to discuss ideas _and_ the area of patch authors' self-advertisement. And issue tracker is a TODO list; it may be useful or annoying, and I think we can live without one for a while. But I vote for haskell-mode.el mailing list. Examples: http://www.haskell.org/mailman/listinfo/xmonad http://code.google.com/p/xmonad/issues/list -- Description of the attached dpatch: * make `inferior-haskell-find-project-root' respect export lists A hierarchical module (one or more dots in module name) with an export list cannot be loaded (`C-c C-l') unless there is .cabal file available. That is because regexp current in `inferior-haskell-find-project-root' does not match module headers with export lists. Like this one: module Codec.Binary.MSCP ( -- * Data structures FileHeader(..), CDR(..), -- * Parsing readFile ) where This patch makes the regexp less strict. Have fun! -- vvv #part type=application/octet-stream filename=/tmp/XXX/respect-export-lists.dpatch disposition=attachment description=respect-export-lists.dpatch #/part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell-mode.el mailing list (+ dpatch)
-- Description of the attached dpatch: * make `inferior-haskell-find-project-root' respect export lists No joke this time. Sorry for the glitch. -- vvv Tue Nov 24 23:48:05 EET 2009 Valery V. Vorotyntsev valery...@gmail.com * make `inferior-haskell-find-project-root' respect export lists A hierarchical module (one or more dots in module name) with an export list cannot be loaded (`C-c C-l') unless there is .cabal file available. That is because regexp current in `inferior-haskell-find-project-root' does not match module headers with export lists. Like this one: module Codec.Binary.MSCP ( -- * Data structures FileHeader(..), CDR(..), -- * Parsing readFile ) where This patch makes the regexp less strict. New patches: [make `inferior-haskell-find-project-root' respect export lists Valery V. Vorotyntsev valery...@gmail.com**20091124214805 Ignore-this: 13944cebba542b12a6b02a7c8ef43c81 A hierarchical module (one or more dots in module name) with an export list cannot be loaded (`C-c C-l') unless there is .cabal file available. That is because regexp current in `inferior-haskell-find-project-root' does not match module headers with export lists. Like this one: module Codec.Binary.MSCP ( -- * Data structures FileHeader(..), CDR(..), -- * Parsing readFile ) where This patch makes the regexp less strict. ] hunk ./inf-haskell.el 285 (goto-char (point-min)) (let ((case-fold-search nil)) (when (re-search-forward - ^module[ \t]+\\([^- \t\n]+\\.[^- \t\n]+\\)[ \t]+where\\ nil t) + ^module[ \t]+\\([^- \t\n]+\\.[^- \t\n]+\\)[ \t]+ nil t) (let* ((dir default-directory) (module (match-string 1)) (pos 0)) Context: [Emacs regexes are not perl regexes! svein@aas.no**20091120123455 Ignore-this: 7adddfb072ffabb8e02457fd9f1d7179 ] [Add missing `:group's to defcustoms. Dave Love f...@gnu.org**2009105701 Ignore-this: c5126608a89343c907e6a03f77143a82 ] [Resolve conflict with mdo patch. Dave Love f...@gnu.org**20091110143208 Ignore-this: 48568e05d3b1d48d5a3c8014e5287fe3 ] [Allow non-ASCII names. Dave Love f...@gnu.org**20091105212057 Ignore-this: f46f407a19ae2a597f44317e4915e5ba The code already used char-classes unconditionally, though I didn't think they're supported in XEmacs. ] [Various fixes for Emacs 21. Dave Love f...@gnu.org**20091105211507 Ignore-this: caae466ff29882fa42f44e081d0a8909 ] [Fix treatment of missing syntax-ppss. Dave Love f...@gnu.org**2009111819 Ignore-this: 284f4d7440592d4b7f4697d1bf2483c7 ] [Comment/doc/message fixes. Dave Love f...@gnu.org**20091105212607 Ignore-this: 15a2aa347da042465d652328b91324a1 ] [Parse the unicode syntax for (::) vandijk.r...@gmail.com**20091106085644 Ignore-this: f4d582279acbaf613b5d77b6788c8189 ] [Fixed bug in haskell-decl-scan.el when using unicode syntax vandijk.r...@gmail.com**2009110615 Ignore-this: 6e8eecb8bd1d7d5ddfc0496bee4d4f3f ] [Indent mdo as do svein@aas.no**20091109214749 Ignore-this: 8cf3b448fcde1d8219c4c97ba1955c85 ] [TAG 2.6.4 svein@aas.no**20091107110901 Ignore-this: d2d4c16df56f5bb4b749e886a99e0550 ] Patch bundle hash: db4c47fb09199c61b1611bfbb46a9e0277c82c0a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Where is `newTVarIO` defined ?
I cannot hoogle it. It appears in Pugs: run' (-d:rest) = do info - fmap Just (io $ newTVarIO Map.empty) let ?debugInfo = info run' rest Sincerely! - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Where-is-%60newTVarIO%60-defined---tp26504967p26504967.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where is `newTVarIO` defined ?
Control.Concurrent.STM On Nov 24, 2009, at 6:11 PM, zaxis wrote: I cannot hoogle it. It appears in Pugs: run' (-d:rest) = do info - fmap Just (io $ newTVarIO Map.empty) let ?debugInfo = info run' rest Sincerely! - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Where-is-%60newTVarIO%60-defined---tp26504967p26504967.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com . ___ 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] Where is `newTVarIO` defined ?
On Tue, Nov 24, 2009 at 11:11 PM, zaxis z_a...@163.com wrote: I cannot hoogle it. It appears in Pugs: run' (-d:rest) = do info - fmap Just (io $ newTVarIO Map.empty) let ?debugInfo = info run' rest Sincerely! - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Where-is-%60newTVarIO%60-defined---tp26504967p26504967.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe http://hackage.haskell.org/packages/archive/stm/latest/doc/html/Control-Concurrent-STM-TVar.html The docs for it are in GHC.Conc but you probably wouldn't import it from there. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell-mode.el mailing list (+ dpatch)
valery...@gmail.com (Valery V. Vorotyntsev) writes: Is there anybody except me feeling the need for mailing list and issue tracker for emacs' haskell-mode? FWIW, you have my vote too. I'm convinced that a discussion forum and tracker would foster contributions from the many emacs users in the community. Cheers, jao -- Purely applicative languages are poorly applicable. - Alan Perlis, Epigrams in Programing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Where is `newTVarIO` defined ?
thanks! Maybe the hoogle shoud add it Ross Mellgren wrote: Control.Concurrent.STM On Nov 24, 2009, at 6:11 PM, zaxis wrote: I cannot hoogle it. It appears in Pugs: run' (-d:rest) = do info - fmap Just (io $ newTVarIO Map.empty) let ?debugInfo = info run' rest Sincerely! - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Where-is-%60newTVarIO%60-defined---tp26504967p26504967.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com . ___ 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 - fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Where-is-%60newTVarIO%60-defined---tp26504967p26505553.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] implementing recursive let
I am trying to write an interpreter for a very simple untyped functional
language. I have a problem with mutually recursive let expressions, for
which my interpreter loops :(
This is a code snippet from the eval function:
eval :: Expr - Eval Value
eval (Let decls body) = mdo
let (names,exprs) = unzip decls
let updateEnv env = foldr (uncurry M.insert) env $ zip names values
(values,result) - local updateEnv $ liftM2 (,) (mapM eval exprs) (eval
body)
return result
Module M is Data.Map, the environment is a simple map from strings to
values. Values are defined as
data Value = Data String | Function (Value - Eval Value)
The Eval monad is defined as
newtype Eval a = Eval {
unEval :: ErrorT String (StateT Env (Writer [String])) a
} deriving (
Monad,
MonadFix,
MonadWriter [String], -- for warnings other messages
MonadState Env,
MonadError String
)
instance MonadReader Env Eval where
ask = get
local tr act = do
s - get
modify tr
r - act
put s
return r
When I test this with an extremely simple expression, something like let x
= 1 in x, the code above loops. I don't understand why, especially since
in a previous version it worked. In the previous version I had a simpler
monad stack that went
newtype Eval a = Eval {
unEval :: ReaderT Env (Writer [String])) a
} deriving (
Monad,
MonadFix,
MonadWriter [String],
MonadReader Env
)
(Replacing reader with state was done so I can add definitions to the
environment at runtime. The ErrorT provides for errors, such as application
of a non-function.)
Expressions not involving let work fine. Also, if I replace the above
definition by one which does not allow recursion (not using mdo, evaluating
the defining expressions before the variable gets added to the
environment), then non-recursive let-expressions (like the simple example
above) work just fine.
I am out of ideas as to what causes this problem. Does the addition of
ErrorT make my monad too strict? How else can I implement mutual recursion?
Cheers
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] implementing recursive let
The following code works fine for me, so it seems you are missing some
details that may help.
{-# LANGUAGE RecursiveDo, GeneralizedNewtypeDeriving,
TypeSynonymInstances, MultiParamTypeClasses #-}
import Control.Monad
import Control.Monad.State
import Control.Monad.Error
import Control.Monad.Writer
import Control.Monad.Reader
import Control.Monad.Fix
import Data.Maybe
import qualified Data.Map as M
data Expr = Let [(String, Expr)] Expr | Const Int | Var String
data Value = Data String | Function (Value - Eval Value)
instance Show Value where
show (Data s) = s
type Env = M.Map String Value
example = Let [(x, Const 1)] (Var x)
eval :: Expr - Eval Value
eval (Const n) = return (Data (show n))
eval (Var x) = gets (fromJust . M.lookup x)
eval (Let decls body) = mdo
let (names,exprs) = unzip decls
updateEnv env = foldr (uncurry M.insert) env $ zip names values
(values,result) - local updateEnv $ liftM2 (,) (mapM eval exprs) (eval body)
return result
newtype Eval a = Eval {
unEval :: ErrorT String (StateT Env (Writer [String])) a
} deriving (
Monad,
MonadFix,
MonadWriter [String], -- for warnings other messages
MonadState Env,
MonadError String
)
runEval :: Eval Value - Either String Value
runEval = fst . runWriter . flip evalStateT M.empty . runErrorT . unEval
evaluate = runEval . eval
instance MonadReader Env Eval where
ask = get
local tr act = do
s - get
modify tr
r - act
put s
return r
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE managing cabal dependencies using nix and hack-nix
First of all: This is a release (very) early and often release
announcment. So expect that there are some minor glitches [5].
Linux is only supported at this moment. [1]
summary:
main goal: provide an environment (= list dependencies) to build a
haskell package with minimal efforts.
The two repositories
git://github.com/MarcWeber/haskell-nix-overlay.git
git://github.com/MarcWeber/hack-nix.git
enable you to build dependencies required to build a specific cabal
project automatically. In some way its similar to what cabal-install
provides. However haskell packages are installed using the nix package
manager which allows you installing arbitrary versions of the same
packages at the same time on the same system.
Follow their READMEs to get latest updates.
what is nix?
See http://nixos.org. Brief: its a package manager utilizing a lazy,
interpreted language called nix to describe package dependencies.
Packages can be installed into user environments. Atomic updates and
rollbacks are some of its key features as well as allowing the user /
or system to install additional versions of a package without breaking
previously installed software. [2] I won't go into details here.
repo haskell-nix-overlay:
=
This contains a sketchy implementation of a dependency solver for cabal
packages using a brute force algorithm [6].
It also contains a set of patches to make hackage packages compile.
hack-nix creates a copy of the hackage index file 00-index.tar called
hackage/hackage-nix-db.nix which can be read by the nix language
applying some optimizations.
You run the solver by telling it about your target
packages and their cabal flags. [3]
globalFlags = {
base4 = true;
}
packageFlags = {
Cabal-1.4.4.splitBase = true;
};
targetPackages = [
happy
HAppS-Server
haskell-src
];
I only pasted the most important parameters here.
So what is this all for?
Many existing package managers assume that there is only one true way to
install packages - using the versions which got packaged.
You want to switch from base-3 to base-4 ? You want to use both?
Some package build with parsec-2 others require parsec-3?
Out of luck(?) Maybe you end up using different users, installing all
packages manually into local (user) databases. Also determining which
packages must be recompiled is a tedious job. So you updated a package
and you have recompiled depending packages. Then you notice that you
want to fix a small bug in an app you didn't update for ages.. however
the old versions of your libraries have been replaced with newer ones..
usage example
==
Let me introduce you to a small hack-nix workflow showing you how I
think you should use it:
# get a cabal package.
vcs clone
# tell hack-nix about package profiles. A profile is a name associated
# with cabal flags:
echo default:-split-base .hack-nix-cabal-config
# run hack-nix to build all dependencies required by [3]
# and create a file exporting PATH and GHC_PACKAGE_PATH
# you should source that in your bash or zsh session
hack-nix --build-env default
source hack-nix-envs/default/source-me/haskell-env
ghc --make Setup.hs
./Setup configure # optionally repeat the cabal flags here [4]
./Setup build
# the package bulids? fine. Now you can register it at your nix
# configuration file ~/.nixpkgs/config.nix after creating a dist file
# and an unmodified representation of the cabal file:
hack-nix --to-nix
cat ~/.nixpkgs/config.nix EOF
{pkgs, ... }: {
hackNix.additionalPackages = [
(import $PATH_TO_CABAL_REPO/dist/$CABAL_PROJECT_NAME.nix)
# repeat the line above for each package
];
}
EOF
From now on nix will know about your (dev version?) of the pkg and it can
be
used when running hack-nix --build-env in other cabal directories.
Let's compare it to cabal install --user here:
base - lib - otherlib - target
you build a dev version of lib.
When running hack-nix --build-env default in the target cabal directory
otherlib will be rebuild automatically.
nix can also create tag files for you. This is implemented but it's not
supported by hack-nix --build-env yet. (TODO)
Now you want to clean those many builds get rid of them and tidy up.
Just run nix-collect-garbage to remove all packages managed by nix
which are no longer referenced by any environment or their previous
generations. Generations? This means that if updating an environment
causes more trouble to than it solves you can temporarily switch back to
the environment you were using before.
How to get started?
===
See [5], read those READMEs. Tell me about your problems.
Right now HAppS-Server and hack-nix can be built easily.
More work has to be done to make all packages compile.
This usally means replacing base 4 by base 5 or such.
Another cause of failure is that C-lib dependencies such as
gtk,
[Haskell-cafe] Possible FGL bug
When developing my QuickCheck-2 test-suite for graphviz, I wrote the
following Arbitrary instance for FGL graphs (which needs
FlexibleInstances):
,
| instance (Graph g, Arbitrary n, Arbitrary e, Show n, Show e) = Arbitrary (g
n e) where
| arbitrary = do ns - liftM nub arbitrary
| let nGen = elements ns
| lns - mapM makeLNode ns
| trace (Nodes: ++ show lns) (return ())
| les - listOf $ makeLEdge nGen
| trace (Edges: ++ show les) (return ())
| return $ mkGraph lns les
| where
| makeLNode n = liftM ((,) n) arbitrary
| makeLEdge nGen = liftM3 (,,) nGen nGen arbitrary
|
| shrink gr = map (flip delNode gr) (nodes gr)
`
However, when I try to run this, I occasionally get irrefutable pattern
match failures as follows:
,
| *Data.GraphViz.Testing.Instances.FGL Data.Graph.Inductive.Tree sample
(arbitrary :: Gen (Gr Int Char))
|
|
| 0:0-[]
|
| 0:-2-[]
| 1:0-[('\a',0)]
| 2:0-[]
|
| -4:-3-[('U',-3),('#',1)]
| -3:3-[]
| 1:-1-[('}',-3)]
|
| -8:8-[]
| -3:2-[]
| -1:-5-[('\US',-3),('',0)]
| 0:5-[('F',-1),('p',4)]
| 4:-1-[]
|
|
-2:8-[('\177',-2),('(',-2),('d',-2),('4',-2),('D',-2),('\US',-2),('d',-2),('u',-2)]
|
| -16:11-[]
| -2:-2-[]
| 0:11-[('@',1)]
| 1:13-[('u',11)]
| 9:-11-[('\231',11)]
| 11:12-[('\226',1)]
| 16:15-[]
|
| -10:2-[]
| -4:8-[]
| 1:30-[]
| 26:26-[('',1),('K',-4)]
| 31:-21-[]
|
| -35:51-[('@',-29)]
| -29:21-[('\132',-11)]
| -11:-31-[('j',61)]
| -4:40-[('a',-29)]
| 0:6-[('z',-35),('9',28),('\170',-11),('\SUB',28)]
| 23:8-[('P',-29),('(',61),('\\',28)]
| 28:60-[]
| 61:44-[('q',61)]
| *** Exception: Data/Graph/Inductive/Graph.hs:250:26-59: Irrefutable pattern
failed for pattern (Data.Maybe.Just (pr, _, la, su), g')
`
The actual error comes from the definition of insEdge:
,
| -- | Insert a 'LEdge' into the 'Graph'.
| insEdge :: DynGraph gr = LEdge b - gr a b - gr a b
| insEdge (v,w,l) g = (pr,v,la,(l,w):su) g'
| where (Just (pr,_,la,su),g') = match v g
`
with the Graph instance for Tree-based graphs using this for its mkGraph
method:
,
| mkGraph vs es = (insEdges' . insNodes vs) empty
| where
| insEdges' g = foldl' (flip insEdge) g es
`
So, is this really a bug in FGL, or am I using mkGraph wrong?
On another note, why doesn't the PatriciaTree graph type have a Show
instance? :(
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Machine Learning Library (SVM)
Hello cafe, Does anybody knows if there is a Machine Learning Library for Haskell? I looked in hackage and couldn't find anything but something for Data Mining but that's not what I need, however, googling I saw a ticket for google summer of code for writing such library proposed by Ketil Malde. Ketil, has any progress been made on that library? Specially in the SVM part which is what I'm really looking for... Thanks to everyone in advance, Hector Guilarte ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] surrogate code points in a Char
On Nov 18, 2009, at 7:28 AM, Manlio Perillo wrote: The Unicode Standard (version 4.0, section 3.9, D31 - pag 76) says: Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range D800 .. DFFF are ill-formed The current version of Unicode is 5.1. This text is now in D90, though otherwise the same. My references below are to the 5.1 documents (freely available on line at: http://www.unicode.org/versions/Unicode5.1.0/ ) However GHC does not reject this code units: Prelude print '\xD800' '\55296' Is this a correct behaviour? I don't think you should consider Char to be UTF-32. Think of Char as representing a Unicode code point. Unicode code points are defined as all in integers in the range \x0 through \x10, inclusive. Values in the range \xD800 through \xDFFF are all valid code points. (§2.4 in general; §3.4, D9, D10) Not all Unicode code points are Unicode scalar values. Only Unicode scalar values can be encoded in the standard Unicode encodings. Unicode scalar values are defined a \x0 through \xD7FF and \xE000 through \x10 - All code points except the surrogate pair area. (§3.9, D76) Not all code points are characters. In particular, \xFFFE, \x are Noncharacters: They are representable in Unicode encodings, but should not be interchanged. Less well known is the range \xFDD0 though \xFDEF which are also noncharacters. (§2.4, Table 2-3; §3.4, D14, §16.7) In particular, note the stance of Unicode toward application internal forms: Applications are free to use any of these noncharacter code points. internally but should never attempt to exchange them. - §16.7 ¶3 Accordingly, it is fine for Haskell's Char to support these values, as they are code points. The place to impose any special handling is in Haskell's various Unicode encoding libraries: When decoding, code points \xD800 through \xDFFF cannot be received, and noncharacters can be either retained or silently dropped (Unicode conformance allows this.) When encoding, code points \xD800 through \xDFFF and noncharacters should either error or just be silently dropped. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Machine Learning Library (SVM)
Hector Guilarte hector...@gmail.com writes: Ketil, has any progress been made on that library? Specially in the SVM part which is what I'm really looking for... No, the SoC ticket was not funded, and I am not aware of any other Haskell implementation of SVMs (and if there is one, I'm sure it will be pointed out on this list). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Machine Learning Library (SVM)
look at: http://www.cs.utah.edu/~hal/SVMseq/ this works but is a little slow and would benefit by being updated to use the bytestring library. and generic data clustering ... http://www.cs.utah.edu/~hal/GDC/ From: ke...@malde.org To: hector...@gmail.com Subject: Re: [Haskell-cafe] Machine Learning Library (SVM) Date: Wed, 25 Nov 2009 07:56:08 +0100 CC: haskell-cafe@haskell.org Hector Guilarte hector...@gmail.com writes: Ketil, has any progress been made on that library? Specially in the SVM part which is what I'm really looking for... No, the SoC ticket was not funded, and I am not aware of any other Haskell implementation of SVMs (and if there is one, I'm sure it will be pointed out on this list). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe _ For more of what happens online Head to the Daily Blob on Windows Live http://windowslive.ninemsn.com.au/blog.aspx___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: haskell-mode.el mailing list (+ dpatch)
On Wed, Nov 25, 2009 at 1:03 AM, Jose A. Ortega Ruiz j...@gnu.org wrote: valery...@gmail.com (Valery V. Vorotyntsev) writes: Is there anybody except me feeling the need for mailing list and issue tracker for emacs' haskell-mode? FWIW, you have my vote too. I'm convinced that a discussion forum and tracker would foster contributions from the many emacs users in the community. I would like to see this too. emacs-mode is important for my productivity. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
