HDTenEightyP/NetNews huggingface dataset:
From: ak45ldp@Texaco.com (Larry D. Pyeatt)
Subject: Re: Is Modula-2 dead?
Organization: Texaco
Date: Fri, 28 Aug 1992 12:50:29 GMT

In article <36848@uflorida.cis.ufl.edu>, bmr@retiree.cis.ufl.edu (Benedict Rafanello) writes:

(stuff deleted)

|> 
|> After talking to Stony Brook Software and Multiscope, I found out that the
|> Multiscope debuggers are written in Modula-2 (using a compiler written by
|> Stony Brook and now sold as Multiscope Modula-2 V4.0).  I also talked to 
|> JPI and was told that their entire product line, except for the C and C++
|> libraries, is written in Modula-2, including their Dos extender.  Also, in
|> BYTE there was an interview with the president of JPI who said that in
|> Europe Modula-2 outsells C by a margin of 2 to 1.  Several
|> of the national laboratories  and NASA use Modula-2 and their was even an
|> article about what they were doing with Modula-2 in Dr. Dobb's Journal.
|> 
|> Modula-2 isn't dead yet, and looks to be doing well in Europe.  Maybe this
|> country will wake up and the "C" craze the will pass. :)
|> 
|> Ben


Don't count on it, Ben.  For some reason, most Americans have a dislike for "good"
programming languages.  If only Wirth had been an American...

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.
Newsgroups: comp.lang.modula2
From: jpussi@cs.joensuu.fi (Jarmo Pussinen)
Subject: Oberon question
Keywords: Oberon, pointers, NEW
Organization: University of Joensuu
Date: Tue, 1 Sep 1992 08:20:31 GMT

In some paper I read that in Oberon, all pointer variables are
initialised to NIL. Now I would like to know if this means that
also pointer fields in dynamically (with NEW) allocated records
or in static records are initialised to NIL. 

In short are pointers always either NIL or valid pointers and
not garbage pointers. May it vary between implementations?

Thanks for your time.
jpussi@cs.joensuu.fi
From: munk@prl.philips.nl (Harm Munk)
Subject: Re: m2 for scientific computation
Organization: Philips Research Laboratories Eindhoven, Netherlands
Date: Wed, 26 Aug 1992 11:29:17 GMT

ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:

>I think Modula-2 still has a good chance to replace FORTRAN as the
>primary language for scientific computing. It has FOR - loops which are
>as easily vectorizable or paralellizable as F-77 DO - loops (unlike C's
>half - baked for loops), will have COMPLEX (last time I checked a draft
>standard, anyway), its typechecking is better than either, etc. Ada, 
>F-90 and C++ suffer from too much complexity.

Scientists are hardly interested in the language they use
for implementing their algorithms, save the mathematicians and information
scientists. The language must be able to express the things they want to express,
the Nag lib should be available in it, and everybody else should be using it.
Furthermore, they tend to concentrate on the problem, not on the language.
I have some firsthand experience: I studied physics at Eindhoven University of
Technology. We used Burroughs Extended Algol to do our number crunching, and
we loved it. It's not as expressive as Pascal or Modula 2, but it worked.
However, the Dutch Government, which subsidises education to a large part, decided
in their infinite wisdom that all universities should go IBM and DEC. So out went
our B7900 and BEA, and in came Big Blue and FORTRAN: yes, they made a switch from
an Algol-like language to FORTRAN. Why not, you have Nag (we had that in BEA as well,
but OK), and the rest of the world uses it. Glad I had graduated by then.

>It would be a real shame to leave the field of scientific computation to
>FORTRAN or C.

I agree, but that's reality.

+----------------------------------------+------------------------------------+
| Harm Munk                              | Building WAY 11                    |
| Philips Research Laboratories          | P.O. Box 80 000                    |
| Knowledge Based Systems                | 5600 JA  Eindhoven                 |
|                                        | The Netherlands                    |
| #include <standard.disclaimer>         | tel. +31 40 74 46 59               |
|                                        | email: munk@prl.philips.nl         |
+----------------------------------------+------------------------------------+
Newsgroups: comp.lang.modula2
From: tchannon@black.demon.co.uk (Tim Channon)
Subject: Re^2: Is Modula-2 dead? 
Distribution: world
Organization: null
Date: Sat, 29 Aug 1992 01:05:27 +0000

