<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Imagine it is implemented by actual functions and not by the compiler?<BR>
<BR>
Like:<BR>
<BR>
interface AtomicInteger;<BR>
<BR>
<*external AtomicInteger__FetchAdd*> PROCEDURE FetchAdd(...)<BR>
<*external AtomicInteger__CompareAndSwap*> PROCEDURE CompareAndSwap(...)<BR>
<BR>
<BR>
interface AtomicWchar;<BR>
<BR>
<*external AtomicWchar__FetchAdd*> PROCEDURE FetchAdd(...)<BR>
<*external AtomicWchar__CompareAndSwap*> PROCEDURE CompareAndSwap(...)<BR>
<BR>
all by instantiating Atomic.ig.<BR>
<BR>
<*external*> generic interface Atomic;<BR>
<BR>
<BR>
PROCEDURE FetchAdd(...)<BR>
PROCEDURE CompareAndSwap(...)<BR>
<BR>
Actually I just realize the language elements are maybe there.<BR>
There is already a notion of an external interface. But as I understand, in the above,<BR>
every instantiation would have the same external names.<BR>
How about we change generic external interfaces to be "two level"?<BR>
There are situations where the existing behavior would suffice that this would break,<BR>
like if you had a generic that only operated on pointers but instantiated it for<BR>
multiple pointer types, in that case using the same external name for every<BR>
function would be ok.<BR>
I've never seen an external interface until recently when I made some, let<BR>
alone a generic external interface so this probably breaks nothing.<BR>
Even so, we could add syntax to external.<BR>
That is, this is useful for non-generic too.<BR>
<BR>
Interface unix<BR>
<BR>
<*external unix__sleep*> PROCEDURE sleep...<BR>
<*external unix__open*> PROCEDURE open...<BR>
<BR>
vs.<BR>
<BR>
<*external twolevel*> interface unix;<BR>
<BR>
PROCEDURE sleep...<BR>
PROCEDURE open...<BR>
<BR>
Granted, maybe something like:<BR>
<BR>
AtomicImpl.i3<BR>
<BR>
<* external atomic__increment8 *> procedure increment8...<BR>
<* external atomic__increment16 *> procedure increment16...<BR>
<* external atomic__increment32 *> procedure increment32...<BR>
<* external atomic__increment64 *> procedure increment64...<BR>
<BR>
<BR>
const something := array of bitcount = {increment8, increment16, increment32, increment64}<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
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".<BR>
<BR>
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.)<BR>
But often the reusable mechanism is much more difficult to design and implement than some special cases.<BR>
<BR>
<BR>
- Jay<BR> <BR>> From: hosking@cs.purdue.edu<BR>> Date: Thu, 24 Dec 2009 10:35:07 -0500<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] external two level names?<BR>> <BR>> I don't understand the question.<BR>> <BR>> I have a pretty good idea how to implement atomic without that.<BR>> <BR>> On 24 Dec 2009, at 10:17, Jay K wrote:<BR>> <BR>> > Should we have a form of <*external*> that assumes two level<BR>> > names insead of one level names?<BR>> > <BR>> > This would be useful I believe for an initial implementation of Atomic.<BR>> > I don't see how to implement Atomic otherwise, well, other than a lame:<BR>> > <BR>> > Atomic.mg:<BR>> > if BYTESIZE(T) == 4<BR>> > blah<BR>> > elsif BYTESIZE(T) == 8<BR>> > blah<BR>> > <BR>> > which I guess is ok, or a switch.<BR>> > <BR>> > It'd also be very useful in the existing code base.<BR>> > <BR>> > - Jay<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> <BR> </body>
</html>