On 20 Jul 2010, at 21:18, William Tanksley, Jr wrote:
> Don Groves <dgroves <at> ccwebster.net> wrote:
>> William Tanksley, Jr wrote:
>>> Don Groves <dgroves <at> ccwebster.net> wrote:
>>>>>>> "William Tanksley, Jr" <wtanksleyjr <at> > wrote:
>>>>>>>> Laziness is one of the things that can't easily be imported
>>>>>>>> to a
>>>>>>>> concatenative language.
>>>> It seems to me that laziness can be implemented simply by
>>>> encapsulating all data in functions. If a particular function
>>>> is not called, that data is not evaluated. What am I missing?
>>> Data isn't supposed to be evaluated, of course; I think you meant
>>> encapsulating all functions in data rather than the other way
>> OK, guess I may need some hand-holding here:
> No... It's just unclear presuppositions. Thanks for making them clear
> by asking about them.
You're welcome and this is getting vert interesting
First, I should explain my background. When I was at UCLA in
the early 60s, there was no such field as computer science.
The closest thing to it was a math class on numerical methods
taught by a physics professor.
I was working as a Fortran programmer though and that's how
I came to know this stuff. I learned assembly languages by always
printing what Fortran compilers called the "second file" which had
the assembly code interspersed in the Fortran code. Those were
the good old days for me...
>> Isn't call-by-reference essentially equivalent to lazy evaluation?
> No; C++ allows call by reference semantics (explicitly specified, of
> course) without being lazy at all. An early Fortran had implicit call
> by reference, again not lazy (but, I'm told, very dangerous). I don't
> use Perl, but I'm told it's call-by-reference.
The reason Fortran's call by reference was so dangerous was that
numerical constants were also passed by reference and hence their
value could be changed by the called subroutine. This was lazy all
right, a lazy implementation. Passing the address of a function which
would yield the constant would have been far safer but, in those days,
the programmer was expected to do most of the work. Programmer
time was dirt cheap by comparison to machine time on an IBM 7094
that cost $2 million 1960 dollars!
> Wikipedia just reminded me that you're thinking of "call by name" or
> "call by need", but those are simply ways to achieve lazy evaluation.
>> If the called function doesn't need a certain parameter during a
>> particular call, that parameter will not be evaluated. So, parameters
>> (data) are only evaluated when needed, i.e., they are lazy.
> That IS what lazy evaluation is, yes.
OK, at least I've got a handle on that concept.
>> In a call-by-value environment, It seems to me that encapsulating
>> all data in functions yields the same effect as call-by-reference. If
>> a parameter is not needed, its evaluating function will not be
> This gets confusing to me, so hold on tight...
> In order to pass a function to a procedure, the function has to be
> available as data. If it's not, you can't pass it.
I don't understand this -- I do it all the time in my C code by using
address operator, &, and the same is easily done in Forth, et al.
It means, of course that the called function must be more intelligent
than is required in some languages. It must know the type values
of its parameters. As I've read on this list in the past, it seems there
has been a lot of research aimed at automating that very task.
As I said, a most interesting and enlightening discussion. Thanks
for taking part.
> Now, if your language is lazy (or non-strict) this doesn't matter; you
> can avoid executing the function by never mentioning its parameter on
> an execution path. This allows languages that don't provide
> higher-order functions to still be very expressive.
> Yahoo! Groups Links