Re: [Haskell-cafe] Re: Why functional programming matters

[Wolfgang Jeltsch]

Am Freitag, 25. Januar 2008 03:35 schrieb Conal Elliott:
> […]

> See http://haskell.org/haskellwiki/Reactive and http://haskell.org/yampa/ .

Or better  
which has come into existence recently.

> […]

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

[Haskell-cafe] Re: Why functional programming matters

[ChrisK]

Simon Peyton-Jones wrote:

1. Small examples of actual code.


I particularly like the lazy way of counting change example (also works for 
picking items off a menu).


The code below show 3 approaches :
 a function for computing the coins used in each way as a verbose list
 a function for computing just the total number of ways
 a simply Monoid that does both at once, which a pretty summary display
And it has a short but user friendly main function that drives it.

The method used is simple.  It considers each value of coin in turn, this loop 
is done by the foldr.  The value being folded is a list where the index into the 
list is an amount for which change is being made; the value at that list index 
is the list or count of the ways to make that amount using the coins considered 
so far.


These exploit laziness since the returned lists are infinite and since 'result' 
is defined recursively for each different value of coin.


The example of defining a Monoid is a clear abstraction or generalization of the 
first two functions.



-- This demonstrates a way to find every eay to make change for a
-- given total using a set of coins.
--
-- By Chris Kuklewicz, Public Domain
import System.Environment(getArgs)
import Control.Exception as E(catch)
import Control.Monad(when)
import Data.List(group)
import Data.Monoid(Monoid(mempty,mappend))

computeListOfWays :: [Int] -> [[[Int]]]
computeListOfWays coins = foldr includeValue noValues coins
  where noValues = [] : repeat []
includeValue value oldResult =
  let (unchangedResult,changedResult) = splitAt value oldResult
  result = unchangedResult ++
   zipWith (++) changedResult (map addCoin result)
  addCoin = map (value:)
  in result

computeCountOfWays :: [Int] -> [Integer]
computeCountOfWays coins = foldr includeValue noValues coins
  where noValues = 1 : repeat 0
includeValue value oldResult =
  let (unchangedResult,changedResult) = splitAt value oldResult
  result = unchangedResult ++
   zipWith (+) changedResult result
  in result

computeWays :: [Int] -> [Ways]
computeWays coins = foldr includeValue noValues coins
  where noValues = Ways [[]] 1 : repeat mempty
includeValue value oldResult =
  let (unchangedResult,changedResult) = splitAt value oldResult
  result = unchangedResult ++
   zipWith mappend changedResult (map addCoin result)
  addCoin (Ways list count) = Ways (map (value:) list) count
  in result

data Ways = Ways [[Int]] Integer

instance Monoid Ways where
  mempty = Ways [] 0
  mappend (Ways list1 count1) (Ways list2 count2) = Ways (list1++list2) 
(count1+count2)

instance Show Ways where
  show (Ways list count) = unlines (map summary list) ++ "Count of Ways = " ++ show count 
++ "\n"
where summary = show . map (\sub -> (length sub,head sub)) . group


coins_US :: [Int]
coins_US = [1,5,10,25,50]

coins_UK :: [Int]
coins_UK = [1,2,5,10,20,50]

main = do
  args <- getArgs
  case args of
