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
Am Freitag, 25. Januar 2008 03:35 schrieb Conal Elliott:
[…]
See http://haskell.org/haskellwiki/Reactive and http://haskell.org/yampa/ .
Or better http://haskell.org/haskellwiki/Functional_Reactive_Programming
which has come into existence recently.
[…]
Best wishes,
Wolfgang
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
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
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
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
* 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
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
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
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.
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo
