[M3devel] "target specific pragmas"?

Thu Feb 14 01:34:44 CET 2008

I'll try to repeat myself less and ramble less, and stay constructive...

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).

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 than you.
Bad module system -- #include.
Bad module system -- preprocesor which kills or damages other efforts at language-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.

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 editors all support braces now.
Until you get me to change editors (probably never), Modula-3 is always going to be less convenient.
At this point you are just fighting the vast majority (except Python...). It could have gone differently, but C won.

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

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.

SUBARRAY is probably example where I don't/didn't know the language well enough.
  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 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)

I guess I should be in comp.lang.c.advocacy. :)

To a large extent I'm just looking for a small smart group to have a friendly intellectual discussion with.
(and of course, don't mess up their code)

 - 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 > benefits. I've seen some good responses along these lines from members > of the list.> > But Randy does have a valid point. M3 is is not just different to C, > it's the antithesis of C. It's everything C isn't and the language > designers went to great lengths to make it this way. It's why most of > us use the language.> > I certainly wouldn't like to drive anyone away because they have a > different point of view, but it may be a good idea to examine problems > and solutions more closely and offer other solutions that 'why not do > it like C'.> > In the case of printf, it is useful, when debugging especially, and > I've created some code which takes a list of refany parameters and > prints them out. It is a bit inefficient since any 'atomic' values > such as integers need to be allocated but it also prints out all the > fields of structures and arrays. But it is completely safe. If there > were a need for a more efficient way to generated formatted strings, > I'd write something else more efficient but also configurable since > embedding fixed strings in your code is generally a a bad idea.> > > On 14/02/2008, at 4:44 AM, Randy Coleburn wrote:> > > Jay:> >> > I don't want to be offensive, but quite frankly I'm tired of > > continually reading your gripes about Modula-3 as a language and > > your pining for C.> >> > This forum is for those people interested in advancing the state of > > Modula-3. We don't care about C/C++/C#/etc in this forum. Those of > > us who are M3 zealots for the most part probably would welcome any > > move to divest CM3 of all underpinnings from the C world.> >> > Have you seriously studied the Modula-3 language and used it to > > build production software? I think some of your comments suggest > > that you are not a true Modula-3 programmer and that you still cling > > to the C-way of doing things rather than embracing the Modula-3 way.> >> > Now, I do think that most people are interested in improving things > > and no language is perfect, so any well-thought-out proposal for a > > change to the language is welcome for consideration, But in this > > mail list forum, I for one would appreciate less ranting about C and > > more constructive Modula-3.> >> > Truly, I do not want to offend you. Maybe I'm just having a bad > > day, but I encourage you to try and focus your posts to the > > advancement of Modula-3.> >> > Regards,> > Randy> >> > >>> Jay <jayk123 at hotmail.com> 2/12/2008 11:28 PM >>>> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> >> > This is somewhat my point.> > When I am debugging, I really miss printf.> >> > The debugging options seem really poor everywhere and esp. on NT386.> >> > gdb has all wierded out variable names for one thing.> > And I think we should fix it so that that the symbols have full > > source paths.> > I realize they would only be correct on one machine, and hopefully > > there's a decent story for copying the files.> > Yeah, I know about "dir" but haven't yet formed a .gdbinit or whatnot.> >> > Other than printf'ing, I also end up getting a stack in cdb with no > > symbols and then disasm in gdb to find what the functions were. That > > works fine a few times, but I hope not to do it often. Somewhat > > lucky I could even get a stack. Because, see, cdb is nice enough to > > stop on access violations by default (such as the time/date code was > > causing). gdb has a promising sounding feature, the ability to stop > > on "signals", which I think an access violation would count as, oh, > > but that feature isn't implemented, sorry. Ok, true, think about it > > more and I can break on the toplevel exception handler in > > cygwin1.dll, not sure that always works or not, it's an > > implementation detail, but heck, when you are debugging, take > > advantage of whatever you have. :)> >> > RTIO, is too verbose for me.> > But darnit, I can't really have printf..puts is about the best I > > could do..> > Oh, but no, since TEXT != char* even that isn't useful.> > fread/fwrite maybe though.> >> > On a different hand (how many are there? :) ), have you looked in > > m3core\src\unix?> > There is just tons of dead stuff, stuff with comments about it > > perhaps being wrong, "use with care".> > It seemed to me maybe the point was to expose "all" of /usr/include.> > Someone, other than me, sure seems to have gone overboard, like > > someone using Ultrix and Linux 1.x, and then it copied around.> > Heck, look at the mem* functions being commented out (and probably > > using the incorrect type int) because Ultrix or somesuch didn't have > > them. I uncommented them to fix a build. And notice that these > > functions, again, like most of printf, are /extremely/ portable in > > functionality and exact binary interface (yeah yeah, I've heard of > > bcopy and bzero).> >> > What there was of Cstdio.i3 seemed very possibly wrong, at least on > > many targets, and very doubtfully useful for anything, and I think > > I've now shown unused.> >> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> >> > But wrapping everything in Modula-3 is so tedious...> > Oh for all languages to just understand C headers so we can stop > > rewriting them...> > Or some other language, ok...not going to be solved in this forum.> > To go the unpopular route (again), MS CLR/.NET among many other > > things, attempts to solve this very problem.> > One way to describe "interfaces" that "all" languages can > > understand...at least for some subset of languages features..> >> > Just as tedious btw, it is often more portable to wrap all the C > > APIs in C, exposing a portable controled Modula-3 interface > > independent of the precise header content. Like errno and my > > get_stderr/out/in.> >> > - Jay> >> >> > > To: hosking at cs.purdue.edu> > > Date: Tue, 12 Feb 2008 16:37:43 -0800> > > From: mika at async.caltech.edu> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] "target specific pragmas"?> > >> > >> > > This is also an excellent reason not to permit "interfaces" to C> > > code inlined into MODULEs.> > >> > > Interfaces are the contract that the implementation has to live up> > > to. Ok, so it happens that under operating system X on architecture> > > Y, the easiest way to implement the interface is to call a C > > function> > > that "just happens" to have the correct interface. But on another> > > system, which either isn't built in C or where the function doesn't> > > exist, it might be convenient to implement the interface in (gasp!)> > > Modula-3!> > >> > > (I use this pattern as follows: on systems where Intel's Fortran> > > compiler is available, compile from assembly (which was generated> > > by ifort). On other systems, the code is implemented in Modula-3.)> > >> > > Mika> > >> > > Tony Hosking writes:> > > >My principle concern is that once we provide C APIs then C will> > > >permeate the M3 space more pervasively (both apps and libraries).> > > >What happens when I want to bring up a system where there is no> > > >C?!?! Consider the SPIN OS perhaps...> > > >> > > >Maybe I am just being overly fusty...> > > >> > > >On Feb 12, 2008, at 4:35 PM, DragiÅ¡a DuriÄ? wrote:> > > >> > > >> What we _maybe_ can do... is to make some special, preprocessable> > > >> source> > > >> form, which some quake command can parse into multiple files in > > their> > > >> folders. And these file can be compiled later...Kind of how > > generic> > > >> works.> > > >>> > > >> But, as current system works, and it does it very well, and as > > only> > > >> case> > > >> where we really need this is Windows... most Unices being or > > becoming> > > >> POSIX... I don't see it's smart to spend resources on becoming > > more> > > >> C...> > > >> Esp when "founding fathers" made it so good and so much non-C :).> > > >>> > > >> If we really need to make some approach to "their world", it's > > much> > > >> better to work on interoperability issues and thus cement our> > > >> first-class-citizen language status even more.> > > >>> > > >> dd> > > >>> > > >> On Tue, 2008-02-12 at 15:16 -0500, Randy Coleburn wrote:> > > >>> Jay:> > > >>>> > > >>> My understanding of Modula-3 is that rather than cluttering up > > the> > > >>> source code with a bunch of preprocessor directives to deal > > with the> > > >>> various changes needed by various platforms, a separate source> > > >>> file is> > > >>> used for platforms whose implementation must diverge. The > > m3makefile> > > >>> is used to control the selection of these platform sources at > > build> > > >>> time. I like this approach much better.> > > >>>> > > >>> Regards,> > > >>> Randy> > > >>>> > > >>>>>> Jay <jayk123 at hotmail.com> 2/11/2008 8:21 PM >>>> > > >>> So I have NOT thought this through.> > > >>>> > > >>> I wonder if "preprocessing" dependent only on "target" is a good> > > >>> idea.> > > >>>> > > >>> Something like either the ability to prefix pragmas with a > > target, or> > > >>> an "iftarget" and "ifnottarget" pragma.> > > >>>> > > >>> Something like so:> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>>> > > >>>> > > >>> <* IF_TARGET NT386 *>> > > >>> <* END_IF_TARGET*>> > > >>> It's a small can of worms.> > > >>> Where can they be placed? Only at "global" scope? (ie: > > toplevel in an> > > >>> interface/module).> > > >>>> > > >>> What about IF_OSTYPE?> > > >>> What about expressions?> > > >>> IF_TARGET NT386 OR NTAMD64> > > >>>> > > >>> IF_TARGET STARTS(NT)> > > >>>> > > >>> etc.> > > >>>> > > >>> I don't really have enough interest here to work through this, > > just> > > >>> sending out the bait...> > > >>>> > > >>> Obviously this was triggered by my happening into the odbc > > directory> > > >>> and bringing up ignoring WINAPI on non-NT386 or prefixing > > calling> > > >>> conventions with a target.> > > >>>> > > >>> This reminds me of an important point here however -- nobody > > else is> > > >>> going to make the mistake of ever having multiple calling> > > >>> conventions.> > > >>> Therefore the generality of prefixing WINAPI with NT386: is > > useless.> > > >>> Unless Mac68K support is added.> > > >>>> > > >>> And here is some rationale even. The PC and Mac evolved from > > "small"> > > >>> systems, where assembly programming was common, more people > > knew more> > > >>> lower level details and playing games with calling conventions > > was> > > >>> something anyone could do. Most other current systems are > > rooted in C> > > >>> programming. Working in C, calling conventions are generally > > in a> > > >>> hidden layer below what anyone thinks about. Therefore, the > > smaller> > > >>> number of capable people working at that level have the good > > sense to> > > >>> only have one calling convention. No more systems will evolve > > from> > > >>> "small", at least not without having observed this history.> > > >>> Therefore,> > > >>> there will no longer be multiple calling conventions.> > > >>>> > > >>> That is my theory at least.> > > >>>> > > >>> Oh, Windows does also have __thiscall and __clrcall. > > __thiscall is> > > >>> only x86> > > >> --> > > >> DragiÅ¡a DuriÄ? <dragisha at m3w.org>> >> >> > Connect and share in new ways with Windows Live. Get it now!> 
_________________________________________________________________
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/ac1f2a2a/attachment-0002.html>