[M3devel] "target specific pragmas"?

[Darko]

I actually see some benefit to Jay's postings since they make us  
examine some of the differences between M3 and C and explain the  
benefits. These questions might be asked by any C programmer  
approaching the M3 language. It may be the point that Jay hasn't  
created and serious software in M3 and needs to be informed of the  
benefits. I've seen some good responses along these lines from members  
of the list.

But Randy does have a valid point. M3 is is not just different to C,  
it's the antithesis of C. It's everything C isn't and the language  
designers went to great lengths to make it this way. It's why most of  
us use the language.

I certainly wouldn't like to drive anyone away because they have a  
different point of view, but it may be a good idea to examine problems  
and solutions more closely and offer other solutions that 'why not do  
it like C'.

In the case of printf, it is useful, when debugging especially, and  
I've created some code which takes a list of refany parameters and  
prints them out. It is a bit inefficient since any 'atomic' values  
such as integers need to be allocated but it also prints out all the  
fields of structures and arrays. But it is completely safe. If there  
were a need for a more efficient way to generated formatted strings,  
I'd write something else more efficient but also configurable since  
embedding fixed strings in your code is generally a a bad idea.


On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:

> Jay:
>
> I don't want to be offensive, but quite frankly I'm tired of  
> continually reading your gripes about Modula-3 as a language and  
> your pining for C.
>
> This forum is for those people interested in advancing the state of  
> Modula-3.  We don't care about C/C++/C#/etc in this forum.  Those of  
> us who are M3 zealots for the most part probably would welcome any  
> move to divest CM3 of all underpinnings from the C world.
>
> Have you seriously studied the Modula-3 language and used it to  
> build production software?  I think some of your comments suggest  
> that you are not a true Modula-3 programmer and that you still cling  
> to the C-way of doing things rather than embracing the Modula-3 way.
>
> Now, I do think that most people are interested in improving things  
> and no language is perfect, so any well-thought-out proposal for a  
> change to the language is welcome for consideration,  But in this  
> mail list forum, I for one would appreciate less ranting about C and  
> more constructive Modula-3.
>
> Truly, I do not want to offend you.  Maybe I'm just having a bad  
> day, but I encourage you to try and focus your posts to the  
> advancement of Modula-3.
>
> Regards,
> Randy
>
> >>> Jay <jayk123 at hotmail.com> 2/12/2008 11:28 PM >>>
>  > >My principle concern is that once we provide C APIs then C will
>  > >permeate the M3 space more pervasively (both apps and libraries).
>
> This is somewhat my point.
> When I am debugging, I really miss printf.
>
> The debugging options seem really poor everywhere and esp. on NT386.
>
> gdb has all wierded out variable names for one thing.
> And I think we should fix it so that that the symbols have full  
> source paths.
> I realize they would only be correct on one machine, and hopefully  
> there's a decent story for copying the files.
> Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot.
>
> Other than printf'ing, I also end up getting a stack in cdb with no  
> symbols and then disasm in gdb to find what the functions were. That  
> works fine a few times, but I hope not to do it often. Somewhat  
> lucky I could even get a stack. Because, see, cdb is nice enough to  
> stop on access violations by default (such as the time/date code was  
> causing). gdb has a promising sounding feature, the ability to stop  
> on "signals", which I think an access violation would count as, oh,  
> but that feature isn't implemented, sorry. Ok, true, think about it  
> more and I can break on the toplevel exception handler in  
> cygwin1.dll, not sure that always works or not, it's an  
> implementation detail, but heck, when you are debugging, take  
> advantage of whatever you have. :)
>
> RTIO, is too verbose for me.
> But darnit, I can't really have printf..puts is about the best I  
> could do..
> Oh, but no, since TEXT != char* even that isn't useful.
> fread/fwrite maybe though.
>
> On a different hand (how many are there? :) ), have you looked in  
> m3core\src\unix?
> There is just tons of dead stuff, stuff with comments about it  
> perhaps being wrong, "use with care".
> It seemed to me maybe the point was to expose "all" of /usr/include.
> Someone, other than me, sure seems to have gone overboard, like  
> someone using Ultrix and Linux 1.x, and then it copied around.
> Heck, look at the mem* functions being commented out (and probably  
> using the incorrect type int) because Ultrix or somesuch didn't have  
> them. I uncommented them to fix a build. And notice that these  
> functions, again, like most of printf, are /extremely/ portable in  
> functionality and exact binary interface (yeah yeah, I've heard of  
> bcopy and bzero).
>
> What there was of Cstdio.i3 seemed very possibly wrong, at least on  
> many targets, and very doubtfully useful for anything, and I think  
> I've now shown unused.
>
>  > 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
>
> But wrapping everything in Modula-3 is so tedious...
> Oh for all languages to just understand C headers so we can stop  
> rewriting them...
> Or some other language, ok...not going to be solved in this forum.
> To go the unpopular route (again), MS CLR/.NET among many other  
> things, attempts to solve this very problem.
> One way to describe "interfaces" that "all" languages can  
> understand...at least for some subset of languages features..
>
> Just as tedious btw, it is often more portable to wrap all the C  
> APIs in C, exposing a portable controled Modula-3 interface  
> independent of the precise header content. Like errno and my  
> get_stderr/out/in.
>
>  - Jay
>
>
> > To: hosking at cs.purdue.edu
> > Date: Tue, 12 Feb 2008 16:37:43 -0800
> > From: mika at async.caltech.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] "target specific pragmas"?
> >
> >
> > 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>
>
>
> Connect and share in new ways with Windows Live. Get it now!