[M3devel] "target specific pragmas"?

[Darko]

M3 is the antithesis in the sense that it takes the opposite approach.  
C has few protections, M3 has many. M3 does examine what was wrong  
with C and other languages and fix them and it did a good job. The M3  
design team made an explicit goal to look at features from other  
languages and take the best. The fact that M3 works so well is the  
proof.

Some of the things you raise, like braces or stack allocations of  
objects are just features of C++ with no justification. Can you show  
that typing less characters is important? You say M3 is less  
convenient, but what is less convenient, less typing or less bugs? Do  
you spend most of your time typing or thinking when you write code?

Should language include every feature anyone can think of? How is  
excluding unimportant features 'arbitrary'? Each feature must be  
weighed to avoid unnecessary complexity and size, which have a direct  
impact on compiler maintainability and language usability. Language  
bloat is a real problem. I doubt that anyone understands the full  
semantics of C++.

You say that C has 'won', but in what sense? More people use it?  
Language design is not American Idol, it's not a question of who has  
the most votes.

You have to do more than list features of C or C++ and your opinions  
on them. You have to provide some rationale as to their benefit which  
convinces people.



On 14/02/2008, at 11:34 AM, Jay wrote:

> 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! Learn more.