
Sorry, forgot to reply to the list. On 01/09/2016 06:36 PM, Tom Ellis wrote:
On Sat, Jan 09, 2016 at 06:29:05PM +0100, Jerzy Karczmarczuk wrote:
Tom Ellis wrote :
consider a lazy language, Haskell--,/which doesn't allow recursive bindings of non-function types./ In Haskell-- you *cannot* write
exps = 1 + integral exps
but you have to write
exps = I.fix (\e -> 1 + integral e)
So we see that the nice syntax "exps = 1 + integral exps" is not due to laziness (since Haskell-- is lazy, but you cannot write that). If you say so...
You may always say:
"Consider the syntax XXXX. Now, consider a lazy language which doesn't allow XXXX. So, your nice syntax has nothing to do with laziness. QED".
Granted, but the more important point was the sketch of the strict language which *does* allow it. You have conveniently failed to challenge me on any of the aspects of the very simple design.
Tom, construct such a language, and I might believe you.
I remind you that Doug's original claim was "this won't work in a strict language", which he offered without proof, even a sketch of a proof. I still hold the onus is on you (or him) to demonstrate it!
If I'm not mistaken, a strict language implies that arguments are evaluated before function calls. To calculate exps, you need to add 1 to the result of the function call integral on argument exps. To evaluate that call, it first evaluates the arguments: exps. And so on... This causes a non-terminating calculation, I would expect. IMHO, unless you add explicit laziness to a strict language, which some do but it requires some extra syntax, this cannot be done. I do believe Scheme or ML does have laziness annotations, and they show in the data types and function call syntax.
Also, I recall your former objection, that
*exps = 1 + integral exps*
should work "for lazy lists" in a strict language. Please, implement it. Since you would need *letrec* anyway, I suggest Scheme (say, Racket). You will see what that implies. Compare the behaviour of strict and lazy Racket.
Maybe since Scheme and Racket are not typed things will go through there. I shall have to look into it. I don't know the languages.
Tom
If you propose that a function (or anything with a function type) is implicitly lazy, then I think that you are describing a lazy/non-strict language. kind regards, Arjen