1.1 --- a/docs/invocation.txt Mon Jul 13 01:02:42 2009 +0200
1.2 +++ b/docs/invocation.txt Tue Jul 14 00:37:04 2009 +0200
1.3 @@ -209,7 +209,29 @@
1.4 One motivation: avoid explicitly making sequences.
1.5 Opportunity: avoid expensive dynamic allocation of sequences?
1.6
1.7 -Star parameters, known callables and sequences:
1.8 +Star parameters, approach #1:
1.9 +
1.10 + Make a sequence to hold the extra arguments, either in the caller for known
1.11 + callables or in the function itself.
1.12 +
1.13 + Such a sequence would need allocating and its contents copying from the
1.14 + stack.
1.15 +
1.16 +Star parameters, approach #2:
1.17 +
1.18 + Keep the extra arguments in the stack.
1.19 +
1.20 + Access to the star parameter would need to consider assignment to other
1.21 + things and "escape situations" for the parameter:
1.22 +
1.23 + def f(*args):
1.24 + return args # need to allocate and return the sequence
1.25 +
1.26 + Access to elements of the extra argument sequence would behave slightly
1.27 + differently to normal sequences, but this could be identified at
1.28 + compile-time.
1.29 +
1.30 +Star parameters, known callables and sequences, approach #1:
1.31
1.32 g(1, 2, 3, 4) # g known as function g(a, *args) at compile-time
1.33
1.34 @@ -217,10 +239,17 @@
1.35 1 -> argument #1
1.36 2 -> reference to sequence containing arguments #2, #3, #4
1.37
1.38 - (This according to approach #1 described for unknown callables. With approach
1.39 - #2, normal argument positioning would occur.)
1.40 +Star parameters, known callables and sequences, approach #2:
1.41 +
1.42 + g(1, 2, 3, 4) # g known as function g(a, *args) at compile-time
1.43
1.44 -Star parameters, unknown callables:
1.45 + g -> don't get any context information
1.46 + 1 -> argument #1
1.47 + 2 -> argument #2
1.48 + 3 -> argument #3
1.49 + 4 -> argument #4
1.50 +
1.51 +Star parameters, unknown callables, both approach #1 and #2:
1.52
1.53 g(1, 2, 3, 4) # g not known at compile-time
1.54