[Haskell-cafe] Re: Best Editor In Windows

2009-11-03 Thread Gour
On Fri, 16 Oct 2009 10:41:05 -0700
 Gregory == gcr...@phys.washington.edu  wrote:

Hi Greg,

Gregory While Emacs has some outline capabilities, they are not at
Gregory this time remotely as nice or as powerful as Leo, which among
Gregory other things:

Do you use Leo for Haskell development?

I've asked on Leo list about support for Haskell and Emacs, but no
reply so far.

IIRC, Emacs can be used as Leo's external editor, right?


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6



signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Best Editor In Windows

2009-11-03 Thread Gregory Crosswhite

Gour,

Yes, I use Leo for Haskell development.  You will need to use the  
development trunk, though, since it contains a necessary patch I  
submitted to make Leo work correctly with Haskell sources.   You can  
download this from Launchpad:


https://launchpad.net/leo-editor

It is possible to use Emacs as the external editor.  I don't remember  
the exact procedure off the top of my head, but the idea is that you  
enable the emacs plugin inside Leo, set your installation of emacs to  
start the emacs server (so that emacsclient can connect to it), and  
then when you double-click on a node it sends the node to emacs via.  
emacsclient and when you save the buffer is sent back to Leo.  One  
caveat with this is that Leo has a newer Qt-based GUI and an older Tk- 
based GUI, and I don't know if the plugin works with the Qt-based GUI  
yet.  You can tell Leo to use the Tk GUI by specifying --gui=Tk on  
the command line --- i.e., python launchLeo.py --gui=Tk.


Hope this helps!

- Greg


On Nov 3, 2009, at 12:55 AM, Gour wrote:


On Fri, 16 Oct 2009 10:41:05 -0700

Gregory == gcr...@phys.washington.edu  wrote:


Hi Greg,

Gregory While Emacs has some outline capabilities, they are not at
Gregory this time remotely as nice or as powerful as Leo, which among
Gregory other things:

Do you use Leo for Haskell development?

I've asked on Leo list about support for Haskell and Emacs, but no
reply so far.

IIRC, Emacs can be used as Leo's external editor, right?


Sincerely,
Gour

--

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Simple FAST lazy functional primes

2009-11-03 Thread Steve
Hi Will,

I had previously tested the Melissa O'Neil prime function (using the
primes 0.1.1 package) and found it to be fast (for a functional
approach), but with high memory use.

To fully test a prime function, I think you should:
1. Test for more than the first 10^6 primes.
Generating all primes to 10^6 is quite easy for modern computers. Most
prime generating functions will run in less than 1 sec and look fast. 
Try generating all primes to 10^7 and 10^8 then you will see how 'fast'
these lazy functional methods really are.
2. Measure memory use.
As you move above 10^6 and test primes up to 10^7, 10^8, and 10^9,
memory use becomes very important. A prime function with excessive
memory use will soon consume all of the system's memory.

Here's another primes function which performs quite well.

primes :: [Int]
primes = 2 : filter (isPrime primes) [3,5..]  where
  isPrime (p:ps) n
| mod n p == 0 = False
| p*p  n  = True
| otherwise= isPrime ps n
  isPrime [] _ = False -- never used, but avoids compiler warning

Here's some results from my PC, for generating primes to 10^8.

 10**6  10**7   10**8
  secs MiB   secs MiB   secs  MiB
  ---
1 0.01   00.1   2  2   14
2 0.56   7   11.1  43270  306
3 0.61   7   11.8  44260  342
4 0.43  365.4 345900 not finished

1 using a Haskell ST Array
2 your primes function
3 my primes function, listed above
4 Melissa O'Neil method from primes 0.1.1 package

To summarise the results from the tests I've run:
- if you want fast functional primes, forget it, its not possible.
- if you just want fast primes, then use C, or a Haskell array.
- if performance does not matter and slow primes are acceptable, then
use the purely functional approach.

Regards,
Steve


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Best Editor In Windows

2009-11-03 Thread Philippos Apolinarius
I tryed it, and noticed that it is very slow, compared both with Emacs, 
TextPad, and Emerald. I tryed also leksah, but it is always complaining about 
something missing in Pango, although it works fine. Here is the error message

(leksah.exe:1588): Pango-WARNING **: error opening config file 'C:\Arquivos de
Programas\Leksah\etc\pango\pangorc': Invalid argument


--- On Tue, 11/3/09, Gregory Crosswhite gcr...@phys.washington.edu wrote:

From: Gregory Crosswhite gcr...@phys.washington.edu
Subject: Re: [Haskell-cafe] Re: Best Editor In Windows
To: Gour g...@gour-nitai.com
Cc: haskell-cafe@haskell.org
Received: Tuesday, November 3, 2009, 2:21 AM

Gour,

Yes, I use Leo for Haskell development.  You will need to use the development 
trunk, though, since it contains a necessary patch I submitted to make Leo work 
correctly with Haskell sources.   You can download this from Launchpad:

    https://launchpad.net/leo-editor

It is possible to use Emacs as the external editor.  I don't remember the exact 
procedure off the top of my head, but the idea is that you enable the emacs 
plugin inside Leo, set your installation of emacs to start the emacs server (so 
that emacsclient can connect to it), and then when you double-click on a node 
it sends the node to emacs via. emacsclient and when you save the buffer is 
sent back to Leo.  One caveat with this is that Leo has a newer Qt-based GUI 
and an older Tk-based GUI, and I don't know if the plugin works with the 
Qt-based GUI yet.  You can tell Leo to use the Tk GUI by specifying --gui=Tk 
on the command line --- i.e., python launchLeo.py --gui=Tk.

Hope this helps!

- Greg


On Nov 3, 2009, at 12:55 AM, Gour wrote:

 On Fri, 16 Oct 2009 10:41:05 -0700
 Gregory == gcr...@phys.washington.edu  wrote:
 
 Hi Greg,
 
 Gregory While Emacs has some outline capabilities, they are not at
 Gregory this time remotely as nice or as powerful as Leo, which among
 Gregory other things:
 
 Do you use Leo for Haskell development?
 
 I've asked on Leo list about support for Haskell and Emacs, but no
 reply so far.
 
 IIRC, Emacs can be used as Leo's external editor, right?
 
 
 Sincerely,
 Gour
 
 --
 Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



  __
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Simple FAST lazy functional primes

2009-11-03 Thread Will Ness
Jason Dagit dagit at codersbase.com writes:

 By the way, do you understand where the speedup with Int is coming from?  As I
understand it, there are two main places.  One is that the type class dictionary
passing can be removed (GHC might figure this out already, I'd need to check the
core to be sure).  The other is that GHC is likely unboxing to it's primitive
Int# type.
 [...]
 Good luck!
 Jason


Thanks!

Writing the super-fast sieve wasn't my objective here though. It rather was
writing the fastest possible simple functional lazy code true to the sieve's
definition, and understanding it better that way (that's the added bonus).

As it stands now, this code seems a rather faithful description of what _is_
sieve, except that it tests each number in isolation instead of counting over a
bunch of them at once (skipping over primes, getting them for free). THAT's the
crucial difference, which the article seems trying to explain but never quite
gets it in such simple terms. All the extra activity is kept to absolute minimum
here, and _now_ the main thing can be dealt with further, if so desired - like
turning to using the PQ thing, etc. 

Then if we were to compare them, it wouldn't be like comparing apples with
orange juice. :)  That's what it felt like, seeing the PQ code compared with the
classic naive version in that article. I'm reasonably sure that PQ-augmented,
this code will be even faster, not slower, even for the first million primes. 

This whole experience proves it that the clearest code can also be the fastest
(and may be necessarily so). Seeing it described in that article as if clarity
must be paid for with efficiency (and vice versa), didn't seem right to me.


Cheers,
 


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe at haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Are all arrows functors?

2009-11-03 Thread Neil Brown

Hi,

I was thinking about some of my code today, and I realised that where I 
have an arrow in my code, A b c, the type (A b) is also a functor.  The 
definition is (see 
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html):


fmap = (^)
-- Or, in long form:
fmap f x = arr f  x

Out of curiosity, and since this is a typical haskell-cafe question, 
does this definition of fmap hold for all arrows?


And is there a wiki page somewhere that has a table of all of these 
Haskell type-classes (Functor, Monad, Category, Arrow, Applicative and 
so on), and says that if you are an instance of class A you must have 
some corresponding instance of B? (e.g. all Monads are Functors and 
Applicatives)  I'm fairly certain my arrow isn't a Monad or Applicative, 
although of course it must be a Category, given the type-class 
dependency, but it would be nice when using one of these things to see 
what other instances you should automatically supply.


Thanks,

Neil.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Are all arrows functors?

2009-11-03 Thread Eugene Kirpichov
2009/11/3 Neil Brown nc...@kent.ac.uk:
 Hi,

 I was thinking about some of my code today, and I realised that where I have
 an arrow in my code, A b c, the type (A b) is also a functor.  The
 definition is (see
 http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html):

 fmap = (^)
 -- Or, in long form:
 fmap f x = arr f  x

 Out of curiosity, and since this is a typical haskell-cafe question, does
 this definition of fmap hold for all arrows?

 And is there a wiki page somewhere that has a table of all of these Haskell
 type-classes (Functor, Monad, Category, Arrow, Applicative and so on), and
 says that if you are an instance of class A you must have some corresponding
 instance of B? (e.g. all Monads are Functors and Applicatives)  I'm fairly
 certain my arrow isn't a Monad or Applicative, although of course it must be
 a Category, given the type-class dependency, but it would be nice when using
 one of these things to see what other instances you should automatically
 supply.


What about the Typeclassopedia
(http://haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf)?

 Thanks,

 Neil.
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe




-- 
Eugene Kirpichov
Web IR developer, market.yandex.ru
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces

2009-11-03 Thread Henning Thielemann
Jose Iborra schrieb:
 Folks,
 
 I'm happy to announce a new release of control-monad-exception with
 monadic call traces,
 available in Hackage. Grab it now while it is still online!
 
 Monadic stack traces are described in detail in a blog post [1].
 
 In short, what this means for your code is the ability to generate
 errors like this:
 
 500 Internal Server Error
 The CGI server failed with the following error:
 DeleteException (BmPK 2009-10-26 19:39:51.031297 UTC Testing RPO)
  in deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 44)
 deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 25)
 deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (184, 17)
 deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (180, 90)
 deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs):
 (108, 3)
 deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs):
 (106, 20)
 cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 33)
 cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 30)
 cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (50, 9)
 cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (46, 11)

Sure, this is a nice functionality. But isn't it about debugging, not
exception handling? Internal Server Error means to me, the server has a
bug, thus we want to know, how to reproduce it, thus the stack trace.
For handling expected irregularites, what exceptions are, you would not
need that, right?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Are all arrows functors?

