[M3devel] "target specific pragmas"?

[Tony Hosking]

Hear hear!

On Feb 12, 2008, at 7:56 AM, Mika Nystrom wrote:

>
> 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_--