[] -> error "Pass a number of cents for which to count ways of making 
change"
[x] -> do n <- E.catch (readIO x) (const (error "The argument passed needs to be 
a number"))
  when (n<0) (error "The argument passed needs to be a non-negative 
number")
  print (computeWays coins_US !! n)
_ -> error "Too many parameters, need just one number"


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

Re: [Haskell-cafe] Re: Why functional programming matters

[Conal Elliott]

On Jan 24, 2008 1:45 AM, Peter Hercek <[EMAIL PROTECTED]> wrote:

> [...]
> On the other side there are downsides like what to do instead of
>  reactive GUIs? GUI is a big part for a lot of applications. [...]


GUIs can be expressed in a *much* more direct and modular way in functional
programming than imperative programming.  See
http://haskell.org/haskellwiki/TV and
http://haskell.org/haskellwiki/Phooeyfor examples.  No inversion of
control is necessary.  And not just for GUIs,
but for reactive systems in general.  See
http://haskell.org/haskellwiki/Reactive and http://haskell.org/yampa/ .

I'd cite easy & modular GUIs as a strong advantage of functional
programming.

Just to be clear, I mean really *functional* programming, not imperative
programming in Haskell (IO).

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

[Haskell-cafe] Re: Why functional programming matters

[Achim Schneider]

ChrisK <[EMAIL PROTECTED]> wrote:

> Achim Schneider wrote:
> > Don Stewart <[EMAIL PROTECTED]> wrote:
> > 
> >> jwlato:
> >>> In addition to STM, another item that should interest serious
> >>> programmers is forkIO.  Lightweight threads that (unlike in
> >>> Python) can use multiple cpu's.  Coming from Python, I personally
> >>> appreciate this.  Using STM to handle concurrency issues often
> >>> greatly simplifies multithreaded code.
> >> And further on this, the use of `par` in pure code to make it go 
> >> multicore is way beyond what most people think is possible.
> >>
> > I said _don't_ make me think of using par on a beowolf cluster of
> > ps3's. Don't you guys have any scruples?
> > 
> 
> Well... ghc still has a single-threaded garbage collector, so all the
> "par" threads must stop for garbage collection.  So scaling to the
> level of a cluster would be significantly sub-linear.
> 
"By the time you learnt how to write proper Haskell, that's most likely
implemented in an arcane one-liner using par."

-- 
/me aleady drank a bootle of vin and suggests that you don't answer
seriously if you want to get non-abstroose anwererse.

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

[Haskell-cafe] Re: Why functional programming matters

[ChrisK]

Achim Schneider wrote:

Don Stewart <[EMAIL PROTECTED]> wrote:


jwlato:

In addition to STM, another item that should interest serious
programmers is forkIO.  Lightweight threads that (unlike in Python)
can use multiple cpu's.  Coming from Python, I personally appreciate
this.  Using STM to handle concurrency issues often greatly
simplifies multithreaded code.
And further on this, the use of `par` in pure code to make it go 
multicore is way beyond what most people think is possible.



I said _don't_ make me think of using par on a beowolf cluster of
ps3's. Don't you guys have any scruples?



Well... ghc still has a single-threaded garbage collector, so all the "par" 
threads must stop for garbage collection.  So scaling to the level of a cluster 
would be significantly sub-linear.


--
Chris

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

[Haskell-cafe] Re: Why functional programming matters

[Achim Schneider]

Don Stewart <[EMAIL PROTECTED]> wrote:

> jwlato:
> > In addition to STM, another item that should interest serious
> > programmers is forkIO.  Lightweight threads that (unlike in Python)
> > can use multiple cpu's.  Coming from Python, I personally appreciate
> > this.  Using STM to handle concurrency issues often greatly
> > simplifies multithreaded code.
> 
> And further on this, the use of `par` in pure code to make it go 
> multicore is way beyond what most people think is possible.
> 
I said _don't_ make me think of using par on a beowolf cluster of
ps3's. Don't you guys have any scruples?

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Don Stewart]

jwlato:
> In addition to STM, another item that should interest serious
> programmers is forkIO.  Lightweight threads that (unlike in Python)
> can use multiple cpu's.  Coming from Python, I personally appreciate
> this.  Using STM to handle concurrency issues often greatly simplifies
> multithreaded code.

And further on this, the use of `par` in pure code to make it go 
multicore is way beyond what most people think is possible.

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

Re: [Haskell-cafe] Re: Why functional programming matters

[John Lato]

In addition to STM, another item that should interest serious
programmers is forkIO.  Lightweight threads that (unlike in Python)
can use multiple cpu's.  Coming from Python, I personally appreciate
this.  Using STM to handle concurrency issues often greatly simplifies
multithreaded code.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Robin Green]

On Thu, 24 Jan 2008 10:29:23 -0600
Derek Elkins <[EMAIL PROTECTED]> wrote:

> Doing it in the IDE would a) require much more from most IDEs and b)
> be almost entirely useless.  Most IDEs don't even get as far as
> parsing the code, even the the best rarely know much about the actual
> semantics of the language.  This would require a rather deep analysis
> and ultimately it is undecidable.  Practically speaking, having such
> a feature in the IDE would be useless unless the programming style of
> most "imperative" programmers changed dramatically.  The only
> functions such an analysis would say were pure are those that were
> rather trivial.  Either way, having such a feature in the IDE doesn't
> really help.  A purity checker in the IDE isn't going to help when
> the function/method is unknown, e.g. when I write a function/method
> that takes a function or an object.  A "purity annotation" would have
> to be at the language level, short of doing a whole-program analysis
> which would be infeasible.