2009-11-03 Thread Nicolas Pouillard
Excerpts from Neil Brown's message of Tue Nov 03 13:45:42 +0100 2009:
 Hi,
 
 I was thinking about some of my code today, and I realised that where I 
 have an arrow in my code, A b c, the type (A b) is also a functor.  The 
 definition is (see 
 http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html):
 
 fmap = (^)
 -- Or, in long form:
 fmap f x = arr f  x
 
 Out of curiosity, and since this is a typical haskell-cafe question, 
 does this definition of fmap hold for all arrows?

Yes, as shown by the 'WrappedArrow' newtype:

http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicative.html#t%3AWrappedMonad

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces

2009-11-03 Thread Thomas Hartman
When using happstack, I find it really annoying to get a Prelude.head:
null list error (or similar) in my web browser window because
somewhere, some library used something unsafe -- and of course, since
this is haskell, no stack trace.

if c-m-e can offer benefits around this, I would be very interested in
adopting it.

thomas.

2009/11/3 Henning Thielemann lemm...@henning-thielemann.de:
 Jose Iborra schrieb:
 Folks,

 I'm happy to announce a new release of control-monad-exception with
 monadic call traces,
 available in Hackage. Grab it now while it is still online!

 Monadic stack traces are described in detail in a blog post [1].

 In short, what this means for your code is the ability to generate
 errors like this:

 500 Internal Server Error
 The CGI server failed with the following error:
 DeleteException (BmPK 2009-10-26 19:39:51.031297 UTC Testing RPO)
  in deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 44)
     deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 25)
     deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (184, 17)
     deleteBenchmarkFromPK,
 NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (180, 90)
     deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs):
 (108, 3)
     deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs):
 (106, 20)
     cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 33)
     cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52, 30)
     cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (50, 9)
     cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (46, 11)

 Sure, this is a nice functionality. But isn't it about debugging, not
 exception handling? Internal Server Error means to me, the server has a
 bug, thus we want to know, how to reproduce it, thus the stack trace.
 For handling expected irregularites, what exceptions are, you would not
 need that, right?

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: [Haskell] ANNOUNCE: control-monad-exception 0.5 with monadic call traces

2009-11-03 Thread Jose Iborra

On 03/11/2009, at 14:24, Henning Thielemann wrote:


Jose Iborra schrieb:

Folks,

I'm happy to announce a new release of control-monad-exception with
monadic call traces,
available in Hackage. Grab it now while it is still online!

Monadic stack traces are described in detail in a blog post [1].

In short, what this means for your code is the ability to generate
errors like this:

500 Internal Server Error
The CGI server failed with the following error:
DeleteException (BmPK 2009-10-26 19:39:51.031297 UTC Testing RPO)
in deleteBenchmarkFromPK,
NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 44)
   deleteBenchmarkFromPK,
NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (186, 25)
   deleteBenchmarkFromPK,
NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (184, 17)
   deleteBenchmarkFromPK,
NarradarBenchmarkDB(src/NarradarBenchmarkDB.hs): (180, 90)
   deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs):
(108, 3)
   deleteTests, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs):
(106, 20)
   cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52,  
33)
   cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (52,  
30)
   cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (50,  
9)
   cgiMain, NarradarBenchmarkCGI(src/NarradarBenchmarkCGI.hs): (46,  
11)


Sure, this is a nice functionality. But isn't it about debugging, not
exception handling? Internal Server Error means to me, the server  
has a

bug, thus we want to know, how to reproduce it, thus the stack trace.
For handling expected irregularites, what exceptions are, you would  
not

need that, right?



This is about error handling and reporting.
Catching an exception does not tell you where the exception comes  
from, in the
same way that a head of empty list error does not point at the  
source of the error.

You need a stack trace to know that.
So the output above, generated by a regular exception handler

 cgiMain
   `catchWithSrcLoc`
 \loc e...@someexception{} -
  outputInternalServerError [ The Narradar CGI server  
failed with the following error:
, showExceptionWithTrace loc  
e]


gives you that kind of information.
What you do with the stack trace, printing it (currently it is simply  
a list

of Strings) or something else, is your choice.

Thanks,
pepe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Simple FAST lazy functional primes

2009-11-03 Thread Will Ness

Hi Steve,

Steve stevech1097 at yahoo.com.au writes:

 
 Hi Will,
 
 I had previously tested the Melissa O'Neil prime function (using the
 primes 0.1.1 package) and found it to be fast (for a functional
 approach), but with high memory use.
 
 To fully test a prime function, I think you should:
 1. Test for more than the first 10^6 primes.
 Generating all primes to 10^6 is quite easy for modern computers. Most
 prime generating functions will run in less than 1 sec and look fast. 
 Try generating all primes to 10^7 and 10^8 then you will see how 'fast'
 these lazy functional methods really are.
 2. Measure memory use.
 As you move above 10^6 and test primes up to 10^7, 10^8, and 10^9,
 memory use becomes very important. A prime function with excessive
 memory use will soon consume all of the system's memory.
 
 Here's another primes function which performs quite well.
 
 primes :: [Int]
 primes = 2 : filter (isPrime primes) [3,5..]  where
   isPrime (p:ps) n
 | mod n p == 0 = False
 | p*p  n  = True
 | otherwise= isPrime ps n
   isPrime [] _ = False -- never used, but avoids compiler warning
 
 Here's some results from my PC, for generating primes to 10^8.
 
  10**6  10**7   10**8
   secs MiB   secs MiB   secs  MiB
   ---
 1 0.01   00.1   2  2   14
 2 0.56   7   11.1  43270  306
 3 0.61   7   11.8  44260  342
 4 0.43  365.4 345900 not finished
 
 1 using a Haskell ST Array
 2 your primes function
 3 my primes function, listed above
 4 Melissa O'Neil method from primes 0.1.1 package
 
 To summarise the results from the tests I've run:
 - if you want fast functional primes, forget it, its not possible.
 - if you just want fast primes, then use C, or a Haskell array.
 - if performance does not matter and slow primes are acceptable, then
 use the purely functional approach.
 
 Regards,
 Steve
 


you just have a fast PC that's all, :) so a million is not enough for you. My
old laptop is 50 times slower. :)

Seriously though, your conclusions seem entirely plausible to me. My goal here
was to have a Haskell code for primes, that is decent. Nothing more.

The reason your code is slightly slower is of course that in effect it
recalculates the needed primes prefix for each new candidate. If you could
somehow thread its length through, it might have sped it up some more.

I've just tried it and it was twice slower than mine. (?) I didn't use the [Int]
signature in both. Maybe it's not real issues we're dealing with here, but
compiler/OS/CPU issues? (or have you've forgotten to put the [Int] signature
into my code too, when tested? It runs twice as fast with it). Although your
code has an advantage that it is very easy to add the wheel optimization to it.

BTW I don't know about the code in the package, but the one in the article makes
terrible faux-pas of adding each prime into the queue as soon as it is produced;
this could easily account for a memory blow-up you're seeing. What's really
needed, is to plug a decent PQ implementation into my framework, which does
absolute minimum of repeated calculations it seems.

What I have now, is this:

 qprimes   = 2: 3: sieve emptyQ primes' 5  where
  primes'  = tail qprimes
  sieve q (p:ps) x  
   = h ++ sieve (addQ q' (2*p) (p*p+2*p)) ps (p*p+2)  
 where
   (h,q') = noComps q [x,x+2..p*p-2] 
  ..

The main deficiency of list-based sieves, as I've now came to realize and
formulate in simple enough terms for myself to understand, is that they work
with each number in isolation, and thus must test primes as well as composites.
Testing composites on average is cheap, because most of them will have small
factors; testing primes is costly.

Imperative sieves avoid that by working over spans of numbers at once, so they
get their primes for free, when they see gaps in produced/marked composites (I
repeat myself here, but am not sure if you've read this my explanation in other
posts). What counts here, is the direct access to random memory - or the numbers
written out on a blackboard. Melissa's PQ approach tries to emulate that. Not
crossing them off, but seeing the gaps in between.

One is tempted to treat Haskell as high-level executable definition, hoping for
a compiler to turn it into the fastest possible low-level code. I know I can
translate it into C by hand fairly well; why wouldn't the compiler? It seems
Haskell compilers have much room for improvement. :)





___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: ANN: haskell-mode 2.6

2009-11-03 Thread Svein Ove Aas
On Sun, Nov 1, 2009 at 8:20 PM, Svein Ove Aas svein@aas.no wrote:
 Fellow haskellers:

 Haskell-mode 2.6 has been released.

2.6.2 is now out.

This is a pure bugfix release; it fixes some parse issues in
haskell-decl-scan and haskell-indentation.


-- 
Svein Ove Aas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] socket error

2009-11-03 Thread Alberto G. Corona
socket: 1796: hPutBuf: illegal operation (handle is finalized)

I´m a bit lost trying to find the source of this error.
I´m running an hack application  (package hack). Basically it is a handler
of web requests.
hack can be used with different web servers: Hyena, simpleserver,
HappStack
all of them produce this error after a few interactions.,  Supposedly, it
happens within the socket module
since neither my module, nor hack, nor the hack simpleserver (package
hack-handler-simpleserver) call explicitly hPutBuf

I tried to reproduce the error under linux, but my ubuntu installation is
too old and I´m in the process of reinstalling everything again.

In the meantime, Any of you can give me any hint about the error?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: socket error

2009-11-03 Thread Alberto G. Corona
I´m running windows, ghc 6.10.3  and 6.10.4 in two different machines.

2009/11/3 Alberto G. Corona agocor...@gmail.com

 socket: 1796: hPutBuf: illegal operation (handle is finalized)

 I´m a bit lost trying to find the source of this error.
 I´m running an hack application  (package hack). Basically it is a handler
 of web requests.
 hack can be used with different web servers: Hyena, simpleserver,
 HappStack
 all of them produce this error after a few interactions.,  Supposedly, it
 happens within the socket module
 since neither my module, nor hack, nor the hack simpleserver (package
 hack-handler-simpleserver) call explicitly hPutBuf

 I tried to reproduce the error under linux, but my ubuntu installation is
 too old and I´m in the process of reinstalling everything again.

 In the meantime, Any of you can give me any hint about the error?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Stephen Tetley
2009/11/3 Andrew Coppin andrewcop...@btinternet.com:


 As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is
 notionally very similar to Haskell, but with lots of added clutter,
 complexity and general ugliness - but it's probably somehow more
 machine-efficient as a result.

 (All of which makes the name Clean rather ironic, IMHO.)


Ouch - you really could put it the other way round.

Clean has very little clutter, though I suppose some people might take
offence to it having simple macros (:==), but wait so does GHC via
-XCPP...

I think Clean had generics before Haskell had Data.Generics, otherwise
Haskell generally has more innovation, more people work on Haskell,
Haskell's motivation was language research...

Clean has far fewer libraries, more people use Haskell...

Clean used to be considered faster than Haskell, though I don't know
what the situation is now:
http://www.haskell.org/pipermail/haskell-cafe/2007-October/033854.html

Clean is a very fine language, if I wasn't using Haskell I know what
my alternative choice would be.

Best wishes

Stephen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: dbus-core 0.5 and dbus-client 0.1

2009-11-03 Thread John Millikin
The purpose behind the weird signature there is so that the
computations in DBus.Bus can be passed directly to mkClient. Because
of the design of dbus-client, you probably don't want to keep the
connection around separately.

-
client - mkClient getSessionBus
-


Here's a quick-and-dirty skeleton for sending notifications:
-
{-# LANGUAGE OverloadedStrings #-}
import DBus.Bus
import DBus.Client
import DBus.Types

-- Definition of notification object / interface
notifications = Proxy (RemoteObject
(mkBusName' org.freedesktop.Notifications)
(mkObjectPath' /org/freedesktop/Notifications))
(mkInterfaceName' org.freedesktop.Notifications)

-- Callbacks; in real systems, these would probably be more complex
onError x = putStrLn (ERROR\n\n ++ show x ++ \n\n)
onReturn x = putStrLn (RETURN\n\n ++ show x ++ \n\n)

-- A real library might accept additional parameters
-- by the way: signature of Notify() is susssasa{sv}i
notify c = call' params onError onReturn where
params = [{- build parameters for your library here -}]
call' = call client notifications (mkMemberName' Notify) []

main = do
client - mkClient getSessionBus
notify client
{- main loop / mvar / whatever your library uses -}
-

On Tue, Nov 3, 2009 at 14:07, Max Rabkin max.rab...@gmail.com wrote:
 Hi John

 I'm trying to implement a pure Haskell library for notifications (like
 libnotify). Unfortunately I don't know my way around dbus too well.

 Is there a reason for

 mkClient :: IO (Connection, BusName) - IO Client

 instead of

 mkClient :: Connection - IO Client

 ?

 mkClient simply discards the bus name, so in the event that one
 doesn't have a bus name, one must create a fake one. Also, it executes
 the IO action right away, so there is no need for it to take an IO
 argument. All in all, this means I must write

 getClient = mkClient (flip (,) undefined $ getSessionConnection)

 instead of

 getClient = mkClient = getSessionConnection.

 Perhaps you have a good reason for it?

 Regards,
 Max

 On Fri, Oct 30, 2009 at 11:44 PM, John Millikin jmilli...@gmail.com wrote:
 These are pure-Haskell client libraries for using the D-Bus protocol.
 D-Bus is heavily used for inter-application IPC on Free and
 open-source desktop platforms, such as Linux, OpenSolaris, and
 FreeBSD. These libraries allow applications written in Haskell to
 inter-operate with other components of recent GNOME, KDE, and XFCE
 desktops.

 This is the first real release of these libraries; dbus-core has
 been published on Hackage for some time, but mostly just to make sure
 I got the Cabal bits right. I feel they are now stable / featureful
 enough for public use.

 Both are available on Hackage:

 http://hackage.haskell.org/package/dbus-core
 http://hackage.haskell.org/package/dbus-client

 -

 dbus-core is an implementation of the D-Bus protocol, specifically
 the parts relevant to clients. Eventually, it will probably grow some
 functions useful for implementing a message bus as well. It includes
 type mapping / conversion, an implementation of the wire format
 (marshaling / unmarshaling), data types for the currently defined
 message types (METHOD_CALL, METHOD_RETURN, ERROR, and SIGNAL) and a
 basic parser / generator for introspection documents. It is roughly
 equivalent in purpose to libdbus.

 By itself, a protocol implementation is somewhat cumbersome to use, so
 dbus-client is a high-level wrapper. It provides some abstractions
 like remote object proxies, exported object trees, synchronous method
 calls, signal reception, and name reservation. Messages are received
 and processed in separate IO threads, allowing asynchronous method
 call and signal handling.

 The purpose between splitting the library into two packages is
 stability; dbus-core, ideally, will change only rarely --
 performance improvements, new message / data types, etc. It provides a
 base level of functionality which more specialised libraries may use.
 dbus-client is an example of what such a library could look like,
 though for now it's not very Haskell-y (IO everywhere, exceptions,
 explicit locking). By separating the protocol from the client libs,
 alternative client libs can safely depend on the protocol
 implementation.

 -

 To see a sample of the library working, there's a clone of the
 dbus-monitor utility in dbus-core/Examples. Documentation is
 currently a bit lacking, so for now, the best documentation is the PDF
 of the source code itself, and the (rather barren) Haddock output:

 https://dl.getdropbox.com/u/1947532/dbus-core_0.5.pdf
 https://dl.getdropbox.com/u/1947532/dbus-core_0.5/index.html

 https://dl.getdropbox.com/u/1947532/dbus-client_0.1.pdf
 https://dl.getdropbox.com/u/1947532/dbus-client_0.1/index.html

 Once more people have used it without any major API issues, I'll write
 up a manual and populate the Haddock entries.

 Please respond with any feedback, difficulties, or suggestions. I'm
 particularly 

Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread wren ng thornton

Roman Leshchinskiy wrote:

On 04/11/2009, at 13:23, Daniel Peebles wrote:


In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on
what operations they are paired with. We need to think of a better way
to express this behavior in the documentation though.


I have to disagree here. Fusion never makes the complexity of operations 
worse. If it does, it's a bug.


I think the point was more that the relevant complexity bound can change 
in the presence of fusion. For a poor example: the first map over a list 
is O(n) but all subsequent ones in a chain of maps are O(1) with fusion. 
I'm sure there are better examples than that, but you get the idea. Some 
people may care to know about that latter complexity rather than just 
the independent complexity.


While this comes up with fusion, it's not a new problem. The same sort 
of thing is gotten at by distinguishing worst-case vs average-case 
complexity, or amortized worst-case vs non-amortized wost-case, etc.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Don Stewart
briand:
 Really, arrays in Haskell are the most @#!$! confusing thing in the  
 world.

 There's a bunch of different array structures.

 I can't tell which one works best, and all I want to do is x[i] = value.

 I thought uvector was the answer, you know, fast unboxed ARRAYs.   
 Imagine my surprise when I saw this

   indexU :: UA e = UArr e - Int - e

   O(n). indexU extracts an element out of an immutable unboxed array.

Umm That's a typo in the docs. Thanks.

-- Don

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Fair diagonals

2009-11-03 Thread Louis Wasserman
+1 on Control.Monad.Omega.  In point of fact, your diagN function is simply

diagN = runOmega . mapM Omega

You'll find it an interesting exercise to grok the source of
Control.Monad.Omega, obviously, but essentially, you're replacing concatMap
with a fair (diagonal) traversal order version.

Louis Wasserman
wasserman.lo...@gmail.com
http://profiles.google.com/wasserman.louis
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Gauss Elimination - More Clean2Haskell

2009-11-03 Thread Don Stewart
phi500ac:
 import Control.Monad
 import Data.Array.IO

You're using boxed arrays here -- try Data.Array.Unboxed and IOUArray's
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Erik de Castro Lopo
David Leimbach wrote:

 Disciplined Disciple might be interesting to look at here too, but i'm not
 sure I'd deploy anything with DDC just yet :-)

Indeed. What DDC needs most at the moment is more people working
on it.

I've fixed a couple of bugs and I'm working on some others, but
there are a large chunk of them in the bug tracker which are
simply too deep for me with my current level of knowledge.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Evan Laforge
 So what's the deal with Clean? Why is it preferable to Haskell? Why is it not?

Purely from glancing through the language reference, two things that
it looks like clean has that I would love to have in haskell are
better records and better arrays.  The records don't implement any of
the fancy subtyping stuff that the various haskell proposals do, but
they have the benefits of a nicer syntax and actually being
implemented.

Haskell arrays (by which I mean the IArray and MArray interfaces) are,
to me at least, really hard to use.  From little things like using
closed ranges where the rest of the world uses half-open ones and
opaque documentation and no consistency between IArray and MArray, to
bigger things like how do you insert or delete something.  My
conclusion, after wrestling with ixmap for 15 minutes, was to convert
to a list, concatMap across [(i, a)], convert back to an array, which
has the bonus of runtime crashes if you forget an 'i'.

Sorry if this turned into a rant about arrays, but it's bothered me
for a while :)  I think the clean guys got it right when they decided
to make good array support an explicit goal.  I suppose haskell has
since gone a different way with the various array fusion libraries
with listlike interfaces, and maybe that's better in the long term.
Maybe type families can make a nice interface someday.  Meanwhile it's
a mess though.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread David Leimbach
On Tue, Nov 3, 2009 at 3:14 PM, Ben Lippmeier ben.lippme...@anu.edu.auwrote:

 David Leimbach wrote:

 Disciplined Disciple might be interesting to look at here too, but i'm not
 sure I'd deploy anything with DDC just yet :-)

 :) Nor would I (and I wrote most of it). I think the approach is right, but
 the compiler itself is still in the research prototype stage.

 Ben.


I have to admit, the first time I hit the wiki page for DDC I said to myself
Self, this sounds crazy complicated.  Then I read part of the PDF (your
thesis I believe) about Region Types on the bus ride to work and thought.
 Gee I think I scared myself off too quickly.

Uniqueness typing is quite interesting in Clean, but to control aliasing,
like really *control* aliasing, that's just far out man.

So I still have to wrap my head around why this isn't going to get
completely out of control and see why it's all safer than just writing C
code but I must say the attention I will be paying to DDC has just gone
quite a bit up.

Dave
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread David Leimbach
On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh tracy.wadle...@gmail.comwrote:


 I had to implement a ring buffer, and I wanted the code using it to be
 written in Haskell.  I ended up implementing the buffer in C, and wrapping
 it in FFI from Haskell because implementing a destructive array in Haskell
 is kind of unwieldy to someone of my experience level.  In Clean, it looks
 like the uniqueness typing allows for destructive updates in a very
 controlled manner.


 The ST monad provides this functionality. The
 never-instantiated-in-a-visible-way state parameter of the ST monad provides
 the uniqueness required for doing destructive updates in a pure way.


Someone suggested that to me on IRC once I'd already cranked out a C
implementation with FFI bindings.  It's just too easy to use the FFI in
Haskell :-)

If we raise the barrier of FFI, more people will use ST!

Dave




 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Fwd: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Tracy Wadleigh
 I had to implement a ring buffer, and I wanted the code using it to be
 written in Haskell.  I ended up implementing the buffer in C, and wrapping
 it in FFI from Haskell because implementing a destructive array in Haskell
 is kind of unwieldy to someone of my experience level.  In Clean, it looks
 like the uniqueness typing allows for destructive updates in a very
 controlled manner.


The ST monad provides this functionality. The
never-instantiated-in-a-visible-way state parameter of the ST monad provides
the uniqueness required for doing destructive updates in a pure way.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Andrew Coppin

