[M3devel] "target specific pragmas"?

[Tony Hosking]

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>