[M3commit] CVS Update: cm3

[Jay]

Really I'm aware of most/all of these issues and some of it, sorry, I forgot.
  I forgot that one of Modula-3's (few) strengths, it was ahead of its time, and now everything else except C and C++ have caught up (e.g. Java, C#), is that it easy to parse and easy to build other tools that parse it, instead of the compiler being the only tool by far that understands the language, and be incapable of providing everyone's feature, so you are left with a shortage of functionality, esp. that full works (class browsers and such).
 
I do rather think the situation is already slightly broken in this regard though.
That is, there are already generated source files. So either every tool has to know quake (not), or there has to be a place to go to get "the Modula-3 source" and "the Modula-3 source before running quake". I rather suspect this is the package store...except dependency on shipping probably very not good. Perhaps perhaps it is a very simple minimal search algorithm -- look in BUILD_DIR first? Perhaps such tools tend to be able to ignore what they can't find or understand??
 
And, if I /really/ wanted this feature (not), I would suggest (rather than merely mention :) ) the idea that whenever there was "target preprocessing", the compiler would be obligated to output a "preprocessed" file into BUILD_DIR.
(This reminds, Metrowerks IDEs have a feature, right click on a file and select "preprocess". It is sorely missing in Visual Studio..it'd also be nice to have a batch mode -- build everything and while you are it, save preprocessed versions of everything, maybe in a compressed tokenized form viewable in the IDE unless I ask for plain text for plain tools)
 
I didn't realize the subtley of pragmas limited affect, though I think it's still debatable.
I think it'd be reasonable for other language tools to be confused about the nonexistance of implementations of <*extern*> functions.
 
 - Jay



> From: hosking at cs.purdue.edu> Date: Tue, 12 Feb 2008 12:49:21 -0500> To: jkrell at elego.de> CC: m3commit at elegosoft.com> Subject: Re: [M3commit] CVS Update: cm3> > There are inherently *BAD* *BAD* things about target preprocessing. > The baddest thing is that preprocessing is defined separately from > the language, so any tools that you use to process source files > (including IDEs) have to smarten up to understand the preprocessors. > In another project I am involved in it took a year or so to *remove* > preprocessing crap from the sources so that the project could be > developed and built using Eclipse.> > I would hate to see M3 go the way of C in this regard.> > There are more principled ways of doing language-defined (syntactic/ > checkable/tool-usable) MACROS but in my opinion those approaches will > add unnecessary complexity and clutter to what is currently a very > clean Modula-3 language specification. I STRONGLY oppose any notion > of "preprocessing" for Modula-3.> > On Feb 12, 2008, at 1:32 PM, Jay Krell wrote:> > > CVSROOT: /usr/cvs> > Changes by: jkrell at birch. 08/02/12 13:32:58> >> > Modified files:> > cm3/m3-libs/m3core/src/C/Common/: Cstddef.i3 m3makefile> > cm3/m3-libs/m3core/src/C/NT386/: m3makefile> > cm3/m3-libs/m3core/src/C/NT386GNU/: m3makefile> > Added files:> > cm3/m3-libs/m3core/src/C/Common/: Cstdio.i3 CstdioC.c> > Removed files:> > cm3/m3-libs/m3core/src/C/NT386/: Cstdio.i3> > cm3/m3-libs/m3core/src/C/NT386GNU/: Cstdio.i3> >> > Log message:> > a more complete fairly portable Cstdio.i3, only for NT386 for now> > (This highlights well where target-preprocessing would be useful,> > the majority of Cstdio.i3 is completely portable, except possibly> > for fpos_t, SEEK_SET/CUR/END, and fdopen/fileno, etc.)> 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20080213/7d0c0b66/attachment-0002.html>