On Sep-28, Leopold Toetsch wrote: > Steve Fink <[EMAIL PROTECTED]> wrote: > > > I'm not sure IMCC is going to be able to autogenerate the prototyped > > and nonprototyped versions of the callee's entry code from the same > > set of .param declarations. > > This is currently implemented as the "unprototyped" case. If a sub does > expect to be called either prototyped or non-prototyped, the proto > specifier of the .pcc_sub SHOULD be omitted. The entry code then looks > at C<I0> and does either case. > > So we should specify, what to do with wrong param counts or wrong > types. pcc.t has some examples for this (labeled "unproto" or > "exception").
I was arguing that this isn't enough. We need the set of parameters to really be different in the two cases, so we need two sets of ".param" statements, not just one. > I think we als need the concept of a default value (for at least > Pie-Thon's sake - does Perl6 also have default values?) > > sub f($a, $b=1, $c="Default"); > ... > &f(42); Yes, this is what I was talking about in the big block comment in the sample code at the end of my last message. Perl6 does have them. I don't know whether Perl6 or any other language we want to be nice to has *non-constant* defaults. If so, and if we want direct support for them, then it means we need to evaluate them in the context of the callee. Which is the natural way to do it anyway, but having the caller fill in default values for a prototyped call could work around some of the issues with argument passing that would otherwise require more native support to handle. (I'd prefer the native support, whatever it might be.) There's the issue of detecting whether a parameter was passed or not, in order to decide whether to fill in the default value. (See my last message for more discussion of this.)
