[M3devel] "target specific pragmas"?

[Jay]

too much to respond to right now...
 
Yes C++ certainly allows virtual functions on stack allocated objects.
class Foo{public:  virtual void Bar();};
void F(){  Foo foo;
  foo.Bar();}
 works fine. You can take the address and pass it around, etc., just don't return it of course.
You are right that a record with procedures might suffice.I've been using them in C lately:
struct Foo_t;typedef struct Foo_t Foo_t;struct FooFunctions_t;typedef struct FooFunctions_t FooFunctions_t;
struct FooFunctions_t{    // probably never any data here, it muddies the model, but maybe     void (*DoSomething)(Foo_t*);    void (*OrSomethingElse)(Foo_t*, size_t a, size_t b);};
struct Foo_t{   // probably never any data here, it muddies the model, but maybe    const FooFunctions_t* Functions;};
// see winnt.h for exactly correct definition#define CONTAINING_RECORD(basepointer, derivedtype, basefield)   ((derivedtype*) ((char*)basepointer) - (offsetof(derivedtype, basefield))))
struct Bar_t{    size_t BarData...;    Foo_t Base;};
void Bar_DoSomething(Foo_t* Foo){   Bar* = CONTAINING_RECORD(Foo, Bar_t, Base)
   do something with Bar->BarData...}
void Bar_OrSomethingElse(...) ...
const FooFunctions ={   &Bar_DoSomething,   &Bar_OrSomethingElse};
Foo_t* Bar_Create(){  Bar_t* Bar = (Bar_t*) calloc(1, sizeof(*Bar));
  if (Bar == NULL) ....  Bar->Functions = &FooFunctions;   return &Bar->Base; }
 Foo_t* f = Bar_Create();  f->Functions->DoSomething(f); 
 // ouch a double pointer deref, maybe code will cache the functions though  
 
