[Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

[Edward Kmett]

This doesn't really work in a non-strict language like Haskell with
uncontrolled recursion. We often need a lazy int that may be _|_ and
shouldn't affect termination of the program unless demanded.

The result would be that you'd actually have to compile all of your code
several ways times the number of type arguments and you'd get rather
severely different semantics around evaluation as it switched between
strictness and laziness.

Moreover, cycles that happened to involve one of these values would have to
tie the knot strictly, meaning you'd have issues like scheme where letrec
secretly exposes extra, observable, #f cases when you encounter a cycle.

-Edward

On Sun, Feb 7, 2016 at 7:17 AM, Ben Lippmeier <benl at ouroborus.net> wrote:

>
> > On 7 Feb 2016, at 9:50 pm, Joachim Durchholz <jo at durchholz.org> wrote:
>
> > For the Int/Int# concept, the approaches I have seen either ignore the
> efficiency and let the machine figure out what to do (Smalltalk, Python,
> pre-Int# Haskell), or they complicate the type system at the expense of
> polymorphism (Java, Eiffel), or they complicate the type system even more
> to regain some form of polymorphism (C++, today's Haskell).
>
> Although I haven’t implemented it, I suspect another approach is to just
> specialise every polymorphic function at its unboxed type arguments. Boxed
> and unboxed value types would share the same kind. Of course, full
> specialisation of polymorphic code assumes that code is available in the
> interface files, but we’ve almost got that already. Dealing with mutual
> recursion could be a pain, though.
>
> I don’t think specialisation was an option back when unboxed types were
> originally implemented. I believe GHC’s support for cross module inlining
> came some time after the unboxed types, if the publication dates of the
> relative papers are to be a guide.
>
> Ben.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160208/949a564e/attachment.html>