Deniz Dogan wrote:

Recently there has been a lot of discussion on this list about the
programming language Clean and converting Clean programs to Haskell.
Reading the Wikipedia article on the language, I can't really see any
major difference between that and Haskell, except for the monads vs.
uniqueness types.

So what's the deal with Clean? Why is it preferable to Haskell? Why is it not?
  


As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean 
is notionally very similar to Haskell, but with lots of added clutter, 
complexity and general ugliness - but it's probably somehow more 
machine-efficient as a result.


(All of which makes the name Clean rather ironic, IMHO.)

Of course, this is merely the opinion I formed after performing a 
cursory scan of some of the introductory documentation. I haven't 
actually seen any code written with it or anything, so my opinion 
probably doesn't mean a lot...


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread wren ng thornton

Stephen Tetley wrote:

2009/11/3 Andrew Coppin andrewcop...@btinternet.com:


As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is
notionally very similar to Haskell, but with lots of added clutter,
complexity and general ugliness - but it's probably somehow more
machine-efficient as a result.

(All of which makes the name Clean rather ironic, IMHO.)


Ouch - you really could put it the other way round.


Part of this really comes down to how one feels about the monads vs 
uniqueness types argument. It's a silly argument to have since the ideas 
are orthogonal and only really intersect at IO, but there's history 
there which lead to the current state of things.


Sometimes in Haskell I've thought about how uniqueness typing would make 
something faster, but in general all the plumbing associated with it in 
Clean makes me feel like I'm writing systems-level code (i.e. C, asm) 
instead of using a high-level language. The extra plumbing really makes 
it feel dirtier to work with. That doesn't mean Clean is bad, but I 
think it does contribute to the cluttered feeling Haskellers get.


But as I said, it's a silly argument and folks should use whichever 
gives them warm fuzzies. I also have a vague unnameable distaste 
whenever working with Python, and rather enjoy working with Perl. 
Nobody's perfect :)


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Gregory Crosswhite
Actually, it's not a typo.  If you look at the source, what you'll see  
is


indexU arr n = indexS (streamU arr) n

and then tracking down indexS, you'll see


indexS (Stream next s0 _) n0
| n0  0= error Data.Array.Vector.Stream.indexS: negative  
index

| otherwise = loop_index n0 s0
  where
loop_index n s = case next s of
  Yield x s' | n == 0- x
 | otherwise - s' `seq` loop_index (n-1) s'
  Skips' - s' `seq` loop_index  ns'
  Done   - error  
Data.Array.Vector.Stream.indexS: index too large



So in other words, indexU really does have O(n) complexity since it  
first converts the array into a stream and then walks down the stream  
in order to find the desired element.


Cheers,
Greg


On Nov 3, 2009, at 6:25 PM, Roman Leshchinskiy wrote:


On 04/11/2009, at 13:12, brian wrote:


indexU :: UA e = UArr e - Int - e

O(n). indexU extracts an element out of an immutable unboxed array.


This is a typo (unless Don inserted a nop loop into the original DPH  
code).


Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Fair diagonals

2009-11-03 Thread Martijn van Steenbergen

Dear café,

I am looking for a function that does an N-dimensional diagonal 
traversal. I want the traversal to be fair: the sum of the indices of 
the produced combinations should be non-decreasing. Let me illustrate 
with an example.


The type of a 2-dimensional traversal would look like this:

diag2 :: [a] - [b] - [(a, b)]


The first two arguments are the two half-axes of the grid and the result 
is a fair diagonal traversal of all the points. For example:

diag2 [1,2,3] [4,5,6,7]

[(1,4),(2,4),(1,5),(3,4),(1,6),(2,5),(1,7),(3,5),(2,6),(2,7),(3,6),(3,7)]


Of course the function should work on infinite lists:

diag2 [1..] [1..]

[(1,1),(2,1),(1,2),(3,1),...


Or a combination of finite and infinite lists:

diag2 [1,2] [1..]

[(1,1),(2,1),(1,2),(1,3),(2,2),(1,4),...


Notice that in each case the sum of the pairs (which can seen as indices 
in these particular examples) are non-decreasing:

let sums = map (uncurry (+))
sums $ diag2 [1,2,3] [4,5,6,7]

[5,6,6,7,7,7,8,8,8,9,9,10]

sums $ diag2 [1..] [1..]

[2,3,3,4,4,4,5,5,5,5,6,...

sums $ diag2 [1,2] [1..]

[2,3,3,4,4,5,5,6,6,7,7,...


Similarly for 3 dimensions the type would be:

diag3 :: [a] - [b] - [c] - [(a, b, c)]


For N dimensions we have to sacrifice some generality and ask all axes 
to be of the same type and produce lists instead of tuples, but I'm 
perfectly happy with that:

diagN :: [[a]] - [[a]]


I have implemented diag2 and diag3 [1] but noticed that the function 
bodies increase in size exponentially following Pascal's triangle and 
have no clue how to generialize to N dimensions. Can you help me write 
diagN?


Bonus points for the following:
* An infinite number of singleton axes produces [origin] (and finishes 
computing), e.g. forall (infinite) xs. diagN (map (:[]) xs) == map (:[]) xs
* For equal indices, the traversal biases to axes that are occur early 
in the input (but I don't know how to formalize this).

* The implementation shows regularity and elegance.

Many thanks,

Martijn.

[1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id=11515
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Don Stewart
stephen.tetley:
 2009/11/3 Andrew Coppin andrewcop...@btinternet.com:
 
 
  As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is
  notionally very similar to Haskell, but with lots of added clutter,
  complexity and general ugliness - but it's probably somehow more
  machine-efficient as a result.
 
  (All of which makes the name Clean rather ironic, IMHO.)
 
 Clean used to be considered faster than Haskell, though I don't know
 what the situation is now:
 http://www.haskell.org/pipermail/haskell-cafe/2007-October/033854.html

We've come a long way in 5 years. Haskell is almost always faster  on
the shootout now. And parallelism goes a long way to helping there:


http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=ghclang2=cleanbox=1

Though this is also true on a single core:


http://shootout.alioth.debian.org/u64/benchmark.php?test=alllang=ghclang2=cleanbox=1
  

It's just a lot closer. Clean continues to have a very small memory
footprint.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread brian
Really, arrays in Haskell are the most @#!$! confusing thing in the  
world.


There's a bunch of different array structures.

I can't tell which one works best, and all I want to do is x[i] = value.

I thought uvector was the answer, you know, fast unboxed ARRAYs.   
Imagine my surprise when I saw this


  indexU :: UA e = UArr e - Int - e

  O(n). indexU extracts an element out of an immutable unboxed array.

An array implementation with an order N lookup.  huh ??  That's not an  
array, that's a list.  I was looking for an array.


However, I then found in the same hackage:

  readMU :: MUArr e s - Int - ST s e

  O(1). readMU reads the element at the specified index of a mutable  
unboxed array.


So O(1) for mutable, but O(n) for immutable ? See, confusing...  I'm  
sure there's a really good, lofty type safety, something

or other reason for that, that I'm sure I don't care about ;-)

There's also ST.  So why is there a uvector, when there's ST ??

etc, etc, etc...

and then there's monads...

other than that, having fun with haskell :-)

Brian


On Nov 3, 2009, at 3:42 PM, David Leimbach wrote:




On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh tracy.wadle...@gmail.com 
 wrote:


I had to implement a ring buffer, and I wanted the code using it to  
be written in Haskell.  I ended up implementing the buffer in C, and  
wrapping it in FFI from Haskell because implementing a destructive  
array in Haskell is kind of unwieldy to someone of my experience  
level.  In Clean, it looks like the uniqueness typing allows for  
destructive updates in a very controlled manner.


The ST monad provides this functionality. The never-instantiated-in- 
a-visible-way state parameter of the ST monad provides the  
uniqueness required for doing destructive updates in a pure way.


Someone suggested that to me on IRC once I'd already cranked out a C  
implementation with FFI bindings.  It's just too easy to use the FFI  
in Haskell :-)


If we raise the barrier of FFI, more people will use ST!

Dave



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread ajb

G'day all.

Quoting wren ng thornton w...@freegeek.org:


Sometimes in Haskell I've thought about how uniqueness typing would
make something faster, but in general all the plumbing associated with
it in Clean makes me feel like I'm writing systems-level code (i.e. C,
asm) instead of using a high-level language. The extra plumbing really
makes it feel dirtier to work with. That doesn't mean Clean is bad, but
I think it does contribute to the cluttered feeling Haskellers get.


I think you're right here.

Haskell has developed something of an aversion to naming things that
aren't important enough to have a name, such as variables whose only
reason to exist is plumbing.  We'd far rather spend effort on more
higher-order functions, monads, combinators and points-freeness than
name something that's unimportant.  And the funny thing about this is
that it usually works, because in Haskell, abstraction is cheap.

I believe that this is the main reason why Haskell programmers haven't
embraced arrows, despite their theoretical advantages: Every notation
that has been implemented so far requires names for things that shouldn't
need names.


But as I said, it's a silly argument and folks should use whichever
gives them warm fuzzies.


I'd like to think that professional developers are a bit more scientific
than this.

Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Roman Leshchinskiy

On 04/11/2009, at 13:23, Daniel Peebles wrote:


In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on
what operations they are paired with. We need to think of a better way
to express this behavior in the documentation though.


I have to disagree here. Fusion never makes the complexity of  
operations worse. If it does, it's a bug.


Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Daniel Peebles
In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on
what operations they are paired with. We need to think of a better way
to express this behavior in the documentation though.

On Tue, Nov 3, 2009 at 9:12 PM, brian bri...@aracnet.com wrote:
 Really, arrays in Haskell are the most @#!$! confusing thing in the world.

 There's a bunch of different array structures.

 I can't tell which one works best, and all I want to do is x[i] = value.

 I thought uvector was the answer, you know, fast unboxed ARRAYs.  Imagine my
 surprise when I saw this

  indexU :: UA e = UArr e - Int - e

  O(n). indexU extracts an element out of an immutable unboxed array.

 An array implementation with an order N lookup.  huh ??  That's not an
 array, that's a list.  I was looking for an array.

 However, I then found in the same hackage:

  readMU :: MUArr e s - Int - ST s e

  O(1). readMU reads the element at the specified index of a mutable unboxed
 array.

 So O(1) for mutable, but O(n) for immutable ? See, confusing...  I'm sure
 there's a really good, lofty type safety, something
 or other reason for that, that I'm sure I don't care about ;-)

 There's also ST.  So why is there a uvector, when there's ST ??

 etc, etc, etc...

 and then there's monads...

 other than that, having fun with haskell :-)

 Brian


 On Nov 3, 2009, at 3:42 PM, David Leimbach wrote:



 On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh tracy.wadle...@gmail.com
 wrote:

 I had to implement a ring buffer, and I wanted the code using it to be
 written in Haskell.  I ended up implementing the buffer in C, and wrapping
 it in FFI from Haskell because implementing a destructive array in Haskell
 is kind of unwieldy to someone of my experience level.  In Clean, it looks
 like the uniqueness typing allows for destructive updates in a very
 controlled manner.

 The ST monad provides this functionality. The
 never-instantiated-in-a-visible-way state parameter of the ST monad provides
 the uniqueness required for doing destructive updates in a pure way.

 Someone suggested that to me on IRC once I'd already cranked out a C
 implementation with FFI bindings.  It's just too easy to use the FFI in
 Haskell :-)

 If we raise the barrier of FFI, more people will use ST!

 Dave



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Are all arrows functors?

