[Haskell-cafe] Proposal: Non-recursive let

[Edward Kmett]

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>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>
>> 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>
>>>> 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
>>> http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>>>
>>> ______________________________**_________________
>>> Haskell-Cafe mailing list
>>> 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
> http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130724/bb508a06/attachment.htm>