
<html>

<head>

<style>

.hmmessage P

{

margin:0px;

padding:0px

}

body.hmmessage

{

FONT-SIZE: 10pt;

FONT-FAMILY:Tahoma

}

</style>

</head>

<body class='hmmessage'>I'll <EM>try </EM>to repeat myself less and ramble 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 code probably once the bug is fixed. (Ok, I like to comment out or somehow disable sometimes maybe but that is a different point, it's still not the height of production code; and yes, I realize it's a slippery slope and the next 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 than you.<BR>

Bad module system -- #include.<BR>

Bad module system -- preprocesor which kills or damages other efforts at language-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 editors all support braces now.<BR>

Until you get me to change editors (probably never), Modula-3 is always going to be less convenient.<BR>

At this point you are just fighting the vast majority (except Python...). It could have gone differently, but C won.<BR>

 <BR>

If you ignore that lowest level thing, there are places where Modula-3 is perfectly good, but doesn't take the next step.<BR>

A good example I think here is it has nice "objects", however it requires they be heap allocated I think even in unsafe code. You should be able stack (or global) allocate something with "virtual functions". It seems an arbitrary limitation. I realize in safe code, you have to heap allocate more anyway, but that is a different point I think.<BR>

 <BR>

Similarly is "multiple inheritance just of interfaces". I realize though..this hides a "vtable per interface". Maybe is much more expensive than people realize and shouldn't be provided lightly.<BR>

 <BR>

SUBARRAY is probably example where I don't/didn't know the language well enough.<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 examples. A tutorial that gives many examples might be good. Hey maybe I'm just the 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 friendly intellectual discussion with.<BR>

