Re: [PROPOSAL] named arguments
Roger Browne
> Proposal: Named Arguments...
Your proposal covers all the functionality that I need for Amber,
thanks.
> b = new .Integer
> c = 3
I'm sure everyone realised, but just for the sake of completeness: the
first identifier above should be 'c'.
> - 'name' => var is the same as: var :named('name')
> (we can implement one of these or both)
Either syntax is fine for me. Might also want:
'name' => 'var' -or- 'var' :named('name')
for cases where 'var' has the same name as a PIR keyword.
On Nov 30, Chip wrote:
> Leo, would you be so kind as to rescind the parameter passing error
> flags, and make mismatches always throw? ...
> users can use :slurpy on an unused register to mean "extra params OK".
Any chance of making the above change first? Or at least making argument
count mismatch detection work with '.param'? (We're always being told
that compilers should emit PIR not PASM, and - although it's not a big
deal - I'll need a second pass through my argument lists to generate the
'get_params' version).
Regards,
Roger Browne
Leopold Toetsch
> On Fri, 2006-01-13 at 14:29 +0100, Leopold Toetsch wrote:
>
>>Proposal: Named Arguments...
>
>
> Your proposal covers all the functionality that I need for Amber,
> thanks.
Great.
>>Leo, would you be so kind as to rescind the parameter passing error
>>flags, and make mismatches always throw? ...
>>users can use :slurpy on an unused register to mean "extra params OK".
>
>
> Any chance of making the above change first? Or at least making argument
> count mismatch detection work with '.param'?
That's as easy as emitting one instruction in main:
errorson 0x0C
But yes, we should make that the default after at least the test suite
is fixed.
885/4851 subtests failing, 81,76% okay.
> Regards,
> Roger Browne
leo
Roger Browne
> ... making argument
> > count mismatch detection work with '.param'?
>
> That's as easy as emitting one instruction in main:
>
> errorson 0x0C
Wow, it really does work. Thanks! Although it misses the case where the
called sub has zero .params:
.sub 'main' :main
errorson 0x0C
foo(5)
.end
.sub foo
print "Not OK\n"
.end
> 885/4851 subtests failing, 81,76% okay.
Wow, that's a lot of tests affected by this one thing.
Regards,
Roger Browne
Leopold Toetsch
> Wow, it really does work. Thanks! Although it misses the case where the
> called sub has zero .params:
>
> .sub 'main' :main
> errorson 0x0C
> foo(5)
> .end
> .sub foo
> print "Not OK\n"
> .end
Yep. There is currently just one reason for that and it's in your code
too :-)
.sub main :main
.param pmc argv # implicitely very :optional
That is, if no '.param' is present, currently no get_params is emitted
alas no error checking and no exception.
This could be fixed by special-casing the initial call to ':main', and
then turn on param count checks if wanted. I'll have a look at it
tomorrow, if no one beats me.
> Regards,
> Roger Browne
leo
Jerry Gay
tests, and and about 750 of these test failures are PGE failures, this
is more limited that it may look.
but i can say that this feature is definitely well tested, however
indirectly that may be :)
i'll fix PGE, which will leave only about 135 failures, many of which
are in library code (no surprise there.) with a little help, i think
we can squash these failures in no time.
who's up for some bug hunting?
~jerry
Jerry Gay
> i'll fix PGE, which will leave only about 135 failures, many of which
> are in library code (no surprise there.) with a little help, i think
> we can squash these failures in no time.
>
that's still unclear to me, why don't i back up a bit and get things
cleared up.
applying the attached patch, rebuilding, and running 'prove -v
t/compilers/imcc/syn/pcc.t' should show you some failing TODO tests
where i'm unclear as to what the results should be.
i believe after all these tests are passing, we'll have a full test of
what the specification for mismatched parameter handling should be for
regular subs. i think there's still something missing from mismatched
parameter handling with coroutines (please see pcc.t test 7,) but
let's handle one thing at a time.
~jerry
Leopold Toetsch
> Wow, it really does work. Thanks! Although it misses the case where the
> called sub has zero .params:
>
> .sub 'main' :main
> errorson 0x0C
> foo(5)
> .end
> .sub foo
> print "Not OK\n"
> .end
As said, get_params isn't emitted at all, if there are no params. A
simple work-around could be:
.macro .no_params # maybe defined internally
get_params '()'
.endm
...
.sub foo
.no_params # could of course just emit the get_params directly
...
With r11213 this throws an exception for the above sample code.
Should we just use this syntax?
leo
Roger Browne
> As said, get_params isn't emitted at all, if there are no params. A
> simple work-around could be:
>
> .macro .no_params # maybe defined internally
> get_params '()'
> With r11213 this throws an exception for the above sample code.
>
> Should we just use this syntax?
It works for me. Thanks!
Regards,
Roger Browne
Chip Salzenberg
> This could be fixed by special-casing the initial call to ':main',
> and then turn on param count checks if wanted.
I think you'll need to invert that, given that code can be executed
before :main, e.g. :immediate. Default the errors on, and if
necessary[*], temporarily disable them for the :main call.
[*] I actually don't have a problem requiring all :main subs to have
explicit .param argv. But I'd also be OK with a code generator
hack that inserts an automatic .param __argv in :main if the user
doesn't say .param himself. Then the errors can be left on always.
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> i suppose we need a design decision on this.
We need a PIR version of get_params '()'. I'm OK with .no_params.
--
Chip Salzenberg <ch...@pobox.com>
Jerry Gay
added t/op/cc_params.t which tests required positional parameter
mismatches. it's a test generator, so the .t file isn't too
enlightening, but the test files it generates should give good ideas
for usage.
hope that helps.
~jerry
Leopold Toetsch
On Jan 20, 2006, at 20:57, Chip Salzenberg wrote:
> On Fri, Jan 13, 2006 at 05:51:53PM +0100, Leopold Toetsch wrote:
>> This could be fixed by special-casing the initial call to ':main',
>> and then turn on param count checks if wanted.
>
> I think you'll need to invert that, given that code can be executed
> before :main, e.g. :immediate. Default the errors on, and if
> necessary[*], temporarily disable them for the :main call.
Of course.
> [*] I actually don't have a problem requiring all :main subs to have
> explicit .param argv. But I'd also be OK with a code generator
> hack that inserts an automatic .param __argv in :main if the user
> doesn't say .param himself. Then the errors can be left on always.
Well, the problem isn't PIR code at all. C<.sub main :main> can
translate to everything including an extra line C<.param pmc __argv
:optional> if no params are given.
Troubles are coming from PASM code, which can start with an arbitrary
opcode. While a dummy Sub PMC is already provided, it's not trivial to
insert an empty get_params opcode.
Therefore the simpler way is to special-case the call to :main.
leo