HDTenEightyP/NetNews huggingface dataset:
From: 6035230@LMSC5.IS.LMSC.LOCKHEED.COM (Charles Schulz)
Subject: Re:  Looking for good APL2 book
Organization: Lockheed Missiles & Space Company, Inc.
Date: Mon, 25 Jan 93 11:48:05 PST

------------------------- Original Article -------------------------
Newsgroups: comp.lang.apl
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: Re:  Looking for good APL2 book
Date: Sun, 24 Jan 1993 03:09:33 GMT

In article <1993Jan20.065531.22302@Princeton.EDU>,
lardieri@phoenix.Princeton.EDU (Stephen Lardieri) writes:

>>  I would like to learn the APL2 language and am looking for
>>  recommendations on a good book to buy.  I would prefer a book that
>>  does not assume I will be using one particular computer system.
>>  ...
>>  I will be using APL2 1.3.0 on an IBM 3090 ... I will eventually be
>>  using STSC APL on a PC ...

"APL2 at a Glance", by Brown et. al. is pretty good at an elementary
level, which is fortunate as it's the only general introduction to APL2
that I know of.  For more depth, the choice is clear (to me):  the IBM
APL2 Language Reference.  ...

END---------------------- Original Article -------------------------

More detail and contact info for APL2 books:

Renaissance Data Systems -- all APL books in print?
PO Box 20023
Park West Finance Station
NY, NY  USA  10025-1510
(212) 864-3078

SIGAPL book sale -- surplus supplies of various books
Robert G. Brown, executive editor of Quote-Quad:
116 Bentley Avenue
Old Bridge, New Jersey, USA  08857-1336
Robert_Brown@MTS.cc.Wayne.edu

IBM manuals to start with:
- "An Introduction to APL2" (SH20-9229)
- "APL2 Programming: Language Reference" (SH20-9227)

Other books:
- "APL2 at a Glance", Brown et. al., (ISBN 0-13-038670-7, Prentice Hall)
- "APL:  An Interactive Approach", Gilman & Rose (220-471-30022-5, Wiley)

/Charles A. Schulz
Lockheed Missiles & Space Co., Inc.
Sunnyvale, California  94088-3504
Tel:  408-742-5277
E-mail:  cschulz@lmsc.lockheed.com
Newsgroups: comp.lang.apl
From: kurt@dna.lth.se (Kurt Swanson)
Subject: J is NOT APL (was Re: Interpreter advice sought.)
Organization: Lund Institute of Technology, Sweden
Date: Sat, 23 Jan 1993 10:05:53 GMT

