[Haskell-cafe] Byte Histogram

[Gábor Lehel]

2011/2/8 Ketil Malde <ketil at malde.org>:
> Gábor Lehel <illissius at gmail.com> 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.