2009-11-03 Thread George Pollard
See also the paper Idioms are oblivious, arrows are meticulous,
monads are promiscuous [1]. Functors can be extended to give
applicative functors (idioms) which can then be extended to arrows,
and then monads. So all arrows are also (applicative) functors.


[1]: 
http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Best Editor In Windows

2009-11-03 Thread Gregory Crosswhite
The problem with Leo is that although there are rarely performance  
problems when navigating and editing the outline, the text pane can be  
very slow at times when using the Tk-based GUI --- even on modern  
hardware --- because the syntax highlighter is written in Python.   
(Incidentally, as much as I love Leo, I also hold it up as an example  
of how slow scripting languages aren't always fast enough as their  
proponents claim.  :-) )


There are two solutions to this:  First, you can use the Qt-based Leo  
GUI, which uses the native C++ colorizer built into QtScintilla, which  
I have never had any performance problems with.  Since you  
(reasonably) really like haskell-mode in Emacs, though, you can  
alternatively use the Emacs plugin so that you end up using Leo to  
navigate through your code to the chunk that you want to edit, and  
then using Emacs to do the actual editing.  This might sound like an  
awkward setup, but I actually find that navigating in this way  
requires much less mental energy than scanning through multiple flat  
files to pick out the code that you want to edit next, and the plugin  
makes this type of workflow fairly painless.


Viewing Leo as a meta-editor is a good way to think about it.

Cheers,
Greg


On Nov 3, 2009, at 12:26 PM, Gour wrote:


On Tue, 3 Nov 2009 03:15:03 -0800 (PST)

Philippos ==  phi50...@yahoo.ca wrote:


Philippos I tryed it, and noticed that it is very slow, compared both
Philippos with Emacs, TextPad, and Emerald.

Is it usable (btw, what hardware?) or just slow?

Philippos I tryed also leksah, but it is always complaining about
Philippos something missing in Pango, although it works fine.

I'd prefer to stay with Emacs and its haskell-mode as editor-tool, but
Leo might come handy as meta-editor.


Sincerely,
Gour

--

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Roman Leshchinskiy

On 04/11/2009, at 13:12, brian wrote:


 indexU :: UA e = UArr e - Int - e

 O(n). indexU extracts an element out of an immutable unboxed array.


This is a typo (unless Don inserted a nop loop into the original DPH  
code).


Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Gauss Elimination - More Clean2Haskell

2009-11-03 Thread Philippos Apolinarius
I am keeping with my project of translating programs from Clean to Haskell. As 
far as arrays go, I don't understand well how to use them in Haskell. 
Therefore, I will appreciate if somebody can find time to check the program 
below, and make suggestions to improve it. My Haskell program is about 4 times 
slower than the Clean version. It would be great if one could reduce the 
execution time by half, approaching to the speed of Clean and Scheme. Here are 
the constraints:

1 --- The program must be implemented using arrays.  Update must be done in 
place, in order to minimize use of the garbage collector. I have used 
Data.Array.IO, but I guess that  Data.Array.ST is better. Is it easy to rewrite 
the program in order to use DataArray.ST?

2 --  I liked very much the forM_ monad. I wonder if there is an accumulating 
monad that play the role of a program like leftSide.

3 -- Clean program almost double its speed, if one uses strictness annotations. 
Is it possible to use similar anotations for Haskell?

Here is how I compiled the program:

ghc -O2 gel.hs --make

In order to run the program with 2000 equations,  type

gel.exe 2000 +RTS -sstderr

The program will create a linear system with 2000 equations so that all 
elements of the solution is equal to 1. It prints 20 elements of the solution.

Here is the program:

{- File: gel.hs
Compilation: ghc -O2 gel.hs --make
Run: time gel.exe 2000
-}
import Control.Monad
import Data.Array.IO
import System.IO
import System.Random
import System (getArgs)

prtSol i n1 arr | i  1= return ()
prtSol i n1 arr= do
    b - readArray arr (i, n1)
    putStr ((show b)++ )
    prtSol (i-1) n1 arr

fillArray xs s (i, n) (j, m) arr |  i  n= return ()
fillArray xs s (i,n) (j, m) arr | i==n  jm= do
  writeArray arr (i, j) s
  return ()
fillArray xs s (i, n) (j, m) arr | j  m  = do
   writeArray arr (i, j) s
   fillArray xs 0.0 (i+1, n) (1, m) arr
fillArray (val:xs) s (i, n) (j, m) arr= do
   writeArray arr (i, j) val
   fillArray xs (s+val) (i, n) (j+1, m) arr

sLU arr n= sIJ 2 1 2 n arr

sIJ i j k n arr | i  n = return ()
sIJ i j k n arr | k  n = sIJ (i+1) i (i+1) n arr
sIJ i j k n arr = do
  im - pmax (j+1) j
  swap j im 1
  a - readArray arr (k, j)
  forM_ [j..n+1] $  \l - do
  ajj - readArray arr (j, j)
  ajl - readArray arr (j, l)
  akl - readArray arr (k, l) 
  writeArray arr (k, l) (akl-a*(ajl/ajj))
  sIJ i j (k+1) n arr where
 pmax line imax | line  n = return imax
 pmax line imax = do
   alj - readArray arr (line, j)
   aij - readArray arr (imax, j)
   if (abs alj) (abs aij) 
  then pmax (line+1) line
  else pmax (line+1) imax
 swap r s q | qn+1 = return ()
 swap r s q | r==s = return ()
 swap r s q = do
    arq - readArray arr (r,q)
    asq - readArray arr (s,q)
    writeArray arr (s,q) arq
    writeArray arr (r,q) asq
    swap r s (q+1)
 
  
leftSide acc i j n arr | jn= return acc
leftSide acc i j n arr = do
   v - readArray arr (j, n+1)
   a - readArray arr (i, j)
   leftSide (acc-v*a) i (j+1) n arr

solvit i n arr | i1= return ()
solvit i n arr= do
   a - readArray arr (i, i)
   acc - readArray arr (i, n+1)
   v - leftSide acc i (i+1) n arr
   writeArray arr (i, n+1) (v/a)
   solvit (i-1) n arr

rnList :: (Double, Double) - IO [Double]
rnList r=getStdGen=(\x-return(randomRs r x))

dims [input] = (read input, read input)
dims _ = (1000, 1000)

main = do
 xs - rnList (1.0,1000.0)
 args - getArgs
 let (n, m)= dims args
 arr - newArray_ ((1,1),(n,m+1)) :: 
    IO (IOUArray (Int, Int) Double)
 fillArray xs 0.0 (1,n) (1,m) arr
 sLU arr n
 solvit n n arr
 prtSol (min 20 n) (n+1) arr
 print Done




  __
Be smarter than spam. See how smart SpamGuard is at giving junk email the boot 
with the All-new Yahoo! Mail.  Click on Options in Mail and switch to New Mail 
today or register for free at http://mail.yahoo.ca___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Fair diagonals

2009-11-03 Thread Luke Palmer
On Tue, Nov 3, 2009 at 1:42 PM, Martijn van Steenbergen
mart...@van.steenbergen.nl wrote:
 Dear café,

 I am looking for a function that does an N-dimensional diagonal traversal. I
 want the traversal to be fair: the sum of the indices of the produced
 combinations should be non-decreasing. Let me illustrate with an example.

 The type of a 2-dimensional traversal would look like this:

 diag2 :: [a] - [b] - [(a, b)]

I believe you can get what you want using the diagonal function from
Control.Monad.Omega.

product xs ys = [ [ (x,y) | y - ys ] | x - xs ]
diag2 xs ys = diagonal (product xs ys)

I think if you separate taking the cartesian product and flattening
it, like this, you might have an easier time wrangling all the
different variants you want.

Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: Best Editor In Windows

2009-11-03 Thread Gour
On Tue, 3 Nov 2009 03:15:03 -0800 (PST)
 Philippos ==  phi50...@yahoo.ca wrote:

Philippos I tryed it, and noticed that it is very slow, compared both
Philippos with Emacs, TextPad, and Emerald. 

Is it usable (btw, what hardware?) or just slow?
 
Philippos I tryed also leksah, but it is always complaining about
Philippos something missing in Pango, although it works fine. 

I'd prefer to stay with Emacs and its haskell-mode as editor-tool, but
Leo might come handy as meta-editor.


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6



signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Deniz Dogan
Recently there has been a lot of discussion on this list about the
programming language Clean and converting Clean programs to Haskell.
Reading the Wikipedia article on the language, I can't really see any
major difference between that and Haskell, except for the monads vs.
uniqueness types.

So what's the deal with Clean? Why is it preferable to Haskell? Why is it not?

-- 
Deniz Dogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Ben Lippmeier

David Leimbach wrote:
Disciplined Disciple might be interesting to look at here too, but i'm 
not sure I'd deploy anything with DDC just yet :-)
:) Nor would I (and I wrote most of it). I think the approach is right, 
but the compiler itself is still in the research prototype stage.


Ben.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Gauss Elimination - More Clean2Haskell

2009-11-03 Thread Ryan Ingram
On Tue, Nov 3, 2009 at 12:02 PM, Philippos Apolinarius
phi50...@yahoo.ca wrote:
 1 --- The program must be implemented using arrays.
 Update must be done in place, in order to minimize use of the garbage 
 collector.
  I have used Data.Array.IO, but I guess that  Data.Array.ST is better. Is it 
 easy to
 rewrite the program in order to use DataArray.ST?

It should be pretty easy as long as the rest is pure; ST is a subset
of I/O that deals with algorithms that have mutable variables/arrays
but no observable side-effects.  ST safely guarantees that no
side-effects escape to somewhere they can be observed through a clever
type-system trick.

 2 --  I liked very much the forM_ monad. I wonder if there is an accumulating 
 monad that play the role of a program like leftSide.

forM_ is just a function; it works for all monads.  Probably just a
terminology error?

 3 -- Clean program almost double its speed, if one uses strictness 
 annotations. Is it possible to use similar anotations for Haskell?

Yes.  The common ways to do this are to use ! annotations in data
structures, like so:

] data Foo s = Foo !Int !Int !(STArray s (Int,Int) Double)

You also can use seq and/or $! to guide the evaluation order of your
expressions:

   x - readArray a (1,1)
   writeArray a (1,1) $! (x+1)   -- forces x+1 to evaluate instead of
