<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I'm still left wondering -- these other language tools -- you run them over the pkg store's shipped implementation files, right? Or at least check the BUILD_DIR for derived *3 files?<BR>
Or do the tools, like, ignore missing implementations or other "small" problems?<BR>
If the "forwarding" shown works, that goes very far in solving this problem without stepping on other language tools (again though, depending somewhat on the first question -- except, I just remembered -- a lot of these tools only need the *.i3 files and not the *.m3 files?)<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Subject: Re: [M3devel] "target specific pragmas"?<BR>> From: dragisha@m3w.org<BR>> To: rcoleburn@scires.com<BR>> CC: m3devel@elegosoft.com; jayk123@hotmail.com<BR>> Date: Tue, 12 Feb 2008 22:35:12 +0100<BR>> <BR>> What we _maybe_ can do... is to make some special, preprocessable source<BR>> form, which some quake command can parse into multiple files in their<BR>> folders. And these file can be compiled later...Kind of how generic<BR>> works. <BR>> <BR>> But, as current system works, and it does it very well, and as only case<BR>> where we really need this is Windows... most Unices being or becoming<BR>> POSIX... I don't see it's smart to spend resources on becoming more C...<BR>> Esp when "founding fathers" made it so good and so much non-C :).<BR>> <BR>> If we really need to make some approach to "their world", it's much<BR>> better to work on interoperability issues and thus cement our<BR>> first-class-citizen language status even more.<BR>> <BR>> dd<BR>> <BR>> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:<BR>> > Jay:<BR>> > <BR>> > My understanding of Modula-3 is that rather than cluttering up the<BR>> > source code with a bunch of preprocessor directives to deal with the<BR>> > various changes needed by various platforms, a separate source file is<BR>> > used for platforms whose implementation must diverge. The m3makefile<BR>> > is used to control the selection of these platform sources at build<BR>> > time. I like this approach much better.<BR>> > <BR>> > Regards,<BR>> > Randy<BR>> > <BR>> > >>> Jay <jayk123@hotmail.com> 2/11/2008 8:21 PM >>><BR>> > So I have NOT thought this through.<BR>> > <BR>> > I wonder if "preprocessing" dependent only on "target" is a good idea.<BR>> > <BR>> > Something like either the ability to prefix pragmas with a target, or<BR>> > an "iftarget" and "ifnottarget" pragma.<BR>> > <BR>> > Something like so:<BR>> > <BR>> > <* IF_TARGET NT386 *><BR>> > <* END_IF_TARGET*><BR>> > <BR>> > <BR>> > <* IF_TARGET NT386 *><BR>> > <* END_IF_TARGET*><BR>> > It's a small can of worms.<BR>> > Where can they be placed? Only at "global" scope? (ie: toplevel in an<BR>> > interface/module).<BR>> > <BR>> > What about IF_OSTYPE?<BR>> > What about expressions?<BR>> > IF_TARGET NT386 OR NTAMD64<BR>> > <BR>> > IF_TARGET STARTS(NT)<BR>> > <BR>> > etc.<BR>> > <BR>> > I don't really have enough interest here to work through this, just<BR>> > sending out the bait...<BR>> > <BR>> > Obviously this was triggered by my happening into the odbc directory<BR>> > and bringing up ignoring WINAPI on non-NT386 or prefixing calling<BR>> > conventions with a target.<BR>> > <BR>> > This reminds me of an important point here however -- nobody else is<BR>> > going to make the mistake of ever having multiple calling conventions.<BR>> > Therefore the generality of prefixing WINAPI with NT386: is useless.<BR>> > Unless Mac68K support is added.<BR>> > <BR>> > And here is some rationale even. The PC and Mac evolved from "small"<BR>> > systems, where assembly programming was common, more people knew more<BR>> > lower level details and playing games with calling conventions was<BR>> > something anyone could do. Most other current systems are rooted in C<BR>> > programming. Working in C, calling conventions are generally in a<BR>> > hidden layer below what anyone thinks about. Therefore, the smaller<BR>> > number of capable people working at that level have the good sense to<BR>> > only have one calling convention. No more systems will evolve from<BR>> > "small", at least not without having observed this history. Therefore,<BR>> > there will no longer be multiple calling conventions.<BR>> > <BR>> > That is my theory at least.<BR>> > <BR>> > Oh, Windows does also have __thiscall and __clrcall. __thiscall is<BR>> > only x86<BR>> -- <BR>> Dragiša Durić <dragisha@m3w.org><BR>> <BR><BR><br /><hr />Climb to the top of the charts! Play the word scramble challenge with star power. <a href='http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan' target='_new'>Play now!</a></body>
</html>