Cobol/Java/etc

Ladies (if present here?) & Gentlemen,

Speaking of languages it's just came to my mind the old "task" published
relatively long time ago by the American writer (unfortunatly I've forgot
his name, but actually I can figure out).

The task is to write the program which prints it's own source code (so it
can be accepted by compiler) but of course not reading any file.

For all Cobol funs I can suggest to try :-))
(I'm not sure anybody has a guts to do that in Cobol but I'll definitely
take my hat off if I see that source)

As I remember it took for me 40 minutes and 9 statements in PL/I language.

Regards,
Sergey

"Sergey Kashyrin" <ska@resqnet.com> wrote in message
news:D8MSf.55$Th7.117876@news.sisna.com...
> Ladies (if present here?) & Gentlemen,
>
> Speaking of languages it's just came to my mind the old "task" published
> relatively long time ago by the American writer (unfortunatly I've forgot
> his name, but actually I can figure out).
>
> The task is to write the program which prints it's own source code (so it
> can be accepted by compiler) but of course not reading any file.

Cannot be done, since you can get the same compiled program file from an
infinite number of source code inputs.

Since datanames and symbols do not exist in the compiled file, any such
program - often called either a disassembler or decompiler - would have to
make them up, de facto making the generated source code something other than
the original, absent absolutely terrific dumb luck.


MCM

Michael Mattias wrote:
>
> "Sergey Kashyrin" <ska@resqnet.com> wrote in message
> news:D8MSf.55$Th7.117876@news.sisna.com... 
>
> Cannot be done, since you can get the same compiled program file from an
> infinite number of source code inputs.
>
> Since datanames and symbols do not exist in the compiled file, any such
> program - often called either a disassembler or decompiler - would have to
> make them up, de facto making the generated source code something other th
an
> the original, absent absolutely terrific dumb luck.
>
> MCM

Not so.  There's a book called "Etudes for programmers" which presents
this as an "etude" - borrowed from the musical sense of the word.  The
article describing the assignment states that there's a theorem which
proves that this can be done in any language "powerful" enough - and
also that all languages are "powerful" enough.

The only way I could think of to do this was to print a bunch of
literals which duplicated the actual source -  but that leads only into
an ever-regressing loop.  So I don't know how it's done, in Cobol or any
other language.

PL

"Peter Lacey" <lacey@mts.net> wrote in message
news:441C52CC.E102AE63@mts.net...
> Michael Mattias wrote: 
published 
forgot 
it 
to 
than 

If you mean could I create a program which prints its own source code 'from
within' , if it can be a Windows executable I can do that in say, twenty
minutes. You simply make the source code file a program resource and print
it from there:

1. Finish editing source code, save
2. Compile resource file with source code file as a resource
3. Compile executable program file from source code
4. Run linker to embed resource in executable

For an example, go to my web site at http://www.talsystems.com. Click on
"Tech Corner" and download the file "835did.exe" (near the bottom of the
page).  Run this program on a Windows machine. Forget what it's supposed to
do, just click on the "Info" button. The text that comes up is an ordinary
"rich text" document file I embedded in the executable at compile time
(well, technically it would have been at "link" time) .  No reason this file
could not have been the source code file.

I'm not sure if other environments support "program data embedded in the
executable module" but if they do you could apply the same principle.  And
this technique is perforce source-language independent!

Depending on what you mean by "print"  the source code, it would not even
take much code. To just dump the source code to a text file would take me
maybe twenty (20) lines of procedural code. (In either COBOL or BASIC). (ID,
ENVIRONMENT and DATA DIVISIONs as well as Windows header files not
included).

But I thought you meant 'given the executable code in this executable file -
and only the executable code - print the source code."  This cannot be done
for the reasons stated above.

MCM

In article <D8MSf.55$Th7.117876@news.sisna.com>, "Sergey Kashyrin" <ska@resqnet.com> writes
:
> Speaking of languages it's just came to my mind the old "task" published
> relatively long time ago by the American writer (unfortunatly I've forgot
> his name, but actually I can figure out).

You're probably thinking of W. V. Quine.  Such programs are commonly
called "quines".  There are loads of web pages dedicated to quines in
various languages, and to various debates about them (eg whether the
Basic program "1 PRINT" is a legitimate quine).

> The task is to write the program which prints it's own source code (so it
> can be accepted by compiler) but of course not reading any file.

There are COBOL quines on the web, but of course many people enjoy
writing their own.

--
Michael Wojcik                  michael.wojcik@microfocus.com

It wasn't fair; my life was now like everyone else's.  -- Eric Severance

