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