09 Mar, 2011, JohnnyStarr wrote in the 1st comment:
Votes: 0
In the spirit of Lua, my small language will be embeddable in other languages.
I understand that I can expose variables and functions using an API of some sort.

I am concerned that my naming conventions don't clash with the host application.
Consider the name Token for example. This would be the typedef name of my
struct Token structure. I understand that a struct tag is in it's own namespace,
but what if the host application also had a Token structure?

I realize the host application would need to include token.h in order to even have it defined, but
there would still be a clash somewhere down the line.

Since I will be compiling into a library format, will this even be an issue?
10 Mar, 2011, Tyche wrote in the 2nd comment:
Votes: 0
The only thing that will clash are the types and functions exposed in the API. The struct Token sounds like an internal type unless you are exposing the AST to the host, possibly for a debugger app. As it's common for applications to use the same nouns like token, string, list, class, person, etc., my own particular convention is to prepend names with a two letter code. For example, my string and list classes (applies to structs as well) in TychoMud are TMString and TMList.
10 Mar, 2011, JohnnyStarr wrote in the 3rd comment:
Votes: 0
I see, that makes sense.

It's difficult for me to decide when to expose functions to the API. I've noticed
in Lua that the standard libraries utilize the API. I suppose libraries are partially internal,
but if the language offers the ability to extend it with C libraries, then it would have to
use the API functions to manipulate the stack.

BTW, is TychoMud your current project?
10 Mar, 2011, JohnnyStarr wrote in the 4th comment:
Votes: 0
I have portability question concerning function pointers:

My list structure for instance is type uList, and each element is uListIter. Currently
I am using a void* to store the value. Of course this requires explicit casts which can
be a burden, however I am making it easier on the user by providing help functions. IE (toString, toNumber, etc)

The naming convention is currently: uL_dosomething.

I view the uListIter structure as an internal to the uList structure, so I don't feel comfortable exposing
iterator functions to the rest of the program.

Then it dawned on me to use function pointers to static uListIter functions.

example:

uList *l;
uListIter *i;

uL_add(l, "hello");
uL_add(l, "world");

uL_foreach(i,l)
printf("%s", i->toString(i));


I believe C89/C90 allow this concept. But are there any drawbacks I'm missing?
Obviously you have to pass the pointer, but besides that it's a bit more readable.
11 Mar, 2011, Tyche wrote in the 5th comment:
Votes: 0
JohnnyStarr said:
BTW, is TychoMud your current project?


No an old project…slightly similar I guess, since I implemented a tiny language called Aphrodite.

JohnnyStarr said:
I believe C89/C90 allow this concept. But are there any drawbacks I'm missing?
Obviously you have to pass the pointer, but besides that it's a bit more readable.


Not sure. I've used something along these lines.
typedef int (*DoFunction) (ListNode*);

void r_walklist(ListNode *n, DoFunction f)
{
if (n == NULL)
return;
f(n);
r_walklist(n->next, f);
}

int for_each(LinkList *l, DoFunction f)
{
r_walklist(l->head, f);
}
/////
int my_function(ListNode *n)
{
printf("Data is %s\n", n->data);
return 0;
}
LinkList *l = new_list();
for_each(l, my_function);
0.0/5