- Haskell-prime - Haskell.org

deriving Typeable
by oleg＠pobox.com 04 Apr '06

04 Apr '06

John Meacham wrote: > things like DeepSeq and Typeable will most likely have optimized > versions on various compilers which is why I'd like to see the > restriction that the only way to create instances for these two > classes is via the "deriving" mechanism of the compiler. Please make it so! Allowing users to create their own instances of Typeable is tantamount to allowing them to define the _total_ function unsafeCoerce :: (Typable a, Typeable b) => a -> b That function always succeeds; you don't want to trust its result in general though. If we add -fallow-incoherent-instances, then the Typeable constraint disappears and we obtain the total function of the type a->b. The fact these functions are expressible in Haskell at all is quite disconcerting.

1 0

RE: Concurrency
by Simon Marlow 04 Apr '06

04 Apr '06

On 31 March 2006 22:15, John Meacham wrote: > On Fri, Mar 31, 2006 at 04:21:26PM +0100, Simon Marlow wrote: >> Great. Apart from my misgivings about allowing cooperative >> scheduling at all, here's a few comments on the proposal: > > much much preferable to a standard that not everyone can implement. :) > >> - I wouldn't include threadWaitRead, threadWaitWrite, >> or threadDelay at all. These can all be implemented using >> FFI, so don't belong in the concurrency library. Their >> presence is largely historical. > > They all have special implementations on a 'epoll' based system. > threadDelay turns into the timeout parameter to select, waitread/write > turn into the basic building blocks of your epoll wait-list. We > definitly want these in the interface as primitves. Still not convinced. Most applications can use the standard IO library in a multithreaded program to get I/O multiplexing. The library might be implemented by using a clever epoll/kqueue/whatever interface underneath, but I don't see a reason to expose that as a standard library. And it's perfectly reasonable to implement concurrent IO without doing any clever epoll stuff: GHC on Windows does just that. IMHO, concurrency gives you a way to *avoid* needing an event interface in your language. > In particular, foregin concurrent calls will most likely be > implemented in _terms_ of threadWaitRead on cooperative systems. By all means, but that still doesn't mean that threadWaitRead needs to be in the standard. Cheers, Simon

2 1

RE: Re[2]: thread priorities?
by Simon Marlow 04 Apr '06

04 Apr '06

On 31 March 2006 10:24, Bulat Ziganshin wrote: > Hello Simon, > > Friday, March 31, 2006, 12:24:23 PM, you wrote: > >>> threadSetPriority :: ThreadID -> Int -> IO () > >> I'd rather not, if we can avoid it. The only rationale I'll offer is >> that we don't have it in GHC, and people manage to do a lot without >> priorities. Priorities come with a whole can of worms that I'd >> rather not deal with. > > it was requested by Joel Reymont, and he even give us information how > that is implemented in Erlang, together with hint to assign higher > priorities to consuming threads. Yes, but the Erlang implementation doesn't do anything about priority inversion. Also, I don't think Joel really wanted priorities, his problem could have been solved by using bounded channels. Cheers, Simon

3 2

RE: Re[2]: 'deriving Tree (Eq,Ord)'
by Simon Marlow 04 Apr '06

04 Apr '06

On 04 April 2006 14:35, Bulat Ziganshin wrote: > Hello Ross, > > Tuesday, April 4, 2006, 4:55:09 PM, you wrote: > >>> http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg00727.html >> (Making 'deriving' a separate declaration instead of a clause) > >> Orphan instances are discouraged in the GHC libraries, so there might >> not be much support for adding a feature designed to permit orphan >> derived instances. > > sorry, i don't understand how them are discouraged? GHC can't support > this because of it's internal limits? i think you mean some other > thing but i can't understand you Discouraged in the sense of "it works fine, but we don't recommend it". Compilation times may be worse if you have orphan instances, because the compiler *always* has to read an interface file containing an orphan instance if it is in the transitive closure of imported modules. Cheers, Simon

1 0

Deriving for newtypes
by Bulat Ziganshin 04 Apr '06

04 Apr '06

Hello , as i see, it was some form of formal specification for subj: http://www.cse.unsw.edu.au/~dons/haskell-1990-2000/msg05468.html -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

RE: deeqSeq proposal
by Simon Peyton-Jones 03 Apr '06

03 Apr '06

