Adding modifiers to NCI

[Allison Randal]

Vadim Konovalov wrote:
> 在 Monday 22 December 2008 05:10:14，Simon Cozens 写道：
>> Hello all,
>> 	I've started looking at adding Postgres bindings to DBDI, and hit a bit
>> of a wall; it needs its bind parameters passed in as an array of
>> strings. Now there is an undocumented "T" signature for char** that's
>> been sitting there for a while, but before I found it I got a bit
>> frustrated about the state of NCI signatures. They've expanded a little
>> randomly, whether it's the fact that "s" means a short but "S" means a
>> string, or the 2/3/4 grabbing-numbers-from-a-PMC signature.
> 
> Last time I've tried to use "3" - pointer to int - I completely failed :(
> 
> So whatever you do please do, there are chances that pointer to int start 
> working :)

The number syntax is really horrible, and can die. Others definitely 
need a cleanup for consistency and sensibility.

>> 	I think we've reached that point. My plan is to add two modifiers: "$"
>> means "get this type from a PDD" and "@" means "this is an array". Hence
>> 2/3/4 would be replaced by $s, $i and $l respectively.
>> "T" would probably become "@S".
> 
> Sorry for the question - how a type could be got from a PDD?

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

>> 	I don't think we should go down the road of a completely new
>> DSL for function signatures - please no, let's not overcomplicate until
>> we need it - but I think we do need something a little more flexible,
>> and a little better organised, than what we have already.

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.


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

Allison