HDTenEightyP/NetNews huggingface dataset:
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: function name as an argument
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Mon, 14 Dec 1992 15:03:47 GMT


In article <ADK.92Dec12114449@ds2.sun13.SCRI.FSU.EDU>, 
adk@sun13.SCRI.FSU.EDU (Tony Kennedy) writes:
|>>> J. Giles <jlg@cochiti.lanl.gov> and
|>>> Steve Lionel <lionel@quark.enet.dec.com> write:
|>
|>   lionel> PROGRAM DUMB
|>   lionel> character*10 func,arg
|>   lionel> external func
|>   lionel> call sub(func,arg)
|>   lionel> end
|>
|>   lionel> SUBROUTINE SUB (func,arg)
|>   lionel> character*(*) func,arg       
|>   lionel> arg = func()
|>   lionel> write(*,*)arg
|>   lionel> END
|>
|>   lionel> FUNCTION FUNC()
|>   lionel> character*(*) func
|>   lionel> func = 'abcdefghijklmnopqrstuvwxyz'
|>   lionel> END
|>
|>   lionel> How does SUB know how much to allocate for the function result
|>   lionel> of SUB?  This isn't known at compile time, so the length has to
|>   lionel> be passed in to SUB somehow so that SUB can allocate the space
|>   lionel> at run-time.
|>
|>   jlg> Nope, the space can be allocated statically when PROGRAM DUMB
|>   jlg> is compiled! The descriptor passed to SUB can contain the
|>   jlg> length of the space which has been allocated and a reference
|>   jlg> to that memory.  This is the same information that needs to
|>   jlg> be passed if FUNC were called *directly* by the main program.
|>
|>This is not possible because the three routines can be compiled separately.
|>

Absolutely true.  But even if you compiled all the routines together, what if
you added another caller of SUB which passed FUNC declared as a different
length?  Unless you additionally require procedure inlining, there is no way
that SUB can know which routine called it and which length to statically
allocate.  This is why the standard requires the length of a character
function to be declared as an integer constant expression in the program
unit which calls the function.  And this is why an implementation (such as
VAX FORTRAN), which does allow the (*) in the referencing unit, passes the
length along with the routine address, so that it may do run-time allocation
for the function result.
--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.lang.fortran
From: michael@chpc.utexas.edu (Michael Lemke)
Subject: Re: function name as an argument
Organization: The University of Texas System - CHPC
Date: Tue, 15 Dec 92 06:17:43 GMT

In article <1gj95eINNqgo@gap.caltech.edu> shepard@sampson.ccsf.caltech.edu (Ron Shepard) writes:
>I believe that the following is standard f77.  

	I don't think so -- see below.

>Note that the character
>function is declared as (*) in the main program, and is declared, and
>called, with different *(CONSTANT) values from the two subroutines.
>
>It is apparently because of the requirement of *(CONSTANT) declaration
>in the referencing subprogram that this can be done legally without
>recourse to runtime memory allocation.
>
>      program dumb
>      character*30 cvar
>      character*(*) cfun
>      external cfun
>      cvar='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
>      call sub1( cvar, cfun )
>      write(*,*) 'cvar=', cvar
>      call sub2( cvar, cfun )
>      write(*,*) 'cvar=', cvar
>      stop
>      end
>
>      subroutine sub1( cvar, cfun )
>      character*10 cvar
>      character*10 cfun
>c     # cfun() returns a 10-character value here.
>      cvar = cfun()
>      return
>      end
>
>      subroutine sub2( cvar, cfun )
>      character*20 cvar
>      character*20 cfun
>c     # cfun() returns a 20-character value here.
>      cvar = cfun()
>      return
>      end
>
>      function cfun
>      character*(*) cfun
>c     # assign a 30-character value, truncating as necessary.
>      cfun = '123456789012345678901234567890'
>      return
>      end
>
>Upon execution on a couple of machines, I get:
>
>cvar=1234567890xxxxxxxxxxxxxxxxxxxx
>cvar=12345678901234567890xxxxxxxxxx
>
>which is what I thought I should get according to the previous discussion
>in this thread.  
>
>Are there any machines that give different results?

	Yes, VAX/VMS:

