HDTenEightyP/NetNews huggingface dataset:
From: roland@quadsys.com (Roland Besserer)
Subject: APL on SPARC
Organization: QUAD Systems
X-Newsreader: Tin 1.1 PL3
Date: Mon, 25 Jan 1993 08:24:23 GMT

I am considering getting an APL implementation, preferably APL2, for
my SPARC 2 or DECStation 5000/200 - or both.

I would like to hear from anyone who has APL running on either of these
machines.

Also, does anyone have an email address or phone number for MicroAPL
in England? I seem to remember that they were working on APL2 for the
SUN.

Thanx

-- 

--------------------------------------------------------------------------------
Roland Besserer          QUAD Systems, Santa Cruz             roland@quadsys.com
Newsgroups: comp.lang.apl
From: SJEVM5@vnet.ibm.com
Subject: Message from JONESCA at SJEVM5
Date: 21 Jan 1993 00:00:43

 Vacation through Thursday.

 The mail you sent has been archived.

 This message was sent by the SAFE automatic machine: do not reply.
Newsgroups: comp.lang.apl
From: sam@csi.jpl.nasa.gov (Sam Sirlin)
Subject: Re: Interpreter advice sought.
Originator: sam@kalessin
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Fri, 22 Jan 1993 00:35:08 GMT


In article <1993Jan21.160604.7887@lth.se>, kurt@dna.lth.se (Kurt Swanson) writes:
|> Is there any "free" apl *interpreter* available for UNIX and/or MAC's???

Unix: J only, as far as I know, though if you have an ATT source site
      licence an (unsuported) APL comes with (BSD) Unix

Mac: J, and I think there is a port of IAPL (rather a toy...) and I've heard 
      APL 90 is available 

For a pc there are many more options.

-- 
Sam Sirlin
Jet Propulsion Laboratory         sam@kalessin.jpl.nasa.gov

Newsgroups: comp.lang.apl
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: Control structures beyond GOTO
Organization: University of Waterloo
Date: Fri, 22 Jan 1993 05:12:13 GMT

I understand there was a presentation on this subject at Minnowbrook in
September; perhaps one of the participants could summarize it?
From: shoeft@hsc.usc.edu (Sebastian Hoeft)
Newsgroups: comp.lang.clu
Subject: test: ignore
Date: 21 Jan 1993 13:47:24 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: ca
NNTP-Posting-Host: hsc.usc.edu


Newsgroups: comp.lang.modula3
From: jredford@shearson.com (John Redford)
Subject: Re: references, objects & m3
Organization: Lehman Brothers
	<C1E30F.vx@undergrad.math.waterloo.edu>
	<FN00.93Jan25085601@tahoe.gte.com>
Date: Mon, 25 Jan 1993 19:17:26 GMT

In article <FN00.93Jan25085601@tahoe.gte.com> fn00@gte.com (Farshad Nayeri) writes:

   In article <C1E30F.vx@undergrad.math.waterloo.edu> papresco@undergrad.math.waterloo.edu (Paul Prescod) writes:

[STUFF DELETED]


      Also is there anyway to auto-initialize/auto-destroy objects as in C++
      with constructors and destructors?

   Not really (except for static initializations).  This is a matter of
   religeous war among Modula-3 purists and people with C++ orientation.

I have been looking at the WeakRef interface. It would appear at first
reading that this would provide a destructor-like functionality. I
cant tell for sure if it would work with objects, but it would seem
likely.

--
John Redford (AKA GArrow) | 3,600 hours of tape.
jredford@shearson.com     | 5 cans of Scotchguard.
Newsgroups: comp.lang.modula3
From: mjordan@src.dec.com (Mick Jordan)
Subject: Re: Why are M3 executables so big?
Organization: DEC Systems Research Center
Distribution: usa
Date: Wed, 27 Jan 93 03:07:07 GMT

In article <C1Hp3L.3z7@babbage.ece.uc.edu>, dsims@don.ece.uc.edu (David Sims) writes:
|> Why does the following hello-world program create a 400K stripped
|> executable on my Sparc box?  The .mo file is a mere 399 bytes, but the
|> executable balloons to 400K.  Are the Wr, Stdio, and other run-time
|> libraries really that large?
|> 

This is an old chestnut that many new users find astonishing, but we ought to
put it in a little perspective. First, all programs include a relatively
sophisticated storage manager and garbage collector, a lightweight process
package (Thread), and a run-time type system. These artefacts, that in other
languages would count as user libraries, cost quite a bit in code and data
size. There is also some overhead that arises from generating C code instead
of native machine code.

