Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no args checking for a sub without params #600

Open
coke opened this issue Sep 21, 2009 · 9 comments
Open

no args checking for a sub without params #600

coke opened this issue Sep 21, 2009 · 9 comments

Comments

@coke
Copy link
Contributor

coke commented Sep 21, 2009

Originally reported in [http://rt.perl.org/rt3/Ticket/Display.html?id=39844 RT].

If no .params are given, no args checking is done on sub invocation. From the original:

On Sat Jul 15 23:29:10 2006, mdiep wrote:
> I expect this to die with a "too many args" error, but it doesn't -- 
> it prints "ok":
> 
> .sub main :main
> test("foo", "bar")
> end
> .end
> 
> .sub test
> print "ok\n"
> .return()
> .end
> 
> --
> Matt Diephouse
> 

2 sample patches to achieve this (both of which are declared to fail) are attached to the original ticket. Neither apply cleanly to trunk.

There is a question, however, as to whether or not the existing behavior is desirable - should we always check args? should we always check except for :main? (should we check for :main too and suggest that the programmer use .param args :slurpy to avoid any issues?)

There's a test already committed in t/op/calling.t

Originally http://trac.parrot.org/parrot/ticket/1033

@wagle
Copy link

wagle commented Feb 16, 2010

I was trying to distinguish between a getter (0 args) and a setter (1 arg), and the getter was grabbing things with 1 arg, which I think is a total error.

I understand that its a (sloppy) unix idiom to often pretend that :main receives 1,2, or 3 args, so I could see :main setting up a complex :multi (and/or implied .param's) for that.

Everything else is an error. Squash it now, it ain't going to get better with time. Add a catch-all dummy .param option if you must.

By the way, my zero-arity getter was marked :multi(), making it twice the error (?) for it to accept arity-1 calls, ESPECIALLY since there was a arity-1 acceptor (ie, the setter) sitting there, ready.

@wagle
Copy link

wagle commented Feb 16, 2010

PS. I initially annotated the setter with :multi(P), which didn't accept anything I sent at it. :multi(PMC) fixed that (as did :multi(_)), so my getter and setter work for 0 and 1 args, but not 2, etc.

Could someone add some examples (besides :main) of why you would want 0-arity sub's to be grab-all's?

@wagle
Copy link

wagle commented Feb 16, 2010

PPS. That is, the http doc's suggest P, and make no mention of PMC as an option to :multi.

@wagle
Copy link

wagle commented Feb 16, 2010

PPPS. I don't stop thinking:

my getter is marked :multi(), yet accepts arity-2 calls. I can't see how that's correct.

@leto
Copy link
Member

leto commented Feb 19, 2010

It seems that throwing an exception when no function of the correct arity is found should be the correct behavior. This probably incurs a deprecation policy.

@pmichaud
Copy link
Member

my getter is marked :multi(), yet accepts arity-2 calls. I can't see how that's correct.

The :multi() pragma is used only to constrain the types and minimum number of arguments, it does not provide an arity-based constraint. In particular, :multi(Foo?) simply says that the first argument must be of type 'Foo', it doesn't limit the sub to calls with only one argument.

:multi(_) says that a sub requires at least one argument (but may have more), and that argument may be of any type.

Thus ":multi()" simply says that a given sub is a MultiSub and has to have at least zero arguments to be invoked (but is allowed to have more).

Pm

@cotto
Copy link
Contributor

cotto commented Jan 4, 2011

gci task created for this ticket

@jkeenan
Copy link
Contributor

jkeenan commented Aug 27, 2011

Replying to cotto:

gci task created for this ticket

This wasn't taken up by any of the GCI students. whiteknight, given the work you've done on IMCC, do you have any opinion on this?

Thank you very much.

kid51

@Benabik
Copy link
Member

Benabik commented Oct 1, 2013

Although it's been more than a year since I was poking around bytecode/IMCC, I believe this is caused by the fact that IMCC doesn't emit any of the get_param, etc. ops when there are no .param directives. So argument handling is simply never called. (And hence, never has an opportunity to check arity.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants