[Haskell-cafe] Proposal: Non-recursive let

[Andreas Abel]

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.abel at ifi.lmu.de
> <mailto:andreas.abel at 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.abel at ifi.lmu.de <mailto:andreas.abel at ifi.lmu.de>> wrote:
>
>             On 22.07.2013 10:50, MigMit wrote:
>
>
>                 On Jul 22, 2013, at 12:27 PM, Andreas Abel
>                 <andreas.abel at ifi.lmu.de <mailto:andreas.abel at 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.abel at ifi.lmu.de <mailto:andreas.abel at ifi.lmu.de>
>             http://www2.tcs.ifi.lmu.de/~__abel/
>             <http://www2.tcs.ifi.lmu.de/~abel/>
>
>             _________________________________________________
>             Haskell-Cafe mailing list
>             Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at 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.abel at ifi.lmu.de <mailto:andreas.abel at 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.abel at ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/