Re: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Hugh Perkins]

On 8/30/07, Miguel <[EMAIL PROTECTED]> wrote:
> What about running Haskell on a PostScript printer? PostScript IS 
> Turing-complete.

Yes, because postscript printers are famous for being really fast ;-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Hugh Perkins]

Dan Piponi <[EMAIL PROTECTED]> wrote:
> http://developer.nvidia.com/object/cuda.html
>
> It's a C compiler with multiprocessor streaming extensions that
> targets nvidia cards.

Whoa :-O Cool :-)

> But it's not that simple...

Few things are ;-)  Whats the catch?  Can we use a graphics-card as an
n-core machine, where n >= 1024?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Bulat Ziganshin]

Hello Miguel,

Thursday, August 30, 2007, 9:40:08 AM, you wrote:

> What about running Haskell on a PostScript printer? PostScript IS 
> Turing-complete.

it would be cool to port SOE graphics to PostScript engine :)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re[2]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Bulat Ziganshin]

Hello Hugh,

Thursday, August 30, 2007, 11:01:02 AM, you wrote:

>> But it's not that simple...

> Few things are ;-)  Whats the catch?  Can we use a graphics-card as an
> n-core machine, where n >= 1024?

no. it's more like 8-16 cores with 64-element SSE instructions

http://developer.download.nvidia.com/compute/cuda/0_8/NVIDIA_CUDA_Programming_Guide_0.8.pdf


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] interaction between OS processes

[Andrea Rossato]

Hi,

there's something I don't get about interaction among OS processes and
Haskell handles/channels.

Suppose I have a very small program that takes a line and prints it
till you write "quit":

main = do
  s <- getLine
  case s of
"quit" -> putStrLn "quitting" >> return ()
_ -> loop s
  where
loop s = do
 putStrLn s
 main

This is a small interactive process I would like to talk to from
another Haskell program, like the following one which, indeed, is just
a wrapper around the first.

Now, if I write a single line with "quit", I get "quitting" back,
otherwise the program doesn't work.

I think I need some direction in order to understand how handles
work. The same with channels, I'm afraid. Could you please point me
in the right direction?

Thanks for your kind attention.
Andrea

The not working code:

import Control.Concurrent
import System.Process
import System.IO

main = do
  c <- runInteractiveCommand "./main2"
  loop c

loop c@(i,o,e,p) = do
  s <- getLine
  hPutStrLn i s
  hFlush i -- now "i" is closed, right?
  s' <- hGetLine o
  putStrLn s'
  loop c 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re[2]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Hugh Perkins]

So, according to the blurb, and since this is product-specific, I dont
know if this is allowed on the newsgroup?, but it does seem to be a
fairly unique product? :

- this technology works on GeGForce 8800 cards or better
- there's a dedicated processing unit available called the "Tesla",
which is available in a standalone version that you can plug into a
PCI port, or in various pre-built 1U servers.  The Tesla standalone
card:

- 128 thread processor
- 518 gigaflops
- 1.5 GB dedicated memory
- Fits in one full-length, dual slot with one open PCI Express x16 slot
- Retails for about 1500usd (so, I can afford one, I guess)

For anyone who's counting, some sources put the computational capacity
of the human brain at around 10petaflops, so 20,000 of these
processors ought to be approaching that. (At a cost of 30 million
dollars ;-)  )

Anyway, 128 threads, if it is true, sounds fun.  It's not
1024-threads, but it's decent, and it's more than the 32-threads where
automatic threading is rumoured to bottom out.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[4]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Bulat Ziganshin]

Hello Hugh,

Thursday, August 30, 2007, 2:46:51 PM, you wrote:

> - this technology works on GeGForce 8800 cards or better

afaik, on any 8xxx cards - the only difference is number of threads

> - 128 thread processor

it's the same as 8800GTX. please read CUDA manual first. these 128
threads are not independent, each 8 or 16 threads execute the same
code

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] Re: GHC optimisations

[Simon Marlow]

Simon Peyton-Jones wrote:

GHC does some constant folding, but little by way of strength reduction, or 
using shifts instead of multiplication.  It's pretty easy to add more: it's all 
done in a single module.  Look at primOpRules in the module PrelRules.


Although it isn't done at the Core level as Simon says, GHC's native code 
generator does turn multiplies into shifts, amongst various other low-level 
optimisations.  In fact it's not clear that this kind of thing *should* be 
done at a high level, since it's likely to be machine-dependent.


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

Re: [Haskell-cafe] Haskell on the Playstation 3? :-)

[David Roundy]

On Thu, Aug 30, 2007 at 11:03:35AM +0400, Bulat Ziganshin wrote:
> Hello Miguel,
> 
> Thursday, August 30, 2007, 9:40:08 AM, you wrote:
> 
> > What about running Haskell on a PostScript printer? PostScript IS 
> > Turing-complete.
> 
> it would be cool to port SOE graphics to PostScript engine :)

I spent some time a few years back figuring out how to use TH to "compile"
haskell to postscript, but I didn't really know what I was doing and did a
pretty poor job.  But I'd love to have a postscript compiler.  It's *so*
nice to be able to produce compact and readable postscript files (which you
could with compiled code, in the sense that the data portion of the
file--which is what you want to read anyhow--would be readable).  I've
often wrote C code to write postscript code, which has the advantage of
giving viewable output that also has the raw data in a format that is both
computer-readable and human-readable.  It'd be much nicer to do this in
Haskell.
-- 
David Roundy
http://www.darcs.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for suggestions to improve my algorithm

[Chaddaï Fouché]

I managed it in 7 seconds (on 1500 MHz) with an idea close to yours
(but I used IntSet, not IntMap), Daniel Fisher gave you some good
ideas to achieve it, the real snail in this problem is the sumDivisors
function.

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

Re: [Gtk2hs-users] [Haskell-cafe] Bug in Gtk2HS 0.9.12/SOE on WinXP? Or is it just me?

[Duncan Coutts]

On Fri, 2007-08-24 at 11:58 +0200, Malte Milatz wrote:
> Peter Verswyvelen <[EMAIL PROTECTED]>:
> > However, in the code below the blue and green triangle should render on top 
> > of each other, but the green triangle is rendered incorrectly.
> > 
> > Being a newbie, I hesitate to file a bug report... Can anyone reproduce 
> > this? Maybe it works fine on unix?
> 
> I can reproduce this with 0.9.12.

I think this is now fixed. It's included in the current Gtk2Hs darcs
repo or if you want to use your existing Gtk2Hs-0.9.12 installation you
can get the updated soegtk package from hackage:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/soegtk

Duncan

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

Re: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Brandon S. Allbery KF8NH]

On Aug 30, 2007, at 2:34 , Radosław Grzanka wrote:


obsolete and Pocket PC is probably better target. Anyway, does anyone
else experience a feeling that at the time of buying yourself new
gadget you are already in "deprecated zone"? ;)


I've been feeling that way since 1982

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Brandon S. Allbery KF8NH]

On Aug 30, 2007, at 3:00 , Hugh Perkins wrote:


On 8/30/07, Miguel <[EMAIL PROTECTED]> wrote:
What about running Haskell on a PostScript printer? PostScript IS  
Turing-complete.


Yes, because postscript printers are famous for being really fast ;-)


You youngsters don't remember when PostScript printers *were* faster  
than the workstations they were connected to.  :)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] 2D game graphics library for Haskell?

[Duncan Coutts]

On Fri, 2007-08-24 at 12:31 +0200, peterv wrote:

> Anyway, SOE is great for learning Haskell, but it lacks a couple of
> fundamental functions to make it really attractive, like:

> -   Support for images
> 
> -   Support for rendering to an “offscreen graphics surface” and
> reading the pixels from that surface (for pixel-wise collision
> detection)
> 
> -   Support for detecting non-ASCII key presses (cursor keys, etc)
> 
> -   Support for joysticks

> Concurrent Clean seems to have a nice 2D game library and PLT/DrScheme
> also has nice support for basic 2D graphics, but somehow I feel
> Haskell is more mature and more elegant. 

> So before digging into “advanced” APIs (like GTK itself, which I know
> nothing about, I’m a Win32 GDI/XNA/WPF expert), I should ask the
> question if something similar exists? It has to be as simple as SOE.

Would it be possible to extend the GTK SOE with support for the features
mentioned above? Is this insanely difficult for someone like me who
knows a lot about Win32 but little Haskell?

Graphics.SOE.Gtk is actually based on a very nice vector graphics
library Graphics.Rendering.Cairo which can certainly do nice things like
rendering to off-screen surfaces and much more besides, like
transparency, arbitrary affine scaling/rotation/translation. It can load
and save images in png and svg formats. It's also got a rather nice API,
so instead of trying to extend the GTK SOE you might find it simpler
just to use Cairo directly.

Gtk+'s event processing can certainly detect non-ASCII key presses, it's
just the SOE getKey api that's limited to Char. I've no idea how
joystick input is implemented in X/Gtk, I expect it's possible.

The other alternative though it's getting more low level, is to use the
Haskell bindings for SDL.

Duncan

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

Re: [Haskell-cafe] defining mapPairs function

[Devin Mullins]

That's great (really, thank you for such a fun example of Arrow 
programming), but isn't the (*) on line two of mapPair supposed to be a 
"point"? How would you make a point-less version of mapPair that 
actually had the type signature (a->a->a)->[a]->[a]*? (For that matter, 
/would/ you?)


Devin
* Grr, you're right. Were it not for that odd requirement, the type 
could be loosened to (a->a->b)->[a]->[b]. Maybe mapPairs should take a 
monadic (that is, one-arg) function to handle the dangling oddies.


Dan Weston wrote:

import Control.Arrow((&&&),(>>>))
import Data.Maybe(catMaybes,maybeToList)

mapPair = (id &&& tail   >>>  -- offset list by one
   uncurry (zipWith (*)) >>>  -- multiply adjacent
   alternate >>>  -- mark   even elements
   catMaybes) -- delete even elements

 &&&  -- Tuple this up with...

  (alternate >>>  -- keep odd indices
   (Nothing:)>>>  -- make sure there is a last
   last  >>>  -- get last
   maybeToList)   -- keep if it had odd index

 >>>  -- and then...

  uncurry (++)-- append pair of lists

  where alternate = zipWith ($) (cycle [Just,const Nothing])
  -- Mark even-indexed elements for deletion
  -- cycle goes on forever, but zipWith stops at
  -- the end of the shorter list, so no worries.

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

Re: Re[4]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Hugh Perkins]

On 8/30/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> it's the same as 8800GTX. please read CUDA manual first. these 128
> threads are not independent, each 8 or 16 threads execute the same
> code

H, yes you are right.  The GPU contains 8 "multiprocessors", where
each multiprocessor contains multiple processors that execute the same
code at the same time ("data parallel").

There are 8 processors in each multiprocessor unit, which run at twice
the clock speed, so in one clock cycle they can execute 16 threads;
and in two clock cycles they can execute all 32 threads of a "warp"
(group of threads running the same code).

Sooo kindof an interesting architecture. To what extent do we
think that this is representative of future "general-purpose"
multi-core architectures?

Looking at Haskell parallelization, things like maps, and folds of
associative functions can be split across the threads of a single
warp.  On the other hand, things like independent lets that we want to
run in parallel would need to be assigned to independent warps.

On the whole, maps and folds may constitute the bulk of what we are
trying to parallelize (certainly, SPJ's NDP focuses extensively on
maps), so this is probably broadly compatible with the CUDA
architecture?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for suggestions to improve my algorithm

[Chaddaï Fouché]

2007/8/30, Chaddaï Fouché <[EMAIL PROTECTED]>:
> I managed it in 7 seconds (on 1500 MHz) with an idea close to yours
> (but I used IntSet, not IntMap), Daniel Fisher gave you some good
> ideas to achieve it, the real snail in this problem is the sumDivisors
> function.
>
I put my final solution on the wiki, it get it done in 6s now (on a
Pentium M 1.73Mhz).

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

Re: Re[4]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Dan Piponi]

On 8/30/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:

> On the whole, maps and folds may constitute the bulk of what we are
> trying to parallelize (certainly, SPJ's NDP focuses extensively on
> maps), so this is probably broadly compatible with the CUDA
> architecture?

Right. But the functions and data that we are trying to map and fold
could be anything, so we are required to have the full functionality
of Haskell running on the GPU - unless the compiler can smartly figure
out what should run on the GPU and what shouldn't. All in all, this
could be a fairly ambitious project.