Indeed - JML (Java Modelling Language) takes exactly this approach.
-- 
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Derek Elkins]

On Thu, 2008-01-24 at 10:45 +0100, Peter Hercek wrote:
> Tim Chevalier wrote:
> > On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote:
> >> Other things did not seem that great for me from the beginning. For
> >> example: referential transparency - just enforces what you can take care
> >> not to do yourself
> > 
> > ...if you never make mistakes, that is.
> > 
> >> (e.g. in C# you just cannot be sure some function is
> >> referentially transparent even when comment claims so - which of course
> >> sucks because programmers are not disciplined).
> > 
> > But if that's the point you're trying to make, I agree that a lot of
> > programmers seem to think they don't make mistakes, and thus might not
> > be receptive to the siren song of referential transparency :-)
> 
> What I wanted to say is that focusing on referential transparency
>   will not appeal that much to an imperative programmer especially
>   when he needs to overcome Haskell learning curve. What may appeal,
>   though, are the consequences of it like:
> * easier to repeat test cases for bugs
> * easier to do automated tests (like quickcheck) since state space
>is not that big (provided I count automatic vars on stack/heap
>as state)
> * makes laziness to work which allow easier and efficient expression
>of producer - consumer type of code
> * easy undo (no need for memento pattern etc)
> * allows monads to work which adds options like built-in user logging
>or error recovery
> * better changes for compilers to find parallelize automatically
> * safe STM
> ... and probably a lot of more goodies
> 
> On the other side there are downsides like what to do instead of
>   reactive GUIs? GUI is a big part for a lot of applications. A lot
>   of efficient algorithms we have are state based. And again probably
>   more.
> 
> If referential transparency by itself would be that important for
>   imperative languages then it would be already added to IDEs* in
>   some form like a popup menu item with name "check function purity".
>   In some cases you could actually decide that the function is pure
>   (especially if you would go deeper analyzing and annotating your
>   objects with purity flags in your IDE).

Doing it in the IDE would a) require much more from most IDEs and b) be
almost entirely useless.  Most IDEs don't even get as far as parsing the
code, even the the best rarely know much about the actual semantics of
the language.  This would require a rather deep analysis and ultimately
it is undecidable.  Practically speaking, having such a feature in the
IDE would be useless unless the programming style of most "imperative"
programmers changed dramatically.  The only functions such an analysis
would say were pure are those that were rather trivial.  Either way,
having such a feature in the IDE doesn't really help.  A purity checker
in the IDE isn't going to help when the function/method is unknown, e.g.
when I write a function/method that takes a function or an object.  A
"purity annotation" would have to be at the language level, short of
doing a whole-program analysis which would be infeasible.

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Lutz Donnerhacke]

* Isaac Dupree wrote:
> fewer frustratingly unsolvable bugs down-the-road?

I personally like the refactoring speed. Due to pureness it's easy to
refactor and that's why I can generalize more and more often.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Isaac Dupree]

