From dmurdoch at pair.com  Sat Oct 11 05:02:55 2003
From: dmurdoch at pair.com (Duncan Murdoch)
Date: Sat Oct 11 05:02:47 2003
Subject: [Rd] An artifact of base being namespace
In-Reply-To: <Pine.LNX.4.44.0310102038040.20816-100000@itasca2.stat.uiowa.edu>
References: <uteeov43hd0lg5bjd7k069kdku96oa00t0@4ax.com>
	<Pine.LNX.4.44.0310102038040.20816-100000@itasca2.stat.uiowa.edu>
Message-ID: <lmreov0m6tip41d0h9thbpb2r0qug6fgq5@4ax.com>

On Fri, 10 Oct 2003 21:01:07 -0500 (CDT), you wrote:
>On the other hand, having lazy evaluation makes other things simpler:
>there is no need for special operators, macros or other such stuff;
>everything can be done with ordinary functions.  if, for, try,
>on.exit, switch are just functions. Some of them happen to be
>implemented internally for efficiency, but this isn't essential.

I can think of two uses for lazy evaluation: what you say above, where
parameters are given but never evaluated, and cases where default
values are computed using variables that don't exist at the time of
the function call.  Are there others?

The first use is incompatible with generics, but I don't think the
second is, and I'd guess that the second use is the most common one.
So not all functions could be generics, but maybe most of them could
be?  Maybe we should register functions as not being compatible with
being a generic, but let everything else act like one by default?

>But it would be a good idea, once the design of methods stabilizes a
>bit more, to review functions in base and other packages to decide
>which ones ought to be generic.

That sounds like a good idea, but is "once the design stabilizes a bit
more" a stopping time? :-)

Duncan Murdoch


[Rd] An artifact of base being namespace
Duncan Murdoch