[sclug] The C Lang is not machine readable

[Graham]

Top-posted from
> Subject: [sclug] Building very large packages?

	The problem with the (AST) world today is ... machine readability yesterday

	The C language is not machine readable.
	Makefiles are not, nor shell, Tcl, Pascal, ASM, ... 

	Compilers and bin/make process the files, but they dont _UNDERSTAND_ them.
	Re-factoring IDE's do (to some extent), but there is a missing popularity
	for tools that can read programs, and understand them as they are.

	Doxygem does seem to have some MR skills, it can retain the original text
	(not wiped out by CPP), cross-refer linked symbols, but it should have been
	written as an extension to GENERIC tools, not from scratch.

	cb-beautifier _APPEARS_ to do MR. (its output matches its input, but mormalised)
	but its a barely-sufficient list of text processing tricks (it doesnt understand
	the code).

	gcc (and others) can read the files into AST abstract-syntax-trees, but thats AFTER
	the CPP has lost a lot of nuances (# define PAGE_SIZE 4096). It cannot output
	a C/C++ file that is then HUMAN readable.

	If we had a culture of machine readability, C++ would be slightly different,
	and _USED_ significantly differently. We would have more home-brew varients,
	like embedded SQL, or programs that can call functions in #define declarations.
	Like YAXX, we'd have more tables built from running code, and we'd certainly have
	much better IDE's 

	In a culture of machine readability, the authors of llgen, would make it MR,
	and the other scripts. You would be able to run an option like 'gcc -MM'
	to list all dependencies.

	In a culture of machine readability, it would be common practice to have a
	pre-loaded image of all the header.h files, and you would have fine grained
	dependencies, on FIELDS of classes, not entire header files. Then a minor
	change ina header file, that didnt change ony OFFSETS of anu fields,
	would not recimpile the world.


	Why are you taking over the maintenence of the  ACK?
	Maybe you could take your position as an opportunity to ask
	compiler enthusiasts, to write a parser for C++, that creates a tree,
	that can then write a C++ file, that looks like the input.

		Due to C/C++ characteristics, comments can be _EXPECTED_
		to be in doxygen format, or moved to a fixed place.

	I've looked on Stroustroup's site, but there is only a free-market approach
	to parsers, not an actual one.

--
   Graham
   gps @ Information-Cascade .co.uk
   www . Information-Cascade .co.uk


> Message: 2
> Date: Fri, 24 Jun 2005 20:32:04 +0100
> From: David Given <dg at cowlark.com>
> Subject: [sclug] Building very large packages?
> To: sclug at sclug.org.uk
> Message-ID: <200506242032.05008.dg at cowlark.com>
> Content-Type: text/plain;  charset="us-ascii"
> 
> I've found myself maintaining a large compiler toolchain; the ACK 
> (http://tack.sf.net). There are about 10'000 files in its source repository, 
> some of which have timestamps over twenty years old, all bound together by an 
> undocumented mass of twisty, turny little shell scripts and recursive 
> makefiles. I'm having a lot of trouble making it do *anything* much.
> 
> So, I'd rather like to replace the whole build system with something more 
> modern. Any suggestions?
> 
> (I do have a half-finished custom build system based around generating a 
> single, very large makefile --- currently over 600kB. This gets all the 
> dependencies right and is very fast, but I'm not terribly happy about the 
> maintainability.)
> 
> Part of the trouble is that the ACK is made up of lots and lots, and lots, of 
> little tools that generate code. The nastiest one I've met so for is llgen, a 
> LL(1) parser generator styled after yacc (a version of which is supplied). 
> The llgen source files are read in with a parser written in llgen! Hopefully, 
> that's the only actual recursive dependency, but everything else is just as 
> annoying (in different ways).
> 
> -- 
> "Curses! Foiled by the chilled dairy treats of righteousness!" --- Earthworm 
> Jim (evil)
> 
> ------------------------------