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