In article <iHUSf.1867$4L1.1293@newssvr11.news.prodigy.com>, "Michael Mattias" <michael.mat
tias@gte.net> writes:
> "Sergey Kashyrin" <ska@resqnet.com> wrote in message
> news:D8MSf.55$Th7.117876@news.sisna.com... 
>
> Cannot be done, since you can get the same compiled program file from an
> infinite number of source code inputs.

I think you misunderstand the nature of the problem.  A quine is not
expected to determine its original source code through some magic
computation; it's supposed to contain a computation that represents
that source code (in a finite manner) such that it can restore it
when executed.  It's entirely possible, many exist, and the fact that
compilation is an information-reducing transformation is no obstacle.

Quines are discussed extensively (more so than they warrant, probably)
on the net.

--
Michael Wojcik                  michael.wojcik@microfocus.com

If Mokona means for us to eat this, I, a gentle person, will become
!  -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_

In article <iHUSf.1867$4L1.1293@newssvr11.news.prodigy.com>,
"Michael Mattias" <michael.mattias@gte.net> wrote:

> "Sergey Kashyrin" <ska@resqnet.com> wrote in message
> news:D8MSf.55$Th7.117876@news.sisna.com... 
>
> Cannot be done, since you can get the same compiled program file from an
> infinite number of source code inputs.
>
> Since datanames and symbols do not exist in the compiled file, any such
> program - often called either a disassembler or decompiler - would have to
> make them up, de facto making the generated source code something other th
an
> the original, absent absolutely terrific dumb luck.
>
>
> MCM

Easy enough on z/OS.  Look in the PPA for the address of the actual
module, find the ADATA records, filter on source records and display
them.

Perhaps a few minutes of code...

Michael Mattias wrote:
>
> "Peter Lacey" <lacey@mts.net> wrote in message
> news:441C52CC.E102AE63@mts.net... 
> published 
> forgot 
> it 

Michael has snipped all that I (Pater Lacey) posted; readers will have
to refer back to my message.  The above lines come from Sergei Kashyrin,
the original poster.
 
> to 
> than 
>
> If you mean could I create a program which prints its own source code 'fro
m
> within' , if it can be a Windows executable I can do that in say, twenty
> minutes. You simply make the source code file a program resource and print
> it from there:
>
> 1. Finish editing source code, save
> 2. Compile resource file with source code file as a resource
> 3. Compile executable program file from source code
> 4. Run linker to embed resource in executable
>

This problem was proposed long before such techniques were available.
But by the
terms of the problem, the "resource" to which you refer must be part of
the original source, not something linked in.  Otherwise the problem is
trivial.


> But I thought you meant 'given the executable code in this executable file
 -
> and only the executable code - print the source code."  This cannot be don
e
> for the reasons stated above.
>
> MCM

That is what I meant.  I did say >>I<< hadn't worked it out!  But see
the posts by Michael Wojcik on the subject of "quines".

PL

Peter Lacey wrote:
> Michael Mattias wrote: 
>
> Not so.  There's a book called "Etudes for programmers" which presents
> this as an "etude" - borrowed from the musical sense of the word.  The
> article describing the assignment states that there's a theorem which
> proves that this can be done in any language "powerful" enough - and
> also that all languages are "powerful" enough.
>
> The only way I could think of to do this was to print a bunch of
> literals which duplicated the actual source -  but that leads only into
> an ever-regressing loop.  So I don't know how it's done, in Cobol or any
> other language.
>
> PL

The trick is to encode the data in some fashion and then decode it at
run-time. This avoids the problem of literals quoting themselves,
quoting themselves......

see http://www.madore.org/~david/computers/quine.html

Often the language chosen to illustrate this is "C" in the context of
an obfuscated programming contest.

While this of course has no real application to the world of business
D.P., it might stimulate the mind of the COBOL programmer to think
about some interesting things:

1. Programs which write other programs.
2. Data tables which are created at run time or unpacked at run time.

-- Elliot

"Joe Zitzelberger" <zberger@knology.net> wrote in message
news:zberger-57A7B5.17450518032006@ispnews.usenetserver.com...
> In article <iHUSf.1867$4L1.1293@newssvr11.news.prodigy.com>,
> "Michael Mattias" <michael.mattias@gte.net> wrote:
>
<snip>
> Easy enough on z/OS.  Look in the PPA for the address of the actual
> module, find the ADATA records, filter on source records and display
> them.
>
> Perhaps a few minutes of code...

Joe,
If you can "decode" ADATA in a few minutes, you are a better programmer than
 I
am <G>.

--
Bill Klein
wmklein <at> ix.netcom.com