[m-dev.] Re: Documentation of support for polymorphic pragma c code

[Fergus Henderson]

On 14-Jan-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> On Wed, 14 Jan 1998, Oliver Hutchison wrote:
> 
> > :- pragma c_code(fug(A::in, B::in) ,"
> > 	do_some_stuff(TypeInfo_for_T1, TypeInfo_for_T2, A, B);
> > ").
> > 
> > I know I like the second alternative.
> 
> The (well, one) trouble with documenting this is that it puts the way type
> infos are handled into the language.  I really don't think it belongs there. 

Well, we'd only have to document how it is done for `pragma c_code';
an implementation would still be free to do things different for
Mercury code.

> I guess the following would be quite horrible to try to implement, but I'd
> really like to write something like this: 
> 
> :- pred fug(T1, T2).
> :- mode fug(in, out) is det.
> 
> :- pragma c_code(fug(A::in, B::in) ,"
> 	do_some_stuff(MR_TYPE_INFO(T1,1), MR_TYPE_INFO(T2,1), A, B);
> ").

That could be implemented very easily:

	#define paste(x,y) x##y
	#define MR_TYPE_INFO(var) paste(TypeInfo_for_,var)

Using a macro like this puts a small layer of abstraction over
the arguably ugly technique of using special variable names.
On the other hand, I'm not sure it really adds much.
It does have the advantage that we could minimize the invasion of the
user's name space for variable names, by using say `MR_TypeInfo_for'
instead of `TypeInfo_for_'.

One potential drawback with this is that MR_TYPE_INFO() could only
be used within the `pragma c_code'; naive users might try to use
it from within C functions called from the pragma c_code.

> (The second argument to MR_TYPE_INFO being the parameter number of the type
> of the first argument, needed for multiparametric types).

I don't understand why this is needed.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.