Chad Scherrer wrote:
> My question is, as I learn C, are there any particular Haskell concepts I
> should keep in the back of my mind, or is it better to approach C from
> scratch?
One thing from Haskell I'd try keep in mind is to minimize side
effects and keep the scope of side effects as con
On 6/12/06, Chad Scherrer <[EMAIL PROTECTED]> wrote:
Ok, so I'm doing things somewhat backward. I've been using Haskell for a
while now, whenever I get a chance to. But in order to become more involved
in high-performance computing projects at my work, I need to learn C.
[snip]
My question is,
Thanks, Minh. So are things like recursion and memory sharing typically out the window?
Also, I don't see how thinking about type classes will help, without the benefits of polymorphism.
-Chad-- Forwarded message --From: minh thu <[EMAIL PROTECTED]>Date: Jun 12, 2006 12:23 PM
S
Thanks, Minh. So are things like recursion and memory sharing typically out
the window?
Recursion works in C, but every function call pushes stack, so
recursive depth is limited by RAM (compare to tail call optimization
in many functional programming languages where the stack frame is
reused if
On Mon, 2006-06-12 at 14:48 -0700, Jared Updike wrote:
> > Thanks, Minh. So are things like recursion and memory sharing typically out
> > the window?
>
> Recursion works in C, but every function call pushes stack, so
> recursive depth is limited by RAM (compare to tail call optimization
> in many
I did the transition the other way, and even now the real-world keeps me using
more C-like languages (Java, Python).
Unlike the transition from imperative languages to Haskell, I don't think
there's much you have to unlearn or rethink. But I suspect you may feel a
degree of frustration at how inc