hello all,
I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1;
Apparently, it worked fine!
However, function parseModule has been given the type:
parseModule ::
String
- ParseResult haskell-src-1.0.1.3:Language.Haskell.Syntax.HsModule
instead of simply
parseModule
On Thu, Feb 26, 2009 at 2:31 AM, Manuel M T Chakravarty
c...@cse.unsw.edu.au wrote:
I'm planning to purchase a MacBookPro so I'm wondering how well
Haskell is supported under this platform.
At least two of the regular contributors to GHC work on Macs. That should
ensure that Mac OS X is well
John Lato jwl...@gmail.com writes:
Brandon Allbery wrote:
On 2009 Feb 21, at 20:47, Jonathan Cast wrote:
On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:
Not showing platform-specific packages by default *might* make
package writers more likely to develop cross-platform
packages.
Peter Hercek pher...@gmail.com writes:
Relinking against newer Gtk2Hs versions might not work.
You have the option of recompiling the new Gtk2Hs with the old GHC and
relinking, don't you?
I want to repeat what I’ve said earlier on this list: For Haskell,
there is no real difference between
[now with the name of the package on subject; appologies for multiple emails]
hello all,
I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1;
Apparently, it worked fine!
However, function parseModule has been given the type:
parseModule ::
String
- ParseResult
Hi
With binary 0.5,
src - decodeFile _make/_make
return $! src
I'm pretty sure I was on the latest Cabal released version of binary,
and the above trick did not work. It _usually_ worked, but every so
often I'd get a locking error.
Shouldn't you use rnf[1]? Also, there seems to be
On Thu, 2009-02-26 at 08:00 +, jpa...@di.uminho.pt wrote:
hello all,
I've used cabal to install package haskell-src-1.0.1.3 under ghc 6.10.1;
Apparently, it worked fine!
However, function parseModule has been given the type:
parseModule ::
String
- ParseResult
On Thu, 2009-02-26 at 00:56 -0500, Brandon S. Allbery KF8NH wrote:
On 2009 Feb 25, at 18:06, Manlio Perillo wrote:
Debian some time ago introduced the popularity context, to find the
most installed/used packages:
http://popcon.debian.org/
Is it possible to do something similar with
Hi,
i have compared a C++ implementation with a Haskell implementation of the Monte
Carlo Pi approximation:
http://lennart.kudling.de/haskellPi/
The Haskell version is 100 times slower and i wonder whether i do something
obvious wrong.
Profiling says that the majority of the time is spend in
First thing I noticed, how about removing the sqrt in isInCircle:
isInCircle :: (Floating a, Ord a) = (a,a) - Bool
isInCircle (x,y) = x*x + y*y = 1.0
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt is
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt is
worse than its Haskell counterpart.
Oops, of course I mean, you only improve if Haskell's implementation is
worse than C++'s implementation :)
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt is
worse than its Haskell counterpart.
Oops, of course I mean, you only improve if Haskell's implementation is
worse than C++'s implementation :)
Yep, this program will crawl.
You can get reasonable numeric performance out of GHC, but you need to
work at it. There is some advice in the GHC manual at http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
.
The first thing I would do is replace your
isInCircle ::
hask...@kudling.de writes:
Profiling says that the majority of the time is spend in main. But i have
no idea where.
Can someone give me a hint?
Yes. Lots of them, but somehow, I suspect nobody tried your code.
COST CENTRE MODULE
Hi,
thanks for your input.
You can get reasonable numeric performance out of GHC, but you need to
work at it. There is some advice in the GHC manual at
http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
I am using -O2 and strictness already.
Currently i can only imagine to
hask...@kudling.de schrieb:
Hi,
i have compared a C++ implementation with a Haskell implementation of the Monte
Carlo Pi approximation:
http://lennart.kudling.de/haskellPi/
The Haskell version is 100 times slower and i wonder whether i do something
obvious wrong.
Hi,
Nice benchmark, but I
On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
Currently i can only imagine to define a data type in order to use
unboxed Ints instead of the accumulator tuple.
That would probably help a lot. It would also help to use two separate
Double# parameters instead of the tuple.
The
Hello,
I just want to mention that the Grapefruit FRP library now has a mailing list
and a Trac instance which contains a bug tracker. See:
http://www.haskell.org/haskellwiki/Grapefruit#Community
Please also note that the Grapefruit repositories have moved to
code.haskell.org.
Best
Ben Lippmeier wrote:
The first thing I would do is replace your isInCircle :: (Floating
a, Ord a) = (a,a) - Bool with isInCircle :: (Double, Double) -
Bool
Can you point me to why that matters?
At the machine level, GHC treats the (Floating a, Ord a) as an extra
argument to the
Hi all,
An easy thing to do here would be to get a written statement from the
author about the interpretation with regard to what you intend to do -
like Duncan posted.
AFAIK this only works when the code has a single author (or, you get a written
statement from each author). In practice, many
Here is a variant that uses mersenne-random-pure64 and works less than
2x slower than C++:
- You don't need to compute samples count an extra time
- You don't need to assemble double pairs from a list
- Notice the strictness in randomDoublePairs: it doubled performance
{-# LANGUAGE
I replaced the standard random number generated with the one from
mersenne-random. On my system this makes the resulting program about
14 times faster than the original. I also made a change to
accumulateHit because it doesn't need to count to total. That is
already known.
{-# LANGUAGE
accumulateHit because it doesn't need to count to total. That is
already known.
Well in theory i agree. But somone could feed a non-infite number of doubles.
Then the argument n would not necessarily be the same as the number of random
number pairs really used.
Do you think it would be feasable to replace the GHC implementation of
System.Random with something like System.Random.Mersenne?
Here is a variant that uses mersenne-random-pure64 and works less than
2x slower than C++:
- You don't need to compute samples count an extra time
- You don't need
I, personally, do, but I think that's more of a question to the GHC people :)
2009/2/26 hask...@kudling.de:
Do you think it would be feasable to replace the GHC implementation of
System.Random with something like System.Random.Mersenne?
Here is a variant that uses mersenne-random-pure64 and
On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov ekirpic...@gmail.com wrote:
Here is a variant that uses mersenne-random-pure64 and works less than
2x slower than C++:
And I would like to notice that rand() is incredibly dumber than the
Mersenne twister, so probably if we took rand()'s code
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Roel van Dijk
I replaced the standard random number generated with the one from
mersenne-random. On my system this makes the resulting program about
14 times faster than the original. I also made
Kenneth Hoste ha scritto:
Hello,
I'm having a go at the Netflix Prize using Haskell. Yes, I'm brave.
[...]
To see if I could efficiently represent the data set in this way, I
wrote a small
Haskell program (attached) which uses the following data type:
From what I see, to append a new
C's rand() function is very bad and should never be used really.
On Thu, Feb 26, 2009 at 11:37 AM, Felipe Lessa felipe.le...@gmail.com wrote:
On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov ekirpic...@gmail.com
wrote:
Here is a variant that uses mersenne-random-pure64 and works less than
hask...@kudling.de wrote:
Do you think it would be feasable to replace the GHC implementation
of System.Random with something like System.Random.Mersenne?
There's a problem with using the Mersenne Twister: System.Random's
interface has a split method:
class RandomGen g where
split:: g -
You can implement a reasonable split if you can fast-forward the generator.
There's no known method to fast-forward the MT, but other generators
like MRG32k3a can handle it.
-- Lennart
On Thu, Feb 26, 2009 at 12:08 PM, Bertram Felgenhauer
bertram.felgenha...@googlemail.com wrote:
John Lato jwl...@gmail.com writes:
Brandon Allbery wrote:
On 2009 Feb 21, at 20:47, Jonathan Cast wrote:
On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote:
Not showing platform-specific packages by default *might* make
package writers more likely to develop cross-platform
packages.
Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek:
So my opinion (IAMNAL):
1) source code under very limiting commercial license (just to allow
recompile with a newer LGPL lib and nothing else) is OK
2) it is probable that only the *.o, *.hi files and a linking script are
OK too
I
I'm Switzerland on open source licenses -- I use GPL3 on everything I write,
because I like the default position, but I'm always happy to relicense on
request (except maybe to companies like Fluffy Bunny Killer, Inc). My
sister tells me I'm a control freak, and maybe I am :-)
So BSD is just
Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:
Peter Hercek pher...@gmail.com writes:
Relinking against newer Gtk2Hs versions might not work.
You have the option of recompiling the new Gtk2Hs with the old GHC and
relinking, don't you?
Relinking is technically not possible
I'm planning to purchase a MacBookPro so I'm wondering how well
Haskell is supported under this platform.
At least two of the regular contributors to GHC work on Macs. That
should ensure that Mac OS X is well supported. Installation is
trivial with the Mac OS X installer package:
Am Donnerstag, 26. Februar 2009 13:41 schrieb John Lato:
I didn't phrase this well. In the context of my argument, design for
cross-platform meant avoid platform-limiting choices in the absence
of any compelling reasons otherwise, which really isn't the same.
Could we sum that up as:
Do not
The Mozilla Public License is superior to LGPL for this purpose: it
still forces you to release any modifications, while clearly allowing
bundling and commercial sales of software that includes MPL code.
MPL is a good fit if you want to ensure improvements get contributed
back to the
Daniel provided the wisdom:
Do not knowingly make your code unportable unless you have a good reason to
Are there any objections to that maxim?
Thanks for bringing some sanity back. I notice very few people have
bothered to comment on the wiki page Neil has setup. Incase anyone
has fogotten
On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote:
John A. De Goes j...@n-brain.net wrote:
The problem is that PL research is probably not going to stop
evolving in our lifetimes. Yes, that research needs a venue, but why
should it be Haskell? Haskell is a good language and it's time to
start
Hi,
I seem to be a little stuck with incremental array updates... I've got
an array of few (some thousand) integers, but have to do a calculation
where I incrementally build up the array. For sake of simplicity, for
now I don't use a State-Monad but simply pass the array as state down
the
You need to use STUArray. The Data.Array
completely-immutable-and-boxed arrays are ok only for tasks where you
build an array once and don't modify it, and where you need array
elements to be lazy.
The // operation creates a copy of the whole array with one element
modified. It should probably be
On Thu, Feb 26, 2009 at 6:53 AM, Daniel Kraft d...@domob.eu wrote:
procOne (a + 1) (newarr `seq` newarr)
The semantics of seq are: a `seq` b = _|_ if a = _|_, b otherwise. This
implies that x `seq` x = x, and this seq is superfluous.
Maybe you meant newarr `seq` procOne (a+1) newarr ?
Eugene Kirpichov wrote:
You need to use STUArray. The Data.Array
completely-immutable-and-boxed arrays are ok only for tasks where you
build an array once and don't modify it, and where you need array
elements to be lazy.
The // operation creates a copy of the whole array with one element
On Feb 26, 2009, at 13:00 , Manlio Perillo wrote:
Kenneth Hoste ha scritto:
Hello,
I'm having a go at the Netflix Prize using Haskell. Yes, I'm brave.
[...]
To see if I could efficiently represent the data set in this way, I
wrote a small
Haskell program (attached) which uses the following
Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:
Hi,
I seem to be a little stuck with incremental array updates... I've got
an array of few (some thousand) integers, but have to do a calculation
where I incrementally build up the array. For sake of simplicity, for
now I don't
Daniel Fischer wrote:
Am Donnerstag, 26. Februar 2009 14:53 schrieb Daniel Kraft:
Hi,
I seem to be a little stuck with incremental array updates... I've got
an array of few (some thousand) integers, but have to do a calculation
where I incrementally build up the array. For sake of
On Thu, 2009-02-26 at 13:52 +0100, Daniel Fischer wrote:
Am Donnerstag, 26. Februar 2009 13:41 schrieb John Lato:
I didn't phrase this well. In the context of my argument, design for
cross-platform meant avoid platform-limiting choices in the absence
of any compelling reasons otherwise,
Hi all,
Under gitit 0.5.3 I always get Prelude.read: no parse when trying to
load a configuration file.
My previous file goes attached, but the sample config file from
http://github.com/jgm/gitit/tree/master does not work also.
Has anything changed that is not documented?
Thanks,
hugo
On Sun,
On Thu, 2009-02-26 at 06:30 -0700, John A. De Goes wrote:
On Feb 25, 2009, at 7:49 PM, Achim Schneider wrote:
John A. De Goes j...@n-brain.net wrote:
The problem is that PL research is probably not going to stop
evolving in our lifetimes. Yes, that research needs a venue, but why
should
STUArray is really a bit tricky to get used with: especially, if you
do something wrong, the type errors will be rather dreadful.
However, if you do everything right, it's OK and you sometimes even
don't need to write the types at all.
There are a couple of examples here
Okay, so I've written a small library to generalize 'fst' and 'snd' to
arbitrary tuples, but I'd like to extend it a bit. I'm using the
type-level library to do the thinking :)
Imports and defines first:
{-# LANGUAGE UnicodeSyntax, MultiParamTypeClasses,
FunctionalDependencies,
On Thu, 26 Feb 2009 14:30:17 +
Hugo Pacheco hpach...@gmail.com wrote:
Hi all,
Under gitit 0.5.3 I always get Prelude.read: no parse when trying to
load a configuration file.
My previous file goes attached, but the sample config file from
http://github.com/jgm/gitit/tree/master does not
Still nothing. No matter which config file I try (deleting almost
every fields, newlines, etc), I always get the no parse error.
On Thu, Feb 26, 2009 at 5:47 AM, Robin Green gree...@greenrd.org wrote:
On Thu, 26 Feb 2009 14:30:17 +
Hugo Pacheco hpach...@gmail.com wrote:
Hi all,
Under
Are you by chance using OSX? The file you attached was not a plain
text file -- it was an RTF file.
If you made this file on OSX and forgot to invoke the Format Make
Plain Text command, it'll be an RTF file which I'm sure gitit will
have no clue about.
-Ross
On Feb 26, 2009, at 10:21
Hi,
Is it possible to write a strict version of Data.Map.map (so that the
Map becomes strict in the elements as well as the keys)?
Thanks,
Edsko
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Yes I am.
I just copy/pasted the text from the server where it is plain text, so
that shall not be the problem.
On Thu, Feb 26, 2009 at 3:23 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote:
Are you by chance using OSX? The file you attached was not a plain text file
-- it was an RTF file.
If you
I'd advise you to see Control.Parallel.Strategies, specially the
NFData class and the rnf function.
HTH,
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, Feb 26, 2009 at 1:21 PM, Thomas DuBuisson
thomas.dubuis...@gmail.com wrote:
Daniel provided the wisdom:
Do not knowingly make your code unportable unless you have a good reason to
Are there any objections to that maxim?
Thanks for bringing some sanity back. I notice very few people
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson
lenn...@augustsson.netwrote:
You can implement a reasonable split if you can fast-forward the generator.
There's no known method to fast-forward the MT, but other generators
like MRG32k3a can handle it.
Are you aware of any existing
2009/2/26 Tracy Wadleigh tracy.wadle...@gmail.com:
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson lenn...@augustsson.net
wrote:
You can implement a reasonable split if you can fast-forward the
generator.
There's no known method to fast-forward the MT, but other generators
like MRG32k3a
Awesome, Felipe. Thanks.
--Tracy
On Thu, Feb 26, 2009 at 11:07 AM, Felipe Lessa felipe.le...@gmail.comwrote:
2009/2/26 Tracy Wadleigh tracy.wadle...@gmail.com:
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson
lenn...@augustsson.net
wrote:
You can implement a reasonable split if
On Thu, Feb 26, 2009 at 02:53:42PM +0100, Daniel Kraft wrote:
I seem to be a little stuck with incremental array updates... I've got
an array of few (some thousand) integers, but have to do a calculation
where I incrementally build up the array. For sake of simplicity, for
now I don't
Ben.Lippmeier:
On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
Currently i can only imagine to define a data type in order to use
unboxed Ints instead of the accumulator tuple.
That would probably help a lot. It would also help to use two separate
Double# parameters instead of the
Alistair.Bayley:
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Roel van Dijk
I replaced the standard random number generated with the one from
mersenne-random. On my system this makes the resulting program about
14 times faster than the
Ross Paterson wrote:
On Thu, Feb 26, 2009 at 02:53:42PM +0100, Daniel Kraft wrote:
I seem to be a little stuck with incremental array updates... I've got
an array of few (some thousand) integers, but have to do a calculation
where I incrementally build up the array. For sake of simplicity,
I looked at the core and the tuples were already unboxed IIRC.
2009/2/26 Don Stewart d...@galois.com:
Ben.Lippmeier:
On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
Currently i can only imagine to define a data type in order to use
unboxed Ints instead of the accumulator tuple.
That
On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote:
Well, my main problem was the lazy evaluation...
No, your main problem was that you were creating 100,000 arrays,
each only a little different from the one before.
For this example program... yes of course :) I'm trying to do so
Might also mean bad alignment of data structures, maybe when marshalling
data between the GHC runtime and the C implementation? If I recall correctly
SSE2 requires 16-byte alignment.
On Thu, Feb 26, 2009 at 5:24 PM, Don Stewart d...@galois.com wrote:
Alistair.Bayley:
From:
i'm implementing a benchmark which includes a detailed specification for a
random number generator. for any of the kernels outlined in the benchmark,
i might have to generate a set of random numbers R, which has a length n,
using the following formulas:
R[k] = ((2^-46)(X[k])) mod 2^46, where
On Thu, Feb 26, 2009 at 12:45:09PM -0300, Felipe Lessa wrote:
I'd advise you to see Control.Parallel.Strategies, specially the
NFData class and the rnf function.
What is the time complexity of running rnf on a Data.Map? If it is O(n),
then surely running rnf on my map after every 'map'
vandijk.roel:
I replaced the standard random number generated with the one from
mersenne-random. On my system this makes the resulting program about
14 times faster than the original. I also made a change to
accumulateHit because it doesn't need to count to total. That is
already known.
On Thu, Feb 26, 2009 at 2:13 PM, Edsko de Vries devri...@cs.tcd.ie wrote:
On Thu, Feb 26, 2009 at 12:45:09PM -0300, Felipe Lessa wrote:
I'd advise you to see Control.Parallel.Strategies, specially the
NFData class and the rnf function.
What is the time complexity of running rnf on a Data.Map?
james.swaine:
i'm implementing a benchmark which includes a detailed specification for a
random number generator. for any of the kernels outlined in the benchmark, i
might have to generate a set of random numbers R, which has a length n, using
the following formulas:
R[k] = ((2^-46)(X[k]))
2009/2/26 James Swaine james.swa...@gmail.com
--gets r[k], which is the value at the kth
--position in the overall sequence of
--pseudorandom numbers
getRandAt :: Int64 - Int64 - Float
getRandAt 0 seed = multiplier * (fromIntegral seed)
getRandAt k seed = multiplier * (fromIntegral x_next)
How about an FFI call to rand() and then measure the performance
On Thu, Feb 26, 2009 at 3:37 AM, Felipe Lessa felipe.le...@gmail.comwrote:
On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov ekirpic...@gmail.com
wrote:
Here is a variant that uses mersenne-random-pure64 and works less than
Thanks for all the hints and code provided, nevertheless, it implied
another questions:
1) Am I right that MemoCombinators can be hardly ever used with hugs? If
not, which guidelines to be used for installation...
2) Is there any paper/tutorial/wiki that describes, which local
Thanks for all the hints and code provided, nevertheless, it implied
another questions:
1) Am I right that MemoCombinators can be hardly ever used with hugs? If
not, which guidelines to be used for installation...
2) Is there any paper/tutorial/wiki that describes, which local
Ross Paterson wrote:
On Thu, Feb 26, 2009 at 05:31:34PM +0100, Daniel Kraft wrote:
Well, my main problem was the lazy evaluation...
No, your main problem was that you were creating 100,000 arrays,
each only a little different from the one before.
Here I have to disagree (in my particular
Ketil Malde ke...@malde.org wrote:
So it seems we're just tremendously lousy at generating random
Doubles.
We had this a while ago, and Don was kind enough to post some bindings
to dSFMT:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-random-pure64-0.2.0.2
which could
Hello Daniel,
Thursday, February 26, 2009, 9:27:10 PM, you wrote:
It was about this: I needed to generate all possibilities for some
combinations and each of those had a numeric property, say from 1 to
1; I then had to count how many of the possibilities were of a given
category. So I
Am Donnerstag, 26. Februar 2009 18:48 schrieb Luke Palmer:
2009/2/26 James Swaine james.swa...@gmail.com
--gets r[k], which is the value at the kth
--position in the overall sequence of
--pseudorandom numbers
getRandAt :: Int64 - Int64 - Float
getRandAt 0 seed = multiplier *
On Thu, Feb 26, 2009 at 07:27:10PM +0100, Daniel Kraft wrote:
It was about this: I needed to generate all possibilities for some
combinations and each of those had a numeric property, say from 1 to
1; I then had to count how many of the possibilities were of a given
category. So I
On Thu, Feb 26, 2009 at 06:45:27PM +, Ross Paterson wrote:
Yes, bucketing problems like this are a common case that the standard
functions cannot handle. Perhaps the libraries need a canned solution.
Stratch that -- as Bulat points out, accumArray is such a canned solution.
On Thu, Feb 26, 2009 at 09:36:17PM +0300, Bulat Ziganshin wrote:
Thursday, February 26, 2009, 9:27:10 PM, you wrote:
It was about this: I needed to generate all possibilities for some
combinations and each of those had a numeric property, say from 1 to
1; I then had to count how many
Hello Ross,
Thursday, February 26, 2009, 9:54:23 PM, you wrote:
the same loop using STArray, but accumArray provide you pure API for
such computations
And accumArray can also be used with UArray if laziness is a problem.
to be exact, for Array, STArray used internally
for
Hello Eugene,
Thursday, February 26, 2009, 5:32:14 PM, you wrote:
look at http://haskell.org/haskellwiki/Library/ArrayRef
it contains reimplementation of arrays library according to OlegSimon idea:
- Unboxed arrays now can be used in polymorphic functions, they are defined
for every element
John A. De Goes j...@n-brain.net wrote:
Partial functions and dependent typing do not seem to play well together,
for instance.
Well, sure, they do, as long as you don't expect the typechecker to
terminate if some type it checks is formulated in unterminating code.
GHC already has this problem
Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote:
Am Donnerstag, 26. Februar 2009 09:17 schrieb Ketil Malde:
Peter Hercek pher...@gmail.com writes:
Relinking against newer Gtk2Hs versions might not work.
You have the option of recompiling the new Gtk2Hs with the old GHC
and
Achim Schneider bars...@web.de wrote:
-calculus
PiSigma calculus, that is. I really shouldn't attempt to send unicode
via US-ascii.
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights reserved. Copying, hiring, renting,
performance
On Feb 26, 2009, at 12:12 PM, Achim Schneider wrote:
I think that arguing that Haskell is _obsolete_ because it isn't yet
fully dependently typed is vastly mistaken.
I never said it was obsolete. Far from it. But I did say that choices
already made and codified into H98 have implications on
Hello,
Thanks, I'll have a look at these. Treating unboxed stuff
polymorphically is anyways very interesting and would be good to use
in collections API that has been recently discussed (and which I
occasionally try to continue inventing with scarce success :-/ ).
2009/2/26 Bulat Ziganshin
On Thu, Feb 26, 2009 at 6:23 PM, Don Stewart d...@galois.com wrote:
But note the lazy list of Double pairs, so the inner loop still looks like
this though:
$wlgo :: Int# - [(Double, Double)] - Int
$wlgo =
\ (ww_s1pv :: Int#)
(w_s1px :: [(Double, Double)]) -
case
John A. De Goes j...@n-brain.net wrote:
What do you mean by progress? I noted before that there are
tradeoffs. Constraining the evolution of the language in backward
compatible ways leads to substantial improvements in tools,
libraries, and the speed of compiled code. That's progress in
Are you saying has been no progress since KR C in the number of
libraries available to C programmers? And that C programmers still
have to edit files with vi and compile and link by specifying all
files on the command-line?
You may disagree, but the evidence points in the opposite
On Thu, 2009-02-26 at 13:18 -0700, John A. De Goes wrote:
Are you saying has been no progress since KR C in the number of
libraries available to C programmers? And that C programmers still
have to edit files with vi and compile and link by specifying all
files on the command-line?
You
No, I hate C and will never use it again in my entire life unless
forced to at the point of a gun.
You're point? :-P
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 26, 2009, at 1:17 PM, Jonathan Cast wrote:
Wolfgang Jeltsch wrote:
Am Mittwoch, 25. Februar 2009 23:38 schrieb Peter Hercek:
So my opinion (IAMNAL):
1) source code under very limiting commercial license (just to allow
recompile with a newer LGPL lib and nothing else) is OK
2) it is probable that only the *.o, *.hi files and a linking
On Thu, 2009-02-26 at 13:25 -0700, John A. De Goes wrote:
No, I hate C and will never use it again in my entire life unless
forced to at the point of a gun.
Why? Its libraries are far better, its editors are far better [1], its
compilers are far better, its tool support is far better, it's
John A. De Goes j...@n-brain.net wrote:
Are you saying has been no progress since KR C in the number of
libraries available to C programmers?
I never did, I asked you to compare usability. If you want it in plain
English, library semantics still suck, hell, there isn't even name
spacing.
1 - 100 of 134 matches
Mail list logo