Another, more modest, approach would be to define a DSL, maybe along
the lines of what Lennart Augustsson has been doing on his blog
(http://augustss.blogspot.com/), and implement a compiler back end
that generates GPU code from the DSL. Something similar for C++ is
Michael McCool's Sh library
(www.csee.umbc.edu/~olano/s2005c37/ch07.pdf) which has now developed
into a more general purpose commercial product. It seems to me that
this could be a killer application for Haskell without a major rewrite
of the Haskell compiler. What's more, the same DSL could have
different back ends targeting GPUs, multiple cores or even just single
CPUs (where you'd still get the benefits of partial evaluation).
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] let and fixed point operator

[Peter Hercek]

Hi,

I find the feature that the construct "let x = f x in expr"
 assigns fixed point of f to x annoying. The reason is that
 I can not simply chain mofifications a variable like e.g. this:

f x =
  let x = x * scale in
  let x = x + transform in
  g x

When one is lucky then it results in a compile error; in worse
 cases it results in stack overflow in runtime. The annoying
 part is figuring out new and new variable names for essentially
 the same thing to avoid the search/evaluation of the fixed point.

I suppose Haskell was designed so that it makes sense. The only
 usage I can see is like this:

let fact = \x -> if x == 0 then 1 else x * fact (x-1) in

  ... but that is not any shorter than:

let fact x = if x == 0 then 1 else x * fact (x-1) in

So the question is what am I missing? Any nice use cases where
 fixed point search is so good that it is worth the trouble with
 figuring out new and new variable names for essentially the same
 stuff?

Peter.

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

Re: [Haskell-cafe] let and fixed point operator

[Dan Piponi]

On 8/30/07, Peter Hercek <[EMAIL PROTECTED]> wrote:

> f x =
>let x = x * scale in
>let x = x + transform in
>g x

Why are you trying to call three different things by the same name 'x'
in one tiny block of code? That's very confusing and makes it hard to
reason equationally about the code.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[Brent Yorgey]

On 8/30/07, Peter Hercek <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I find the feature that the construct "let x = f x in expr"
>   assigns fixed point of f to x annoying. The reason is that
>   I can not simply chain mofifications a variable like e.g. this:
>
> f x =
>let x = x * scale in
>let x = x + transform in
>g x
>
> When one is lucky then it results in a compile error; in worse
>   cases it results in stack overflow in runtime. The annoying
>   part is figuring out new and new variable names for essentially
>   the same thing to avoid the search/evaluation of the fixed point.
>
> I suppose Haskell was designed so that it makes sense. The only
>   usage I can see is like this:
>
> let fact = \x -> if x == 0 then 1 else x * fact (x-1) in
>
>... but that is not any shorter than:
>
> let fact x = if x == 0 then 1 else x * fact (x-1) in
>
> So the question is what am I missing? Any nice use cases where
>   fixed point search is so good that it is worth the trouble with
>   figuring out new and new variable names for essentially the same
>   stuff?
>
> Peter.


This is not really about fix points, it is about the very essence of
functional programming.  You cannot "modify" variables in the way you are
suggesting; a variable such as x must *always refer to the same thing*
within a given scope.  This is not a liability, but rather a very nice
thing: it makes it much easier to reason about programs if a given name
always refers to the same thing.  In an imperative language, where you
really can modify the contents of variables, you do not have this
guarantee.  The same variable could refer to different values at different
points in the program, which can lead to much confusion.

Now, I do understand your annoyance; it certainly is annoying to type
something like

f x =
  let y = x * scale in
  let z = y + transform in
  g z

where you have to come up with a bunch of different names for the
intermediate values. But it's actually possible to do this in a much nicer
way which is idiomatic in a functional language such as Haskell.  Note that
what you are really doing here is sending x through a "pipeline" of
functions which transform it into another value.  The way to combine
functions into a pipeline is by using function concatenation:

f = g . (+ transform) . (* scale)

This is exactly the same thing, but no annoying intermediate names in
sight!  This simply says that f is the function you get when you first
multiply by scale, then add transform, then finally apply function g.  If
you don't like the "point-free" style, you could also write something like

f x = g $ (+ transform) $ (* scale) $ x

(The $ simply lets you avoid writing lots of parentheses.)


Hope this helps,
-Brent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: let and fixed point operator

[Peter Hercek]

1 f x =
2let x = x * scale in
3g x

Hmmm ... just assume that the scope of the x on line 3 (which
 hides the x from the higher level scope is extended from line 3 to
 the beginning part of line 2 (from line start to the equal sign).
 OCAML does it. "Let before" in Clean does it too. Does not sound
 bad to me either. So this sounds to me like weak argument compared
 to disadvantages. There should be something else (I'm missing)
 there too...

Thanks,
   Peter.

Dan Piponi wrote:

On 8/30/07, Peter Hercek <[EMAIL PROTECTED]> wrote:


f x =
   let x = x * scale in
   let x = x + transform in
   g x


Why are you trying to call three different things by the same name 'x'
in one tiny block of code? That's very confusing and makes it hard to
reason equationally about the code.
--
Dan


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

Re: [Haskell-cafe] let and fixed point operator

[Ketil Malde]

On Thu, 2007-08-30 at 18:17 +0200, Peter Hercek wrote:

> I find the feature that the construct "let x = f x in expr"
>   assigns fixed point of f to x annoying. 

Any alternative?  Non-recursive assignments?

> f x =
>let x = x * scale in
>let x = x + transform in
>g x

I think it is often it is better to avoid temporary names.  I guess this
is a simplified example, but I think it is better to write:

  f x = g (transform + scale * x)

Or even use point-free style to avoid fixpoint?

   f = g . (+transform) . (* scale)

-k


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

Re: [Haskell-cafe] let and fixed point operator

[Brent Yorgey]

On 8/30/07, Brent Yorgey <[EMAIL PROTECTED]> wrote:
>
>
>
>   The way to combine functions into a pipeline is by using function
> concatenation:
>

Oops, of course I meant "function composition" instead of "function
concatenation".

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

Re: [Haskell-cafe] let and fixed point operator

[Derek Elkins]

On Thu, 2007-08-30 at 18:17 +0200, Peter Hercek wrote:
> Hi,
> 
> I find the feature that the construct "let x = f x in expr"
>   assigns fixed point of f to x annoying. The reason is that
>   I can not simply chain mofifications a variable like e.g. this:
> 
> f x =
>let x = x * scale in
>let x = x + transform in
>g x

The common answer is that such code is considered ugly in most
circumstances.  Nevertheless, one solution would be to use the Identity
monad and write that as,
f x = runIdentity $ do 
x <- x*scale
x <- x + transform
return (g x)

> 
> When one is lucky then it results in a compile error; in worse
>   cases it results in stack overflow in runtime. The annoying
>   part is figuring out new and 
> new variable names for essentially
>   the same thing to avoid the search/evaluation of the fixed point.
> 
> I suppose Haskell was designed so that it makes sense. The only
>   usage I can see is like this:
> 
> let fact = \x -> if x == 0 then 1 else x * fact (x-1) in
> 
>... but that is not any shorter than:
> 
> let fact x = if x == 0 then 1 else x * fact (x-1) in
> 
> So the question is what am I missing? Any nice use cases where
>   fixed point search is so good that it is worth the trouble with
>   figuring out new and new variable names for essentially the same
>   stuff?
> 
> Peter.

Haskell is lazy, we can have (mutually) recursive values.  The canonical
example,
fibs = 0:1:zipWith (+) fibs (tail fibs)
Slightly more interesting,
karplusStrong = y
where y = map (\x -> 1-2*x) (take 50 (randoms (mkStdGen 1)))
   ++ zipWith (\x y -> (x+y)/2) y (tail y)

However, the real point is that you shouldn't be naming and renaming the
"same" thing.  Going back to your original example, it would be nicer to
most to write it as,
f = g . transform displacement . scale factor
or pointfully
f x = g (transform displacement (scale factor x))
with the appropriate combinators.

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

Re: [Haskell-cafe] let and fixed point operator

[Andrew Coppin]

OK, so it's only tangentally related, but... do you have *any idea* how 
many times I've written something like


 let x = (some complex function of x)
 in (some other complex function of x)

when in fact what I *meant* to do was type x' instead of x?!

It's really maddening to write 50,000 lines of code, eventually get it 
to compile, run it, and have the program lock up and start consuming so 
much virtual memory that the entire PC becomes unstable within seconds. 
(This isn't helped by the fact that Ctrl+C doesn't seem to make either 
GHCi or GHC-compiled programs halt...) Now you have 50,000 lines of 
otherwise untested code, and there's a bug within it *somewhere*... good 
luck.


Obviously you might very well have *meant* to write x = f x. But would 
it be possible to add some kind of optional compiler warning to find 
such assignments? It can be a nightmare trying to track down where you 
made the mistake...


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

[Haskell-cafe] Re: let and fixed point operator

[Peter Hercek]

Derek Elkins wrote:

On Thu, 2007-08-30 at 18:17 +0200, Peter Hercek wrote:

Hi,

I find the feature that the construct "let x = f x in expr"
  assigns fixed point of f to x annoying. The reason is that
  I can not simply chain mofifications a variable like e.g. this:

f x =
   let x = x * scale in
   let x = x + transform in
   g x


The common answer is that such code is considered ugly in most
circumstances.  Nevertheless, one solution would be to use the Identity
monad and write that as,
f x = runIdentity $ do 
x <- x*scale

x <- x + transform
return (g x)


This is nice but more complicated. The goal should be to have it
 as simple as possible.



Haskell is lazy, we can have (mutually) recursive values.  The canonical
example,
fibs = 0:1:zipWith (+) fibs (tail fibs)
Slightly more interesting,
karplusStrong = y
where y = map (\x -> 1-2*x) (take 50 (randoms (mkStdGen 1)))
   ++ zipWith (\x y -> (x+y)/2) y (tail y)


This is very nice argument! Thanks. I actually used it myself, but did
 not realize it when I was looking for the pro/contra arguments. This
 with the fact that it is not that good style to use the same name for
 intermediate results might be worth it.



However, the real point is that you shouldn't be naming and renaming the
"same" thing.  Going back to your original example, it would be nicer to
most to write it as,
f = g . transform displacement . scale factor
or pointfully
f x = g (transform displacement (scale factor x))
with the appropriate combinators.


Essentially the same idea as the one from Brent Yorgey.
Works fine till the operations can fill easily on one line. Then it does not
 scale that well since when it needs to be on more lines it interferes with
 automatic insertion of curly braces and semicolons by the layout rules (which
 are influenced by the context). Of course when there are more transformations
 it makes sense to name the intermediate results differently, but even few
 transformations may not fit easily when identifier names are long.

Thanks,
Peter.

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

Re: [Haskell-cafe] let and fixed point operator

[Brent Yorgey]

>
> It's really maddening to write 50,000 lines of code, eventually get it
> to compile, run it, and have the program lock up and start consuming so
> much virtual memory that the entire PC becomes unstable within seconds.

(This isn't helped by the fact that Ctrl+C doesn't seem to make either
> GHCi or GHC-compiled programs halt...) Now you have 50,000 lines of
> otherwise untested code, and there's a bug within it *somewhere*... good
> luck.


Well, this is why you should test your program in bits and pieces before you
get to that point.  Writing 50,000 LOC before you even run your first test
is a horrible idea in any programming language.

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

Re: [Haskell-cafe] let and fixed point operator

[David Roundy]

On Thu, Aug 30, 2007 at 06:16:12PM +0100, Andrew Coppin wrote:
> Obviously you might very well have *meant* to write x = f x. But would 
> it be possible to add some kind of optional compiler warning to find 
> such assignments? It can be a nightmare trying to track down where you 
> made the mistake...

If you enable -Wall, ghc will warn you about this, provided that x was
already bound in this context.
-- 
David Roundy
http://www.darcs.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[Dan Piponi]

On 8/30/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
> Obviously you might very well have *meant* to write x = f x. But would
> it be possible to add some kind of optional compiler warning to find
> such assignments?

The thing that convinced me to learn Haskell in the first place was
the fact that you could write x = f x. Equations where you refer to
the same variable on the left and right hand sides are the bread of
butter and mathematics, and I was really pleased to find a programming
language that let me do the same. So to me the idea of having a
warning for this is a bit like putting a sign on bottled water saying
"Warning: Contents may be wet". But that's just me. :-)

Still, it might be useful to for the compiler to warn when a newly
introduced name shadows another one.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[Paul Hudak]

Andrew Coppin wrote:
OK, so it's only tangentally related, but... do you have *any idea* 
how many times I've written something like


 let x = (some complex function of x)
 in (some other complex function of x)

when in fact what I *meant* to do was type x' instead of x?! 


I try not to use primes (x', x'', etc.) on variables for exactly this 
reason, and instead try to use more descriptive names, such as "newx", 
or "y", or whatever.  Of course you can still make typing mistakes, but 
that's always the case...


   -Paul

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

Re: [Haskell-cafe] let and fixed point operator

[jerzy . karczmarczuk]

Brent Yorgey quotes: 


It's really maddening to write 50,000 lines of code, eventually get it
to compile, run it, and have the program lock up and start consuming so
much virtual memory that the entire PC becomes unstable within seconds.
... 

Well, this is why you should test your program in bits and pieces 
before you get to that point.  Writing 50,000 LOC before you even run 
your first test is a horrible idea in any programming language.


I would rephrase this in a more brutal way.
Writing 5 lines of code in a language which seems to be badly mastered
is a suicidary exercice. The let x=f x construct touches the essence of
Haskell, its laziness, and it is used as a co-recursive way to replace
loops. If it appears as the effect of forgetting the prime in x', use
variables with long, meaningful names. This will economize some frustration. 


==
An anecdote.
Hundreds of years ago, when I taught programming in Cracow, Poland, we had
some students from Vietnam (North, of course). One of them wrote programs
where *all* variable names were ... you guess it, Vietnamese.
It was easy to remember for him, no errors, no confusion. 


The only touchy point in this affair was that my group counted also three
Vietnamese girls, who always when the boy with his poker-face produced
publicly his solution, became red and began to giggle, or shouted angrily
something I couldn't understand. 


Had I noted or memorized those programs, I would probably learn a good
collection of particularly succulent Vietnamese swearwords. 

== 

Perhaps you should decorate your program a bit as well? 



Jerzy Karczmarczuk 



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

Re: [Haskell-cafe] let and fixed point operator

[Chaddaï Fouché]

Another interesting example of the x = f x use :

coins = [1,2,5,10,20,50,100,200]

beautiful = foldl (\without p ->
  let (poor,rich) = splitAt p without
  with = poor ++
 zipWith (++) (map (map (p:)) with)
  rich
  in with
 ) ([[]] : repeat [])

I don't remember who wrote this code (I rewrote it from memory since
it impressed me quite a bit), but it's a very fast and beautiful (in
my eyes at least) solution to the "menu" problem :
(beautiful coins !! 200) would give you all the set of coins you could
use to pay for 200, in less than 40ms on my computer...

But, even more trivial... You use this all the time when you define
recursive function, you know ? You would need to add a "rec" keyword
to the language if you disallowed this.

Myself I'm a big fan of the point-free style (to a limit) and find
that it scale very well indeed when you begin to name the combination
of functions you want to use.

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

[Haskell-cafe] Newbie question: Why gfoldl has this strange type?

[Rodrigo Geraldo]

Hi!

I am a novice in Haskell, and particularly I have interested in generic
programming. This interest motivated me to read paper Scrap your
boilerplate: A practical design pattern for generic programming, but I
didn't understand the type of the function gfoldl, that was present in class
Term (Data). Somebody could help me to understand the type of this function?

Thanks...

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

Re: [Haskell-cafe] let and fixed point operator

[Albert Y. C. Lai]

Peter Hercek wrote:

So the question is what am I missing? Any nice use cases where
 fixed point search is so good that it is worth the trouble with
 figuring out new and new variable names for essentially the same
 stuff?


When I write functional code, I do find myself writing recursions much 
more often than writing imperative-wannabe assignments. I appreciate 
that Haskell's "let" defaults to recursion. I don't appreciate that 
OCaml makes a distinction between "let" and "letrec", since every time I 
change a non-recursive definition to a recursive one, I am prone to 
forget to change "let" to "letrec", IOW it is a hidden hazard to 
maintenance and evolution.


When I write imperative code in Haskell, the notation is so different 
from functional code that "let" doesn't even come into the equation.


When I write imperative code in imperative languages, my mental model 
treats "x:=x+1" as "x'=x+1 and y'=y and z'=z and ...", following several 
treatises on imperative semantics(*). Going back to functional 
programming, when I do write imperative-wannabe assignments, I totally 
like having names x, x', x'', etc., since they're in my head anyway.


Underlying all this is probably the soberness of recognizing that "=" is 
not ":=".



(*) Such as:

Eric C. R. Hehner, "A Practical Theory of Programming". First edition 
Springer 1993. Current edition at

http://www.cs.toronto.edu/~hehner/aPToP/

C. A. R. Hoare and He Jifeng, "Unifying Theories of Programming". 
Prentice Hall 1998.


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

RE: [Haskell-cafe] let and fixed point operator

[Peter Verswyvelen]

F# and Concurrent Clean introduced special syntax for doing this. Basically
they just invent new names for you.

In Haskell (warning: I'm a newbie, so take this with a grain of salt), I
guess you just use monads if you want to pass a value from one function to
another under some context, or you could just make your own little much
simpler combinator like:

infixl 0 \> -- I just took the first weird symbol combination that came to
mind, this does not mean anything (I hope ;-)

x \> fx = fx x

f x = x * scale \> \x ->
  x + transform \> \x ->
  g x

like this you don't have to invent new names, and you don't have to type
much more.

I'm sure this silly sequencing operator must already exist in the library
somewhere?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Hercek
Sent: Thursday, August 30, 2007 6:18 PM
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] let and fixed point operator

Hi,

I find the feature that the construct "let x = f x in expr"
  assigns fixed point of f to x annoying. The reason is that
  I can not simply chain mofifications a variable like e.g. this:

f x =
   let x = x * scale in
   let x = x + transform in
   g x

When one is lucky then it results in a compile error; in worse
  cases it results in stack overflow in runtime. The annoying
  part is figuring out new and new variable names for essentially
  the same thing to avoid the search/evaluation of the fixed point.

I suppose Haskell was designed so that it makes sense. The only
  usage I can see is like this:

let fact = \x -> if x == 0 then 1 else x * fact (x-1) in

   ... but that is not any shorter than:

let fact x = if x == 0 then 1 else x * fact (x-1) in

So the question is what am I missing? Any nice use cases where
  fixed point search is so good that it is worth the trouble with
  figuring out new and new variable names for essentially the same
  stuff?

Peter.

___
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] cabal install of HDBC-odbc fails on ghc 6.7, -I flag causes problems

[Duncan Coutts]

On Wed, 2007-08-29 at 10:05 -0400, Thomas Hartman wrote:
> 
> Ah ok, so I did 
> 
> echo ":main build -v3" | /usr/local/bin/ghci-6.7.20070816 Setup.hs
> 1>build.out 2>build.err 
> 
> and this does indeed seem more informative. advice?

Turns out this was a bug in FilePath that Cabal was hitting. The bug was
fixed some days ago in Cabal by not using the offending FilePath
function. Hopefully the FilePath function will also be fixed.

So the solution is to update your development version of Cabal to the
latest version.

Note that Cabal-1.1.6.x does not have this problem, only Cabal-1.1.7.

Duncan

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

RE: Re[4]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Peter Verswyvelen]

