Re: [Haskell-cafe] In-place modification
Sebastian Sylvan wrote: On 10/07/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: Hint: If you can get readable/maintainable Haskell to run on more than one core "automatically", you're onto something pretty special. ;-) Soon, have a little patience :-) See for example: http://research.microsoft.com/~simonpj/papers/ndp/NdpSlides.pdf http://research.microsoft.com/~tharris/papers/2007-fdip.pdf Mmm... it'll be damn good if any of this ever actually happens. But until then... heh. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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: http://www.lambdassociates.org/studies/study10.htm The OCaml program is simply: let rec ( +: ) f g = match f, g with | `Int n, `Int m -> `Int (n +/ m) | `Int (Int 0), e | e, `Int (Int 0) -> e | f, `Add(g, h) -> f +: g +: h | f, g -> `Add(f, g) let rec ( *: ) f g = match f, g with | `Int n, `Int m -> `Int (n */ m) | `Int (Int 0), e | e, `Int (Int 0) -> `Int (Int 0) | `Int (Int 1), e | e, `Int (Int 1) -> e | f, `Mul(g, h) -> f *: g *: h | f, g -> `Mul(f, g) let rec simplify = function | `Int _ | `Var _ as f -> f | `Add (f, g) -> simplify f +: simplify g | `Mul (f, g) -> simplify f *: simplify g -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hugh Perkins wrote: > On 7/15/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > [Lots of stuff] Can we stop this rubbish before I unsubscribe? Seriously, get a clue before propagating nonsense across the mail clients of a large audience. "Just ignore the rubbish and the rubbish will go away" usually works for me, but it isn't in this case. How about we all try it at once? Tony Morris http://tmorris.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFGmqh9mnpgrYe6r60RAlS+AJ9jIQ+MPwV2oL+vzmeHLXisH3mMtQCY+zXt CAvanZ6el/x3Ja449AKM2Q== =mX2J -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Sun, 2007-07-15 at 23:05 +0100, Jon Harrop wrote: > 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 interfaced to is of huge interest to me. Functional > languages tend to have very poor FFIs, so I for one would like to see whether > or not non-trivial graphical programs can be written in Haskell. > > I was amazed to find that Frag corrupts memory in 64-bit, for example. Why > are > there malloc calls in a Haskell program?! > Because Haskell has a very nice FFI and the Haskell philosophy is to try to do as much on the Haskell-side as possible. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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 interfaced to is of huge interest to me. Functional languages tend to have very poor FFIs, so I for one would like to see whether or not non-trivial graphical programs can be written in Haskell. I was amazed to find that Frag corrupts memory in 64-bit, for example. Why are there malloc calls in a Haskell program?! -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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 use bounds checked access in C++. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 7/15/07, Jon Harrop <[EMAIL PROTECTED]> wrote: This should tell you that your C++ is not very good. This is several times faster, for example: For some reason you were using C-style allocation rather than the C++ STL to implement a bit vector. The STL implementation is optimized. Yes good point. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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
#include
#include
using namespace std;
int CalculateNumberOfPrimes(int maxprime)
{
vector NotPrime(maxprime+1);
int NumberOfPrimes = 0;
for (int i = 2; i <= maxprime; i++ )
if (!NotPrime[i])
{
++NumberOfPrimes;
for (int j = 2*i; j <= maxprime; j += i)
if (!NotPrime[j]) NotPrime[j] = true;
}
return NumberOfPrimes;
}
For some reason you were using C-style allocation rather than the C++ STL to
implement a bit vector. The STL implementation is optimized.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The OCaml Journal
http://www.ffconsultancy.com/products/ocaml_journal/?e
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Sun, Jul 15, 2007 at 03:39:27AM +0100, Jon Harrop wrote: > 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 precision, especially on Windows) > > What is the URL for that page? > > I can only find this page: > > http://www.haskell.org/hawiki/SieveOfEratosthenes > > which seems to consist largely of misinformation from newbies... That's not even on the current wiki :) (don't feel bad, Google still hasn't indexed the whole site yet) http://haskell.org/haskellwiki/Prime_numbers Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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 precision, especially on Windows) What is the URL for that page? I can only find this page: http://www.haskell.org/hawiki/SieveOfEratosthenes which seems to consist largely of misinformation from newbies... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
... still talking about "In-place modification" ? yes. in the time-honoured tradition of demonstrating concepts by means of meta-circular arguments. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Tue, 10 Jul 2007, Jon Harrop wrote: > 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 performance. Add a > little functionality (e.g. operator overloading). That is C#. ... still talking about "In-place modification" ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Donald Bruce Stewart wrote: allbery: Doesn't nhc98 target embedded devices? It's been used on embedded arm devices the size of a credit card. 1. Where on earth do you find such a device? 2. How do you run code on one? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Jul 11, 2007, at 13:37 , Andrew Coppin wrote: (Windoze-only, you say? Perhaps I misunderstood - I thought this is what Mono is all about...) As someone else pointed out earlier, the real power is the libraries, which provide a complete and powerful GUI environment. Mono provides the VM and C# but duplicating the libraries is a much bigger and harder job. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Sebastian Sylvan wrote: On 10/07/07, Jon Harrop <[EMAIL PROTECTED]> wrote: Both are designed for GUI and web programming, so they don't fare well for massive concurrency, high-performance numerics or allocation-intensive algorithms (e.g. idiomatic functional programming). C# 3.0 gets it a bit closer, though. I wonder what C# 4.0 will look like, though I worry about the complexity of the language when they keep tacking stuff on like that. The thing that I *like* about Haskell is that it manages to be very powerful, and yet elegently simple. :-D (...and then they add MPTCs, GADTs, ATs, ETs, Rank-N polymorphism, FDs...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Jon Harrop wrote: 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 performance. Add a little functionality (e.g. operator overloading). That is C#. Both are designed for GUI and web programming, so they don't fare well for massive concurrency, high-performance numerics or allocation-intensive algorithms (e.g. idiomatic functional programming). Really? I thought Java was designed to take over the world! LOL. There are certainly *a lot* of mistakes to fix. OTOH, this is Micro$oft we're talking about... how good can it possibly be? (Windoze-only, you say? Perhaps I misunderstood - I thought this is what Mono is all about...) Hint: If you can get readable/maintainable Haskell to run on more than one core "automatically", you're onto something pretty special. ;-) If you're using a Unix, just fork the process and pass messages via a pipe. Yeah, but it's hardly trivial to decide which things are "big enough" to be worth forking for, and which aren't. (Take, for example, a quicksort. You could run the recursions in parallel - but once you get down to small enough lists, it isn't worth the overhead. But how to know when to stop? You end up adding more processing overhead analysing whether to fork than you actually gain by forking...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 11/07/07, brad clawsie <[EMAIL PROTECTED]> wrote: > Yeah, and 640K should be enough for everybody... Again, the original > statement was about 20 years down the line. Go back 20 years and > people would say similar things about C (comparing it to assembly). but one could argue that the democratization of programming will indeed marginalize "hair shirt" tech like haskell in favor of something accesible to the wider public Maybe. Frankly I don't much care. Haskell may become more accessible to the wider public, or it may not. But it seems pretty clear that we need something *like* Haskell to be able to effecitvely program the devices of the future, and whatever language that turns out to be, I'll just be happy that I don't need to use C anymore! -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
> Yeah, and 640K should be enough for everybody... Again, the original > statement was about 20 years down the line. Go back 20 years and > people would say similar things about C (comparing it to assembly). but one could argue that the democratization of programming will indeed marginalize "hair shirt" tech like haskell in favor of something accesible to the wider public what is the fastest growing segment of the programming industry? web development and look at the wonderfully advanced toolkit - a document retrieval protocol hacked up as a packet abstraction (http). a markup format intended to render simple text formatting now coerced into a generalized viewport description mechanism (html). a scripting language with networking features from the 70s. and every day people are migrating existing applications to this stack. worse is better!? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 11 Jul 2007, at 8:02 am, Sebastian Sylvan wrote: On 10/07/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: 20 years from now people will still be saying this... I highly doubt that. For two reasons: 1. People can only cling to unproductive and clumsy tools for so long (we don't write much assembly any more...). Capitalism works to ensure this; people who are willing to switch to more efficient tools will put the rest out of business (if they really are more efficient). We are still seeing terabytes of assembly code written; it is just being written by compilers. As for me, I still sometimes write Fortran. (Mind you, F95 is not your grandfather's Fortran. But it does still beat the pants off C.) People have been predicting the death of Fortran for a long time. 2. The many-core revolution that's on the horizon. You cannot have played with Cilk if you think that will kill C. Actually, it's not on the horizon. The revolution has happened. Some people have seen the flash; others haven't heard the bang yet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
> That might eliminate the concurrency imperative (for a while!), but it > doesn't adress the productivity point. My hypothesis is this: People > don't like using unproductive tools, and if they don't have to, they > won't. productivity is not the only metric for a tool for some people, it is performance for many employers, it is access to a vibrant labor pool for some other coders (database admins, web developers), they don't even have a choice of tool and how do we measure productivity? i would claim the tool that requires me to produce the least new code to get to a sufficient solution is the most productive. haskell's syntax and semantics can aid in reducing code, but do not address real problem domains. thats where hackage comes in. compare hackage to cpan, we've got a ways to go. i'm going to add something to hackage tonight to help! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Tue, 2007-07-10 at 21:02 +0100, Sebastian Sylvan wrote: > On 10/07/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: > > Hallo, > > > > On 7/10/07, Hugh Perkins <[EMAIL PROTECTED]> wrote: > > > On 7/8/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > > > > I was wittering on about stream fusion and how great it is, and I got a > > > > message from Mr C++. > > > > > > > > (Mr C++ develops commercial games, and is obsessed with performance. For > > > > him, the only way to achieve the best performance is to have total > > > > control over every minute detail of the implementation. He sees Haskell > > > > is a stupid language that can never be fast. It seems he's not alone...) > > > > > > > > > > > > > > Just a random observation: the competition for Haskell is not really C or > > > C++. C is basically dead; > > > > 20 years from now people will still be saying this... > > I highly doubt that. For two reasons: > 1. People can only cling to unproductive and clumsy tools for so long > (we don't write much assembly any more...). Capitalism works to ensure > this; people who are willing to switch to more efficient tools will > put the rest out of business (if they really are more efficient). > 2. The many-core revolution that's on the horizon. > > 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, unless the problem happens to be highly > amenable to concurrency (web servers etc.). We need *something* else. > It may not be Haskell, but it will be something (and it will probably > be closer to Haskell than C!). > Single Assignment C! (http://www.sac-home.org/) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hallo, On 7/10/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: The revolution (tm) won't come at the same time for all domains. C is probably used/supported in embedded devices mostly because it's popular for non-embedded devices (not because C is somehow uniquely suited for embedded devices). Wrong. Java and C# are far more popular languages, but C is just the right tool for the job. Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
allbery: > > On Jul 10, 2007, at 16:07 , Alex Queiroz wrote: > > >As I replied to Hugh, the Universe of computers is not restricted > >to PCs. We, embedded developers, will be using C for a lot of time > >still. > > Doesn't nhc98 target embedded devices? It's been used on embedded arm devices the size of a credit card. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Jul 10, 2007, at 16:19 , Andrew Coppin wrote: I have repeatedly attempted to discover what C# actually is, all to no avail. Still, that probably means I don't need it... C# is Microsoft's answer to Java: a vaguely Java/C++-like language that runs in Microsoft's ".net" virtual machine. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Jul 10, 2007, at 16:07 , Alex Queiroz wrote: As I replied to Hugh, the Universe of computers is not restricted to PCs. We, embedded developers, will be using C for a lot of time still. Doesn't nhc98 target embedded devices? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 10/07/07, Jon Harrop <[EMAIL PROTECTED]> wrote: 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 performance. Add a little functionality (e.g. operator overloading). That is C#. Both are designed for GUI and web programming, so they don't fare well for massive concurrency, high-performance numerics or allocation-intensive algorithms (e.g. idiomatic functional programming). C# 3.0 gets it a bit closer, though. I wonder what C# 4.0 will look like, though I worry about the complexity of the language when they keep tacking stuff on like that. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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 performance. Add a little functionality (e.g. operator overloading). That is C#. Both are designed for GUI and web programming, so they don't fare well for massive concurrency, high-performance numerics or allocation-intensive algorithms (e.g. idiomatic functional programming). > Hint: If you can get readable/maintainable Haskell to run on more than > one core "automatically", you're onto something pretty special. ;-) If you're using a Unix, just fork the process and pass messages via a pipe. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?h ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 10/07/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: Sebastian Sylvan wrote: > On 10/07/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: >> So you think we use C because we like it? :-) When this >> revolutionary tool of yours arrive that compiles Haskell to PIC >> devices, I'm gonna be the first to use it. >> > > No, you use it because you have to, there is very little choice. Which > is exactly my point. > > I don't think it's unreasonable to expect that when nobody uses C for > desktop applications, games etc. anymore because there's a better > language available and widely supported, that some version of this > "next mainstream language" will make it onto embedded devices too. > > The revolution (tm) won't come at the same time for all domains. C is > probably used/supported in embedded devices mostly because it's > popular for non-embedded devices (not because C is somehow uniquely > suited for embedded devices). So what happens when something else is > popular, when most industries have stopped using C and almost nobody > coming from university knows it very well or at all? Isn't it likely > that a lot of vendors will write compilers targeting embedded devices > for this new popular language? Mmm... a garbage-collected language on a PIC with single-digit RAM capacity? That's going to be fun! :-D OTOH, isn't somebody out there using Haskell to design logic? (As in, computer ICs.) I doubt you'll even run "Haskell" on a PIC, but you might well use it to *construct* a program that works on a PIC... Yeah, and 640K should be enough for everybody... Again, the original statement was about 20 years down the line. Go back 20 years and people would say similar things about C (comparing it to assembly). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 10/07/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: Sebastian Sylvan wrote: > That might eliminate the concurrency imperative (for a while!), but it > doesn't adress the productivity point. My hypothesis is this: People > don't like using unproductive tools, and if they don't have to, they > won't. > > When "the next mainstream language" comes along to "solve" the > concurrency problem (to some extent), it would seem highly likely that > there will relatively soon be compilers for it for most embedded > devices too, so why would you make your life miserable with C in that > case (and cost your company X dollars due to inefficiency in the > process)? ...because only C works on bizzare and unusual hardware? By what magic is this the case? Hardware automatically supports C without the efforts of compiler-writers? We're talking 20 years down the line here, when someone can choose to write a C compiler, or an X compiler (where X is the most popular systems programming language of the time). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Sebastian Sylvan wrote: On 10/07/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: So you think we use C because we like it? :-) When this revolutionary tool of yours arrive that compiles Haskell to PIC devices, I'm gonna be the first to use it. No, you use it because you have to, there is very little choice. Which is exactly my point. I don't think it's unreasonable to expect that when nobody uses C for desktop applications, games etc. anymore because there's a better language available and widely supported, that some version of this "next mainstream language" will make it onto embedded devices too. The revolution (tm) won't come at the same time for all domains. C is probably used/supported in embedded devices mostly because it's popular for non-embedded devices (not because C is somehow uniquely suited for embedded devices). So what happens when something else is popular, when most industries have stopped using C and almost nobody coming from university knows it very well or at all? Isn't it likely that a lot of vendors will write compilers targeting embedded devices for this new popular language? Mmm... a garbage-collected language on a PIC with single-digit RAM capacity? That's going to be fun! :-D OTOH, isn't somebody out there using Haskell to design logic? (As in, computer ICs.) I doubt you'll even run "Haskell" on a PIC, but you might well use it to *construct* a program that works on a PIC... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Sebastian Sylvan wrote: That might eliminate the concurrency imperative (for a while!), but it doesn't adress the productivity point. My hypothesis is this: People don't like using unproductive tools, and if they don't have to, they won't. When "the next mainstream language" comes along to "solve" the concurrency problem (to some extent), it would seem highly likely that there will relatively soon be compilers for it for most embedded devices too, so why would you make your life miserable with C in that case (and cost your company X dollars due to inefficiency in the process)? ...because only C works on bizzare and unusual hardware? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 10/07/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: Hallo, On 7/10/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > > That might eliminate the concurrency imperative (for a while!), but it > doesn't adress the productivity point. My hypothesis is this: People > don't like using unproductive tools, and if they don't have to, they > won't. > So you think we use C because we like it? :-) When this revolutionary tool of yours arrive that compiles Haskell to PIC devices, I'm gonna be the first to use it. No, you use it because you have to, there is very little choice. Which is exactly my point. I don't think it's unreasonable to expect that when nobody uses C for desktop applications, games etc. anymore because there's a better language available and widely supported, that some version of this "next mainstream language" will make it onto embedded devices too. The revolution (tm) won't come at the same time for all domains. C is probably used/supported in embedded devices mostly because it's popular for non-embedded devices (not because C is somehow uniquely suited for embedded devices). So what happens when something else is popular, when most industries have stopped using C and almost nobody coming from university knows it very well or at all? Isn't it likely that a lot of vendors will write compilers targeting embedded devices for this new popular language? -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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, unless the problem happens to be highly > amenable to concurrency (web servers etc.). We need *something* else. > It may not be Haskell, but it will be something (and it will probably > be closer to Haskell than C!). As long as your C-killer language has a run-time that is written in C, it won't be killing C. :-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. The OCaml Journal http://www.ffconsultancy.com/products/ocaml_journal/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hallo, On 7/10/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: That might eliminate the concurrency imperative (for a while!), but it doesn't adress the productivity point. My hypothesis is this: People don't like using unproductive tools, and if they don't have to, they won't. So you think we use C because we like it? :-) When this revolutionary tool of yours arrive that compiles Haskell to PIC devices, I'm gonna be the first to use it. Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 10/07/07, Andrew Coppin <[EMAIL PROTECTED]> 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, all to no avail. Still, that probably means I don't need it... > If you can get to the stage where you can get a non-optimized, > readable/maintainable Haskell program to run at more than say 30% of > the speed of a non-optimized, readable/maintainable C# program, but > automatically runs across 16 or 256 cores, then you're on to a winner. Hint: If you can get readable/maintainable Haskell to run on more than one core "automatically", you're onto something pretty special. ;-) Soon, have a little patience :-) See for example: http://research.microsoft.com/~simonpj/papers/ndp/NdpSlides.pdf http://research.microsoft.com/~tharris/papers/2007-fdip.pdf -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
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, all to no avail. Still, that probably means I don't need it... If you can get to the stage where you can get a non-optimized, readable/maintainable Haskell program to run at more than say 30% of the speed of a non-optimized, readable/maintainable C# program, but automatically runs across 16 or 256 cores, then you're on to a winner. Hint: If you can get readable/maintainable Haskell to run on more than one core "automatically", you're onto something pretty special. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 7/10/07, Sebastian Sylvan <[EMAIL PROTECTED]> 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, unless the problem happens to be highly amenable to concurrency (web servers etc.). We need *something* else. It may not be Haskell, but it will be something (and it will probably be closer to Haskell than C!). Yeah I agree with this. C# totally rocks, but threading is an unsolved problem. If you can get to the stage where you can get a non-optimized, readable/maintainable Haskell program to run at more than say 30% of the speed of a non-optimized, readable/maintainable C# program, but automatically runs across 16 or 256 cores, then you're on to a winner. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 10/07/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: Hallo, On 7/10/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > > I highly doubt that. For two reasons: > 1. People can only cling to unproductive and clumsy tools for so long > (we don't write much assembly any more...). Capitalism works to ensure > this; people who are willing to switch to more efficient tools will > put the rest out of business (if they really are more efficient). As I replied to Hugh, the Universe of computers is not restricted to PCs. We, embedded developers, will be using C for a lot of time still. That might eliminate the concurrency imperative (for a while!), but it doesn't adress the productivity point. My hypothesis is this: People don't like using unproductive tools, and if they don't have to, they won't. When "the next mainstream language" comes along to "solve" the concurrency problem (to some extent), it would seem highly likely that there will relatively soon be compilers for it for most embedded devices too, so why would you make your life miserable with C in that case (and cost your company X dollars due to inefficiency in the process)? -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hallo, On 7/10/07, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: I highly doubt that. For two reasons: 1. People can only cling to unproductive and clumsy tools for so long (we don't write much assembly any more...). Capitalism works to ensure this; people who are willing to switch to more efficient tools will put the rest out of business (if they really are more efficient). As I replied to Hugh, the Universe of computers is not restricted to PCs. We, embedded developers, will be using C for a lot of time still. Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 10/07/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: Hallo, On 7/10/07, Hugh Perkins <[EMAIL PROTECTED]> wrote: > On 7/8/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > > I was wittering on about stream fusion and how great it is, and I got a > > message from Mr C++. > > > > (Mr C++ develops commercial games, and is obsessed with performance. For > > him, the only way to achieve the best performance is to have total > > control over every minute detail of the implementation. He sees Haskell > > is a stupid language that can never be fast. It seems he's not alone...) > > > > > > Just a random observation: the competition for Haskell is not really C or > C++. C is basically dead; 20 years from now people will still be saying this... I highly doubt that. For two reasons: 1. People can only cling to unproductive and clumsy tools for so long (we don't write much assembly any more...). Capitalism works to ensure this; people who are willing to switch to more efficient tools will put the rest out of business (if they really are more efficient). 2. The many-core revolution that's on the horizon. 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, unless the problem happens to be highly amenable to concurrency (web servers etc.). We need *something* else. It may not be Haskell, but it will be something (and it will probably be closer to Haskell than C!). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
You're talking to someone who spent his teenage years doing assembler because that's what l33t games developers did, and I wanted to be like them. Sure, you can still find assembler around the place, but even l33t games developers dont use it any more. On 7/10/07, Alex Queiroz <[EMAIL PROTECTED]> wrote: > Just a random observation: the competition for Haskell is not really C or > C++. C is basically dead; 20 years from now people will still be saying this... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hi > It picks whichever one you have first on your $(PATH). ...right. Presumably this is isomorphic to "whichever one was installed the most recently"? (Oh, wait... IIRC, on Windoze the GHC installer doesn't actually add GHC to the PATH variable. You have to do it by hand...) It does. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hallo, On 7/10/07, Hugh Perkins <[EMAIL PROTECTED]> wrote: On 7/8/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: > I was wittering on about stream fusion and how great it is, and I got a > message from Mr C++. > > (Mr C++ develops commercial games, and is obsessed with performance. For > him, the only way to achieve the best performance is to have total > control over every minute detail of the implementation. He sees Haskell > is a stupid language that can never be fast. It seems he's not alone...) > > Just a random observation: the competition for Haskell is not really C or C++. C is basically dead; 20 years from now people will still be saying this... -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On 7/8/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: I was wittering on about stream fusion and how great it is, and I got a message from Mr C++. (Mr C++ develops commercial games, and is obsessed with performance. For him, the only way to achieve the best performance is to have total control over every minute detail of the implementation. He sees Haskell is a stupid language that can never be fast. It seems he's not alone...) Just a random observation: the competition for Haskell is not really C or C++. C is basically dead; C++ is only really useful when you dont want people to be able to read your source code. Java comes close to being competition, but it's slow and eats memory (except in benchmarks where it somehow does quite well). The competition for Haskell is C#, which runs at 80% C++ speed, has a really decent interface into legacy C libraries, has a garbage collector, bounds checking, decent debug messages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Tue, Jul 10, 2007 at 08:10:32PM +0100, Andrew Coppin wrote: > Neil Mitchell wrote: >>> ...OK...and when you tell GHC to compile something, exactly which >>> compiler does it run? o_O >> >> It picks whichever one you have first on your $(PATH). > > ...right. Presumably this is isomorphic to "whichever one was installed the > most recently"? Yes. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Neil Mitchell wrote: Hi ...OK...and when you tell GHC to compile something, exactly which compiler does it run? o_O It picks whichever one you have first on your $(PATH). ...right. Presumably this is isomorphic to "whichever one was installed the most recently"? (Oh, wait... IIRC, on Windoze the GHC installer doesn't actually add GHC to the PATH variable. You have to do it by hand...) On linux you can do: which ghc c:\path\to\ghc Ah, true... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hi > The worst problem that comes of this is a slow loss of disk space, but > I don't think I'll ever be able to fill this 80G disk :) > ...OK...and when you tell GHC to compile something, exactly which compiler does it run? o_O It picks whichever one you have first on your $(PATH). On linux you can do: which ghc c:\path\to\ghc Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Stefan O'Rear wrote: On Mon, Jul 09, 2007 at 10:01:06PM +0100, Andrew Coppin wrote: Is it safe to install two versions of GHC at once? :-. Certainly. I have no less than twelve. [EMAIL PROTECTED]:~$ ls -l /usr/bin/ghc-6* /usr/local/bin/ghc-6* lrwxrwxrwx 1 root root 30 2007-05-26 08:50 /usr/bin/ghc-6.6.1 -> ../lib/ghc-6.6.1/bin/ghc-6.6.1 -rwxr-xr-x 1 root staff 385 2006-12-24 13:43 /usr/local/bin/ghc-6.4.2 -rwxr-xr-x 1 root staff 145 2007-01-13 16:52 /usr/local/bin/ghc-6.7 -rwxr-xr-x 1 root staff 172 2007-02-13 18:20 /usr/local/bin/ghc-6.7.20070213 -rwxr-xr-x 1 root staff 172 2007-02-24 01:29 /usr/local/bin/ghc-6.7.20070223 -rwxr-xr-x 1 root staff 172 2007-03-25 19:53 /usr/local/bin/ghc-6.7.20070323 -rwxr-xr-x 1 root staff 172 2007-04-01 14:04 /usr/local/bin/ghc-6.7.20070402 -rwxr-xr-x 1 root staff 172 2007-04-14 10:35 /usr/local/bin/ghc-6.7.20070413 -rwxr-xr-x 1 root staff 172 2007-05-02 18:46 /usr/local/bin/ghc-6.7.20070502 -rwxr-xr-x 1 root staff 172 2007-05-19 16:01 /usr/local/bin/ghc-6.7.20070518 -rwxr-xr-x 1 root staff 172 2007-06-02 23:41 /usr/local/bin/ghc-6.7.20070601 -rwxr-xr-x 1 root staff 144 2007-06-12 20:20 /usr/local/bin/ghc-6.7.20070612 The worst problem that comes of this is a slow loss of disk space, but I don't think I'll ever be able to fill this 80G disk :) ...OK...and when you tell GHC to compile something, exactly which compiler does it run? o_O ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Mon, Jul 09, 2007 at 10:01:06PM +0100, Andrew Coppin wrote: > Bulat Ziganshin wrote: >> Hello Andrew, >> >> Monday, July 9, 2007, 12:36:25 AM, you wrote: >> >>> OK. So that's just the GHC binary itself, right? >>> >> >> it's INSTALLER >> > > Ah. That explains the size then... > > Is it safe to install two versions of GHC at once? :-. Certainly. I have no less than twelve. [EMAIL PROTECTED]:~$ ls -l /usr/bin/ghc-6* /usr/local/bin/ghc-6* lrwxrwxrwx 1 root root 30 2007-05-26 08:50 /usr/bin/ghc-6.6.1 -> ../lib/ghc-6.6.1/bin/ghc-6.6.1 -rwxr-xr-x 1 root staff 385 2006-12-24 13:43 /usr/local/bin/ghc-6.4.2 -rwxr-xr-x 1 root staff 145 2007-01-13 16:52 /usr/local/bin/ghc-6.7 -rwxr-xr-x 1 root staff 172 2007-02-13 18:20 /usr/local/bin/ghc-6.7.20070213 -rwxr-xr-x 1 root staff 172 2007-02-24 01:29 /usr/local/bin/ghc-6.7.20070223 -rwxr-xr-x 1 root staff 172 2007-03-25 19:53 /usr/local/bin/ghc-6.7.20070323 -rwxr-xr-x 1 root staff 172 2007-04-01 14:04 /usr/local/bin/ghc-6.7.20070402 -rwxr-xr-x 1 root staff 172 2007-04-14 10:35 /usr/local/bin/ghc-6.7.20070413 -rwxr-xr-x 1 root staff 172 2007-05-02 18:46 /usr/local/bin/ghc-6.7.20070502 -rwxr-xr-x 1 root staff 172 2007-05-19 16:01 /usr/local/bin/ghc-6.7.20070518 -rwxr-xr-x 1 root staff 172 2007-06-02 23:41 /usr/local/bin/ghc-6.7.20070601 -rwxr-xr-x 1 root staff 144 2007-06-12 20:20 /usr/local/bin/ghc-6.7.20070612 The worst problem that comes of this is a slow loss of disk space, but I don't think I'll ever be able to fill this 80G disk :) Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Bulat Ziganshin wrote: Hello Andrew, Monday, July 9, 2007, 12:36:25 AM, you wrote: OK. So that's just the GHC binary itself, right? it's INSTALLER Ah. That explains the size then... Is it safe to install two versions of GHC at once? :-. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Sun, Jul 08, 2007 at 09:36:25PM +0100, Andrew Coppin wrote: > Neil Mitchell wrote: > > > >Seriously. Thanks to Igloo, And Neil, who wrote the actual installer-generator! > >you can even download a GHC nightly > >complete with an installer! It doesn't get any easier than that :) > > > >http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070706-i386-unknown-mingw32.exe > > > > > > OK. So that's just the GHC binary itself, right? It includes everything the installer for released versions includes. (the release installer for 6.8.1 will be one of these nightly-built installers). Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
andrewcoppin: > I was wittering on about stream fusion and how great it is, and I got a > message from Mr C++. > > (Mr C++ develops commercial games, and is obsessed with performance. For > him, the only way to achieve the best performance is to have total > control over every minute detail of the implementation. He sees Haskell > is a stupid language that can never be fast. It seems he's not alone...) Many libraries use inplace update and mutable data. Like, hmm, Data.ByteString. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Sun, Jul 08, 2007 at 09:35:10PM +0100, Andrew Coppin wrote: >> GHC HQ is considering retiring the registerised >> -fvia-C path, leaving only native code for normal use and ANSI C for >> porting. This is because mangled C is only about 3% faster according to >> the GHC benchmark suite, and carries a high maintaince cost. >> > > It would mean that on Windoze, you don't have to supply gcc and an emulator > for running it... That was also part of the justification. > (Are you keeping an external assembler and linker, or doing the whole > shooting match in GHC?) Currently, we use gas and ld, yes... Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Neil Mitchell wrote: Hi btw, you doesn't need to use unix in order to play with ghc HEAD - you can download compiled windows binary Seriously? I'm pretty sure I tried to do that and couldn't... Seriously. Thanks to Igloo, you can even download a GHC nightly complete with an installer! It doesn't get any easier than that :) http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070706-i386-unknown-mingw32.exe OK. So that's just the GHC binary itself, right? Perl may die soon - GHC HQ is considering retiring the registerised -fvia-C path, leaving only native code for normal use and ANSI C for porting. This is because mangled C is only about 3% faster according to the GHC benchmark suite, and carries a high maintaince cost. I still wouldn't want to compile GHC on Windows... For the only GHC patch I've ever contributed I borrowed a friends Linux box. The build instructions alone for Windows scarred me off. Hmm... Mind you, not sure I fancy trying it on Linux either. Just because Linux is scary... :-P ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Stefan O'Rear wrote: Yes, GHC does in-place updates on almost everything. But probably not in the way you wanted. Ah yes, true... (Try implementing that in Java. Tricky...) I did think about compiling GHC myself once. But then I found out that it's not actually written in Haskell - it's written in Haskell + C + asm + Perl (?!) and it's utterly *huge*... Perl may die soon Yay! Oh wait, you meant Perl in GHC? :-} GHC HQ is considering retiring the registerised -fvia-C path, leaving only native code for normal use and ANSI C for porting. This is because mangled C is only about 3% faster according to the GHC benchmark suite, and carries a high maintaince cost. It would mean that on Windoze, you don't have to supply gcc and an emulator for running it... (Are you keeping an external assembler and linker, or doing the whole shooting match in GHC?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hi btw, you doesn't need to use unix in order to play with ghc HEAD - you can download compiled windows binary Seriously? I'm pretty sure I tried to do that and couldn't... Seriously. Thanks to Igloo, you can even download a GHC nightly complete with an installer! It doesn't get any easier than that :) http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070706-i386-unknown-mingw32.exe > I did think about compiling GHC myself once. But then I found out that it's > not actually written in Haskell - it's written in Haskell + C + asm + Perl > (?!) and it's utterly *huge*... Perl may die soon - GHC HQ is considering retiring the registerised -fvia-C path, leaving only native code for normal use and ANSI C for porting. This is because mangled C is only about 3% faster according to the GHC benchmark suite, and carries a high maintaince cost. I still wouldn't want to compile GHC on Windows... For the only GHC patch I've ever contributed I borrowed a friends Linux box. The build instructions alone for Windows scarred me off. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
On Sun, Jul 08, 2007 at 07:52:19PM +0100, Andrew Coppin wrote: > Bulat Ziganshin wrote: >> Hello Andrew, >> Sunday, July 8, 2007, 9:40:15 PM, you wrote: >>> I've asked this before and nobody answered, so I take it that nobody >>> knows the answer... Does GHC *ever* do an in-place update on anything? >> >> no. this will break GC's heart :) > > Yeah, having only immutable objects to collect must simplify a whole bunch > of stuff... Yes, GHC does in-place updates on almost everything. But probably not in the way you wanted. The crucial feature of laziness, that distinguishes it from call-by-name as found in old ALGOL, is that when you finish evaluating an expression you overwrite the expression with its value. This guarantees that expressions are only evaluated once, and is crucial for the performance of idioms such as circular programming and array-memoization. This does mean that GHC needs a *very* simple write barrier in the GC - it just tacks the current node onto a linked list. No overflow checks, no occurence checks, just a couple of fast instructions. But this does mean that everything overwritable (with pointers) (MutVar#, MutArray#, SynchVar#, TVar#, indirections) needs an extra link pointer. >>> Does the STG even have a command for that? >>> >> >> hm. there are ghc primitives that work with mutable arrays. look for >> primops.txt.pp in ghc sources. > > The GHC sources. Scary place. ;-) You could also look at the HTMLized primop documentation: http://haskell.org/ghc/dist/current/docs/libraries/base/GHC-Prim.html writeArray#, writeArray#, writeOffAddr#, writeMutVar#, writeTVar#, takeMVar#, tryTakeMVar#, putMVar#, tryPutMVar#, do inplace writes. > I did think about compiling GHC myself once. But then I found out that it's > not actually written in Haskell - it's written in Haskell + C + asm + Perl > (?!) and it's utterly *huge*... Perl may die soon - GHC HQ is considering retiring the registerised -fvia-C path, leaving only native code for normal use and ANSI C for porting. This is because mangled C is only about 3% faster according to the GHC benchmark suite, and carries a high maintaince cost. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Bulat Ziganshin wrote: Hello Andrew, Sunday, July 8, 2007, 9:40:15 PM, you wrote: I've asked this before and nobody answered, so I take it that nobody knows the answer... Does GHC *ever* do an in-place update on anything? no. this will break GC's heart :) Yeah, having only immutable objects to collect must simplify a whole bunch of stuff... and it really breaks it as far as you start to work with updateable arrays. look for details at http://haskell.org/haskellwiki/Modern_array_libraries "GHC 6.6 (currently in beta testing) will add..." Oh, that's cute. ;-) Does the STG even have a command for that? hm. there are ghc primitives that work with mutable arrays. look for primops.txt.pp in ghc sources. The GHC sources. Scary place. ;-) I did think about compiling GHC myself once. But then I found out that it's not actually written in Haskell - it's written in Haskell + C + asm + Perl (?!) and it's utterly *huge*... btw, you doesn't need to use unix in order to play with ghc HEAD - you can download compiled windows binary Seriously? I'm pretty sure I tried to do that and couldn't... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In-place modification
Hello Andrew, Sunday, July 8, 2007, 9:40:15 PM, you wrote: > I've asked this before and nobody answered, so I take it that nobody > knows the answer... Does GHC *ever* do an in-place update on anything? no. this will break GC's heart :) and it really breaks it as far as you start to work with updateable arrays. look for details at http://haskell.org/haskellwiki/Modern_array_libraries > Does the STG even have a command for that? hm. there are ghc primitives that work with mutable arrays. look for primops.txt.pp in ghc sources. btw, you doesn't need to use unix in order to play with ghc HEAD - you can download compiled windows binary -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
