headers
David Sabel | 1 Oct 2002 17:47
Picon

Re: IO-System


> > I'm, analysing the IO-system of the GHC and need more
> > information about
> > it.
> > More precisely: How switches the run-time-system between (normal)
> > evaluation and performing of IO-actions?
> >
> > I read the rts-paper, but didn't find any information about this.
> >
> > Can somebody give a short review, or are ther any other
> > papers available?
>
> The runtime system mostly has no concept of IO vs. non-IO evaluation.
> The IO monad is implemented as the following type:
>
>   newtype IO a = IO (State# RealWorld ->
>    (# State# RealWorld, a #)
>
> which means that an IO action is simply a function from the world state
> to a pair of a new world state and a value.  In other words, it's a
> straightfoward state monad, except that we use some optimised
> representations to eliminate some of the overhead of passing the state
> around.
>
> Cheers,
> Simon

In the GHC users guide Chapter 7.2.12 is the single primitve value
realWorld# of the state of the world provided.
This value is also used in the implementation of unsafePerformIO
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 1 Oct 2002 18:02
Picon
Favicon

RE: IO-System

> In the GHC users guide Chapter 7.2.12 is the single primitve value
> realWorld# of the state of the world provided.
> This value is also used in the implementation of unsafePerformIO
> (GHC.IOBase), where it is applied as the argument
> to the IO action, and so on (after performing the action it's 
> discarded).
> 
> My question is now: Is the same value (realWorld#) applied while using
> normal monadic - not unsafe - IO, more precisely
> is a programm main::IO () executing the expression (main realWorld#)?

In effect, yes.  However, the implementation optimises away the actual
values of type State#, so that no actual argument passing goes on most
of the time.

Cheers,
	Simon
Permalink | Reply | 15 comments |
headers
Simon Marlow | 1 Oct 2002 18:22
Picon
Favicon

No GHC support for a week

Folks,

GHC support will be intermittent at best for the next week or so, as
Simon & I are both heading out to Pittsburgh for ICFP and the Haskell
workshop.  Catch you all later...

Cheers,
	Simon
Permalink | Reply | 1 comment |
headers
Ketil Z. Malde | 2 Oct 2002 11:49
Picon
Picon

Re: No GHC support for a week

"Simon Marlow" <simonmar <at> microsoft.com> writes:

> GHC support will be intermittent at best for the next week or so, as
> Simon & I are both heading out to Pittsburgh for ICFP and the Haskell
> workshop.  Catch you all later...

And here I recently started using GHC 5.04 from the provided RH7.2
packages, and getting occasional "heapCensus" errors.  Relatively
rare, difficult to reproduce, rerunning on the same data usually
works. 

(I was going to forward another question about a heap usage problem I
had, but it turned out it was just a question of applying a bit more
strictness in the right place. :-)

-kzm
--

-- 
If I haven't seen further, it is by standing in the footprints of giants
Permalink | Reply | 0 comments |
headers
Ketil Z. Malde | 2 Oct 2002 13:20
Picon
Picon

Performance question


At the moment, I have a user defined data type on which I have defined
some operations, instantiated (not derived) Eq and so on.  However,
for efficiency I'm storing the actual data in UArrays of Word8.

In order for everything to work, I need functions 'toW8' and 'fromW8'
to map between the data type and its representation in the array.

I gather it is impossible to hide the 'Eq' instance of Word8 and/or
redefine it, but could this be circumvented by instead of

        data Foo = F | G

        instance Eq Foo where
                F == _ = True
                _ == _ = False

defining something like

        newtype Foo = F Word8
        f, g, h :: Foo
        f = F 0
        g = F 1

and using the same instance declaration?  And will it still fit into a
UArray? 

(It is of course possible that, while profiling indicates otherwise,
the conversion functions have little impact in practice; i.e. the
optimizer will do away with them.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Daume III | 2 Oct 2002 16:50
Picon
Favicon

Re: No GHC support for a week

Ketil,

Simon and I have been tracking down this bug for some time now.  A few
days ago I was finally able to come up with a often repeatable, relatively
short example (enough qualifiers? :P).  Last I talked to him, Simon was
getting it running in gdb, but because of how the moon was aligned
yesterday (or something), it was refusing to fall over.

If you have a short program which demonstrates the same problem, I'm sure
Simon would love to get a copy...

 - Hal

--
Hal Daume III

 "Computer science is no more about computers    | hdaume <at> isi.edu
  than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

On 2 Oct 2002, Ketil Z. Malde wrote:

> "Simon Marlow" <simonmar <at> microsoft.com> writes:
> 
> > GHC support will be intermittent at best for the next week or so, as
> > Simon & I are both heading out to Pittsburgh for ICFP and the Haskell
> > workshop.  Catch you all later...
> 
> And here I recently started using GHC 5.04 from the provided RH7.2
> packages, and getting occasional "heapCensus" errors.  Relatively
> rare, difficult to reproduce, rerunning on the same data usually
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hal Daume III | 2 Oct 2002 16:58
Picon
Favicon

Re: Performance question

If I'm understanding you correctly, you just want to be able to put F|Gs
into an unbooxed array.  You don't need to do this conversion stuff...you
can just define new instances.  Something like:

instance MArray IOUArray F IO where
    newArray (l,h) f = newArray (l,h) (f==F) >>= castIOUArray
    newArray_ (l,h)  =
       do (arr :: IOUArray ix Bool) <- newArray_ (l,h)
          castIOUArray arr
    unsafeRead arr i =
        do arr' <- castIOUArray arr
           b    <- unsafeRead arr' i
           return (if b then F else G)
    unsafeWrite arr i f = castIOUArray arr >>= \arr' ->
          unsafeWrite arr' i (f==F)

here we have represented Fs by their isomorphic type Bool, which already
has MArray instances.

HTH

 - Hal

--
Hal Daume III

 "Computer science is no more about computers    | hdaume <at> isi.edu
  than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

On 2 Oct 2002, Ketil Z. Malde wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Daume III | 2 Oct 2002 19:57
Picon
Favicon

deriving weirdness on newtypes

So I love the fact that I can derive anything I want on
newtypes.  However, there seem to be problems with it.  If I write:

    newtype Foo = Foo Int deriving (Show)
    x = show (Foo 5)

Then x is "Foo 5"

However, if I do

    newtype Foo = Foo Int deriving (Num)
    x = show (Foo 5)

Then the definition of 'x' claims that there is no Show instance of Foo.

However (this is where it gets weird).  If I do:

    newtype Foo = Foo Int deriving (Num)
    x = show ((Foo 5) + 4)

then x is *valid* and has value "9", not "Foo 9".  Moreoever, I can even
do:

    x = show ((5::Foo) + 4)

and this x has value "9".

Futhermore, if I do:

    newtype Foo = Foo Int deriving (Show,Num)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ketil Z. Malde | 3 Oct 2002 09:25
Picon
Picon

Re: No GHC support for a week

Hal Daume III <hdaume <at> ISI.EDU> writes:

> If you have a short program which demonstrates the same problem, I'm sure
> Simon would love to get a copy...

I have a longish program that demonstrates the same problem; that is,
it only fails when the moon is aligned or something. :-)

It happens (has happened) rarely enough that it's not a problem for
me. 

-kzm
--

-- 
If I haven't seen further, it is by standing in the footprints of giants
Permalink | Reply | 0 comments |
headers
Ketil Z. Malde | 3 Oct 2002 09:45
Picon
Picon

Re: deriving weirdness on newtypes

Hal Daume III <hdaume <at> ISI.EDU> writes:

> So I love the fact that I can derive anything I want on
> newtypes.  However, there seem to be problems with it.  If I write:
> 
>     newtype Foo = Foo Int deriving (Show)
>     x = show (Foo 5)
> 
> Then x is "Foo 5"
> 
> However, if I do
> 
>     newtype Foo = Foo Int deriving (Num)
>     x = show (Foo 5)
> 
> Then the definition of 'x' claims that there is no Show instance of Foo.
> 
> However (this is where it gets weird).  If I do:
> 
>     newtype Foo = Foo Int deriving (Num)
>     x = show ((Foo 5) + 4)
> 
> then x is *valid* and has value "9", not "Foo 9".  

Did you check the type of x?  (I'd do it but I just found out that I
no longer have GHCi after my 5.04 upgrade)  Did you try different
compilers? 

I guess that there's an automatically derived instance of Show
(annoyingly being necessary for Num) after all, and that it is
(Continue reading)

Permalink | Reply | 0 comments |

Gmane