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 hector...@gmail.com: 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
[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. inline: haskell-mascot.jpg 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-mascot.jpg___ 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?
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] 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] 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
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
