[M3devel] external two level names?

[Jay K]

Imagine it is implemented by actual functions and not by the compiler?

 

Like:

 

interface AtomicInteger;

 

<*external AtomicInteger__FetchAdd*> PROCEDURE FetchAdd(...)

<*external AtomicInteger__CompareAndSwap*> PROCEDURE CompareAndSwap(...)

 

 

interface AtomicWchar;

 

<*external AtomicWchar__FetchAdd*> PROCEDURE FetchAdd(...)

<*external AtomicWchar__CompareAndSwap*> PROCEDURE CompareAndSwap(...)

 

all by instantiating Atomic.ig.

 

<*external*> generic interface Atomic;

 

 

PROCEDURE FetchAdd(...)

PROCEDURE CompareAndSwap(...)

 

Actually I just realize the language elements are maybe there.

There is already a notion of an external interface. But as I understand, in the above,

every instantiation would have the same external names.

How about we change generic external interfaces to be "two level"?

There are situations where the existing behavior would suffice that this would break,

like if you had a generic that only operated on pointers but instantiated it for

multiple pointer types, in that case using the same external name for every

function would be ok.

I've never seen an external interface until recently when I made some, let

alone a generic external interface so this probably breaks nothing.

Even so, we could add syntax to external.

That is, this is useful for non-generic too.

 

Interface unix

 

<*external unix__sleep*> PROCEDURE sleep...

<*external unix__open*> PROCEDURE open...

 

vs.

 

<*external twolevel*> interface unix;

 

PROCEDURE sleep...

PROCEDURE open...

 

Granted, maybe something like:

 

AtomicImpl.i3

 

<* external atomic__increment8 *> procedure increment8...

<* external atomic__increment16 *> procedure increment16...

<* external atomic__increment32 *> procedure increment32...

<* external atomic__increment64 *> procedure increment64...

 

 

const something := array of bitcount = {increment8, increment16, increment32, increment64}

 

 

then you can maybe index into the array by the type size log 2 and call the function...and really really hope it gets optimized to a direct call.

 

 

But on the other hand...if some versions have special inlining support in the compiler anyway, then you can also just teach the compiler about a size to function name mapping and still have an "external" (non-inlined function) implementation, just with compiler support to map the names. That seems like a reasonable compromise -- "compiler support to map the names".

 

So I'm ok with no new language mechanism, but, of course, there is that philosophy -- build reusable mechanisms, not special cases. (This seems to be a guiding principle of C++ -- instead of special casing memory, all user defined types can have destructors; like the special built in numeric types, user defined types can overload operators and have type conversions, etc.)

But often the reusable mechanism is much more difficult to design and implement than some special cases.

 

 

 - Jay
 
> From: hosking at cs.purdue.edu
> Date: Thu, 24 Dec 2009 10:35:07 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] external two level names?
> 
> I don't understand the question.
> 
> I have a pretty good idea how to implement atomic without that.
> 
> On 24 Dec 2009, at 10:17, Jay K wrote:
> 
> > Should we have a form of <*external*> that assumes two level
> > names insead of one level names?
> > 
> > This would be useful I believe for an initial implementation of Atomic.
> > I don't see how to implement Atomic otherwise, well, other than a lame:
> > 
> > Atomic.mg:
> > if BYTESIZE(T) == 4
> > blah
> > elsif BYTESIZE(T) == 8
> > blah
> > 
> > which I guess is ok, or a switch.
> > 
> > It'd also be very useful in the existing code base.
> > 
> > - Jay
> > 
> > 
> > 
> > 
> > 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091224/3dc91e2c/attachment-0002.html>