need help: Mercury+C

tcklnbrg at at ingenuity-sw.com
Wed Sep 2 07:16:07 AEST 1998


I have looked over the examples and docs
for calling C-code from Mercury and I can't
figure out hot to make it work for me.

I have created a Flex grammar which yields
a single file implementing a lexer (lets call it "lexer.c").  

The code in this file is mechanically generated by Flex and
is very ugly (typedef'd and #define'd to abstraction).  

There are many functions in lexer.c,
but there is only one I am interested in calling
from Mercury code.  It has the signature:

char* tokenize(char *);

tokenize takes a filename as its only argument, and
returns a single malloc'ed string of tokens.

The lexer.c file contains one global var, "char * tokenStr",
which many of the functions in lexer.c use.  

The "tokenize(...)" prototype and tokenStr var are both
declared and defined in lexer.c. No header file is created.

Given the preprocessor spaghetti threaded through lexer.c, 
I haven't been successful in using Mercury's 
pragma's, c_code, c_header_code to directly create a .m file
from the lexer.c.  

It may be possible, but its going to be
ugly and complicated.  And every time I make a slight change
in the grammar file, I will lose my Mercury modifications.

lexer.c must be linked with one library (libfl.a) to form
an executable.

What is the *easiest* way to make the lexer.cc "tokenize" function
available to Mercury code and make sure that the tokenize function
has access to the global var, token?

Can I create an ordinary C library from lexer.c and libfl.a to be
used by Mercury---then how do I declare the tokenize function for
use in Mercury code since there is no corresponding .m file?
Since there is no .h file for tokenize, how do I make the function
signature known to Mercury? (extern...??)

The tokenize(..) c code in lexer.c does open and "read-only" a file.  
Does this mean that the Mercury function that corresponds to c
tokenize(..)
in file lexer.c, must be declared with the 2 extra io__state args?  

The c tokenize function
is guaranteed to always succeed---
it either returns a valid token string
or an error string.

Any help greatly appreciated.

Thanks,

Ann Tecklenburg



More information about the users mailing list