(and of course, don't mess up their code)<BR>

 <BR>

 - Jay<BR><BR><BR>


<HR id=stopSpelling>

<BR>

> CC: jayk123@hotmail.com; m3devel@elegosoft.com<BR>> From: darko@darko.org<BR>> To: rcoleburn@scires.com<BR>> Subject: Re: [M3devel] "target specific pragmas"?<BR>> Date: Thu, 14 Feb 2008 11:10:18 +1100<BR>> <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>> approaching the M3 language. It may be the point that Jay hasn't <BR>> created and serious software in M3 and needs to be informed of the <BR>> 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. M3 is is not just different to C, <BR>> 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.<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 problems <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 which 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 structures 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 something else more efficient but also configurable since <BR>> embedding fixed strings in your code is generally a a bad idea.<BR>> <BR>> <BR>> 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 frankly 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 <BR>> > 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 welcome any <BR>> > move to divest CM3 of all underpinnings from the C world.<BR>> ><BR>> > Have you seriously studied the Modula-3 language and used it to <BR>> > build production software? I think some of your comments suggest <BR>> > that you are not a true Modula-3 programmer and that you still cling <BR>> > to the C-way of doing things 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>> > Truly, 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>> > advancement of Modula-3.<BR>> ><BR>> > Regards,<BR>> > Randy<BR>> ><BR>> > >>> Jay <jayk123@hotmail.com> 2/12/2008 11:28 PM >>><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>> ><BR>> > This is somewhat my point.<BR>> > When I am debugging, I really miss printf.<BR>> ><BR>> > The debugging options seem really poor everywhere and esp. on NT386.<BR>> ><BR>> > gdb has all wierded out variable names for one thing.<BR>> > And I think we should fix it so that that the symbols have full <BR>> > source paths.<BR>> > I realize they would only be correct on one machine, and hopefully <BR>> > there's a decent story for copying the files.<BR>> > Yeah, 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 functions 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. Because, see, cdb is nice enough to <BR>> > stop on access violations by default (such as the time/date code was <BR>> > 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 <BR>> > more and I can break on the toplevel exception handler in <BR>> > cygwin1.dll, not sure that always works or not, it's an <BR>> > implementation detail, but heck, when you are debugging, take <BR>> > advantage of whatever you have. :)<BR>> ><BR>> > RTIO, is too verbose for me.<BR>> > But darnit, I can't really have printf..puts is about the best I <BR>> > could do..<BR>> > Oh, but no, since TEXT != char* even that isn't useful.<BR>> > fread/fwrite maybe though.<BR>> ><BR>> > On a different hand (how many are there? :) ), have you looked in <BR>> > m3core\src\unix?<BR>> > There is just tons of dead stuff, stuff with comments about it <BR>> > perhaps being wrong, "use with care".<BR>> > It seemed to me maybe the point was to expose "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* functions being commented out (and probably <BR>> > using the incorrect type int) because Ultrix or somesuch didn't have <BR>> > them. I uncommented them to fix a build. And notice that these <BR>> > functions, again, like most of printf, are /extremely/ portable in <BR>> > functionality and exact binary interface (yeah yeah, I've heard of <BR>> > bcopy and bzero).<BR>> ><BR>> > What there was of Cstdio.i3 seemed very possibly wrong, at least on <BR>> > many targets, and very doubtfully useful for anything, and I think <BR>> > I've now shown unused.<BR>> ><BR>> > > Y, the easiest way to implement the interface is to call a C <BR>> > function<BR>> > > that "just happens" to have the correct interface. But on another<BR>> ><BR>> > But wrapping everything in Modula-3 is so tedious...<BR>> > Oh for all languages to just understand C headers so we can stop <BR>> > rewriting them...<BR>> > Or some other language, ok...not going to be solved in this forum.<BR>> > To go the unpopular route (again), MS CLR/.NET among many other <BR>> > things, attempts to solve this very problem.<BR>> > One way to describe "interfaces" that "all" languages can <BR>> > understand...at least for some subset of languages features..<BR>> ><BR>> > Just as tedious btw, it is often more portable 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>> > - Jay<BR>> ><BR>> ><BR>> > > To: hosking@cs.purdue.edu<BR>> > > Date: Tue, 12 Feb 2008 16:37:43 -0800<BR>> > > From: mika@async.caltech.edu<BR>> > > CC: m3devel@elegosoft.com<BR>> > > Subject: Re: [M3devel] "target specific pragmas"?<BR>> > ><BR>> > ><BR>> > > This is also an excellent reason not to permit "interfaces" to C<BR>> > > code inlined into MODULEs.<BR>> > ><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 <BR>> > 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<BR>> > > exist, it might be convenient to implement 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 (which was generated<BR>> > > by ifort). On other systems, the code is implemented in Modula-3.)<BR>> > ><BR>> > > Mika<BR>> > ><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 there is no<BR>> > > >C?!?! Consider the SPIN OS perhaps...<BR>> > > ><BR>> > > >Maybe I am just being overly fusty...<BR>> > > ><BR>> > > >On Feb 12, 2008, at 4:35 PM, Dragiša Duri�? wrote:<BR>> > > ><BR>> > > >> 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>> > > >><BR>> > > >> But, as current system works, and it does it very well, and as <BR>> > only<BR>> > > >> case<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<BR>> > > >> C...<BR>> > > >> Esp when "founding fathers" made it so good and so much non-C :).<BR>> > > >><BR>> > > >> If we really need to make some approach to "their world", it's <BR>> > much<BR>> > > >> better to work 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>> > > >>> Jay:<BR>> > > >>><BR>> > > >>> My understanding of Modula-3 is that rather than cluttering up <BR>> > the<BR>> > > >>> source code with a bunch of preprocessor directives to deal <BR>> > with the<BR>> > > >>> various changes needed by various platforms, a separate source<BR>> > > >>> file is<BR>> > > >>> used for platforms whose implementation must diverge. The <BR>> > m3makefile<BR>> > > >>> is used to control the selection of these platform sources at <BR>> > build<BR>> > > >>> time. I like this approach much better.<BR>> > > >>><BR>> > > >>> Regards,<BR>> > > >>> Randy<BR>> > > >>><BR>> > > >>>>>> Jay <jayk123@hotmail.com> 2/11/2008 8:21 PM >>><BR>> > > >>> So I have NOT thought this through.<BR>> > > >>><BR>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good<BR>> > > >>> idea.<BR>> > > >>><BR>> > > >>> Something like either the ability to prefix pragmas with a <BR>> > target, or<BR>> > > >>> an "iftarget" and "ifnottarget" pragma.<BR>> > > >>><BR>> > > >>> Something like so:<BR>> > > >>><BR>> > > >>> <* IF_TARGET NT386 *><BR>> > > >>> <* END_IF_TARGET*><BR>> > > >>><BR>> > > >>><BR>> > > >>> <* IF_TARGET NT386 *><BR>> > > >>> <* END_IF_TARGET*><BR>> > > >>> It's a small can of worms.<BR>> > > >>> Where can they be placed? Only at "global" scope? (ie: <BR>> > toplevel in an<BR>> > > >>> interface/module).<BR>> > > >>><BR>> > > >>> What about IF_OSTYPE?<BR>> > > >>> What about expressions?<BR>> > > >>> IF_TARGET NT386 OR NTAMD64<BR>> > > >>><BR>> > > >>> IF_TARGET STARTS(NT)<BR>> > > >>><BR>> > > >>> etc.<BR>> > > >>><BR>> > > >>> I don't really have enough interest here to work through this, <BR>> > just<BR>> > > >>> sending out the bait...<BR>> > > >>><BR>> > > >>> Obviously this was triggered by my happening into the odbc <BR>> > directory<BR>> > > >>> and bringing up ignoring 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>> > > >>> going to make the mistake of ever having multiple calling<BR>> > > >>> conventions.<BR>> > > >>> Therefore the generality of prefixing WINAPI with NT386: is <BR>> > useless.<BR>> > > >>> Unless Mac68K support is added.<BR>> > > >>><BR>> > > >>> And here is some rationale even. The PC and Mac evolved from <BR>> > "small"<BR>> > > >>> systems, where assembly programming was common, more people <BR>> > knew more<BR>> > > >>> lower level details and playing games with calling conventions <BR>> > was<BR>> > > >>> something anyone could do. Most other current systems are <BR>> > rooted in C<BR>> > > >>> programming. Working in C, calling conventions are generally <BR>> > in a<BR>> > > >>> hidden layer below what anyone thinks about. Therefore, the <BR>> > smaller<BR>> > > >>> number of capable people working at that level have the good <BR>> > sense to<BR>> > > >>> only have one calling convention. No more systems will evolve <BR>> > from<BR>> > > >>> "small", at least not without having observed this history.<BR>> > > >>> Therefore,<BR>> > > >>> there will no longer be multiple calling conventions.<BR>> > > >>><BR>> > > >>> That is my theory at least.<BR>> > > >>><BR>> > > >>> Oh, Windows does also have __thiscall and __clrcall. <BR>> > __thiscall is<BR>> > > >>> only x86<BR>> > > >> --<BR>> > > >> Dragiša Duri�? <dragisha@m3w.org><BR>> ><BR>> ><BR>> > Connect and share in new ways with Windows Live. Get it now!<BR>> <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>