[Haskell-cafe] Re: Python's big challenges, Haskell's big advantages?

[Brandon S. Allbery KF8NH]

On 2008 Sep 19, at 17:14, Manlio Perillo wrote:
> Brandon S. Allbery KF8NH ha scritto:
>> There are two ways to handle a growable stack; both start with  
>> allocating each stack in a separate part of the address space with  
>> room to grow it downward.  The simpler way uses stack probes on  
>> function entry to detect impending stack overflow.  The harder (and  
>> less portable) one involves trapping page faults ("segmentation  
>> violation" on POSIX), enlarging the stack, and restarting the  
>> instruction that caused the trap; this requires fairly detailed  
>> knowledge of the CPU and the way signals or page faults are handled  
>> by the OS.  (There's also a hybrid which many POSIXish systems use,  
>> trapping the page fault specifically when running the stack probe;  
>> the probe is designed to be safe to either restart or ignore, so it  
>> can be handled more portably.)
>
> What implementation is used in GHC?

I haven't looked at the GHC implementation.

> Is this more easy to implement with a pure functional language like  
> Haskell, or the same implementation can be used with a procedural  
> language like C?


You can use it with pretty much any language, as long as you can limit  
the size of stack frames.  (If a stack frame is larger than the stack  
probe distance you might just get an unhandled page fault.)  The main  
question is whether you ant to absorb the additional complexity; it's  
a bit harder to debug memory issues when you have to deal with page  
faults yourself.  (A *real* segmentation violation might be hidden by  
the stack grow code.)

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH