[M3devel] "target specific pragmas"?

[Mika Nystrom]

Can you just generate the Modula-3 code you want using a Python
script or COBOL or whatever you like instead of trying to foist
preprocessing nastiness on innocent users of high-level Modula-3?

Preprocessing is super nasty.  It's not just a question of human
readability.  m3tk has to be able to read the code, too.  I should
be able to write a program that reads in (using m3tk) an arbitrary
Modula-3 interface and understands it to the point that it can
generate Network Object stubs, inter-language call stubs, etc.  The
stubs should ALSO be human- and m3tk-readable after the transformation!
This should work even if the programmer has been very "clever" in
his use of Modula-3 constructs.  (Just try getting something like
that to work with C or C++... it's hopeless once the preprocessor
gets involved, and possibly before.)

Also if I may make a little request, if at all possible, please try
not to break binary compatibility with gcc-compiled C and Fortran
on NT386GNU (not sure if your ideas about calling conventions could
possibly do that...)

     Mika

Jay writes:
>--_8b04f633-e2a4-411d-940a-739ab79b0616_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>I insist that it depends.
>Putting every platform-specific piece of code in its own file/directory can=
> lead to mass duplication of nearly identical code.
>Sometimes an #if here or there goes very far in /improving/ code maintainab=
>ility.
>A lot of #if here there and everywhere of course can have the opposite effe=
>ct.
>And I realize if you were to drop support for a target, it is easier to fin=
>d/delete files/directories than #ifs, but I don't think that's a good enoug=
>h reason to sway the decision.
>It goes both ways.
>=20
>Yes, you could endeavor factor things down so that everything common is in =
>common, and everything not-common is in platform-specific. But this is inad=
>equate I think. The tail is wagging the dog unnecessarily I think. If my co=
>de very nearly all goes together, don't make me separate it. Also sometimes=
> a different factoring is "encouraged" for other reasons, to match someone =
>else's factoring. Look at the C*.i3 files. They actually can be almost all =
>be nearly the same, yet they are hardly shared at all. I realize you could =
>also do a sort of "forwarding", though I'm not sure that Modula-3 offers al=
>l the right capabilities for this. Type forwarding, sure. But how about pro=
>cedure forwarding? Like nt386\cstdio.i3 fopen =3D common\ccommonstdio.i3 fo=
>pen? And having to duplicate a line per type/procedure is lame anyway, you =
>KIND OF want "module inheritance". However, if you allow preprocessing base=
>d on target, perhaps the need for that goes away.
>=20
>While extern C varargs functions are generally useless in Modula-3, and the=
>refore extern __cdecl is fairly rare, it DOES occur when you write little h=
>elpers in C, such as for errno.
>=20
>A good /heuristic/ might be to change the default in any directory that has=
> no c_source.
>But it is only heuristic.
>=20
>Whatever is done here, some allowance should probably be made for multiple =
>calling conventions in the same file.
>Switching the default to the overwhelming majority and then annotating the =
>minority is reasonable.
>=20
>I still believe that silently ignoring calling conventions on all but NT386=
> is VERY reasonable, and that no other platform from here on out will ever =
>have calling conventions. Esp. not with the same names. When OS/FOO has the=
> FOOAPI calling convention, you can just ignore that one on all but target =
>OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=
>ly something like:
><*EXTERN FOOAPI WINAPI*> fopen();
>FOOAPI for OS/FOO, WINAPI ignored.
>WINAPI for NT386, FOOAPI ignored.
>The One True Calling Convention for all others, calling convention ignored.
>=20
>I really believe this is highly highly unlikely to occur, and it is not a t=
>errible outcome, and this bridge could be crossed in the far off future.
>The functions that are usually in need of calling conventions are usually o=
>nly present on one system.
>Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=
>existant.
>That could be also.
>A change just for ODBC is probably not the best, though it is a very small =
>safe harmless change (I always say that :) )
>=20
>=20
> - Jay
>
>
>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: hosking at cs.purdue.e=
>du> Subject: Re: [M3devel] "target specific pragmas"?> Date: Mon, 11 Feb 20=
>08 21:08:46 -0500> To: darko at darko.org> > Indeed!> > On Feb 11, 2008, at 8:=
>37 PM, Darko wrote:> > > I think it's not a good idea. I think all platform=
> specific code > > should be in a separate file. I'd also like to see an op=
>tion to > > move calling conventions to the makefile rather than in pramas =
>to > > avoid having to duplicate interface files just to have a different >=
> > calling convention for a different platform.> >> > - Darko> >> >> > On 1=
>2/02/2008, at 12:21 PM, Jay wrote:> >> >> So I have NOT thought this throug=
>h.> >>> >> I wonder if "preprocessing" dependent only on "target" is a good=
> > >> idea.> >>> >> Something like either the ability to prefix pragmas wit=
>h a target, > >> or an "iftarget" and "ifnottarget" pragma.> >>> >> Somethi=
>ng like so:> >>> >> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >>> >>> >=
>> <* IF_TARGET NT386 *>> >> <* END_IF_TARGET*>> >> It's a small can of worm=
>s.> >> Where can they be placed? Only at "global" scope? (ie: toplevel in >=
> >> an interface/module).> >>> >> What about IF_OSTYPE?> >> What about expr=
>essions?> >> IF_TARGET NT386 OR NTAMD64> >>> >> IF_TARGET STARTS(NT)> >>> >=
>> etc.> >>> >> I don't really have enough interest here to work through thi=
>s, > >> just sending out the bait...> >>> >> Obviously this was triggered b=
>y 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 g=
>oing 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 programmi=
>ng was common, more > >> people knew more lower level details and playing g=
>ames with > >> calling conventions was something anyone could do. Most othe=
>r > >> current systems are rooted in C programming. Working in C, calling >=
> >> conventions are generally in a hidden layer below what anyone > >> thin=
>ks about. Therefore, the smaller number of capable people > >> working at t=
>hat level have the good sense to only have one calling > >> convention. No =
>more systems will evolve from "small", at least not > >> without having obs=
>erved this history. Therefore, there will no > >> longer be multiple callin=
>g conventions.> >>> >> That is my theory at least.> >>> >> Oh, Windows does=
> also have __thiscall and __clrcall. __thiscall is > >> only x86>=20
>_________________________________________________________________
>Climb to the top of the charts!=A0Play the word scramble challenge with sta=
>r power.
>http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=
>n=
>
>--_8b04f633-e2a4-411d-940a-739ab79b0616_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style>
>.hmmessage P
>{
>margin:0px;
>padding:0px
>}
>body.hmmessage
>{
>FONT-SIZE: 10pt;
>FONT-FAMILY:Tahoma
>}
></style>
></head>
><body class=3D'hmmessage'>I insist that it depends.<BR>
>Putting every platform-specific piece of code in its own file/directory can=
> lead to mass duplication of nearly identical code.<BR>
>Sometimes an #if here or there goes very far in /improving/ code maintainab=
>ility.<BR>
>A lot of #if here there and everywhere of course can have the opposite effe=
>ct.<BR>
>And I realize if you were to drop support for a target, it is easier to fin=
>d/delete files/directories than #ifs, but I don't think that's a good enoug=
>h reason to sway the decision.<BR>
>It goes both ways.<BR>
> <BR>
>Yes, you could endeavor factor things down so that everything common i=
>s in common, and everything not-common is in platform-specific. But this is=
> inadequate I think. The tail is wagging the dog unnecessarily I think. If =
>my code very nearly all goes together, don't make me separate it.&nbsp=
>;Also sometimes a different factoring is "encouraged" for other reasons, to=
> match someone else's factoring. Look at the C*.i3 files. They actually can=
> be almost all be nearly the same, yet they are hardly shared at all. I rea=
>lize you could also do a sort of "forwarding", though I'm not sure that Mod=
>ula-3 offers all the right capabilities for this. Type forwarding, sure. Bu=
>t how about procedure forwarding? Like nt386\cstdio.i3 fopen =3D common\cco=
>mmonstdio.i3 fopen? And having to duplicate a line per type/procedure is la=
>me anyway, you KIND OF want "module inheritance". However, if you allow pre=
>processing based on target, perhaps the need for that goes away.<BR>
> <BR>
>While extern C varargs functions are generally useless in Modula-3, and the=
>refore extern __cdecl is fairly rare, it DOES occur when you write little h=
>elpers in C, such as for errno.<BR>
> <BR>
>A good /heuristic/ might be to change the default in any directory that has=
> no c_source.<BR>
>But it is only heuristic.<BR>
> <BR>
>Whatever is done here, some allowance should probably be made for multiple =
>calling conventions in the same file.<BR>
>Switching the default to the overwhelming majority and then annotating the =
>minority is reasonable.<BR>
> <BR>
>I still believe that silently ignoring calling conventions on all but NT386=
> is VERY reasonable, and that no other platform from here on out will ever =
>have calling conventions. Esp. not with the same names. When OS/FOO has the=
> FOOAPI calling convention, you can just ignore that one on all but target =
>OS/FOO. Just as all but NT386 ignore WINAPI. Yes this COULD possibly get ug=
>ly something like:<BR>
><*EXTERN FOOAPI WINAPI*> fopen();<BR>
>FOOAPI for OS/FOO, WINAPI ignored.<BR>
>WINAPI for NT386, FOOAPI ignored.<BR>
>The One True Calling Convention for all others, calling convention ignored.=
><BR>
> <BR>
>I really believe this is highly highly unlikely to occur, and it is not a t=
>errible outcome, and this bridge could be crossed in the far off future.<BR=
>>
>The functions that are usually in need of calling conventions are usually o=
>nly present on one system.<BR>
>Perhaps ODBC is an extremely rare anomaly and the whole issue is nearly non=
>existant.<BR>
>That could be also.<BR>
>A change just for ODBC is probably not the best, though it is a very small =
>safe harmless change (I always say that :) )<BR>
> <BR>
> <BR>
> - Jay<BR><BR>
>
><HR id=3DstopSpelling>
><BR>
>> CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>> From: hosking at c=
>s.purdue.edu<BR>> Subject: Re: [M3devel] "target specific pragmas"?<BR>&=
>gt; Date: Mon, 11 Feb 2008 21:08:46 -0500<BR>> To: darko at darko.org<BR>&g=
>t; <BR>> Indeed!<BR>> <BR>> On Feb 11, 2008, at 8:37 PM, Darko wro=
>te:<BR>> <BR>> > I think it's not a good idea. I think all platfor=
>m specific code <BR>> > should be in a separate file. I'd also like t=
>o see an option to <BR>> > move calling conventions to the makefile r=
>ather than in pramas to <BR>> > avoid having to duplicate interface f=
>iles just to have a different <BR>> > calling convention for a differ=
>ent platform.<BR>> ><BR>> > - Darko<BR>> ><BR>> ><B=
>R>> > On 12/02/2008, at 12:21 PM, Jay wrote:<BR>> ><BR>> &gt=
>;> So I have NOT thought this through.<BR>> >><BR>> >>=
> I wonder if "preprocessing" dependent only on "target" is a good <BR>> =
>>> idea.<BR>> >><BR>> >> Something like either the =
>ability to prefix pragmas with a target, <BR>> >> or 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 <BR>> >>=
> an interface/module).<BR>> >><BR>> >> What about IF_OSTY=
>PE?<BR>> >> What about expressions?<BR>> >> IF_TARGET NT3=
>86 OR NTAMD64<BR>> >><BR>> >> IF_TARGET STARTS(NT)<BR>&gt=
>; >><BR>> >> etc.<BR>> >><BR>> >> I don't =
>really have enough interest here to work through this, <BR>> >> ju=
>st sending out the bait...<BR>> >><BR>> >> Obviously this=
> was triggered by my happening into the odbc <BR>> >> directory an=
>d bringing up ignoring WINAPI on non-NT386 or <BR>> >> prefixing c=
>alling conventions with a target.<BR>> >><BR>> >> This re=
>minds me of an important point here however -- nobody else <BR>> >&gt=
>; is going to make the mistake of ever having multiple calling <BR>> &gt=
>;> conventions. Therefore the generality of prefixing WINAPI with <BR>&g=
>t; >> NT386: is useless.<BR>> >> Unless Mac68K support is ad=
>ded.<BR>> >><BR>> >> And here is some rationale even. The=
> PC and Mac evolved from <BR>> >> "small" systems, where assembly =
>programming was common, more <BR>> >> people knew more lower level=
> details and playing games with <BR>> >> calling conventions was s=
>omething anyone could do. Most other <BR>> >> current systems are =
>rooted in C programming. Working in C, calling <BR>> >> convention=
>s are generally in a hidden layer below what anyone <BR>> >> think=
>s about. Therefore, the smaller number of capable people <BR>> >> =
>working at that level have the good sense to only have one calling <BR>>=
> >> convention. No more systems will evolve from "small", at least no=
>t <BR>> >> without having observed this history. Therefore, there =
>will no <BR>> >> longer be multiple calling conventions.<BR>> &=
>gt;><BR>> >> That is my theory at least.<BR>> >><BR>&g=
>t; >> Oh, Windows does also have __thiscall and __clrcall. __thiscall=
> is <BR>> >> only x86<BR>> <BR><BR><br /><hr />Climb to the top=
> of the charts!=A0Play the word scramble challenge with star power. <a href=
>=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlin=
>k_jan' target=3D'_new'>Play now!</a></body>
></html>=
>
>--_8b04f633-e2a4-411d-940a-739ab79b0616_--