kurt@dna.lth.se (Kurt Swanson)  [That's me] writes:
>Is there any "free" apl *interpreter* available for UNIX and/or MAC's???
                     ===

Many have written to me tell me about the wonders of J.  Thanks, but
I'm not interested.  I've used it. It's not APL.

To me the "enhancements" of J from APL are minimal, and certainly not
enough to swallow that terrible ASCIIzation of the language (even if
you can say J is a modification of APL).

In these days of fonts galore, graphical windows (of many types),
postscript, and last but not least UNICODE, there is NO reason to
switch to an antiquated 7-bit US standard.

From a pure programming theory standpoint, J is flawed where APL is
not.  APL uses real mathematical symbols that, (get this), perform
what they look like they should.  J uses cryptic combinations of
overloaded operators taken from a subset of english punctuation.  Talk
about unreadability!!!
-- 
Kurt Swanson, Dept. of Computer Science,
Lunds universitet.  Kurt.Swanson@dna.lth.se
Newsgroups: comp.lang.apl
From: wchang@phage.cshl.org (William Chang in Marr Lab - CSHL)
Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
Organization: Cold Spring Harbor Lab, Long Is New York
Date: Tue, 26 Jan 1993 15:41:46 GMT

Oh my.  A year ago I started one of these, with a posting of
"APL/!".  There was a huge amount of traffic (for this group),
and I saved it all.  Anyway, I think an ASCII APL is useful
for telecommunications (who in this group runs APL through
a modem?) and occasionally for printing to non-postscript
devices.  I actually implemented a second design, "APL?!",
and used it on occasion.  

I'll repost APL/! (12/31/91) and APL?! (3/30/92).  Although
some details have changed, the design philosophies haven't.

-- Bill Chang (wchang@cshl.org)   Cold Spring Harbor Lab., NY
Newsgroups: comp.lang.apl
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
Organization: Dept. of Computer Science, University of Ottawa
Date: Mon, 25 Jan 93 14:40:21 GMT

In article <C1EIJn.I3@quadsys.com> roland@quadsys.com (Roland Besserer) writes:
>hui@fid.morgan.com (Roger Hui) writes:
>: There are some simple tests of this assertion.  For example,
>: try posting the text of an APL function to this news group, 
>: using the system editor on your machine to construct the message.
>
>This is certainly not a valid point. To hopelessly confuse the syntax
>and limit it to agonizingly obscure sequences of punctuation
>characters for the sake of being able to post verbose sources is
>nonsense. 

Is this an invalid point because you don't WANT it to be a valid
point, or is it invalid because the communication of source code is
unimportant?

It appears that you're implying that it is relatively unimportant
whether or not source code can be made portable.  Much of the REST of
the world thinks that portability is HIGHLY important.

The syntax is most definitely NOT limited to "agonizingly obscure
sequences of punctuation characters" - it is quite possible (and can
be useful) to RENAME the various syntax components.  On a system that
has a sufficiently verbose character set that, say, included the APL
character set, you could assign the commands to the appropriate
character.

On the other hand, J allows one to apply power similar to that of APL
in virtually any environment, whether it has "funny characters" or
not.  Moreover, it allows you to make applications portable.

Yes, it tends to look like "line noise".  So does APL, to the
uninitiated.

-- 
Christopher Browne                |     PGP 2.0 key available
cbbrowne@csi.uottawa.ca           |======================================
University of Ottawa              | Genius may have its limitations, but
Master of System Science Program  | stupidity is not thus handicapped.
Newsgroups: comp.lang.apl
From: abalje47@ursa.calvin.edu (Alan Baljeu)
Subject: Re: Surrogate arguments in J 3.0
Organization: Calvin College
Date: Fri, 22 Jan 1993 20:16:57 GMT

Brian Schott writes:

>I have been reading Alexei Skurihin's article "Neural networks in J" from
>the Russian APL92 Conference.  His code does NOT contain the surrogate
>arguments x. and y. presumably because early versions of J accomplished
>this differently: How?

I believe this hasn't changed.  However, it is possible in J to take a function
using x. and y. and transform it so that it no longer contains any x.'s or y.'s
This produces what is known as a pure, or tacit function.  See APL91 for
some articles discussing this.

--
			Alan Baljeu
