[ ghc-Bugs-635605 ] ghc-pkg in ghc root directory

2002-11-18 Thread noreply
Bugs item #635605, was opened at 2002-11-08 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635605group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to:

[ ghc-Bugs-635594 ] objectio not included in 5.04 September

2002-11-18 Thread noreply
Bugs item #635594, was opened at 2002-11-08 17:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635594group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to:

RE: Native Threads in the RTS

2002-11-18 Thread Simon Peyton-Jones
| I propose adding something like | | forkNativeThread :: IO () - IO () I haven't talked to Simon about this, but it sounds possible. Three thoughts. First, before doing anything like this I'd like to ask you or someone else, or a group, to write a clear exposition of what the problem is and

RE: Silly question about IORefs and MVars

2002-11-18 Thread Simon Marlow
I have a silly question about IORefs and MVars. When do we have to use MVars if a var is accessed by multiple threads. In fact, I wonder why IORefs updates aren't safe : it seems that preemptive scheduling takes place during memory allocation and I can't see where there could be an

RE: Native Threads in the RTS

2002-11-18 Thread Simon Marlow
I'm still unconvinced that the current optional RTS support for mixed green/native threads is the right way to go. It looks to me like a workaround for poor OS support for really lightweight threads. It is a workaround for the lack of truly lightweight threads at the OS level. But I

RE: Class/Implicit Param/Module Interface bug

2002-11-18 Thread Simon Peyton-Jones
These bugs are now fixed in the HEAD. I hope the fixes will make it into 5.04.2 as well. Thanks for identifying them. It was all horribly bogus before. Simon | -Original Message- | From: Ashley Yakeley [mailto:[EMAIL PROTECTED]] | Sent: 13 November 2002 13:46 | To: Simon Peyton-Jones

Re: first stab at -ffunction-sections

2002-11-18 Thread William Lee Irwin III
On Mon, Nov 18, 2002 at 11:55:27AM -, Simon Marlow wrote: What exactly are you trying to use -ffunction-sections for? I'm pretty sure it won't work as things stand currently, unless you can guarantee to be able to find a text/data boundary symbol for the garbage collector (currently it

Re: Bug? [was: Implicit params]

2002-11-18 Thread Jorge Adriano
Now fixed in the HEAD, and will be in 5.04.2 Thanks for pointing it out. Simon Thanks :) J.A. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: first stab at -ffunction-sections

2002-11-18 Thread Simon Marlow
On Mon, Nov 18, 2002 at 11:55:27AM -, Simon Marlow wrote: What exactly are you trying to use -ffunction-sections for? I'm pretty sure it won't work as things stand currently, unless you can guarantee to be able to find a text/data boundary symbol for the garbage collector

unsafePerformIO and IORefs

2002-11-18 Thread Nicolas Oury
I want to write something like type State a = IORef a newState :: a - State a newState v = unsafePerformIO (newIORef v) But I don't want the compileer to inline this nor to inline any application of this. {#NOINLINE newState#} But how can I stop this function to be inlined when applied for

Re: unsafePerformIO and IORefs

2002-11-18 Thread Sven Panne
Hal Daume III wrote: You can't. [...] Well, you can, but only for CAFs. This idiom/hack is used quite happily throughout GHC, HOpenGL, H/Direct, ... Slightly modified stuff from GHC's sources: -- global variables in Haskell :-)

Re: unsafePerformIO and IORefs

2002-11-18 Thread Michael Weber
On Mon, Nov 18, 2002 at 10:36:05AM -0800, Hal Daume III wrote: You can't. CSE (common subexpression elimination) will replace any occurances of 'newState 0' in a function body with the same value. In short: don't use upIO :) Sorry, cannot resist to pour a little salt onto the wound :)

Functional dependencies and Constructor Classes

2002-11-18 Thread Martin Sulzmann
Hi, I was wondering whether other people made similiar observations. Functional dependencies seem to be expressiveness enough to encode some of the kinding rules required for Constructor Classes. Take a look at the Haskell code below (runs under hugs -98 or ghci

Functional dependencies and improvement

2002-11-18 Thread Martin Sulzmann
Hi, yet again FD's! In my previous example I employed FD's to improve constraints. However, there are cases where FD's seem to be overly restrictive. Take a look at the Haskell code below. Have others made similar experiences? Martin -- FDs are sometimes overly restrictive module Insert

CFP for LDTA 2003: ACM SIGPLAN Workshop

2002-11-18 Thread Pierre-Etienne . Moreau
Please apologize if you receive multiple copies of this message. ** *** LDTA 2003: ACM SIGPLAN Workshop *** *** APRIL, 6, 2003 *** *** WARSAW,

Re: Functional dependencies and Constructor Classes

2002-11-18 Thread Yoann Padioleau
Martin Sulzmann [EMAIL PROTECTED] writes: Hi, I was wondering whether other people made similiar observations. Functional dependencies seem to be expressiveness enough to encode some of the kinding rules required for Constructor Classes. read this page:

Re: Functional dependencies and Constructor Classes

2002-11-18 Thread Martin Sulzmann
Yoann Padioleau writes: nevertheless i found constructor class more elegant for many problems. Your solution is less elegant that the one using constructor classes. Yes, the current presentation of constructor classes might be easier to comprehend. I found too that type error messages

RE: Functional dependencies and Constructor Classes

2002-11-18 Thread Mark P Jones
Hi Martin, | The issue I want to raise is whether constructor classes are | redundant in the presence of FDs No, they are not comparable. Let fds = functional dependencies ccs = constructor classes Example of something you can do with ccs but not fds: data Fix f = In (f (Fix f))

Formatting function types

2002-11-18 Thread Lauri Alanko
Just a silly thing that's been nagging me. a very common way (at least in the base libraries) of formatting function types seems to be this: hPutBuf :: Handle -- handle to write to - Ptr a-- address of buffer - Int

RE: Bug? [was: Implicit params]

2002-11-18 Thread Simon Peyton-Jones
Now fixed in the HEAD, and will be in 5.04.2 Thanks for pointing it out. Simon | -Original Message- | From: Jorge Adriano [mailto:[EMAIL PROTECTED]] | Sent: 14 November 2002 21:10 | To: Iavor S. Diatchki | Cc: Haskell Cafe; [EMAIL PROTECTED] | Subject: Bug? [was: Implicit params] | |

Re: Bug? [was: Implicit params]

2002-11-18 Thread Jorge Adriano
Now fixed in the HEAD, and will be in 5.04.2 Thanks for pointing it out. Simon Thanks :) J.A. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe