An anonymous called ok writes:
jerzy.karczmarczuk wrote [about "R"]:
... This is not a functional language. There is some laziness (which looks a bit like macro-processing), sure.
There is no macro processing in R (or S).
I know I've been superficial, but, please, *try* to understand my point. There is a cheap (not always) way of making everything "lazy", by rewriting. If an expression is the argument of a function, what is passed is the representation of this expression. This gets evaluated in the context of the caller function, although perhaps in the environment of the argument itself, if there are external references. It is something *similar* to macros, and it is more or less what I understood from my - admittedly weak - knowledge of R, S, etc. (Frankly, I do not know them enough to make the difference). But this is not the same as the laziness - realization of the normal order of evaluation, call by name (need), etc.
The manual speaks about promises and about forcing them. But, at the same time we read that the call by value IS the protocol.
That is a misreading. Paragraph 2 of 4.3.3 says
The semantics of invoking a function in R argument are call-by-value. ...
But that is NOT to be read as "strict", but as contrasting with "call-by-reference".
There is a difference between call by name, and by reference.
... you didn't say that there were no *pure* lazy dynamically typed languages, only that there were no lazy dynamically typed languages.
Right. But then, laziness *AND* side effects may put you in a nice mess... Near your favourite 4.3.3 there are warnings against using functions with side effects, since the arguments may not be evaluated. Now, the discussion began with ideas how to advertize *functional* languages, not packages with dangerous, non-formalizable semantics, I thought we would agree on this point. OF COURSE, there are untyped languages with suspended evaluation. Snobol had "unevaluated expressions", Icon has "co-expressions", etc. But if the merits of FL include some protection against errors, issued from enforcing a concrete programming discipline, "R" doesn't seem to me a good example. But you are right in principle, there are languages with "a form of lazy evaluation", as the R manual delicately says...
I don't see how to make co-inductive constructions, infinite streams, etc.
I don't know what co-inductive constructions are.
OK, try to code in R the list [0,1,2,3, ...] using a co-recursive data definition, in Haskell: integs = 0 : (ones + integs) where ones = 1 : ones and where (+) acts on lists element-wise. This may be esoteric for most of readers here, but I happen to use such constructions, or worse... Jerzy Karczmarczuk