mouse@mcgill-vision.UUCP (der Mouse) (08/27/88)
In article <36174@yale-celray.yale.UUCP>, lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes: > In article <20349@watmath.waterloo.edu> atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) writes: >> A classic example are those Pascal programs that allocate 1 large >> static linear array and then run their own memory allocator [...]. > Just a comment on this....this is the typical technique to implement > pointers and dynamic memory handling in Fortran, [...]. Are "those > Pascal programs" maybe translated Fortran programs? I know of at least one which isn't: TeX. Why did Knuth do it this way? I can only guess; I would guess that it's for some portability reason I am not aware of. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dsb@igor.uucp (David S. Bakin) (08/28/88)
In article <1268@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <36174@yale-celray.yale.UUCP>, lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes: >> In article <20349@watmath.waterloo.edu> atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) writes: >>> A classic example are those Pascal programs that allocate 1 large >>> static linear array and then run their own memory allocator [...]. >> Just a comment on this....this is the typical technique to implement >> pointers and dynamic memory handling in Fortran, [...]. Are "those >> Pascal programs" maybe translated Fortran programs? > >I know of at least one which isn't: TeX. > >Why did Knuth do it this way? I can only guess; I would guess that >it's for some portability reason I am not aware of. TeX is written in a subset of Pascal that doesn't include 'with' statements, any use of the heap, set types, enumerated scalar types, 'var' parameters, tag fields on variant records, assignments real := integer, or nested procedure declarations. It is nearly character-set independent, and goes to great lengths to use only portable constructs for exact arithmetic. The goal was to make it as easy to port as possible to the various brain-damaged Pascal compilers that existed at the time; in fact it is now automatically translated into C, and possibly other languages as well. -- Dave ---------------------------------------------------------- Dave Bakin (408) 496-3600 c/o Rational; 3320 Scott Blvd.; Santa Clara, CA 95054-3197 Internet: dsb@rational.com Uucp: ...!uunet!igor!dsb
henry@utzoo.uucp (Henry Spencer) (08/28/88)
In article <1268@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >I know of at least one which isn't: TeX. > >Why did Knuth do it this way? I can only guess; I would guess that >it's for some portability reason I am not aware of. Well, a friend of mine who visited there in TeX's early days said, "those people know *nothing* about portability". Undoubtedly they've learned since, but don't overlook the possibility that this is a historical relic rather than something done after knowledgeable consideration of the alternatives. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
schwartz@gondor.cs.psu.edu (Scott Schwartz) (08/29/88)
In article <1268@mcgill-vision.UUCP> der Mouse writes: >In article <36174@yale-celray.yale.UUCP> Bjorn Lisper writes: >> Are "those >> Pascal programs" maybe translated Fortran programs? > >I know of at least one which isn't: TeX. > >Why did Knuth do it this way? I can only guess; I would guess that >it's for some portability reason I am not aware of. From tex.web: @* \[4] String handling. Control sequence names and diagnostic messages are variable-length strings of seven-bit characters. Since \PASCAL\ does not have a well-developed string mechanism, \TeX\ does all of its string processing by homegrown methods. Elaborate facilities for dynamic strings are not needed, so all of the necessary operations can be handled with a simple data structure. -- Scott Schwartz schwartz@gondor.cs.psu.edu schwartz@psuvaxg.bitnet
drc@claris.UUCP (Dennis Cohen) (08/29/88)
In article <3868@psuvax1.cs.psu.edu> schwartz@gondor.cs.psu.edu (Scott Schwartz) writes: >In article <1268@mcgill-vision.UUCP> der Mouse writes: >>I know of at least one which isn't: TeX. >> >>Why did Knuth do it this way? I can only guess; I would guess that >>it's for some portability reason I am not aware of. Wasn't TeX originally written is SAIL? I seem to remember some reference to it in the Pascal sources that I saw many years ago at JPL (gads, that seems like a lifetime ago -- working on Univac 1100s, IBM 3032s, ModComps and VAXen). Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_!
iwm@asun3.ic.ac.uk (Ian Moor) (08/30/88)
>I know of at least one which isn't: TeX. > >Why did Knuth do it this way? I can only guess; I would guess that >it's for some portability reason I am not aware of. At least one early Pascal compiler did not implement `dispose', instead there were `mark' and `free' which treated the heap like a stack, `free' released all the heap that was claimed since the last mark. If your program doesn't use store in a LIFO way then you had to do your own allocation.
rminnich@super.ORG (Ronald G Minnich) (09/01/88)
In article <IWM.88Aug30095804@asun3.ic.ac.uk> iwm@asun3.ic.ac.uk (Ian Moor) writes: >At least one early Pascal compiler did not implement `dispose', >instead there were `mark' and `free' which treated the heap like a stack, ah, pascal. So portable, except everybody had a slightly different IO system, esp. with the interpretation of eol and eof. (berkeley pascal will still kill you if you test eol when eof is true). And, of course, everybody did one of 2 1/2 storage system types, so that you did not use any dynamic storage if you wanted your program to be portable. Gosh, brings back the good ol' days doesn't it? There are lots of little holes like that in Pascal, which may explain the coding style of TeX. Within limits- no I/O, no dynamic memory, etc.- a real portable language. ron