fewer frustratingly unsolvable bugs down-the-road?  When I have bugs in 
my Haskell programs (and usually I get type errors instead), I've always 
found them eventually and they're either a silly mistake or I realize 
that I misunderstood the problem I was trying to solve (it needs to be 
solved a different way)... which is great, being able to realize that 
and rewrite things!  Usually not everything has to be rewritten because 
Haskell is pretty modular (unless used poorly :-).


~Isaac

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Sebastian Sylvan]

On Jan 24, 2008 9:45 AM, Peter Hercek <[EMAIL PROTECTED]> wrote:

>  A lot
>  of efficient algorithms we have are state based. And again probably
>  more.
>
Yes, and we can write those using the ST monad in Haskell. I think it's
important to point this out, since some imperative programmers will just go
"but what about if I *need* mutable state?" and probably tune out if they
don't hear right away that Haskell can give it to them in a safe
encapsulated form.

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Why functional programming matters

[Maarten Hazewinkel]

On 24 Jan 2008, at 10:45, Peter Hercek wrote:


* safe STM
... and probably a lot of more goodies


Especially STM would be a good point to elaborate on.
Most big systems have issues around concurrency and state modification  
being broken.
Anything that can reliably solve that problem is going to interest  
serious programmers.



Maarten

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

[Haskell-cafe] Re: Why functional programming matters

[Peter Hercek]

Tim Chevalier wrote:

On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote:

Other things did not seem that great for me from the beginning. For
example: referential transparency - just enforces what you can take care
not to do yourself


...if you never make mistakes, that is.


(e.g. in C# you just cannot be sure some function is
referentially transparent even when comment claims so - which of course
sucks because programmers are not disciplined).


But if that's the point you're trying to make, I agree that a lot of
programmers seem to think they don't make mistakes, and thus might not
be receptive to the siren song of referential transparency :-)


What I wanted to say is that focusing on referential transparency
 will not appeal that much to an imperative programmer especially
 when he needs to overcome Haskell learning curve. What may appeal,
 though, are the consequences of it like:
* easier to repeat test cases for bugs
* easier to do automated tests (like quickcheck) since state space
  is not that big (provided I count automatic vars on stack/heap
  as state)
* makes laziness to work which allow easier and efficient expression
  of producer - consumer type of code
* easy undo (no need for memento pattern etc)
* allows monads to work which adds options like built-in user logging
  or error recovery
* better changes for compilers to find parallelize automatically
* safe STM
... and probably a lot of more goodies

On the other side there are downsides like what to do instead of
 reactive GUIs? GUI is a big part for a lot of applications. A lot
 of efficient algorithms we have are state based. And again probably
 more.

If referential transparency by itself would be that important for
 imperative languages then it would be already added to IDEs* in
 some form like a popup menu item with name "check function purity".
 In some cases you could actually decide that the function is pure
 (especially if you would go deeper analyzing and annotating your
 objects with purity flags in your IDE).

* and IDEs like visual studio or eclipse are incredibly good compared
 to the stuff Haskell has; anyway IMHO all IDEs are not good enough
 - they could be much better

Anyway I'm not that qualified to discuss this (I hope this is my last
 post to this thread :) ). I just wanted to point out what could be
 a point of view of an imperative programmer based on what I remember
 from times I was getting more involved with functional programming.
 The reason I started with functional programming is sure not common
 - sometimes I may need to actually prove some program features.


Peter.

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Thomas Schilling]

On Wed, 2008-01-23 at 15:42 -0800, Don Stewart wrote:
> catamorphism:
> > On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote:
> > > Other things did not seem that great for me from the beginning. For
> > > example: referential transparency - just enforces what you can take care
> > > not to do yourself
> > 
> > ...if you never make mistakes, that is.
> > 
> > > (e.g. in C# you just cannot be sure some function is
> > > referentially transparent even when comment claims so - which of course
> > > sucks because programmers are not disciplined).
> > 
> > But if that's the point you're trying to make, I agree that a lot of
> > programmers seem to think they don't make mistakes, and thus might not
> > be receptive to the siren song of referential transparency :-)
> > 
> 
> Yes, we have to talk more about it making the job "faster and easier",
> than "safer". It's a particular kind of programmer that likes things to
> be safer (i.e. people on this list :), but all kinds want their job
> to be faster and easier :)