This signature is.
From: mdanjou@gel.ulaval.ca (Martin D'Anjou)
Newsgroups: comp.lang.apl
Subject: PostScript Files under APL*STSC /386 II ver. 4
Date: 22 Jan 93 19:50:03 GMT
Organization: Universite Laval

Hello,
	In the manuals, STSC says that we must install port 10
in order to be able to print postscript files with the POSTSCRIPT
workspace.
	We have a PostScript printer but it is not connected to the PC on
which APL2 runs.
	How can I get the POSTSCRIPT functions to print to a file instead of "port 10"?

PS: I hope I do not have to write a assembly prog. to redirect port 10 to a file.

Thanks
Martin d'Anjou
mdanjou@gel.ulaval.ca
From: 6035230@LMSC5.IS.LMSC.LOCKHEED.COM (Charles Schulz)
Newsgroups: comp.lang.apl
Subject: Re: APL on SPARC
Date: 26 Jan 93 19:37:34 GMT
Organization: Lockheed Missiles & Space Company, Inc.

------------------------- Original Article -------------------------
Newsgroups: comp.lang.apl
From: roland@quadsys.com (Roland Besserer)
Subject: APL on SPARC
Organization: QUAD Systems
Date: Mon, 25 Jan 1993 08:24:23 GMT

..

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.

..
END-----------------------------------------------------------------------------

MicroAPL's APL.68000 and related products:

US distributor:
     Spencer Organization
     24 Wampum Road
     Park Ridge NJ 07656
     USA
     Tel. (201) 307-9099
     Fax  (201) 307-9404
Direct:
     MicroAPL Ltd.
     South Bank Technopark
     90 London Road
     London SE1 6LN
     UK
     Tel. 44-71-922-8866
     Fax  44-71-928-1006

/Charles A. Schulz
Lockheed Missiles & Space Co., Inc.
E-mail:  cschulz@lmsc.lockheed.com
From: 6035230@LMSC5.IS.LMSC.LOCKHEED.COM (Charles Schulz)
Newsgroups: comp.lang.apl
Subject: Sorry about extra copies
Date: 25 Jan 93 21:54:36 GMT
Article-I.D.: LMSC5.93025.50076.6035230
Organization: Lockheed Missiles & Space Company, Inc.

Sorry about extra copies re the APL book references.  Our posting hung
up a few times, then got flushed.

/CAS
Newsgroups: comp.lang.apl
From: 6035230@LMSC5.IS.LMSC.LOCKHEED.COM (Charles Schulz)
Subject: Sorry for extra copies
Organization: Lockheed Missiles & Space Company, Inc.
Date: Mon, 25 Jan 93 13:48:43 PST

Sorry for the extra copies of book references note.  Posting hung
up a few times here, then got flushed.

/CAS
Newsgroups: comp.lang.apl
From: hui@fid.morgan.com (Roger Hui)
Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
Organization: Morgan Stanley & Co., New York, NY
Date: Sat, 23 Jan 1993 11:30:19 GMT

Kurt Swanson writes:

> ... 
> In these days of fonts galore, graphical windows (of many types), 
> postscript, and last but not least UNICODE, there is NO reason to 
> switch to an antiquated 7-bit US standard.  
> ...

There are some simple tests of this assertion.  For example,
try posting the text of an APL function to this news group, 
using the system editor on your machine to construct the message.
Newsgroups: comp.lang.apl
From: sam@csi.jpl.nasa.gov (Sam Sirlin)
Subject: Re: Weaning  myself from Matlab: is APL a viable alternative for scientific programming and signal processing?
Originator: sam@kalessin
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Sat, 23 Jan 1993 02:04:33 GMT


In article <WEG.93Jan19140548@mace.cc.purdue.edu>, weg@mace.cc.purdue.edu (Eythan Weg) writes:
|> Can someone try to build a linear algebra (for example) version of J?
|> It seems to be very simple had I known C.  The components are there,
|> free, as I am told by this group.  Is it not a matter of compilation
|> with few extra defintions for LinkJ?  So, where is your hacking
|> spirit?  Any volunteers?

What would need to be done:

 - pick the right functionality from LAPACK etc, the minimum imho
   would be general qr and qz
 - use f2c to translate the routines, probably ignoring possible
   inefficiencies (?) from column/row orientation reversal to start with
 - link them into J

I'm familiar with the first 2, having done the same sort of thing to
get domino working in the compiler I'm hacking. But I haven't used
linkJ yet... I do intend to do this someday, but seeing as I have lots
of other things to due these days can't say when.

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

Newsgroups: comp.lang.apl
From: wchang@phage.cshl.org (William Chang in Marr Lab - CSHL)
Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
Organization: Cold Spring Harbor Lab, Long Is New York
Date: Thu, 28 Jan 1993 15:34:32 GMT

I'd appreciate any feedback regarding APL?! and APL/!.
In theory, I agree that we are moving toward more complex glyph 
sets, particularly as PDAs become more popular.  In practice,
however, and for at least several years to come, we have a
problem.  Not so much ASCII vs APL glyphs, but different
uses of glyphs by the APL vendors.  Things get very complicated
very quickly...  I have in front of me five incompatible APLs!
(IBM APL2 for RS6000; DEC VAXAPL; MIPS Dyalog APL for Sparc;
APL.68000 II for the Mac; orphaned STSC APL*PLUS for the Mac.)
Each requires a custom set of bitmap and postscript fonts,
keyboard mapping, translation software, etc. etc. etc.

My hope is that an ASCII standard can act as a neutral lingua
franca, a device for communication--electronic or otherwise.

Again, this was hotly debated last year, but not much came of it.

-- Bill Chang (wchang@cshl.org)
Newsgroups: comp.lang.apl
From: 6035230@LMSC5.IS.LMSC.LOCKHEED.COM (Charles Schulz)
Newsgroups: comp.lang.apl
Subject: Re:  Looking for good APL2 book
Date: 25 Jan 93 21:12:27 GMT
Article-I.D.: LMSC5.93025.47547.6035230
Organization: Lockheed Missiles & Space Company, Inc.

--------------------------------Original note----------------------------
Newsgroups: comp.lang.apl
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: Re:  Looking for good APL2 book
Date: Sun, 24 Jan 1993 03:09:33 GMT

In article <1993Jan20.065531.22302@Princeton.EDU>,
lardieri@phoenix.Princeton.EDU (Stephen Lardieri) writes:

>>  I would like to learn the APL2 language and am looking for
>>  recommendations on a good book to buy.  I would prefer a book that
>>  does not assume I will be using one particular computer system.
>>  ...
>>  I will be using APL2 1.3.0 on an IBM 3090 ... I will eventually be
>>  using STSC APL on a PC ...

"APL2 at a Glance", by Brown et. al. is pretty good at an elementary
level, which is fortunate as it's the only general introduction to APL2
that I know of.  For more depth, the choice is clear (to me):  the IBM
APL2 Language Reference. ...

END-----------------------------Original note----------------------------

More detail and contact info for APL2 books:

Renaissance Data Systems -- all APL books in print?
PO Box 20023
Park West Finance Station
NY, NY  USA  10025-1510
(212) 864-3078

SIGAPL book sale -- surplus supplies of various books
Robert G. Brown, executive editor of Quote-Quad:
116 Bentley Avenue
Old Bridge, New Jersey, USA  08857-1336
Robert_Brown@MTS.cc.Wayne.edu

IBM manuals to start with:
- "An Introduction to APL2" (SH20-9229)
- "APL2 Programming: Language Reference" (SH20-9227)

Other books:
- "APL2 at a Glance", Brown et. al., (ISBN 0-13-038670-7, Prentice Hall)
- "APL:  An Interactive Approach", Gilman & Rose (220-471-30022-5, Wiley)

/Charles A. Schulz
Lockheed Missiles & Space Co., Inc.
Sunnyvale, California  94088-3504
E-mail:  cschulz@lmsc.lockheed.com
Newsgroups: comp.lang.apl
From: roland@quadsys.com (Roland Besserer)
Subject: Re: J is NOT APL (was Re: Interpreter advice sought.)
Organization: QUAD Systems
X-Newsreader: Tin 1.1 PL3
Date: Thu, 28 Jan 1993 08:12:20 GMT

cbbrowne@csi.uottawa.ca (Christopher Browne) writes:
: In article <C1EIJn.I3@quadsys.com> roland@quadsys.com (Roland Besserer) writes:
: >hui@fid.morgan.com (Roger Hui) writes:
: >: There are some simple tests of this assertion.  For example,
: >: try posting the text of an APL function to this news group, 
: >: using the system editor on your machine to construct the message.
: >
: >This is certainly not a valid point. To hopelessly confuse the syntax
: >and limit it to agonizingly obscure sequences of punctuation
: >characters for the sake of being able to post verbose sources is
: >nonsense. 
: 
: Is this an invalid point because you don't WANT it to be a valid
: point, or is it invalid because the communication of source code is
: unimportant?
: 
: It appears that you're implying that it is relatively unimportant
: whether or not source code can be made portable.  Much of the REST of
: the world thinks that portability is HIGHLY important.
: 

The ability to upload/view program sources with a standard text edit
is unrelated to the issue of portability. Portability simply means the
existance of a functional and syntactic standard available and adhered
to on diverse hardware/software environments. If current communications
software imposses restrictions on the transmission and viewing of program
sources utilizing anything more than 7-bit ASCII, there is always the
simply solution to use an encoding scheme, transfer the code in question
and decode it. Yes, this apporach is inconvenient, but it should bot
be a constraint in the design of a language. 
 
: The syntax is most definitely NOT limited to "agonizingly obscure
: sequences of punctuation characters" - it is quite possible (and can
: be useful) to RENAME the various syntax components.  On a system that
: has a sufficiently verbose character set that, say, included the APL
: character set, you could assign the commands to the appropriate
: character.
: 