>Answer: There is currently *no* interest in Oberon[-2] from industry. 
>Only Universities, research institutes
>and recreational programmers (hobbiest) show some interest in Oberon.
>

Let's take a simile: you decide to start manufacture of a new automobile in 
direct competition with Ford (chosen at random). You want to take at least as 
big a market share.

How would this be done and what would the product have to offer?

We have plenty of instances of this sort of thing in the UK where however 
excellent the product it just does not displace the brand leader.

A good instance was the sad failure of Philips V2000 video recorders to kill 
VHS, notwithstanding much superior technical performance -- better definition, 
perfect stills, very much longer playtime. Technical excellence counts for 
little which is sad.

Now, if we take a massively successful real world product: Borland C++, what 
would we have to do?

I contend that the product has to offer a _massive_ something which real users 
want and to quote a horrible phrase "want bad".

Really there is very little which C++ or Modula have in the way of difference 
except the ability to be lazy and the coding environment in the case of market 
leader.

Do you seriously expect a C programer to forsake printf() for some verbose 
other set of procedures?
The programmer doesn't want to worry about types right now, sorry, you must.

Perhaps if someone produces a Modula with a much better environment than 
Borland, much better functionality including full Windows programming support, 
excellent debugging, a considerable execution speed improvement, much smaller 
code sizes, etc. etc. and you wonder why it doesn't happen?

Why isn't Modula interactive? I realise this is an implementation issue but it 
could be demanded by a standard.

The next step may be graphical programming and this is almost upon us.

  TC. 
    E-mail: tchannon@black.demon.co.uk or tchannon@cix.compulink.co.uk
                                
Newsgroups: comp.lang.modula2
From: fellows@jupiter.sun.csd.unb.ca (David M. Fellows CS)
Subject: Re: FST is alive and well
Organization: University of New Brunswick
Date: Thu, 3 Sep 1992 14:19:54 GMT

In article <DZABEL.92Sep3122216@pc2.cs.tu-berlin.de> dzabel@cs.tu-berlin.de (Dirk Zabel) writes:
>
>But the ONE enhancement which would make the difference between a
>nice toy and a serious tool seems still to be missing: code & data 
>space > 64 K FOR EACH SINGLE MODULE. While this may not be a problem
>if you develop new code (at least not the 64 K maximum code size per
>module), it becomes nearly impossible to port existing software from
>unix (writtten using the Mocka compiler, in my case) which does not
>suffer from these restrictions!
>
Anyone using any system to produce modules with a *code* size >64K
per module should take a very critical look at their program's 
modularity.  Data size is a different matter.

>In the meantime: Is there any other Modula-Compiler for MS-DOS (may
>well require a 386) which does not not have those infamous 64 K -
>limits? I don't have experiences with Topspeed or Logitech, but have
>been told they are not better in this respect.
>
Stony Brook's Optimizing compiler supports the following memory models:
Code:
	Small -	Combined code of all modules <64k
	Large - Each Module <64k; total is limited only by available
		memory.

Data:
	Small - All data including stack & heap total <64k
	Medium- All static data total <64k;
		stack: an additional 64k for dynamic data
		heap: limited only by available memory
	Large -	As in medium but each module can have 64k of
		static data

Their data classes are:
	Static: variables not contained in a procedure, literal
		strings, structured constants.
	Dynamic: variables declared within procedures.
	Heap:	data allocated by NEW or Storage.ALLOCATE.

I believe that these all apply to 8088 and 'better' processors.

David M. Fellows
Newsgroups: comp.lang.fortran
From: mjs@hubcap.clemson.edu (M. J. Saltzman)
Subject: Re: Small Language Wanted
Organization: Clemson University, Clemson SC
Date: Thu, 27 Aug 1992 15:15:05 GMT

In article <9224014.17999@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
>
>>UweKloss@lionbbs.bs.open.de ( Uwe Kloss) writes:
>>: > In addition, C has nothing equivalent to Fortrans **
>>: > operator nor does it have complex types.
>
>Note however that C++ does have complex types.
                       ^^^^
Complex types can be implemented as a class...

>[...]
>>: > And arrays, C has no true array type
>>: > like Fortran does (One must use pointers to pointers ... to pointers).
>>: Did you ever try:     int a[12][34];
>>: And             :     a[x][y] = somewhat;
>>
>>Yes, but try to use "a" in a subroutine.
>
>void subroutine(int a[12][34]) {...}
>
>If there are problems, could you please explain them better?

No need to be so contrary.  He's talking about writing subroutine() to
manipulate a generic multidimensional array with size not specified
until runtime.


-- 
		Matthew Saltzman
		Clemson University Math Sciences
		mjs@clemson.edu
From: svanhout@cmsa.gmr.com (Sid VanHouten CT90)
Newsgroups: comp.lang.fortran
Subject: date,time and pwd from rs6k FORTRAN
Keywords: date time
Date: 26 Aug 92 12:46:37 GMT
Reply-To: svanhout@cmsa.gmr.com (Sid VanHouten CT90)
Organization: General Motors Research Labs

--
Can anyone tell me how to get date, time and current working directory info
from my FORTRAN program on an RS/6000 using xlf? 
Thanks...

Sid VanHouten                svanhout@cmsa.gmr.com (internet)
General Motors Research Labs    (313)986-1958 (phone)
Warren, MI 48090-9055           (313)986-2995 (fax)
Newsgroups: comp.lang.fortran
From: wonga@chem.su.oz.au ()
Subject: Performance diff between passed and stack arrays
Organization: Sydney University Computing Service, Sydney, NSW, Australia
X-Newsreader: Tin 1.1 PL4
Date: Mon, 31 Aug 1992 07:08:36 GMT

For medium to large sized arrays, is there any difference in performance 
between an array passed from main & creating the array within the subroutine
on the stack? I realize that for very large arrays there is some default
stacksize that it might exceed, where performance may be degraded. (my
compiler informs me of this) but could this extrapolated back to smaller
arrays. I.e. does smaller stacksizes neccessarily imply better perforamnce?

Is there any difference between an array declared in main's stack and
one given common storage.

This sort of dilemma is a continual source of headaches for which it 
seems there are three options:

	i) Pass portions of blank common to the subroutines to use as
	workspace. This leads to lengthy parameter lists and messy
	indexing arithmetic. 

	ii) Declare the temporary arrays in the subroutine itself.
	This is apparently not suitable for large arrays and for arrays
	where the required dimensions is not known in advance.

	iii) Use blank common in the subroutine, however
	once again dynamic setting of array lengths is not possible.

Without resorting to dynamic memory allocation, I would say (i) was the 
preferred option since the main module can abort the program if the
size of the problem is too big and the other modules can be independent
of PARAMETER statements. However, 90% of my main modules are invariably 
devoted to indexing/memory arithmetic.

I would be interested to hear how others tackle this problem.
-----------------------------------------------------------------------------
Adrian Wong, Dept.of Theoretical Chemistry     wong_a@summer.chem.su.oz.au
University of Sydney NSW 2006 Australia        061-2-692 4137
Xref: sparky comp.lang.fortran:3225 comp.unix.cray:250
From: ssp2537@tamsun.tamu.edu (Satya Srinivas Padavala      )
Newsgroups: comp.lang.fortran,comp.unix.cray
Subject: CRAY-YMP single precision machine constants.
Date: 27 Aug 92 16:08:28 GMT
Article-I.D.: tamsun.1992Aug27.160828.18574
Organization: Texas A&M University, College Station

Hi Folks,

     I am wondering if any knowledgeable soul could help me with the following 
problem. I have been using in my code, BLAS (Basic Linear Algebra Subprograms),
 which are routines called by public domain math packages such as LINPACK, 
EISPACK etc. I have recently started working on a CRAY-YMP and am need of the 
following machine constants for single precision for that machine. 

 1) Smallest positive magintude
 2) Largest positive magnitude
 3) Smallest relative spacing
 4) Largest relative spacing

 I would appreciate your help if you can point me where I can find these
values.

Thanks,
Satya Padavala
ssp2537@tamsun.tamu.edu
From: jrbd@craycos.com (James Davies)
Newsgroups: comp.lang.fortran
Subject: Re: FAQ  request
Date: 31 Aug 92 23:20:12 GMT
Organization: Cray Computer Corporation

In article <29AUG199204051328@mpx2.lampf.lanl.gov> ahn@mpx2.lampf.lanl.gov (Hyo E. Ahn) writes:
>Hello,
>
>Could someone please post or mail me a copy of the FAQ for this group?

Well, I've never seen one, but here's a start:

Q:  Why are you morons still using Fortran?  C is the best language ever.

A:  No, Fortran is better.  And Fortran 90 is the best of all.


Q:  I don't believe you, so I want to convert my Fortran code to C.
    Where can I get a Fortran to C converter?

A:  f2c is available via FTP from research.att.com, or by email from
    netlib@research.att.com (put "send index from f2c" in the body of the 
    message).  An MS-DOS version is available from wuarchive.wustl.edu.


Q:  Where can I get a free Fortran compiler?

A:  On Unix, you can use f2c (see above).  For MS-DOS, there's something
    around called BCF77 that is rumored to be a shareware Fortran compiler,
    but the documentation is in German.


Q:  How can I call C from Fortran, and vice-versa?

counter-Q:  What system are you using?
    The answer is very system dependent.  Check your system's Fortran
    and C manuals for starters.


Q:  Is there a lint program for Fortran?

A:  There's a freeware Fortran lint called ftncheck that is available from
    the netlib servers netlib@research.att.com and netlib@ornl.gov, among
    other places.  There are also various commercial programs available.


Q:  Where can I get Gnu Fortran?

A:  You can't.  It's just now entering alpha testing.
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.lang.fortran
Subject: Re: Help for rs6k passed arrays (old fortran)?
Date: 3 Sep 92 22:54:22 GMT
Organization: Digital Equipment Corporation


In article <6556@lhdsy1.lahabra.chevron.com>, jpr@lhdsy1.lahabra.chevron.com 
(John C. Prestridge) writes...
> 
>Excuse me if this question was asked before.
> 
>In some old fortran programs, the array dimension is passed to the subroutine
>with a argument size of 1,   For Example:
>                
> [example omitted]

>In many machines, the compilation of such a routine would not give compilation
>errors and/or warnings, but on the rs6000 a warning is given about a CONSTANT
>SUBSCRIPT IS OUT OF BOUNDS for each such occurrence in the code.  In many large
>codes there are very large numbers of such occurrences.  Is there some method
>to tell the compiler that the code is an earlier FORTRAN, so that such 
>warnings would not be generated?    
> 

The standard way of expressing this is to declare the upper bound with
an asterisk; this makes it an "assumed size array".  Many compilers
(including Digital's) treat a last dimension of 1 as an implicit assumed
size array for compatibility with many old programs which used this
convention (it was never a part of a FORTRAN standard).

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: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: Small Language Wanted
Organization: Department of Chemistry, University of Toronto
Date: Thu, 27 Aug 1992 18:19:26 GMT

In article <H.3lvmyc56w&A@lionbbs.bs.open.de> UweKloss@lionbbs.bs.open.de
writes:
>In <DAVIS.92Aug23010605@pacific.mps.ohio-state.edu>, "John E. Davis" writes:
>> In addition, C has nothing equivalent to Fortrans **
>> operator nor does it have complex types.
>The differeces between code the compiler generates and
>the one that is linked as a library or inserted by the
>preprocessor.

     That is a big difference!  Consider the following Fortran program:

      integer i
      double precision a,b
      a = 4.2
      b = 9.3
      i = 10
      write(*,*)a**i,a**b
      END

     The compiler, faced with such a program, examines the types of the
arguments and generates completely different code to do the two
exponentiations; certainly, one calculation can be expressed exactly in
terms of multiplications while the other cannot.  It may be more
efficient or more accurate to do it one way or the other and the
compiler can choose a calculation method which reflects current thinking
on this sort of problem.
     Now consider an equivalent piece of code, written in C:

     void main(){
     int i;
     double a,b;
     a = 4.2;
     b = 9.3;
     i = 10;
     printf(pow(a,(double) i),pow(a,b));
     }

(You'll forgive me, I hope, for getting the C idiom slightly wrong.
The one manual I have at hand right now is less than entirely helpful on
several trivial details.  In particular, I'm not at all sure that the
cast of i to double is entirely kosher, and I think that printf wants a
format specification.  In any event, you get the general idea.)  Can the
compiler play the sorts of tricks which the Fortran compiler was free to
do?  I don't think so.  pow() being a library routine, I don't think it
would be good form (or standard-conforming) for the compiler to guess at
the programmer's intent and to do anything more than to leave the
reference to be resolved by the linker.  After all, until the library is
linked in, in principle the compiler knows nothing about any function
but perhaps its prototype.  This particular library function
expects (I think) two doubles (floats?) and must be passed these.
That's all there is to it.
     In my opinion, what C lacks to be able to handle these things
correctly is any concept of a "built-in" function.  Fortran knows to
treat sin(a) and sin(x) differently if a is real and x is double
precision because knowledge of these primitive functions is built into
the compiler.  C can't do anything like this because of its design.  C
is great for writing wordprocessors, but not so great for scientific
computing for exactly this sort of reason.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca
Xref: sparky comp.lang.fortran:3414 comp.graphics:9430 sci.engr:1983 sci.engr.civil:425 sci.geo.geology:1886 sci.image.processing:606
From: jpr@lhdsy1.lahabra.chevron.com (John C. Prestridge)
Newsgroups: comp.lang.fortran,comp.graphics,sci.engr,sci.engr.civil,sci.geo.geology,sci.image.processing
Subject: Calcomp to Postscript routines ?
Keywords: Calcomp, Fortran, Postscript
Date: 3 Sep 92 23:09:15 GMT
Followup-To: comp.lang.fortran
Organization: Chevron, La Habra, CA


Is there any public domain or shareware conversion routines for converting
CALCOMP fortran plotting routines to postscript file output and/or to  
X-windows.  The CALCOMP routines date from the late 1960's to early '70's.
 
I heard about some routines written by someone in the US Geological Service
which have been released into public domain, but I haven't been able to
find an anonymous ftp site which has them.

Thanks for any tips and assistance. 
 
                    John Prestridge   :-)
                    (jpr@chevron.com)