$ for x
%FORT-F-ADJLENUSE, Passed length character name used in invalid context 
 	[CFUN] in module DUMB 
%FORT-F-ENDNOOBJ, IO$DUC0:[MICHAEL]X.FOR;2 completed with 1 diagnostic - object 
deleted

So what junky Fortran took this?

Michael
-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.fortran
Subject: Re: Real Programmers
Date: 13 Dec 92 16:23:43 GMT
Organization: CWI, Amsterdam

In article <DODD.92Dec13064112@mycenae.cchem.berkeley.edu> dodd@roebling.poly.edu writes:
 > >>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:
Toon> The problem is not so much with the outdated hardware (spacecraft,  
Toon> microcomputers) alluded to, as with the target itself: FORTRAN as of 1991
Toon> is a language with semicolons ;-)
 > 
 > But it is still column based! And as RP says: "but every one of them
 > [compilers] has a way of converting itself back into a FORTRAN 66 compiler at
 > the drop of an option card -- to compile DO loops like God meant them to be."
 > 
 > (it doesn't really have semi-colons -- does it?)

Yes, it has.  Also it is no longer column based.  It starts to resemble
program languages of about 1965.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: v096my2q@ubvmsd.cc.buffalo.edu (ZORBA THE GEEK)
Newsgroups: comp.lang.fortran
Subject: VAX to UNIX (integer*2, *4)
Keywords: vax integers
Date: 11 Dec 92 20:43:00 GMT
Organization: University at Buffalo
News-Software: VAX/VMS VNEWS 1.41

I'm having some problems reading a binary data file that was originally
written on the vax, on the unix machine. The data consists of 2 and 4 byte 
integers. I assume that the problem is arising because vax and unix store 
these number differently. Does anyone have a subroutine that will convert
vax integer*2 and integer*4 to unix format? Thanks


Mark Wieczorek  
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: function name as an argument
Organization: Los Alamos National Laboratory
Date: Mon, 14 Dec 1992 19:36:34 GMT

In article <ADK.92Dec12114449@ds2.sun13.SCRI.FSU.EDU>, adk@sun13.SCRI.FSU.EDU (Tony Kennedy) writes:
|> >> J. Giles <jlg@cochiti.lanl.gov> and
|> >> Steve Lionel <lionel@quark.enet.dec.com> write:
|> 
|>    lionel> PROGRAM DUMB
|>    lionel> character*10 func,arg
|>    lionel> external func
|>    lionel> call sub(func,arg)
|>    lionel> end
|> 
|>    lionel> SUBROUTINE SUB (func,arg)
|>    lionel> character*(*) func,arg       
|>    lionel> arg = func()
|>    lionel> write(*,*)arg
|>    lionel> END
|> 
|>    lionel> FUNCTION FUNC()
|>    lionel> character*(*) func
|>    lionel> func = 'abcdefghijklmnopqrstuvwxyz'
|>    lionel> END
|> 
|> [...]
|> 
|>    jlg> Nope, the space can be allocated statically when PROGRAM DUMB
|>    jlg> is compiled! The descriptor passed to SUB can contain the
|>    jlg> length of the space which has been allocated and a reference
|>    jlg> to that memory.  This is the same information that needs to
|>    jlg> be passed if FUNC were called *directly* by the main program.
|> 
|> This is not possible because the three routines can be compiled separately.

It doesn't *matter* that they are compiled separately!  The memory is
allocated at compile time.  It is allocated when the *main* program
is compiled.  The compiler needn't know or care what the size is
or where the memory was allocated when compiling the subroutines.
While compiling the subroutines, the compiler simply generates code
which expects the main routine to *pass* this information implicitly
in the calling sequence.  This is exactly what it always does for
character *variables*, why should it do any different for character
*functions*?  Where variables are concerned, this is exactly what the
"CHARACTER*(*)" notation was designed to do.

Once again: there is no need to rely on dynamic memory to provide
the above functionality.  However, it appears that there *is* a
constraint in the Fortran 77 standard which prohibits it.  I don't
know why and neither does our representative to the committee.

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Subject: Re: Dynamic Memory Allocation in FORTRAN, Question
Reply-To: ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi)
Organization: MRL - UIUC
Date: Mon, 21 Dec 1992 02:41:57 GMT

