Mmh, true, for polymorphic definitions there is not a lot to see. This probably diminishes the applicability of a strictness analysis quite a bit. Maybe it is entirely useless at this point.

It would make more sense after whole-program optimization. Ghc does not have this, I heard the Intel Research Compiler does such things.

This is becoming a very high-hanging fruit...

--Andreas

On 24.07.2013 20:22, Edward Kmett wrote:
You only have a Num constraint when type checking that code:

(+) :: Num a => a -> a -> a

For better or worse, you don't get strictness in the type signatures in
Haskell.

We do not separate codata from data here.

Without knowing about the particular instance of Num and even the
direction of recursion on (+) there is no information for such a
strictness analyzer to work with.

many :: Alternative m => m a -> m [a]
many p = ps where
   ps = (:) <$> p <*> ps
    <|> pure []

is another perfectly cromulent example of "value" recursion, and one
that is far nearer and dearer to my heart and is similarly opaque to any
such analysis.

-Edward



On Wed, Jul 24, 2013 at 4:14 AM, Andreas Abel <andreas.a...@ifi.lmu.de
<mailto:andreas.a...@ifi.lmu.de>> wrote:

    Sure.  I have not looked a concrete strictness analyses, but I
    expect they would treat Conat differently than Integer.  In particular,

       x   does *not* appear strictly in  S x

    if S is a lazy constructor.


    On 22.07.13 4:54 PM, Edward Kmett wrote:

        let x = x +1

        is perfectly cromulent when x is sufficiently lazy, e.g. in the
        one point compactification of the naturals:

        data Conat = S Conat | Z

        There it represents infinity with proper sharing.

        -Edward

        On Jul 22, 2013, at 10:24 AM, Andreas Abel
        <andreas.a...@ifi.lmu.de <mailto:andreas.a...@ifi.lmu.de>> wrote:

            On 22.07.2013 10:50, MigMit wrote:


                On Jul 22, 2013, at 12:27 PM, Andreas Abel
                <andreas.a...@ifi.lmu.de <mailto:andreas.a...@ifi.lmu.de>>
                wrote:

                    On 20.07.13 9:36 PM, Evan Laforge wrote:

                        However, I'm also not agitating for a
                        non-recursive let, I think
                        that ship has sailed.  Besides, if it were added
                        people would
                        start wondering about non-recursive where, and
                        it would introduce
                        an exception to haskell's pretty consistently
                        order-independent
                        declaration style.


                    For functions, recursive-by-default let makes sense.
                      But for
                    *values*, intended recursion is rather the
                    exception.  It is useful
                    for infinite lists and the like.  For values of
                    atomic type like
                    Int or Bool, recursive let is a bug.


                It seems hard to distinguish between them. What about
                values that
                contain functions, like data T = T Int (Int -> Int)?
                What about
                polymorphic values, that could be functions and could be
                not?


            I agree.  It cannot be implemented like that.  A thing that
            could be implemented is that

               let x = e

            is an error if x appears strictly in e.  In practice, this
            could catch some unintended cases of recursion like

               let x = x +1

            , but not all of them.

            Cheers,
            Andreas

            --
            Andreas Abel  <><      Du bist der geliebte Mensch.

            Theoretical Computer Science, University of Munich
            Oettingenstr. 67, D-80538 Munich, GERMANY

            andreas.a...@ifi.lmu.de <mailto:andreas.a...@ifi.lmu.de>
            http://www2.tcs.ifi.lmu.de/~__abel/
            <http://www2.tcs.ifi.lmu.de/~abel/>

            _________________________________________________
            Haskell-Cafe mailing list
            Haskell-Cafe@haskell.org <mailto:Haskell-Cafe@haskell.org>
            http://www.haskell.org/__mailman/listinfo/haskell-cafe
            <http://www.haskell.org/mailman/listinfo/haskell-cafe>



    --
    Andreas Abel  <><      Du bist der geliebte Mensch.

    Theoretical Computer Science, University of Munich
    Oettingenstr. 67, D-80538 Munich, GERMANY

    andreas.a...@ifi.lmu.de <mailto:andreas.a...@ifi.lmu.de>
    http://www2.tcs.ifi.lmu.de/~__abel/ <http://www2.tcs.ifi.lmu.de/~abel/>




--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to