writing a thunk.

If you really care about speed, you probably want to look into
STUArrays; these store unboxed values and should be about as fast as a
C array.

Now to the stylistic comments:

You can use guards better to not repeat yourself so often:

 prtSol i n1 arr | i  1= return ()
 prtSol i n1 arr= do
     b - readArray arr (i, n1)
     putStr ((show b)++ )
     prtSol (i-1) n1 arr

becomes

] prtSol i n1 arr
]| i  1 = return ()
]| otherwise = do
]   b - readArray arr (i, n1)
]   putStr ((show b)++ )
]   prtSol (i-1) n1 arr

Similarily:

 fillArray xs s (i, n) (j, m) arr |  i  n= return ()
 fillArray xs s (i,n) (j, m) arr | i==n  jm= do

this branch doesn't need do because writeArray returns ()

   writeArray arr (i, j) s
   return ()
 fillArray xs s (i, n) (j, m) arr | j  m  = do
    writeArray arr (i, j) s
    fillArray xs 0.0 (i+1, n) (1, m) arr
 fillArray (val:xs) s (i, n) (j, m) arr= do
    writeArray arr (i, j) val
    fillArray xs (s+val) (i, n) (j+1, m) arr

] fillArray xs s (i, n) (j, m) arr
]| i  n= return ()
]| i==n  jm = writeArray arr (i, j) s
]| j  m  = do
]   writeArray arr (i, j) s
]   fillArray xs 0.0 (i+1, n) (1, m) arr
]| otherwise = do
]   writeArray arr (i, j) val
]   fillArray xs (s+val) (i, n) (j+1, m) arr

I'll let someone else show you how to build this into a fold.

  -- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread David Leimbach
On Tue, Nov 3, 2009 at 1:37 PM, Andrew Coppin
andrewcop...@btinternet.comwrote:

 Deniz Dogan wrote:

 Recently there has been a lot of discussion on this list about the
 programming language Clean and converting Clean programs to Haskell.
 Reading the Wikipedia article on the language, I can't really see any
 major difference between that and Haskell, except for the monads vs.
 uniqueness types.

 So what's the deal with Clean? Why is it preferable to Haskell? Why is it
 not?



 As far as I can tell, Clean is to Haskell as C is to Pascal. I.e., Clean is
 notionally very similar to Haskell, but with lots of added clutter,
 complexity and general ugliness - but it's probably somehow more
 machine-efficient as a result.

 (All of which makes the name Clean rather ironic, IMHO.)

 Of course, this is merely the opinion I formed after performing a cursory
 scan of some of the introductory documentation. I haven't actually seen any
 code written with it or anything, so my opinion probably doesn't mean a
 lot...


It's preferable to Haskell in situations where Haskell isn't the best
choice.

The criteria for that decision is different from problem to problem.

Example:

I had to implement a ring buffer, and I wanted the code using it to be
written in Haskell.  I ended up implementing the buffer in C, and wrapping
it in FFI from Haskell because implementing a destructive array in Haskell
is kind of unwieldy to someone of my experience level.  In Clean, it looks
like the uniqueness typing allows for destructive updates in a very
controlled manner.

Disciplined Disciple might be interesting to look at here too, but i'm not
sure I'd deploy anything with DDC just yet :-)

Dave



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Arrays in Clean and Haskell

2009-11-03 Thread Philippos Apolinarius
Brian wrote:
 Really, arrays in Haskell are the most @#!$! confusing thing in the world.

Hi, Brian. 
I am having a great difficulty with arrays in Haskell.  In the university where 
I study, functional programming is taught in Clean or in Haskell, depending on 
the professor who is teaching the subject in a given year. One year ago, when I 
took functional programming, the professor used Clean in his classes. I had no 
difficulty in learning how arrays and input/output work in Clean.  In the case 
of arrays, the idea is very simple: One can update arrays, provided that s/he 
does not try to access the old array. Therefore, one needs to make a copy of 
any value of the old array that s/he will use before performing the update; the 
operation that makes copies also provides a new name for the array, that 
obliterates the old name.  In order to get a better feeling of the thing, here 
is the `solvit´ function, in Clean and Haskell (you can consider the # as a 
kind of do):

// Clean
leftSide acc i j n arr | j = n= (acc, arr);
   # (v, arr)= arr![j, n];
 (a, arr)= arr![i, j];
   = leftSide (acc-v*a) i (j+1) n arr;

solvit i n arr | i  0 = arr
  # (a, arr)= arr![i, i];
    (acc, arr)= arr![i, n];
    (v, arr)= leftSide acc i (i+1) n arr;
  = solvit (i-1) n {arr[i, n]= v/a};

-- HASKELL
leftSide acc i j n arr | jn= return acc
leftSide acc i j n arr = do
   v - readArray arr (j, n+1)
   a - readArray arr (i, j)
   leftSide (acc-v*a) i (j+1) n arr

solvit i n arr | i1= return ()
solvit i n arr= do
   a - readArray arr (i, i)
   acc - readArray arr (i, n+1)
   v - leftSide acc i (i+1) n arr
   writeArray arr (i, n+1) $! (v/a)
   solvit (i-1) n arr

And here comes the reason for writing this article. In the previous version of 
the Gauss elimination algorithm, I have imported Data.Array.IO. I also wrote a 
version of the program that imports Data.Array.ST. The problem is that I  don't 
know how to read an STUArray from a file, process it, and write it back to a 
file. Is it possible to transform it into an IOUArray pro tempore, read it, 
make it into an STUArray again in order to process it, and bring it back to 
IOUArray in order to print it? Below,  you will find the Gauss elimination 
program in STUArray (by the way, it is slower than IOUArray). Could you modify 
the main function so it can read array `arr´ from a file, and write the result 
to a file?  Here is the Gauss Elimination for STUArray (the main function is 
the first one; modify it to read the array from a file, and write it back to a 
file):

import Control.Monad
import Control.Monad.ST
import Data.Array.ST
import Data.Array.IO 
import System.IO
import System.Random
import System (getArgs)


main = do
 xs - rnList (1.0,1000.0)
 args - getArgs
 let (n, m)= dims args
 xx -  stToIO $ do
 arr - newArray_ ((1,1),(n,m+1)) :: 
   ST s (STUArray s (Int, Int) Double)
 fillArray xs 0.0 (1,n) (1,m) arr
 sLU arr n
 solvit n n arr
 x1 - readArray arr (1, n+1)
 x2 - readArray arr (1, n+1)
 return [x1, x2]
 print xx


{-  -- Other option:
main = do
 xs - rnList (1.0,1000.0)
 args - getArgs
 let (n, m)= dims args
 print $ runST $ do
 arr - newArray_ ((1,1),(n,m+1)) :: 
   ST s (STUArray s (Int, Int) Double)
 fillArray xs 0.0 (1,n) (1,m) arr
 sLU arr n
 solvit n n arr
 x1 - readArray arr (1, n+1)
 x2 - readArray arr (1, n+1)
 return [x1, x2]
-}   

fillArray xs s (i, n) (j, m) arr |  i  n= return ()
fillArray xs s (i,n) (j, m) arr | i==n  jm= do
  writeArray arr (i, j) $! s
  return ()
fillArray xs s (i, n) (j, m) arr | j  m  = do
   writeArray arr (i, j) $! s
   fillArray xs 0.0 (i+1, n) (1, m) arr
fillArray (val:xs) s (i, n) (j, m) arr= do
   writeArray arr (i, j) $! val
   fillArray xs (s+val) (i, n) (j+1, m) arr

sLU arr n= sIJ 2 1 2 n arr

sIJ i j k n arr | i  n = return ()
sIJ i j k n arr | k  n = sIJ (i+1) i (i+1) n arr
sIJ i j k n arr = do
 {- im - pmax (j+1) j
  swap j im 1 -}
  a - readArray arr (k, j)
  forM_ [j..n+1] $  \l - do
  ajj - readArray arr (j, j)
  ajl - readArray arr (j, l)
  akl - readArray arr (k, l) 
  writeArray arr (k, l) $! (akl-a*(ajl/ajj))
  sIJ i j (k+1) n arr where
 pmax line imax | line  n = return imax
 pmax line imax = do
   alj - readArray arr (line, j)
   aij - readArray arr (imax, j)
   if (abs alj) (abs aij) 
  then pmax (line+1) line
  else pmax (line+1) imax
 swap r s q | qn+1 = return ()
 swap r s q | r==s = return ()
 swap r s q = do
    arq - readArray arr (r,q)
    asq - readArray arr (s,q)
    writeArray arr (s,q) $! arq
    writeArray arr (r,q) $! asq
    swap r s (q+1)
 
  
leftSide acc i j n arr | jn= return acc
leftSide acc i j n arr = do
 

[Haskell-cafe] ANNOUNCE: feldspar-language

2009-11-03 Thread Emil Axelsson
I'm happy to announce the first release of Feldspar, which is an 
embedded domain-specific language with associated code generator mainly 
targeting DSP algorithms. The language is developed in cooperation by 
Ericsson, Chalmers University and Eötvös Loránd University.


Feldspar stands for *F*unctional *E*mbedded *L*anguage for *DSP* and 
*PAR*allelism.


The language front-end is available on Hackage:

  http://hackage.haskell.org/package/feldspar-language

The back-end C code generator will be uploaded and announced shortly. 
For more information, see:


  http://feldspar.sourceforge.net/

/ Emil

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: feldspar-language

2009-11-03 Thread Warren Henning
I see that section 4.1 of the user guide -
http://feldspar.sourceforge.net/documents/language/FeldsparLanguage.html#htoc23
- includes an example involving autocorrelation.

Does this mean I could use Feldspare to easily build my own Autotune
program? I love T-Pain and Autotune the News!

Warren

On Tue, Nov 3, 2009 at 7:39 PM, Emil Axelsson e...@chalmers.se wrote:
 I'm happy to announce the first release of Feldspar, which is an embedded
 domain-specific language with associated code generator mainly targeting DSP
 algorithms. The language is developed in cooperation by Ericsson, Chalmers
 University and Eötvös Loránd University.

 Feldspar stands for *F*unctional *E*mbedded *L*anguage for *DSP* and
 *PAR*allelism.

 The language front-end is available on Hackage:

  http://hackage.haskell.org/package/feldspar-language

 The back-end C code generator will be uploaded and announced shortly. For
 more information, see:

  http://feldspar.sourceforge.net/

 / Emil

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Roman Leshchinskiy

On 04/11/2009, at 13:35, wren ng thornton wrote:


Roman Leshchinskiy wrote:

On 04/11/2009, at 13:23, Daniel Peebles wrote:

In the presence of fusion (as is the case in uvector), it's hard to
give meaningful time complexities for operations as they depend on
what operations they are paired with. We need to think of a better  
way