 CONTAINING_RECORD isn't really needed here -- Base can be at the start -- but  this slightly generalized pattern supports more types of inheritance better. 
 Presumably I can just clone this in about as much Modula-3.  I'll have to try it out
   when I find an excuse for having "COM-like" interfaces.  "I can have my C and a good module system too." :)
 It is a little tedious, but it keeps you off the slippery slope of C++. :)
  C++ has few stupid limits I can think of.    One is that types (or constants) with internal linkage can't be template parameters.  
  void F()    {       struct point { int a,b; };       std::vector<point> points; // error  
     special_debugging_class<"print me"> abc; // error    }
  Maybe the last is fixed though.    And they are both widely acknowledged to be dumb. Though I think they have   an obvious rationale. (You all can guess?) 
 True I haven't written much Modula-3.  I do look around the tree some and I do see a lot gross duplication of code/effort. 
  Yes Modula-3 enums and sets and their interaction with arrays is nice.  
   It was actually cryptically terse to me at first but I figured it out.   Optional bounds checking on arrays, good.  
  C++ gives you what you generally need to implement sets and good arrays.    C is soso. You know, the main thing you have to give up in C regarding    user defined types is using those special operator characters on them.    You must make explicit function calls.  
 
There is this real tension between building stuff into a language vs. building in
  enough facilities for people to put in libraries what they "thought" should be in the language.
 
Same thing even goes for libraries themselves. Do you put more functionality "in" them, or
provide the right composable pieces for people to build what they want.
  Exceptions (which nobody mentioned) are a mixed bag btw. It's not that hard really to get C correct,
  esp. with macros and goto (seriously!) but also not clearly worth it. Optional garbage collection maybe nice,  again not so hard in C, and C++ gives you, in a sense, garbage collection  and much much more along these lines via "RIAA".
  Also true that lots of languages don't compile to native code.    The CLR does promise to be the last system to need this (at runtime or install time) and everyone else    can target it. Java (VM) is similar but not general purpose enough.  
  True that name mangling is kind of lame. Try searching for the functions, or debugging (how do I specify the name to a command line debugger? It isn't necessarily impossible, but it's another varying complexity.)
    Also, on the "American Idol" point, true, good point, being right and good   is better than being popular, but there are network affects and some of them are   desirable. It's true you don't want everyone jumping on your bandwagon, you want   to keep some folks out, but having other people writing tools (editors, etc.)   that you can use CAN be very nice.    
   True again I'm a lazy typist but a frequent reader. But begin/end are no more     readable than braces. It seems arbitrary, except for the network affects that     make my editor favor braces.  
 
 ..Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "target specific pragmas"? > Date: Wed, 13 Feb 2008 18:00:46 -0800> From: mika at async.caltech.edu> > > I should point out that I am not trying to tell you that Modula-3> is better than C++ and you should immediately switch and stop talking> about the wonderful features of C++. It's not and if you are> competent enough to be coding in C++ and happy with it you should> certainly not.> > A way to summarize what I said before is this. I do not consider> myself a good programmer. Yet I sit in front of my computer trying> to write software that plays with millions of dollars of other> people's money. I simply do not trust myself to use a tool as sharp> and unconstrained as C++. The constraints of enumerated types,> subranges, typechecking at interfaces and runtime, bounds-checked> arrays etc., let me sleep a bit better (but still not well).> > I am reminded of something my advisor's advisor once wrote, regarding> the difficulty of producing large software systems:> > We shall do a much better programming job, provided that we> approach the task with a full appreciation of its tremendous> difficulty, provided that we stick to modest and elegant programming> languages, provided that we respect the intrinsic limitations> of the human mind and approach the task as Very Humble Programmers.> > ( http://www.cs.utexas.edu/~EWD/ewd03xx/EWD340.PDF > CACM 15, 1972, #10, 859-866)> > Mika> > > > > > > Jay writes:> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >I'll try to repeat myself less and ramble less, and stay constructive...> >=20> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).> >=20> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.> >Bad module system -- #include.> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.> >Beyond this, at the moment, I am unsure.> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.> >=20> >If you start over completely from scratch, you should still look at what is=> > out there.> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.> >=20> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.> >=20> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.> >=20> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.> > And maybe the docs aren't good here.> >And VAR/BEGIN.> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)> >=20> >I guess I should be in comp.lang.c.advocacy. :)> >=20> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.> >(and of course, don't mess up their code)> >=20> > - Jay> >> >> >> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com> From: darko at darko.org> To=> >: rcoleburn at scires.com> Subject: Re: [M3devel] "target specific pragmas"?> => >Date: Thu, 14 Feb 2008 11:10:18 +1100> > 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 > b=> >enefits. 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 beca=> >use they have a > different point of view, but it may be a good idea to exa=> >mine 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 debug=> >ging 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 > embedd=> >ing fixed strings in your code is generally a a bad idea.> > > On 14/02/200=> >8, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be off=> >ensive, 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 zealot=> >s for the most part probably would welcome any > > move to divest CM3 of al=> >l underpinnings from the C world.> >> > Have you seriously studied the Modu=> >la-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 p=> >roposal 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 fo=> >cus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy>=> > >> > >>> Jay <jayk123 at hotmail.com> 2/12/2008 11:28 PM >>>> > > >My princip=> >le concern is that once we provide C APIs then C will> > > >permeate the M3=> > space more pervasively (both apps and libraries).> >> > This is somewhat m=> >y point.> > When I am debugging, I really miss printf.> >> > The debugging => >options seem really poor everywhere and esp. on NT386.> >> > gdb has all wi=> >erded 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 o=> >nly 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 .g=> >dbinit or whatnot.> >> > Other than printf'ing, I also end up getting a sta=> >ck in cdb with no > > symbols and then disasm in gdb to find what the funct=> >ions 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 enou=> >gh 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 > > m=> >ore and I can break on the toplevel exception handler in > > cygwin1.dll, n=> >ot sure that always works or not, it's an > > implementation detail, but he=> >ck, 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 !=3D char=> >* even that isn't useful.> > fread/fwrite maybe though.> >> > On a differen=> >t hand (how many are there? :) ), have you looked in > > m3core\src\unix?> => >> There is just tons of dead stuff, stuff with comments about it > > perhap=> >s being wrong, "use with care".> > It seemed to me maybe the point was to e=> >xpose "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 co=> >pied around.> > Heck, look at the mem* functions being commented out (and p=> >robably > > 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 > > fu=> >nctionality and exact binary interface (yeah yeah, I've heard of > > bcopy => >and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, a=> >t least on > > many targets, and very doubtfully useful for anything, and I=> > think > > I've now shown unused.> >> > > Y, the easiest way to implement t=> >he interface is to call a C > > function> > > that "just happens" to have t=> >he correct interface. But on another> >> > But wrapping everything in Modul=> >a-3 is so tedious...> > Oh for all languages to just understand C headers s=> >o we can stop > > rewriting them...> > Or some other language, ok...not goi=> >ng 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 port=> >able controled Modula-3 interface > > independent of the precise header con=> >tent. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: h=> >osking 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: [M3=> >devel] "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> > > e=> >xist, it might be convenient to implement the interface in (gasp!)> > > Mod=> >ula-3!> > >> > > (I use this pattern as follows: on systems where Intel's F=> >ortran> > > compiler is available, compile from assembly (which was generat=> >ed> > > 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 p=> >ervasively (both apps and libraries).> > > >What happens when I want to bri=> >ng 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=C5=A1a Duri=C4? wrote:> > > >> > > >> What we _ma=> >ybe_ can do... is to make some special, preprocessable> > > >> source> > > => >>> form, which some quake command can parse into multiple files in > > thei=> >r> > > >> folders. And these file can be compiled later...Kind of how > > g=> >eneric> > > >> works.> > > >>> > > >> But, as current system works, and it => >does it very well, and as > > only> > > >> case> > > >> where we really nee=> >d this is Windows... most Unices being or > > becoming> > > >> POSIX... I d=> >on'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 rath=> >er than cluttering up > > the> > > >>> source code with a bunch of preproce=> >ssor directives to deal > > with the> > > >>> various changes needed by var=> >ious platforms, a separate source> > > >>> file is> > > >>> used for platfo=> >rms whose implementation must diverge. The > > m3makefile> > > >>> is used => >to control the selection of these platform sources at > > build> > > >>> ti=> >me. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> R=> >andy> > > >>>> > > >>>>>> 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 > > ta=> >rget, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>>=> > Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END=> >_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* E=> >ND_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they => >be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interfa=> >ce/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about exp=> >ressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET S=> >TARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enou=> >gh interest here to work through this, > > just> > > >>> sending out the ba=> >it...> > > >>>> > > >>> Obviously this was triggered by my happening into t=> >he 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 > > "s=> >mall"> > > >>> systems, where assembly programming was common, more people => >> > knew more> > > >>> lower level details and playing games with calling c=> >onventions > > was> > > >>> something anyone could do. Most other current s=> >ystems are > > rooted in C> > > >>> programming. Working in C, calling conv=> >entions are generally > > in a> > > >>> hidden layer below what anyone thin=> >ks about. Therefore, the > > smaller> > > >>> number of capable people work=> >ing at that level have the good > > sense to> > > >>> only have one calling=> > convention. No more systems will evolve > > from> > > >>> "small", at leas=> >t not without having observed this history.> > > >>> Therefore,> > > >>> th=> >ere will no longer be multiple calling conventions.> > > >>>> > > >>> That => >is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thisc=> >all and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> D=> >ragi=C5=A1a Duri=C4? <dragisha at m3w.org>> >> >> > Connect and share in new w=> >ays with Windows Live. Get it now!>=20> >_________________________________________________________________> >Shed those extra pounds with MSN and The Biggest Loser!> >http://biggestloser.msn.com/=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_> >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'll <EM>try </EM>to repeat myself less and rambl=> >e less, and stay constructive...<BR>> > <BR>> >I understand that printf type unsafety stinks and I have been bitten by it,=> > but it is nicely terse, crude but effective, I'm going to throw away the c=> >ode probably once the bug is fixed. (Ok, I like to comment out or somehow d=> >isable sometimes maybe but that is a different point, it's still not the he=> >ight of production code; and yes, I realize it's a slippery slope and the n=> >ext thing I'll do is use it in production code; debugging is just what I'm => >doing now, next up, real code).<BR>> > <BR>> >You can't just be the antithesis of C. You have to decide what it is about => >C that is wrong and fix it or do it over.<BR>> >And then of course, agreement on what is wrong. I probably see less wrong t=> >han you.<BR>> >Bad module system -- #include.<BR>> >Bad module system -- preprocesor which kills or damages other efforts at la=> >nguage-aware tools.<BR>> >Beyond this, at the moment, I am unsure.<BR>> >I have "argued for" C++ for further "problems" in C, but I have "grown" (or=> > shrunk? :) ) to appreciate that C might not be as bad as I used to think.<=> >BR>> > <BR>> >If you start over completely from scratch, you should still look at what is=> > out there.<BR>> >Granted, some things are mostly arbitrary. Braces vs. begin/end. But the ed=> >itors all support braces now.<BR>> >Until you get me to change editors (probably never), Modula-3 is always goi=> >ng to be less convenient.<BR>> >At this point you are just fighting the vast majority (except Python...). I=> >t could have gone differently, but C won.<BR>> > <BR>> >If you ignore that lowest level thing, there are places where Modula-3 is p=> >erfectly good, but doesn't take the next step.<BR>> >A good example I think here is it has nice "objects", however it requires t=> >hey be heap allocated I think even in unsafe code. You should be able stack=> > (or global) allocate something with "virtual functions". It seems an arbit=> >rary limitation. I realize in safe code, you have to heap allocate more any=> >way, but that is a different point I think.<BR>> > <BR>> >Similarly is "multiple inheritance just of interfaces". I realize though..t=> >his hides a "vtable per interface". Maybe is much more expensive than peopl=> >e realize and shouldn't be provided lightly.<BR>> > <BR>> >SUBARRAY is probably example where I don't/didn't know the language well en=> >ough.<BR>> >  And maybe the docs aren't good here.<BR>> >And VAR/BEGIN.<BR>> >Maybe I just need to reread Nelson's book. You know..reference vs. tutorial=> >. The language reference is very very terse and that is ok. Short on exampl=> >es. A tutorial that gives many examples might be good. Hey maybe I'm just t=> >he newbie in a good position to write it. (not)<BR>> > <BR>> >I guess I should be in comp.lang.c.advocacy. :)<BR>> > <BR>> >To a large extent I'm just looking for a small smart group to have a friend=> >ly intellectual discussion with.<BR>> >(and of course, don't mess up their code)<BR>> > <BR>> > - Jay<BR><BR><BR>> >> ><HR id=3DstopSpelling>> ><BR>> >> CC: jayk123 at hotmail.com; m3devel at elegosoft.com<BR>> From: darko at dar=> >ko.org<BR>> To: rcoleburn at scires.com<BR>> Subject: Re: [M3devel] "tar=> >get specific pragmas"?<BR>> Date: Thu, 14 Feb 2008 11:10:18 +1100<BR>&gt=> >; <BR>> I actually see some benefit to Jay's postings since they make us=> > <BR>> examine some of the differences between M3 and C and explain the => ><BR>> benefits. These questions might be asked by any C programmer <BR>&=> >gt; approaching the M3 language. It may be the point that Jay hasn't <BR>&g=> >t; created and serious software in M3 and needs to be informed of the <BR>&=> >gt; benefits. I've seen some good responses along these lines from members => ><BR>> of the list.<BR>> <BR>> But Randy does have a valid point. M=> >3 is is not just different to C, <BR>> it's the antithesis of C. It's ev=> >erything C isn't and the language <BR>> designers went to great lengths => >to make it this way. It's why most of <BR>> us use the language.<BR>>=> > <BR>> I certainly wouldn't like to drive anyone away because they have => >a <BR>> different point of view, but it may be a good idea to examine pr=> >oblems <BR>> and solutions more closely and offer other solutions that '=> >why not do <BR>> it like C'.<BR>> <BR>> In the case of printf, it => >is useful, when debugging especially, and <BR>> I've created some code w=> >hich takes a list of refany parameters and <BR>> prints them out. It is => >a bit inefficient since any 'atomic' values <BR>> such as integers need => >to be allocated but it also prints out all the <BR>> fields of structure=> >s and arrays. But it is completely safe. If there <BR>> were a need for => >a more efficient way to generated formatted strings, <BR>> I'd write som=> >ething else more efficient but also configurable since <BR>> embedding f=> >ixed strings in your code is generally a a bad idea.<BR>> <BR>> <BR>&=> >gt; On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:<BR>> <BR>> > => >Jay:<BR>> ><BR>> > I don't want to be offensive, but quite fran=> >kly I'm tired of <BR>> > continually reading your gripes about Modula=> >-3 as a language and <BR>> > your pining for C.<BR>> ><BR>> => >> This forum is for those people interested in advancing the state of <B=> >R>> > Modula-3. We don't care about C/C++/C#/etc in this forum. Those=> > of <BR>> > us who are M3 zealots for the most part probably would we=> >lcome any <BR>> > move to divest CM3 of all underpinnings from the C => >world.<BR>> ><BR>> > Have you seriously studied the Modula-3 la=> >nguage and used it to <BR>> > build production software? I think some=> > of your comments suggest <BR>> > that you are not a true Modula-3 pr=> >ogrammer and that you still cling <BR>> > to the C-way of doing thing=> >s rather than embracing the Modula-3 way.<BR>> ><BR>> > Now, I => >do think that most people are interested in improving things <BR>> > => >and no language is perfect, so any well-thought-out proposal for a <BR>>=> > > change to the language is welcome for consideration, But in this <BR>=> >> > mail list forum, I for one would appreciate less ranting about C => >and <BR>> > more constructive Modula-3.<BR>> ><BR>> > Tru=> >ly, I do not want to offend you. Maybe I'm just having a bad <BR>> > => >day, but I encourage you to try and focus your posts to the <BR>> > a=> >dvancement of Modula-3.<BR>> ><BR>> > Regards,<BR>> > Ran=> >dy<BR>> ><BR>> > >>> Jay <jayk123 at hotmail.com> 2=> >/12/2008 11:28 PM >>><BR>> > > >My principle concern i=> >s that once we provide C APIs then C will<BR>> > > >permeate th=> >e M3 space more pervasively (both apps and libraries).<BR>> ><BR>>=> > > This is somewhat my point.<BR>> > When I am debugging, I really=> > miss printf.<BR>> ><BR>> > The debugging options seem really p=> >oor everywhere and esp. on NT386.<BR>> ><BR>> > gdb has all wie=> >rded out variable names for one thing.<BR>> > And I think we should f=> >ix it so that that the symbols have full <BR>> > source paths.<BR>&gt=> >; > I realize they would only be correct on one machine, and hopefully <=> >BR>> > there's a decent story for copying the files.<BR>> > Yea=> >h, I know about "dir" but haven't yet formed a .gdbinit or whatnot.<BR>>=> > ><BR>> > Other than printf'ing, I also end up getting a stack in => >cdb with no <BR>> > symbols and then disasm in gdb to find what the f=> >unctions were. That <BR>> > works fine a few times, but I hope not to=> > do it often. Somewhat <BR>> > lucky I could even get a stack. Becaus=> >e, see, cdb is nice enough to <BR>> > stop on access violations by de=> >fault (such as the time/date code was <BR>> > causing). gdb has a pro=> >mising sounding feature, the ability to stop <BR>> > on "signals", wh=> >ich I think an access violation would count as, oh, <BR>> > but that => >feature isn't implemented, sorry. Ok, true, think about it <BR>> > mo=> >re and I can break on the toplevel exception handler in <BR>> > cygwi=> >n1.dll, not sure that always works or not, it's an <BR>> > implementa=> >tion detail, but heck, when you are debugging, take <BR>> > advantage=> > of whatever you have. :)<BR>> ><BR>> > RTIO, is too verbose fo=> >r me.<BR>> > But darnit, I can't really have printf..puts is about th=> >e best I <BR>> > could do..<BR>> > Oh, but no, since TEXT !=3D => >char* even that isn't useful.<BR>> > fread/fwrite maybe though.<BR>&g=> >t; ><BR>> > On a different hand (how many are there? :) ), have yo=> >u looked in <BR>> > m3core\src\unix?<BR>> > There is just tons => >of dead stuff, stuff with comments about it <BR>> > perhaps being wro=> >ng, "use with care".<BR>> > It seemed to me maybe the point was to ex=> >pose "all" of /usr/include.<BR>> > Someone, other than me, sure seems=> > to have gone overboard, like <BR>> > someone using Ultrix and Linux => >1.x, and then it copied around.<BR>> > Heck, look at the mem* functio=> >ns being commented out (and probably <BR>> > using the incorrect type=> > int) because Ultrix or somesuch didn't have <BR>> > them. I uncommen=> >ted them to fix a build. And notice that these <BR>> > functions, aga=> >in, like most of printf, are /extremely/ portable in <BR>> > function=> >ality and exact binary interface (yeah yeah, I've heard of <BR>> > bc=> >opy and bzero).<BR>> ><BR>> > What there was of Cstdio.i3 seeme=> >d very possibly wrong, at least on <BR>> > many targets, and very dou=> >btfully useful for anything, and I think <BR>> > I've now shown unuse=> >d.<BR>> ><BR>> > > Y, the easiest way to implement the inter=> >face is to call a C <BR>> > function<BR>> > > that "just hap=> >pens" to have the correct interface. But on another<BR>> ><BR>> &g=> >t; But wrapping everything in Modula-3 is so tedious...<BR>> > Oh for=> > all languages to just understand C headers so we can stop <BR>> > re=> >writing them...<BR>> > Or some other language, ok...not going to be s=> >olved in this forum.<BR>> > To go the unpopular route (again), MS CLR=> >/.NET among many other <BR>> > things, attempts to solve this very pr=> >oblem.<BR>> > One way to describe "interfaces" that "all" languages c=> >an <BR>> > understand...at least for some subset of languages feature=> >s..<BR>> ><BR>> > Just as tedious btw, it is often more portabl=> >e to wrap all the C <BR>> > APIs in C, exposing a portable controled => >Modula-3 interface <BR>> > independent of the precise header content.=> > Like errno and my <BR>> > get_stderr/out/in.<BR>> ><BR>> &g=> >t; - Jay<BR>> ><BR>> ><BR>> > > To: hosking at cs.purdue.=> >edu<BR>> > > Date: Tue, 12 Feb 2008 16:37:43 -0800<BR>> > &g=> >t; From: mika at async.caltech.edu<BR>> > > CC: m3devel at elegosoft.com=> ><BR>> > > Subject: Re: [M3devel] "target specific pragmas"?<BR>&gt=> >; > ><BR>> > ><BR>> > > This is also an excellent r=> >eason not to permit "interfaces" to C<BR>> > > code inlined into M=> >ODULEs.<BR>> > ><BR>> > > Interfaces are the contract tha=> >t the implementation has to live up<BR>> > > to. Ok, so it happens=> > that under operating system X on architecture<BR>> > > Y, the eas=> >iest way to implement the interface is to call a C <BR>> > function<B=> >R>> > > that "just happens" to have the correct interface. But on => >another<BR>> > > system, which either isn't built in C or where th=> >e function doesn't<BR>> > > exist, it might be convenient to imple=> >ment the interface in (gasp!)<BR>> > > Modula-3!<BR>> > >=> ><BR>> > > (I use this pattern as follows: on systems where Intel's=> > Fortran<BR>> > > compiler is available, compile from assembly (wh=> >ich was generated<BR>> > > by ifort). On other systems, the code i=> >s implemented in Modula-3.)<BR>> > ><BR>> > > Mika<BR>&gt=> >; > ><BR>> > > Tony Hosking writes:<BR>> > > >My=> > principle concern is that once we provide C APIs then C will<BR>> > => >> >permeate the M3 space more pervasively (both apps and libraries).<=> >BR>> > > >What happens when I want to bring up a system where t=> >here is no<BR>> > > >C?!?! Consider the SPIN OS perhaps...<BR>&=> >gt; > > ><BR>> > > >Maybe I am just being overly fusty=> >...<BR>> > > ><BR>> > > >On Feb 12, 2008, at 4:35 P=> >M, Dragi=C5=A1a Duri=C4? wrote:<BR>> > > ><BR>> > > &g=> >t;> What we _maybe_ can do... is to make some special, preprocessable<BR=> >>> > > >> source<BR>> > > >> form, which some=> > quake command can parse into multiple files in <BR>> > their<BR>>=> > > > >> folders. And these file can be compiled later...Kind of=> > how <BR>> > generic<BR>> > > >> works.<BR>> > &=> >gt; >><BR>> > > >> But, as current system works, and i=> >t does it very well, and as <BR>> > only<BR>> > > >> c=> >ase<BR>> > > >> where we really need this is Windows... most=> > Unices being or <BR>> > becoming<BR>> > > >> POSIX...=> > I don't see it's smart to spend resources on becoming <BR>> > more<B=> >R>> > > >> C...<BR>> > > >> Esp when "foundin=> >g fathers" made it so good and so much non-C :).<BR>> > > >>=> ><BR>> > > >> If we really need to make some approach to "the=> >ir world", it's <BR>> > much<BR>> > > >> better to wor=> >k 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>> &=> >gt; > >>> Jay:<BR>> > > >>><BR>> > >=> > >>> My understanding of Modula-3 is that rather than cluttering u=> >p <BR>> > the<BR>> > > >>> source code with a bunch=> > of preprocessor directives to deal <BR>> > with the<BR>> > &gt=> >; >>> various changes needed by various platforms, a separate sour=> >ce<BR>> > > >>> file is<BR>> > > >>> us=> >ed for platforms whose implementation must diverge. The <BR>> > m3mak=> >efile<BR>> > > >>> is used to control the selection of th=> >ese platform sources at <BR>> > build<BR>> > > >>> => >time. I like this approach much better.<BR>> > > >>><BR>&=> >gt; > > >>> Regards,<BR>> > > >>> Randy<BR=> >>> > > >>><BR>> > > >>>>>> Jay=> > <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>><BR>> > &g=> >t; >>> So I have NOT thought this through.<BR>> > > >&=> >gt;><BR>> > > >>> I wonder if "preprocessing" dependen=> >t only on "target" is a good<BR>> > > >>> idea.<BR>> &=> >gt; > >>><BR>> > > >>> Something like either => >the ability to prefix pragmas with a <BR>> > target, or<BR>> > => >> >>> an "iftarget" and "ifnottarget" pragma.<BR>> > >=> > >>><BR>> > > >>> Something like so:<BR>> &gt=> >; > >>><BR>> > > >>> <* IF_TARGET NT386 *&=> >gt;<BR>> > > >>> <* END_IF_TARGET*><BR>> > &g=> >t; >>><BR>> > > >>><BR>> > > >>&g=> >t; <* IF_TARGET NT386 *><BR>> > > >>> <* END_IF_=> >TARGET*><BR>> > > >>> It's a small can of worms.<BR>&g=> >t; > > >>> Where can they be placed? Only at "global" scope?=> > (ie: <BR>> > toplevel in an<BR>> > > >>> interface=> >/module).<BR>> > > >>><BR>> > > >>> Wha=> >t about IF_OSTYPE?<BR>> > > >>> What about expressions?<B=> >R>> > > >>> IF_TARGET NT386 OR NTAMD64<BR>> > > => >>>><BR>> > > >>> IF_TARGET STARTS(NT)<BR>> &g=> >t; > >>><BR>> > > >>> etc.<BR>> > > => >>>><BR>> > > >>> I don't really have enough inte=> >rest here to work through this, <BR>> > just<BR>> > > >&g=> >t;> sending out the bait...<BR>> > > >>><BR>> > => >> >>> Obviously this was triggered by my happening into the odb=> >c <BR>> > directory<BR>> > > >>> and bringing up ig=> >noring WINAPI on non-NT386 or prefixing <BR>> > calling<BR>> > => >> >>> conventions with a target.<BR>> > > >>>=> ><BR>> > > >>> This reminds me of an important point here => >however -- nobody <BR>> > else is<BR>> > > >>> goin=> >g to make the mistake of ever having multiple calling<BR>> > > &gt=> >;>> conventions.<BR>> > > >>> Therefore the general=> >ity of prefixing WINAPI with NT386: is <BR>> > useless.<BR>> > => >> >>> Unless Mac68K support is added.<BR>> > > >&gt=> >;><BR>> > > >>> And here is some rationale even. The P=> >C and Mac evolved from <BR>> > "small"<BR>> > > >>>=> > systems, where assembly programming was common, more people <BR>> > => >knew more<BR>> > > >>> lower level details and playing ga=> >mes with calling conventions <BR>> > was<BR>> > > >>&g=> >t; something anyone could do. Most other current systems are <BR>> > => >rooted in C<BR>> > > >>> programming. Working in C, calli=> >ng conventions are generally <BR>> > in a<BR>> > > >>&=> >gt; hidden layer below what anyone thinks about. Therefore, the <BR>> &g=> >t; smaller<BR>> > > >>> number of capable people working => >at that level have the good <BR>> > sense to<BR>> > > >&g=> >t;> only have one calling convention. No more systems will evolve <BR>&g=> >t; > from<BR>> > > >>> "small", at least not without h=> >aving observed this history.<BR>> > > >>> Therefore,<BR>&=> >gt; > > >>> there will no longer be multiple calling convent=> >ions.<BR>> > > >>><BR>> > > >>> That is=> > my theory at least.<BR>> > > >>><BR>> > > >&=> >gt;> Oh, Windows does also have __thiscall and __clrcall. <BR>> > => >__thiscall is<BR>> > > >>> only x86<BR>> > > &gt=> >;> --<BR>> > > >> Dragi=C5=A1a Duri=C4? <dragisha at m3w.=> >org><BR>> ><BR>> ><BR>> > Connect and share in new way=> >s with Windows Live. Get it now!<BR>> <BR><BR><br /><hr />Shed those ext=> >ra pounds with MSN and The Biggest Loser! <a href=3D'http://biggestloser.ms=> >n.com/' target=3D'_new'>Learn more.</a></body>> ></html>=> >> >--_26c72f2f-07a7-4258-b083-944d52866fbb_--
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080214/332e90cc/attachment-0002.html>