Although I'm sure a lot can be done on modern GPU's (especially the DirectX
10 cards = Nvidia 8x00, that can write back to main memory, called "geometry
shaders"), a Playstation 3 runs Linux, doesn't cost a lot, and it has 7 CPUs
running at 3+ GHz, and 6 of these have parallel vector processing
capacities. I think it should be easier (but far from easy) to implement
Haskell on a PS3 then it is on a GPU. I developed imperative software for
both, but not in depth, but to me GPUs are still too much oriented towards
graphics, whilest the PS3 CPUs are more general purpose (although they also
expect to process streams of data).

See http://cell.scei.co.jp/e_download.html

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Piponi
Sent: Thursday, August 30, 2007 6:05 PM
To: haskell-cafe@haskell.org
Subject: Re: Re[4]: [Haskell-cafe] Haskell on the Playstation 3? :-)

On 8/30/07, Hugh Perkins <[EMAIL PROTECTED]> wrote:

> On the whole, maps and folds may constitute the bulk of what we are
> trying to parallelize (certainly, SPJ's NDP focuses extensively on
> maps), so this is probably broadly compatible with the CUDA
> architecture?

Right. But the functions and data that we are trying to map and fold
could be anything, so we are required to have the full functionality
of Haskell running on the GPU - unless the compiler can smartly figure
out what should run on the GPU and what shouldn't. All in all, this
could be a fairly ambitious project.

