[lbpp-devel] DECLARE statement USING clause syntax

[Anthony L. <aj...@be...>]

All,

I have something that I'd love to get an opinion on - and a chance for
people to chime in ;-)

I assume everyone is familiar with the DECLARE statement but if not,
here's a basic synopsis:

The DECLARE statement tells the compiler how to interpret a statement or
function call.  Currently, it can take a either a type or literal as
it's arguments and then generates a function called based name mangling
algorithm.

So, the DECLARE statement for the BUTTON command is as follows:

DECLARE STATEMENT BUTTON &handle "," string "," label "," keyword ","
double "," double

' Valid BUTTON call
button #window, "Click Me", [test], UL, 10, 10

There is also one for the specification of width and height, but we'll
ignore that for now.  The & prefix causes a variable to be passed by
reference.  The caller of the statement does not have to do anything
special.

This will get translated to the following C prototype:

void LB_BUTTON_11(LBContext *cxt, Variable *var, LBString str,
Label *label, char *keyword, double x, double y);

FYI:  LBContext contains all the information that lets one be able to
lookup variables by string name and labels by string name.  It also
allows for C functions to access LB variable such as WindowWidth,
WindowHeight, etc.

What I want to be able to do though, is having a USING clause.  This
would allow for a custom name atleast and optionally, reformatting of
parameters.  This way, instead of having to have the ugly name
"LB_BUTTON_11", it could be renamed to something more useful like
"LB_BUTTON_X_Y"

I also want to be able to use this to inline functions.  Take the
LB ABS function.  There already exists a C abs function.  But because we
mange the names and pass a context, a wrapper has to be written.  It
would be nice if the following could be used:

DECLARE FUNCTION ABS double USING "abs" (double)%1

The reason this doesn't work yet, is because I haven't been able to
determine the best syntax for the using clause.  I like the ability to
specify argument order via the %n thing.  %0 would also mean the
LB context so that one could either pass the context or just ignore it.
The cast is very C like but the idea is to support a the C primative
types.  The following types would be supported and should work for
everything that would ever be needed:

 LB TypeC Type
 uchar  unsigned char
 char   char
 ushort unsigned short
 short  short
 uint   unsigned int
 int    int
 ulong  unsigned long
 long   long
 single float
 double double
 void * void *

A & modifier would also be used to specify a reference so that to pass a
reference to a string, one would use (void * &)%n.  The idea too would
be to allow any number of nestings so that a reference to a reference
could also be used such as (int &&)%n.  This is just to be _that_
flexible.

I also am thinking of allowing a {} to be used too to denote straight C
code to be used.  This way, the following could be done:

DECLARE FUNCTION MessageBox string string USING "MessageBoxA" {NULL}
(void *)%1 (void *)%2 {MB_ICONINFORMATION | MB_OK}

It's a mouthful I admit but it would dramatically reduce code size and
also would make adding certain statements a heck of alot easier.

So, is this too much or does it work in a basic language?  I am
seriously considering using ptr to represent (void *) in LB since that
probably makes more sense.  What is everyone's thoughts on the pass by
reference syntax?  Should we use integer instead of int too?

Is the inline C stuff ({}) too much?  Remember, 99% of the
DECLARE statements will occur in the autoinc.bas file which most users
will never see so this statement should be considered an intermediate
statement if that helps any.  This statements needs to be good enough
though to replace CALLDLL's which I know people love alot.  It only
needs to occur once though so I definitely think it has a ton of
advantages to the CALLDLL statement.  My only concern is that I am such
of a C/C++ programmer that I might be introducing something that's a tad
to complex for a BASIC language.

Thanks for your input,
Anthony Liguori