Adding modifiers to NCI

chromatic chromatic at wgz.org
Wed Dec 24 07:02:14 UTC 2008


On Tuesday 23 December 2008 10:41:04 Allison Randal wrote:

> The over-all direction we're moving with function signatures is toward
> everything using the PCC signature strings. That is, currently:
>
>    I INTVAL
>    N FLOATVAL
>    S STRING *
>    P PMC *
>
> with modifiers:
>
>    f flatten
>    i invocant
>    n named
>    o optional
>    p opt flag
>    s slurpy
>
> and "->" to separate the arguments from the return values. So "PiN->S"
> is a method call on a PMC object, with a float argument that returns a
> string result.
>
> This syntax would have to be extended to cover all we need for NCI, but
> let's start with this as the base, rather than extending the existing
> NCI signature string syntax. The initial ground-rules for extensions:
>
> - Capital letters always represent the core argument/return type.
>
> - Lower case letters and punctuation (aside from "->") always represent
> modifiers to the argument/return type.
>
> - Modifiers always follow the argument/return type.

I don't see how this works with C calling conventions.  It works fine for 
Parrot calling conventions, but C calling conventions care about type, width, 
signedness, and pointerness, and they're strictly positional.

I suppose we could flip the current NCI signatures so that the return value 
type signifier always appears at the end of the signature, prefixed with ->, 
but even that doesn't make sense, for two reasons:

	- C functions always have a single return type (even if that type is void)
	- our current signature style matches C function signature declarations more 
directly, where the C signature is void int int int, for example.

What value is there in attempting to unify the descriptions of two very 
different types of calling conventions?

-- c


More information about the parrot-dev mailing list