Another, more modest, approach would be to define a DSL, maybe along
the lines of what Lennart Augustsson has been doing on his blog
(http://augustss.blogspot.com/), and implement a compiler back end
that generates GPU code from the DSL. Something similar for C++ is
Michael McCool's Sh library
(www.csee.umbc.edu/~olano/s2005c37/ch07.pdf) which has now developed
into a more general purpose commercial product. It seems to me that
this could be a killer application for Haskell without a major rewrite
of the Haskell compiler. What's more, the same DSL could have
different back ends targeting GPUs, multiple cores or even just single
CPUs (where you'd still get the benefits of partial evaluation).
--
Dan
___
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] defining mapPairs function

[Dan Weston]

That's just a minor change of plumbing:

import Control.Arrow((***),(&&&),(>>>),app)
import Data.Maybe(catMaybes,maybeToList)

mapPair :: (a -> a -> a) -> [a] -> [a]
mapPair = curry mp where
 mp = (((zipWith >>> uncurry) ***  -- (inter-elem function
(id &&& tail) >>>  -- ,duplicate and offset)
 app  >>>  -- apply fst to snd
 alternate>>>  -- mark   even elements
 catMaybes))   -- delete even elements

 &&& -- Tuple this up with...

  (snd>>>
   alternate  >>>  -- keep odd indices
   (Nothing:) >>>  -- make sure there is a last
   last   >>>  -- get last
   maybeToList)-- keep if it had odd index

 >>>  -- and then...

  uncurry (++)-- append pair of lists

 alternate = zipWith ($) (cycle [Just,const Nothing])
   -- Mark even-indexed elements for deletion
   -- cycle goes on forever, but zipWith stops at
   -- the end of the shorter list, so no worries.

When you find yourself manually plumbing the inputs, that's probably 
where point-free has morphed into point-less programming! I plead guilty! :)