In article <1992Dec20.233539.4905@sol.ctr.columbia.edu>, shenkin@still3.chem.columbia.edu (Peter
Shenkin) writes:
|>In article <Dec.20.02.22.20.1992.7312@spade.rutgers.edu>
|> xiong@spade.rutgers.edu (Xiong) writes:
|>>Hi, I am wondering if it is possible to allocate memory dynomically in
|>>FORTRAN as in C? 
|>
|>No.

We are a bit negative, aren't we?  :-)

Well, if you stick to the FORTRAN standard the answer is no
[of course, Fortran is another story].
But there might be vendor extensions that may allow dynamic
or almost-dynamic arrays.  One of them is the AUTOMATIC
declaration, that is quite popular on RISC architectures
(e.g., SGI, IBM RS/6000, DEC MIPS).  Storage space for variables 
declared to be AUTOMATIC in a certain subroutine is created
when the subroutine is entered, and deleted upon exit.
So it's not as flexible as in C, in the sense that the lifetime
of the variable must coincide with the subroutine execution,
and the variable size must be known at compile time.
Still, if your purpose is to avoid wasting memory, it does
the job nicely.  

There may be other schemes implemented by other vendors,
and one can also attempt a mixed language implementation but
this goes beyond the original question. 
--
Furio Ercolessi
Materials Research Laboratory           |   Intl School for Advanced Studies
Univ. of Illinois at Urbana-Champaign   |   Trieste, Italy
furio@uiuc.edu                          |   furio@sissa.it
Newsgroups: comp.lang.fortran
From: fsset@bach.lerc.nasa.gov (Scott Townsend)
Subject: Re: Uglifier (was Re: Real Programmers)
Keywords: n
Organization: NASA Lewis Research Center [Cleveland, Ohio]
Date: Wed, 16 Dec 1992 13:59:15 GMT

In article <BzC6n8.J2G@news.cso.uiuc.edu> ercolessi@uimrl3.mrl.uiuc.edu (furio ercolessi) writes:

>Hmmm ...
>did any one ever made a source code uglifier, a filter removing
>all comments, renaming all variables as A1,A2,... (*),  removing all
>extra spaces, replacing character constants with Holleriths, etc?
>It could be a useful tool after all!  Sometimes you do not want to
>give away your sources, you would like to give only the binaries
>but that's impractical ... this would be a brilliant intermediate 
>solution, give uglified code!  :-)

I heard a rumor years ago that the Government and a Contractor didn't agree
on wether source to a particular program was a contract deliverable.  Unable
to get the Government to change its view, the Contractor converted all
variable names, labels, etc to use combinations of '0', '1', 'O' and 'I'.

Satisfied the lawyers I suppose.



-- 
Scott Townsend,  Sverdrup Technology Inc.  NASA Lewis Research Center Group
fsset@bach.lerc.nasa.gov
Newsgroups: comp.lang.fortran
From: fairfield@slacvx.slac.stanford.edu
Subject: Re: How common are long variable names?
Organization: Stanford Linear Accelerator Center
Date: Sat, 12 Dec 1992 01:47:22 GMT

In article <1992Dec11.221459.10841@sol.UVic.CA>, klassen@sol.UVic.CA (Melvin Klassen) writes:
> Dr. Kenneth H. Fairfield <fairfield@slacvx.SLAC.Stanford.EDU> writes:
>>    Hurray for IBM's VS Fortran!!!  31-character identifiers allowed,
>>but if you should be so bold as to use an identifier > 7 characters long
>>for a global symbol (i.e., SUBROUTINE, FUNCTION, ENTRY, BLOCK DATA, or
>>COMMON block name), it takes the first 4 characters and concatenates
>>them with the last 3 characters of the (long) identifier to generate the
>>external name.  Think about the following (generic) utilities:
>>
>>		SUBROUTINE UTL_GET_DATA
>>		SUBROUTINE UTL_PUT_DATA
>>		SUBROUTINE UTL_CLEAR_DATA
> 
> If you CALL more than one of these routines from a single program-unit,
> the compiler reports the error-message:
>    ILX1454I  Two or more external symbols are not unique.
>              Check the "external symbol report".
> 
> The ICA (InterCompilation Analyzer) reports the diagnostic:
>    ILX0067I  Conflicting name usage -- the name, UTL_ATA has been used
>              as the name of a subroutine in UTL_ATA (compilation 2) and
>              as the name of a subroutine in UTL_ATA (compilation 3).
> 
> The compiler is doing as best as it can!
> It's the IBM linker/loader which is the bottle-neck,
> due to the restriction to 8-character external names,
> so don't blame the IBM FORTRAN-development group
> for a problem which they have no authority to fix!

    Well, I _didn't_ "name names", you did ;-)  I didn't say "the IBM 
FORTRAN-development group" stinks because of this kluge, I said, in
effect, "look what happens" if you use long names with VS FORTRAN.  And
it's not just the linker/loader people, it goes all the way down to the
file system in some cases...

    My posting was in sympathy to J. Giles' (?) remark about compilers
which _accept_ long names but, in essence, don't _support_ them.  Yes, at
least IBM is flagging the possible conflict...  My personal opinion is
that it would be better for them to say, "We support long variable names,
but externals still need to be limited to 7 characters".  That would be 
clear; the other lays a trap for the unwary.

    	-Ken
-- 
 Dr. Kenneth H. Fairfield    |  Internet: Fairfield@Slac.Stanford.Edu
 SLAC, P.O.Box 4349, MS 98   |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309        |  BITNET    Fairfield@Slacvx
 ----------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Newsgroups: comp.lang.fortran
From: klassen@sol.UVic.CA (Melvin Klassen)
Subject: Re: How common are long variable names?
Organization: University of Victoria, Victoria, B.C. CANADA
Date: Fri, 11 Dec 92 22:14:59 GMT

Dr. Kenneth H. Fairfield <fairfield@slacvx.SLAC.Stanford.EDU> writes:
>    Hurray for IBM's VS Fortran!!!  31-character identifiers allowed,
>but if you should be so bold as to use an identifier > 7 characters long
>for a global symbol (i.e., SUBROUTINE, FUNCTION, ENTRY, BLOCK DATA, or
>COMMON block name), it takes the first 4 characters and concatenates
>them with the last 3 characters of the (long) identifier to generate the
>external name.  Think about the following (generic) utilities:
>
>		SUBROUTINE UTL_GET_DATA
>		SUBROUTINE UTL_PUT_DATA
>		SUBROUTINE UTL_CLEAR_DATA

If you CALL more than one of these routines from a single program-unit,
the compiler reports the error-message:
   ILX1454I  Two or more external symbols are not unique.
             Check the "external symbol report".

The ICA (InterCompilation Analyzer) reports the diagnostic:
   ILX0067I  Conflicting name usage -- the name, UTL_ATA has been used
             as the name of a subroutine in UTL_ATA (compilation 2) and
             as the name of a subroutine in UTL_ATA (compilation 3).

The compiler is doing as best as it can!
It's the IBM linker/loader which is the bottle-neck,
due to the restriction to 8-character external names,
so don't blame the IBM FORTRAN-development group
for a problem which they have no authority to fix!
Newsgroups: comp.lang.fortran
From: jumper@fritz.catt.ncsu.edu (Michael Lanham)
Subject: How Do I produce a map file
Organization: North Carolina State University
Distribution: comp
Date: Thu, 17 Dec 1992 17:48:17 GMT

After searching through the man pages I cannot find the needed material.

I want to produce a file that gives me the addresses of the variables used in
the program. Specifically the various common blocks.  I am using a DECstation
with Ultrix 4.3.  Help would be appreicated.


He who will not reason, is a bigot; he who cannot is a fool;
and he who dares not is a slave.      --- Sir William Drummond

Michael Lanham       mjlanham@eos.ncsu.edu   &  jumper@catt.ncsu.edu
Newsgroups: comp.lang.fortran
From: b259phl@utarlg.uta.edu (PHILIP LIPPEL)
Subject: Re: Real Programmers
News-Software: VAX/VMS VNEWS 1.41    
Organization: The University of Texas at Arlington
Date: Wed, 16 Dec 1992 01:36:00 GMT


> 5. Best language to use on an IBM-1620 CADET (Can't add, doesn't even try).
> 
> 4. Rigid field format goes hand-in-hand with model 29 keypunch program drum.
> 
REAL Real Programmers only use 026s. Those are the keypunches without the
equals signs ( and a few other "useful" keys). A compiler switch enables the
appropriate translation-- I think it was & for = on the machine upon which I
 first  learned FORTRAN. The advantages should be obvious.
Newsgroups: comp.lang.fortran
From: panoff@doppler.ncsc.org (Robert M. Panoff)
Subject: Fortran for a Mac IIci
Organization: North Carolina Supercomputing Center
Date: Tue, 15 Dec 1992 15:35:42 GMT


It's time for my nearly annual request for input: I need suggestions,
anecdotal comments, empirical benchmarks and whatever other supporting
documentation you care to share that would help me advise someone on
the best (you define best...) Fortran compiler for a Mac.  Please
include cost information if you have it.  Please send all replies
to me directly, and I will post a summary.  Thanks in advance.

Bob Panoff
panoff@ncsc.org
From: shepard@sampson.ccsf.caltech.edu (Ron Shepard)
Newsgroups: comp.lang.fortran
Subject: Re: SUMMARY: CHARACTER FUNCTION as dummy argument
Date: 15 Dec 1992 18:44:33 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sampson.ccsf.caltech.edu


>      program dumb
>      character*30 cvar
>      character*(*) cfun
>      external cfun
>      cvar='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
>      call sub1( cvar, cfun )
>      write(*,*) 'cvar=', cvar
>      call sub2( cvar, cfun )
>      write(*,*) 'cvar=', cvar
>      stop
>      end
> [Lines Deleted]

The above declaration (and the code; see previous entries in this
thread) works alright on a Sun and on an Alliant.  It DOESN'T work
on a Cray and on a Stardent Titan (and apparently on VAX/VMS
according to one poster).

Two Questions:

1) Is the above legal f77?  (Please cite the standard if possible)

   My previous posting that it could be legal was based on page 8-6
   lines 40-45 which states (somewhat obscurely):
   "An entity declared in a CHARACTER statement must have a length
   specification that is an integer constant expression, unless that
                                                         ^^^^^^^^^^^
   entity is an external function, a dummy argument of an external
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   procedure, or a character constant that has a symbolic name."

2) If it is standard, then on which machines does it not work?

-Ron Shepard
shepard@tcg.anl.gov
Newsgroups: comp.lang.fortran
From: shenkin@still3.chem.columbia.edu (Peter Shenkin)
Subject: Re: Reinventing WRITE...
Organization: Dept. of Chem, Columbia U, New York
Date: Wed, 16 Dec 1992 20:20:30 GMT
X-Posted-From: still3.chem.columbia.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

This followup addresses the question of line-buffering Fortran output
under UNIX.

In article <29011.9212161323@thor.cf.ac.uk>
 spxsjm@thor.cf.ac.uk (Mr S J Morris 92) writes:
>   I want to define a subroutine which will take the same input paramters
>   as a WRITE procedure; that is, I'd like to define
>
>	 SUBROUTINE WRITELN(A,B)
>
>   in such a way that
>
>	 WRITELN (7,100) X,Y
>	 WRITELN (6,*) 'HELLO THERE'
>	 WRITELN (*,*) 'HE''S GETTING CLEVER NOW'
>
>   all work more or less the same as the corresponding WRITE statements (by
>   the way, the reason I'm doing this is to open a file, find the endfile
>   record, append a new record and then close the file again, all in a
>   single call - so that I can flush the output buffer in SUN Fortran)...

This is both machine-dependent and incomplete, but under UNIX, Fortran IO-unit
6 is almost always bound to the standard output.  So if unit 6 is all you
really care about, you can write a little C program callable from Fortran;
you call this routine just before you OPEN the file, and have this C program 
call setvbuf() for the standard output using the right arguments to line-buffer
the output.  This fragment (reasonably portable in the UNIX world, I
believe) reads:

#include <stdio.h
...
	setvbuf( stdout, NULL, _IOLBF, BUFSIZ );

Is there any way to figure out what UNIX file-pointer an arbitrary Fortran
io unit is associated with?  If so, this trick could be used for arbitrary
files.

	-P.

-- 
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************
Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
New York, NY  10027;  shenkin@still3.chem.columbia.edu;  (212) 854-5143
******* ...ghostlier demarcations, keener sounds.  (Wallace Stevens) ********
From: poynor@david.wheaton.edu (George V. Poynor)
Newsgroups: comp.lang.fortran
Subject: Re: Looking for random-number generator
Keywords: Random
Date: 15 Dec 92 21:23:15 GMT
Organization: Wheaton College, IL

In article <tregilli.724351639@msi.umn.edu> tregilli@s21.msi.umn.edu (Ian Lee Tregillis [Astro]) writes:
>Greetings, 
>
>	I'm not a regular reader of this group, 
>but I did look in the FAQ before deciding to post
>my request:
>
>	I'm looking for a decent random-number 
>generator in Fortran. (By 'decent' I mean one 
>where a pseudo-random sequence won't repeat 
>before at least 1000 samples.)  This is probably

	This wouldn't be a random number 
	generator, would it?  A sequence
	is (pseudo-)random if over the
	length of the sequence the distribution
	of values approaches a uniform
	distribution.
	--
	geo...


>something that real programmers learn to do before
>age 10, but I'm obviously nothing of the sort.
>Anyway, I'd appreciate it if anyone could give
>me a hint or tell me where to look.
>
>	Please respond by email to:
>	tregilli@s1.msi.umn.edu
>		or
>	treg0001@student.tc.umn.edu
>
>Many thanks in advance,
>	Ian "Magnetic Moment" Tregillis
>	Physics and Mathematics undergrad, U of MN, TC


-- 
George V. Poynor
--
poynor@david.wheaton.edu
Xref: sparky comp.lang.fortran:4752 comp.lang.c++:18046 comp.lang.c:18454
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.fortran,comp.lang.c++,comp.lang.c
Subject: Re: Examples in Documentation
Date: 16 Dec 92 09:09:00 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1gdm89INN6bj@gazette.bcm.tmc.edu>, rick@crick.ssctr.bcm.tmc.edu (Richard H. Miller) writes:

[A bunch of stuff, most of which I agree with, but...]

> One other point, electronic documentation is great for reference
> manuals but there will always be a need to paper manuals especially
> when one is developing some of these more complicated things. It is
> easier to have that manual open and be able to flip it depending on
> how things do, It is also useful to have the manual at the side or on
> your lap rather than have to switch screens to look at the manual and
> back to look at your code.

Speak for yourself.  I much prefer online text for reference, because I
don't have to look away from the screen, don't have to try to keep five
different places at once in a paper document, etc, and most especially
can snarf-&-barf examples or declarations or sometimes even running
text from the docs into what I'm working on.  (If the online
documentation is in a form that makes this impossible, such as
PostScript that I have to run GhostScript to look at, it is at best
marginally better and often significantly worse than paper.)

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.lang.fortran