[Haskell-cafe] resources on static analysis
Dear list, I am interested in learning more about static analysis of Haskell code. Specifically of the relation between arguments of recursive and non-recursive calls. For example if we look at the ++ function from Prelude: (++) [] ys = ys (++) (x:xs) ys = x : xs ++ ys amongst others, we could infer the relations: ys_i+1 = ys_i (x:xs)_i+1 = xs_i Searching the web I found several tools (HLint, Haskabelle, Sourcegraph), but I am interested in the theory behind this. If you could recommend a paper or a book on this topic I would be grateful. Thanks, Maarten Faddegon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] pattern matching vs if-then-else
Hi there, I am writing a toy compiler in Haskell to further my skills in functional programming. One of the functions I wrote is to determine the iteration count of a loop. I have a number of different test that I want to do and I find myself now testing some of these using pattern matching and some properties using an if-then-else construction. I do not consider this very pretty. My question is: are there guidelines of when to use pattern matching and when to use if-then-else? Snippet of the function I mentioned: ---8<--- itercount (ForLoop [ ( Assignment update_lcv (Op2 "+" (Content update_lcv') update_expr) ) ] [(Assignment init_lcv init_expr)] (TestStmt (Op2 "<" (Content test_lcv) test_expr)) bodyblock) = if-- All stmts use the same lcv test_lcv == init_lcv && test_lcv == update_lcv && test_lcv == update_lcv' -- And the lcv is not updated in the body && intersect [test_lcv] (blockkills bodyblock) == [] then Just $ simple_itercount init_expr test_expr update_expr else Nothing itercount _ = Nothing ---8<------- Thanks, Maarten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic Reference Counting
On 2 Jul 2011, at 18:35, Thomas Davie wrote: > > It's interesting that you cite that GC is both faster and lower memory > overhead – Apple's stated reasons for implementing this were that GC was both > too slow and too memory intensive to use sensibly on iDevices and that ARC > was both faster and less memory intensive. Reality is probably a little more subtle than this. In general, and specifically for long-running and memory intensive processes (such as used in servers), quality garbage collection (and especially compacting garbage collection) are probably more efficient overall. Apple already supported (and continues to support) garbage collection for Objective-C in their desktop systems. The primary motivation (as I understand it) for developing ARC is to bring (mostly) automatic memory management to the iOS platforms. There are 2 reasons that I've heard why Apple considers ARC a superior solution for the iOS platform: 1. iOS devices are much more resource constrained than a desktop system. Therefore the delay that garbage collection causes before memory is available for re-allocation can have a much greater effects on application. 2. Running a background garbage collector can introduce unpredictable pauses in your application, which would destroy the illusion of immediacy that is one of the prime characteristics of good iOS apps. So for iOS immediate memory release and predictable performance trumps overall average performance. To see if this technique would be at all useful for Haskell, you'll have to evaluate these points in the context of a Haskell application and decide which trade-off brings you the most benefit. Maarten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Computer Graphics and Haskell - Radiosity Methods
> 2010/3/1 Hector Guilarte : >> Hello cafe, >> While I was studying for my computer graphics test I have tomorrow I >> realized that maybe some of the major problems I've read so far about >> Radiosity Rendering Algorithms may be reduced significantly if it was >> implemented in Haskell and taking advantage of the lazy evaluation so that >> only what can be seen from the viewer's perspective point of view is >> calculated, and the rest of the scene just remains as thunks waiting for >> them to be calculated in case they are needed. The way radiosity works, those invisible parts of the scene can still add illumination to the visible parts. So the first time you query the radiosity data for any part of the scene, you'll end up forcing the calculation of the entire radiosity solution. That's basically the difference between plain raytracing, which is lazy in that way and works backwards from the viewer's perspective, and radiosity. Maarten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell on JVM
On 26 Jun 2009, at 14:09, Timo B. Hübel wrote: And here comes my question: If there is anybody with proper knowledge about this issue, I would really like to know what are those things that are missing? For example, Clojure lacks proper tail recrusion optimization due to some missing functionality in the JVM. But does anybody know the details? Basically, the JVM lacks a native ability to do tail calls. It does not have an instruction to remove/replace a stack frame without executing an actual return to the calling method/function. With the heavy use of recursion in functional programs, this is an important feature in a language implementation to avoid stack overflows. Some language implementations (Scala) can do partial workarounds by turning the generated code into a loop in the compiler, but this is frequently limited to only deal with self-recursive calls, and does not deal with the general case (X-calls-Y-calls-Z-calls-X...), which a proper implementation of tail- calls at the JVM level would allow. At the JIT level (below the JVM spec level) some implementations may actually do the tail call optimization anyway, but this is beyond the control of a language implementation, and would result in a situation where the behaviour of your program depends on particular implementations/versions/parameters of the JVM running it. That is something to be avoided if possible. Maarten Hazewinkel maarten.hazewin...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thread priority?
Hi all, Some two year I wrote a library to change thread priorities in Windows, including another library that allows real time processing. With this you can play midi files real time and without interruption from the OS. (Manipulating thread priorities is really easy in Windows, real time uninterrupted processing a little more complicated). Actually, I thought this problem was already resolved (haskore-realtime), but if there is interest I can see if I can dust them off, although I'm sure there will be still lots of things to improve. Right now I'm working in linux only, so it may take a few days to get a suitable xp version. (Actually, I would be really interested in a linux port, but have little time right now. Perhaps this library can help: http://sourceforge.net/projects/high-res-timers ?) Kind regards, Maarten Christopher Lane Hinson wrote: Is there any interest or movement in developing thread priority or any other realtime support in Haskell? Right now, if I have tasks that need to be responsive in real time, even if the realtime needs are very soft, it seems that the only option is to try to ensure that at least one hardware thread is kept clear of any other activity. To be very useful to me, thread priority would not need to come with very strict guarantees, but there would need to be a way to make sure that `par` sparks and DPH inherit the priority of the sparking thread. In part I ask because I'm working on a small library to support a degree of cooperative task prioritization. Friendly, --Lane ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Marketing Haskell
That's not you usual Koala face. Must be a special Simon^H^H^H^H^HHaskell-Koala species. <> On 1 Apr 2009, at 10:07, Simon Peyton-Jones wrote: Dear Haskell enthusiasts, Now that the logo issue finally has been settled, it is time to select the proper Haskell mascot. As you are no doubt aware, Microsoft's involvement in Haskell means that we have moved from avoiding success at all cost to actively marketing the language, and any language striving for success is entirely dependent on a cute and distinctive mascot. Where would Perl be today without its camel? Since the recent logo discussion has demonstrated once and for all the futility of attempting a democratic process in the Haskell community - to be quite honest, the elected logo looks like an error message from an IBM mainframe - I have decided to decide on a mascot myself. So I hereby declare the official Haskell mascot to be the koala, in the form of the image attached below. Please ensure that this image accompanies any material published on the web or on paper. Simon ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell Maarten Hazewinkel maarten.hazewin...@gmail.com Tel: 06-53 692 432 (+31-653 692 432 from outside the Netherlands) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Android
On 25 Sep 2008, at 13:33, Adam Langley wrote: A Google search for "haskell java" turns up at least one good candidate[1], but if you manage to get that working well, binding the APIs is a rather trivial task ;) [1] http://www.cse.unsw.edu.au/~pls/thesis-topics/ghcjava.html That's actually just a thesis proposal, not actual work done. Try this for something closer to realization: http://www.cs.rit.edu/~bja8464/lambdavm/ Regards, Maarten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can you do everything without shared-memory concurrency?
On 10 Sep 2008, at 20:28, Ryan Ingram wrote: On Wed, Sep 10, 2008 at 2:55 AM, Maarten Hazewinkel <[EMAIL PROTECTED]> wrote: [on transaction failures in databases and STM] This seems to be a bit too much F.U.D. for STM. As long as you avoid unsafeIOToSTM (which you really should; that function is far more evil than unsafePerformIO), the only failure case for current Haskell STM is starvation; some thread will always be making progress and you do not have to explicitly handle failure. This is absolutely guaranteed by the semantics of STM: no effects are visible from a retrying transaction--it just runs again from the start. You don't have to write "proper error handling" code for transactional updates failing. Thanks for the clarification Ryan. As a hobbyist I haven't actually used STM, so I was grouping it with databases as the only transactional system I am directly familiar with. I suppose I could have guessed that the Haskell community would come up with something that's a class better than a normal shared database. Regards, Maarten Hazewinkel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can you do everything without shared-memory concurrency?
Hi Bruce, Some comments from an 11 year Java professional and occasional Haskell hobbyist. On 9 Sep 2008, at 20:30, Bruce Eckel wrote: So this is the kind of problem I keep running into. There will seem to be consensus that you can do everything with isolated processes message passing (and note here that I include Actors in this scenario even if their mechanism is more complex). And then someone will pipe up and say "well, of course, you have to have threads" and the argument is usually "for efficiency." One important distinction to make, which can make a lot of difference in performance, is that shared memory itself is not a problem. It's when multiple threads/processes can update a single shared area that you get into trouble. A single updating thread is OK as long as other threads don't depend on instant propagation of the update or on an update being visible to all other threads at the exact same time. I make two observations here which I'd like comments on: 1) What good is more efficiency if the majority of programmers can never get it right? My position: if a programmer has to explicitly synchronize anywhere in the program, they'll get it wrong. This of course is a point of contention; I've met a number of people who say "well, I know you don't believe it, but *I* can write successful threaded programs." I used to think that, too. But now I think it's just a learning phase, and you aren't a reliable thread programmer until you say "it's impossible to get right" (yes, a conundrum). In general I agree. I'm (in all modesty) the best multi-thread programmer I've ever met, and even if you were to get it right, the next requirements change tends to hit your house of cards with a large bucket of water. And never mind trying to explain the design to other developers. I currently maintain a critical multi-threaded component (inherited from another developer who left), and my comment on the design is "I cannot even properly explain it to myself, let alone someone else". Which is why I have a new design based on java.util.concurrent queues on the table. 2) What if you have lots of processors? Does that change the picture any? That is, if you use isolated processes with message passing and you have as many processors as you want, do you still think you need shared-memory threading? In such a setup I think you usually don't have directly shared memory at the hardware level, so the processors themselves have to use message passing to access shared data structures. Which IMHO means that you might as well design your software that way too. A comment on the issue of serialization -- note that any time you need to protect shared memory, you use some form of serialization. Even optimistic methods guarantee serialization, even if it happens after the memory is corrupted, by backing up to the uncorrupted state. The effect is the same; only one thread can access the shared state at a time. And a further note on sharing memory via a transactional resource (be it STM, a database or a single controlling thread). This situation always introduces the possibility that your update fails, and a lot of client code is not designed to deal with that. The most common pattern I see in database access code is to log the exception and continue as if nothing happened. The proper error handling only gets added in after a major screwup in production happens, and the usually only the the particular part of the code where it went wrong this time. Kind regards, Maarten Hazewinkel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
On 23 Aug 2008, at 23:10, Tim Newsham wrote: I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying "we can give you programs that never segfault", instead of "we have a strong type system". By the way, the Java camp has (correctly) been touting this argument for quite a while. As a day-time java programmer, I can say from experience that sometimes (100% pure) Java programs DO segfault. I've had it happen to me, and while you can justifiably say it's an error in the JVM somehow triggered by your program behaviour/timing, that doesn't help you very much at the time. Maarten Hazewinkel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why functional programming matters
On 24 Jan 2008, at 10:45, Peter Hercek wrote: * safe STM ... and probably a lot of more goodies Especially STM would be a good point to elaborate on. Most big systems have issues around concurrency and state modification being broken. Anything that can reliably solve that problem is going to interest serious programmers. Maarten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] submenu doesn't seem to work properly in wxhaskell
Dear all, The following code doesn't seem to work properly. Either the main entry (m1/mp1) or it's sub menu entry (ms1/mps1) do not seem to propagate the event when pressed. It is possible to make it working by uncomments the lines where the menu commands are registered in the frame. I have the following two questions: 1. Why doesn't the plain code work. Am I missing something or doing something wrong? 2. Doesn't registering eventhandlers in the frame introduce a memory/resource leak, especially in the case of popups? Any suggestions or comments appreciated. Thanks. Kind regards, Maarten Code: gui :: IO () gui = do f <- frame [ text := "Hello world!" ] m <- menuPane [ text := "&Menu" ] m1 <- menuItem m [ text := "Menu m1", on command := putStrLn "menu m1"] -- set f [ on (menu m1) := putStrLn "menu m1" ] menuLine m sub <- menuPane [text := "Sub menu"] ms1 <- menuItem sub [ text := "submenu ms1", on command := putStrLn "submenu ms1" ] -- set f [ on (menu ms1) := putStrLn "submenu ms1" ] menuSub m sub [ text := "Sub" ] menuItem m [text := "E&xit", on command := close f] set f [menuBar := [m], on mouse := mouseEvent f, clientSize := sz 200 200 ] return () mouseEvent f eventMouse = do case eventMouse of MouseRightDown mousePoint _ -> doPopup f mousePoint _ -> return () doPopup f mousePoint = do m <- makePopupMenu f "&Popup" "Doesnt' work..." menuPopup m mousePoint f objectDelete m makePopupMenu f c t = do mp <- menuPane [ text := c ] mp1 <- menuItem mp [ text := "Popup mp1", on command := putStrLn "popup mp1"] -- set f [ on (menu mp1) := putStrLn "popup mp1" ] menuLine mp sub <- menuPane [text := "more text"] mps1 <- menuItem sub [ text := "Popup mps1", on command := putStrLn "popup mps1"] menuSub mp sub [ text := "Sub" ] -- set f [ on (menu mps1) := putStrLn "popup mps1" ] return mp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ambiguous partially defined type problem
Dear Brian,
Maarten wrote:
Brian Hulley wrote:
Alternatively, you could wrap the custom part within the node as in:
data Node = forall cust. ICustom cust => Node cust Common
getCommon :: Node -> Common
getCommon (Node cust com) = com
Thanks. This really helped. The main thing (I think) that you put the
custom part behind an interface. After this I separated the custom and
common part of two 'piggy bagged' state transformers, so one can access
the functionality separately. The state transformers made into active
object by putting them behind a channel in a separate thread and one can
invoke actions by writing to the channel. The common functionality
provides the connections between the active objects. In this way I would
like to create some sort of 'agent' structure, that receive message and
process them in their own thread. So far this works quite neat. Wonder
if this is they way to go though...
Only update (see code below) is a bit ugly (I have no idea why I need
fixCastUpdate) and Node itself is probably not necessary, so one level
of indirection could be removed. Rest is quite straight forward.
Thanks again.
Maarten
... (imports)
data Node = forall cust. (ICustom cust) => Node cust
deriving (Typeable)
instance Show Node where-- just for debugging
show (Node a) = "Node (" ++ show a ++ ")"
class (Show a, Typeable a) => ICustom a where
getVal :: forall b cust. (Typeable b, ICustom cust) => a -> (cust ->
b) -> Maybe b
getVal a f = case cast a of
Nothing -> Nothing
Just cust -> Just (f cust)
--update :: oif -> (forall a. (ObjectIFace a) => a -> a) -> IO oif
update :: a -> (forall b. (ICustom b) => b -> b) -> a
update a f = f a
instance ICustom Node where
getVal (Node n) f = getVal n f
update (Node n) f = Node (update n f)
type NodeState a = StateT Node (StateT Common IO) a
type Connection = Chan (NodeState ())
type Connections = [Connection]
instance Show Connection where
show o = "Chan (StateT Node (StateT Common IO) ())"
-- common part
data Common = Common { uid::Integer, connections::Connections }
deriving (Show,Typeable)
-- custom data
data Custom = Custom { val::Integer }
deriving (Show,Typeable)
instance ICustom Custom where
data Custom2 = Custom2 { val2::Integer }
deriving (Show,Typeable)
instance ICustom Custom2 where
-- some function to use common functionality
uidM :: NodeState Integer
uidM = lift $ gets uid
addNodeM :: Connection -> NodeState ()
addNodeM n = lift $ modify (\s -> addNode s n)
where
addNode (Common i ns) nn = (Common i (nn:ns))
getNodeM :: Integer -> NodeState Connection
getNodeM i = do
s <- lift $ get
return (getNode s i)
where
getNode (Common _ ns) i = (ns!!(fromInteger i))
getValM f = do
s <- get
return (getVal s f)
updateM :: forall a b. (ICustom a, ICustom b) => (a -> b) -> NodeState ()
updateM f = do
s <- get
let s' = update s (fixCastUpdate f)
put s'
fixCastUpdate f st =
case (cast st) of
Nothing -> st
Just es -> case cast (f es) of
Nothing -> st
Just g -> g
getStateM = get
-- function to create active node functionality
action [] = return ()
action (e:es) = do
e
s <- get-- just for debugging
lift $ lift $ putStrLn $ show s
action es
newBaseState = do
uid <- newUnique
return (Common ((toInteger .hashUnique) uid) [])
initAction list state = do
bs <- newBaseState
execStateT (execStateT (action list) state) bs
return ()
send chan action = writeChan chan action
sync chan f = do
mv <- newEmptyMVar
send chan (f' mv)
a <- takeMVar mv
return a
where
f' mv = do
a <- f
lift $ lift $ putMVar mv a
newActiveObject action state = do
chan <- newChan
cs <- getChanContents chan
forkIO (action cs state)
return chan
-- example
main = do
let n1 = Node (Custom 5)
let n2 = Node (Custom2 6)
let n3 = Node (Custom2 7)
chan <- newActiveObject initAction n1
chan2 <- newActiveObject initAction n3
let l = [chan, chan2]
mapM_ (\ch -> send ch (addNodeM chan)) l
mapM_ (\ch -> send ch (addNodeM chan2)) l
r <- mapM (\ch -> sync ch (getNodeM 0)) l
putStrLn $ "r:" ++ show r
r2 <- mapM (\ch -> sync ch (uidM)) l
putStrLn $ "r2:" ++ show r2
r3 <- mapM (\ch -> sync ch (getValM val)) l
putStrLn $ "r3:" ++ show r3
mapM_ (\ch -> send ch (updateM (\s -> s { val2 = 100 }))) l
r5 <- mapM (\ch -> sync ch (getStateM)) l
putStrLn $ "r5:" ++ show r5
getChar
return ()
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ambiguous partially defined type problem
Dear all,
For a project involving I use some partially defined node (in this case
a simple record, in my project state transformers) in which the defined
part is common to all nodes, and the custom part is different for each
node. They have to become anonymous so I can put them in a list of
connections from each node to another.
For some reason GHC complains of 'ambigous type variable' in the code
below. The thing is, part of the code may be undefined, but since I'm
(explicitly) not using that part, why would GHC care? Are there other
solutions to this problem? Any pointers or comments appreciated. Thanks.
Maarten
(This code is just some dummy code that contains the essence of the
problem. I posted the complete code with piggy bagged state transformers
in active objects on haskell@haskell.org, but that is rather long and
this seems to be the correct mailing list).
-- data structure with custom and common part
data Node cust = Node cust Common
deriving (Show,Typeable)
-- anonymous data structure to put use in list
data AN = forall ar. (Show ar, Typeable ar) => AN ar
instance Show AN where
show (AN an) = "AN (" ++ show an ++ ")"
-- common part
data Common = Common Integer
deriving (Show,Typeable)
data Custom = Custom Integer
deriving (Show,Typeable)
data Custom2 = Custom2 Integer
deriving (Show,Typeable)
-- extract common part, ignoring type of custom part
getCommon :: forall gc. (Node gc) -> Common
getCommon (Node cust com) = com
main = do
let a = AN (Node (Custom 5) (Common 10))
let b = case a of (AN a') -> getCommon (case (cast a') of Just a''
-> a'')
putStrLn $ "ok:" ++ show b
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The History of Haskell
Simon and partners, Thank you for this paper. As a relative newcomer to Haskell, quite few topics on the mailing lists went right past me. Now that I've read this paper a can at least understand generally what most topics are about. I'd definitely recommend this as reading material to anyone right after they know a bit about the basic language from a tutorial. It helps place the basic Haskell language in both its historical context, and in the current Haskell universe with its miriad extensions and tools. Thanks again, Maarten On 7/14/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: Friends, Phil Wadler, John Hughes, Paul Hudak and I have been writing a paper about the The History of Haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: Re[2]: [Haskell-cafe] EclipseFP (Haskell IDE) 0.10.0 released
On 7/3/06, Thiago Arrais <[EMAIL PROTECTED]> wrote: EclipseFP is being written in Java, I wonder how the GHC library would be accessed on such a environment. The York Haskell Compiler (yhc) compiles to bytecode, and my memory suggests that there was an implementation of the required runtime system written in Java. My mail archive confirms this: Neil Mitchell wrote about it on haskell-cafe on March 28 under the topic of 'Haskell's Market'. My feeling is that such an approach might be a smoother (and more portable) integration than JNI. Of course, you'd need to be able compile GHC with YHC, which I cannot guess the feasability of. HTH, Maarten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prime numbers
Daniel, Could it be that the arguments to either divides or mod should be reversed? Currently it seems to be testing whether the candidate prime (n) divides the possible factor (m). Or am I to tired to read the code straight? Regards, Maarten On 12/20/05, Daniel Carrera <[EMAIL PROTECTED]> wrote: > John Peterson wrote: > > Add a type signature: > > > > prime :: Integer -> Bool > > > > It's defaulting to Int and you're getting overflows > > Thanks. Hmm... it's still not working. > > Btw, I mis-reported the problem. The offending number is 38466629, which > is /not/ prime but the sample program reports as prime. > > 38466629 = 31 * 1240859 > > The offending program is: > --//-- > prime :: Integer -> Bool > prime n = not (factors 2 n) > > factors :: Integer -> Integer -> Bool > factors m n | m == n = False > | m < n = divides m n || factors (m+1) n > > divides :: Integer -> Integer -> Bool > divides a b = (mod a b == 0) > --//-- > > The math behind the program seems correct... :( > > Cheers, > Daniel. > > > > -- > /\/`) http://oooauthors.org > /\/_/ http://opendocumentfellowship.org > /\/_/ > \/_/I am not over-weight, I am under-tall. > / > ___ > 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] STM and `orElse` on a few thousand TMVars
On 12/6/05, Joel Reymont <[EMAIL PROTECTED]> wrote: > I'm trying to implement a better waitForChildren from the docs for > Control.Concurrent. > > I would like to know when all the children exit, basically, and I > thought it would be neat to try to do that with STM. I apologise if this doesn't make sense (I'm fairly new to Haskell), but wouldn't a single shared counter be sufficient for this? Increment for each child launched. Decrement by each finished child. When it's back down to zero, you're done. Regards, Maarten ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