Dan Weston

Devin Mullins wrote:
That's great (really, thank you for such a fun example of Arrow 
programming), but isn't the (*) on line two of mapPair supposed to be a 
"point"? How would you make a point-less version of mapPair that 
actually had the type signature (a->a->a)->[a]->[a]*? (For that matter, 
/would/ you?)


Devin
* Grr, you're right. Were it not for that odd requirement, the type 
could be loosened to (a->a->b)->[a]->[b]. Maybe mapPairs should take a 
monadic (that is, one-arg) function to handle the dangling oddies.


Dan Weston wrote:

import Control.Arrow((&&&),(>>>))
import Data.Maybe(catMaybes,maybeToList)

mapPair = (id &&& tail   >>>  -- offset list by one
   uncurry (zipWith (*)) >>>  -- multiply adjacent
   alternate >>>  -- mark   even elements
   catMaybes) -- delete even elements

 &&&  -- Tuple this up with...

  (alternate >>>  -- keep odd indices
   (Nothing:)>>>  -- make sure there is a last
   last  >>>  -- get last
   maybeToList)   -- keep if it had odd index

 >>>  -- and then...

  uncurry (++)-- append pair of lists

  where alternate = zipWith ($) (cycle [Just,const Nothing])
  -- Mark even-indexed elements for deletion
  -- cycle goes on forever, but zipWith stops at
  -- the end of the shorter list, so no worries.

___
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] redirecting stdout

[Chad Scherrer]

Is it possible to write a function

redirect :: Handle -> IO () -> IO ()

so that "redirect h action" is just like action, except that all the
output written to stdout now gets sent to h instead?

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

[Haskell-cafe] darcs behind firewall

[Sukit Tretriluxana]

Hi all,

Does anyone know how to specify proxy server and port for darcs to use when
it connects to servers? I am behind firewall most of the time and all
requests have to go through a proxy.

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

[Haskell-cafe] FFI and DLLs

[Lewis-Sandy, Darrell]

An early proposal for the FFI supported importing functions directly from
dynamic link libraries:

 

www. 
haskell.org/hdirect/ffi-a4.ps.gz

 

This looks like it was dropped from the final version of the addendum in
favor of C header files as the sole form of import entities.  Not being a C
programmer, how would one go about importing a foreign function (e.g. void
Foo(void) ) from a dynamic link library (e.g. foo.dll)??   Would someone be
willing to provide an explicit example?

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

Re: [Haskell-cafe] redirecting stdout

[Bryan O'Sullivan]

Chad Scherrer wrote:

Is it possible to write a function

redirect :: Handle -> IO () -> IO ()

so that "redirect h action" is just like action, except that all the
output written to stdout now gets sent to h instead?


No.  The file descriptor used for IO is wired into a Handle, just as in 
a FILE * in C.  You can change where stdout points using hDuplicateTo, 
but that affects the entire process.


http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] let and fixed point operator

[Henning Thielemann]

On Thu, 30 Aug 2007, Peter Verswyvelen wrote:

> infixl 0 \> -- I just took the first weird symbol combination that came to
> mind, this does not mean anything (I hope ;-)
>
> x \> fx = fx x
>
> f x = x * scale \> \x ->
>   x + transform \> \x ->
>   g x
>
> like this you don't have to invent new names, and you don't have to type
> much more.
>
> I'm sure this silly sequencing operator must already exist in the library
> somewhere?

Sure, its name is (>>=). It must be used for the Identity monad, as
mentioned by Derek Elkins earlier in this thread.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] darcs behind firewall

[Thomas Hartman]

If you are on linux (I'm on ubuntu) you should be able to set 

export http_proxy=http://proxyserver.com:1234
export https_proxy=http://proxyserver.com:123

vars, per what your sysadmin says. In my case, these are set to the same 
var that permits me to use firefox via the proxy, in firefox -> edit-> 
preferences -> network tab -> connection settings, http proxy.

and darcs should "just work"

thomas.





"Sukit Tretriluxana" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
08/30/2007 03:54 PM

To
haskell-cafe@haskell.org
cc

Subject
[Haskell-cafe] darcs behind firewall






Hi all,

Does anyone know how to specify proxy server and port for darcs to use 
when it connects to servers? I am behind firewall most of the time and all 
requests have to go through a proxy.

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



---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[Andrew Coppin]

Brent Yorgey wrote:



It's really maddening to write 50,000 lines of code, eventually get it
to compile, run it, and have the program lock up and start
consuming so
much virtual memory that the entire PC becomes unstable within
seconds.

(This isn't helped by the fact that Ctrl+C doesn't seem to make
either
GHCi or GHC-compiled programs halt...) Now you have 50,000 lines of
otherwise untested code, and there's a bug within it
*somewhere*... good
luck.


Well, this is why you should test your program in bits and pieces 
before you get to that point.  Writing 50,000 LOC before you even run 
your first test is a horrible idea in any programming language.


Horrible? Yes.

Avoidable? Not always, sadly...

(NB. 50,000 is an exaggeration. I've never written a program that large 
in my entire life in any programming language I've ever used.)


The problem is that, depending on the program, sometimes you have to 
write quite a lot of infrastructure before you get to the point where 
there's anything finished enough to test. Obviously it's better to avoid 
that happening, but that's easier said then done!


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

Re: [Haskell-cafe] let and fixed point operator

[Andrew Coppin]

David Roundy wrote:

On Thu, Aug 30, 2007 at 06:16:12PM +0100, Andrew Coppin wrote:
  
Obviously you might very well have *meant* to write x = f x. But would 
it be possible to add some kind of optional compiler warning to find 
such assignments? It can be a nightmare trying to track down where you 
made the mistake...



If you enable -Wall, ghc will warn you about this, provided that x was
already bound in this context.
  


Most excellent. GHC saves the day again...

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

Re: [Haskell-cafe] let and fixed point operator

[Andrew Coppin]

Dan Piponi wrote:

On 8/30/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
  

Obviously you might very well have *meant* to write x = f x. But would
it be possible to add some kind of optional compiler warning to find
such assignments?



The thing that convinced me to learn Haskell in the first place was
the fact that you could write x = f x. Equations where you refer to
the same variable on the left and right hand sides are the bread of
butter and mathematics, and I was really pleased to find a programming
language that let me do the same.


Yeah, but... programs aren't like mathematics. I know people claim that 
they are, but they aren't.


In mathematics, if you write "x = f y" you mean that these two 
expressions are equal. In Haskell, if you say "x = f y" you mean *make* 
then equal!


(Let us not even go into the times when expressions like "z = f z" 
actually means "z[n+1] = f [z]"...)



So to me the idea of having a
warning for this is a bit like putting a sign on bottled water saying
"Warning: Contents may be wet". But that's just me. :-)
  


Well, it's definitely a valid thing to want to do, which is why I asked 
for a *warning* not an error. ;-) Still, this seems to be an extremely 
common way for me to hurt myself, so...



Still, it might be useful to for the compiler to warn when a newly
introduced name shadows another one.
  


...or that...

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

[Haskell-cafe] Re: let and fixed point operator

[Peter Hercek]

Chaddaï Fouché wrote:

But, even more trivial... You use this all the time when you define
recursive function, you know ? You would need to add a "rec" keyword
to the language if you disallowed this.


Great and new reason too. Trying to make a difference based on presence
 of formal argument would be bad since point-free is useful too.
 Well, in my opinion, only to a certain degree since from some point
 on it is more understandable to name intermediate results (points).

Thanks,
Peter.

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

[Haskell-cafe] happs on ghc 6.7 won't work because of dependency on Data.Binary (everything that depends on Data.Binary broken at present) ( unknown symbol `stg_uncheckedShiftRL64' )

