Andrew J Bromage <[EMAIL PROTECTED]> writes:
> G'day all.
>
> On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
>
>> [ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
>
> Understood.
>
>> Isn't compiler convienience a (the?) major issue here?
>
> I wouldn't call it a "major issue". I think of it as a constraint.
>
> The major issue is performance, subject to the constraint that it
> should be possible to write a working compiler (possibly generating
> inefficient code) without going to a lot of trouble.
>
>> How common do you expect tail calls to be? (Got practical examples?)
>
> In Perl, not common. When's the last time you used "goto-&NAME"?
In an autoload, but not anywhere else 'cos it's a pain in the arse to
go fixing this up by inspection (and there's usually no performance
gain in Perl anyway). But if I weren't concerned with the 'damage' it
would do to caller (and generally I'm not; anyway, the 'interesting'
caller is usually what would be the continuation anyway), I do loads
of tail calls.
sub Foo::method {
...
$some_object->callback_to($self); # Tail
}
sub Thing::callback_to {
my $self = shift;
my $caller = shift;
$caller->handle_thing($self); # Tail
}
Classic double dispatch; the stack frames associated with the
application of both these methods are completely useless. I will be
arguing in P6.language for a C<use more 'tail-optimization'> pragma
for handling stuff like this.
> In functional languages (e.g. Scheme) and logic languages (e.g.
> Prolog), it's usually part of the spec.
Indeed. So a scheme compiler that targets parrot may end up having to
ignore the standard parrot calling conventions, which would make
interoperation rather tricky.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