-- 
 -------------------------------------------------------------------------
   John Prestridge                           Internet:   jpr@chevron.com
   Chevron Oil Field Research Company                             
   P.O. Box 446, La Habra, CA 90633-0446
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran
Subject: Re: Does your f77 compiler accepts this?
Date: 25 Aug 92 20:38:20 GMT
Article-I.D.: geech.BURLEY.92Aug25163820
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: KGZXK@ASUACAD.BITNET's message of 25 Aug 92 01:12:34 GMT

In article <92237.181234KGZXK@ASUACAD.BITNET> KGZXK@ASUACAD.BITNET (Zafer KADI) writes:

   The standard Fortran 77 does not except this kind of notation.

   WRITE(6,*)(A)

   Most of the compiler except it, but you may have problems with some.

ANSI FORTRAN 77 does indeed accept (not "except") a statement like:

    WRITE (6,*) (A)

What it doesn't accept is:

    READ (6,*) (A)

The reason is that an output-list-item may be an expression, while an
input-list-item may not.
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Newsgroups: comp.lang.fortran
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Scientists as Programmers (was Re: Smal
Organization: Los Alamos National Laboratory
Date: Tue, 1 Sep 1992 17:52:55 GMT

In article <BtwK17.ADM@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
|> In article <1992Aug31.164354.3518@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|> [...]
|> >No one is recommending (and Herman didn't) that strict typing be abandoned.
|> >It is possible to have type coercion and *still* be able to statically
|> >determine type. [...]

|> [...]
|> I did mean that the user should be able, when appropriate, to completely 
|> ignore the type.  This should be a deliberate act, however, by one who
|> knows what is being done.

The problem with trying to completely ignore the type is that without 
type there are *no* operations defined on an object.  What you really
need is the ability to coerce type without actually altering the bits
of the data.  That way, you can take operations (like shift, mask, booleans,
integer arithmetic, etc.) which are defined on one type in your language
and use them on another type.  Without any type at all, not even assignment
is defined on the data object.

Languages like Modula have a data type called `word' which has a certain
minimal set of operations defined on it.  This is *NOT* a mechanism for
completely ignoring type, it is a subset of the mapping mechanism I
proposed.  The notation I advocate allows *any* type to be mapped to 
*any* other type - giving the user complete flexibility over what 
operations are desired to be carried out.  You can even map things
to a data type called `word' which has the same set of operations
defined on it that Modula `word' type posesses.

All languages which allow the user to "completely ignore the type" are
really just casting the object to a specific type that they simply 
*call* "typeless", but which has specific operations and properties
defined for it, just like all the other types in the language.

|> [...]
|> The above example shows some of the problems.  The multiplication above
|> will work provided there is no overflow and x(5) != 0.  If the leading
|> bit of normalized numbers is present, it will also work if x(5) = 0, but
|> dividing by 2 by subtracting one from the exponent will not work.

Obviously!!  I was giving an example of *notation*, not of how to do
specific operations on floating point.  As I pointed out, this stuff
is _always_ machine dependent and requires care.  It can be seen that
the notation I described makes it *possible* to manipulate the floating
point numbers in the high-level language.

-- 
J. Giles