[Thomas Hartman]

happs on ghc 6.7 won't work because of dependency on Data.Binary, since 
everything that depends on Data.Binary is broken at present.

This is for Data.Binary installed via cabal from darcs get --partial 
http://darcs.haskell.org/binary . Cabal installed without any errors, but 
perhaps there should have been one since it appears broke.

So I think my project of using the ghc debugger to help understand happs 
is on ice until this gets resolved.

Unless this has been fixed since August 16. (Anyone out there got a more 
recent version?)

$ cat UseDataBinary.hs
import Data.Binary

main = putStrLn "hello world"

$ /usr/local/bin/ghc-6.6.1 -e 'main' UseDataBinary.hs
hello world

$ /usr/local/bin/ghc-6.7.20070816 -e 'main' UseDataBinary.hs
: /usr/local/lib/binary-0.3/ghc-6.7.20070816/HSbinary-0.3.o: 
unknown symbol `stg_uncheckedShiftRL64'
ghc-6.7.20070816: unable to load package `binary-0.3'

$ /usr/local/bin/ghc-6.7.20070816 -e '' UseDataBinary.hs




---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[Dan Piponi]

On 8/30/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:

> Yeah, but... programs aren't like mathematics. I know people claim that
> they are, but they aren't.

But the raison d'etre of Haskell is to make programming more like
mathematics. That motivates everything from the fact that it's a
declarative language, and the support for equational reasoning, to the
fact that IO happens in a monad, and the option to use primes on
variables names.

> In mathematics, if you write "x = f y" you mean that these two
> expressions are equal. In Haskell, if you say "x = f y" you mean *make*
> then equal!

Haskell is a declarative language, not an imperative language. When
you write "x = f x" in Haskell, you're declaring to the compiler that
x equals f x. In an imperative language like Java, the line x = f(x)
gives the compiler the imperative to emit instructions to store the
value of f(x) in a 'box' called x. In Haskell, there is no box.

(When you get down to the nuts and bolts, a Haskell compiler and a
Java compiler may ultimately actually do the same thing here, but the
way you think about a language is as important as what instructions
the code generator emits.)
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[jerzy . karczmarczuk]

Dan Piponi writes: 


In mathematics, if you write "x = f y" you mean that these two
expressions are equal. In Haskell, if you say "x = f y" you mean *make*
then equal!




Haskell is a declarative language, not an imperative language. When
you write "x = f x" in Haskell, you're declaring to the compiler that
x equals f x. In an imperative language like Java, the line x = f(x)
gives the compiler the imperative to emit instructions to store the
value of f(x) in a 'box' called x. In Haskell, there is no box.


Well, there are boxes...
But there also thunks and latent, yet-unevaluated graphs... 


Anyway, I believe strongly that ALL people who have problems with the
Haskell protocole, and they are numerous, I teach a good sample of them,
should be encouraged to learn Prolog. IN DEPTH, and I mean it, Andrew
Coppin and Peter Hercek ! 


In Prolog A=B is the unification, which is a bit more than equality, and
something much more aggressive than an assignment. When you REALLY
understand unification, it will be easier to see the lazy instantiation
of the Haskell assignment, and, additionally, it becomes much more easy
to understand the automatic inference of types, which sooner or later
must be harnessed by all Haskell programmers... 

The best. 

Jerzy Karczmarczuk 



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

Re: [Haskell-cafe] let and fixed point operator

[Dan Piponi]

On 8/30/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Dan Piponi writes:
> > In Haskell, there is no box.
>
> Well, there are boxes...
> But there also thunks and latent, yet-unevaluated graphs...

But the point of Haskell is to provide an abstraction that hides these
details from you. (Though ultimately it's a leaky abstraction and
there comes a point where you do need to know about these things.)

> Anyway, I believe strongly that ALL people who have problems with the
> Haskell protocole, and they are numerous, I teach a good sample of them,
> should be encouraged to learn Prolog.

I'd second that. It's hard to see the difference between declarative
and imperative programming when you only have one instance of a
declarative language from which to generalise.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[Derek Elkins]

On Thu, 2007-08-30 at 23:58 +0200, [EMAIL PROTECTED]
wrote:
> Dan Piponi writes: 
> 
> >> In mathematics, if you write "x = f y" you mean that these two
> >> expressions are equal. In Haskell, if you say "x = f y" you mean *make*
> >> then equal!
>  
> 
> > Haskell is a declarative language, not an imperative language. When
> > you write "x = f x" in Haskell, you're declaring to the compiler that
> > x equals f x. In an imperative language like Java, the line x = f(x)
> > gives the compiler the imperative to emit instructions to store the
> > value of f(x) in a 'box' called x. In Haskell, there is no box.
> 
> Well, there are boxes...
> But there also thunks and latent, yet-unevaluated graphs... 
> 
> Anyway, I believe strongly that ALL people who have problems with the
> Haskell protocole, and they are numerous, I teach a good sample of them,
> should be encouraged to learn Prolog. IN DEPTH, and I mean it, Andrew
> Coppin and Peter Hercek ! 
> 
> In Prolog A=B is the unification, which is a bit more than equality, and
> something much more aggressive than an assignment. When you REALLY
> understand unification, it will be easier to see the lazy instantiation
> of the Haskell assignment, and, additionally, it becomes much more easy
> to understand the automatic inference of types, which sooner or later
> must be harnessed by all Haskell programmers... 

One should learn Prolog anyway.

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

[Haskell-cafe] Re: trouble compiling regex posix head (I think >0.92) on ghc 6.7

[Thomas Hartman]

I darcs pulled cabal head to get latest cabal, removed -Werror from 
GHC-Options in the cabal file, removed HsRegexPosixConfig.h and tried 
again with the same result.

It seems to really want that file. With, it installs, without, no install.

$ darcs whatsnew
{
hunk ./regex-posix.cabal 16
-Build-Depends:  regex-base >= 0.80, base >= 2.0
+Build-Depends:  regex-base >= 0.80, base >= 2.0, array, 
containers, byt
estring
hunk ./regex-posix.cabal 32
-GHC-Options:-Wall -Werror -O2
+GHC-Options:-Wall -O2
hunk ./regex-posix.cabal 43
-Include-Dirs:   include
+Include-Dirs:   include/regex
}
 



