Re: deeqSeq proposal
Lennart Augustsson wrote: > Andy Adams-Moran wrote: >>> The only thing you can do with non-functions is put them in the sin bin: >>> >>> deepSeq :: a -> IO () >> >> unsafeDeepSeq? >> >> I guess we don't want to expand the unsafe* vocabulary for Haskell' >> though ... > > What's wrong with > deepSeeqIO :: a -> IO () > ? > Then you can use unsafePerformIO if you want > deepSeq :: a -> b -> b Yes, quite right! In the case of deepSeqIO, we do know precisely what the safety condition is (as opposed to generic uses of unsafePerformIO and its cousins), so maybe we want to call that out somehow. A -- Andy Adams-Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290http://www.galois.com Beaverton, OR 97005 [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: deeqSeq proposal
Simon Marlow wrote: > On 04 April 2006 19:53, Andy Adams-Moran wrote: > >> Andy Gill wrote: >>> let xs' () = 1 : 2 : xs' () >>> let xs2 = xs' >>> >>> let xs = 1 : 2 : xs >>> >>> So deepSeq xs2 ==> _|_, but deepSeq xs ==> xs > > Yes, and hence deepSeq isn't monotonic. That's bad. Yes, quite right. In the standard denotational semantics, we can't even express deepSeq (the fact that it's not monotonic is a consequence, or a cause, depending on your PoV :-). If the semantics of Haskell was sensitive to sharing, and could distinguish between terms depending upon their level of sharing (probably not a desirable feature of a Haskell semantics), then deepSeq would be expressible and probably legit. The above example points to the fact that we don't won't to allow speculative use of deepSeq. However, if the program is hyperstrict in a term (i.e., demands all parts of the term, like all of the cases wherre Andy wants to use it), then it's safe to use deepSeq ahead of demand. Thus deepSeq begins to sound a little like unsafePerformIO: it's okay to use when you satisfy certain pre-conditions. At least we're able to /specify/ the pre-conditions for deepSeq :-) > The only thing you can do with non-functions is put them in the sin bin: > > deepSeq :: a -> IO () unsafeDeepSeq? I guess we don't want to expand the unsafe* vocabulary for Haskell' though ... A -- Andy Adams-Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290http://www.galois.com Beaverton, OR 97005 [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: deeqSeq proposal
Andy Gill wrote: > > On Apr 4, 2006, at 3:47 AM, Simon Marlow wrote: > >> On 30 March 2006 23:12, Andy Gill wrote: >> >>> Implementation: >>> >>> deepSeq (RAW_CONS ... fields ) = >>> if == True >>> then return /* hey, we've already deepSeq'd this */ >>> else set to True. >>> deepSeq (field_1) >>> ... >>> deepSeq (field_n) >>> deepSEQ (REF/MVAR...) = return >> >> So deepSeq doesn't return _|_ when passed a cyclic structure? This is a >> bad idea, because it lets you distinguish cyclic structures from >> infinite ones. deepSeq has to behave like a function, regardless of its >> implementation. >> >> Cheers, >> Simon > > Good observation, though pragmatically I'd rather the deepSeq to > behave well on loops. Its the thunks I'm trying to remove, not > the loop itself. > > Allowing loops in the returned value gives the the beauty of laziness > to construct the cycle, but the assurance that the structure does not > contain > thunks. A nice property, and a way to interact with laziness. > > let xs' () = 1 : 2 : xs' () > let xs2 = xs' > > let xs = 1 : 2 : xs > > So deepSeq xs2 ==> _|_, but deepSeq xs ==> xs > > I appeal to the "morally correct reasoning" argument .. If the program > terminates, then it is still correct. The deepSeq is an assertion about > the ability to represent the result in finite space. I'm not convinced Simon's argument holds, as I don't think you can use deepSeq to write a Haskell function that will distinguish cyclic structures from infinite ones. If we can't do that, then we haven't really added any new semantic observational capability to the theory, so I think the "morally correct reasoning" argument holds. Simon? A -- Andy Adams-Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290http://www.galois.com Beaverton, OR 97005 [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Concurrency
John Meacham wrote: > On Mon, Apr 03, 2006 at 05:22:34PM +0200, Benjamin Franksen wrote: >> On Monday 03 April 2006 08:38, John Meacham wrote: >>> On Sat, Apr 01, 2006 at 07:31:05AM -0500, David Roundy wrote: >>>> I'd like to be sure that asynchronous exceptions can get into the >>>> standard. They require concurrency, but I'm not sure that they're >>>> included in John's page. >>> I am assuming you mean supporting the 'throwTo' primitive, which can >>> be caught in the IO Monad? >> There is also divide-by-zero and related stuff that is thrown from pure >> code. > > those are 'ImpreciseExceptions' which is a different extension. The asynchronous exceptions extension is morally an extension to the imprecise exceptions extension :-) You /can/ do the former without the latter, but the semantics we gave assumed both were in play. A -- Andy Adams-Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290http://www.galois.com Beaverton, OR 97005 [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strictness standardization/description
Claus Reinke wrote: >- the Programatica project has a Haskell-in-Haskell implementation, >which apart from a possible candidate for such a library, prompted >many investigations into the oddities of Haskell 98, strictness >aspects of pattern matching amongst them, iirc; I think Bill > Harrison >was involved in most of those papers: > >http://www.cs.missouri.edu/~harrison/publications.html The Programatica team also produced a formal spec of the Haskell 98 module system, which may come handy: http://www.cse.ogi.edu/PacSoft/projects/programatica/diatchi.pdf Their Haskell implementation correctly implements Haskell98's recursive modules (among other subtleties). Here's the "Logic of Demand" paper that I think Claus is referring to above: http://www.cse.ogi.edu/PacSoft/projects/programatica/harrison-kieburtz.pdf A -- Andy Adams-Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290http://www.galois.com Beaverton, OR 97005 [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