In addition, there is substantially more functionality in the libraries,
than hello-world actually needs. We have not tried very hard to structure
the library into small components. I have a prototype tool that optimises
whole M3 programs and, when applied to hello-world, generates an
executable that is 220K in size, as opposed to 417K, on a DECstation 5000.
If this is then optimised with the C compiler, it reduces to 177K.

Of course, since you are running on a Sparc, you can use shared libraries
to mitigate the size of executables. 

Mick Jordan
From: moss@cs.cmu.edu (Eliot Moss)
Newsgroups: comp.lang.modula3
Subject: Re: references, objects & m3
Date: 24 Jan 93 21:41:46 GMT
Article-I.D.: CRAFTY.MOSS.93Jan24164146
Reply-To: moss@cs.cmu.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

I don't understand why you're using REF OBJECT ... END instead of just OBJECT
... END. The latter is implementation essentially as REF RECORD ... END, but
with the additional semantics of OBJECT method invocation, subtyping, etc. You
should probably just delete the level of REF in your binary tree stuff. Maybe
you want somehting like this:

	TYPE Node = RECORD
	              This       : Sortable;
		      Left, Right: REF Node;
		    END;

You are quite right in noting that REF S is not a subtype of REF T, even when
S is a subtype of T. Adding such subtyping rules to the language has various
undesirable consequences, mainly in complexity, though one may be able to come
up with type systems in which such subtyping judgements would be sound. See
the section of the Nelson book "How the Language Got Its Spots" for further
discussion of rationale for the subtyping rules.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
Newsgroups: comp.lang.modula3
From: marc@ecrc.de (Marc Bourgois)
Subject: debugger?
Reply-To: marc@ecrc.de
Organization: European Computer-Industry Research Centre GmbH.
Date: Tue, 26 Jan 1993 14:13:36 GMT

with the release come tools like replayheap and showthread.  From their
names I suppose they are debugging tools, is there any doc on how to
use them?  Are they graphical?

Any info on how you debug multithreaded m3 programs is useful -- thanks

---
Marc Bourgois
European Computer-Industry Research Centre      Tel. + (49) 89-92699-179
Arabellastr 17, 8000 Muenchen 81. Germany.
Internet: marc@ecrc.de
UUCP: ..unido!ecrc!marc
From: muller@src.dec.com (Eric Muller)
Newsgroups: comp.lang.modula3
Subject: Re: What is the representation of Text?
Date: 28 Jan 93 18:09:05 GMT
Organization: DEC Systems Research Center

In article <FN00.93Jan27115929@tahoe.gte.com>, fn00@gte.com (Farshad Nayeri) writes:

|> Looking at the libm3 source, I can see that "Text"s _are_
|> null-terminated, but I can't find any part of the code that _uses_ the
|> null-termination (instead, a combination of memcpy and NUMBER is used).
|> 
|> So, _why_ are "Text"s null-terminated?
|> 
|> I can think of two possiblities: 
|> 
|> a) it makes debugging easier in a c-oriented debugger.

That's the correct answer.

|> b) some of the lower layers of the code (like the compiler) uses this
|>    assumption.

M3toC.TtoS uses it.  It breaks when you try to convert a Text.T with a
'\000' in it, but you cannot represent such a string anyway.

-- 
Eric.
From: awenn@matilda.vut.edu.au (Andrew Wenn)
Newsgroups: comp.lang.modula3
Subject: Help installing m3 on ARM
Date: 26 Jan 93 23:39:27 GMT
Organization: Victoria University of Technology

Can anyone help me please?

I am installing m3 on an ACORN machine using the ARM architecture and RISCiX.

Most of the installation appears to go O.K. until we get to step 6.

i.e. m3make -f m3makefile.boot all install 

then I get an error:

LongReal_i.c: 15: Error: small floating point value converted to 0.0
LongReal_i.c: 0warnings 1 error 0 serious errors
Error code 1.
Stop.
Error code 1.
Stop.