to express this behavior in the documentation though.
I have to disagree here. Fusion never makes the complexity of  
operations worse. If it does, it's a bug.


I think the point was more that the relevant complexity bound can  
change in the presence of fusion. For a poor example: the first map  
over a list is O(n) but all subsequent ones in a chain of maps are  
O(1) with fusion. I'm sure there are better examples than that, but  
you get the idea. Some people may care to know about that latter  
complexity rather than just the independent complexity.


I think asymptotic complexity is the wrong tool for what you're trying  
to do. You implement your algorithm using operations with known  
complexities. This allows you to compute the complexity of the entire  
algorithm. That's all you can use operation complexities for. The  
compiler is then free to optimise the algorithm as it sees fit but is  
supposed to preserve (or improve) its complexity. It is not guaranteed  
or even supposed to preserve the original operations. To stay with  
your example, each of the two maps is linear regardless of whether  
fusion happens. Executing the two maps, be it one after another or  
interlocked, is linear simply because O(n) + O(n) = O(n), not because  
of fusion.


Essentially, you're trying to use complexity to describe an  
optimisation which doesn't actually affect the complexity.


Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Roman Leshchinskiy

On 04/11/2009, at 14:07, Gregory Crosswhite wrote:

Actually, it's not a typo.  If you look at the source, what you'll  
see is


indexU arr n = indexS (streamU arr) n


I suspect it gets rewritten back to the O(1) version somewhere after  
is has had a chance to fuse. If not, then it's a bug. In the vector  
package, I do this instead, though:


indexU arr n = O(1) implemetation

{-# RULES

indexU/unstreamU  forall s n. indexU (unstreamU s) n = indexS s n

#-}

Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Arrays in Clean and Haskell

2009-11-03 Thread Jason Dusek
  How do you read in the IOUArray? By parsing a character string
  or do you treat the file as binary numbers or ... ?

--
Jason Dusek
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Nice addition to Foreign: castAny

2009-11-03 Thread John Meacham
On Tue, Oct 27, 2009 at 12:48:32AM -0200, Maurí­cio CA wrote:
 This could be beside castPtr, castCharToCChar etc.

 

 castAny :: (Storable a, Storable b) = a - b
 castAny = unsafePerformIO . genericCast
   where
 genericCast :: (Storable a, Storable b) = a - IO b
 genericCast v = return undefined = \r -
   allocaBytes (max (sizeOf v) (sizeOf r)) $ \p -
 poke p v  if False then return r else peek (castPtr p)

 

 GHCi:

 let a = -1000 :: Int16
 castAny a :: Word16  --
64536
 castAny a :: Ptr ()
0xb4c2fc18
 castAny (castAny a :: Ptr ()) :: Int16
-1000

 let b = pi :: CLDouble
 b
3.141592653589793
 castAny b :: CInt
1413754136
 castAny b :: Ptr ()
0x54442d18
 castAny b :: CFloat
3.3702806e12
 castAny b :: Int8
24


 At minimum, this is safer than 'unsafeCoerce'. What do you think?

Try it on a big endian architecture, or one that has alignment
restrictions, or a different size for HsChar or so forth. Casting by
'punning' (as the C folks like to call it) does have uses, but they are
generally hardware dependent and useful only in certain rare
circumstances that a generic cast probably isn't likely to fill.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Arrays in Clean and Haskell

2009-11-03 Thread brian


On Nov 3, 2009, at 7:38 PM, Philippos Apolinarius wrote:


Brian wrote:
 Really, arrays in Haskell are the most @#!$! confusing thing in  
the world.


Hi, Brian.
I am having a great difficulty with arrays in Haskell.  In the  
university where I study, functional programming is taught in Clean  
or in


me too :-)

And here comes the reason for writing this article. In the previous  
version of the Gauss elimination algorithm, I have imported


you're asking me ??  I have no idea.  I can't even figure out which  
package to use.


However if I had to guess, it seems to me that you want to read the  
data into a list and then find some ST function which can initialize  
an array using a list (maybe ?)


Brian

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Arrays in Clean and Haskell

2009-11-03 Thread Roman Leshchinskiy

On 04/11/2009, at 14:38, Philippos Apolinarius wrote:

And here comes the reason for writing this article. In the previous  
version of the Gauss elimination algorithm, I have imported  
Data.Array.IO. I also wrote a version of the program that imports  
Data.Array.ST. The problem is that I  don't know how to read an  
STUArray from a file, process it, and write it back to a file.


Why don't you use the IOUArray directly instead of converting it to  
STUArray and back?


Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Hugs Trex for GHC / JHC / UHC / ... ?

2009-11-03 Thread John Meacham
On Thu, Oct 08, 2009 at 11:13:42PM +0200, Peter Verswyvelen wrote:
 I briefly read about Hugs record system Trex, and at first sight this
 was really nice!
 
 I know this question was asked a long time ago already, but are there
 any plans to add this extension to GHC?
 
 What about the other compilers, like JHC, UHC, etc?

The most likely record system to be implemented by jhc would be a
variant of Daan Leijen's Extensible records with scoped labels[1].
However, it is not something I will likely get to any time soon.
(contributors welcome of course!)

[1] http://www.cs.ioc.ee/tfp-icfp-gpce05/tfp-proc/21num.pdf

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Richard O'Keefe


On Nov 4, 2009, at 9:30 AM, Deniz Dogan wrote:
So what's the deal with Clean? Why is it preferable to Haskell? Why  
is it not?


(1) Speed.
(2) If you are a Windows developer, the fact that Windows is the primary
platform and others (even Mac OS, which is historically ironic) are
second- (or in the case of Solaris) third-class citizens.
(3) Did I mention speed?
(4) It comes with its own IDE.  I don't think it can do anything much  
that
Haskell tools can't do, but if you don't like looking for things,  
it's

a help.
(5) Plus of course there's speed.
(6) They're working on a Haskell front end, so you won't actually have  
to

choose.  (Anyone doing a Clean front end for Haskell?)
(7) Haskell now has bang-patterns so you can specify (a bound on)  
intended
strictness when you declare a function.  But that's not in  
Haskell 98.

(8) As a result of this, speed is a bit more declarative than adding
$! in strange places.
(9) There's a theorem prover for Clean, called Sparkle.
Sadly, it's Windows-only, but we all know what most computers on  
the

planet run, don't we?  (It's probably Symbian, actually.)
(10) And finally, of course, there's speed.  Did I mention that?



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Don Stewart
Well, it depends on which indexU the OP means. The one linked in the docs is
the O(1) UA type class version.

-- Don

gcross:
 Actually, it's not a typo.  If you look at the source, what you'll see  
 is

 indexU arr n = indexS (streamU arr) n

 and then tracking down indexS, you'll see


 indexS (Stream next s0 _) n0
 | n0  0= error Data.Array.Vector.Stream.indexS: negative  
 index
 | otherwise = loop_index n0 s0
   where
 loop_index n s = case next s of
   Yield x s' | n == 0- x
  | otherwise - s' `seq` loop_index (n-1) s'
   Skips' - s' `seq` loop_index  ns'
   Done   - error Data.Array.Vector.Stream.indexS: 
 index too large


 So in other words, indexU really does have O(n) complexity since it  
 first converts the array into a stream and then walks down the stream in 
 order to find the desired element.

 Cheers,
 Greg


 On Nov 3, 2009, at 6:25 PM, Roman Leshchinskiy wrote:

 On 04/11/2009, at 13:12, brian wrote:

 indexU :: UA e = UArr e - Int - e

 O(n). indexU extracts an element out of an immutable unboxed array.

 This is a typo (unless Don inserted a nop loop into the original DPH  
 code).

 Roman


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Gregory Crosswhite
So I take it you are saying that it really *cleans* Haskell's clock  
when it comes to speed?  ;-)


- Greg


On Nov 3, 2009, at 9:04 PM, Richard O'Keefe wrote:



On Nov 4, 2009, at 9:30 AM, Deniz Dogan wrote:
So what's the deal with Clean? Why is it preferable to Haskell? Why  
is it not?


(1) Speed.
(2) If you are a Windows developer, the fact that Windows is the  
primary

   platform and others (even Mac OS, which is historically ironic) are
   second- (or in the case of Solaris) third-class citizens.
(3) Did I mention speed?
(4) It comes with its own IDE.  I don't think it can do anything  
much that
   Haskell tools can't do, but if you don't like looking for things,  
it's

   a help.
(5) Plus of course there's speed.
(6) They're working on a Haskell front end, so you won't actually  
have to

   choose.  (Anyone doing a Clean front end for Haskell?)
(7) Haskell now has bang-patterns so you can specify (a bound on)  
intended
   strictness when you declare a function.  But that's not in  
Haskell 98.

(8) As a result of this, speed is a bit more declarative than adding
   $! in strange places.
(9) There's a theorem prover for Clean, called Sparkle.
   Sadly, it's Windows-only, but we all know what most computers on  
the

   planet run, don't we?  (It's probably Symbian, actually.)
(10) And finally, of course, there's speed.  Did I mention that?



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Joe Fredette
Given the Shootout results, the difference is a matter of a few  
seconds. If Clean Programmers need those few extra seconds, they're  
welcome to them.


We're Lazy around here. :)

/Joe


On Nov 4, 2009, at 12:16 AM, Gregory Crosswhite wrote:

So I take it you are saying that it really *cleans* Haskell's clock  
when it comes to speed?  ;-)


- Greg


On Nov 3, 2009, at 9:04 PM, Richard O'Keefe wrote:



On Nov 4, 2009, at 9:30 AM, Deniz Dogan wrote:
So what's the deal with Clean? Why is it preferable to Haskell?  
Why is it not?


(1) Speed.
(2) If you are a Windows developer, the fact that Windows is the  
primary

  platform and others (even Mac OS, which is historically ironic) are
  second- (or in the case of Solaris) third-class citizens.
(3) Did I mention speed?
(4) It comes with its own IDE.  I don't think it can do anything  
much that
  Haskell tools can't do, but if you don't like looking for things,  
it's

  a help.
(5) Plus of course there's speed.
(6) They're working on a Haskell front end, so you won't actually  
have to

  choose.  (Anyone doing a Clean front end for Haskell?)
(7) Haskell now has bang-patterns so you can specify (a bound on)  
intended
  strictness when you declare a function.  But that's not in  
Haskell 98.
(8) As a result of this, speed is a bit more declarative than  
adding

  $! in strange places.
(9) There's a theorem prover for Clean, called Sparkle.
  Sadly, it's Windows-only, but we all know what most computers on  
the

  planet run, don't we?  (It's probably Symbian, actually.)
(10) And finally, of course, there's speed.  Did I mention that?



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Gregory Crosswhite
Oh, that's strange...  the type class UA is defined twice, once in  
Data.Array.Vector and once in Data.Array.Vector.UArr;  in the first  
module indexU is a separate function with the sources I exhibited, in  
the second module it is a method of the UA type-class which seems to  
have O(1) access for most of the defined instances.


