Does anyone have any comments on the following criticism of some difficulties
with FFI, including IO, in Haskell:
http://groups.google.com/group/comp.lang.functional/msg/6d650c086b2c8a49?hl=en
In particular, is it not always possible to write IO libraries safely in
Haskell?
--
Dr Jon Harrop
Is it possible to parallelize array-based functions such as in-place quicksort
in Haskell? If so, does anyone have a working implementation?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Haskell-Cafe mailing list
On Thursday 31 May 2007 20:56:47 Andrew Coppin wrote:
> Jon Harrop wrote:
> > If you write a simple, numerically-intensive program that runs in the
> > Mathematica rewriter then its performance is about 100-1,000x slower than
> > that of a native-code compiled language like Ha
On Saturday 02 June 2007 02:45:48 Dan Piponi wrote:
> But do use the examples here:
> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/examples/R
>edBook/ They worked for me.
Great, thanks. May I just ask, does ShadowMap.hs work on your machine?
--
Dr Jon D Harrop, Flying Frog Co
On Saturday 02 June 2007 16:01:05 Dan Piponi wrote:
> On 6/1/07, Jon Harrop <[EMAIL PROTECTED]> wrote:
> > Great, thanks. May I just ask, does ShadowMap.hs work on your machine?
>
> It compiles fine. Runs imperfectly. The shadow map matrix seems to be
> off so that shadows
On Friday 08 June 2007 01:19:02 Jason Dagit wrote:
> Did you remember to do all the double buffering operations? Did you
> setup the clear color first? One thing that you have to be careful
> about with OpenGL is that you correctly manage the state of the opengl
> machine. Haskell should have a
On Tuesday 12 June 2007 18:41:34 Tomasz Zielonka wrote:
> On Sun, May 13, 2007 at 02:19:55PM +0100, Andrew Coppin wrote:
> > Writing *insanely* efficient number chrunking software requires a deep
> > understanding of the target architecture, and lots of playing with very
> > low-level constructs. A
On Saturday 16 June 2007 21:34:43 Peter Verswyvelen wrote:
> That's just my point. Although I have no practical experience with Haskell
> (besides writing a simple L-System using HOpenGL), from what I've read
> Haskell is indeed much better than typical OO languages... So it *deserves*
> an easy en
On Monday 18 June 2007 05:39:21 Derek Elkins wrote:
> Not directed at Michael Richter specifically:
>
> I don't normally say this stuff, but this discussion has drifted onto
> topics that have nothing to do with Haskell. I personally would like
> the parts unrelated to Haskell to be carried on off
On Monday 18 June 2007 17:36:25 Donn Cave wrote:
> On Mon, 18 Jun 2007, Jon Harrop wrote:
> > I don't normally drag threads back on topic, but functional reactive GUIs
> > seem to be pioneered by Haskell programmers. Can anyone explain what this
> > idea is all about?
&g
I'm not a Haskell guru but I think I can answer this...
On Tuesday 19 June 2007 19:26:20 Andrew Coppin wrote:
> In Smalltalk, there is a wide selection of collection types, all with
> different facilities and efficiency trade offs. There is bag, set, list,
> array, ordered list, dictionary, hash
On Wednesday 20 June 2007 19:42:59 Andrew Coppin wrote:
> But what kind of thing would you use a general graph for?
Connectivity in networks, being anything from computers on the internet to
atoms in a molecule.
Most graphs are best represented as sum types (and abstract references, like
identi
On Wednesday 20 June 2007 20:04:25 Andrew Coppin wrote:
> Lennart Augustsson wrote:
> > I don't think the collection type (a,b) is best thought of as a loop.
>
> True. That's a rather special type; I haven't seen anything remotely
> like it in any other language.
Are you referring to a 2-tuple/pai
Awesome stuff!
On Thursday 21 June 2007 12:36:27 Philip Armstrong wrote:
> On Thu, Jun 21, 2007 at 12:25:44PM +0100, Sebastian Sylvan wrote:
> >Try using floats for the vector, and strict fields (add a ! to the
> >fields in the data declaration).
>
> Because the optimisation page on the haskell w
On Friday 22 June 2007 19:54:16 Philip Armstrong wrote:
> On Fri, Jun 22, 2007 at 10:11:27PM +0400, Bulat Ziganshin wrote:
> >btw, *their* measurement said that ocaml is 7% faster :)
>
> Indeed. The gcc-4.0 compilied binary runs at about 15s IIRC, but it's
> still much better than 7% faster than th
On Friday 22 June 2007 16:38:18 peterv wrote:
> - Unfortunately this project won't be open source; if my first tests are
> successful, I will try to convince my employer (who wants to develop such a
> graphical language) to use Haskell for building a prototype instead of
> C#/F#/Java. Can Haskell b
On Saturday 23 June 2007 08:58:10 Philip Armstrong wrote:
> On Sat, Jun 23, 2007 at 03:28:53AM +0100, Jon Harrop wrote:
> >What architecture, platform, compiler versions and compile lines are you
> >using?
>
> 32-bit x86...
Intel or AMD?
> > http://www.ffconsultan
On Saturday 23 June 2007 08:54:11 Philip Armstrong wrote:
> On Sat, Jun 23, 2007 at 12:42:33AM +0100, Claus Reinke wrote:
> >>http://www.kantaka.co.uk/darcs/ray
> >
> >try making ray_sphere and intersect' local to intersect,
> >then drop their constant ray parameter. saves me 25%.
> >claus
>
> I se
On Saturday 23 June 2007 12:05:01 Claus Reinke wrote:
> >>>http://www.kantaka.co.uk/darcs/ray
> >>
> >>try making ray_sphere and intersect' local to intersect,
> >>then drop their constant ray parameter. saves me 25%.
> >>claus
>
> also try replacing that (foldl' intersect') with (foldr (flip inter
On Saturday 23 June 2007 13:02:54 Andrew Coppin wrote:
> Well, I altered the code, and it's *still* very short and very readable,
> and it's just as fast as the (3 pages long) C++ version. >:-D
Indeed. The performance of modern functional programming languages never
ceases to amaze me. INRIA typi
On Tuesday 26 June 2007 23:20:32 Lennart Augustsson wrote:
> If you are going to ban graphs you also need to ban web pages (the links
> for a graph, both between pages and interanlly), computer networks, maps,
> dictionaries, you name it, it has a graph structure.
Layout and rendering of web pages
On Tuesday 10 July 2007 21:02:45 Sebastian Sylvan wrote:
> While I personally think that the productivity argument should be
> enough to "make the switch", the killer-app (the app that will kill C,
> that is :-)) is concurrency. C is just not a tractable tool to program
> highly concurrent programs
On Tuesday 10 July 2007 21:19:42 Andrew Coppin wrote:
> Hugh Perkins wrote:
> > Yeah I agree with this. C# totally rocks, but threading is an
> > unsolved problem.
>
> I have repeatedly attempted to discover what C# actually is...
Take Java. Make it Windows only. Fix some mistakes. Tweak performa
On Saturday 14 July 2007 23:45:57 Derek Elkins wrote:
> Read http://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf
Wow, that is a really enlightening paper. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e
On Sunday 15 July 2007 00:31:12 Chaddaï Fouché wrote:
> The HaskellWiki repertory it under "primes" and it's at least 170
> times faster than the extra-naive sieve you used in your comparison on
> my computer... (I have some doubts on the accuracy of the benchmark
> and System.Time at this level of
I just stumbled upon this fast action 3D shooter written entirely in Haskell:
http://haskell.org/haskellwiki/Frag
After 15 minutes trying to build it I find that it segfaults. Can anyone else
get this to work?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffc
On Sunday 15 July 2007 05:00:33 Donald Bruce Stewart wrote:
> Likely depends on your OpenGL version, and possibly even graphics card.
Ok. Latest nVidia drivers with a GF7900GT. I use OpenGL a lot and everything
from the drivers onwards is working beautifully.
> It's not been updated in about a y
On Sunday 15 July 2007 05:15:52 Mark Wassell wrote:
> Builds easily and works for me with GHC 6.6.1 on widows (though). You
> need to specify a level when running it and you will get a series of
> messages about loading textures before the window appears. Does it get
> this far?
Yes. Strictly spea
On Sunday 15 July 2007 11:19:29 Hugh Perkins wrote:
> Not only does mono come close to the Microsoft .Net time, both mono and
> Microsoft .Net are faster than g++ ;-) and whack Haskell.
This should tell you that your C++ is not very good. This is several times
faster, for example:
#include
#inc
On Sunday 15 July 2007 11:39:32 Hugh Perkins wrote:
> On 7/15/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote:
> > [snip] unsafeWrite[snip]
> > [snip]unsafeRead[snip]
>
> Hi Donald, the idea is to use this for operational code, so avoiding unsafe
> operations is preferable ;-)
Then you should u
On Sunday 15 July 2007 21:57:40 Sebastian Sylvan wrote:
> OpenGL is mostly written in C, so most of the code will likely run the
> exact same bits. It's just an interface to a C library.
Benchmarking OpenGL is certainly of little to no interest. However, showing
how easily OpenGL can be interface
On Sunday 15 July 2007 21:26:49 Sebastian Sylvan wrote:
> Can you find me a list of the contests?
No. I've been staring at that site for about 15 minutes and could only find a
single challenge that was a trivial function from graph theory.
You might like this symbolic simplifier benchmark:
ht
On Tuesday 17 July 2007 14:53:20 Edward Ing wrote:
> Has anyone tried out F#?
Yes. We've been using F# for 9 months now and have several products written in
it.
> Is this a taboo subject here?
Probably. ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffcon
On Tuesday 17 July 2007 23:26:08 Hugh Perkins wrote:
> Am I the only person who finds it interesting/worrying that there are few
> to no people in the group who are ex-C# programmers. I mean, you could
> argue that C# programmers are simply too stupid to do Haskell, but ... you
> know, there is an
Anyone care to code up a Haskell implementation of this trivial interpreter
for comparison:
http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/7b1ab36f5d5cce0a/0ca59e0bfb794e07?hl=en#0ca59e0bfb794e07
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://ww
On Saturday 21 July 2007 01:41:58 Hugh Perkins wrote:
> Ok, that got the variables working.
> ...
Don't fizzle out on me now: this was just getting interesting! :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
On Monday 23 July 2007 16:57:08 Simon Marlow wrote:
> Dan Licata wrote:
> > Simon PJ and I are implementing view patterns, a way of pattern matching
> > against abstract datatypes, in GHC. Our design is described here:
> >
> > http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
> >
> > If you ha
I've heard that there are a plethora of Haskell compilers available. Which
others give performance comparable to GHC?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
_
On Thursday 26 July 2007 17:03:31 C.M.Brown wrote:
> Hi Jon,
>
> On Thu, 26 Jul 2007, Jon Harrop wrote:
> > If you have a boolean-or expression:
> >
> > a || b
> >
> > will "a" be evaluated before "b" in Haskell as it is in other
If you have a boolean-or expression:
a || b
will "a" be evaluated before "b" in Haskell as it is in other languages?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
___
Does Haskell have anything similar to OCaml's polymorphic variants?
They act as inferred sum types:
# let rec eval = function
| `Int n -> n
| `Add(f, g) -> eval f + eval g
| `Mul(f, g) -> eval f * eval g;;
val eval :
([< `Add of 'a * 'a | `Int of int | `Mul of 'a * 'a ] as 'a) -> i
I've added four progressively optimized implementations of the Haskell ray
tracer to the language comparison:
http://www.ffconsultancy.com/languages/ray_tracer/
Only the first is lazy and I haven't mentioned them in the discussion yet.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml
Is there a memory profiler for Haskell?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/ma
On Monday 30 July 2007 09:51:48 apfelmus wrote:
> Thomas Conway wrote:
> > To amuse myself while waiting for test-runs to complete, I was
> > thinking about random terrain generation. I came across a bunch of
> > nice posts by Torben Mogensen, where he describes a neat way of
> > constructing rando
On Thursday 26 July 2007 00:07:23 Josef Svenningsson wrote:
> On 7/26/07, Jon Harrop <[EMAIL PROTECTED]> wrote:
> > Does Haskell have anything similar to OCaml's polymorphic variants?
>
> No as such, but it's possible to simulate them. As always Oleg was the
&
Any suggestions for a perfect example that uniquely demonstrates the benefits
of the Haskell language compared to other languages?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e
On Tuesday 07 August 2007 21:22:00 Frank Buss wrote:
> I assume to make it fast, a good idea would be to cache some calculations...
If you want to make it fast you should be using hardware acceleration.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultanc
On Friday 10 August 2007 07:46:36 Donald Bruce Stewart wrote:
> Doesn't look too good for your assertion :(
Poor benchmark design forces the authors of the shootout to subjectively
reject or cripple submissions. In fact, counting primes and printing pi are
among the worst possible benchmark task
Suffix trees are a data structure used to search for a substring of length "m"
in a string of length "n" in O(m) time. Suffix trees can also be used for
efficient approximate searches. This data structure is of particular
importance in bioinformatics.
Does anyone have any Haskell code implemen
On Saturday 18 August 2007 19:05:04 Wouter Swierstra wrote:
> I hacked up a parallel version of Richard Bird's function pearl solver:
>
> http://www.haskell.org/sitewiki/images/1/12/SudokuWss.hs
>
> It not really optimized, but there are a few neat tricks there.
> Rather than prune the search space
On Monday 27 August 2007 09:09:17 manu wrote:
> Daniel Fischer's modifications to my original program lead to a 400 %
> speed boost !!!
> (It now runs in 22 seconds on my machine)
> He avoided unecessary calls to 'length', uses Array instead of Map,
> refactored 'search' function (details below)
>
On Monday 27 August 2007 11:54:20 you wrote:
> Am Montag, 27. August 2007 11:24 schrieb Jon Harrop:
> > You shouldn't have any problem writing a purely functional solver that is
> > faster and much shorter than Norvig's Python without having to use
> > arrays.
>
On Sunday 14 October 2007 13:31:56 Andrew Coppin wrote:
> PS. I've investigated existing APIs and I'm not seeing anything that
> looks useful. Lots of support for drawing lines and arcs and so on, but
> not for plotting individual pixels.
I highly recommend OpenGL. Even if you are just filling tex
On Friday 02 November 2007 19:03, Isaac Gouy wrote:
> It's slightly interesting that, while we're happily opining about LOCs
> and gz, no one has even tried to show that switching from LOCs to gz
> made a big difference in those "program bulk" rankings, or even
> provided a specific example that th
On Friday 02 November 2007 20:29, Isaac Gouy wrote:
> ...obviously LOC doesn't tell you anything
> about how much stuff is on each line, so it doesn't tell you about the
> amount of code that was written or the amount of code the developer can
> see whilst reading code.
Code is almost ubiquitousl
On Friday 02 November 2007 23:53, Isaac Gouy wrote:
> > > Best case you'll end up concluding that the added complexity had
> > > no adverse effect on the results.
>
> Best case would be seeing that the results were corrected against bias
> in favour of long-lines, and ranked programs in a way that
On Monday 12 November 2007 20:00, Galchin Vasili wrote:
> I am looking for (objective.. i.e. not juts FPL cheerleading) opinions as
> to why Wall Street ( http://www.janestcapital.com/) and banking are now
> using OCaml and Haskell.
They have been using OCaml and Haskell for many years now. They
On Tuesday 13 November 2007 08:41, Henning Thielemann wrote:
> On Tue, 13 Nov 2007, Jon Harrop wrote:
> > Penetration is highest in parts of industry where small groups of
> > talented programmers get together, most notably startups. Look at
> > XenSource, Wolfram Re
Following Lennart Augustsson's improvements of the Haskell implementations of
my ray tracer language comparison:
http://augustss.blogspot.com/2007/11/benchmarking-ray-tracing-haskell-vs.html
I thought I'd share the performance improvements offered by Lennart's new code
with the latest release
On Tuesday 13 November 2007 16:03, Laurent Deniau wrote:
> OCaml was used to write a meta-program which applies heuristics to
> minimize the runtime of the critical C code (i.e. the butterflies). This
> has nothing to do with FFT computation
No. The sole purpose of the OCaml code is to symbolicall
On Tuesday 13 November 2007 18:38, Tim Newsham wrote:
> > Functional programming languages are now much more widely used in
> > industry, primarily because they offer substantial productivity
> > improvements (roughly 10x) over C++ and Java and, consequently, are much
> > more cost effective.
>
> D
On Wednesday 14 November 2007 00:14, Don Stewart wrote:
> Trying out some of the great language shootout programs with ghc 6.8 is
> producing nice results. For example, our "classic" cache-hammering,
> bitwise sieve benchmark is out of the box 10% faster with the new
> compiler. The (already rather
On Wednesday 14 November 2007 10:55, luc.taesch wrote:
> do not expect it to be a lead to mass expansion for tommorow...
I think the functional programming market is far from saturated though: there
are still many inroads to make into areas like technical computing that stand
to benefit a lot fr
I'd like some free software to help me plot charts like the one from the ray
tracer language comparison:
http://www.ffconsultancy.com/languages/ray_tracer/results.html
I was using Mathematica but its stopped working and an upgrade is £2,000. Are
there Haskell bindings to any free libraries o
On Monday 19 November 2007 22:12, Don Stewart wrote:
> Check the thesis on Frag for a pure approach, or just use StateT IO.
Has Frag been fixed to work on x86-64?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
___
On Wednesday 21 November 2007 07:06, Jules Bean wrote:
> As far as I'm aware, all GL implementations come with a GLUT
> implementation.
No: GL is typically installed with your video card drivers and glut must be
installed as a separate package. On Linux, package managers handle this
transparentl
On Wednesday 21 November 2007 02:27, Conal Elliott wrote:
> Moreover, functional programming makes it easy to have much more state than
> imperative programming, namely state over *continuous* time. The
> temporally discrete time imposed by the imperative model is pretty puny in
> comparison. Cont
On Wednesday 21 November 2007 20:14, Magnus Therning wrote:
> Many other programming languages have packaging strategies that sound
> very similar. Several of them have managed to have a negative impact on
> platforms that already have good packaging technologies (i.e. almost
> every platform apar
On Friday 30 November 2007 00:31, Justin Bailey wrote:
> I represent the automata as an array of integers, where each bit
> represents a cell.
Mathematica uses a single arbitrary-precision integer to represent each
generation of a 1D automaton. The rules to derive the next generation are
compile
On Thursday 20 December 2007 19:02, Don Stewart wrote:
> Ok, so I should revive nobench then, I suspect.
>
> http://www.cse.unsw.edu.au/~dons/nobench/x86_64/results.html
>
> that kind of thing?
Many of those benchmarks look good.
However, I suggest avoiding trivially reducible problems like c
On Friday 28 December 2007 11:05:12 Andrew Coppin wrote:
> I thought Lisp and Erlang were both infinitely more
> popular and better known. Followed by Clean and O'Camal.
According to the Debian and Ubuntu package popularity figures OCaml, Haskell
and Erlang are the most popular general-purpose f
On Saturday 29 December 2007 06:09:44 Bill Wood wrote:
> On Fri, 2007-12-28 at 20:23 -0700, Luke Palmer wrote:
> > OO is orthogonal to functional. Erlang is pure functional, Lisp is a
> > bastard child...
>
> Give it its historical due, please -- bastard grandsire at least.
You'll have to speak u
On Saturday 29 December 2007 06:31:35 Miguel Mitrofanov wrote:
> >> Well, it seems for me that Erlang is much less functional than Lisp.
> >> It's totally OO, in fact.
> >
> > OO is orthogonal to functional.
>
> ? Kay's definition of OOP necessarily implies imperative behaviour.
OCaml has purely f
On Saturday 29 December 2007 07:18:28 Peter Verswyvelen wrote:
> Jon Harrop wrote:
> > However, both F# and Scala have the potential to dwarf all of these
> > languages in the not-so-distant future. I believe F# will do so in 2008
> > but Scala will take 2-3 years becaus
On Monday 07 January 2008 20:27:17 Peter Verswyvelen wrote:
> If your compiler (pretty amazing job btw) does whole program optimization,
> can it remove the dictionary (aka v-table in C/C++ parlance?) overhead of
> type classes? Because if I understand it correctly, unless one uses
> existential ty
Is it possible to get throwback of inferred types into Emacs or an IDE for
Haskell?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org
On Saturday 19 January 2008 18:11:13 Peter Verswyvelen wrote:
> I would find it most useful to get type inference information on the fly,
> even when not all of the code compiles correctly yet.
Yes. Is this not provided by any development environments then?
--
Dr Jon D Harrop, Flying Frog Consul
On Sunday 20 January 2008 21:02:04 [EMAIL PROTECTED] wrote:
> On 2008.01.19 19:11:13 +0100, Peter Verswyvelen <[EMAIL PROTECTED]> scribbled
1.4K characters:
> > I would find it most useful to get type inference information on the fly,
> > even when not all of the code compiles correctly yet.
>
> D
I'd like to compare the performance of Parsec to other parsers but the only
reference to a benchmark I have found is a dead link from one of the papers
about Parsec:
http://research.microsoft.com/users/daan/download/parsec/parsec.pdf
Are there any surviving Parsec benchmarks?
--
Dr Jon D H
On Sunday 20 January 2008 22:06:04 Duncan Coutts wrote:
> On Sun, 2008-01-20 at 21:02 +0000, Jon Harrop wrote:
> > On Sunday 20 January 2008 21:02:04 [EMAIL PROTECTED] wrote:
> > > On 2008.01.19 19:11:13 +0100, Peter Verswyvelen <[EMAIL PROTECTED]>
> > >
On Tuesday 22 January 2008 14:30:22 Bryan O'Sullivan wrote:
> Paul Moore wrote:
> > I'm posting here because there doesn't seem to be an "overall" comment
> > section, but the TOC seems to cover less ground than I expected. Is
> > the TOC meant to be complete?
>
> No, it's less than a third of the
On Friday 25 January 2008 03:30:03 Paulo Tanimoto wrote:
> But I must say I don't have much practical experience with them
> myself. Mostly reading other people's work.
Me too. I have read that EC is competitive when the fitness function is
riddled with discontinuities though, so it may still be
Has anyone written anything on the use of FP (e.g. point free style) in linear
algebra problems?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://ww
r capabilities to those already available for free to OCaml
users.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
ndations makes pens (an
encapsulation of the color and width of a line) thread unsafe for no reason
whatsoever which goes a long way to undermining the reliability of GUI code.
At least in the case of OCaml, my impression is that the libraries are far
better designed and, consequently, much
d is getting improved support for dynamic and functional
> languages (method handles, tail call).
The JVM has been about to get basic features like tail calls for several years
now.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffcon
't optimize away the tuple allocation)...
That is incorrect. OCaml does optimize away that tuple: both forms compile to
the same 2-argument function.
OCaml does not optimize away this tuple:
let a, b = 1, 2
So, when efficiency is important, you write:
let a = 1 and b = 2
--
Dr Jon Har
gt; choice at runtime, which makes it much easier.
Is anyone developing a JIT Haskell compiler? The approach has many important
practical benefits and tools like LLVM are a joy to use...
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffc
On Saturday 27 June 2009 18:31:25 Günther Schmidt wrote:
> Hi guys,
>
> is there a mailing list for haskellers that defected to F#?
Here's the F# mailing list on Google Groups:
http://groups.google.com/group/fsharp?hl=en
--
Dr Jon Harrop, Flying Frog Consult
nstead of O(1), so
> I don't think you can break the log n for really large lists this
> way since the key length increases as well (unless most elements are
> equal anyway).
Use a trie of hash tables with ~word-sized pieces of key.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http:/
.
And your results above indicate that the fastest imperative heap is over 3x
faster than the fastest functional heap?
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Friday 25 December 2009 06:09:55 Matt Morrow wrote:
> On 12/23/09, Jon Harrop wrote:
> > And your results above indicate that the fastest imperative heap is over
> > 3x faster than the fastest functional heap?
>
> It's saying that
>
> (1) Using an imprecis
on in
> asymptotically optimal time...
You're assuming he meant asymptotic time complexity.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
nk replaces the unevaluated expression with the
value it evaluates to. That is effectively in-place mutation.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://
On Monday 28 December 2009 18:04:32 Gautam bt wrote:
> On Tue, Dec 29, 2009 at 12:04 AM, Jon Harrop wrote:
> > Forcing the evaluating of a thunk replaces the unevaluated expression
> > with the value it evaluates to. That is effectively in-place mutation.
>
> How can on
om source fixed 6.10. Now I seem to
be able to compile with 6.10 and programs run without segfaulting (but not
6.8 or 6.12). I never managed to get cabal to work though...
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
__
I felt the previous comparison left a little to be desired so I have repeated
the experiment on 8 cores using the original Haskell code and giving results
for 9, 12 and 13 levels of spheres:
http://flyingfrogblog.blogspot.com/2010/01/naive-parallelization-c-vs-haskell.html
--
Dr Jon Harrop
On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
> Actually, your solution with arrays is the most often occured solution
> an imperative programmer will come with. It is simple but not scalable
> and not particularly fast.
What gave you that impression?
--
Dr Jon Harrop, Fl
On Tuesday 02 February 2010 18:23:59 Serguey Zefirov wrote:
> 2010/2/2 Jon Harrop :
> > On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote:
> >> Actually, your solution with arrays is the most often occured solution
> >> an imperative programmer will come
ster than using Map or Set but you're still paying a lot
for the indirections between cons cells. Mutating an array in-place would be
significantly faster and no more difficult to code correctly because this is
such a trivial algorithm.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://ww
1 - 100 of 123 matches
Mail list logo
