libes@nbs-amrf.UUCP (Don Libes) (05/14/86)
> Couldn't you write a small(?) filter which would let you write C > without braces and fill them in for you from the indentation? It > doesn't seem too difficult. (No I'm not offering to do it). Someone here, upon being introduced to C, decided it was so ugly, that he wrote a filter called "uglify" which allowed him to write "beautiful code" which when translated by uglify looked like real C. One of the things uglify did was to take statements without the braces and fill them in from the indentation. It did a variety of other things that were cute. One of the things I remember is that you could put the args next to the formats in printf strings, rather than having to count up the number of %'s you had seen to tell which argument to look at. The guy obviously had no idea of separation between lexical scanning, parsing and functions. He just knew what he liked and didn't like. I refused to criticize him, because some of the best ideas are born that way. If you want "uglify", call Tom Kramer (301) 921-2461. I'm sure he doesn't read his mail. Don Libes {seismo,umcp-cs}!nbs-amrf!libes
zben@umd5.UUCP (Ben Cranston) (05/17/86)
Forgive me if this is too obvious to mention, but it seems to me that using
the indentation information makes life much harder for programs like YACC
and LEX that act by creating C source code. Now they have to keep track of
what column they are outputting to...
I just remember doing some assembly macros that tried to make their
expansion obvious by "display"ing the code they were generating to the
listing before actually generating it. There was real gore in getting the
columns lined up right, and in getting meaningful comments...
--
"We're taught to cherish what we have | Ben Cranston
by what we have no longer..." | zben@umd2.umd.edu
...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben kwh@bentley.UUCP (KW Heuer) (05/19/86)
In article <968@umd5.UUCP> umd5!zben (Ben Cranston) writes: >Forgive me if this is too obvious to mention, but it seems to me that using >the indentation information makes life much harder for programs like YACC >and LEX that act by creating C source code. Now they have to keep track of >what column they are outputting to... Slightly harder, but still not all that difficult. Instead of outputting a left brace, the program increments a variable; instead of a right brace, it decrements. Then each output line is preceded by that many blanks. Of course, I'm assuming some support would be built into yacc and lex. They would automatically add the indentation level of your code blocks to that of the automatically-generated blocks. Btw, how would such a language interpret a one-liner like "if (c) a; b;"? Would that be "if (c) {a;} b;" or "if (c) {a; b;}" or just illegal? Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
franka@mmintl.UUCP (Frank Adams) (05/21/86)
In article <968@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: > >Forgive me if this is too obvious to mention, but it seems to me that using >the indentation information makes life much harder for programs like YACC >and LEX that act by creating C source code. Now they have to keep track of >what column they are outputting to... This isn't all that hard. Such programs must implicitly keep track of depth, frequently by recursion. Adding the additional machinery to make this explicit is not bad. One global variable, and update it every time you enter or exit a block in the generated code. >I just remember doing some assembly macros that tried to make their >expansion obvious by "display"ing the code they were generating to the >listing before actually generating it. There was real gore in getting the >columns lined up right, and in getting meaningful comments... Dealing with such issues in the macro processing portion of an assembler is another matter entirely. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108