Re: [Haskell-cafe] Monads from Functors
Edward Kmett wrote: I think there is another way to view the ContT/Codensity/Monad generated by a functor, in terms of an accumulating parameter that may be informative. [...] Now what I find interesting is that Yoneda is basically carrying around an accumulator for 'fmap' applications. [...] When you look at the definition for Codensity f a, what it effectively supplies is a 'better accumulator', one which is large enough to encode (>>=). Indeed an insightful perspective! Ryan Ingram wrote: If we have a computation a :: Monad m => m a and we have a pointed functor `f`, then we can get the result of the computation `a` in our functor `f` because `runContT a :: f a`. Sure, but you can also do the same much more simply: mkPointed :: Pointed f => forall f a. (forall m. Monad m => m a) -> f a mkPointed m = point $ runIdentity m Ha! Nice damper. So the interesting part is not that one gets a monad for free but that one gets a monad for free that can be combined with effects defined elsewhere. That seems closely related to your MonadPrompt. Thanks for the pointer. You may as well do the following: data MPlus a = Zero | Pure a | Plus (MPlus a) (MPlus a) instance Monad MPlus where ... instance MonadPlus MPlus where ... mkAlternative :: forall f a. Alternative f => (forall m. MonadPlus m => m a) -> f a (all this code is really saying is that being polymorphic over MonadPlus is kind of dumb, because you aren't really using Monad at all) Well, you can use return, bind, mzero and mplus.. I'd consider this *really* monad. You are right, that your version is equivalent to the "generic" MonadPlus instance which (only) eliminates the intermediate data structure. Without any way to lift other effects from the underlying functor into ContT, I don't really see how the "generic" ContT MonadPlus instance buys you much :) I'm not sure which other effects can be lifted without bind and which need lift. But anyway, there is a lift function that can be used if necessary. Non-determinism is one interesting effect that does not need lift. The generic MonadPlus (ContT t) instance buys you a lot, if you are interested in non-determinism and search. Inspired by all your replies I have applied ContT to a type for difference lists which resulted in the well known two-continuation model for depth first search -- refactoring it modularly into two different parts that are useful on their own. Replacing one of those parts lead to a CPS implementation of breadth-first search that I have not been aware of previously. Please tell me if you have seen this implementation before. I have written about it: http://www-ps.informatik.uni-kiel.de/~sebf/haskell/stealing-bind.html Ryan: > The CPS transfrom in ContT also has the nice property that it makes > most applications of >>= in the underlying monad be > right-associative. Do you have a specific reason to say *most* (rather than *all*) here? Yes, because runContT ( (lift (a >>= f)) >>= g ) still has a left-associative >>=. [...] I know this was a pretty in-depth example, so I hope I've made it clear :) Yes, thanks! Cheers, Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best text editor
Michael Mossey wrote: I'm a beginner, but I'll chime in and say I use Emacs with haskell-mode. It's auto-indentation is a bit complex in behavior which is unappealing (I feel like I never know what it's going to do when I hit tab), but I would be curious what someone with more experience feels about that. Yes. Don't use it. Use this: http://kuribas.hcoop.net/haskell-indentation.el (The message from Stefan appears to suggest this will be bundled with the next haskell-mode release - that's excellent news). It is much more predictable - TAB always moves right to the next valid position, BACKSPACE always moves left. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How the following works
Hello, I can hardly imagine how the following code works: cinits :: [a] -> [[a]] cinits [] = [[]] cinits (x:xs) = [] : map (x:) (cinits xs) can someone give me a good explaination? (I understand it a bit, but it's really hard for me to figure out how a map in a map function works.) Thank you for your time, Tsunkiet ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How the following works
Why don't you hand execute it on an example, like cinits [1,2,3]? cinits [1,2,3] = cinits (1:2:3:[]) = [] : map (1:) (cinits (2:3:[]) = [] : map (1:) ([] : map (2:) (cinits (3:[])) = ... On Tue, Apr 14, 2009 at 10:39 AM, Tsunkiet Man wrote: > Hello, > > I can hardly imagine how the following code works: > > cinits :: [a] -> [[a]] > cinits [] = [[]] > cinits (x:xs) = [] : map (x:) (cinits xs) > > can someone give me a good explaination? > > (I understand it a bit, but it's really hard for me to figure out how a map > in a map function works.) > > Thank you for your time, > > Tsunkiet > ___ > 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] How the following works
Let's see... cinits [] = [[]] cinits (hd:tl) = [] : [ hd : rest | rest <- cinits tl ] Well, ehm, I'm trying to understand "map" in "map" functions, however I do understand list comprehensions. But I don't think I can write "any" "map" in "map" function into a list comprehension can I? 2009/4/14 Daniel Fischer > Am Dienstag 14 April 2009 10:39:28 schrieb Tsunkiet Man: > > Hello, > > > > I can hardly imagine how the following code works: > > > > cinits :: [a] -> [[a]] > > cinits [] = [[]] > > cinits (x:xs) = [] : map (x:) (cinits xs) > > > > can someone give me a good explaination? > > Perhaps it's easier to follow as a list comprehension: > > cinits [] = [[]] > cinits (hd:tl) = [] : [ hd : rest | rest <- cinits tl ] > > > > > (I understand it a bit, but it's really hard for me to figure out how a > map > > in a map function works.) > > > > Thank you for your time, > > > > Tsunkiet > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Maybe off-topic -- Writing contracts or software specifications
"Richard O'Keefe" wrote: > If you have a low level of trust, you'll need a great level of > detail, and it still won't help. > Heh. Keep your friends close, your enemies closer. Freelancing, I was always paid per hour, not per feature. From my experience, writing something like "The contractor will work closely with an employee designated by Foo to ensure formal and informal, known or yet to be discovered, specifications are implemented" is the best thing you can do. If you have it, mention your QA and its guidelines. If you don't have it, get both. [1] It's more than enough to boot a bad teamplayer out of his contract, doesn't induce frowns in top coders (SNAFU, as those are the ones you want to hire), does not risk mis-specifying requirements (which, with legal backing, is also SNAFU) and doesn't take longer and/or cost more to work out than the program itself (SNAFU, again). Be sure that not only bugs are fixed, but the reasons they appeared in the first place, too: That's the secret people writing space shuttle control software and similar use. [1] Even if it's just one guy working out things like "Every function must be documented" and me getting a bug report saying "Help text does not mention how to display help text". -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How the following works
Assuming you already think you know what cinits does, you can convince yourself using induction. On Tue, Apr 14, 2009 at 11:16 AM, Tsunkiet Man wrote: > Let's see, if I execute it by hand: > > cinits :: [a] -> [[a]] > cinits [] = [[]] > cinits (x:xs) = [] : map (x:) (cinits xs) > > cinits [1,2,3] = [] : map (1:) ( [] : map (2:) ( [] : map (3:) ( [[]]) ) ) > = [] : map (1:) ( [] : map (2:) ( [] : map (3:) [[]] ) ) > = [] : map (1:) ( [] : map (2:) ( [] : [[3]] ) > = [] : map (1:) ( [] : map (2:) ( [[], [3]] ) > = [] : map (1:) ( [] : [[2], [2,3]]) > = [] : map (1:) ( [[], [2], [2,3]]) > = [[],[1], [1,2], [1,2,3]] > > Well, I understand this part. But isn't there an easier way to "see" the > answer? > > Thank you for your help! > ___ > 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] How the following works
map f xs = [ f x | x <- xs ] On Tue, Apr 14, 2009 at 11:21 AM, Tsunkiet Man wrote: > Let's see... > > cinits [] = [[]] > cinits (hd:tl) = [] : [ hd : rest | rest <- cinits tl ] > > Well, ehm, I'm trying to understand "map" in "map" functions, however I do > understand list comprehensions. But I don't think I can write "any" "map" in > "map" function into a list comprehension can I? > > 2009/4/14 Daniel Fischer >> >> Am Dienstag 14 April 2009 10:39:28 schrieb Tsunkiet Man: >> > Hello, >> > >> > I can hardly imagine how the following code works: >> > >> > cinits :: [a] -> [[a]] >> > cinits [] = [[]] >> > cinits (x:xs) = [] : map (x:) (cinits xs) >> > >> > can someone give me a good explaination? >> >> Perhaps it's easier to follow as a list comprehension: >> >> cinits [] = [[]] >> cinits (hd:tl) = [] : [ hd : rest | rest <- cinits tl ] >> >> > >> > (I understand it a bit, but it's really hard for me to figure out how a >> > map >> > in a map function works.) >> > >> > Thank you for your time, >> > >> > Tsunkiet >> > > > ___ > 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] ANN: Elerea, another FRP library
> And just as IO is unnecessary for behavior (functions of time), it's also > unnecessary for imagery (functions of space). Continuing with the > functional (non-IO) theme, you can give a semantically precise, > composable and simple type of images. Yes, that's a further separation of concerns. Instead of producing an IO action, you produce a data structure to be consumed by the framework. However, there's an interesting question of dealing with feedbacks, i.e. signals affected (or even created and destroyed) by the IO actions resulting from your output. It might sound like too low-level design if you have to rely on IO-bound feedback, but I don't see how it could be put behind a nice abstraction in general. For instance, if you have some large terrain to roam around, you'll have to keep most of it on the disk (static as well as dynamic objects), and it depends on your location and orientation which parts get loaded and discarded/archived at any time. While low-level caching and loading of resources is certainly not the responsibility of the reactive subsystem, it will still have to manage the life cycle of signals. And that's what I'm missing: a nice way to describe this kind of feedback. Grapefruit looks like a possible solution to this problem (assuming it can be made completely dynamic), and then the integration of a Grapefruit-like and a Reactive-like system could be the ultimate solution in the long run. Gergely -- http://www.fastmail.fm - IMAP accessible web-mail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Best text editor
FFT wrote: > Has anyone tried Yi? > Yes, and I figured I'd have to edit the keymap to get productive. While it features a fully functional subset of vim that's more than enough to efficiently edit files, it's not the subset I use... and then I was too lazy to actually do it. Documentation is badly lacking, too, it's like trying to configure xmonad without xmonad-contrib and all the docs. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Best text editor
Hello Alexandr, Tuesday, April 14, 2009, 6:37:38 AM, you wrote: >> Hi I would like to follow the crowd and find out what text editor everyone >> uses for haskell on windows. > * HippoEdit (http://www.hippoedit.com/) i've tried HippoEdit and don't recommend it. it's work in progress so i immediately hit several bugs -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
> Interesting. I'm testing it on Window though. You're using Linux? Maybe > the scheduling is different. Now I tried it on Windows in VirtualBox, and it still looks quite smooth to me (except that hardware acceleration doesn't seem to work properly through virtualisation, but it's okay as long as I keep the window small enough). However, unlike the Linux version, it does max out the CPU, so the trick with threadDelay 0 doesn't work. Apparently, I'll have to find a real Windows box somewhere, because I couldn't reproduce the jerkiness you're talking about. Gergely -- http://www.fastmail.fm - The way an email service should be ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Best text editor
Melanie_Green wrote: > > Hi I would like to follow the crowd and find out what text editor > everyone uses for haskell on windows. > Have you considered using leksah? While it doesn't focus on being an editor, it's still a darn fine way to edit Haskell. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How the following works
Let's see, if I execute it by hand: cinits :: [a] -> [[a]] cinits [] = [[]] cinits (x:xs) = [] : map (x:) (cinits xs) cinits [1,2,3] = [] : map (1:) ( [] : map (2:) ( [] : map (3:) ( [[]]) ) ) = [] : map (1:) ( [] : map (2:) ( [] : map (3:) [[]] ) ) = [] : map (1:) ( [] : map (2:) ( [] : [[3]] ) = [] : map (1:) ( [] : map (2:) ( [[], [3]] ) = [] : map (1:) ( [] : [[2], [2,3]]) = [] : map (1:) ( [[], [2], [2,3]]) = [[],[1], [1,2], [1,2,3]] Well, I understand this part. But isn't there an easier way to "see" the answer? Thank you for your help! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Non-atomic "atoms" for type-level programming
The recent GHC trac ticket revision reminded me of the old open type-sharing problem with type tags and record labels: - if type-level tags (such as 'data TTrue'/'data TFalse') are declared repeatedly in separate modules, they represent separate types, preventing shared use (your type-level predicate doesn't return my version of 'TTrue'/'TFalse') - if record field labels (as used in your run-of-the-mill extensible record library) have to be declared, that is not only inconvenient, but prevents sharing of field labels over independent code bases (see the old Haskell' ticket #92 for discussion http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels ; also http://hackage.haskell.org/trac/ghc/ticket/1872 for alternative extensible records libs) Since Haskell has no concept of type sharing, the only way to express this is to declare types in a common import. But there is no way for that common import to predict all possible future uses, and we can't just keep adding more labels/tags to it, forcing all dependencies to be updated and kept in sync. Using Template Haskell, and QuasiQuotes in particular, we can now at least work around this issue, by splitting the atoms:-) - 'undefined :: Tag' becomes 'undefined :: (TT :. Ta :. Tg)' - 'label :: Label' becomes '(Ll :< La :< Lb :< Le :< Ll) :: (Ll :< La :< Lb :< Le :< Ll)' - a common import, Data.Label, provides type letters and combinators: 'data La = La' and 'data a :< b = a :< b' 'data Ta' and 'data a :. b' .. - quasiquoting and Show instances, also provided by Data.Label, try to hide the internal structure of labels and tags, at least at expression level. Since there is no quasiquoting at type-level (why?), generating type synonyms seems the best we can do there.. - since record field labels are constructed from type letters, this would also provide a basis for - type-level numbers (type-level quasiquoting would help, though) - label ordering: http://hackage.haskell.org/trac/ghc/ticket/2104 http://hackage.haskell.org/trac/ghc/ticket/1894 In actual use, this is what tags and labels from Data.Label look like: - -- the usual extensible-records-as-nested-pairs data label := value = label := value deriving Show data field :& record = field :& record deriving Show infixr :& -- no quasiquoting for types:-(, so generate type synonyms instead $(genTypeTag "TTrue") $(genTypeTag "TFalse") -- a type-level predicate, using shared tags TTrue/TFalse class HasField record label tbool | label record -> tbool instance HasField () label TFalse instance HasField ((label:=value):&record) label TTrue instance HasField record label tbool => HasField (field:&record) label tbool -- record field selection, driven by field label types class Select record label value where (!) :: record -> label -> value instance .. -- some example records -- no need to declare field labels, and they will be -- shared with other importers of Data.Label! a = ([$l|this|] := True) :&([$l|that|] := "hi") :&() b = ([$l|that|] := "there") :&([$l|x|] := 100) :&([$l|y|] := 200) :&() -- we don't even need label values for this, -- type tags are sufficient, as long as we don't -- evaluate the (undefined) values of tags c = ([$t|this|] := 'x') :&([$t|y|] := ()) :&() -- testing Show and record selection records = do print a print b print c print $ (a ! [$l|this|]) print $ (c ! [$t|this|]) print $ (a ! [$l|that|]) ++ ", " ++ (b ! [$l|that|]) - *Main> [$l|label|] label *Main> :t [$l|label|] [$l|label|] :: Ll :< (La :< (Lb :< (Le :< Ll))) *Main> [$l|label|] `seq` () () *Main> [$t|label|] label *Main> :t [$t|label|] [$t|label|] :: Tl :. (Ta :. (Tb :. (Te :. Tl))) *Main> [$t|label|] `seq` () *** Exception: Prelude.undefined *Main> :t [$l|100|] [$l|100|] :: L1 :< (L0 :< L0) *Main> records (this := True) :& ((that := "hi") :& ()) (that := "there") :& ((x := 100) :& ((y := 200) :& ())) (this := 'x') :& ((y := ()) :& ()) True 'x' "hi, there" - For example code, see http://community.haskell.org/~claus/misc/Data/Label.hs http://community.haskell.org/~claus/misc/Data/Label/TH.hs http://community.haskell.org/~claus/misc/labels.hs Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Types and hashes of hashes, trouble for a Java-programmer...
Thanks, I was close, but the I was trying to use (something like) this statement without the return: maybe (return Nothing) (flip HashTable.lookup 1000) More or less like this: maybe (Nothing) (flip HashTable.lookup 1000) Which did't work... Guess the return is needed because we use a new monad (Maybe) inside another monad (IO). Petter On Mon, Apr 13, 2009 at 7:45 PM, Lennart Augustsson wrote: > res <- HashTable.lookup h 3 >>= maybe (return Nothing) (flip > HashTable.lookup 1000) > > On Mon, Apr 13, 2009 at 6:59 PM, John Smith wrote: >> Yes, agreed. Got any clue on the original problem (except to use Data.Map)? >> >> On Mon, Apr 13, 2009 at 6:55 PM, Jason Dagit wrote: >>> >>> Others have provided help to answer your question but I'd like to >>> provide a little bit different feedback. >>> >>> On Mon, Apr 13, 2009 at 8:42 AM, John Smith wrote: >>> > Hi, a java-programmer running into trouble while trying to learn >>> > Haskell. >>> > >>> > I try to make a hash containing hashes but can not getting a value out >>> > of >>> > the innermost hash - I keep running into type-trouble where IO and Maybe >>> > monad is getting mixed? >>> > >>> > My attempt: >>> > >>> > removeMaybeHash x = >>> > case x of >>> > Just ref -> ref >>> > Nothing -> HashTable.new (==) (\key -> key) >>> >>> When you see yourself writing a function like this, you could write it >>> like this instead: >>> removeMaybeHash (Just ref) = ref >>> removeMaybeHash Nothing = HashTable.new (==) (\key -> key) >>> >>> Hopefully you agree this 2 line version is more clear. You could go >>> further of course and use the function 'maybe' from the prelude, and >>> pass the function 'id' instead of \key -> key, but I don't want to >>> overwhelm you. >>> >>> Good luck, >>> Jason >> >> >> ___ >> 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] How the following works
Am Dienstag 14 April 2009 10:39:28 schrieb Tsunkiet Man: > Hello, > > I can hardly imagine how the following code works: > > cinits :: [a] -> [[a]] > cinits [] = [[]] > cinits (x:xs) = [] : map (x:) (cinits xs) > > can someone give me a good explaination? Perhaps it's easier to follow as a list comprehension: cinits [] = [[]] cinits (hd:tl) = [] : [ hd : rest | rest <- cinits tl ] > > (I understand it a bit, but it's really hard for me to figure out how a map > in a map function works.) > > Thank you for your time, > > Tsunkiet ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Looking for the fastest Haskell primes algorithm
Today I happened to need a large list of prime numbers. Obviously this is a well-known problem, so I figured there would be something on Hackage that I could use. Surprisingly, there isn't, or if there is it's not easy to find. Searching for prime or primes on Hackage reveals nothing. Searching for primes on Hayoo gives Codec.Encryption.RSA.NumberTheory, but that uses the inefficient one-liner implementation. The HaskellWiki article on primes (http://www.haskell.org/haskellwiki/Prime_numbers) has a number of implementations, but the faster they get, the longer and uglier they become. Since it's such a common problem I'd say it would be a good idea to add a package to Hackage that exports primes :: [Integer] and hides the ugly implementation details. Data.Numbers.Primes seems a logical choice for the namespace, but I'm open to suggestions. The trick then is to find the most efficient implementation of primes. The Haskell wiki article mentions ONeillPrimes.hs as one of the fastest ones, but maybe there's a faster version. So my question is: does anybody know what the fastest Haskell algorithm for generating primes is? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm
Some other ideas for things to put in this package possibly: is_prime :: Int -> Bool nth_prime :: Int -> Int -- or Int -> Integer prime_factors :: Int -> [Int] I'm assuming there are faster ways of doing the first 2 than by just simply looking through all of primes. Someone should also look through Euler - I'm sure that will generate other ideas of things that could be useful in playing with primes. On Tue, Apr 14, 2009 at 8:40 AM, Niemeijer, R.A. wrote: > Today I happened to need a large list of prime numbers. Obviously this is > a well-known problem, so I figured there would be something on Hackage that > I could use. Surprisingly, there isn’t, or if there is it’s not easy to > find. Searching for prime or primes on Hackage reveals nothing. Searching > for primes on Hayoo gives Codec.Encryption.RSA.NumberTheory, but that uses > the inefficient one-liner implementation. The HaskellWiki article on primes > (http://www.haskell.org/haskellwiki/Prime_numbers) has a number of > implementations, but the faster they get, the longer and uglier they become. > > > > Since it’s such a common problem I’d say it would be a good idea to add a > package to Hackage that exports > > primes :: [Integer] > > and hides the ugly implementation details. Data.Numbers.Primes seems a > logical choice for the namespace, but I’m open to suggestions. > > > > The trick then is to find the most efficient implementation of primes. The > Haskell wiki article mentions ONeillPrimes.hs as one of the fastest ones, > but maybe there’s a faster version. So my question is: does anybody know > what the fastest Haskell algorithm for generating primes is? > > ___ > 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] Looking for the fastest Haskell primes algorithm
I'd suggest also primesFrom :: Integer -> [Integer] and probably a separate function nextPrime :: Integer -> Integer 2009/4/14 Andrew Wagner : > Some other ideas for things to put in this package possibly: > is_prime :: Int -> Bool > nth_prime :: Int -> Int -- or Int -> Integer > prime_factors :: Int -> [Int] > > I'm assuming there are faster ways of doing the first 2 than by just simply > looking through all of primes. Someone should also look through Euler - I'm > sure that will generate other ideas of things that could be useful in > playing with primes. > On Tue, Apr 14, 2009 at 8:40 AM, Niemeijer, R.A. > wrote: >> >> Today I happened to need a large list of prime numbers. Obviously this is >> a well-known problem, so I figured there would be something on Hackage that >> I could use. Surprisingly, there isn’t, or if there is it’s not easy to >> find. Searching for prime or primes on Hackage reveals nothing. Searching >> for primes on Hayoo gives Codec.Encryption.RSA.NumberTheory, but that uses >> the inefficient one-liner implementation. The HaskellWiki article on primes >> (http://www.haskell.org/haskellwiki/Prime_numbers) has a number of >> implementations, but the faster they get, the longer and uglier they become. >> >> >> >> Since it’s such a common problem I’d say it would be a good idea to add a >> package to Hackage that exports >> >> primes :: [Integer] >> >> and hides the ugly implementation details. Data.Numbers.Primes seems a >> logical choice for the namespace, but I’m open to suggestions. >> >> >> >> The trick then is to find the most efficient implementation of primes. The >> Haskell wiki article mentions ONeillPrimes.hs as one of the fastest ones, >> but maybe there’s a faster version. So my question is: does anybody know >> what the fastest Haskell algorithm for generating primes is? >> >> ___ >> 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 > > -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best text editor
> and Visual Haskell had some unique features (such as hovering tooltips > showing types) that are now found in the F# editor, and should now be easier > to implement with the recent GHC API (I guess). haskell-mode for Emacs does show the type signature of standard functions in the mini-buffer when the cursor is over them. JP ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Monad.Reader (14) - Call for copy
Call for Copy The Monad.Reader - Issue 14 Please consider writing something for the next issue of The Monad.Reader. The deadline for Issue 14 is: ** May 15, 2009 ** The Monad.Reader is a electronic magazine about all things Haskell. Check out the website and browse the previous editions to learn more: http://www.haskell.org/haskellwiki/The_Monad.Reader * Submission Details * Get in touch if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (wouter at chalmers.se). Articles should be written according to the guidelines available from: http://www.haskell.org/haskellwiki/The_Monad.Reader Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. Looking forward to your submission, Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm
Niemeijer, R.A. wrote: Since it’s such a common problem I’d say it would be a good idea to add a package to Hackage that exports primes :: [Integer] and hides the ugly implementation details. Data.Numbers.Primes seems a logical choice for the namespace, but I’m open to suggestions. Excellent idea. Picking the most efficient implementation from the start isn't really necessary; if you find a faster implementation later you can just upload a new version. The API is unlikely to change in such a case anyway. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm
You might want to start with the Sieve of Atkin: http://en.wikipedia.org/wiki/Sieve_of_Atkin -Edward On Tue, Apr 14, 2009 at 8:40 AM, Niemeijer, R.A. wrote: > Today I happened to need a large list of prime numbers. Obviously this is > a well-known problem, so I figured there would be something on Hackage that > I could use. Surprisingly, there isn’t, or if there is it’s not easy to > find. Searching for prime or primes on Hackage reveals nothing. Searching > for primes on Hayoo gives Codec.Encryption.RSA.NumberTheory, but that uses > the inefficient one-liner implementation. The HaskellWiki article on primes > (http://www.haskell.org/haskellwiki/Prime_numbers) has a number of > implementations, but the faster they get, the longer and uglier they become. > > > > Since it’s such a common problem I’d say it would be a good idea to add a > package to Hackage that exports > > primes :: [Integer] > > and hides the ugly implementation details. Data.Numbers.Primes seems a > logical choice for the namespace, but I’m open to suggestions. > > > > The trick then is to find the most efficient implementation of primes. The > Haskell wiki article mentions ONeillPrimes.hs as one of the fastest ones, > but maybe there’s a faster version. So my question is: does anybody know > what the fastest Haskell algorithm for generating primes is? > > ___ > 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] ANN: hmatrix-static: statically-sized linear algebra
Hi Reiner, Fantastic work! User-friendly static dimension checking is an essential feature for any decent linear algebra library. Your interface using quasiquotation and view patterns is very elegant and practical. I am happy that hmatrix is useful, but I'm afraid that its primitive dynamic interface will no longer be used :) Many thanks for your excellent work! Alberto Reiner Pope wrote: There should be essentially no performance penalty in going from hmatrix to hmatrix-static, for most functions. The Vector and Matrix types I define are just newtypes of hmatrix's Vector and Matrix types, so they will have the same runtime representation. There are a few cases where performance could potentially differ, described below. Reflecting and reifying Ints (i.e. converting between types and values): (The ideas for this come from the Implicit Configurations paper[1].) Some Int arguments in hmatrix have been written as types in hmatrix-static, such as the function "constant". hmatrix type: constant :: Element a => a -> Int -> Vector a hmatrix-static type: constant :: (Element a, PositiveT n) => a -> Vector n a The PositiveT constraint is essentially a way of passing the Int parameter as an implicit parameter. To demonstrate this, we use two library functions which allow us to convert from Ints to types with PositiveT constraints, and back: value :: PositiveT n => Proxy n -> Int-- type -> value reifyPositive :: Int -> (forall n. PositiveT n => n -> r) -> r -- value -> type. The use of these functions is nice in some cases, such as "constant" above, because it allows us to pass parameters implicitly. On the other hand, the conversion between types and values imposes an O(log n) cost, where n is the size of the number we are converting. In my experience, this cost has not been significant (although it was previously, when I used a naive O(n) reifyIntegral implementation!). Newtype conversion costs: Occasionally, unwrapping newtypes can actually have a runtime cost. For instance, the hmatrix-static function joinU :: Storable t => [Vector Unknown t] -> Vector Unknown t needs to do a conversion :: [Vector Unknown t] -> [HMatrix.Vector t]. Now, the conversion "unwrap :: Vector Unknown t -> HMatrix.Vector t" is a noop, as it unwraps a newtype. However, to get the list conversion, we need to do "map unwrap", which requires mapping a noop over a list. However, because of map's recursion, GHC may not be able to recognise that "map unwrap" is a noop, and traverse the list anyway, causing a performance loss. However, there aren't many recursive data structures used in hmatrix-static, so this problem mostly doesn't exist. Cheers, Reiner [1] http://okmij.org/ftp/Haskell/types.html#Prepose On Sun, Apr 12, 2009 at 12:18 PM, Xiao-Yong Jin wrote: Reiner Pope writes: Hi everyone, I am pleased to announce hmatrix-static[1], a thin wrapper over Alberto Ruiz's excellent hmatrix library[2] for linear algebra. The main additions of hmatrix-static over hmatrix are: - vectors and matrices have their length encoded in their types - vectors and matrices may be constructed and destructed using view patterns, affording a clean, safe syntax. hmatrix-static includes statically-sized versions of hmatrix's linear algebra routines, including: - simple arithmetic (addition, multiplication, of matrices and vectors) - matrix inversion and least squares solutions - determinants / rank / condition number - computing eigensystems - factorisations: svd, qr, cholesky, hessenberg, schur, lu - exponents and sqrts of matrices - norms See http://code.haskell.org/hmatrix-static/examples/ for example code. This is quite interesting. I would like to know the performance penalty of such a wrapper. I'll test it by myself when I've got time. But can you give me some idea of how such a wrapper can be optimized by ghc in terms of space and time performance? -- c/*__o/* <\ * (__ */\ < ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Printing list of enum type
What do I need to add to this Color enum type to print a list of them? Michael === data Color = Red | Blue | Green | Yellow | Orange | Brown | White | Black instance Show Color where show Red = "Red" show Blue = "Blue" show Green = "Green" show Yellow = "Yellow" show Orange = "Orange" show Brown = "Brown" show White = "White" show Black = "Black" == Ok, modules loaded: Main. *Main> Red Red *Main> Black Black *Main> [Red Black White] :1:1: Couldn't match expected type `Color -> Color -> t' against inferred type `Color' In the expression: Red Black White In the expression: [Red Black White] In the definition of `it': it = [Red Black White] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing list of enum type
1. data Color = Red | Green | Blue deriving (Show) 2. [Red,Black,White] 2009/4/14 michael rice : > What do I need to add to this Color enum type to print a list of them? > > Michael > > === > > data Color > = Red > | Blue > | Green > | Yellow > | Orange > | Brown > | White > | Black > > instance Show Color where > show Red = "Red" > show Blue = "Blue" > show Green = "Green" > show Yellow = "Yellow" > show Orange = "Orange" > show Brown = "Brown" > show White = "White" > show Black = "Black" > > == > > Ok, modules loaded: Main. > *Main> Red > Red > *Main> Black > Black > *Main> [Red Black White] > > :1:1: > Couldn't match expected type `Color -> Color -> t' > against inferred type `Color' > In the expression: Red Black White > In the expression: [Red Black White] > In the definition of `it': it = [Red Black White] > > > > > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing list of enum type
You don't need to add anything, you just need to use list notation correctly. Try typing [Red, Black, White] in at the prompt instead. The commas are part of the list syntax. On Tue, Apr 14, 2009 at 9:15 AM, michael rice wrote: > What do I need to add to this Color enum type to print a list of them? > > Michael > > === > > data Color > = Red > | Blue > | Green > | Yellow > | Orange > | Brown > | White > | Black > > instance Show Color where > show Red = "Red" > show Blue = "Blue" > show Green = "Green" > show Yellow = "Yellow" > show Orange = "Orange" > show Brown = "Brown" > show White = "White" > show Black = "Black" > > == > > Ok, modules loaded: Main. > *Main> Red > Red > *Main> Black > Black > *Main> [Red Black White] > > :1:1: > Couldn't match expected type `Color -> Color -> t' >against inferred type `Color' > In the expression: Red Black White > In the expression: [Red Black White] > In the definition of `it': it = [Red Black White] > > > > > > > > ___ > 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] Printing list of enum type
Dumb, dumb, dumb, dumb, DUMB!, he Lisped. Thanks. Michael --- On Tue, 4/14/09, Andrew Wagner wrote: From: Andrew Wagner Subject: Re: [Haskell-cafe] Printing list of enum type To: "michael rice" Cc: haskell-cafe@haskell.org Date: Tuesday, April 14, 2009, 9:19 AM You don't need to add anything, you just need to use list notation correctly. Try typing [Red, Black, White] in at the prompt instead. The commas are part of the list syntax. On Tue, Apr 14, 2009 at 9:15 AM, michael rice wrote: What do I need to add to this Color enum type to print a list of them? Michael === data Color = Red | Blue | Green | Yellow | Orange | Brown | White | Black instance Show Color where show Red = "Red" show Blue = "Blue" show Green = "Green" show Yellow = "Yellow" show Orange = "Orange" show Brown = "Brown" show White = "White" show Black = "Black" == Ok, modules loaded: Main. *Main> Red Red *Main> Black Black *Main> [Red Black White] :1:1: Couldn't match expected type `Color -> Color -> t' against inferred type `Color' In the expression: Red Black White In the expression: [Red Black White] In the definition of `it': it = [Red Black White] ___ 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] ANN: Elerea, another FRP library
Am Freitag, 10. April 2009 18:41 schrieb Patai Gergely: > is based on some unsafePerformIO dark magic (that might easily break > depending on many factors) I wonder if this breaks referential transparency. Say, you define a signal s and use s twice in some expression. s may be evaluated once and it maybe evaluated twice. Does this make a difference? In the Haddock docs, you say that repeated evaluation of the same value is prevented by caching. However, caching probably only works if the signal in question is only evaluated once. If it’s evaluated twice, the second “instance” probably cannot reuse cached values of the first “instance”. Is it possible that thereby the second “instance” has different values than the first one? A well known FRP problem is that the values of a signal with internal state (an accumulating signal) depend on the time when the signal is started, i.e., when accumulation starts. When are your signals started? At evaluation time? If yes, doesn’t this mean that the meaning of a signal depends on evaluation time so that evaluating the same signal expression twice actually results in two different signals? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
Am Dienstag, 14. April 2009 11:33 schrieb Patai Gergely: > and then the integration of a Grapefruit-like and a Reactive-like system > could be the ultimate solution in the long run. What do you think, Grapefruit is lacking, compared to Reactive? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
Dear Sirs, I guess this is a very simple question. How can I convert IO [XmlTree] to just a list of XmlTree? Regards, Rodrigo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 8:54 AM, rodrigo.bonifacio < rodrigo.bonifa...@uol.com.br> wrote: > Dear Sirs, > > I guess this is a very simple question. How can I convert IO [XmlTree] to > just a list of XmlTree? > This is very important: you cannot. But you can still get your hands on one inside a do block. As in, if you have tree :: IO [XmlTree], then you can say, eg. printTree = do t <- tree print t Inside this block, t is an [XmlTree], and it is passed to print. Intutively, when you see x <- y inside a do block, if y :: IO a, for some type a, then x :: a. But there is no function that will get you from IO [XmlTree] -> [XmlTree], you have to use binding like this. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
Hallo, On 4/14/09, rodrigo.bonifacio wrote: > > > Dear Sirs, > > I guess this is a very simple question. How can I convert IO [XmlTree] to > just a list of XmlTree? > The short answer is: You cannot. The longer answer is: Only put things in the IO monad when you need to interact with the "outside", i. e., reading, displaying etc. Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 4:54 PM, rodrigo.bonifacio wrote: > Dear Sirs, > > I guess this is a very simple question. How can I convert IO [XmlTree] to > just a list of XmlTree? Quick and dirty answer: unsafePerformIO. That's an easy finding on Hoogle: http://www.haskell.org/hoogle/?hoogle=IO+a+-%3E+a Anyhow, as the name suggest, the function is "unsafe", so you better know what you're doing. Bye, Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 5:01 PM, Luke Palmer wrote: > ... > This is very important: you cannot. I'd answer "You shouldn't, unless you know what you are doing". In some cases, not only is unsafePerformIO desirable but also necessary (I'm thinking of Debug.Trace). Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
Am Samstag, 11. April 2009 16:57 schrieb Patai Gergely: > > Any idea how Elerea compares to Grapefruit? It's great to see a lot of > > competition in the FRP arena, but I hope in the end this results in a > > really usable and scalable FRP system for Haskell :-) > > I think Wolfgang can judge this better, because I don't really know the > innards of Grapefruit, I didn’t have a deep look at Elerea so far but looked at the Haddock docs. If I understand correctly, Elerea’s signals construct mutable variables for caching their current values when they are evaluated. This happens using unsafePerformIO. Grapefruit’s DSignals and SSignals use a purely functional data structure to represent several possible future values of whom only the ones which are actually occuring are evaluated. This data structure is created using unsafeInterleaveIO. So Elerea seems to have to take special care to not break referential transparency. Grapefruit has to take care only with CSignals since only these are using unsafePerformIO internally. Since Grapefruit uses ordinary expression evaluation for evaluating signal values, it can probably make use of certain compiler optimizations. Elerea’s evaluation seems to be driven by hand-coded IO actions so that use of such compiler optimizations is certainly not possible. Both Grapefruit and Elerea probably need a way to fix a signal to a specific starting time. Grapefruit does this using era type parameters. Elerea doesn’t seem to do anything about this at the moment. Patai, could you please correct me where I’m wrong and clarify the points which are still unclear to me? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 9:01 AM, Cristiano Paris wrote: > On Tue, Apr 14, 2009 at 4:54 PM, rodrigo.bonifacio > wrote: > > Dear Sirs, > > > > I guess this is a very simple question. How can I convert IO [XmlTree] to > > just a list of XmlTree? > > Quick and dirty answer: unsafePerformIO. Please don't say that. He's a beginner. You realize that the path of least resistance will be to use it, right? You see why that's not a good thing? Even experts don't use this function. (To the O.P.: don't use it) Luke > > > That's an easy finding on Hoogle: > > http://www.haskell.org/hoogle/?hoogle=IO+a+-%3E+a > > Anyhow, as the name suggest, the function is "unsafe", so you better > know what you're doing. > > Bye, > > Cristiano > ___ > 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] Converting IO [XmlTree] to [XmlTree]
Here's another way of looking at what others have already said. The only way you can do that is within the scope of another IO action. For example: outputXmlTrees :: IO () outputXmlTrees = do trees <- inputXmlTrees; let newTrees = transform trees; print . show $ newTrees Notice a few things: - First, the line "trees <- inputXmlTrees" effectively takes an IO [XmlTree] and turns it into a [XmlTrees]. That is, it runs the IO action inputXmlTrees, and gives you the resulting list of XmlTrees to work with. - You can then pass these off to a pure function which will monkey around with them in a pure (non-IO) context - You must do this in an IO action, however, and any monadic action gets its type from the last line. Thus, the last line must be of type IO something. In this case, it is simply the action that would print out the trees. - Thus, this gives you a way to glue together different IO actions and pure actions and combine them into larger IO actions Hope this clarifies On Tue, Apr 14, 2009 at 10:54 AM, rodrigo.bonifacio < rodrigo.bonifa...@uol.com.br> wrote: > Dear Sirs, > > I guess this is a very simple question. How can I convert IO [XmlTree] to > just a list of XmlTree? > > Regards, > > Rodrigo. > > > > ___ > 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] Converting IO [XmlTree] to [XmlTree]
> Quick and dirty answer: unsafePerformIO. You can do a lot of cool things with a table saw if you take the blade guard off. On Tue, Apr 14, 2009 at 11:01 AM, Cristiano Paris wrote: > On Tue, Apr 14, 2009 at 4:54 PM, rodrigo.bonifacio > wrote: > > Dear Sirs, > > > > I guess this is a very simple question. How can I convert IO [XmlTree] to > > just a list of XmlTree? > > Quick and dirty answer: unsafePerformIO. > > That's an easy finding on Hoogle: > > http://www.haskell.org/hoogle/?hoogle=IO+a+-%3E+a > > Anyhow, as the name suggest, the function is "unsafe", so you better > know what you're doing. > > Bye, > > Cristiano > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
Hello rodrigo.bonifacio, Tuesday, April 14, 2009, 6:54:07 PM, you wrote: > I guess this is a very simple question. How can I convert IO > [XmlTree] to just a list of XmlTree? IO [XmlTree] is an action returning [XmlTree]. so to "convert" it to [XmlTree] you just need to execute it in IO monad: value <- action i suggest you to read http://haskell.org/haskellwiki/IO_inside in order to manage IO monad -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 5:09 PM, Luke Palmer wrote: > ... > Please don't say that. He's a beginner. > You realize that the path of least resistance will be to use it, right? > You see why that's not a good thing? > Even experts don't use this function. > (To the O.P.: don't use it) Mmmh, sorry Luke but I don't understand this ostracism. unsafePerformIO is not "evil" by itself, it's there for a purpose and, as for anything else in the language, it's better to understand when to use it and when not rather than just knowing that is something that MUST not be used, without any further explanation. More, from my personal experience, knowing unsafePerformIO helped me understand better what Monads are and how they should be used. I wounder what so-called "experts" have to say about this. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
win64 ghc version Re[4]: [Haskell-cafe] GHC needs a 64 bit machine to be fast?
Hello Peter, Wednesday, April 8, 2009, 2:42:24 PM, you wrote: if you need win64 ghc version - add yourself to CC list of http://hackage.haskell.org/trac/ghc/ticket/1884 > Well, make that 2! :-) > On Wed, Apr 8, 2009 at 11:47 AM, Bulat Ziganshin > wrote: > Hello Peter, > > Wednesday, April 8, 2009, 12:58:25 PM, you wrote: > > No. it seems that i'm only user asking GHC team for 64-bit version > >> Regarding that, is it possible to generate 64-bit code using GHC on Windows? > >> On Wed, Apr 8, 2009 at 10:17 AM, FFT wrote: >> >> On Wed, Apr 8, 2009 at 1:14 AM, Karel Gardas >> wrote: >>> >>> Hello, >>> >>> perhaps you are hit by following issue? >>> http://hackage.haskell.org/trac/ghc/ticket/594 >> >> >> The benchmark isn't using the native code generator, it compiles via >> C, as I understand. >> >> What are other people's timings on 32 bit Linux machines? >> >> ___ >> Haskell-Cafe mailing list >> haskell-c...@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > >> > > > > -- > Best regards, > Bulat mailto:bulat.zigans...@gmail.com > > > -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 10:54 AM, rodrigo.bonifacio
wrote:
> Dear Sirs,
>
> I guess this is a very simple question. How can I convert IO [XmlTree] to
> just a list of XmlTree?
>
> Regards,
>
> Rodrigo.
One good link on this topic is http://haskell.org/haskellwiki/Avoiding_IO
Maybe there's no need for it be be IO [XmlTree], if you can write
functions that instead produce/consume just [XmlTree]. They can always
be turned later with liftM and whatnot into a IO [XmlTree] (but not
the reverse).
Doing as much as possible in pure code, and wrapping around it/calling
it from a few short IO functions is the Haskell Way. Sometimes it
looks hard to see, but XMonad is probably the best example here of how
it can both be done where it looks infeasible ('What's a window
manager but a bunch of IO?") and is rewarding (testability, etc. as
exemplified by http://cgi.cse.unsw.edu.au/~dons/blog/2007/05/17) The
best writeup on this seems to be
http://www.cse.unsw.edu.au/~dons/talks/xmonad-hw07.pdf
--
gwern
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 9:24 AM, Cristiano Paris wrote: > On Tue, Apr 14, 2009 at 5:09 PM, Luke Palmer wrote: > > ... > > Please don't say that. He's a beginner. > > You realize that the path of least resistance will be to use it, right? > > You see why that's not a good thing? > > Even experts don't use this function. > > (To the O.P.: don't use it) > > Mmmh, sorry Luke but I don't understand this ostracism. > > unsafePerformIO is not "evil" by itself, it's there for a purpose and, > as for anything else in the language, it's better to understand when > to use it and when not rather than just knowing that is something that > MUST not be used, without any further explanation. You have a point. I would like to avoid introducing unfounded authoritarian stigmas whenever possible. However, the way I see it is that unsafePerformIO *is* evil by itself, and it is only by the addition of Holy Water that it is benign to use. Ryan Ingram described it as a way to achieve "RTS extensions", which I think is a fine way to put it I consider Debug.Trace to be an instance of this: we are extending the RTS to provide execution traces. I guess it's a teaching style thing. Mostly, if someone sees "I have an IO [XmlTree] and I need an [XmlTree]", I want the "I'm asking the wrong question" synapse path to fire, rather than the "just use unsafePerformIO" one. Luke > > More, from my personal experience, knowing unsafePerformIO helped me > understand better what Monads are and how they should be used. > > I wounder what so-called "experts" have to say about this. > > Cristiano > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
Hello Cristiano, Tuesday, April 14, 2009, 7:24:40 PM, you wrote: > unsafePerformIO is not "evil" by itself, it's there for a purpose and, > as for anything else in the language, it's better to understand when > to use it we just think that author of original question don't yet have good knowledge of IO monad baiscs and it's what he actually want to know. if the question was how to perform IO action in pure code, unsafePerformIO may be a good answer -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 5:42 PM, Luke Palmer wrote: > > ... > However, the way I see it is that unsafePerformIO *is* evil by itself, and > it is only by the addition of Holy Water that it is benign to use. That's what I meant but your words are indeed more effective :) > Ryan Ingram described it as a way to achieve "RTS extensions", which I think > is a fine way to put it I consider Debug.Trace to be an instance of this: > we are extending the RTS to provide execution traces. > I guess it's a teaching style thing. Mostly, if someone sees "I have an IO > [XmlTree] and I need an [XmlTree]", I want the "I'm asking the wrong > question" synapse path to fire, rather than the "just use unsafePerformIO" > one. Yes, I think your analysis is correct. Perhaps I was a bit too dry in my original answer. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
Cristiano Paris wrote: On Tue, Apr 14, 2009 at 5:09 PM, Luke Palmer wrote: ... Please don't say that. He's a beginner. You realize that the path of least resistance will be to use it, right? You see why that's not a good thing? Even experts don't use this function. (To the O.P.: don't use it) Mmmh, sorry Luke but I don't understand this ostracism. unsafePerformIO is not "evil" by itself, it's there for a purpose and, as for anything else in the language, it's better to understand when to use it and when not rather than just knowing that is something that MUST not be used, without any further explanation. Sure, the explanation is there if people are interested in it. However, in context, your answer was wrong. It is like someone asking: "How do I get hold of a new phone" and the answer "Pull a gun on someone walking down the street and demand they give you their phone" ...that is, the answer was solving the wrong problem, or solving it in the wrong context. If you have IO [XmlTree], then you don't have an [XmlTree] at all - rather you have a description of an (IO-involving) action which you need to run to get one. You can run it many times, or once, or never. It will (in general) give different results depending exactly when you run it. Therefore you need to carefully decide when to run it - i.e. attach it indirectly or directly into your main action, as the various other answers have shown. unsafePerformIO is not part of the haskell language - it does not respect the type system. It is an extension mechanism which allows us to add hooks into the RTS; effectively a way to extend the language. This is a useful and powerful thing, but nothing in the questioner's question suggested that language extension was what they wanted. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
On Tue, Apr 14, 2009 at 5:54 PM, Jules Bean wrote: > ... I'm convinced about what you say and perhaps I answered the way I did just because I'm convinced that, for a newbie, knowing about the existence of unsafePerformIO can't cause any harm. I was a bit surprised by the strong reaction about my citation of unsafePerformIO. Maybe it'd useful, for the future, to write a document explaining how to help newbies properly, maybe putting it in the mailing list charter. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
rodrigo.bonifacio wrote: I guess this is a very simple question. How can I convert IO [XmlTree] to just a list of XmlTree? You can't, unless you use `unsafePeformIO`, as others have already pointed out. Yet others have, more "correctly," suggested that you use do notation to bind a variable with the type you expect. I want to go into a little more detail .I have a spontaneous Monad tutorial to throw out, I guess. How you can convert a value of type `IO [XmlTree]` is probably the wrong question. The right question is how you can convert a function of type `[XmlTree] -> A` into a function of type `IO [XmlTree] -> IO A`. The correct answer has many names: fmap, liftA, liftM, (<$>) :: Monad m => (a -> b) -> (m a -> m b) I will use `fmap` to mean any of the above names. In your case, applying fmap to a function foo: foo ::[XmlTree] ->A fmap foo :: IO [XmlTree] -> IO A So any time you need to pass an IO value to a pure function, this is one way to do it. Suppose that the function actually returns an IO value, though. Here, we will call the function `bar`: bar ::[XmlTree] -> IO A fmap bar :: IO [XmlTree] -> IO (IO A) Now we seem to be in a similar situation as before. We have an extra IO that we don't want. There is a function for this: join :: Monad m => m (m a) -> m a So, we can use `join` to transform an expression of type `IO (IO a)` to an expression of type `IO a`. Putting it all together: bar ::[XmlTree] -> IO A fmap bar:: IO [XmlTree] -> IO (IO A) join . fmap bar :: IO [XmlTree] -> IO A And we now have a sensible function again. Of course, this is a common pattern, using `join` and `fmap` together, so we have yet another function: (=<<) :: Monad m => (a -> m b) -> (m a -> m b) (Note that this has a different argument order than (>>=). I prefer this form since it emphasizes that it actually transforms a function.) So, now we have bar ::[XmlTree] -> IO A (bar =<<) :: IO [XmlTree] -> IO A Putting it all together, with a function that gives us the `IO [XmlTree]`: xmlTree :: IO [XmlTree] bar ::[XmlTree] -> IO A bar =<< XmlTree :: IO A And that last line is equivalent to this in do notation: do tree <- xmlTree bar tree If you have any questions, please do ask. I understand that it can appear quite dense to a beginner. I'm thinking about using this approach in a blog article, which would have more detail and examples, but I would like to be aware of potential stumbling blocks. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Converting IO [XmlTree] to [XmlTree]
"rodrigo.bonifacio" wrote: > Dear Sirs, > > I guess this is a very simple question. How can I convert IO > [XmlTree] to just a list of XmlTree? > unsafeCoerce. Seriously, you just don't, you weld stuff together using >>=. It takes an 'IO a' and a function 'a -> IO b' and returns you an 'IO b', thus preventing you from launching nuclear missiles while you're standing in front of the exhaust jets. You don't want to be able to. do-notation is a convenient short-hand: foo >>= (\bar -> return $ baz bar) do bar <- foo return $ baz bar >>= doesn't only work with IO, but with any monad, that's why it's type, (>>=) :: Monad m => m a -> (a -> m b) -> m b might look intimidating, but actually isn't. For more info, have a look at Real World Haskell[1], and, after that, the Typeclassopedia[2]. As a final notice, don't listen to the others: Those are just desperate people, vainly trying to convince themselves they'd understand monads. If you see monads being compared to space suits, nuclear waste processing plants, or burritos, run far, run fast, but run. If you see them compared to applicative functors, get curious. [1]http://book.realworldhaskell.org/read/ [2]http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-feedback/ -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Converting IO [XmlTree] to [XmlTree]
Cristiano Paris wrote: > I was a bit surprised by the strong reaction about my citation of > unsafePerformIO. Maybe it'd useful, for the future, to write a > document explaining how to help newbies properly, maybe putting it in > the mailing list charter. > 1) Tell them about interact. 2) If they're not satisfied, or already spoiled by the functions they want to use, explain bind wrt. IO, then do-notation. You don't want them to get puzzled by missing returns, or think that it's a keyword. 3) Let them catch up on monads by themselves, there's no need to confuse people with explanations of things they already understand. In other words: 1) Explain Pointed 2) Explain Functor 3) Explain Applicative 4) Explain Monad -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm
On Tue, Apr 14, 2009 at 2:47 PM, Andrew Wagner wrote: > Some other ideas for things to put in this package possibly: > is_prime :: Int -> Bool I'd also add isProbablePrime using a Miller-Rabin test or somesuch, for use with large numbers. It'd have to be in a monad which supplies randomness, of course. But to start with, I'd just package what I had and put it on Hackage. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
Quoth Cristiano Paris , > I was a bit surprised by the strong reaction about my citation of > unsafePerformIO. Well, there might be a couple of things going on here. Part of it is how to guess the unstated context of a question - I'm fairly sure that given a more thorough presentation of the question, there would have been no controversy about the answer. The general problem is that people who are comfortable with extremely esoteric parts of Haskell and used to discussing such things here, fail to recognize when they're dealing with people who are at a point where their needs are much more basic. (And who knows, which one was the present case? Not really enough information to know absolutely for sure.) But as you have found, unsafePerformIO is not just an esoteric topic, it's an uncomfortable one. We read that it isn't even part of the language, one should never really have any use for it in computation, only as a sort of meta-programming RTS thing. Yet, you might never guess this from reading the GHC documentation, which only urges you to be careful. Or from encountering it in fairly widespread use as a way to implement top level program state with IORefs. This sort of unresolved tension between practice and theory rightly makes people uneasy, and in my opinion you shouldn't take it personally. It's a good thing to occasionally probe those sore spots, and maybe if it bothers us enough it will lead to improvements. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC including System.Time but not Data.Time?
Hi folks, Apologies in advance because this sounds rantish... So I went to my friendly API reference at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html and noticed that I couldn't find Data.Time there anymore. Though it was still at http://www.haskell.org/ghc/docs/6.10.1/html/libraries/index.html After some checking on IRC, apparently this is on purpose. I find it *incredibly* annoying, and leaves us with the following unfortunate set of circumstances: 1) GHC ships with NO way to do date/time calculations in the preferred way (Data.Time) 2) GHC's docs reference only the obsolete (System.Time) way of doing things, with no reference to the preferred way. 3) I can't tell people to just install GHC and expect them to be able to perform date & time calculations the preferred way. Just about EVERY other language (C, Perl, Java, Python, etc.) come with this as part of the base install. 4) I can't update all my apps to use Data.Time without worrying about Yet Another Dependency. 5) Result: black eye on us. As I saw on IRC: the system isn't supposed to work out the box. the haskell platform is supposed to work out of the box. (shame it doesn't exist) Which is a fine goal, but until then, pretty please don't go dropping Data.Time out of GHC. I understand the goal of removing stuff from GHC, but the practical implications can be rather annoying. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC including System.Time but not Data.Time?
Hello John, Tuesday, April 14, 2009, 8:44:12 PM, you wrote: > I understand the goal of removing stuff from GHC, but the practical > implications can be rather annoying. i think that Haskell Platform will eventually replace what GHC was for a years, i.e. out-of-box solution for practical haskell usage. and ghc should be just what its name implies - bare compiler but i agree that stripping one package in minor 6.10.2 version, w/o Haskell Platform really available was an error -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC including System.Time but not Data.Time?
Removing a package in a minor release is, to quote, an epic fail. I don't understand how that could be done. -- Lennart On Tue, Apr 14, 2009 at 6:56 PM, Bulat Ziganshin wrote: > Hello John, > > Tuesday, April 14, 2009, 8:44:12 PM, you wrote: > >> I understand the goal of removing stuff from GHC, but the practical >> implications can be rather annoying. > > i think that Haskell Platform will eventually replace what GHC was for > a years, i.e. out-of-box solution for practical haskell usage. and ghc > should be just what its name implies - bare compiler > > but i agree that stripping one package in minor 6.10.2 version, w/o > Haskell Platform really available was an error > > -- > Best regards, > Bulat mailto:bulat.zigans...@gmail.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] Converting IO [XmlTree] to [XmlTree]
Never answer such newbie questions with unsafePerformIO. That's the wrong answer 99.99% of the time, but giving it to a newbie they might follow your advice. On Tue, Apr 14, 2009 at 5:01 PM, Cristiano Paris wrote: > On Tue, Apr 14, 2009 at 4:54 PM, rodrigo.bonifacio > wrote: >> Dear Sirs, >> >> I guess this is a very simple question. How can I convert IO [XmlTree] to >> just a list of XmlTree? > > Quick and dirty answer: unsafePerformIO. > > That's an easy finding on Hoogle: > > http://www.haskell.org/hoogle/?hoogle=IO+a+-%3E+a > > Anyhow, as the name suggest, the function is "unsafe", so you better > know what you're doing. > > Bye, > > Cristiano > ___ > 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] Looking for the fastest Haskell primes algorithm
You might want to look at Pari/GP ( http://pari.math.u-bordeaux.fr/ ) for ideas of what kind of functions to supply. Also, as a source of ideas for algorithms. Mike Matsko - Original Message - From: "Max Rabkin" To: "Andrew Wagner" Cc: "R.A. Niemeijer" , haskell-cafe@haskell.org Sent: Tuesday, April 14, 2009 12:35:19 PM GMT -05:00 US/Canada Eastern Subject: Re: [Haskell-cafe] Looking for the fastest Haskell primes algorithm On Tue, Apr 14, 2009 at 2:47 PM, Andrew Wagner wrote: > Some other ideas for things to put in this package possibly: > is_prime :: Int -> Bool I'd also add isProbablePrime using a Miller-Rabin test or somesuch, for use with large numbers. It'd have to be in a monad which supplies randomness, of course. But to start with, I'd just package what I had and put it on Hackage. --Max ___ 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] Non-atomic "atoms" for type-level programming
- if type-level tags (such as 'data TTrue'/'data TFalse') are declared repeatedly in separate modules, they represent separate types, preventing shared use (your type-level predicate doesn't return my version of 'TTrue'/'TFalse') How is the need for a common import for 'data TTrue; data TFalse' different then the need for a common import for 'data Bool = True | False'? Clearly, the advent of type-level programming necessitates the design of a type-level standard library, which provides standard abstractions to enable interoperation of custom libraries. But I don't see why the module system should not scale to type-level programming. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
> I wonder if this breaks referential transparency. Say, you define a signal > s and use s twice in some expression. s may be evaluated once and it > maybe evaluated twice. Does this make a difference? I'm not sure about the answer at the moment, but I believe we'd simply get two identically behaving signals in most cases, assuming they are evaluated in the same superstep. The automatic insertion of delays into cycles might cause problems here, as it depends on the current topology of the dataflow network what exactly happens. However, if all the cycles are broken with explicit delays, this is not an issue any more. It would break everything if IO-fed signals were created multiple times, but that can't happen, since their construction is explicitly marked by IO. > Is it possible that thereby the second “instance” has different > values > than the first one? I can't exclude the possibility, unfortunately, especially with the delay magic. But this is a question that needs further investigation. > When are your signals started? At evaluation time? Yes. Evaluation returns an IORef holding the initial state of the signal, wrapped in some structure. The top-level network is traversed at the beginning, so its nodes are all evaluated just once. > If yes, doesn’t this mean that the meaning of a signal depends on > evaluation time so that evaluating the same signal expression twice > actually results in two different signals? That's exactly the case. The system heavily relies on sharing in order to work properly. In fact, the ability to keep track of sharing under a pure-looking interface was the main motivation to choose this particular implementation. As far as I can tell, it should be fine as long as no Elerea primitive (signal constructors defined in Internal) is inlined. But I don't like this either, and I'd love to hear how the same effect can be achieved without resorting to such fragile constructs. Unfortunately, all my previous attempts failed at one point or another... > So Elerea seems to have to take special care to not break > referential transparency. No matter how I look at it, that would make it a completely different library. One that's very close to Reactive, in fact. > Elerea’s evaluation seems to be driven by hand-coded IO actions > so that use of such compiler optimizations is certainly not possible. This is quite true. On the other hand, most calculation is happening in pure functions anyway, and reactive book-keeping probably constitutes only a small fragment of the runtime in a typical application, so this is less of a worry for me. In the end, I see FRP as an alternative way to manage entities, and entities surely can't be optimised away. I use applicative laws to unite pure parts as much as possible, although I don't expect the resulting functions to be as efficient as if they had been assembled at compile time. A JIT compiler surely wouldn't hurt. :) > Grapefruit does this using era type parameters. Elerea doesn’t > seem to do anything about this at the moment. Apart from counting on conditions mentioned above, no. The intended meaning is that new signals are created whenever a latcher asks for one, but there's no way to enforce that for the time being. > Patai, could you please correct me where I’m wrong and clarify the > points which are still unclear to me? It seems I can hardly say anything new, because you see all the issues perfectly. (By the way, Patai is my family name. Different endianness over here. ;) > What do you think, Grapefruit is lacking, compared to Reactive? Oh, it's just my subjective opinion that I find the interface of Reactive very easy to use and flexible. That's primarily what I wanted to replicate in Elerea, I just ended up getting rid of events altogether, as I didn't need them, and that gave me a simpler system to play with. Grapefruit looks like something that feels more natural when describing the system at a higher level. But I really need to play with it more to have a well-founded opinion. Gergely -- http://www.fastmail.fm - mmm... Fastmail... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] error handling (esp. IO/exceptions)
I'm finding it hard to write robust code that isn't really ugly. Suppose I want to write > execute :: FilePath -> [String] -> IO (Either ExecuteError ExitCode) where 'ExecuteError' is a data type representing all the ways 'execute' could fail and that 'execute p args' is supposed to * ensure p exists * get p's permissions * ensure p is readable * ensure p is executable * execute p and return its exit code So 'ExecuteError' would have constructors corresponding to these ways to fail: * could not determine whether p exists * p does not exist * could not get p's permissions * p is not readable * p is not executable * could not execute p for some other reason So if I start to code it, I 'tryJust' 'doesFileExist'. If an exception is thrown, I convert it to Left $AppropriateExecuteError. If not, we know whether p exists. If it doesn't, convert it to Left. Otherwise, 'tryJust' 'getPermissions', etc. It's starting to staircase. I'm needing it to be easier to stop my computation and return specific things when exceptions are thrown or when certain requirements aren't met. Thanks for any help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing list of enum type
Michael, > What do I need to add to this Color enum type to print a list of them? You can also easily print a list of /all/ of them. Regards, John scratch$ cat color.hs data Color = Red | Blue | Green | Yellow | Orange | Brown | White | Black deriving (Show,Enum,Bounded) scratch$ ghci color.hs *Main> [minBound..maxBound] :: [Color] [Red,Blue,Green,Yellow,Orange,Brown,White,Black] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error handling (esp. IO/exceptions)
What about ErrorT monad transformer? Well, if it's not what you really want, you can define your own one without ugly "Error" class, so it'd be something like execute :: FilePath -> [String] -> MyCoolErrorT ExecuteError IO ExitCode On 14 Apr 2009, at 23:29, br...@lorf.org wrote: I'm finding it hard to write robust code that isn't really ugly. Suppose I want to write execute :: FilePath -> [String] -> IO (Either ExecuteError ExitCode) where 'ExecuteError' is a data type representing all the ways 'execute' could fail and that 'execute p args' is supposed to * ensure p exists * get p's permissions * ensure p is readable * ensure p is executable * execute p and return its exit code So 'ExecuteError' would have constructors corresponding to these ways to fail: * could not determine whether p exists * p does not exist * could not get p's permissions * p is not readable * p is not executable * could not execute p for some other reason So if I start to code it, I 'tryJust' 'doesFileExist'. If an exception is thrown, I convert it to Left $AppropriateExecuteError. If not, we know whether p exists. If it doesn't, convert it to Left. Otherwise, 'tryJust' 'getPermissions', etc. It's starting to staircase. I'm needing it to be easier to stop my computation and return specific things when exceptions are thrown or when certain requirements aren't met. Thanks for any help. ___ 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] error handling (esp. IO/exceptions)
On Tuesday, 14.04.09 at 23:36, Miguel Mitrofanov wrote: > What about ErrorT monad transformer? I don't see how it helps in my situation. ErrorT doesn't catch exceptions, for example. Suppose I did make something like ErrorT that catches exceptions and turn them into Lefts. Where would (>>=) get my specific error constructor? Maybe I need to make helper functions to use in runErrorT blocks that turn exceptions, Bools, Maybes, etc., into Eithers? Confused. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error handling (esp. IO/exceptions)
There's no way to make all your tests atomically, e.g, between the test that p exists and executing p, some other process could removce p. So the right way to do this (like opening a file), is to try executing it and let the OS tell you if it failed. On Tue, Apr 14, 2009 at 9:29 PM, wrote: > I'm finding it hard to write robust code that isn't really ugly. Suppose > I want to write > >> execute :: FilePath -> [String] -> IO (Either ExecuteError ExitCode) > > where 'ExecuteError' is a data type representing all the ways 'execute' > could fail and that 'execute p args' is supposed to > > * ensure p exists > * get p's permissions > * ensure p is readable > * ensure p is executable > * execute p and return its exit code > > So 'ExecuteError' would have constructors corresponding to these ways to > fail: > * could not determine whether p exists > * p does not exist > * could not get p's permissions > * p is not readable > * p is not executable > * could not execute p for some other reason > > So if I start to code it, I 'tryJust' 'doesFileExist'. If an exception > is thrown, I convert it to Left $AppropriateExecuteError. If not, we > know whether p exists. If it doesn't, convert it to Left. Otherwise, > 'tryJust' 'getPermissions', etc. It's starting to staircase. > > I'm needing it to be easier to stop my computation and return specific > things when exceptions are thrown or when certain requirements aren't > met. Thanks for any help. > ___ > 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] error handling (esp. IO/exceptions)
On Tue, 14 Apr 2009, Miguel Mitrofanov wrote: What about ErrorT monad transformer? Well, if it's not what you really want, you can define your own one without ugly "Error" class, so it'd be something like execute :: FilePath -> [String] -> MyCoolErrorT ExecuteError IO ExitCode My MyCoolErrorT is named Control.Monad.Exception.Synchronous.ExceptionalT and can be found in the explicit-exception package. In contrast to ErrorT it puts no restrictions on the exception type. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error handling (esp. IO/exceptions)
On Tue, 14 Apr 2009, br...@lorf.org wrote: On Tuesday, 14.04.09 at 23:36, Miguel Mitrofanov wrote: What about ErrorT monad transformer? I don't see how it helps in my situation. ErrorT doesn't catch exceptions, for example. Suppose I did make something like ErrorT that catches exceptions and turn them into Lefts. Where would (>>=) get my specific error constructor? With explicit-exception you would call Exc.fromEitherT $ try $ execute path options The package has some hidden modules, where I experiment with a special IO type that cannot throw exceptions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error handling (esp. IO/exceptions)
On Tuesday, 14.04.09 at 22:13, Lennart Augustsson wrote: > So the right way to do this (like opening a file), is to try executing > it and let the OS tell you if it failed. I know, but the various functions that create processes don't help me know whether the program actually ran or not. For example, > createProcess (proc "nosuch" []) >>= \(_,_,_,ph) -> waitForProcess ph returns ExitCode 127. If I use the same code to run 'test', a C program that returns 127, I get the same thing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Elerea, another FRP library
I will test it on a couple of machines, desktops and laptops. I think the problem was my laptop going into power safe mode or something, since sometimes it runs smooth, sometimes it doesn't. This could indeed be a problem with GLFW's time attribute on windows (which uses the CPU tick frequency which gets trottled to safe energy), although I believe the Windows API should take care of this. I haven't seen this yet with my own frp experiments, which seem to run smooth all the time, but again I will do more testing. I have been thinking about your approach, using mutable variables to hold a signal's sample. This is exactly what I did with on old C# prototype, and it worked out nicely. If you take a look what Yampa does: it hides signals and only exposes signal functions. But that means that the FRP engine itself could indeed use mutable variables for its signals, as long as during the evaluation of the circuit at time T no side effects should occur; the side effects should take place when the simulation is advanced to T+dT, which is done after the circuit is fully evaluated at time T. If you want higher order integration, you would need to keep a buffer of more samples, but it would still work. So I think you approach is a very good pragmatic one! I'm only a bit worried about your automatic insertion of delays; this might break referential transparency at time T, since it depends on the order in which the nodes in the circuit are evaluated no? The latter could be problematic when doing evaluation in parallel on multiple cores I guess. 2009/4/14 Patai Gergely > > Interesting. I'm testing it on Window though. You're using Linux? Maybe > > the scheduling is different. > Now I tried it on Windows in VirtualBox, and it still looks quite smooth > to me (except that hardware acceleration doesn't seem to work properly > through virtualisation, but it's okay as long as I keep the window small > enough). However, unlike the Linux version, it does max out the CPU, so > the trick with threadDelay 0 doesn't work. Apparently, I'll have to find > a real Windows box somewhere, because I couldn't reproduce the jerkiness > you're talking about. > > Gergely > > -- > http://www.fastmail.fm - The way an email service should be > > ___ > 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] ANN: Elerea, another FRP library
Ouch, I did not see Wolfgang's email nor your reply, sorry for the noise (which I'm doing again with this email ;-) On Tue, Apr 14, 2009 at 11:01 PM, Peter Verswyvelen wrote: > I will test it on a couple of machines, desktops and laptops. I think the > problem was my laptop going into power safe mode or something, since > sometimes it runs smooth, sometimes it doesn't. This could indeed be a > problem with GLFW's time attribute on windows (which uses the CPU tick > frequency which gets trottled to safe energy), although I believe the > Windows API should take care of this. I haven't seen this yet with my own > frp experiments, which seem to run smooth all the time, but again I will do > more testing. > I have been thinking about your approach, using mutable variables to hold a > signal's sample. This is exactly what I did with on old C# prototype, and it > worked out nicely. If you take a look what Yampa does: it hides signals and > only exposes signal functions. But that means that the FRP engine itself > could indeed use mutable variables for its signals, as long as during the > evaluation of the circuit at time T no side effects should occur; the side > effects should take place when the simulation is advanced to T+dT, which is > done after the circuit is fully evaluated at time T. If you want higher > order integration, you would need to keep a buffer of more samples, but it > would still work. So I think you approach is a very good pragmatic one! I'm > only a bit worried about your automatic insertion of delays; this might > break referential transparency at time T, since it depends on the order in > which the nodes in the circuit are evaluated no? The latter could be > problematic when doing evaluation in parallel on multiple cores I guess. > > 2009/4/14 Patai Gergely > > > Interesting. I'm testing it on Window though. You're using Linux? Maybe >> > the scheduling is different. >> Now I tried it on Windows in VirtualBox, and it still looks quite smooth >> to me (except that hardware acceleration doesn't seem to work properly >> through virtualisation, but it's okay as long as I keep the window small >> enough). However, unlike the Linux version, it does max out the CPU, so >> the trick with threadDelay 0 doesn't work. Apparently, I'll have to find >> a real Windows box somewhere, because I couldn't reproduce the jerkiness >> you're talking about. >> >> Gergely >> >> -- >> http://www.fastmail.fm - The way an email service should be >> >> ___ >> 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: win64 ghc version Re[4]: [Haskell-cafe] GHC needs a 64 bit machine to be fast?
I will add myself a million times then :-) On Tue, Apr 14, 2009 at 5:25 PM, Bulat Ziganshin wrote: > Hello Peter, > > Wednesday, April 8, 2009, 2:42:24 PM, you wrote: > > if you need win64 ghc version - add yourself to CC list of > http://hackage.haskell.org/trac/ghc/ticket/1884 > > > Well, make that 2! :-) > > On Wed, Apr 8, 2009 at 11:47 AM, Bulat Ziganshin > > wrote: > > Hello Peter, > > > > Wednesday, April 8, 2009, 12:58:25 PM, you wrote: > > > > No. it seems that i'm only user asking GHC team for 64-bit version > > > > >> Regarding that, is it possible to generate 64-bit code using GHC on > Windows? > > > >> On Wed, Apr 8, 2009 at 10:17 AM, FFT wrote: > >> > >> On Wed, Apr 8, 2009 at 1:14 AM, Karel Gardas > wrote: > >>> > >>> Hello, > >>> > >>> perhaps you are hit by following issue? > >>> http://hackage.haskell.org/trac/ghc/ticket/594 > >> > >> > >> The benchmark isn't using the native code generator, it compiles via > >> C, as I understand. > >> > >> What are other people's timings on 32 bit Linux machines? > >> > >> ___ > >> Haskell-Cafe mailing list > >> Haskell-Cafe@haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > > >> > > > > > > > > -- > > Best regards, > > Bulatmailto:bulat.zigans...@gmail.com > > > > > > > > > > -- > Best regards, > Bulatmailto:bulat.zigans...@gmail.com > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Printing list of enum type
I didn't know that, but there's a lot I don't know about Haskell. It works great. Thanks! Michael --- On Tue, 4/14/09, John Dorsey wrote: From: John Dorsey Subject: Re: [Haskell-cafe] Printing list of enum type To: "michael rice" Cc: haskell-cafe@haskell.org Date: Tuesday, April 14, 2009, 3:33 PM Michael, > What do I need to add to this Color enum type to print a list of them? You can also easily print a list of /all/ of them. Regards, John scratch$ cat color.hs data Color = Red | Blue | Green | Yellow | Orange | Brown | White | Black deriving (Show,Enum,Bounded) scratch$ ghci color.hs *Main> [minBound..maxBound] :: [Color] [Red,Blue,Green,Yellow,Orange,Brown,White,Black] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] hgettext 0.1.10 - last major release
Hello, I've uploaded last (and latest) significant version on hgettext module. Currently it works fine, and has bindings to all gettext functions (from libintl.h). Next versions will be only bug fixes of this version. GNU GetText allows you only to create simple, standalone desktop applications for Linux, to make something complex you should use different trick, fortunately Haskell could do these tricks much easier than other languages (if you want to see, how to build Gtk application, which supports run time language switching, and shows information on two languages simultaneously you could download example from http://hgettext.googlecode.com/files/gtk-hello-0.0.2.tar.gz , or read about it from http://progandprog.blogspot.com/2009/04/multilingual-ui-and-dynamic-language.html) I don't see any strong reasons to write any combinators over this basic bindings. Haskell needs more powerful internationalization library, and I am plan to design it, but it will be completely different from gettext principles, so this library will be released with another name. CHANGELOG: * Added '--version' command line parameter to hgettext tool * Added support for literate haskell files to hgettext tool * Changed all functions to throw IOError when they fails instead of return Nothing * Added bindings for: ngettext, dgettext, dngettext, dcgettext and dcngettext functions -- Best regards, Vasyl Pasternak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lift in TemplateHaskell?
Hi folks, I'm having trouble reading the TemplateHaskell docs and trying to do something that seems like it should be simple. In MetaML, there is a 'lift' function which does exactly what I want to do. Here's an example function: let double n = [| 2 * $( litE (integerL n) ) |] This works as intended, but instead of writing "litE (integerL n)" I just want to write "lift n", or something similar. I expect that would involve a type class called something like Liftable that would lift literals using the appropriate functions. Does this exist? Thanks, Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: lift in TemplateHaskell?
OK, I figured it out. The class is Language.Haskell.TH.Syntax.Lift. The function is Language.Haskell.TH.Syntax.lift. And I can rewrite my function as: let double n = [| 2 * n |] I wish this were explained in the TemplateHaskell documentation. - Lyle On Tue, Apr 14, 2009 at 2:51 PM, Lyle Kopnicky wrote: > Hi folks, > > I'm having trouble reading the TemplateHaskell docs and trying to do > something that seems like it should be simple. In MetaML, there is a 'lift' > function which does exactly what I want to do. Here's an example function: > > let double n = [| 2 * $( litE (integerL n) ) |] > > This works as intended, but instead of writing "litE (integerL n)" I just > want to write "lift n", or something similar. I expect that would involve a > type class called something like Liftable that would lift literals using the > appropriate functions. Does this exist? > > Thanks, > Lyle > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error handling (esp. IO/exceptions)
Quoth br...@lorf.org, > On Tuesday, 14.04.09 at 22:13, Lennart Augustsson wrote: >> So the right way to do this (like opening a file), is to try executing >> it and let the OS tell you if it failed. > > I know, but the various functions that create processes don't help me > know whether the program actually ran or not. For example, > >> createProcess (proc "nosuch" []) >>= \(_,_,_,ph) -> waitForProcess ph > > returns ExitCode 127. If I use the same code to run 'test', a C program > that returns 127, I get the same thing. Right, awkward problem. Don't know if it can be solved in a portable way, but you (as author of a createProcess-like function) can use a pipe from the forked process. The code demo I append works, given FFI support for the POSIX functions it uses, but may not be appropriate for use with GHC (I'm using nhc98.) Donn spawn file cmd env = do (e0, e1) <- pipe -- F_CLOEXEC: close fd on (sucessful) exec. fcntlSetFlag e1 F_CLOEXEC t <- fork (fex e0 e1) close e1 rx <- readFd e0 256 if null rx then return t else ioError (userError rx) where fex e0 e1 = do close e0 catch (execve file cmd env) (\ e -> writeFd e1 (ioeGetErrorString e)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] error handling (esp. IO/exceptions)
Quoth br...@lorf.org, >> execute :: FilePath -> [String] -> IO (Either ExecuteError ExitCode) > > where 'ExecuteError' is a data type representing all the ways 'execute' > could fail and that 'execute p args' is supposed to > > * ensure p exists > * get p's permissions > * ensure p is readable > * ensure p is executable * read UNIX "magic number" from first 2 bytes of p case number of "#!" -> interpret rest of line, start validation process over on interpreter file valid executable type for OS -> OK _ -> not OK > * execute p and return its exit code Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Best text editor
Stefan Monnier writes:
>> I'm a beginner, but I'll chime in and say I use Emacs with
>> haskell-mode. It's auto-indentation is a bit complex in behavior which is
>> unappealing (I feel like I never know what it's going to do when I hit tab),
>> but I would be curious what someone with more experience feels about that.
>
> I clearly recommend Emacs with haskell-mode, but I agree that the
> indentation is problematic. Note that the code in the CVS repository
> comes with a completely new indentation algorithm courtesy of Kristof
> Bastiaensen (so you can now choose
> between haskell-simple-indent, haskell-indent, and the new
> haskell-indentation). I haven't tried this new algorithm much, but
> people who dislike haskell-indent might want to give it a try.
It works for me and I believe it indeed behaves much more
rational. The doc in the file haskell-indentation.el is
misleading. It states using function
turn-on-haskell-indentation, which is removed according to
Changelog. And the default definition of haskell-mode-hook
in haskell-mode.el is somewhat offending, so I recommend
remove the two autoload lines.
Index: haskell-mode.el
===
RCS file: /cvs/fptools/CONTRIB/haskell-modes/emacs/haskell-mode.el,v
retrieving revision 1.32
diff -u -b -B -r1.32 haskell-mode.el
--- haskell-mode.el 28 Feb 2008 22:23:36 - 1.32
+++ haskell-mode.el 14 Apr 2009 22:24:53 -
@@ -504,8 +504,6 @@
;;;###autoload(add-to-list 'auto-mode-alist '("\\.\\(?:[gh]s\\|hi\\)\\'" .
haskell-mode))
;;;###autoload(add-to-list 'auto-mode-alist '("\\.l[gh]s\\'" .
literate-haskell-mode))
-;;;###autoload(add-hook 'haskell-mode-hook 'turn-on-haskell-doc-mode)
-;;;###autoload(add-hook 'haskell-mode-hook 'turn-on-haskell-indent)
(defcustom haskell-hoogle-command
(if (executable-find "hoogle") "hoogle")
--
c/*__o/*
<\ * (__
*/\ <
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Best text editor
On Tue, 2009-04-14 at 11:34 +0200, Achim Schneider wrote: > Yes, and I figured I'd have to edit the keymap to get productive. While > it features a fully functional subset of vim that's more than enough to > efficiently edit files, it's not the subset I use... and then I was too > lazy to actually do it. As one of the Yi developers, I'd love to hear some more specific feedback on this. Do you remember any specific Vim features that were missing? > Documentation is badly lacking, too, it's like trying to configure > xmonad without xmonad-contrib and all the docs. This is slowly improving, and Yi's haddock documentation now builds fine. This should soon be available on Hackage also, when the Haddock there is upgraded. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] glut installation using cabal failed
On Tue, 14 Apr 2009 08:25:52 +0200, Raja Koduru wrote: hi, I am a beginner to haskell. I am trying to install glut using "cabal install glut" Pasting here a tail of the output - checking for unistd.h... yes checking windows.h usability... yes checking windows.h presence... yes checking for windows.h... yes checking GL/glut.h usability... no checking GL/glut.h presence... no checking for GL/glut.h... no checking for GLUT library... no checking for GL/glut.h... (cached) no checking GLUT/glut.h usability... no checking GLUT/glut.h presence... no checking for GLUT/glut.h... no configure: error: no GLUT header found, so this package cannot be built See `config.log' for more details. cabal: Error: some packages failed to install: GLUT-2.1.1.2 failed during the configure step. The exception was: exit: ExitFailure 1 - But I do have "glut.h" in my "D:\ghc\ghc-6.10.2\include\mingw\GL". Define the environment variable: C_INCLUDE_PATH=D:\ghc\ghc-6.10.2\include\mingw (you can add more directories, separate them by ';') To let the linker find the libraries, define LIBRARY_PATH. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Best text editor
On Wed, Apr 15, 2009 at 8:57 AM, Jeff Wheeler wrote: > > As one of the Yi developers, I'd love to hear some more specific > feedback on this. Do you remember any specific Vim features that were > missing? My main gripe with the vi emulation in Yi was in vty mode[1] and how it was unable to tell that 'esc' wasn't always 'meta-'. e.g., If I leave insert mode with esc and hit j to go down a line too quickly it interpreted it as meta-j. Quite annoying. This was a little while ago though. Also, I remember the cursor would go beyond the last character in a line in command mode, which is very un-vi-ish. At the time I remember thinking I should try and fix these things myself... but.. umm... [1] vty Yi is the only one I would use--coding must always live inside a screen session :) I really dislike wrapping a GUI around vi(m). I don't want toolbars, tabs, scrollbars nor menus. I don't even want a titlebar. Absolute full screen terminal running screen is perfect. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