Be careful, though, this is only convincing against Java and C.  Python,
Ruby, Perl have the same argument.  Compared to those, using Haskell
might in fact be slower and harder--at least in the beginning.  This is
where Haskell's static typing enters the game and automates many of the
boring and error prone tasks, like finding all the use sites of a type
(just change it and let the compiler tell you).  If you use 'newtype'
and maybe some more advanced type checker features (MPTCs, Existentials)
you can let the type-checker work for you (cf. "Lightweight Static
Capabilities").  This is where Haskell could actually beat all those
"dynamic" languages, which otherwise seem to be much easier to pick up
for imperative programmers. 

Then there is concurrency of course ...

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Don Stewart]

catamorphism:
> On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote:
> > Other things did not seem that great for me from the beginning. For
> > example: referential transparency - just enforces what you can take care
> > not to do yourself
> 
> ...if you never make mistakes, that is.
> 
> > (e.g. in C# you just cannot be sure some function is
> > referentially transparent even when comment claims so - which of course
> > sucks because programmers are not disciplined).
> 
> But if that's the point you're trying to make, I agree that a lot of
> programmers seem to think they don't make mistakes, and thus might not
> be receptive to the siren song of referential transparency :-)
> 

Yes, we have to talk more about it making the job "faster and easier",
than "safer". It's a particular kind of programmer that likes things to
be safer (i.e. people on this list :), but all kinds want their job
to be faster and easier :)

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

Re: [Haskell-cafe] Re: Why functional programming matters

[Tim Chevalier]

On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> wrote:
> Other things did not seem that great for me from the beginning. For
> example: referential transparency - just enforces what you can take care
> not to do yourself

...if you never make mistakes, that is.

> (e.g. in C# you just cannot be sure some function is
> referentially transparent even when comment claims so - which of course
> sucks because programmers are not disciplined).

But if that's the point you're trying to make, I agree that a lot of
programmers seem to think they don't make mistakes, and thus might not
be receptive to the siren song of referential transparency :-)

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"You never have to aspire to difficulty, darling. It arrives,
uninvited.  Then it stays for dinner."--Sue Miller
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Why functional programming matters

[Peter Hercek]

Here are things I liked most (compared with standard imperative 
languages) when I started to learn functional programming:


* algebraic types with pattern matching work nicely as "tagged unions"; 
doing a tagged union manually in C/C++/C# is a pain (there is no 
automatic tag (provided you dismiss rtti over objects))


* lambda expressions, lexical scoping, closures; doing this in C++ is 
just incredible amount of typing; it is a bit better in C# but still not 
good enough

I happen to have nice examples of code like:
  map (\x->x*2) [1,2,3] -- but with an array
in C/C++/ML/C#. Each written as natively as possible. They are attached.

Other things did not seem that great for me from the beginning. For 
example: referential transparency - just enforces what you can take care 
not to do yourself (e.g. in C# you just cannot be sure some function is 
referentially transparent even when comment claims so - which of course 
sucks because programmers are not disciplined). Or another example: 
nontrivial higher order functions looked more damaging than helping 
because understanding usage/interactions is harder. Not mentioning 
monads (user level understanding of uniqueness typing with all the 
annotations is easier than monads).


I found ML/Clean/Haskell much more appealing than the common imperative 
languages an even Prolog (with which I could produce usably quick code 
only after actually using intimate knowledge of the inference and 
sprinkling cuts around, but that does not feel declarative to me any 
more then).


Peter.


functions_as_values.tgz
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe