headers
Ian Lynagh | 1 Feb 2007 01:22
Picon
Gravatar

Re: Proposal: Make StateT in mtl lazy

On Wed, Jan 31, 2007 at 04:06:07PM +0000, Neil Mitchell wrote:
> 
> >If we're going to have a strict StateT then it would make sense to have
> >a strict State too. Control.Monad.State.Strict perhaps? (and likewise
> >for the other mtl monads, where appropriate).
> 
> For foldl we have foldl and foldl'.

Right, and I'd guess about a dozen other functions dotted around the
core libraries.

> Why not State and State' ?
(refering to type names, not module names)

This would also presumably give us

    runState'  evalState'  ...
    runStateT' evalStateT' ...

Existing examples of using .Strict/.Lazy modules are:

    Control.Monad.ST.Lazy
    Control.Monad.ST.Strict

    Data.STRef.Lazy
    Data.STRef.Strict

    Data.ByteString
    Data.ByteString.Lazy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Feb 2007 10:46
Picon

Re: Proposal: System.Timeout module for base

Einar Karttunen wrote:
> On 30.01 12:20, Simon Marlow wrote:
>> How would you interrupt the FFI call when the timeout expired? 
>> pthread_cancel(), maybe?
> 
> That is one solution. Just letting it running and returning
> is "good enough" for most things. One common thing would be
> network related functions if implemented in a blocking way (over
> various C libraries). They usually do need timeouts and are
> blocking FFI calls.

I think it would be wrong to leave the FFI call running and still deliver the 
exception to the thread.  Wrong because it leads to surprising behaviour: if the 
blocked call has a side effect, e.g. a write(), then the side-effect may still 
heppen, despite the fact that the Haskell thread has been interrupted by the 
timeout.  And wrong because it's not possible to implement it in GHC, at least 
for bound threads: the OS thread making the foreign call is the only one that 
can execute the Haskell thread.

So that leaves pthread_cancel().  Unfortunately pthread_cancel() isn't really an 
exception - it can be caught, but the handler is for cleaning up only, it can't 
continue.  So this doesn't let us interrupt FFI calls either.

Any other suggestions?

My take on this is that if you want to make an interruptible FFI call, you make 
it in a separate thread, and ensure that if it continues to execute after the 
parent has received an exception, then this is benign.  This is essentially what 
the IO manager thread in the GHC IO library does: any thread blocked on I/O can 
be interrupted by a signal, because it is the IO manager thread performing the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bulat Ziganshin | 1 Feb 2007 11:49
Picon

Re[2]: Proposal: System.Timeout module for base

Hello Simon,

Thursday, February 1, 2007, 12:46:29 PM, you wrote:

> Any other suggestions?

may be, we can raise exception in foreign language? at least for
'safe' calls. i.e., we establish in RTS signal handler. this handler
checks whether we are performing safe call and if so - raise
language-specific exception... hmm, if that's possible

btw, how about using for *Haskell* code *default* signal handler that
raise Haskell exception? i think that using signal handlers to process
OS-generated events is just legacy from the C days. i.e. 'main'
should be called by RTS inside code like this:

  mainThread <- myThreadId
  let onBreak event = do
        throwTo mainThread BreakException
  bracket (installHandler$ Catch onBreak) (installHandler) $  \oldHandler -> do
    main

(of course, this handles only ^Break and only on Windows)

among other things, this should make signal handling portable between
Win/Unix

--

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin <at> gmail.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Marlow | 1 Feb 2007 14:35
Picon

Re: Proposal: Make StateT in mtl lazy

Neil Mitchell wrote:
> Hi
> 
>> If we're going to have a strict StateT then it would make sense to have
>> a strict State too. Control.Monad.State.Strict perhaps? (and likewise
>> for the other mtl monads, where appropriate).
> 
> For foldl we have foldl and foldl'. Why not State and State' ? I'm not
> a particular fan of changing the imports to get different sets of
> behaviours...

So if you want (gasp!) strictness you have to pay the Prime Tax :-)

I'm not keen on having a bias implied by the naming convention: State' suggests 
that this is a special/modified version of State, whereas I think both versions 
are equally useful.  Using lazy when you wanted strict can result in a space 
leak, using strict when you wanted lazy can result in a stack overflow or a time 
leak.

I don't mind so much a bias in the module names: e.g. Control.Monad.State could 
be the lazy version, Control.Monad.State.Strict the strict version, that's much 
less intrusive.

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Malcolm Wallace | 1 Feb 2007 14:47
Picon

Re: Re[2]: Unsafe aspects of ByteString

Bulat Ziganshin <bulat.ziganshin <at> gmail.com> wrote:

> > The Data.ByteString functions relating to CString have now been
> > modified as follows, in the darcs repository. These changes will be
> > propogated into base in due course.
> 
> i.e. only in ghc 6.8. i use this chance to remind about our suggestion
> to remove ByteString from Base in ghc 6.6.1 and include it as
> *separate* library.

I'd like to echo this.  The Data.ByteString library is wonderful, but
its API is still changing fast.  It was definitely a mistake to include
it in the 'base' package so early.  Furthermore, users of ghc cannot
even override the 'base' version by adding "-package fps" on the
command-line.  (Well, you can, but only if your importing module does
not use any of the other 'base' package libraries.  Is that right?)

Regards,
    Malcolm
Permalink | Reply | 0 comments |
headers
Chris Kuklewicz | 1 Feb 2007 15:00

Re: Proposal: Make StateT in mtl lazy

Simon Marlow wrote:
> Neil Mitchell wrote:
>> Hi
>>
>>> If we're going to have a strict StateT then it would make sense to have
>>> a strict State too. Control.Monad.State.Strict perhaps? (and likewise
>>> for the other mtl monads, where appropriate).
>>
>> For foldl we have foldl and foldl'. Why not State and State' ? I'm not
>> a particular fan of changing the imports to get different sets of
>> behaviours...
> 
> So if you want (gasp!) strictness you have to pay the Prime Tax :-)
> 
> I'm not keen on having a bias implied by the naming convention: State'
> suggests that this is a special/modified version of State, whereas I
> think both versions are equally useful.  Using lazy when you wanted
> strict can result in a space leak, using strict when you wanted lazy can
> result in a stack overflow or a time leak.
> 
> I don't mind so much a bias in the module names: e.g.
> Control.Monad.State could be the lazy version,
> Control.Monad.State.Strict the strict version, that's much less intrusive.
> 
> Cheers,
>     Simon

It is foreseeable that complicated Monads mighty have more intermediate levels
of Strictness (in the tuple, in the return value, in part of the state ...).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Lynagh | 1 Feb 2007 15:24
Picon
Gravatar

Re: Proposal: Make StateT in mtl lazy

On Wed, Jan 31, 2007 at 03:48:25PM +0000, Ian Lynagh wrote:
> 
> instance Monad (State s) where
>     return a = State $ \s -> (a, s)
>     m >>= k  = State $ \s -> case runState m s of
>                              (a, s') -> runState (k a) $! s'
> 
> instance (Monad m) => Monad (StateT s m) where
>     return a = StateT $ \s -> return (a, s)
>     m >>= k  = StateT $ \s -> do
>         (a, s') <- runStateT m s
>         runStateT (k a) $! s'
>     fail str = StateT $ \_ -> fail str

We agreed on IRC that the $!'s solve an orthogonal problem so the strict
monads will just have:

instance Monad (State s) where
    return a = State $ \s -> (a, s)
    m >>= k  = State $ \s -> case runState m s of
                             (a, s') -> runState (k a) s'

instance (Monad m) => Monad (StateT s m) where
    return a = StateT $ \s -> return (a, s)
    m >>= k  = StateT $ \s -> do
        (a, s') <- runStateT m s
        runStateT (k a) s'
    fail str = StateT $ \_ -> fail str

Thanks
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Simons | 1 Feb 2007 19:05
Picon
Gravatar

Re: Proposal: System.Timeout module for base

Simon Marlow writes:

 > Any other suggestions?

The fact that blocking FFI threads cannot be timed out with the
current implementation is unpleasant, and I would be happy to
lift that limitation.

I wonder, though, whether depending on unportable low-level OS
mechanisms like pthread_cancel() or pthread signals to deliver a
timeout might prove to be far more unpleasant than the limitation
we try to lift. As far as I'm concerned, the limitation that
blocking FFI threads cannot be timed out from Haskell is not that
hard. A blocking FFI call, well, blocks. In all honesty, I
wouldn't expect that to be any different. I would be far more
surprised if it turned out that my currently running C code
suddenly receives signals and is supposed to deal with that.

My preferred approach would be to agree on the _signature_ of the
combinator. We should find consensus that timeout is supposed to
look like this:

  timeout :: Int -> IO a -> IO (Maybe a)

If that is the case, then we can add the function into the
distribution now and worry about wild improvements of the
implementation later. I feel that making even an unperfect
solution available to Haskell programmers would be a significant
step forward.
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Meacham | 1 Feb 2007 23:27
Favicon

Re: Unsafe aspects of ByteString

I am not sure this is actually an issue.

if you are willing to use 'poke' then _nothing_ preserves referential
transparency in Haskell, you can arbitrarily overwrite various parts of
the heap.

Of course anything that writes to memory directly is unsafe, but 'poke'
is the unsafe thing here, not packCString.

        John

--

-- 
John Meacham - ⑆repetae.net⑆john⑈
Permalink | Reply | 0 comments |
headers
Simon Marlow | 2 Feb 2007 10:04
Picon

Re: Proposal: System.Timeout module for base

Peter Simons wrote:
> Simon Marlow writes:
> 
>  > Any other suggestions?
> 
> The fact that blocking FFI threads cannot be timed out with the
> current implementation is unpleasant, and I would be happy to
> lift that limitation.
> 
> I wonder, though, whether depending on unportable low-level OS
> mechanisms like pthread_cancel() or pthread signals to deliver a
> timeout might prove to be far more unpleasant than the limitation
> we try to lift. As far as I'm concerned, the limitation that
> blocking FFI threads cannot be timed out from Haskell is not that
> hard. A blocking FFI call, well, blocks. In all honesty, I
> wouldn't expect that to be any different. I would be far more
> surprised if it turned out that my currently running C code
> suddenly receives signals and is supposed to deal with that.

Yes, agreed.

> My preferred approach would be to agree on the _signature_ of the
> combinator. We should find consensus that timeout is supposed to
> look like this:
> 
>   timeout :: Int -> IO a -> IO (Maybe a)
> 
> If that is the case, then we can add the function into the
> distribution now and worry about wild improvements of the
> implementation later. I feel that making even an unperfect
(Continue reading)

Permalink | Reply | 0 comments |

Gmane