Adding modifiers to NCI

[chromatic]

On Friday 26 December 2008 20:12:00 Allison Randal wrote:

> > I also don't see any examples of out parameters.

> Toss me some examples and I'll do a first pass at fitting them into the 
> hypothetical new syntax.

See t/pmc/nci_52.pasm and nci_i33 in src/nci_test.c.  The signature for this 
function is "i33", which means it returns and int and takes two pointers to 
ints.  It modifies the pointed-to ints in place and returns an int value.

> chromatic wrote:
> >> For the sake of unifying the parsers of signatures of two completely
> >> different calling conventions with separate goals, a C signature of a
> >> form well- understood for almost 40 years as:
> >>
> >>      int squash_coords_to_int(uint16 x, uint16 y);
> >>
> >> .. becomes somewhat less obvious:
> >>
> >>      Tu2 Tu2 -> T1
>
> Well, the NCI version isn't particularly obvious either. I suppose we
> could go to "int uint16, uint16" or some such, but the short signature
> strings seem to have worked well.
>
> On the whole, the definition of "usability" isn't "intuitively obvious"
> because nothing is ever intuitively obvious to the outsider.

"Intuitively obvious" has never been my goal nor complaint.  I just want 
something easier to use than XS typemaps.

I want people writing NCI bindings to C functions to say "Hey, these signature 
strings remind me of C function signatures so well that it's very difficult to 
get them wrong!"

I want people writing PCC signatures to say "Hey, these signature strings 
remind me of Parrot calling conventions so well that it's very difficult to 
get them wrong."

I believe that those are very separate tasks.  The former is for mere users of 
Parrot.  The latter is for Parrot hackers.  I do not believe that unifying two 
completely different sets of calling conventions used in two very different 
situations by two somewhat disjoint groups of people can achieve either goal.

> What we're looking for is a consistent system, and to make it easier to
> learn than what we have now.

What could be more consistent with 40 years of C function signatures than the 
same C function signature syntax that C function signatures have had for 40 
years?

> >> .. and we tell all of the people writing PCC signature strings to ignore
> >> all of the type sizes and signedness modifiers and all of the people
> >> writing NCI signature strings to *know for certain* how big an INTVAL is
> >> on every platform, because if they accidentally leave off a number
> >> they'll get weird crashes and ask me to spend my day poking at code with
> >> GDB,
>
> That distinction has to do with what you're calling, not what syntax
> you're using. The same distinction exists now for NCI used internally
> and NCI used externally.

It doesn't, because every NCI signature expresses C calling conventions.  
That's what they're for.

> >> Wasn't one goal of defining and using INTVAL and FLOATVAL and STRING
> >> within the Parrot API to avoid the explosion of datatypes which C has
> >> suffered because it doesn't have a type system and encourages people to
> >> agonize over the position of each last byte?
>
> Yes, but we're defining a way to interface to C functions, so we're
> hampered by its pedantic nature.

I see no reason why we need to extend Parrot's calling conventions to handle 
the range of types and signedness and workarounds for C's peculiarities.

Let's take another example.  PCC supports multiple return values.  C doesn't.  
How do you make it screechingly obvious that specifying multiple return values 
in a unified signature intended for a C function is wrong?  C requires that 
every function signature specify a return value, even if it's void.  How do 
you make it screechingly obvious that forgetting a return value on the 
signature will likely crash your program without requiring you to run the 
program and see it crash (and if you're lucky, it'll corrupt memory very close 
to the point of call, so it'll crash in a place that's relatively easy to 
debug with gdb).

Still not convinced?  How do you specify a tailcall in PCC?  What does that 
mean when passed as a C signature?

I want my interfaces so obvious that bugs will jump off of the screen when I 
skim the code.  I believe that unifying two completely different calling 
conventions will not help.

The details behind the proposed abstraction will always leak through the 
abstraction because the details are the point of the abstraction.  (Also, if 
we're still using C calling conventions within Parrot for flow of control in 
two years, we've probably done something wrong.)

-- c