A valid point. 

: On the other hand, J allows one to apply power similar to that of APL
: in virtually any environment, whether it has "funny characters" or
: not.  Moreover, it allows you to make applications portable.
: 

Portability is never really a problem with an infant language. Should
J proliferate it will face the same portability problems as any other
language.

: Yes, it tends to look like "line noise".  So does APL, to the
: uninitiated.

Here I most strongly disagree with you. APLs character set and nomenclature
are easily recognizable as they are based on mathimatical symbolism 
familiar to most of us. J simply overloads ASCII punctuation characters.
-- 

--------------------------------------------------------------------------------
Roland Besserer          QUAD Systems, Santa Cruz             roland@quadsys.com
Newsgroups:   comp.lang.apl
From:         eem@ipsaint.ipsa.reuter.COM (Mcdonnell, Eugene E.)
Subject:      quote on APL interpreted
Reply-To:     eem@ipsaint.ipsa.reuter.COM (Mcdonnell, Eugene E.)
Organization: Reuters Information Services (Canada)
Date:         22 Jan 93 17:00:06 UT


-----------Message forwarded from IPSA Mailbox-------------


no. 6922348 filed 16.26.22  fri 22 jan 1993
from eem
to   uclapl
subj quote on APL interpreted

Richard Gaylord is puzzled by the awkward Englishing of a 
sentence given in translation from the French, and attributed to 
Anthony Hoare.

