Necroing this thread because I just noticed there's a (rather old!) bug report which covers much of the same ground and doesn't seem to have been mentioned by anyone:
http://hackage.haskell.org/trac/ghc/ticket/1349 2011/2/8 Gábor Lehel <[email protected]>: > 2011/2/8 Ketil Malde <[email protected]>: >> Gábor Lehel <[email protected]> writes: >> >>> Is there any sensible meaning for bangs on return types? I've been >>> trying to think this through but not necessarily succeeding. >> >> Not knowing Clean in any detail, I've always just thought that a type >> signature of, say: >> >> something :: !Foo -> Bar >> >> would mean the same as, in Haskell: >> >> something :: Foo -> Bar >> something foo = foo `seq` ... >> >> In this case, there's no point to a strict return type, since it would >> boil down to "x `seq` x", which is just "x". > > Yeah, this is what I keep arriving at as well, I'm not sure if there's > another option I might be missing... > >> >> But it seems that a lot of these discussions are about considering Foo >> and !Foo distinct types, which would mean that you can no longer, say, >> add a strict and a lazy integer - at least not with the current Num >> instance. I find this line of thought very confusing. > > As I would ideally imagine it, again, strictness would be entirely > orthogonal to the 'normal' part of the type. So you could combine Foo > and !Foo completely freely as if the ! had never been there. !Foo > would be a subtype of Foo, so to speak -- !Foo representing evaluated > values, and Foo representing either evaluated or unevaluated values. > The ! would be an instruction to the compiler/runtime, "make sure the > Foo is evaluated by this point", and information for the programmer, > "the Foo is certain to be evaluated by this point". Adding !s would > only ever result in evaluation happening, and not ever a type error. > The advantage over bang patterns would be that the time/place of > evaluation could be controlled by the user rather than/in addition to > the implementer of a function/type (or at least more flexibly and > easily than it can be done now), it would more visible, obvious, and > certain, and perhaps type inference/elaboration could even be done. > > But I'm minimally well-versed in compilers and type theory, so if > someone sees something fundamentally wrong with this idea, please > enlighten me. > >> >>> This does seem a bit excessive. As a start, I don't remember anyone >>> asking for control over (un)boxedness, so hopefully we could jettison >>> that part of it? >> >> Uh, you mean like in IOUArrays, the UNPACK pragma, or >> -funbox-strict-fields? Unboxing is an important optimization, but >> perhaps the current feature set suffices. > > Yeah, I meant within the current context. I don't recall hearing > complaints that control over unboxing is currently insufficient or > that unboxing is insufficiently predictable. (But if there have been, > feel free to fill me in...) > >> >> -k >> -- >> If I haven't seen further, it is by standing in the footprints of giants >> > > > > -- > Work is punishment for failing to procrastinate effectively. > -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
