Adding modifiers to NCI

Geoffrey Broadwell geoff at broadwell.org
Tue Dec 23 22:27:42 UTC 2008


On Tue, 2008-12-23 at 12:41 -0600, Allison Randal wrote:
> The number syntax is really horrible, and can die. Others definitely 
> need a cleanup for consistency and sensibility.

Yes, and we need to make sure that we (portably) do the right thing with
unsigned integer types, small integer types, 64-bit ints when Parrot is
compiled 32-bit, etc.  For NCI, 90% solutions are 10% hell.

> My guess is that he means "scalar" versus "array" types, mainly because 
> of the Perl-like sigils.

The sigil-heavy design feels like too strong a single-language bias for
a core Parrot API.  I think the NCI should feel much closer to a
shorthand for some IDL.  The DBus method call signature string format
has some decent (but not phenomenal) prior art for this.

> 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.

Are there plans to enforce the in/out/inout distinction for arguments?
How do we call APIs that have each of those expectations?  (The in case
isn't as obvious as it sounds.  What do we do if the called API alters
it anyway?  Are we resilient to hanky-panky that may leave us with
now-invalid data structures in what was supposed to be read-only data?)

Also, can we automagically convert out arguments at the C level to 
return values at the PIR level, and similarly for inout?

> 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'd like to add integers as valid type modifiers for NCI, and ignore
(optional) whitespace.  That makes 'Iu16 F32 F32 -> F64' very simple and
obvious, to me at least.  If I can't get the space ignore, I'll live,
but I think integer modifiers are necessary to avoid going insane with
increasingly non-obvious modifier letters.  It also makes it easier to
handle future or specialty types without further depleting the lowercase
pool:  F16, I128, etc.

The other problem is APIs that use "C magic fairy dust sizing" types,
like 'long'.  We need to make sure there is a way to specify an integer
the exact same size as the platform's C compiler uses for int and long.

In the mid term it would be nice to have proper byte order handling as
well.  And then there's packed and unpacked count/array APIs ....

At what point do we cross over from direct NCI type maps to going
through the (Un)ManagedStruct PMCs or some Parrot equivalent of Perl5's
pack()/unpack()?  Personally, having used the *Struct PMCs, I'd like to
delay using them as long as possible -- it's a pain in the keister (and
rather slow) to set up an even moderately interesting call.

> Simon, could you reframe your proposal in those terms? Be as radical or 
> conservative as you like, and we'll bounce it around a few times.
> 
> (The NCI/extending/embedding interface isn't on the critical path until 
> the 1.3 release next June, but if we get a reasonable working syntax 
> together now and can implement it without disrupting 1.0-critical tasks, 
> we might as well go ahead and do it.)




More information about the parrot-dev mailing list