My recollection is that the quote is not due to the Englishman 
Hoare but rather to the Dutchman Dijkstra, who, in an 
epigrammatic survey of the major programming languages, circa 
1970, which was generally more insulting to other languages than 
to APL, wrote about it, as best as I can recall, that "APL is a 
mistake carried out to perfection."  Praising with faint damn.  
Dijkstra came to visit the IBM Research laboratory in Yorktown 
Heights, New York, I believe about 1968, and was led into Ken 
Iverson's office there, where Ken gave him an introduction to 
APL.  He showed no response.  


-----------------------------------------------------------
This posting is forwarded from an internal Reuters mailbox.
No statement or opinion contained herein should be taken as
being Reuters policy, or even as being approved by Reuters,
in any way.
Newsgroups: comp.lang.apl
From: ljdickey@math.uwaterloo.ca (L.J. Dickey)
Subject: Re: branching in proposed ISO standard
Keywords: branching goto ISO APL flow control structure:w
Organization: University of Waterloo
Date: Fri, 22 Jan 1993 13:11:56 GMT

In article <1993Jan22.001626.10902@csi.jpl.nasa.gov> sam@csi.jpl.nasa.gov (Sam Sirlin) writes:
>
>In article <1993Jan21.155458.21218@nntpd2.cxo.dec.com>, mark@11srus.enet.dec.com (Mark Eklof) writes:
>|> 	If you mean things like if-then-else, and such, they aren't intended
>|> to be there.  I'm not aware of any APL implementations that include them, and
>|> I don't recall proposals for them.

>Actually there have been some in the literature. I like the ideas of
>FHD van Batenburg, APL91 regarding dyadic .goto. J has some as well.

