HDTenEightyP/NetNews huggingface dataset:
From: hui@yrloc.ipsa.reuter.COM (Roger Hui)
Subject: Re: Beginner J questions: local variables
Organization: Iverson Software Inc.
Date: Sat, 12 Sep 92 05:57:06 GMT

Lou Glassy writes:
 
> bar =. '(+/ y.) % (# y.)' : ''
> var =. 'bar *: y. - bar y.' : ''
>
> what i'd like to do, is encapsulate bar y. in a noun local
> to the var verb.  var is correct and straightforward, but it
> irks me that it recalculates bar y. repeatedly when it doesn't have
> to.  can local variables be embedded in verb definitions?
> if so, how?
>
> (i don't *know* that var recalculates bar y.  just a guess.)
 
var calculates bar y. just once.  In any case, names can be assigned
within explicit verbs as without, using =. or =: .  For example:
 
s2 =. '((n*+/*:y.)-*:+/y.)%*:n=.#y.' : ''

------------------------------------
Roger Hui, Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
Phone: (416) 925 6096;  Fax: (416) 488 7559
Newsgroups: comp.lang.apl
From: sam@csi.jpl.nasa.gov (Sam Sirlin)
Subject: Re: apl*plus to IBM/apl2 conversion problem
Originator: sam@kalessin
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Tue, 15 Sep 1992 21:25:31 GMT


In article <5835@blue.cis.pitt.edu.UUCP>, gunner1+@pitt.edu (Jayant Rajgopal) writes:
...
|> which were created on APL*PLUS (STSC, Inc.) into transfer files for
|> use with the IBM APL2 system on my PC.  However, when I try to run
|> programs in these, I'm running into a problem with a system variable
|> "quad"TCNL which APL2 does not recognize.  I have no idea what this
...
|> My question: is there any way that I can assign a suitable value to this
|> system variable and save the same in the converted APL2 workspace so
|> that I can use the workspace.  Or do I have to edit each of the programs
|> in the workspace that uses this thing and remove it from them ?

quadTCNL is just the newline character, ASCII CR or 13 (0 origin).
Since you're on a pc, you don't have to play with EBCIDIC. But you do
have to edit all the functions. My guess (I don't know APL2) is you'll
have to make up some variable name to use, say qtcnl, globally
make it ASCII 13 (probably the 14'th element of quad AV), and replace
all the quadTCNL's with qtcnl. I have heard of APL ws that will do
that sort of thing for you and if I had to do alot of this I'd write
my own - it's easy in STSC at least what with quad vr and quad ss. 

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

Newsgroups: comp.lang.apl
From: "Paul Robinson, Contractor" <FZC@CU.NIH.GOV>
Subject:  About the APL book - AUCTION - sorry.
Reply-To: TDARCOS@MCIMAIL.COM
Organization: University of Waterloo
Date: Sun, 13 Sep 1992 16:32:56 GMT

Dick Holt is attempting to sell some APL related material
(and some minor miscellaneous items) to people who are
interested in APL.  My apologies to this newsgroup in that
I failed to make it clear that this is an AUCTION of items
and when someone is interested in something, they have to
submit a bid for the item.

I want to apologize to those of you who submitted a request
for some of the items thinking it was a standard sale of
Miscellaneous APL material.

For those of you who did submit bids (or withdrew them) the
next message shows the current status of bids on the various
items for the products shown.

Thank you for your cooperation.

Paul Robinson
TDARCOS@MCIMAIL.COM

Newsgroups: comp.lang.apl
From: oususalg@cs.montana.edu (Glassy)
Subject: Beginner J questions: local variables
Organization: Montana State University, Bozeman Montana USA
Date: Thu, 10 Sep 1992 16:45:11 GMT

Hi J-folk:

Per subj: line, I have some questions on local variables in J.

Here's a verb to find the arithmetic mean of a rank-1 vector:
   
bar =. '(+/ y.) % (# y.)' : ''

ok.  Now I'd like to write a verb to calculate the variance 
of a vector.  The following does the trick:

var =. 'bar *: y. - bar y.' : ''

what i'd like to do, is encapsulate bar y. in a noun local
to the var verb.  var is correct and straightforward, but it
irks me that it recalculates bar y. repeatedly when it doesn't have
to.  can local variables be embedded in verb definitions?  
if so, how?

(i don't *know* that var recalculates bar y.  just a guess.)

thanks in advance...

lou.
-- 
Lou Glassy (oususalg@cs.montana.edu)                  C Delenda Est
From: COTRSSM@SEA04VM.NAVSEA.NAVY.MIL ("Scott  Mattes", nmi)
Newsgroups: comp.lang.asm370
Subject: Fairwell to network, for now
Date: 8 Sep 92 14:53:56 GMT
Reply-To: IBM 370 Assembly Programming Discussion List <ASM370%UGA.BITNET@cmsa.Berkeley.EDU>
Distribution: inet
Organization: The Internet


  Today I will be losing my Internet access, for an unknown length of
time.  This is due to the downsizing of our IBM mainframe and
consolidation of certain applications to another IBM data center.

  So, for the time being at least, I bid farewell to the net. I wish
to thank all those who have helped to enlighten me on various things
(work, religion, eating, etc) while I have had access.

  If anyone needs to contact me, my 'home' and voice addresses will still
work.

  Needless to say (I will anyway) the ANONYMOUS FTP account
(144.11.100.1) is going away also.

--------------------------------------+----------------------------------------
Scott (nmi) Mattes                    | No success can compensate for failure
Work: COTRSSM@SEA04VM.NAVSEA.Navy.Mil | in the home.  David O. McKay, Prophet
Home: 73027.3270@CompuServe.COM       | and President of the Church of Jesus
Voice: (703) 769-2917                 | Christ of Latter-day Saints, 1951-70
Newsgroups: comp.lang.modula3
From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Constructors in Modula-3
Organization: Dept. of Computer Science, University of Waterloo
	<1992Sep14.150057.4225@Urmel.Informatik.RWTH-Aachen.DE>
Date: Mon, 14 Sep 1992 18:33:41 GMT


I proposed what I think is a simple solution to this problem a couple
months ago, but got no response.  My solution was to add a pragma, say
<*NO NEW*>, that can be affixed to type declarations in an interface.
E.g.,

        INTEFACE foo
           <*NO NEW*> TYPE T <: U;
           PROCEDURE New(x: INTEGER): T;
        END foo.

In the presence of this type declaration, NEW cannot be used to create
objects of type T.  This forces the user of the interface to use
whatever constructor procedures are supplied in the interface; in this
case "New".  (Of course, NEW could still be used inside a module that
implements foo.)

What I would really like to see is a keywork, say PRIVATE, that does
what <*NO NEW*> does.  I think it is a mistake in the language design
that Modula-3 tries to guess whether NEW should be allowed based on
how much is known about a type.  Whether NEW is allowed is really
orthogonal to whether a type is completely opaque, partly revealed, or
fully revealed.

-mike



Newsgroups: comp.lang.modula3
From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Constructors in Modula-3
Organization: Dept. of Computer Science, University of Waterloo
	<1992Sep15.122237.271@Urmel.Informatik.RWTH-Aachen.DE>
Date: Tue, 15 Sep 1992 19:58:54 GMT

In article <1992Sep15.122237.271@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) writes:
> ...
> No, *please* no more pragmas. If you want to have a feature in the
> language standard, then introduce a new keyword. Everything else leads
> to portability problems. I see a certain use for pragmas if they don't
> change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>.
> (What about INLINE anyway? Will it ever be supported?) But what you suggest
> definetely changes the semantics, and should therefore be a keyword (just 
> like <* EXTERNAL *>, which is actually no pragma either).

I, too, like a new keyword, but that would involve changing the
standard, which is pretty difficult.  Adding a pragma can be done by
merely changing a single implementation.  Furthermore, if successfully
implemented and tested, it would add ammunition for introducing a new
keyword in the next version of the standard (if there is one). 

And, as pragmas go, <*NO NEW*> is fairly benign. It doesn't introduce
any portability problems that I can see.  If you write a program using
a compiler that supports <*NO NEW*>, you can compile it on another
compiler that ignores <*NO NEW*> and everything will work just fine.
On the other hand, if you develop a program using a compiler that
doesn't support <*NO NEW*>, it will certainly work on one that does.

The point is that <*NO NEW*> restricts the language, which merely
makes some otherwise-legal programs illegal.  In contrast,
<*EXTERNAL*>, makes some otherwise-illegal programs legal, which is
far more serious and *does* cause portability problems.

-mike
From: Geoff.Wyant@East.Sun.COM (Geoffrey Wyant - Sun BOS SunLabs)
Subject: OpenWindows patches for Trestle ?
To: m3
Date: Wed, 9 Sep 92 16:42:31 EDT

It seems that Trestle causes the OpenWindows
X server to crash. While this is undoubtably
a bug in OpenWindows, does anyone have any
patches to Trestle to work around this ?

thanks,

geoff

Geoff Wyant
Sun Laboratories, Inc.
wyant@suneast.east.sun.com
Newsgroups: comp.lang.modula3
From: shri@sol.acs.unt.edu (Shrinand Desai)
Subject: Re: Modula3 for Windows
Organization: University of North Texas
Date: Thu, 10 Sep 1992 15:56:11 GMT

MBLOMQVIST@finabo.abo.fi (Mikael Blomqvist INF) writes:

>... is that something impossible

>I am a BIG fan of modula2. I have not fallen for modula3 yet since I have been
>using jensen&partner's TopSpeed M2 which includes LONGCARD and such useable
>data types. 
> But the last year I have mostly been programming under MS-Windows and
>therefore been forced to change language.
> So, does anyone know something? is a Windows version on its way... or it is
>just a hopeful dream?

>Micke

Hello,
I am in process(in very initial stages) of porting a subset of M3 on IBM-PC
(386 and above using MS_DOS) with the help of DJGPP 32-bit c compiler (which
does not support windows 3.1) but does support deskview. But I thought,even
a subset of M3 would be very good for PC-world(no threads).
Dr. Moss is writing a native compiler for modula-3 using gcc which would
be easier to port then DEC M3(IMO).
But it is fun anyway.

--shri
From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Newsgroups: comp.lang.modula3
Subject: Re: Constructors in Modula-3
Date: 14 Sep 92 15:00:57 GMT
Reply-To: pk@rwthi3.informatik.rwth-aachen.de
Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany

An obvious solution (though not very elegant) to the constructor problem is
to have an "initialized" flag in the object. This can be set to FALSE by the
default initialization. Every method should check this flag and either raise
an exception if the flag is unset, or it can dynamically init the object at
the first use. Especially the last solution makes NEW act like a constructor,
since the actual init method is not exported.

Now, if you don't like this, I think we should handle the problem in a more
general way. Your suggestion might work for constructors, but at the cost
of introducing pretty much new syntax. This overhead could be reduced
dramatically if we think of constructors as class methods, i.e. methods
which can be applied to non-existing objects. This might look something
like
TYPE A = OBJECT
           <fields>
         CLASS
           <class methods>
         METHODS
           <object methods>
         OVERRIDES
           <class & object method overrides>
         END;
Maybe the distinction between class and object methods could be dropped
altogether; I'm not sure if I'd like this.

In this case, NEW would loose it's status as standard operator and would
become a default for a class constructor. Any new class declaration could
override this NEW method by doing a NEW on the superclass and then perform
initializations on the object fields.

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany
Newsgroups: comp.lang.modula3
From: elliottm@beach.csulb.edu (Mike Elliott)
Subject: Re: Another installation problem (long)
Organization: Cal State Long Beach
Date: Sun, 6 Sep 1992 08:52:43 GMT

In a recent attempt to install Modula-3 version 1.07 on a Sparc, I ran into the
same problem as Mr. Werts -- that of not having enough room on the /tmp disk to
build libm3.a.  The suggestions of Mr. Wyant, Mr. Heiney and Mr. Nayeri on use
of the -l option for ar got me past the first of these problems.  Thanks guys!

Although I feel I've gotten closer, now I get the message 

***
*** runtime error:
***    ASSERT failed
***    file "OS.m3", line 109

followed by a stack dump of the exception handler.  Well, what do I do
now, boss?



-- 


                                           Mike Elliott
                                           elliottm@beach.csulb.edu
Newsgroups: comp.lang.modula3
From: yost@adobe.com (David Yost)
Subject: Re: What is the current status of GNU Modula 3?
Organization: Adobe Systems Incorporated
Date: Mon, 14 Sep 1992 05:45:41 GMT

In article <MOSS.92Sep2223534@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>It's the raft of little things, such as complete floating point and string
>support, all the built in functions, etc., etc., that we're mostly into now
>... I think you might see something without threads by the end of the
>calendar year.

Hmmm, sounds like you've decided to do floating point before threads.
Here's a vote that says you should get something running and out there
first, then add threads, then floating point.

 --dave yost
From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Newsgroups: comp.lang.modula3
Subject: Re: Constructors in Modula-3
Date: 15 Sep 92 12:22:37 GMT
Reply-To: pk@rwthi3.informatik.rwth-aachen.de
Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany

In article 92Sep14133341@tolstoy.uwaterloo.ca, mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:
>
>I proposed what I think is a simple solution to this problem a couple
>months ago, but got no response.  My solution was to add a pragma, say
><*NO NEW*>, that can be affixed to type declarations in an interface.
>E.g.,
>
>        INTEFACE foo
>           <*NO NEW*> TYPE T <: U;
>           PROCEDURE New(x: INTEGER): T;
>        END foo.
>
>In the presence of this type declaration, NEW cannot be used to create
>objects of type T.  This forces the user of the interface to use
>whatever constructor procedures are supplied in the interface; in this
>case "New".  (Of course, NEW could still be used inside a module that
>implements foo.)
>
No, *please* no more pragmas. If you want to have a feature in the
language standard, then introduce a new keyword. Everything else leads
to portability problems. I see a certain use for pragmas if they don't
change the semantics of a program, like <* OBSOLETE *> or <* INLINE *>.
(What about INLINE anyway? Will it ever be supported?) But what you suggest
definetely changes the semantics, and should therefore be a keyword (just 
like <* EXTERNAL *>, which is actually no pragma either).

>What I would really like to see is a keywork, say PRIVATE, that does
>what <*NO NEW*> does.  I think it is a mistake in the language design
>that Modula-3 tries to guess whether NEW should be allowed based on
>how much is known about a type.  Whether NEW is allowed is really
>orthogonal to whether a type is completely opaque, partly revealed, or
>fully revealed.
>
Yes. For constructors, this would be an acceptable solution.

Peter
---
Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
D-5100 Aachen
Germany
Newsgroups: comp.lang.modula3
From: joachim@nada.kth.se (Joachim Hollman)
Subject: Standard interfaces in M3 - no I/O?
Originator: joachim@spirit.nada.kth.se
Reply-To: joachim@nada.kth.se (Joachim Hollman)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 10 Sep 1992 11:14:21 GMT


After reading Nelson's ``Systems Prpgramming with Modula-3'' I have the 
impression that the standard intefaces in M3 are

1. Text
2. Thread
3. Word
4. Floating-point

while the RECOMMENDED intefaces are

1. Fmt    (Textual formatting)
2. Pkl    (``pickles'' - binary files, depends on Wr and Rd, see below)
3. Table  (Generic hash tables).

SRC Modula-3 also provides interfaces for input and output
(Wr, Rd, Stdio, FileStream and WrClass), but these are not
part of the standard.

So the question is: 
*** Why are the interfaces for input and output not part of the standard? ***


-------------------------------------------------------------------------------
Joachim Hollman         Royal Institute of Technology                    
Tel. +46 8- 790 7188    Dept of Numerical Analysis and Computing Science  
                        Theoretical CS
                        S-100 44 Stockholm                               
                        Sweden                                           
                        joachim@nada.kth.se
-- 

-------------------------------------------------------------------------------
Joachim Hollman         Royal Institute of Technology                    
Tel. +46 8- 790 7188    Dept of Numerical Analysis and Computing Science  
                        Theoretical CS - Symbolic Computation Group
                        S-100 44 Stockholm                               
Newsgroups: comp.lang.modula3
From: ryan@ponder.csci.unt.edu (Ryan Stansifer)
Subject: Syntax of WITH and TRY
Organization: University of North Texas
Date: Wed, 9 Sep 1992 20:23:55 GMT

After programming some in Modula-3 I have come to think that the WITH
and TRY statements are wordy, especially in conjunction with other
blocks.  In thinking about the language syntax it occurred to me that
some simplification may be possible.  So, for the sake of argument I
offer the following 2 suggestions for expanding the block statement to
encompass both the WITH and the TRY statements.

Instead of
    WITH x = e DO S END
add a new kind declaration, say, WITH.
Now we write:
    WITH x = e BEGIN S END
Now we can mix VAR, CONST, WITH declarations and use only one
BEGIN/END block.  I think the WITH declarations should be separated
by semicolons like other declarations.

(There is another, perhaps more important, issue.  WITH declarations
seem to be used in two distinct ways.  One, as READONLY constant
r-values.  Two, as aliases.  Adding READONLY constants is
unproblematic, but I would hate to add a new "alias" declaration when
they are really READONLY constants of type reference, reference in the
C++ sense.)

Instead of
    TRY S EXCEPTION Handler END
we could follow the example of Ada and tack on an exception part
to the block.  Now we write
    BEGIN S EXCEPTION Handler END
This permits declarations can be added to the block without
extra BEGIN/END pairs.

I do not wish to touch off another language-changing war.  I'm just
curious about the advantages and disadvantages of different approaches.
From: rogers@fangorn.wr.tek.com (Roger Southwick)
Newsgroups: comp.lang.perl
Subject: Re: "client" program (Camel book pg 338/339)
Date: 15 Sep 92 20:56:14 GMT
Organization: Tektronix, Inc.
X-Newsreader: Tin 1.1 PL5

Roger Southwick (rogers@fangorn.wr.tek.com) wrote:

: Hi fellow perl hacks....
: 
: I'm fairly new to comp.lang.perl, and so if this subject has come up before, 
: I apologize.... I've only been reading this newsgroup for 2 weeks.
: 
: I've been playing with the "client" program on pg 338/339 of the Camel
: book and I've been unable to make it work.

Never mind, I found my error (blush).

I found the sources for the examples in the Camel Book on
ftp.uu.net in the /netshell/perl directory in a file called perl.tar.Z
and I ftp'ed that over and diff'ed it with my program....

Sigh.  It would help if I use the same variable name.

Sorry for any panic.

--
    -Roger      (Roger.S.Southwick@tek.com)
		UUCP:	...!uunet!tektronix!Roger.S.Southwick
From: joslin_paul@ae.ge.com
Newsgroups: comp.lang.perl
Subject: Re: Tips and Techniques...
Date: 11 Sep 92 13:59:36 GMT
Reply-To: joslin_paul@ae.ge.com
Distribution: na
Organization: GE Aircraft Engines
Originator: news@c0228.ae.ge.com

merlyn@ora.com (Randal L. Schwartz) writes:

>       merlyn       534    1666     576

>Ooops... coming up a distant third?  How embarassing. :-)

Nah, it's just that 90% are one-line JAPH's. :-)

>seek(DATA,-26,2);print <DATA> __END__ Just another Perl hacker,
See?
-- 
-- 
     Paul R. Joslin     |Dan Quayle's Top 10 TV complaints:
joslin@c0223.ae.ge.com  | 10. Nobody ever "beams up" William Shatner on
   +1 513 583 3537      |    Rescue 911.
From: lwall@netlabs.com (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: aub problem finding sys/socket.ph
Date: 9 Sep 92 07:08:54 GMT
Organization: NetLabs, Inc.

In article <1992Sep9.043504.7463@odin.corp.sgi.com> stantz@sgi.com (Mark Stantz) writes:
: 		require <sys/socket.ph>;

Note that might not work with angle brackets, depending on how the
globbing was done.  Did the original poster use angle brackets?
You really oughta say

	require "sys/socket.ph";

It's only accidental that it works with angle brackets on many machines.

Larry							Bush/Gore '92
From: merlyn@ora.com (Randal L. Schwartz)
Newsgroups: comp.lang.perl
Subject: Re: What's the difference between `command` and system('command')?
Date: 11 Sep 92 15:54:38 GMT
Article-I.D.: romulus.MERLYN.92Sep11085435
	<peter.716216984@merlin>
Organization: Stonehenge Consulting Services; Portland, Oregon, USA

In article <peter.716216984@merlin> peter@merlin.acadiau.ca (Peter Steele) writes:
   Where does error output go (i.e., stderr)? I have an application
   where I want to capture error output, not stdout.

stdin and stderr are inherited from the Perl process for backticks.
Use /bin/sh redirection to dup them to the proper places:

	$foo = `some_command 2>&1`; # get both stderr and stdout in string
	$bar = `some_cmd 2>&1 >/dev/null`; # get *only* stderr

It's important not to reverse those two redirections in the second
example, or you'll get nothing!

print `perl -e 'die "Just another Perl hacker,\n"' 2>&1`
--
Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
merlyn@reed.edu (guest account) merlyn@ora.com (better for permanent record)
cute quote: "Welcome to Portland, Oregon -- home of the California Raisins!"
Newsgroups: comp.lang.perl