Re: [Haskell-cafe] Construct all possible trees
I'm afraid, but you are missing a case here. For example the tree
Branch (Leaf 1) (Branch (Leaf 3) (Leaf 2))
is not constructed by your program. Correct is
insert x t@(Leaf y) = [Branch s t, Branch t s] where s = Leaf x
insert x t@(Branch l r) = [Branch l' r | l' - insert x l] ++
[Branch l r' | r' - insert x r] ++
{- missed this: -} [Branch s t,Branch t s] where s = Leaf x
With this modification, your program becomes essentially the same as my
version but with suboptimal sharing (you construct Leaf x twice and with
the correction even three times). As a consequence my version is faster
and eats less memory.
/BR
--
-- Mirko Rahn -- Tel +49-721 608 7504 --
--- http://liinwww.ira.uka.de/~rahn/ ---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Construct all possible trees
Jon Fairbairn wrote: Trees with all the elements of a list in that order: the_trees [x] = [Leaf x] the_trees l = zipWith Branch (concat (map the_trees (tail $ inits l))) (concat (map the_trees (tail $ tails l))) Sorry, but this problem seems to trigger incorrect codes, somehow. Here we have the_trees [1,2,3,4] outputs Branch (Leaf 1) (Branch (Leaf 2) (Branch (Leaf 3) (Leaf 4))) Branch (Branch (Leaf 1) (Leaf 2)) (Branch (Branch (Leaf 2) (Leaf 3)) (Leaf 4)) Branch (Branch (Leaf 1) (Branch (Leaf 2) (Leaf 3))) (Branch (Leaf 3) (Leaf 4)) Branch (Branch (Branch (Leaf 1) (Leaf 2)) (Leaf 3)) (Leaf 4) which is certainly not as wanted. The problem is that you do the concat before the zip. We have for splits xs = zip (tail . inits $ xs) (tail . tails $ xs) splits [1,2,3,4] == ([1],[2,3,4]) : ([1,2],[3,4]) : ... So now length (the_trees [1]) == 1 length (the_trees [1,2] ) == 1 length (the_trees [2,3,4]) == 2 So we build a Branch from the first tree with labels [1,2] and the last tree with labels [2,3,4]. That's wrong! A fixed version could look like the_trees [x] = [Leaf x] the_trees xs = nonempty_splits xs = \ (l,r) - [ Branch a b | a - the_trees l, b - the_trees r ] nonempty_splits (x:y:ys) = ([x],y:ys) : [ (x:l,r) | (l,r) - nonempty_splits (y:ys) ] nonempty_splits _= [] /BR -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to devide matrix into small blocks
L.Guo wrote: I have wrote the target function like this, and tested. mkBlocks (w,h) = map concat . concat . transpose . chop h . map (chop w) I don't understand how this relates to your original problem description. But then, again, I probably did not understand that one too well. This is not a homework, though likely to be one. No offense meant, of course. Anyway, as a challenge to others on the list: write a one-liner that splits an image like [abcd,efgh,ijkl,mnop], interpreted as abcd efgh ijkl mnop into the list of images: [ ab ef , cd gh , ij mn , kl op ] for (w,h)=(2,2), into: [ a e , b f , c g , d h , i m , j n , k o , l p ] for (w,h)=(1,2), and so on. (Where an image like ab ef is represented as [ab,ef].) Have fun, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] found monad in a comic
Dan Piponi wrote: Marc asked: http://xkcd.com/c248.html ( join /= coreturn ) IMHO this could be a beautiful and easy way to explain monads. comments? I'll eat my hat if there isn't a formal way of looking at this. I'm not qualified to put it together coherently but it goes something like this: modal logic has Kripke semantics based on the notion of many worlds. For the right modal logic, the many worlds idea captures the notion of counterfactual worlds. We can also extend the Curry-Howard isomorphism to include modal logic. Some of the laws of modal logic (or their duals) correspond to monad (or comonad) laws (see laws 4 and t here: http://en.wikipedia.org/wiki/Kripke_semantics). These laws translate into rules about what worlds 'accessible' from what other worlds. So that cartoon may have a formal interpretation in terms of monads... Unfortunately that interpretation would have to rely on an equivocation of 'accessible'. In modal logic (and in the transition from the first to the second situation in the comic), it's a logical relationship; in the transition from the second to the third situation it's meant to ground the possibility of physical interaction, which normally is not thought to be possible between possible worlds. You'd probably have to ship a lot of extra physics (and metaphysics) to have an intelligible interpretation that connects both senses :-) Ciao, Leif -- Dan ___ 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 to devide matrix into small blocks
Hi Janis. I think either my data format or my original question confuses you. About the problem description. When I send the question, I have not decide how to manage the block data. If the rough question confuse you, I have to say sorry. About the data. The whole image is of type [[a]], and after being devided, it is also [[a]]. eg. for (w,h) = (2,2) a b c d e f g h i j k l m n o p makes a b e f c d g h i j m n k l o p in another word, mkBlocks makes [pixels-of-lines] into [pixels-in-blocks]. This cryptical type is easy to form and to form from type [[pixels-of-lines-in-block]], and also, is close to my future purpose. Thanks. -- L.Guo 2007-06-14 - From: Janis Voigtlaender At: 2007-06-14 15:42:40 Subject: Re: [Haskell-cafe] How to devide matrix into small blocks L.Guo wrote: I have wrote the target function like this, and tested. mkBlocks (w,h) = map concat . concat . transpose . chop h . map (chop w) I don't understand how this relates to your original problem description. But then, again, I probably did not understand that one too well. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Happy, GLR and GHC 6.6
Stefan O'Rear wrote: On Thu, Jun 14, 2007 at 12:38:27AM +0200, Iván Pérez Domínguez wrote: Hi everyone, As we all know, FiniteMap was deprecated, and with GHC-6.6 Data.Map must be used instead. Some function names in Data.Map clash with names in prelude, and Map is usually imported qualified. Happy generates GLR parsers (-l), but the templates it uses keep calling FiniteMap functions. When Data.Map is imported, it's not imported qualified and some function names are ambiguous. I've been using a modified template to generate a GLR parser with GHC-6.6 and it seems to work just fine (there are few changes, not a big deal anyway). I just got the most recent version of Happy and the problem remains, so I applied my changes to GLR_Lib.lhs and ran a diff. The result is attached to this mail. Hope it helps someone else. Why don't you just send a darcs patch? That would be easier for everyone :) Stefan I'm not familiar with darcs. Shall I use darcs --whatsnew for it? Ivan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Construct all possible trees
Mirko Rahn [EMAIL PROTECTED] writes: Jon Fairbairn wrote: Trees with all the elements of a list in that order: the_trees [x] = [Leaf x] the_trees l = zipWith Branch (concat (map the_trees (tail $ inits l))) (concat (map the_trees (tail $ tails l))) Sorry, but this problem seems to trigger incorrect codes, somehow. I don't think it's the problem in this case -- it's writing code when half asleep. The network connexion had been down for hours, so it was past my bedtime when I started... splits xs = zip (tail . inits $ xs) (tail . tails $ xs) I should have defined this (though I might have called it partitions), probably like this: partitions l = inits l `zip` tails l and used (with appropriate discarding) it in both the_trees and combinations, and I should have written a proper combinations rather than writing nonempty_combinations and calling it combinations. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to devide matrix into small blocks
On Thu, 14 Jun 2007, Janis Voigtlaender wrote: Anyway, as a challenge to others on the list: write a one-liner that splits an image like [abcd,efgh,ijkl,mnop], interpreted as abcd efgh ijkl mnop into the list of images: [ ab ef , cd gh , ij mn , kl op ] It's just an additional 'concat' in my solution, isn't it? Ah, you mean without the 'split' helper function? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to devide matrix into small blocks
On Thu, 14 Jun 2007, L.Guo wrote: About the data. The whole image is of type [[a]], and after being devided, it is also [[a]]. I would store an image in an (Array (Int,Int)). This is not only more efficient, but also ensures statically that the image data is rectangular. I assume that you do not need infinite images. They can be represented by lists but not by arrays. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to devide matrix into small blocks
Henning Thielemann wrote: On Thu, 14 Jun 2007, Janis Voigtlaender wrote: Anyway, as a challenge to others on the list: write a one-liner that splits an image like [abcd,efgh,ijkl,mnop], interpreted as abcd efgh ijkl mnop into the list of images: [ ab ef , cd gh , ij mn , kl op ] It's just an additional 'concat' in my solution, isn't it? Ah, you mean without the 'split' helper function? No, I do mean using the chop function provided by the original poster. And I think that adding a concat to your solution, as in: concat (chop blockHeight (map (chop blockWidth) image)) gives the following, different from above: [ ab cd , ef gh , ij kl , mn op ] Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Happy, GLR and GHC 6.6
On Thu, Jun 14, 2007 at 11:31:23AM +0200, Iván Pérez Domínguez wrote: Stefan O'Rear wrote: On Thu, Jun 14, 2007 at 12:38:27AM +0200, Iván Pérez Domínguez wrote: Hi everyone, As we all know, FiniteMap was deprecated, and with GHC-6.6 Data.Map must be used instead. Some function names in Data.Map clash with names in prelude, and Map is usually imported qualified. Happy generates GLR parsers (-l), but the templates it uses keep calling FiniteMap functions. When Data.Map is imported, it's not imported qualified and some function names are ambiguous. I've been using a modified template to generate a GLR parser with GHC-6.6 and it seems to work just fine (there are few changes, not a big deal anyway). I just got the most recent version of Happy and the problem remains, so I applied my changes to GLR_Lib.lhs and ran a diff. The result is attached to this mail. Hope it helps someone else. Why don't you just send a darcs patch? That would be easier for everyone :) Stefan I'm not familiar with darcs. Shall I use darcs --whatsnew for it? darcs record pick the changes you wnat type a patch name darcs send select your patch No need to attach files, figure out the right email address, etc. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Thread blocked indefinitely problem when playing with signals and MVar on Windows
Hi all, I'm playing with signal handlers on Win32. I found a good post on signal handlers but it works with System.Posix.Signals which on Win32 is empty. Blog is here: http://therning.org/magnus/archives/285 I tried to adapt this code to GHC.ConsoleHandler, the Win32 counterpart of System.Posix.Signals. The code: = module Main where --import System.Posix.Signals import GHC.ConsoleHandler import Control.Concurrent import Control.Concurrent.MVar import System -- ControlC increments counter handler :: MVar (Int, Bool) - ConsoleEvent - IO () handler mi ControlC = do (i, exit) - takeMVar mi putStrLn In ControlC handler putMVar mi ((i + 1), False) -- Break sets Bool to True to stop application handler mi Break = do (i, exit) - takeMVar mi putStrLn In Break handler putMVar mi (i, True) -- Ignore other signals handler _ _ = do return () doNothing :: MVar (Int, Bool) - IO () doNothing mi = do threadDelay 100 (i, exit) - takeMVar mi if exit then do putStrLn Good bye! exitWith ExitSuccess else do putStrLn $ Repeating ++ (show i) main :: IO () main = do mi - newMVar (0, False) installHandler (Catch $ handler mi) sequence_ $ repeat $ doNothing mi = It compiles but when run I receive this: Repeating 0 SignalsText.exe: loop First iteration is executed but then it gets trapped in what looks like a dead lock. If I remove the installation of the signal handler to just have an infinite loop (comment out installHandler ...) I get this: Repeating 0 SignalsText.exe: thread blocked indefinitely Without the signal handler the code uses only the main and doNothing function and I can't figure out what causes this to block? Something to do with my use of MVar, but what??? Lazy evaluation? Thanks for any advice, Olivier. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Efficient signal processing
I always thought that signal processing must be a good benchmark for compiler optimizations and optimizer rules of libraries like 'binary' and 'fps'. Many signal processing functions process a signal from the beginning to the end with a little of state, thus in many cases I expect that they can be translated to simple loops. However, I still cannot get the necessary speed for real-time processing out of 'binary' and 'fps'. In my setup a signal is of type [Double]. After a series of sound transformations a signal is finally converted to [Int16] and then to ByteString. Can I expect that interim signals represented as lists are optimized away? I have simple example which writes zeros to disk. The content of the first file is created by ByteString.replicate for the purpose of comparison with the second file. With the second file I want to check the speed of the conversion from [Int16] to ByteString. module Main (main) where import System.Time (getClockTime, diffClockTimes, tdSec, tdPicosec) import qualified Data.ByteString.Lazy as B import qualified Data.Binary.Put as Bin import Foreign (Int16) signalToBinaryPut :: [Int16] - B.ByteString signalToBinaryPut = Bin.runPut . mapM_ (Bin.putWord16host . fromIntegral) writeSignalBinaryPut :: FilePath - [Int16] - IO () writeSignalBinaryPut fileName = B.writeFile fileName . signalToBinaryPut measureTime :: String - IO () - IO () measureTime name act = do putStr (name++: ) timeA - getClockTime act timeB - getClockTime let td = diffClockTimes timeB timeA print (fromIntegral (tdSec td) + fromInteger (tdPicosec td) * 1e-12 :: Double) numSamples :: Int numSamples = 100 zeroSignal16 :: [Int16] zeroSignal16 = replicate numSamples 0 zeroByteString :: B.ByteString zeroByteString = B.replicate (fromIntegral (2 * numSamples)) 0 main :: IO () main = do measureTime write zero bytestring (B.writeFile zero-bytestring.sw zeroByteString) measureTime put zero int16 (writeSignalBinaryPut zero-int16string.sw zeroSignal16) The program is compiled with GHC-6.4 and option -O2, CPU clock 1.7 GHz. This yields: $ speedtest write zero bytestring: 2.5674e-2 put zero int16: 1.080541 That is, not using ByteString.replicate and converting from [Int16] to ByteString slows down computation by a factor of 40. What am I doing wrong? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Updated urlcheck
I'm proud to announce an updated version of dons' concurrent urlcheck. It's a bad and buggy rewrite from scratch. It can check a file of urls or the consistency of the transitive hull of a website incl. the existance of the border urls. Futhermore the warnings from TagSoup parsing can be reported. Main bugs are memory leaks in conjunction with unnecessary retrieval of binary files, and missing documentation. If somebody has enough time in the next weeks: Many thanks in advance. URL: http://www.iks-jena.de/mitarb/lutz/haskell/urlcheck-0.0.tar.gz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] found monad in a comic
On 6/14/07, Leif Frenzel [EMAIL PROTECTED] wrote: Dan Piponi wrote: Marc said: Unfortunately that interpretation would have to rely on an equivocation of 'accessible'. I was going to deal with that using an isomorphism from the class Metaphor. You know, the one that also contains the map from Thee to A Summer's Day. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] practicality of typeful programming
Hello folks I've recently asked some questions here about some little type hackery implementing an embedded dsl. But now I wonder if it's worth the effort at all... The thing is enforcing static constraints turns out to be quite time consuming, even for 'reasonble' things. The dsl I'm writing will not primarily be used from Haskell sources, rather more likely be input to the interpreter, and hence dynamic analysis after parsing will occur any way. On the other hand, enforcing them excludes some errors... To give you a flavour, classical example, I could represent expressions simply by 'data Exp' or by 'data Exp a' where a is the type of expression and 4 + str is illegal, or by 'data Exp s a' where a is the same and s is an additional property, like some kind of things the expression mentions, and there are restrictions on how Exp s1 and Exp s2 can combine. And s is not otrhogonal with a. There may be more properties. I'd like to hear your thoughts on how practical it is, and to which extent, to use typeful programing for statically enforcing constraints, in real-life applications, where readability and maintainability matter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Construct all possible trees
Well, I eventually came up with this: - data Tree = Leaf Int | Branch Tree Tree deriving Show pick :: [x] - [(x,[x])] pick = pick_from [] pick_from :: [x] - [x] - [(x,[x])] pick_from ks [] = [] pick_from ks xs = (head xs, ks ++ tail xs) : pick_from (ks ++ [head xs]) (tail xs) trees :: [Int] - [Tree] trees = map fst . (\ts - all_trees 1 (2 * length ts) ts) . map Leaf all_trees :: Int - Int - [Tree] - [(Tree,[Tree])] all_trees n m ts | n m = [] | otherwise = pick ts ++ sub_trees n m ts sub_trees :: Int - Int - [Tree] - [(Tree,[Tree])] sub_trees n m ts = do let n2 = n * 2 (t0,ts0) - all_trees n2 m ts (t1,ts1) - all_trees n2 m ts0 return (Branch t0 t1, ts1) - For example, trees [1,2,3] now gives Leaf 1 Leaf 2 Leaf 3 Branch (Leaf 1) (Leaf 2) Branch (Leaf 1) (Leaf 3) Branch (Leaf 1) (Branch (Leaf 2) (Leaf 3)) Branch (Leaf 1) (Branch (Leaf 3) (Leaf 2)) Branch (Leaf 2) (Leaf 1) Branch (Leaf 2) (Leaf 3) Branch (Leaf 2) (Branch (Leaf 1) (Leaf 3)) Branch (Leaf 2) (Branch (Leaf 3) (Leaf 1)) Branch (Leaf 3) (Leaf 1) Branch (Leaf 3) (Leaf 2) Branch (Leaf 3) (Branch (Leaf 1) (Leaf 2)) Branch (Leaf 3) (Branch (Leaf 2) (Leaf 1)) Branch (Branch (Leaf 1) (Leaf 2)) (Leaf 3) Branch (Branch (Leaf 1) (Leaf 3)) (Leaf 2) Branch (Branch (Leaf 2) (Leaf 1)) (Leaf 3) Branch (Branch (Leaf 2) (Leaf 3)) (Leaf 1) Branch (Branch (Leaf 3) (Leaf 1)) (Leaf 2) Branch (Branch (Leaf 3) (Leaf 2)) (Leaf 1) which looks pretty comprehensive to me! The derivation wasn't easy. It goes something like this: First, the pick function takes a list and picks a single element from it, returning the element picked and the remaining unpicked elements. It does this inside the list monad, thus representing every possibel choice. (It's defined in terms of pick_from, which isn't used anywhere else. The algorithm should be fairly self-evident.) Next, we have trees which transforms a list of integers into a list of trivial 1-leaf trees to be processed by all_trees. The all_trees function calls pick to select all possible trivial trees, and then calls sub_trees to pick all possible nontrivial trees. The code for sub_trees would go something like this: sub_trees ts = do t0 - ts t1 - ts return (Branch t0 t1) But now t0 == t1 sometimes, which we cannot allow. Hence the pick function: sub_trees ts = do (t0,ts0) - pick ts (t1,ts1) - pick ts0 return (Branch t0 t1, ts1) And now the problem is solved. However, this only generates all possible 2-leaf trees. To make *all* possible trees, we must be recursive: sub_trees ts = do (t0,ts0) - all_trees ts (t1,ts1) - all_trees ts0 return (Branch t0 t1, ts1) And now it works properly. Er... wait. Now we have an infinite recursive loop! all_trees -- sub_trees -- all_trees (with the same arguments)! The only way I could figure out to avoid that is to count how big the input list is - and hence how deep the tree can possibly be. Then you keep track of how deep you are, and abort when you get too deep. I added lots of hackery to avoid recomputing stuff. Makes the code look very messy and ugly... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] found monad in a comic
Andrew Coppin wrote: ...is everybody else looking at a different web page to me? *blinks* Everybody is interpreting it differently. (As usual.) I see an unsafePerformIO. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to devide matrix into small blocks
What about blocks w h = concatMap transpose . map (map (chop w)) . chop h ? @L. Guo: map concat . blocks w h is what you want. Cheers, Daniel Am Donnerstag, 14. Juni 2007 09:42 schrieb Janis Voigtlaender: Anyway, as a challenge to others on the list: write a one-liner that splits an image like [abcd,efgh,ijkl,mnop], interpreted as abcd efgh ijkl mnop into the list of images: [ ab ef , cd gh , ij mn , kl op ] for (w,h)=(2,2), into: [ a e , b f , c g , d h , i m , j n , k o , l p ] for (w,h)=(1,2), and so on. (Where an image like ab ef is represented as [ab,ef].) Have fun, Janis. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Thread blocked indefinitely problem when playing with signals and MVar on Windows
I found my mistake. Through my copy/paste I ended up changing a readMVar into a takeMVar leaving the MVar empty and having the main thread blocking to read it. Changed takeMVar to readMVar in doNothing and everything is working fine now. Sorry for the noise, Olivier. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FunPtr stability - suggested clarification to FFI Addendum
Hi, I think the FFI Addendum should make explicit that FunPtr values are stable (in the sense of StablePtr). I'm writing a Haskell plugin for an application written in C, and the control flow is: C-Haskell-C ; C-Haskell-C ; ... and I was confused by this statement in section 4.1 of the Addendum (under the subheading Dynamic wrapper): --8-- The stub factory mkCallback turns any Haskell computation of type IO () into a C function pointer that can be passed to C routines, which can call back into the Haskell context by invoking the referenced function. --8-- The usage of call back makes it clear that this control flow is ok: Haskell-C-Haskell but I wasn't sure whether the C code could store the pointer and call it later. Apparently it is safe, but it isn't made explicit in the Addendum. As SamB said in #haskell: --8-- The fact that there is something called freeHaskellFunPtr seems to indicate that, yes, those things are stable. It would be totally bonkers to have a free function if the associated memory was not stable (and, therefor, garbage collected). --8-- Thanks for your attention, Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implementing Mathematica
You have brought up prolog, unification, etc .. and knowing this is the Haskell board, just wondering what anyones thoughts on the hybrid haskell based language CURRY, for these kind of problems. It seems that it's development is stalled... and sorry ahead of time if I am wrong on that point. In a previous life, I was a logic programming zealot, and looked at curry. As far as I was concerned, it shared a significant problem with most logic programming work: the designers had a bit of a slack attitude to semantics. The key problem was that it had non-deterministic functions so you could write (haskell syntax): main = do if f 42 /= f 42 then putStr Look ma, no referential transparency\n else return () and expect the putStr could get executed. For reference, it's not a problem in Prolog (if you overlook IO being done with side effects ;-)) because the variables are explicit, and not just a notational convenience as they are in lambda calculus: main :- f(42,X), f(42,Y), cheers, T. -- Dr Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] dangerous inlinePerformIO in Data.Binary(?)
Greetings, I was trying to understand the magic inside Data.Binary, and found two somewhat suspicious uses of inlinePerformIO, which imho has a far too innocuous name: | toLazyByteString :: Builder - L.ByteString | toLazyByteString m = S.LPS $ inlinePerformIO $ do | buf - newBuffer defaultSize | return (runBuilder (m `append` flush) (const []) buf) Why is this safe? Considering the GHC implementation of IO, isn't there a real danger that 'newBuffer defaultSize' is floated out and therefore every invocation of 'toLazyByteString' starts out with the same buffer? Isn't that exactly the reason why unsafePerformIO and runST are declared NOINLINE? The other occurence is: | unsafeLiftIO :: (Buffer - IO Buffer) - Builder | unsafeLiftIO f = Builder $ \ k buf - inlinePerformIO $ do | buf' - f buf | return (k buf') which might be safe, since 'f buf' cannot float out of the lambda which binds 'buf', but still, all this stuff is inlined, something constant might get plugged in the place of buf and the result might be floated out to give us an even harder to find Heisenbug. Am I missing something and this is actually safe? If not, what can be done to avoid such errors? I'd really hate to find building blocks that crumble under pressure in standard libraries... -Udo signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] embedded build language?
Has anyone embedded a build language in Haskell? Something like Rakehttp://rake.rubyforge.org/is to Ruby, but in Haskell or any statically-typed functional language. Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] embedded build language?
Greg Fitzgerald wrote: Has anyone embedded a build language in Haskell? Something like Rake http://rake.rubyforge.org/ is to Ruby, but in Haskell or any statically-typed functional language. The closest I've seen is a tiny snippet from a blog posting: http://ashish.typepad.com/ashishs_niti/2007/06/another_dsl_emb.html b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] advice on GADT type witnesses needed
Hi all, Jason and I have been working on getting GADT type witnesses into darcs, and have run into a puzzling error. For the life of me, I can't see how this is an actual error, to the point that I'm wondering if it's actually a bug in ghc. You can check out the code and reproduce this with darcs get http://physics.oregonstate.edu/~roundyd/darcs-gadts cd darcs-gadts autoconf ./configure --with-type-witnesses make darcs At this point ghc will compile for a bit. It shouldn't get past Viewing, since we haven't converted over much of the code yet, but it fails inexplicably on Show. The error message we get is: ghc -DPACKAGE_NAME=\darcs\ -DPACKAGE_TARNAME=\darcs\ -DPACKAGE_VERSION=\1.0.9\ -DPACKAGE_STRING=\darcs\ 1.0.9\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED] -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DGADT_WITNESSES=1 -DHAVE_TERMIO_H=1 -cpp -package regex-compat -package QuickCheck -package mtl -package parsec -package html -package unix -O -funbox-strict-fields -Wall -Werror -I. -I./src -i./src -DHAVE_CURSES -DHAVE_CURL -c src/Darcs/Patch/Show.lhs src/Darcs/Patch/Show.lhs:50:0: Quantified type variable `y' is unified with another quantified type variable `x' When trying to generalise the type inferred for `showPatch' Signature type: forall x y. Patch x y - Doc Type to generalise: Patch y y - Doc In the type signature for `showPatch' When generalising the type(s) for showPatch, showComP, showSplit, showConflicted, showNamed make: *** [src/Darcs/Patch/Show.o] Error 1 The relevant code is showPatch :: Patch C(x,y) - Doc showPatch (FP f AddFile) = showAddFile f ... showPatch (Conflicted p ps) = showConflicted p ps and the trouble comes about because of (in Core.lhs) data Patch C(x,y) where NamedP :: !PatchInfo - ![PatchInfo] - !(Patch C(x,y)) - Patch C(x,y) ... Conflicted :: Patch C(a,b) - FL Patch C(b,c) - Patch C(c,c) Still, this makes no sense to me. If any type gurus could help clarify, that would be great. Thanks! -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] found monad in a comic
well, i see sth like this: data IceCream = EmptyCone | Vanilla | Strawberry | Wasabi | ... data Hypothetical a = ... instance Monad Hypothetical where -- one Functor and two Natural Transformations: fmap :: (a - b) - (Hypothetical a - Hypothetical b) return :: a - Hypothetical a join :: Hypothetical (Hypothetical a) - Hypothetical a and this is the eye opener: knife = join! there is no unsafePerformIO-alike coreturn :: Hypothetical a - a. that belongs to CoMonads. you can actually do the same trick like in the comic in RealWorld: fmap: whatever you can do in the real world, that can be done in the Hypothetical world, too. return: into an Hypothetical world you can imagine/return everything from the real world ...even whole Hypothetical worlds (return (return Wasabi)) and world-cutting knifes (return join). join: but the knife/join will never be a .../coreturn, a bridge from any Hypothetical world into the RealWorld. that is what i call a monad. - marc P.S.: i do not understand what the others are interpreting, maybe it is too high for me to see any connection between the comic and kripke semantics, higher order physics, the different worlds we live in... for me it is just a little monad like Id without runId. Am Donnerstag, 14. Juni 2007 21:10 schrieb Albert Y. C. Lai: Andrew Coppin wrote: ...is everybody else looking at a different web page to me? *blinks* Everybody is interpreting it differently. (As usual.) I see an unsafePerformIO. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe pgpKGwNdkYH3Y.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-devel] advice on GADT type witnesses needed
On 6/14/07, David Roundy [EMAIL PROTECTED] wrote: src/Darcs/Patch/Show.lhs:50:0: Quantified type variable `y' is unified with another quantified type variable `x' When trying to generalise the type inferred for `showPatch' Signature type: forall x y. Patch x y - Doc Type to generalise: Patch y y - Doc In the type signature for `showPatch' When generalising the type(s) for showPatch, showComP, showSplit, showConflicted, showNamed make: *** [src/Darcs/Patch/Show.o] Error 1 The relevant code is showPatch :: Patch C(x,y) - Doc showPatch (FP f AddFile) = showAddFile f ... showPatch (Conflicted p ps) = showConflicted p ps and the trouble comes about because of (in Core.lhs) data Patch C(x,y) where NamedP :: !PatchInfo - ![PatchInfo] - !(Patch C(x,y)) - Patch C(x,y) ... Conflicted :: Patch C(a,b) - FL Patch C(b,c) - Patch C(c,c) I would like to add that I've tried (and failed) to construct a minimal example that demonstrates the type check failure by simulating the relevant code above. This makes me wonder if the problem is not in the obvious place(s). For anyone reading along and not understanding our use of C(x,y), that's a c pre-processor macro we've defined in gadts.h. The C stands for context. In the case of the patches above, we're annotating the type with the context for the patch; x for the context required by the patch and y for the context after applying the patch. The reason we use a macro is so that we can incrementally make this modification to the code and easily disable it at compile time since it doesn't work everywhere yet. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Darcs on Solaris x86
I was able to install the ghc binary for solaris x86, but darcs fails on configure: configure:2718: ghc -o conftest conftest.hs ld: fatal: symbol `GHC_ZCCReturnable_static_info' in file /opt/local/ lib/ghc-6.6.1/libHSrts.a(PrimOps.o): section [1] .text: size 8212: symbol (address 0x2014, size 4) lies o utside of containing section ld: fatal: library -lgmp: not found ld: fatal: File processing errors. No output written to conftest collect2: ld returned 1 exit status ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dangerous inlinePerformIO in Data.Binary(?)
On Fri, 2007-06-15 at 01:03 +0200, Udo Stenzel wrote: Greetings, I was trying to understand the magic inside Data.Binary, and found two somewhat suspicious uses of inlinePerformIO, which imho has a far too innocuous name: It's not really supposed to be a public api. We've decided to rename Data.ByteString.Base to .Internal to make that fact clearer. | toLazyByteString :: Builder - L.ByteString | toLazyByteString m = S.LPS $ inlinePerformIO $ do | buf - newBuffer defaultSize | return (runBuilder (m `append` flush) (const []) buf) Why is this safe? Considering the GHC implementation of IO, isn't there a real danger that 'newBuffer defaultSize' is floated out and therefore every invocation of 'toLazyByteString' starts out with the same buffer? Isn't that exactly the reason why unsafePerformIO and runST are declared NOINLINE? Yes, that seems very suspicious to me. The other occurence is: | unsafeLiftIO :: (Buffer - IO Buffer) - Builder | unsafeLiftIO f = Builder $ \ k buf - inlinePerformIO $ do | buf' - f buf | return (k buf') which might be safe, since 'f buf' cannot float out of the lambda which binds 'buf', but still, all this stuff is inlined, something constant might get plugged in the place of buf and the result might be floated out to give us an even harder to find Heisenbug. I think this is safe because of the continuation k. In the Builder monoid, the continuation takes the place of the IO state token that gets single threaded through everything. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dangerous inlinePerformIO in Data.Binary(?)
On Fri, Jun 15, 2007 at 06:46:11AM +0100, Duncan Coutts wrote: On Fri, 2007-06-15 at 01:03 +0200, Udo Stenzel wrote: The other occurence is: | unsafeLiftIO :: (Buffer - IO Buffer) - Builder | unsafeLiftIO f = Builder $ \ k buf - inlinePerformIO $ do | buf' - f buf | return (k buf') which might be safe, since 'f buf' cannot float out of the lambda which binds 'buf', but still, all this stuff is inlined, something constant might get plugged in the place of buf and the result might be floated out to give us an even harder to find Heisenbug. I think this is safe because of the continuation k. In the Builder monoid, the continuation takes the place of the IO state token that gets single threaded through everything. That's only safe if every function which passes an initial continuation (runBuilder etc) is NOINLINE - exactly the sort of global requirement that is far too easy to break if not documented. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