Yes, that fine article has received a lot of attention, and it is not
the is not the only one on the subject.  But I think that the meaning
of "proposal" intended by Mark in this context is somewhat more
formal.  The work of the ISO APL Working Group in the development of
Committee Draft 1, (now available by anonymous ftp from
watserv1.uwaterloo.ca), has been to work from proposals that were
submissions from various national standards bodies.  I suspect that it
was these proposals that Mark was referring to.  Readers will likely be
interested to know that the ISO APL Working Group restricted itself to
adding only features to the previous standard that exit in current
implementations.  This is not a rule that other programming language
standards groups have stuck to, and it is not clear that the APL group
will stick to it in the future.  So, in this context, and with the
exception of Quad-EA, there were no proposals on "if-then-else" or
"while-do", or other control structures.

I would like add that the subject of structuring APL code is currently
one of great interest, and that several people have been working and
writing on it.  I believe that it is likely that more than one
paper presented at APL93 will be on this topic.

Lee Dickey

-- 
Prof. Leroy J. Dickey, Faculty of Mathematics, U of Waterloo, Canada  N2L 3G1
   Internet:      ljdickey@math.UWaterloo.ca
                  ljdickey@math.waterloo.edu
   UUCP:          ljdickey@watmath.UUCP
Newsgroups: comp.lang.apl
From: sam@csi.jpl.nasa.gov (Sam Sirlin)
Subject: Re: branching in proposed ISO standard
Originator: sam@kalessin
Keywords: branching goto ISO APL
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Fri, 22 Jan 1993 00:16:26 GMT


In article <1993Jan21.155458.21218@nntpd2.cxo.dec.com>, mark@11srus.enet.dec.com (Mark Eklof) writes:
|> 	If you mean things like if-then-else, and such, they aren't intended
|> to be there.  I'm not aware of any APL implementations that include them, and
|> I don't recall proposals for them.

Actually there have been some in the literature. I like the ideas of
FHD van Batenburg, APL91 regarding dyadic .goto. J has some as well.

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

Newsgroups: comp.lang.apl
From: 6035230@LMSC5.IS.LMSC.LOCKHEED.COM (Charles Schulz)
Subject: Re:  Looking for good APL2 book
Organization: Lockheed Missiles & Space Company, Inc.
Date: Mon, 25 Jan 93 11:38:08 PST

------------------------- Original Article -------------------------
Newsgroups: comp.lang.apl
From: Mike Kent <70530.1226@CompuServe.COM>
Subject: Re:  Looking for good APL2 book

In article <1993Jan20.065531.22302@Princeton.EDU>,
lardieri@phoenix.Princeton.EDU (Stephen Lardieri) writes:

>>  I would like to learn the APL2 language and am looking for
>>  recommendations on a good book to buy.  I would prefer a book that
>>  does not assume I will be using one particular computer system.
>>  ...
>>  I will be using APL2 1.3.0 on an IBM 3090 ... I will eventually be
>>  using STSC APL on a PC ...

"APL2 at a Glance", by Brown et. al. is pretty good at an elementary
level, which is fortunate as it's the only general introduction to APL2
that I know of.  For more depth, the choice is clear (to me):  the IBM
APL2 Language Reference....

End --------------------- Original Article -------------------------

More detail and contact info for APL2 books:

Renaissance Data Systems -- all APL books in print?
PO Box 20023
Park West Finance Station
NY, NY  USA  10025-1510
(212) 864-3078

SIGAPL book sale -- surplus supplies of various books
Robert G. Brown, executive editor of Quote-Quad:
116 Bentley Avenue
Old Bridge, New Jersey, USA  08857-1336
Robert_Brown@MTS.cc.Wayne.edu

IBM manuals to start with:
- "An Introduction to APL2" (SH20-9229)
- "APL2 Programming: Language Reference" (SH20-9227)

Other books:
- "APL2 at a Glance", Brown et. al., (ISBN 0-13-038670-7, Prentice Hall)
- "APL:  An Interactive Approach", Gilman & Rose (220-471-30022-5, Wiley)

/Charles A. Schulz
Lockheed Missiles & Space Co., Inc.
Sunnyvale, California
Tel:  408-742-5277
E-mail:  cschulz@lmsc.lockheed.com
Newsgroups: comp.lang.apl