Interesting idea. What would you expect to happen here? f x xs = let g y = x+y in map !! g xs Here I'm evaluating the function g hyperstrictly before the call to map. Does x, the free variable in g's function closure, get evaluated? >From an implementation point of view, you could imagine that hyperstrict evaluation would pull apart function closures, as well as data structures. But I'm not sure you could give that a sensible denotational semantics. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Andy Gill | Sent: 30 March 2006 23:12 | To: haskell-prime(a)haskell.org | Cc: Laura McKinney | Subject: deeqSeq proposal | | For the reasons talked about in previous posts, I'd like to propose a | deepSeq | for Haskell'. | | - It provides a mechanism to allow an effective, systematic | tracking down of | a class of space leaks. | - It provides a mechanism to simply stomp on a class of space leaks. | - It avoids the user having to explicitly declare instances for a | homebrew deepSeq | for every type in your program. | - It has a declarative feel; this expression is hyper strict. | - Is a specification of strictness. | - It will open up various optimization opportunities, avoiding | building thunks. | (I dont talk about this more, but I'm happy to elaborate) | - It can have an efficient implementation, or a simple (slow) | implementation. | (The fast implementation one can be used to stomp space leaks, | the slow one can help find the same leaks.) | | What I would like to propose for Haskell' are four things: | | (Essential) Add a deepSeq function into Haskell' | | deepSeq :: a -> b -> b | | - Don't really care if its in a class or not; would prefer not for | the reasons John Hughes talked about. | - This would deepSeq all its children for regular constructors. | - deepSeq would not indirect into IO or MVar. | - functions would be evaluated to (W?)HNF. | - IO, ST are functions under the hood. | | (Easy) Add a $!! function, and a strict function | | f $!! a = a `deepSeq` f a | strict a = a `deepSeq` a | | (Nice) Add a !! notation, where we have ! in datatypes. | | data StrictList a = Cons (!!a) (!!StrictList a) | Nil | | (Perhaps) Add a way of making *all* the fields strict/hyperstrict. | | data !!StrictList a = .., | | We could also do this for ! | | -------------- | | Implementation: | | deepSeq (RAW_CONS <is_deep_seq'd_bit> ... fields ) = | if <is_deep_seq'd_bit> == True | then return /* hey, we've already deepSeq'd this */ | else set <is_deep_seq'd_bit> to True. | deepSeq (field_1) | ... | deepSeq (field_n) | deepSEQ (REF/MVAR...) = return | | So we only deepSeq any specific constructor once! Sorta like lazy | evaluation :-) | We'd need to catch exceptions, unset the is_deep_seq'd_bit, so that any | subsequent call of deepSeq would also have the option of raising the | exception. | | So, | | - How easy is this to add to the compilers? It looks pretty simple | to me, | and would provide huge bang-for-buck for Galois. | - Any alternatives to the key concern; stomping on space leaks. | (This proposal is orthogonal to the seq/Class discussion) | | Andy Gill | Galois | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

3 2

Concurrency
by John Meacham 03 Apr '06

03 Apr '06

I have tried to summarize the current thinking into a proposal on the wiki. http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrency I split it into 3 parts. the standard - all haskell' compilers must implement optional preemption - ability to preempt pure code, fairness guarentees, interleaved evaluation operators (merge, nmerge) optional OS threads - bound threads, SMP, reentrant concurrent FFI calls supported. comment or modify it at will. John -- John Meacham - ⑆repetae.net⑆john⑈

5 8

Re: Concurrency
by John Meacham 03 Apr '06

03 Apr '06

On Fri, Mar 31, 2006 at 04:21:26PM +0100, Simon Marlow wrote: > Great. Apart from my misgivings about allowing cooperative scheduling > at all, here's a few comments on the proposal: much much preferable to a standard that not everyone can implement. :) > - I wouldn't include threadWaitRead, threadWaitWrite, > or threadDelay at all. These can all be implemented using > FFI, so don't belong in the concurrency library. Their > presence is largely historical. They all have special implementations on a 'epoll' based system. threadDelay turns into the timeout parameter to select, waitread/write turn into the basic building blocks of your epoll wait-list. We definitly want these in the interface as primitves. In particular, foregin concurrent calls will most likely be implemented in _terms_ of threadWaitRead on cooperative systems. > - yield bothers me a little. If it weren't for cooperative > systems, yield would be semantically a no-op, because the > no-starvation guarantee means you never need it for > correctness. I think it's ok, just a bit unsettling. even pthreads provides it. <noise> I think you place a lot of faith in pre-emption. :) In my experience, it doesn't actually buy you a whole lot over state-threading in the non SMP case. everything would be different if we were thinking of different processes on the same computer, where you wouldn't want one buggy one interfering with others, but in general you consider a single program buggy or bug-free as a unit. </noise> In any case, IO multiplexing is 90% of the uses of threading anyway, (ginsu,yi,gui apps that don't do background processing, etc...) which cooperative threading is ideal for. not that there arn't itches that only preemptive threads can scratch too. > - In the optional OS threads section it says "allows multiple > haskell threads to run at once" - actually you can provide > all that without allowing multiple haskell threads to run > at once, eg. ghc-6.4.1 with -threaded. I'll modify it. okay. yeah, I just sort of outlined the options figuring we would fill in the details later. John -- John Meacham - ⑆repetae.net⑆john⑈

3 5

RE: Specification of newtype deriving
by Simon Peyton-Jones 03 Apr '06

03 Apr '06

| By the way, the description in the GHC User's Guide 7.4.12.2: | | newtype T v1...vn = T' (S t1...tk vk+1...vn) deriving (c1...cm) | | is too restrictive in requiring that S must be a type constructor of | the same arity as T, forbidding things like | | newtype Wrap m a = Wrap (m a) deriving (Monad, Eq) | | It should be | | newtype T v1...vn = T' (t vk+1...vn) deriving (c1...cm) | | with vk+1...vn not free in the type expression t. It should also | mention that T may not be recursive, unless all the classes are | those derivable by the existing mechanism. (There is some | awkwardness in the overlap between the two mechanisms.) Good point. It turned out that the HEAD already implemented this, but because I hadn't thought of this case, I'd missed a test in the eta-ok test. So there was a lurking bug. I've fixed the documentation as you suggest too. Thanks for pointing this out Simon

1 0

terminating instances
by Ross Paterson 03 Apr '06

03 Apr '06

GHC 6.4 has rather conservative constraints on instances to guarantee termination. GHC 6.5 has more liberal constraints; see http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/FlexibleInsta… Unfortunately instances generated by newtype-deriving need not satisfy either of these constraints (but the newtypes are required to be non-recursive). I can't construct a problem example for the 6.4 rules (but nor is there an obvious termination ordering). However the following is non-terminating (caught by the depth limit) for GHC 6.5: class C a where foo :: a -> Bool -- instance C (f (Maybe a) a a) => C (Bar f a) newtype Bar f a = Bar (f (Maybe a) a a) deriving C instance C (Bar (,,) a) => C (a,b,c) where foo (a,b,c) = foo (Bar (Just a,a,a)) f = foo ('a', 'b', 'c')

1 0