Stefan O'Rear wrote:
I like pretty pictures.
...and have lots of spare time, apparently. ;-)
[I actually meant to write (Bool,Bool), but anyway...]
Whereas my Quad object is going
to be a pointer to one of 4 values... so it looks like Quads save space.
(And they're more strict.) OTOH,
On Fri, Aug 10, 2007 at 02:08:42PM +0800, Hugh Perkins wrote:
On 8/10/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Good idea! Maybe it could be fit into the GHC Performance Resource
somehow? (http://www.haskell.org/haskellwiki/Performance/GHC)
From the wiki: Since GHC
On 8/10/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 8/10/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Haskell's purpose: To be a generally cool language
Haskell's competition: C++, SML, ... hundreds of thousands more and I make
no assertion of a representative sample ...
Well, C++ is not
On 8/10/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Haskell's purpose: To be a generally cool language
Haskell's competition: C++, SML, ... hundreds of thousands more and I make
no assertion of a representative sample ...
Well, C++ is not really competitive with Haskell, because C++ does not
| And, of course, if it's a strict argument, then the values stored are
| ALWAYS one of two possibilities. So as a matter of curiosity, would
| there be any advantage at all for unboxing enumeration types? (Apart
| from, I suppose, the possibility of using fewer than 32/64 bits to store
| a
hughperkins:
Now, I did have kindof a shootout thread with Don and
Sebastien, calculating prime numbers, where Don managed to
get to within an order of magnitude of C# performance (I
think he got to about 70-80% of C# performance, cool!) -
Despite my better judgement, I'll just
hughperkins:
You'll find by the way that the imperative
GC'd, stack/heap protected languages run *significantly*
faster for many (not all I guess?) algorithms and
applications.
Wow. Big claims. It must be silly hat day on the Haskell lists.
We're trying hard to
On Fri, Aug 10, 2007 at 07:26:28AM +0100, Andrew Coppin wrote:
Stefan O'Rear wrote:
I like pretty pictures.
...and have lots of spare time, apparently. ;-)
Indeed. :)
Probably none. The STG-machine was designed to make user-defined
algebraic types very fast.
My program needs to make
On 8/10/07, John Meacham [EMAIL PROTECTED] wrote:
On Thu, Aug 09, 2007 at 06:37:32PM +0100, Andrew Coppin wrote:
Which of these is likely to go faster?
type Quad = (Bool,Bool)
...
data Quad = BL | BR | TL | TR
...
I'm hoping that the latter one will more more strict / use less space.
On 8/9/07, Chad Scherrer [EMAIL PROTECTED] wrote:
extract :: [Int] - [a] - [a]
extract = f 0
where
f _ _ [] = []
f _ [] _ = []
f k nss@(n:ns) (x:xs) = if n == k then x:f (k+1) ns xs
else f (k+1) nss xs
Finally, even if no one else is using it,
In digest #69, Hugh Perkins mentioned the coolness of Erlang-style
message passing concurrency. It just so happened that I was playing
with that yesterday, so I figured I'd post a link to a 'ping-pong'
thing that I based on an example in the erlang tutorial. I figured
Haskell has lightweight
On Fri, Aug 10, 2007 at 06:12:03PM +0100, Andrew Coppin wrote:
[big blob of simplifier output]
Mmm. See, now, I have *no idea* what GHC is saying. But I would have
expected that if I do something like
x = if testBit 3 q ...
then the definition of testBit would get inlined, and then
Stefan O'Rear wrote:
On Fri, Aug 10, 2007 at 07:26:28AM +0100, Andrew Coppin wrote:
My program needs to make decisions based on a pair of boolean values.
Encoding both values as a single algebraic data type means I have to keep
taking it apart so I can work with it. I'm not sure how much
Stefan O'Rear wrote:
Just wait 12 years, and if the price of processors follows Moore's
extrapolation and the Haskell keeps its parallelism, Haskell will win :)
Nice idea.
Unfortunately, writing code in Haskell does not [yet] magically cause it
to become parallel. It's just that writing
Hugh Perkins wrote:
- parallelism must be quite coarse to offset overheads
(which I think is the problem with expecting things like map
and fold
to parallelised automagically; they're just too small grained for
it to
be worthwhile)
Someone else said that. I dont
On 8/10/07, Bulat Ziganshin [EMAIL PROTECTED] wrote:
if you mean Erlang's sophisticated rules of which messages in queue to
process first - this may be not yet implemented for Haskell. if you
mean that program is just many threads which pass messages through
channels to each other - it's
Stefan O'Rear wrote:
or, if you used the (correct and unintuitive) argument order to testBit:
GAH! _
Do you have ANY IDEA how many times I've got that wrong so far?? All I
can say is thank God that Haskell is a statically-typed language! The
type checker has saved my life here more times
Agreed. I like select better too, and the regular vs Asc version
is a nice parallel with fromList and fromAscList.
Chad
On 8/10/07, Tillmann Rendel [EMAIL PROTECTED] wrote:
Non-negative is obvious for a list of indexes. Ordered makes sense
implementation-wise, and should be easy to match for
Chad Scherrer wrote:
extract :: [Int] - [a] - [a]
[...]
This behaves roughly as
extract ns xs == map (xs !!) ns
extract sounds like removing the elements to be extracted from the
original list. I would therefore expect it's type signature to be
extract :: [Int] - [a] - ([a], [a])
with
For now, we just edit .cabal files when transporting code between GHC
versions...
Just for information, the HaXml darcs repo has recently adopted the
solution of containing two .cabal files, one for ghc-6.6.x, and the
other for the split-base packages (=ghc-6.7). The only difference is
the
The proposal that I like the most is this one:
Open Data Types and Open Functions
http://lambda-the-ultimate.org/node/1453
However, it doesn't readily admit using the variants as overlapping
enumerations like John suggested in a previous thread:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hugh Perkins
Not many replies on this thread? Am I so wrong that no-one's
even telling me? I find it hard to believe that if there
were obvious errors in the proposition that anyone would
resist pointing them out to me
On Aug 10, 2007, at 9:31 AM, Hugh Perkins wrote:
Not many replies on this thread? Am I so wrong that no-one's even
telling me? I find it hard to believe that if there were obvious
errors in the proposition that anyone would resist pointing them
out to me ;-)
So, that leaves a couple
On 8/10/07, Bayley, Alistair [EMAIL PROTECTED] wrote:
Well, the Harris/Singh paper summarises the common problems:
- not many programs are inherently parallel
If thats the case, then multicores are not going to be very useful. Where
there's a will there's a way.
What I think is: if maps etc
Stefan O'Rear wrote:
Bool is 32 bits, but Don is using UArray. UArray is not parametric in
the element type, which means it's less generally useful (no UArray of
Complex Double, for instance), but conversely it is able to use more
efficient representations depending on the type.
Would be
Posix has pretty well taken the name select. It probably isn't a
good idea to use that name in a commonly imported library like
Data.List, since users will have to mask and qualify it if they also
import Posix libraries.
--
Brian T. Sniffen
[EMAIL PROTECTED]or[EMAIL PROTECTED]
Hello Donald,
Friday, August 10, 2007, 10:46:36 AM, you wrote:
Hmm. Not looking so good so for for the imperative, GC'd languages.
Java?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=ghclang2=java
C#?
Donald, i have written (an not once) that most of shooutout
On Fri, Aug 10, 2007 at 04:51:49PM +0800, Hugh Perkins wrote:
Well, managed to shave 25% of C# execution time by writing my own bit
array. For now, I will concede that, under the conditions of the shoot,
bitarrays in c# are slower than bitarrays in Haskell. I'll let you know if
I get any new
Well, managed to shave 25% of C# execution time by writing my own bit
array. For now, I will concede that, under the conditions of the shoot,
bitarrays in c# are slower than bitarrays in Haskell. I'll let you know if
I get any new ideas on this.
Getting back to the original problem, which is:
Oh boy, never mind, after a good night sleep the solution is super obvious...
Grrr what a waste of time ;-)
The solution is in the sentence the logician has then enough information to
solve the problem, which I yesterday read like the problem can now be
solved, which is not the same.
So the
Haskell vs GC'd imperative languages
===
On 8/10/07, Thomas Conway [EMAIL PROTECTED] wrote:
Well, C++ is not really competitive with Haskell, because C++ does not
have
a GC, and it's trivial to corrupt the stack/heap.
Beg to differ. I offer the following proof by
It may not be a bug, because you do get an error, but it's certainly an
infelicity because the error comes out much too late. I'll Trac this and fix
in due course. Thanks for raising it.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian Brunswick-5 wrote:
g f ??? g ??? f
application a a-b flip ($) b
monad bind m a a-m b= m b
comonad cobind w a w a-b= w b
arrowarr a b arr b c arr
hughperkins:
On 8/10/07, Donald Bruce Stewart [EMAIL PROTECTED]
wrote:
It's using bit arrays.
Well I'm a total Haskell newbie, and you're using Haskell to
write imperative code, so it's really hard for me to read,
but looking at your code, you have:
On Fri, Aug 10, 2007 at 04:00:01PM +0800, Hugh Perkins wrote:
On 8/10/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
It's using bit arrays.
Well I'm a total Haskell newbie, and you're using Haskell to write
imperative code, so it's really hard for me to read, but looking at your
On 8/10/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Bool is 32 bits, but Don is using UArray. UArray is not parametric in
the element type, which means it's less generally useful (no UArray of
Complex Double, for instance), but conversely it is able to use more
efficient representations
On 8/10/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
It's using bit arrays.
Well I'm a total Haskell newbie, and you're using Haskell to write
imperative code, so it's really hard for me to read, but looking at your
code, you have:
(IOUArray Int Bool) -- an array of Bool
Bool is a
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
On Fri, Aug 10, 2007 at 02:28:09PM +0800, Hugh Perkins wrote:
On 8/10/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Haskell's purpose: To be a generally cool language
Haskell's competition: C++, SML, ... hundreds of thousands more and I make
no assertion of a representative sample ...
Hugh Perkins wrote:
I'm not trolling, despite strong appearances to the contrary ;-) My
primary objective/goal is to find a way to make threading easy. Thread
management today is like memory management in the early 90s. We kindof
had tools (new, delete in C++ for example) to do it. At
On 8/10/07, Michael Vanier [EMAIL PROTECTED] wrote:
Just to get the history right: garbage collectors have been around a
_long_ time, since the '60s in
Lisp systems. They only became known to most programmers through Java
(which is one unarguable good
thing that Java did).
Ah interesting
Hi all,
Given the follwing function:
owner :: Step - Scenario
owner (Step id scenario action state response) = scenario
Is it possible to define the owner function in such way that I can write
x.owner (returning the scenario related with the Step x)?
Thanks in advance,
Rodrigo.
On Friday 10 August 2007 03:51:49 Hugh Perkins wrote:
Well, managed to shave 25% of C# execution time by writing my own bit
array. For now, I will concede that, under the conditions of the shoot,
bitarrays in c# are slower than bitarrays in Haskell. I'll let you know if
I get any new ideas
On Friday 10 August 2007 12:37:31 Andrew Coppin wrote:
Stefan O'Rear wrote:
Bool is 32 bits, but Don is using UArray. UArray is not parametric in
the element type, which means it's less generally useful (no UArray of
Complex Double, for instance), but conversely it is able to use more
Prelude let (.) = flip ($) in 5 . odd
True
But please don't, the (.) operator is a sacred artifact in my religion,
and I'd hate to see it desecrated... :(
Dan
rodrigo.bonifacio wrote:
Hi all,
Given the follwing function:
owner :: Step - Scenario
owner (Step id scenario action state
Haskellians,
i have a particular interest in FM-set theory in that it simplifies a host
of otherwise non-trivial aspects of programming language semantics,
especially, fresh names. You can provide semantics without sets with atoms,
but the functor category machinery is more than a little on the
Mitar wrote:
Hi!
First, disclaimer: everything I know about interval arithmetics comes
from this video:
http://video.google.com/videoplay?docid=-2285617608766742834
The discussion in the implementation of the Boost Interval Arithmetic
Library is also useful.
Hmm, this would make a good QuickCheck property. I wonder, is listify
a contravariant functor? Fun to work through the details of that some
time, I think.
Chad
On 8/10/07, Brent Yorgey [EMAIL PROTECTED] wrote:
Amusingly, extract is intimately related to function composition. Suppose we
have
Hi all,
Given the follwing function:
owner :: Step - Scenario
owner (Step id scenario action state response) = scenario
Is it possible to define the owner function in such way that I can write
x.owner (returning the scenario related with the Step x)?
Some people use (|), which looks
Stefan O'Rear [EMAIL PROTECTED] wrote:
When you build a package, Cabal passess the -hide-all-packages option
to GHC, which prevents the package from using any installed packages
other than the ones explicitly listed in the Build-Depends: field.
For now, we just edit .cabal files when
I suppose you mean the link at
http://haskelldb.sourceforge.net/#documentation
you can find the tutorial at the Wayback Machine:
http://web.archive.org/web/20070514141711/http://www.haskell.org/hawiki/HaskellDbTutorial
Regards,
Henk-Jan van Tuyl
--
http://functor.bamikanarie.com
Don't be too impressed, I think I was way off base. Looks like just a
homomorphism:
http://en.wikipedia.org/wiki/Homomorphism
Chad
I wonder, is listify a contravariant functor?
I wonder - will I ever reach the stage where I too make off-hand remarks
like this? :-}
Now I know how all the
rodrigo.bonifacio wrote:
owner :: Step - Scenario
owner (Step id scenario action state response) = scenario
Is it possible to define the owner function in such way that I can write
x.owner (returning the scenario related with the Step x)?
The . is already taken. Choose some other symbol,
On 8/8/07, Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Peter,
Wednesday, August 8, 2007, 11:14:37 PM, you wrote:
[...] So could you please tell me more about the problem with pure
functional GUIs
seems that such program will have no effects :)
Not necessarily. Just design the UI IO
Chad Scherrer wrote:
I wonder, is listify a contravariant functor?
I wonder - will I ever reach the stage where I too make off-hand remarks
like this? :-}
Now I know how all the normal people feel when I tell them that a
relation is simply a subset of the extended Cartesian product of the
Andrew Coppin wrote:
Like that time yesterday, I compiled from program and got a weird
message
about GHC about ignored trigraphs or something... What the heck is a
trigraph?
Everyone's favorite obscure feature of the ANSI C99 preprocessor.
Probably you had something like this is
Hello Michael,
Friday, August 10, 2007, 12:50:43 PM, you wrote:
As for threading, in addition to Haskell's approach you might also
look at Erlang, which has a quite
different (and quite interesting) approach to the whole problem. I wonder if
anyone has tried to
implement a
On 8/10/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
No, STUArray s Int Bool is a bit array.
Look at the space use. Or try replacing Bool with Word32, and see what
happens.
Fair enough. Well, the mono example in the shootout is lacking quite a few
optimizations, eg its using the
Not many replies on this thread? Am I so wrong that no-one's even telling
me? I find it hard to believe that if there were obvious errors in the
proposition that anyone would resist pointing them out to me ;-)
So, that leaves a couple of possibilites: some people are agreeing, but see
no point
Haskellians,
A quick follow up. If you look at the code that i have written there is a
great deal of repeated structure. Each of these different kinds of sets and
atoms are isomorphic copies of each other. Because, however, of the
alternation discipline, i could see no way to abstract the
Hugh Perkins wrote:
Now, arguably the fact that we are pattern matching on the receiver at
least
means we dont do anything with the invalid data sent, but this is not
rocket
science: the standard technique to ensure decent compile time validation
in
rpc-type things is to use an interface.
On 8/9/07, Peter Verswyvelen [EMAIL PROTECTED] wrote:
I was writing some haskell code for fun to solve some knights and knaves
. . .
John: answers either Yes or No, and you can now solve the problem.
We can write a Haskell *program* to solve this problem. But is
On 8/11/07, Hugh Perkins [EMAIL PROTECTED] wrote:
- parallelism must be quite coarse to offset overheads
(which I think is the problem with expecting things like map and fold
to parallelised automagically; they're just too small grained for it to
be worthwhile)
Someone else said that.
On Friday 10 August 2007 03:51:49 Hugh Perkins wrote:
Getting back to the original problem, which is: threading. Donald, one of
the things that is very interesting about Haskell is it's potential for
automatic threading, ie you write a trivial algorithm that looks like it
runs in a single
On 8/11/07, Thomas Conway [EMAIL PROTECTED] wrote:
There are many papers about this in the Parallel Logic Programming
area. It is commonly called Embarrassing Parallelism.
Ah, I wasnt very precise ;-) I didnt mean I dont understand the
problem; I meant I dont understand why people think it is
Brian Brunswick wrote:
g f ??? g ??? f
application a a-b flip ($) b
monad bind m a a-m b= m b
comonad cobind w a w a-b= w b
arrowarr a b arr b c arr a c
On 8/10/07, Andrew Coppin [EMAIL PROTECTED] wrote:
My program needs to make decisions based on a pair of boolean values.
Encoding both values as a single algebraic data type means I have to
keep taking it apart so I can work with it. I'm not sure how much time
this wastes...
Incidentally,
Hello Andrew,
Friday, August 10, 2007, 9:37:31 PM, you wrote:
Would be nice if it *could* somehow be parametric...
ForeignArray may hold any Storable values. look at
http://haskell.org/haskellwiki/Modern_array_libraries - we have no
less than 10 array constructors :))
--
Best regards,
68 matches
Mail list logo