Can someone please tell me what to fix as I cannot find any obvious errors
in the files (there are two of them as far as I can see.

Thanks.
Andrew Wenn.



---------------------------------------------------------------------------
Andrew Wenn          Victoria University of Technology
                     Footscray Campus.
                     awenn@matilda.vut.edu.au

                     phone 03 688 4342
                     fax   03 688 4804
---------------------------------------------------------------------------
Newsgroups: comp.lang.modula3
From: papresco@undergrad.math.waterloo.edu (Paul Prescod)
Subject: Re: references, objects & m3
Organization: University of Waterloo
Date: Mon, 25 Jan 1993 23:51:56 GMT

>I wonder why do you need to copy objects.

You are right, it's not that often.  But occasionally you may want to
have permission to edit an object without changing the original.

Besides: Isn't the idea of object oriented programming that you
shouldn't have to understand the implementation of the "primitives."
If I didn't understand how M3 objects worked, I could very easily edit
the original.  

Once you understand it, I guess it's just another convention.

>Not really (except for static initializations).  This is a matter of
>religeous war among Modula-3 purists and people with C++ orientation.
>I hope that I won't be starting a war-thread on this subject, when I
>say that:
>
>- Because of garbage collection, destructors are not as crucial in
>  Modula-3 programming. (What do you usually do in a destructor in
>  C++?)

Agreed.  But what about say, sending a message to a window that has
just been destroyed to remove itself from the screen.  Is there a
one line call-destructor and destroy object similar to your one line
constructor?

>- Constructor-like procedures can be created by doing:

>  VAR t := NEW (Foo.T).init(20);

>Hope this helps.

Immensely, thanks for the explanation.
From: sullivan@teal.csn.org (Steve Sullivan)
Newsgroups: comp.lang.modula3
Subject: structural equivalence ==> no referential transparency
Date: 24 Jan 93 16:52:42 GMT
Distribution: na
Organization: Colorado SuperNet, Inc.


In Modula 3, arrays lose all index info when passed to a subprocedure.
For example, an array dimensioned [1:10] becomes [0:9] in a called proc.

This is a real lack of referential transparency:
vec[1] means different things, depending on which proc it appears in.
If a caller passed an array and an index value of some element
to a subproc, the index value would be invalid in the subproc.
For example:

Main proc:
 avec: ARRAY {1..100} OF LONGREAL;
 ...
 x = subproc( avec, k);

subproc( avec, k):
  v = avec[k]         (* will access element k+1 *) 

Although Modula 3 does have FIRST and LAST functions, they
seem more like afterthoughts than features:  even if the
above subproc were coded   v = avec[FIRST(avec)-1+k],
the subproc must still know the base of avec (hardcoded as "1").
And in any event "avec[FIRST(avec)-1+k]"
is far less clear to the reader than  "avec[k]".

I don't know, but I assume the designers did this:
  1. To further the "structural equivalence" concept:
     that all arrays of reals are identical, whether the indices
     of the arrays ints, or an enumerated set.
  2. To avoid headaches in dealing with enumerated index sets.

However, for me their decision
not only invalidates all use of enumerated index sets (they
can't be used in subprocs), but destroys the usefulness of
subprocs for handling arrays of any sort.

A better approach, in my mind,
would have been to store a pointer to the definition
of the enumeration with each array whose index set is drawn from it.
That way they would main referential transparency.

Does anyone know why the Modula 3 designers created such
an unwieldy definition for array handling?  Is there any
thought of changing it?

Steve Sullivan
Grad Student, Dept Computer Science, Univ Colorado Boulder
sullivan@csn.org
Newsgroups: comp.lang.modula3
From: awenn@matilda.vut.edu.au (Andrew Wenn)
Subject: Modula3 and DOS
Organization: Victoria University of Technology
Date: Thu, 21 Jan 1993 06:52:17 GMT

Dear modula3 users,

Can anyone tell me if there is a DOS version of modula3 available? Prefer
a PD one but any would do.

Andrew Wenn.


---------------------------------------------------------------------------
Andrew Wenn          Victoria University of Technology
                     Footscray Campus.
                     awenn@matilda.vut.edu.au

                     phone 03 688 4342
                     fax   03 688 4804
---------------------------------------------------------------------------
From: papresco@napier.uwaterloo.ca (Paul Prescod)
Subject: references, objects & m3
Organization: University of Waterloo
Date: Sat, 23 Jan 1993 21:20:41 GMT

I'm using modula-3, and I like it.  I've found one thing I can't seem
to get around.

I've got an _Insert_Bin_Tree function, which inserts "Sortable" objects
into a binary tree.

I've got "Sortable_Sub" which is a subtype of the sortable object.

The problem is, _Insert_Bin_Tree only takes REFERENCES to Sortable
objects.  It seems like the REFERENCE to a Sortable_Sub is not a
subtype of the reference to Sortable.  Therefore, I can't use narrow.

How can I call _Insert_Bin_Tree then?  I've modified _Insert_Bin_Tree,
but I won't always be able to do that in the future.

Is the only way around it to declare the module unsafe and use the ADR
operator?

Thanks in advance for any help.
From: fn00@gte.com (Farshad Nayeri)
Newsgroups: comp.lang.modula3
Subject: Re: What is the representation of Text?
Date: 26 Jan 93 12:21:03 GMT
Organization: GTE Laboratories, Waltham, Massachusetts, USA
In-reply-to: grenzelm@slate.mines.colorado.edu's message of 25 Jan 93 23:02:39 GMT


In article <1993Jan25.230239.45587@slate.mines.colorado.edu> grenzelm@slate.mines.colorado.edu (RENZELMAN GREGORY DO) writes:

   I am taking a computer course at the Colorado School of Mines,
   which is using modula3 as the programming language.  I'm interested
   in how the computer represents the data type TEXT.  Is it similar
   to C where there is a null terminator?  This information would be
   helpful because I will have to write code that parses TEXT.
   Thankyou for your time.

I think the whole point is that you *shouldn't* need to know how
Modula represents TEXT. Commmon operations on texts are in the "Text"
interface. If you _really_ want to know what the representation is,
try the "TextF" interface.

You may want to take a look at "Modula-3" by Sam Harbison; I am sure
he explains how to work with TEXTs.

--farshad

--
Farshad Nayeri                Intelligent Database Systems
fn00@gte.com                  Computer and Intelligent Systems Laboratory
(617)466-2473                 GTE Laboratories, Waltham, MA

  "To see is to forget the name of the thing one sees." -- Paul Valery
From: dagenais@vlsi (Michel Dagenais)
Newsgroups: comp.lang.modula3
Subject: Re: references, objects & m3
Date: 27 Jan 93 14:44:21 GMT
	<C1E30F.vx@undergrad.math.waterloo.edu>
	<FN00.93Jan25085601@tahoe.gte.com> <1993Jan25.191726.6722@shearson.com>
Organization: Ecole Polytechnique


>   I have been looking at the WeakRef interface. It would appear at first
>   reading that this would provide a destructor-like functionality. I
>   cant tell for sure if it would work with objects, but it would seem
>   likely.

Indeed, these guys at DEC SRC are incredible. From version 2.07 to version
2.11, besides a lot of interesting applications like Zeus/Mentor, they
solved probably the two most noteworthy problems that i had with Modula 3 
(and that most other popular languages are not close to address for some
time). (Note that i have not tried much these new features yet).

For highly interactive applications, long garbage collections can be a
nuisance. The incremental garbage collector just appeared to solve this!

The other difficulty was "finalization/destructors" as discussed in this
thread. The weakref library is very simple yet solves elegantly the
problem. It handles correctly finalization order and resurected objects. We
needed this for cleaning up windows, communication channels, telling remote
objects that their proxy was not used anymore, removing collected
character bitmaps from the character cache... Many thanks!

--
---------------------------------------------------------------------

Prof. Michel Dagenais			    dagenais@vlsi.polymtl.ca
Dept of Electrical and Computer Eng.
Ecole Polytechnique de Montreal		    tel: (514) 340-4029

---------------------------------------------------------------------
Newsgroups: comp.lang.modula3
From: cflatter@nrao.edu (Chris Flatters)
Subject: m3make relies on obsolete shell feature
Reply-To: cflatter@nrao.edu
Organization: NRAO
Date: Tue, 26 Jan 93 00:13:52 GMT

Make files (.makefile) constructed by m3make from the SRC Modula 3 distribution
contain rules like the following.

c.o:
	IFS=' $(SEP)'; $(PASS1) -c $(BOOTOPT) $<
s.o:
	IFS=' $(SEP)'; $(PASS1) -c $(BOOTOPT) $<


These cause commands similar to the following to be passed to the shell

IFS=' @'; @cc@ -c .... $<

This will not work unless IFS is used for splitting all fields.  This
is traditionally the case for the Bourne shell but is not the case for
the POSIX.2 shell:  the POSIX.2 shell only performs splitting on fields
that result from tilde expansion, parameter expansion, command
substitution and arithmetic expansion (section 3.6).  The splitting of
other fields causes a number of problems (including some security
holes) and has been removed from some Bourne shells (eg. 386BSD --- and
probably other NET-2 derivatives) that do not fully conform to
POSIX.2.  m3make will not, therefore, work in its current form on
systems that comply with POSIX.2 or have a corrected Bourne shell.

Which part of the system relies on the use of a non-whitespace separator
in the definitions of the compiler passes?  Can the seperators be elided
when creating the .makefile(s) without causing any side effects?

	Chris Flatters
	cflatter@nrao.edu
From: C.R.Snow@newcastle.ac.uk (Dick Snow)
Newsgroups: comp.lang.modula3
Subject: UMAX build problem with 2.11
Date: 27 Jan 93 17:12:22 GMT
Reply-To: C.R.Snow@newcastle.ac.uk (Dick Snow)
Organization: University of Newcastle upon Tyne

I am trying to build the 2.11 distribution for the Multimax running UMAX4.3.
The compiler has been successfully built, and I am now trying to create the new
library. The modules compile ok (which presumably tests the compiler quite
adequately), but when it tries to build the archive, it fails with the error
message below. Can anybody suggest a cure?

Thanks,
	... Dick Snow.

-------------------------------------- libm3/UMAX
/usr/local/m3-2.11/bin/m3 -w1 -make -why -nostd -times -O    -a libm3.a
-F.PGM_S
OURCES
new objects -> archiving libm3.a
ar: bad option `3'

 seconds  #times  operation
    1.24       1  flattening search path
    3.80     351  checking object timestamps
   33.26     348  checking old link info
   11.08       1  compiling C -> object
    0.72       1  checking global consistency
    3.60       1  generating _m3lib.c
    0.72       1  building library link info
   19.81       1  exhaling new link info
    0.17       1  building library archive
    0.21       2  removing temporary files
   29.49      10  garbage collection
    1.98          other
---------------------------------------------------
  106.08          TOTAL


Fatal Error: program "/bin/ar" failed (exit status 2)

gmake: *** [libm3.a] Error 255
*** Error code 1

Stop.
Newsgroups: comp.lang.modula3
From: grlw1@cus.cam.ac.uk (G.R.L. Walker)
Subject: Symbolic Expressions
Reply-To: grlw1@phx.cam.ac.uk
Organization: U of Cambridge, England
Distribution: world 
Date: Mon, 25 Jan 1993 12:42:45 GMT

In the 2.11 Modula-3 libraries, the Sx.i3 file refers to (section 3.1)
'SxSyntax.DefineCurly' for adding functionality to Sx things.
But there seems to be no such thing any more.
What happened to it? Is there any easy way to replace it's functionality?

-- Rich!
If not voting could change anything,
would it still be legal?
Newsgroups: comp.lang.modula3
From: gallatin@dimaggio.cs.rpi.edu (Andrew Gallatin)
Subject: cpp / fisheye
Keywords: cpp, fisheye
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: Sun, 24 Jan 1993 18:43:58 GMT


A while back I posted with a problem I was having building libm3 on a
sparc.  The make would die with the message:
 make: Fatal error: Don't know how to make target `/M3Config.m3'

The problem turned out to be caused by setting CPP to gnu's cpp in the
initial config file.  (Which I did because people were recommending
building with gcc, so I figured I would use gnu cpp as well)  Changing
this to Sun cpp solved this problem, and I was able to build the package.

I was wondering if anybody knew the status of the fisheye package?
(Ie, if/when it will be fixed to run with the current version of m3?) Its
the real reason that I started to build modula-3.  Does anybody know
of any working sparc binaries that I could obtain?  Unfortunately, I
don't have access to a mips machine..

Thanks for any help!

Andrew
-- 
   "Early to bed, early to rise, makes a man sleepy and bleary in the eyes"

        Andrew Gallatin                         gallatin@cs.rpi.edu
Newsgroups: comp.lang.modula3
From: rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: Harbison errata list
Date: Mon, 25 Jan 1993 22:57:33 GMT
Organization: Colorado State University

A formatted list of all the errors I know about as of this posting
in Harbison's ``MODULA-3'' text is available via anonymous ftp from 
beethoven.cs.colostate.edu (129.82.102.83), in the file 

  ~ftp/pub/M3/harbison-errs.ps.Z.

The list currently has 96 entries ranging from changing typeface
to the replacement of most of page 75.

I'd appreciate contributions of additional errors to keep this list
up-to-date.  Thanks for your help.


|--------------------------------------------------------------|
| Rod Oldehoeft                    Email: rro@cs.colostate.edu |
| Computer Science Department      Voice: 303/491-5792         |
| Colorado State University        Fax:   303/491-6639         |
| Fort Collins, CO  80523                                      |
|--------------------------------------------------------------|
| I pay the price, but do not count the cost.                  |
|                            John Barth, "The Tidewater Tales" |
|--------------------------------------------------------------|