Chris Kuklewicz <[EMAIL PROTECTED]> 
08/30/2007 12:34 PM

To
Thomas Hartman/ext/[EMAIL PROTECTED]
cc
haskell-cafe@haskell.org, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject
Re: trouble compiling regex posix head (I think >0.92) on ghc 6.7






Thomas Hartman wrote:
> 
> I'm trying to compile regex-posix on ghc 6.7. (Ultimate goal: happs on
> 6.7).

I have not explored ghc 6.7.  You should also try posting on the
<[EMAIL PROTECTED]> mailing list.

> 
> First, I patched by changing the cabal file to be compatible with the
> new libraries broken out of base. I also had to add HsRegexPosixConfig.h
> to include/regex (I just copied it from somewhere else on my hard drive
> where I guess it had been put by an earlier regex-posix install, I don't
> know if it's compatible here but at least it permitted things to compile
> further.)

I had no idea what HsRegexPosixConfig was, and I have no such file at all.
So I looked in Wrap.hsc and found:

> #ifdef HAVE_REGEX_H
> #define HAVE_REGCOMP 1
> #else
> #ifndef __NHC__
> #include "HsRegexPosixConfig.h"
> #else
> #define HAVE_REGEX_H 1
> #define HAVE_REGCOMP 1
> #endif
> #endif

Note that I did not write that section -- that was added by someone else.

So HsRegexPosixConfig.h should only matter if HAVE_REGEX_H is undefined. 
The
regex-base.cabal file says:
"CC-Options: -DHAVE_REGEX_H"
So unless Cabal is having a very very bad day, I assume that
HsRegexPosixConfig.h is never needed.

That it matters to your build to have that file seems _wrong_ to me.

The only header file it should need is "regex.h"

> Setup.hs build -v3 had a lot of warnings but didn't seem to fail.
> However, Setup.hs install -v3 didn't work.

You might try to change the cabal file.  Currently I think it is
"GHC-Options:-Wall -Werror -O2"
and remove -Werror
"GHC-Options:-Wall -O2"

And you can change the cabal "Include-Dirs" to point to wherever it will 
find
"regex.h"

> the problem in build seems to occur around "upsweep partially failed or
> main not exported"...

That means nothing to me.

> 
> [6 of 6] Compiling Text.Regex.Posix ( Text/Regex/Posix.hs,
> dist/build/Text/Regex/Posix.o )
> *** Parser:
> *** Renamer/typechecker:
> 
> Text/Regex/Posix.hs:57:2:
> Warning: The export item `module Text.Regex.Posix.String' exports
> nothing
> 
> Text/Regex/Posix.hs:59:2:
> Warning: The export item `module Text.Regex.Posix.Sequence' exports
> nothing
> 
> Text/Regex/Posix.hs:61:2:
> Warning: The export item `module Text.Regex.Posix.ByteString'
> exports nothing
> 
> Text/Regex/Posix.hs:63:2:
> Warning: The export item `module Text.Regex.Posix.ByteString.Lazy'
> exports nothing

Those warning are slightly bogus.  Including the module should export the 
instances.

> *** Deleting temp files:
> Deleting: /tmp/ghc9618_0/ghc9618_0.s
> Warning: deleting non-existent /tmp/ghc9618_0/ghc9618_0.s
> Upsweep partially successful.
> *** Deleting temp files:
> Deleting:
> link(batch): upsweep (partially) failed OR
>Main.main not exported; not linking.
> *** Deleting temp files:
> Deleting:
> *** Deleting temp dirs:
> Deleting: /tmp/ghc9618_0
> 
> complete output (along with patch) is attached.

> 
> I'd appreciate any advice.
> 
> best, thomas.
> 
> 




---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] let and fixed point operator

[ok]

What is so bad about

f x = g x''
  where x'' = x' + transform
x'  = x  * scale

(if you really hate inventing temporary names, that is).


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

Re: [Haskell-cafe] darcs behind firewall

[Sukit Tretriluxana]

Thank you so much. That works nicely!!

Ed

On 8/30/07, Thomas Hartman <[EMAIL PROTECTED]> wrote:
>
>
> If you are on linux (I'm on ubuntu) you should be able to set
>
> export http_proxy=http://proxyserver.com:1234
> export https_proxy=http://proxyserver.com:123
>
> vars, per what your sysadmin says. In my case, these are set to the same
> var that permits me to use firefox via the proxy, in firefox -> edit->
> preferences -> network tab -> connection settings, http proxy.
>
> and darcs should "just work"
>
> thomas.
>
>
>
>
>  *"Sukit Tretriluxana" <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 08/30/2007 03:54 PM
>   To
> haskell-cafe@haskell.org  cc
>
>  Subject
> [Haskell-cafe] darcs behind firewall
>
>
>
>
>
>
> Hi all,
>
> Does anyone know how to specify proxy server and port for darcs to use
> when it connects to servers? I am behind firewall most of the time and all
> requests have to go through a proxy.
>
> Thanks,
> Ed___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If you
>
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Newbie question: Why gfoldl has this strange type?

[Ryan Ingram]

Just so nobody else has to look it up:
Data.Generics.Basics.gfoldl :: Data a => (c (a -> b) -> a -> c b) -> (g -> c
g) -> a -> c a

  -- ryan


On 8/30/07, Rodrigo Geraldo <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
> I am a novice in Haskell, and particularly I have interested in generic
> programming. This interest motivated me to read paper Scrap your
> boilerplate: A practical design pattern for generic programming, but I
> didn't understand the type of the function gfoldl, that was present in class
> Term (Data). Somebody could help me to understand the type of this function?
>
> Thanks...
>
> Rodrigo
>
> ___
> 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] Newbie question: Why gfoldl has this strange type?

[Ryan Ingram]

Actually, it's a higher rank type and that doesn't show up on hoogle's main
page.

gfoldl :: (forall a b . Data a => c (a -> b) -> a -> c b)
-> (forall g . g -> c g)
-> a
-> c a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: interaction between OS processes

[Aaron Denney]

On 2007-08-30, Andrea Rossato <[EMAIL PROTECTED]> wrote:
> Hi,
>
> there's something I don't get about interaction among OS processes and
> Haskell handles/channels.

This looks like a buffering problem.  You might be able to make it work by
explicitly setting "line buffering" with hSetBuffering

-- 
Aaron Denney
-><-

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

Re: Re[4]: [Haskell-cafe] Haskell on the Playstation 3? :-)

[Hugh Perkins]

On 8/31/07, Dan Piponi <[EMAIL PROTECTED]> wrote:
> Right. But the functions and data that we are trying to map and fold
> could be anything, so we are required to have the full functionality
> of Haskell running on the GPU - unless the compiler can smartly figure
> out what should run on the GPU and what shouldn't. All in all, this
> could be a fairly ambitious project.

Well, yes, I didnt say it would be easy ;-)

It could be useful to make a ballpark estimate of what kind of
performance we'd get running Haskell on a GPU, compared to running on
a CPU.  Any ideas on how to do this?

By the way, is there some reason we couldnt give the entire haskell
program to every thread, and simply pass in something roughly
equivalent to the program counter in with the data?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe