Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!bomgard
From: bomgard@iuvax.cs.indiana.edu (Tim Bomgardner)
Newsgroups: comp.lang.c
Subject: Re: C preprocessing
Message-ID: <60134@iuvax.cs.indiana.edu>
Date: 25 Sep 90 02:13:08 GMT
References: <59770@iuvax.cs.indiana.edu> <223@srchtec.UUCP>
Organization: Indiana University, Bloomington
Lines: 92

In article <223@srchtec.UUCP> johnb@srchtec.UUCP (John T. Baldwin) writes:
}[ellipsis indicates deletion for brevity --jtb] --tab, too.
}
}In article <59770@iuvax.cs.indiana.edu> bomgard@iuvax.cs.indiana.edu
}  (Tim Bomgardner) writes:
}>Wouldn't it be nice ... if the compiler would do what I meant
}>instead of what I said?
}>...
}>Code is written two-dimensionally ... why does it have to processed as
}> a one-dimensional string of tokens?
}>...
}>    if (bool_expression)
}>        do_something();
}>        do_something_else();
}>        if (another_bool_expression)
}>            do_anything();
}>    else
}>        do_this_when_bool_expression_is_false();
}
}This begs several questions.
}
}#1  Why does the program have to be processed as a one-dimensional string
}    of tokens?
}
}It doesn't.

But it is.  And it has to be, "because the language has been defined that
way."  Assuming of course you still consider what I wrote to be C.

}At least, programs in general do not have to be processed this
}way.  Your C programs are, because the language has been defined that way.
}The reason why language designers like to do this is because it makes it
}easier to write the compiler (i.e. the lexer and parser are easier).
}
}[...suggestion that I read up on compiler theory]

Boy, give 'em lex and yacc and tell 'em about LALR(1) and they're ready
for the big time.  I've produced a compiler or two.  I don't know about
the "language designers" here, but my parsers have no difficulty at all
with this sort of grammer.  You wanna know what's hard?  The parser I'm
working on right now recognizes graphics.

}#2  Why can't the compiler "catch" the fact that what was meant (above)
}    isn't what was said?
}
}Because a compiler's job is to translate what was *said*.  The only
}analysis the compiler is required to perform is whatever is germane
}to that task.

Says you.  In the case of C, I agree.  But I'm not really talking about
C anymore.  Maybe I shouldn't call it a preprocessor, although that's
how I think of it.  Perhaps translator would be a better word.  My
intention is to translate into C the way AT&T does with C++.

}If you want a critique, use LINT or a lint-like analyser.  At least
}one LINT that I know of "understands" general indentation rules and
}will flag the probable error above, i.e.
}
}   "line xxx: do you know you *outdented* the 'else' that goes with
}    'if (another_bool_expression)' ???"

You see!  It isn't really all that hard at all to recognize what's
going on.  But I don't want a critique; I want it to just do it.  That's
why I use a compiler in the first place instead of an assembler.

}#3   Wouldn't it be nice if the compiler would do what I meant, instead
}     of what I said?
}
}Yes.
}
}When you (or anyone else) manages to do this, be *sure* to publish.  Quickly.
}You'll probably win a Nobel Prize.    :-)   :-)   :-)   :-)   :-)

Fortran gave us data abstraction.  Block structured languages gave us
control abstraction.  What I'm looking for now I'll call structure
abstraction.  When I design something, I use little diagrams and pictures
and sometimes raw C code as well.  I then take all that and translate it
into C.  My goal is to have the computer do that for me.  I really don't
care about a nobel prize that much (my ideas aren't really that original),
but I WILL be accepting VISA and Mastercard.

}
}-- 
}John T. Baldwin                      |  johnb%srchtec.uucp@mathcs.emory.edu
}Search Technology, Inc.              | 
}                                     | "... I had an infinite loop,
}My opinions; not my employers'.      |  but it was only for a little while..."

To all who have responded, thank you.  I appreciate the feedback.  This is
helping me refine the concepts.  More to come.

Tim