That's incredibly confusing...

- Greg


On Nov 3, 2009, at 9:15 PM, Don Stewart wrote:

Well, it depends on which indexU the OP means. The one linked in the  
docs is

the O(1) UA type class version.

-- Don

gcross:
Actually, it's not a typo.  If you look at the source, what you'll  
see

is

indexU arr n = indexS (streamU arr) n

and then tracking down indexS, you'll see


indexS (Stream next s0 _) n0
   | n0  0= error Data.Array.Vector.Stream.indexS: negative
index
   | otherwise = loop_index n0 s0
 where
   loop_index n s = case next s of
 Yield x s' | n == 0- x
| otherwise - s' `seq` loop_index (n-1) s'
 Skips' - s' `seq` loop_index  ns'
 Done   - error  
Data.Array.Vector.Stream.indexS:

index too large


So in other words, indexU really does have O(n) complexity since it
first converts the array into a stream and then walks down the  
stream in

order to find the desired element.

Cheers,
Greg


On Nov 3, 2009, at 6:25 PM, Roman Leshchinskiy wrote:


On 04/11/2009, at 13:12, brian wrote:


indexU :: UA e = UArr e - Int - e

O(n). indexU extracts an element out of an immutable unboxed array.


This is a typo (unless Don inserted a nop loop into the original DPH
code).

Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Don Stewart
gcross:
 Oh, that's strange...  the type class UA is defined twice, once in  
 Data.Array.Vector and once in Data.Array.Vector.UArr;  in the first  

No, its exported from the former.

 module indexU is a separate function with the sources I exhibited, in  
 the second module it is a method of the UA type-class which seems to  
 have O(1) access for most of the defined instances.

 That's incredibly confusing...

There's direct and stream-based versions. You can choose which
version you need. If you use the stream-based implementations, the
compiler will apply the stream fusion optimization to your loops. If you
use the direct versions, that won't apply.

I'd be happy to talk more about the design of the library, if you like.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread brian

Don,

There is more than one indexU ?

In Data.Array.Vector there is only 1 indexU that I can find.

Brian

On Nov 3, 2009, at 9:15 PM, Don Stewart wrote:

Well, it depends on which indexU the OP means. The one linked in the  
docs is

the O(1) UA type class version.

-- Don

gcross:
Actually, it's not a typo.  If you look at the source, what you'll  
see

is

indexU arr n = indexS (streamU arr) n

and then tracking down indexS, you'll see


indexS (Stream next s0 _) n0
   | n0  0= error Data.Array.Vector.Stream.indexS: negative
index
   | otherwise = loop_index n0 s0
 where
   loop_index n s = case next s of
 Yield x s' | n == 0- x
| otherwise - s' `seq` loop_index (n-1) s'
 Skips' - s' `seq` loop_index  ns'
 Done   - error  
Data.Array.Vector.Stream.indexS:

index too large


So in other words, indexU really does have O(n) complexity since it
first converts the array into a stream and then walks down the  
stream in

order to find the desired element.

Cheers,
Greg


On Nov 3, 2009, at 6:25 PM, Roman Leshchinskiy wrote:


On 04/11/2009, at 13:12, brian wrote:


indexU :: UA e = UArr e - Int - e

O(n). indexU extracts an element out of an immutable unboxed array.


This is a typo (unless Don inserted a nop loop into the original DPH
code).

Roman


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: CComplex in jhc (was: Word128, Word256)

2009-11-03 Thread John Meacham
On Mon, Oct 26, 2009 at 12:24:39AM -0200, Maurí­cio CA wrote:
  Well, before trying to get it standardized, you need to get it
  implemented and tested by at least one compiler to explore the
  design space and tradeoffs. I would happily accept any patches
  into jhc that a support for such types, I don't even think it
  would be that difficult to do.

 One should say jhc code is really clear. It's the first compiler
 code I try to read and for a moment I actually believed I could
 write the patch :)

excellent :)


 Below is my completely naive attempt. If you want to tell me
 where to go from here, I'll try. (For instance: how do I get
 'rt_bits_double_complex_' to exist.) However, I think this is far
 beyond my skills...

A fairly good first attempt. The main issue is that 'primitives.txt' and
its associated machinery is the old way of defining primitives that is
slowly being phased out. Basically, what primitives.txt did was
centralize a lot of 'compiler magic' as in, it created a lot of
instances for things like Num and Storable that one might expect for
built in types. However, as jhc progressed, it became clear that having
things built into the compiler is a real pain. Hence, for newer
primitives, they are simply implemented in pure haskell. as in,
instead of some magic 'data Int' somewhere and a lot of compiler defined
primitives, we have 'data Int = Int Word32_' and plain instance
declarations like 'instance Num Int where ...' and so forth, with
primitive operators being foreign imported.

So, Double and Float have both been fully converted to the new way of
doing things, so look at their implementation to see how complex
versions of them should be handled. 

John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Don Stewart
UArr operations subject to stream fusion:

http://code.haskell.org/~dons/code/uvector/Data/Array/Vector/Strict/

Direct-style operations, not subject to the optimization:

http://code.haskell.org/~dons/code/uvector/Data/Array/Vector/UArr.hs

/me needs to write a tutorial on this.

-- Don

briand:
 Don,

 There is more than one indexU ?

 In Data.Array.Vector there is only 1 indexU that I can find.

 Brian

 On Nov 3, 2009, at 9:15 PM, Don Stewart wrote:

 Well, it depends on which indexU the OP means. The one linked in the  
 docs is
 the O(1) UA type class version.

 -- Don

 gcross:
 Actually, it's not a typo.  If you look at the source, what you'll  
 see
 is

 indexU arr n = indexS (streamU arr) n

 and then tracking down indexS, you'll see


 indexS (Stream next s0 _) n0
| n0  0= error Data.Array.Vector.Stream.indexS: negative
 index
| otherwise = loop_index n0 s0
  where
loop_index n s = case next s of
  Yield x s' | n == 0- x
 | otherwise - s' `seq` loop_index (n-1) s'
  Skips' - s' `seq` loop_index  ns'
  Done   - error  
 Data.Array.Vector.Stream.indexS:
 index too large


 So in other words, indexU really does have O(n) complexity since it
 first converts the array into a stream and then walks down the  
 stream in
 order to find the desired element.

 Cheers,
 Greg


 On Nov 3, 2009, at 6:25 PM, Roman Leshchinskiy wrote:

 On 04/11/2009, at 13:12, brian wrote:

 indexU :: UA e = UArr e - Int - e

 O(n). indexU extracts an element out of an immutable unboxed array.

 This is a typo (unless Don inserted a nop loop into the original DPH
 code).

 Roman


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] multi-line regex

2009-11-03 Thread Michael Mossey
I have some very simple regex-matching needs, and Text.Regex.Posix will 
work fine, EXCEPT I need to match multi-line patterns, and/or find all 
occurrences of text that may occur several times on different lines. So I 
need to turn on some kind of flag. Can someone show me how to do that? I 
have worked the examples in RWH so I basically know how to run the thing.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] multi-line regex

2009-11-03 Thread Don Stewart
mpm:
 I have some very simple regex-matching needs, and Text.Regex.Posix will  
 work fine, EXCEPT I need to match multi-line patterns, and/or find all  
 occurrences of text that may occur several times on different lines. So I 
 need to turn on some kind of flag. Can someone show me how to do that? I  
 have worked the examples in RWH so I basically know how to run the thing.

Is that something that requires the PCRE bindings?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] multi-line regex

2009-11-03 Thread kenny lu
Hi Michael,

Could you give an example of what patterns you want to write?

Regards,
Kenny

On Wed, Nov 4, 2009 at 1:35 PM, Michael Mossey m...@alumni.caltech.eduwrote:

 I have some very simple regex-matching needs, and Text.Regex.Posix will
 work fine, EXCEPT I need to match multi-line patterns, and/or find all
 occurrences of text that may occur several times on different lines. So I
 need to turn on some kind of flag. Can someone show me how to do that? I
 have worked the examples in RWH so I basically know how to run the thing.
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] multi-line regex

2009-11-03 Thread Michael Mossey



kenny lu wrote:

Hi Michael,

Could you give an example of what patterns you want to write?

Regards,
Kenny



Something like

text = 11\n abcd \n22
answer = text =~ 11.*22 :: various possibilities

and have it find the entire string. The default behavior is to stop 
matching when it encounters a newline. There is mention in the 
Text.Regex.Posix docs of a flag to control this behavior, but it is not 
easy to figure out from the docs how to provide flags. The left-hand side 
of the =~ is a very complex type.





___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] What's the deal with Clean?

2009-11-03 Thread Ben Lippmeier

David Leimbach wrote:
I have to admit, the first time I hit the wiki page for DDC I said to 
myself Self, this sounds crazy complicated.  Then I read part of the 
PDF (your thesis I believe) about Region Types on the bus ride to work 
and thought.  Gee I think I scared myself off too quickly.


Uniqueness typing is quite interesting in Clean, but to control 
aliasing, like really *control* aliasing, that's just far out man.


So I still have to wrap my head around why this isn't going to get 
completely out of control and see why it's all safer than just 
writing C code but I must say the attention I will be paying to DDC 
has just gone quite a bit up.


:) A correct C program is just as safe as a correct Haskell/Disciple 
program.


If you're using destructive update then aliasing, side effects and 
mutability all start to matter. It might look complicated when you 
reflect all these things in the type system, but you're really just 
getting a handle on the inherent complications of the underlying program.


I suppose the trick is to be able to ignore said complications when you 
just don't care, or they're not relevant for your particular problem...


Ben.







___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Essence of Functional Programming for Imperative Programmers

2009-11-03 Thread Shelby Moore
New concise guide I am creating:

http://www.coolpage.com/commentary/economic/shelby/Functional_Programming_Essence.html

I was able to condense Category theory and implementation of Monads to one
screen:

http://www.coolpage.com/commentary/economic/shelby/Functional_Programming_Essence.html#Monads

Overall, I think I have a unique method for comparing and condensing the
explanation of the transistion from imperative to pure functional.  What
you think?

It is a work-in-progress, so corrections, feedback, and flames are
welcome.  I will do the OOP section next and incorporate the explanations
from these posts:

http://www.haskell.org/pipermail/haskell-cafe/2009-November/068440.html
(data vs. Module)
http://www.haskell.org/pipermail/haskell-cafe/2009-November/068432.html
(interface vs. virtual)

P.S. The link will not change if you want to link to it now.  If you
mirror it, please update your mirrors periodically.  There is no copyright
claimed, I don't believe in copyrights any more.  I intend to publish
everything as PUBLIC DOMAIN (i.e. no license at all, because licenses
impact composability).  If I want to charge, I will put functionality
behind an unpublished interface (i.e. Module).

P.P.S. I only started learning functional programming about a week ago.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe