Discussing the (im?)possibility of protype-based polymorphism for 5.12

["David Nicol" <davidnicol@gmail.com>]

On Mon, Sep 29, 2008 at 11:11 AM, Moritz Lenz
<moritz@casella.verplant.org> wrote:
>
> how could that be possible? Remember, prototypes change the parsing. If
> you have one sub foo() and one sub foo($), you'd get an ambiguous parse
> tree.

Sensible rules for resolving such ambiguities are obviously needed.
One possibility is that ambiguous combinations would not be allowed.
Another possibility is longest wins.  Longest wins would work for
unlink.

  foo;  # would resoves to foo()
  foo 27; # would resolve to foo($)


> Also &foo doesn't do prototype check von sub foo, so having multiple
> foo's with different prototype would lead to weird behaviour.

&foo could be a syntax error after declaring polymorphic foo.
Alternately, it could defer disambiguation to run-time, depending on
the current contents of @_.  Alternately, it could invoke a
prototypeless foo or die in the absence of such.


My other gripe about prototypes is the fact that one can't define a
syntax that will take more than one argument and then stop.  I would
like

   sub foo($$);
   sub bar(@);

to result in

   bar foo 1, 2, 3, 4;

getting parsed as

  bar( foo(1,2), 3, 4);

rather than the current behavior which is dying because foo has too
many arguments.

When I have brought this up in the past the concept has been condemned
as you-can't-get-there-from-here.

I can demonstrate both of these tricks using Macrame; if I had more time ...

---

Follow-Ups from:

"Rafael Garcia-Suarez" <rgarciasuarez@gmail.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---