[M3commit] CVS Update: cm3

[Tony Hosking]

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