[M3devel] "target specific pragmas"?

[Mika Nystrom]

This is also an excellent reason not to permit "interfaces" to C
code inlined into MODULEs.

Interfaces are the contract that the implementation has to live up
to.  Ok, so it happens that under operating system X on architecture
Y, the easiest way to implement the interface is to call a C function
that "just happens" to have the correct interface.  But on another
system, which either isn't built in C or where the function doesn't
exist, it might be convenient to implement the interface in (gasp!)
Modula-3!

(I use this pattern as follows: on systems where Intel's Fortran
compiler is available, compile from assembly (which was generated
by ifort).  On other systems, the code is implemented in Modula-3.)

     Mika

Tony Hosking writes:
>My principle concern is that once we provide C APIs then C will  
>permeate the M3 space more pervasively (both apps and libraries).   
>What happens when I want to bring up a system where there is no  
>C?!?!  Consider the SPIN OS perhaps...
>
>Maybe I am just being overly fusty...
>
>On Feb 12, 2008, at 4:35 PM, Dragiša Durić wrote:
>
>> What we _maybe_ can do... is to make some special, preprocessable  
>> source
>> form, which some quake command can parse into multiple files in their
>> folders. And these file can be compiled later...Kind of how generic
>> works.
>>
>> But, as current system works, and it does it very well, and as only  
>> case
>> where we really need this is Windows... most Unices being or becoming
>> POSIX... I don't see it's smart to spend resources on becoming more  
>> C...
>> Esp when "founding fathers" made it so good and so much non-C :).
>>
>> If we really need to make some approach to "their world", it's much
>> better to work on interoperability issues and thus cement our
>> first-class-citizen language status even more.
>>
>> dd
>>
>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:
>>> Jay:
>>>
>>> My understanding of Modula-3 is that rather than cluttering up the
>>> source code with a bunch of preprocessor directives to deal with the
>>> various changes needed by various platforms, a separate source  
>>> file is
>>> used for platforms whose implementation must diverge.  The m3makefile
>>> is used to control the selection of these platform sources at build
>>> time.  I like this approach much better.
>>>
>>> Regards,
>>> Randy
>>>
>>>>>> Jay <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>
>>> So I have NOT thought this through.
>>>
>>> I wonder if "preprocessing" dependent only on "target" is a good  
>>> idea.
>>>
>>> Something like either the ability to prefix pragmas with a target, or
>>> an "iftarget" and "ifnottarget" pragma.
>>>
>>> Something like so:
>>>
>>> <* IF_TARGET NT386 *>
>>> <* END_IF_TARGET*>
>>>
>>>
>>> <* IF_TARGET NT386 *>
>>> <* END_IF_TARGET*>
>>> It's a small can of worms.
>>> Where can they be placed? Only at "global" scope? (ie: toplevel in an
>>> interface/module).
>>>
>>> What about IF_OSTYPE?
>>> What about expressions?
>>> IF_TARGET NT386 OR NTAMD64
>>>
>>> IF_TARGET STARTS(NT)
>>>
>>> etc.
>>>
>>> I don't really have enough interest here to work through this, just
>>> sending out the bait...
>>>
>>> Obviously this was triggered by my happening into the odbc directory
>>> and bringing up ignoring WINAPI on non-NT386 or prefixing calling
>>> conventions with a target.
>>>
>>> This reminds me of an important point here however -- nobody else is
>>> going to make the mistake of ever having multiple calling  
>>> conventions.
>>> Therefore the generality of prefixing WINAPI with NT386: is useless.
>>> Unless Mac68K support is added.
>>>
>>> And here is some rationale even. The PC and Mac evolved from "small"
>>> systems, where assembly programming was common, more people knew more
>>> lower level details and playing games with calling conventions was
>>> something anyone could do. Most other current systems are rooted in C
>>> programming. Working in C, calling conventions are generally in a
>>> hidden layer below what anyone thinks about. Therefore, the smaller
>>> number of capable people working at that level have the good sense to
>>> only have one calling convention. No more systems will evolve from
>>> "small", at least not without having observed this history.  
>>> Therefore,
>>> there will no longer be multiple calling conventions.
>>>
>>> That is my theory at least.
>>>
>>> Oh, Windows does also have __thiscall and __clrcall. __thiscall is
>>> only x86
>> -- 
>> Dragiša Durić <dragisha at m3w.org>