Front page | perl.perl5.porters |
Postings from September 2008
Re: Discussing the (im?)possibility of protype-based polymorphism for 5.12
Thread Previous
|
Thread Next
From:
David Nicol
Date:
September 29, 2008 11:41
Subject:
Re: Discussing the (im?)possibility of protype-based polymorphism for 5.12
Message ID:
934f64a20809291140k370b2620g6ea438b009eb853a@mail.gmail.com
On Mon, Sep 29, 2008 at 12:40 PM, Rafael Garcia-Suarez
<rgarciasuarez@gmail.com> wrote:
> What about runtime lookup, like $x="foo";&$x ?
dynamic binding and &-syntax binding -- lets call both of them
sigilated binding -- would bind to the foo declared without prototype,
if any. The second instance of a prototype declaration for a routine
would create associate sigilated subroutine binding for that name with
an error.
>> Alternately, it could invoke a
>> prototypeless foo or die in the absence of such.
I currently think that;s the best alternative, and runtime lookup of
&$x is in that category. (presuming it's worthwhile feature at all)
> Prototypes in perl are more a mean of changing syntax, than doing type
> checking.
Prototypes are supposed to allow user-provied functions to parse like
builtins. Some builtins are parsed in a way not representable by
prototypes. I am suggesting one possibility for extending prototypes
to represent these tricky builtins.
> Type matching will be a mere heuristic, and likely to
> confuse the users in every edge case.
Prototypes are already confusing, and are taught in beginning perl
calsses as something advanced, to avoid, yet they are favored by some
who do use them. Extending prototypes in a way that is in keeping
with the current implementation will not make them any more confusing
than they currently are. I am not suggesting (today, anyway: I know I
have suggested this in the past and might again in the future) basing
dispatch on object bless-type or otherwise attempting to merge OO
method binding and prototypes. However, if the unprototyped routine
of several with the same name is the one that a dynamic call binds to,
that would be the one that a method call would bind to, which answers
the long-awaited call for a way to distinguish between normal calls
and method calls more elegant than examining $_[0].
> Run-time argument checking
> will be a sure way to slow down function calls...
Run-time argument checking is struck from the proposal. And in doing
so, the proposal grows in usefulness to provide a way to differentiate
between methods (unprototyped, available with symbolic binding) and
non-methods (prototyped, not available with symbolic binding, or only
available symbolicly by including the prototype.)
sub foo{ ...} # method
sub foo(@){ ... } # function
Macrame syntax-based polymorphism works by revising each version of a
multiply prototyped sub into a macro with a match signature based on
the provided prototype expression and a subroutine definition with a
new name taken from a reserved set such as rewriting foo($@) into
_Multi_SA_foo($@) so that afterwards, at compile time, calls to foo
are revised.
This approach works at a proof-of-concept level (Macrame is certainly
not ready for production use, but it does pass its own tests)
As an internals extension, the prototype if any could be carried with
the name in such a way to not clutter the package name space
(currently the prototype signature is carried with the named
subroutine, not part of the name: I want to make it part of the name
instead, or in addition), and symbolic coderef lookup could be
extended to allow forcing a multiply prototyped sub like so:
my $hassub = q/foo($$)/; &$hassub;
which can't be done with macro expansion.
Thread Previous
|
Thread Next