Verbose and flexible args and kwargs syntax

[Eelco]

On Dec 12, 8:05 pm, Eelco <hoogendoorn.ee... at gmail.com> wrote:
> To get back on topic a little bit, lets get back to the syntax of all
> this: I think we all agree that recycling the function call syntax is
> less than ideal, since while it works in special contexts like a
> function signature, its symmetric counterpart inside a function call
> already has the meaning of a function call.
>
> In general, we face the problem of specifying metadata about a
> variable, or a limited form of type constraint.
>
> What we want is similar to function annotations in python 3; in line
> with that, we could have more general variable annotations. With an
> important conceptual distinction; function annotations are meaningless
> to python, but the annotations I have in mind should modify semantics
> directly. However, its still conceptually close enough that we might
> want to use the colon syntax here too. To distinguish it from function
> annotations, we could use a double colon (double colon is an
> annotation with non-void semantics; quite a simple rule); or to
> maintain an historic link with the existing packing/unpacking syntax,
> we could look at an augmented form of the asteriks notation.
>
> For instance:
>
> def func(list*args, dict*kwargs) <- list-of-args, dict-of-kwargs
> def func(args::list, kwargs::dict) <- I like the readability of this
> one even better; args-list and kwargs-dict
>
> And:
>
> head, deque*tail = somedeque
> head, tail::deque = somedeque
>
> Or some variants thereof

As for calling functions; calling a function with the content of a
collection type rather than the collection as an object itself is a
rather weird special case operation I suppose, but we can cover it
with the same syntax:

def func(args::tuple, kwargs::dict):
    funccall(args::, kwargs::) <- void type constraint means
unpacking, for symmetry with args/kwargs aggregation
    funccall(::args, ::kwargs) <- I like this better, to emphasize it
being 'the other side' of the same coin, and quite close to ** syntax

Sequence and Mapping unpacking dont need their own symbols, if things
are done like this, since in the function declaration the meaning is
clear from the type of the annotations used, plus their position, and
in the call the meaning is clear from the type of the object
undergoing to unpacking operation.