OT - "Source" was Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?

Thanks Oliver. Your perfectly innocent first post has made a rather
interesting thread.

"Oliver Wong" <owong@xxxxxxxxxxxxxx> wrote in message
news:Sv9De.95888$wr.56881@xxxxxxxxxxx
> "jce" <defaultuser@xxxxxxxxxxx> wrote in message
> news:I_0De.10777$iG6.9945@xxxxxxxxxxxxxxxxxxxxxxxxxx
<snip - a very nice explanation on some OO concepts>

>> I would imagine that for a code generator this is a non issue. I would
>> actually think duplicate code is a lot simpler for autotools to manage.
> Well, this depends on what you're trying to accomplish. If the generator
> "knows" ahead of time that two of the things it's going to generate will
> contain identical code, then it probably has some sort of "planning"
> phase. During this phase, it can make a list of all the functionality it
> wants to generate, checking every time it tries to add a feature that it
> isn't already there, to ensure that no duplicate code gets generated. Even
> without an explicit planning phase, typically when generating code, you'll
> want to refer to it (via method calls or even GOTOs) later on, so you'll
> need to keep some sort of list of what you've generated so far anyway.
> But yes, most tools I've seen don't do an explicit "duplicate code check"
> phase, examining the code it just generated. I think most tools make a
> "decent" effort towards not generating duplicate code, but if it does, it
> doesn't worry about it too much.

I'm not sure why the developers would worry much...You are much more versed
in this area than me, but the code generators I have experience with are
EXTREMELY verbose. Frankly I don't care too much because the code was
fairly static and it was easy enough to figure out what it was doing, even
if it was cumbersome. While we licence the tool it's a non issue - but
recently, that _was_ an issue.

>> If the process is always A to B to C...who's responsible for the build
>> and QA test ? Three tools touching code is almost as dangerous as one
>> person touching it :-)
> I think if you can "prove" that a tool doesn't change the semantics of a
> given program, then it doesn't matter how many times you run that tool,
> each time the semantics won't change. Similarly, if you have 3 tools, each
> of which don't change the action, then you can run any of them in any
> order as many times as you like, and the result at the end will be
> semantically identical to the program at the beginning.
> Of course, very rarely do I see program accompanied by formal proof of
> correctness.

I've yet to find a bug free piece of software that provided an value. The
sheer number of problems and patches create for compilers of all types I
think is testament to that. Having spent hours working with the support
start on a DBMS precompiler abending (protection exception) proved it to me.
Now, if a compiler written by the supposed owner of a language cannot get it
right (in the case of Sun) then I'm standing by my statement...though maybe
it's more accurate to say "3000 tools as dangerous as one "smart and
conscientious" person" .

> As for QA, if you're confident that the tool is correct, then you might
> have more important things to spend time testing (e.g. code you've
> manually written); the less confident you are about the tool, the higher
> the priority should be given to testing the generated code.

Most certainly agree with this - which is why I adjusted my numbers above.

>> To date the best advice I"ve received is, "if you cannot understand the
>> generated code, then you shouldn't use the generator". Good code is
>> readable regardless of who wrote it.

> I don't agree with this; when you generate a lexer (the front end of a
> compiler) using a grammar file, usually the lexer will contain completely
> unintelligeable code. The lexer I'm working with, for example, has a giant
> array containing what I assume (based on the name of the variable) is the
> next state its internal state machine should transition to encoded as a
> bunch of integers. The code looks like:
> jjnextStates = { 485, 486, 468, 487, 488, 497, 499, 501, 502, 490, 492,
> 494, 495, 1, 2, 327, 328, 388, 492, 494, 495, 499, 501, 502, 3, 4, 17, 18,
> 30, 31, 48, 49, 64, 65, 77, 78, 98, 99, 119, 120, 145, 146, 171, 172, 193,
> 194, 223, 224, 253, 254, 288, 289, 323, 324, 5, 6, 7, 9, 10, 12, 13, 14,
> 15, 19

So perhaps they threw you a bone? Maybe if it was the following you wouldn't
be able to assume anything.
i = {485,486...}
It's clear you don't care, so it's moot anyway :-)

I'm not versed in this area so excuse the over simplification.
I think with creating a lexer you have an atypical situation and is a tough
one to think about. You are producing a system to essentially tokenize a
"source" for input into a "parser". IMHO the real source that you are
interested in for this example is the 'grammar file'. The _output_ is the
lexer. To me this is similar to a precompile, or in fact, any compile.
Technically, the output from the compiler is "generated" source but I trust
that the provider has done a good job.

I think to put it in perspective it would be as if you wrote the grammar
file to create a lexer and then asked someone to conform to your grammar.
If your grammer made [0.9] mean any letter and [a.Z] be any integer people
would be baffled and say "I don't understand his grammar".

If you are writing the grammar file to create a lexer for an existing
source, then to me it's a case where you are right - I don't care about the
source in _this_ instance.

I was talking more about the typical in use code generators - taking UML,
MetaData, Designs, or GUI whizz bang drag and drop apps to create code in
which you add functionality. I know that if you drop a table on a form and
attach a database query to fill it, you don't have to write ANY code - even
the SQL has a designer these days - I think you should be able to understand
what the tool produced. It _should_ be readable - if it's not the tool
should be replaced with one that is. I've yet to work somewhere where a
generator was bought and the licence was kept for the entire life of the
application - or worse, that the developer of the generator continued to
support the same version. Someone here recently mentioned an IBM structured
cobol facility that was supported on OS/2 but not windows...that's nice.

I _did_ read the other post regarding those who optimize WITHOUT analyzers
=)

> and so on. I don't understand the code at all. However, I have a basic
> understanding of compiler technology (I know, for example, that lexing can
> be done via regular expressions, and that regular expressions can be
> emulated by DFAs (Deterministic Finite Automatas), and that DFAs can be
> implemented as state machines), and I "trust" that my tool works, so I
> don't bother to "test" the lexer that gets generated. So far I haven't
> been disapointed.

If it wasn't important to understand any outputs then everything should
generate just 0's and 1's as an output targetted per CPU, right?

generate allMyBusinessCode.src -target Xeon64 -numprocessors 64

JCE


.

Relevant Pages

  • Re: UNIXs nrand48() routine for Windows/Visual C/C++ 6.0 ?
    ... the nrand48() function on unix. ... Find the source code for nrand48and have it compile/work on windows. ... Use another random number generator like "Mersenne Twister"... ... compiler is just an implementation of the c language... ...
    (comp.lang.c)
  • Re: Type safety, C++ and code generation
    ... Not mentioning the error messages that you get from the compiler ... These are exactly the factors that limit the practical useability of the template approach and that's why I claim that external code generator can be much more powerful. ...
    (comp.lang.ada)
  • Re: WANTED: One good retargettable compiler back end
    ... LCC is a smallish retargetable compiler using IBURG as a backend ... The OLIVE code generator (backend generator actually) is part of the ... SPAM compiler of Princeton. ...
    (comp.compilers)
  • Re: Pros & Cons for AMD 64b vs. Athlon based Linux box
    ... The difference may very well be due to cache issues. ... > applications that I tried NCVerilog was the only one that exhibited a huge ... It could also be that the code generator for 64 ... > compiler and the 64 bit with GCC, ...
    (comp.os.linux.hardware)