Alfred M. Szmidt wrote: > I wouldn't call troff/latex files for `program source. They all spit > out a static file, one could compare it to a file with values in it, > that you give to a program, which then spits out a fractal image. Is > the file with the values, just numbers, source code? Or even a > program? Of course not.
It's not obvious at all. If the program that you give the file to is an interpreter (compiler / byte code machine / emulator), and the values are source code in the interpreted language (source code in the compiled language or intermediate code produced by a previous compilation step / byte code / machine code of the emulated machine), if necessary encoded in some numeric form (just to satisfy your "just numbers" condition, which is rather meaningless as everything on a digital computer can be written as numbers), then yes, the file is a program. -- To most of us, who include source code in the definition of programs, in all of the cases, and to you who only seem consider machine code as programs, at least in the case of an emulated machine. Or do you claim that whether the content of a file *is* a program depends on whether it's being run on a native machine or on an emulator? (If so, what is it while it's not being run?) > A LaTeX/groff file is more akin to a very > long parameter list (this is stretching it a bit, but that is what it > kinda is) I don't know groff very well, but for (La)TeX this isn't true. (La)TeX provides a Turing-complete language, so (La)TeX files can be programs. Probably the majority of existing (La)TeX files are not "really" programs (or rather, trivial programs, comparable to a C program consisting only of a series of printf's) if you don't count the included packages, but it's certainly possible to write programs in (La)TeX. The same holds for PostScript, unlike PDF, BTW. A rather easy way to find out (for practical purposes -- the formal definition can be found in the literature) is to ask the question whether you can, e.g., compute digits of pi or some well-known fractal in a language, *without* writing down the result. (An indication is, if you keep increasing the number of digits or the resolution of the fractal, does the "program" size grow or remain the same.) E.g., in non-programmable languages such as HTML (without JavaScript or other extensions) the only ways to "display" a fractal are things like including it as an external image, or ASCII art, or use of tables -- all of which have to grow to display larger versions. In contrast, in (La)TeX and PostScript you can implement the fractal algorithms, so you can output the fractal at higher resolutions by just changing a parameter. (FWIW, I programmed some fractals in PS myself. The PS files are very small -- below 1 KB for several fractals, independent of output resolution. When I converted them to PDF for fun, the PDF size exploded as I increased resolution -- quickly approaching 100 MB before I stopped. That's because PDF is basically PS minus the programming language -- the primitives (graphics etc.) are mostly the same, so the difference is quite clearly shown in this comparison.) Simo wrote: > To me what differentiate a program from a document is that a program can > handle inputs, while, generally, documents should not. I don't think this distinction is very useful. On the one hand, as you say: > Said that I know > there a re documents that can change and take inputs, so it really does > not make any sense to draw a clear line, the line moves on a case per > case base. (Even serial letters take inputs.) On the other hand, programs do not have to take inputs. Though you could say that a program without input always gives the same result (if you exclude randomness, by defining it as some kind of input, which seems reasonable), I don't agree to equating a program with its output. As an example, consider a program that repeatedly inputs a natural number n and outputs the n'th digit of pi. It takes input, so it would be a program, according to that definition. Now if you replace the input statement by a statement counting up n, so the program outputs all digits of pi in succession (until aborted), it wouldn't be a program anymore -- though the actual code is the same, except for a trivial modification!? Or even more extreme, what about an automated test suite (say for a compiler, so the individual tests are written in the compiler's source language, and there is some kind of test framework). As it takes no input (given a fixed compiler version), and always outputs "OK", neither part of it would be a program according to that definition. No, I don't think that's a useful definition. The established definitions in CS of computability, Turing completeness etc. seem more useful. Though actually this all misses the point. When someone claims that programs and non-programs need different kinds of freedoms, then it's up to him to support this claim. From such an argument it could be seen show which properties of programs are actually relevant to the argument. Up to now, we've only seen that "it's functional" is not the relevant property (as documentation is functional, even according to the FDL), so the rest seems to be pointless arguing about irrelevant definitions so far. Frank -- Frank Heckenbach, [EMAIL PROTECTED] http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E) _______________________________________________ Discussion mailing list [email protected] https://mail.fsfeurope.org/mailman/listinfo/discussion
