It's not at all easy in general. Suppose we have
f :: [!a] - [a]
f xs = xs
Does f run down the list, behind the scenes, evaluating each element?
That could be expensive. Would it make any difference if we wrote f ::
[!a] - [a], or f :: [a] - [!a]? Or does the type mean that f
It's hard to avoid the feeling that one ought to be able to say
something useful about strictness in the types but it's swampy
territory, and hard to get right.
Fortunately, it's easy to dry up the `swampy territory'. The type
`Contract' below models strictness requirements. The function
On 06 December 2005 19:52, Gour wrote:
Simon Marlow ([EMAIL PROTECTED]) wrote:
The wiki is currently closed because I don't want to have to deal
with spam. Use HaWiki for now.
I got responses from people on #trac to disable entries from
non-registered user as a spam-prevention mechanism.
On 06 December 2005 17:45, Malcolm Wallace wrote:
Just one minor nit: the front page URL tells me a lot about Trac,
but nothing at all about ghc!
Eventually, I worked out that I needed to click on View tickets,
but it took a while to realise this.
The top page of the wiki is now a bit more
On 04 December 2005 00:51, John Meacham wrote:
I was thinking it would be nice if ghc --make could touch the output
file with the timestamp of the most recently modified source file.
As it is, if you edit a file in between when ghc --make starts and it
finishes (a substantial amount of time
Simon Marlow ([EMAIL PROTECTED]) wrote:
Hi Simon!
Unfortunately there isn't a way for users to register themselves, we
have to create them manually using htpasswd. I'm sure someone must have
implemented an online user-registration system for Trac though?
This is what I got on #trac channel
Talk of uniqueness and so forth on the various Haskell mailing lists
causes me to wonder: with so much imperative code being written in
Haskell these days, to what extent is / should GHC perform standard
imperative optimizations? A few things come to mind:
- Fetch elimination for
The Windows distribution of GHC includes GCC. Some header files
(such as iostream, algorithm, and so forth), however, are missing
(at least I was not able to find them).
I could, of course, download the correct version of GCC (this must be
version 3.2.3 for GHC 6.4), and put the header files
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
This transformation is valid only on single-threaded systems.
If there is any possibility of an IORef being shared across
On 07 December 2005 13:17, Gour wrote:
Simon Marlow ([EMAIL PROTECTED]) wrote:
Hi Simon!
Unfortunately there isn't a way for users to register themselves, we
have to create them manually using htpasswd. I'm sure someone must
have implemented an online user-registration system for Trac
On 07 December 2005 13:39, [EMAIL PROTECTED] wrote:
The Windows distribution of GHC includes GCC. Some header files
(such as iostream, algorithm, and so forth), however, are missing
(at least I was not able to find them).
I could, of course, download the correct version of GCC (this must be
On 07 December 2005 13:38, Malcolm Wallace wrote:
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
This transformation is valid only on single-threaded systems.
If there
Hello Ralf,
Wednesday, December 07, 2005, 12:43:33 PM, you wrote:
It's hard to avoid the feeling that one ought to be able to say
something useful about strictness in the types but it's swampy
territory, and hard to get right.
RH Fortunately, it's easy to dry up the `swampy territory'. The
|- Fetch elimination for imperative reads:
| writeIORef r e acts readIORef r
| === writeIORef r e acts return e
|
| This transformation is valid only on single-threaded systems.
| If there is any possibility of an IORef being shared across threads,
| you are out of luck.
|
On Wed, Dec 07, 2005 at 02:15:24PM -, Simon Marlow wrote:
On 07 December 2005 13:38, Malcolm Wallace wrote:
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
On 07 December 2005 15:21, Claus Reinke wrote:
(assuming 'acts' doesn't modify 'r').
this remark is the problem.
No, Jan's transformation is correct even in a multithreaded setting.
It might eliminate some possible outcomes from a non-deterministic
program, but that's ok. There's no
I have a fix for it now, thanks to dons. I just wrap system in
Control.Exception.catch and it doesn't crash. dons also said that this
has been fixed in head
dons:
waitForProcess started raising exceptions if the processed
had already termianted (I think) in 6.4.1 and the head. It's
been fixed
On 07 December 2005 15:14, Ian Lynagh wrote:
On Wed, Dec 07, 2005 at 02:15:24PM -, Simon Marlow wrote:
On 07 December 2005 13:38, Malcolm Wallace wrote:
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
transformation is invalid. In the general case, for some arbitrary
actions between the write and the read
The following paper seems relevant to this thread. Although it's written
in the context of C and C++, it's relevant to any language that combines
pre-emptive threads and imperative features.
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
On 07 December 2005 16:38, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
transformation is invalid. In the general case, for some
On Dec 7, 2005, at 12:05 PM, Simon Marlow wrote:
On 07 December 2005 16:38, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
On Wed, 7 Dec 2005, Robert Dockins wrote:
What exactly are the semantics of C programs and why do we believe that
C compilers are correct?
With regards to threading, the semantics are undefined and the compilers
are subtly broken :-)
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
It's not at all easy in general. Suppose we have
f :: [!a] - [a]
f xs = xs
Does f run down the list, behind the scenes, evaluating each element?
No, because what [!a] means is List !a = ([] | !a : List !a). It
does not mean ([] | !(!a : List !a)). Since the Cons thunks
[previously sent by mistake to Simon only - new para at end]
Simon Marlow [EMAIL PROTECTED] writes:
Now, take the original program, but change the creation of m2 to
newMVar (), i.e. m2 starts off full. Is the transformation valid now?
Well maybe, because in some interleavings acts does not
there seem to be two issues here - can we agree on that at least?
1) scheduling non-sequential programs on sequential processors
i wasn't arguing that the scheduler should realise all possible
interleavings at once. the issue i was referring to is known as
fairness in concurrent systems
Simon Marlow wrote:
If you want to compile C files using GHC (a reasonable thing to do),
then the right thing to do is install a full GCC somewhere (eg. the
mingw gcc), and tell GHC to use it, like this:
$ ghc -pgmc c:/mingw/bin/gcc -c foo.c
How this flag affects linking and the location of
Tony Finch [EMAIL PROTECTED] writes:
On Wed, 7 Dec 2005, Robert Dockins wrote:
What exactly are the semantics of C programs and why do we believe that
C compilers are correct?
With regards to threading, the semantics are undefined and the compilers
are subtly broken :-)
Just have a look
On Wed, Dec 07, 2005 at 08:30:36AM -0500, Jan-Willem Maessen wrote:
What say others? Is there a need yet? (I don't honestly know the
answer!)
Although I don't think impertive optimizations at this high of a level
will benefit much for how much they cost, after the code has been
processed
On Wed, Dec 07, 2005 at 05:05:58PM -, Simon Marlow wrote:
No, that is exactly what I disagree with. Faced with non-derministic
semantics, the compiler does *not* have to preserve all possible
outcomes. In other words, it does not have to assume that an IORef can
be modified between any
On Wed, Dec 07, 2005 at 05:36:09PM +, Malcolm Wallace wrote:
My expectation is that the config data /will/ have been changed by
some other GUI thread. Surely it cannot be OK for the compiler to
silently deliver the original unchanged data here - it goes against
the programmer's intention.
Yup. this is exactly why C has the 'volatile' keyword. variables that
are declared volatile will always be read and written to memory and
never stored in a register because they could be modified by external
interrupts or threads. If every varibale were considered volatile
everything would be
On Thu, Dec 08, 2005 at 12:17:36AM -, Claus Reinke wrote:
ps does your later email imply that you suggest IORef/MVar as
the non-volatile/volative separation? i'd rather see non-thread-
local IORefs phased out of ch..
yeah. exactly. thread local storage is also quite expensive
Oh, dear, a brief mail with a high-level view of optimization seems
to have touched off some confusion about concurrency. I wasn't
thinking about concurrency at all when I wrote my original message,
but there seem to be some major misconceptions in the ensuing
discussion, which I'd like
34 matches
Mail list logo
