HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.misc
Subject: Re: BCPL
From: billk@hawk.cs.ukans.edu (Bill Kinnersley)
Date: Thu, 21 Jan 1993 01:57:31 GMT
Organization: University of Kansas Computer Science Dept
Keywords: where`o'where

In article <1993Jan20.190512.27223@ee.rochester.edu> weisberg@ee.rochester.edu (Jeff Weisberg) writes:
: I recently came across a book on BCPL (the language).  It is  in-
: teresting  to see where features of C evolved from.  I thought it
: would be interesting to give it a try, and was wondering if  any-
: one  has,  or  knows  about an implementation I could get up on a
: sun3, to try out the language, before I try  to  throw  something
: together myself.
: 
The following message, which was posted a little more than a year ago,
might give you a lead:



From: ken@syd.dit.CSIRO.AU (Ken Yap)
Newsgroups: comp.os.cpm,comp.os.msdos,alt.sources
Subject: BCPL for CP/M, MSDOS and Unix
Date: 11 Oct 91 02:00:22 GMT

There's a BCPL* compiler bootstrap kit with an INTCODE interpreter in
C.  It compiles on CP/M, MSDOS and Unix.  Executables for CP/M and DOS
are also provided.  You can get it from ftp.syd.dit.csiro.au
[130.155.128.3] in [.languages]bcpl.tar_z (VMS machine).  The kit is
based on the INTCODE bootstrap technique explained in the book BCPL:
The language and its implementation, Richards and another (not certain
of title, book's at home).

Remember, it's an interpretive system for bootstrapping purposes, so
expect a 10 to 20 times hit compared with native code.

The interpreter was done for fun so it's offered as is, no support,
USTL.  But if you do anything weird with it, do let me know.

*BCPL (Basic Combined Programming Language) is a system programming
language invented by Martin Richards. It's a typeless language with
only one data type, the machine word.  Some of its ideas have
influenced C.
-- 
--Bill Kinnersley
  billk@hawk.cs.ukans.edu
226 Transfer complete.
From: cathy@otago.ac.nz
Newsgroups: comp.lang.misc
Subject: ML for MS-DOS ??
Date: 28 Jan 93 15:26:28 +1300
Organization: University of Otago, Dunedin, New Zealand

Is there a version of ML which will run on an IBM (or clone)
Thanks
From: barreraa@lamar.ColoState.EDU (Azael Barrera)
Newsgroups: comp.lang.misc
Subject: Looking for a PD/Share/Low-cost-commercial COBOL
Date: 26 Jan 93 20:11:55 GMT
Organization: Colorado State University, Fort Collins, CO  80523

Hello:

I am looking for a either low-cost COBOL compiler for DOS or a public domain
version.  I found a PD version called COBOL650.zip, by a fellow named
Nowek, who apparently notified on a file that he was dying.  Did somebody
made any improvements to this PD version to make it COBOL-85 compliant? If
so, where I can find that "refurbished" version?

On low cost version I once heard about a "Utah-COBOL" or "Nevada-COBOL".
Can anyone point me in the direction to find the vendors of these low-
cost commercial versions?

Any hint on the above questions is greatly appreciated. Please send your
replies/answers to:
    barreraa@lamar.colostate.edu (Internet)

A.B.
Newsgroups: comp.lang.misc
Newsgroups: comp.lang.misc
Subject: Re: BCPL
From: billk@hawk.cs.ukans.edu (Bill Kinnersley)
Date: Thu, 21 Jan 1993 13:00:51 GMT
Organization: University of Kansas Computer Science Dept
Keywords: where`o'where

In article <1993Jan20.190512.27223@ee.rochester.edu> weisberg@ee.rochester.edu (Jeff Weisberg) writes:
: I recently came across a book on BCPL (the language).  It is  in-
: teresting  to see where features of C evolved from.  I thought it
: would be interesting to give it a try, and was wondering if  any-
: one  has,  or  knows  about an implementation I could get up on a
: sun3, to try out the language, before I try  to  throw  something
: together myself.
: 
FTP the file /systems/amiga/programming/languages/BCPL/BCPL4Amiga.lzh
from wuarchive.wustl.edu.  It's the original INTCODE interpreter for
BCPL.  You can ignore the Amiga-specific stuff, it has #ifdef's for
Unix and MSDOS.

-- 
--Bill Kinnersley
  billk@hawk.cs.ukans.edu
226 Transfer complete.
Newsgroups: comp.lang.misc
Subject: Re: Language called ABC ? - thanks for responses!
From: comjohn@ccu1.aukuni.ac.nz (Mr. John T Jensen)
Date: Mon, 25 Jan 1993 19:27:04 GMT
Organization: University of Auckland, New Zealand.

comjohn@ccu1.aukuni.ac.nz (Mr. John T Jensen) writes:

>I have been told of a language called ABC, available for DOS, Unix, etc,
>that does unlimited precision arithmetic.  Source anyone?

Thanks, everyone, for the many helpful responses.  I haven't attempted to
reply to each of you individually - please excuse me! - but have more than
enough info now.  Now all I need is time to follow up on it!

jj

John Thayer Jensen                      64 9 373 7599 ext. 7543
Commerce Computer Services              64 9 373 7437 (FAX)
Auckland University                     jt.jensen@auckland.ac.nz
Private Bag 92019
AUCKLAND
New Zealand
From: dgarrett@engr.LaTech.edu (Don Garrett)
Newsgroups: comp.lang.misc
Subject: Modularity for Data-Driven languages
Date: 27 Jan 1993 07:56:19 GMT
Organization: Louisiana Tech University
NNTP-Posting-Host: gmssun.engr.latech.edu
X-Newsreader: TIN [version 1.1 PL8]

	I'm looking for any information about previous work done to
add modularity constructs to forward-chaining, data-driven langauges
such as OPS5, or YAPPS. While I've heard that someone-somewhere has
tried to do this before, I've had little luck finding any sort of
articles, or information about it. I'd appreciate any pointers to
information about what has been done, where, and by who, as well as
what success whoever(whom?) has had.

						Thanks,
							Don

--
Don Garrett                                                      Louisiana Tech
dgarrett@engr.latech.edu                                             University
From: comjohn@ccu1.aukuni.ac.nz (Mr. John T Jensen)
Newsgroups: comp.lang.misc
Subject: Language called ABC ?
Date: 24 Jan 93 19:42:26 GMT
Article-I.D.: ccu1.1993Jan24.194226.28717
Organization: University of Auckland, New Zealand.

I have been told of a language called ABC, available for DOS, Unix, etc,
that does unlimited precision arithmetic.  Source anyone?

jj

John Thayer Jensen                      64 9 373 7599 ext. 7543
Commerce Computer Services              64 9 373 7437 (FAX)
Auckland University                     jt.jensen@auckland.ac.nz
Private Bag 92019
AUCKLAND
New Zealand
Newsgroups: comp.lang.icon
From: norman@flash.bellcore.com (Norman Ramsey)
Subject: separate compilation with iconc?
Organization: Bell Communications Research
Date: Tue, 26 Jan 93 21:22:01 GMT


With icont, I can compile separate Icon files into ucode, then link
them in a separate step.  Is there a way to do the analogous thing
with iconc?  If I try `iconc -c grammar.nw', it complains that there's
no main procedure.

Norman
From: nall@ibm12.scri.fsu.edu (John Nall)
Newsgroups: comp.lang.icon
Subject: Re: Rremoving entab/detab from Icon
Date: 26 Jan 93 22:47:47 GMT
Reply-To: nall@ibm12.scri.fsu.edu (John Nall)
Organization: SCRI, Florida State University

In article <30836@castle.ed.ac.uk> eddie@castle.ed.ac.uk (Eddie Corns) writes:
>
>Surely the best person to decide whether a feature should be in the library or
>the language itself should be the end user.

 ...

>"The customer is always right."  Just
>my opinion, feel free to disregard it.

Excuse me?  My newsfeed must have malfunctioned - apparently the
smiley faces didn't make it.

Free software?  That suits most of us very well?  And the "customer" is
going to say "change this" or "change that"?  Come on, now, guys..:-)
You've got the source - if you don't like something about it, change
the sucker!

John


-- 
John W. Nall              | Supercomputer Computations Research Institute
nall@mailer.scri.fsu.edu  | Florida State University, Tallahassee, Florida
  "Why yes, as a matter of fact, I DID vote for Hillary!!" - me
From: eddie@castle.ed.ac.uk (Eddie Corns)
Newsgroups: comp.lang.icon
Subject: Re: Rremoving entab/detab from Icon
Date: 26 Jan 93 20:56:15 GMT
Organization: Edinburgh University


Surely the best person to decide whether a feature should be in the library or
the language itself should be the end user.  Can we not think up some scheme
whereby those who don't need the overheads or whatever of unwanted features
can remove them.  Things like entab and friends could be supplied as part of a
standard library and also in the language.  If some way of removing them from
the language (or conversely building extra functions into the language) could
be found then we have the best of all possible worlds.  Just a thought.

This is similar to debates like whether langauages should support variable
numbers of arguments.  Those of us who find them useful say yes but others
complain that the overheads are too high.  But of course those who don't want
them don't use them and hence occur no overheads and the rest of us put up
with the extra overheads when we feel they are useful.  Should we have strong
or weak typing? -- let the user decide, add more information into a language to
give the user the control _they_ need.  "The customer is always right."  Just
my opinion, feel free to disregard it.

Eddie
From: vladimir.grodzenski@lill.frmug.fr.mugnet.org (Vladimir Grodzenski) 
Newsgroups: comp.lang.icon
Subject: Happy Holidays
Date: 18 Jan 93 10:24:00 GMT
Distribution: world
Organization: Li'LL BBS - Paris, France
Reply-To: vladimir.grodzenski@lill.frmug.fr.mugnet.org (Vladimir Grodzenski) 

Hi, Chris !

 Thanx for your contribution! Alas, I haven't succeeded to run any
 of your programs... I suspect that your messages that I recieve here
 are missing some few lines. It'll be safe to give us [at the end of
 your message] the number of lines of .ICN source and/or a list of
 procedures.

V.
---
 * SLMR 2.1a * 
                                                             
Newsgroups: comp.lang.icon
Date: Wed, 20 Jan 1993 12:44:36 MST
From: "Ralph Griswold" <ralph@cs.arizona.edu>
Subject: New Implementations of Icon

The latest version of Icon, 8.7/8, is now available for the
following platforms:

	MS-DOS
	MS-DOS/386
	Macintosh MPW
	OS/2
	UNIX
	VMS

The OS/2, UNIX, and VMS versions support the X-Icon graphic
facilities.

This is the same version of Icon that has been available until now
for only Unix and VMS.  Compared to previous versions, this version
adds some new functions, keywords, bug fixes, and other improvements.
Document IPD188 (also available by FTP) describes the features of
Version 8.7; Version 8.8 is essentially identical from an external
standpoint and differs only in internal details.

To pick up program material electronically, do an anonymous FTP
to cs.arizona.edu, cd /icon, and get READ.ME for navigation
instructions.

Persons who have Internet mail access but not FTP access can get
files via ftpmail.  For instructions, send an e-mail message with
the word

	help

in the message body (not the subject line) to

	ftpmail@cs.arizona.edu

Please address any questions to icon-project@cs.arizona.edu, not
to icon-group.
    
Ralph E. Griswold			ralph@cs.arizona.edu
Department of Computer Science 		 uunet!arizona!ralph
The University of Arizona		602-621-6609 (voice)
Tucson, AZ 85721			602-621-9618   (fax)

Newsgroups: comp.lang.icon
Date: Sat, 23 Jan 1993 11:54:17 MST
From: "Gregg Townsend" <gmt@cs.arizona.edu>
Subject: builtin Icon functions

I am amused by postings that state "I never use X, so I suggest that X
should be removed from the library".   That's an awfully self-centered
view.  While I never use acos() or bal(), that doesn't mean that I think
they should be deleted.

A more defensible criterion is the one states "If it can be programmed 
in Icon, it belongs in the IPL instead of being a builtin function".  
At least that one is unbiased.  Of course, that would mean we'd lose
useful functions like tab(), right(), and trim() -- and just think
about the performance of a map() function written in Icon!

My own opinion is that a large repertoire of preprogrammed operations
greatly increases the utility of a language, whether these are supplied
as operators or builtin functions.  Certainly FORTRAN would not have
succeeded without its math library.  Accordingly, I support the inclusion
of tab(), bal(), sin(), detab(), and other functions, and would like to
see more.

The IPL just isn't the same although it is indeed very useful and
underappreciated.  Usage is more difficult because one must set up the
programming environment to find the files, add link directives to the
Icon programs, and perhaps deal with version conflicts.

The argument is made that all these functions make Icon harder to learn.
There is some truth to that, especially when they're all thrown together
in one large bag with no indication of where a new student should start;
but that's a presentation problem, not a language problem.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    +1 602 621 4325     gmt@cs.arizona.edu     110 57 16 W / 32 13 45 N / +758m

Newsgroups: comp.lang.icon
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Re: Rremoving entab/detab from Icon
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago
Date: Wed, 27 Jan 1993 14:48:18 GMT

John Nall writes (concerning the idea that the "customer is always
right"):

>Excuse me?  My newsfeed must have malfunctioned - apparently the
>smiley faces didn't make it.
>
>Free software?  That suits most of us very well?  And the "customer" is
>going to say "change this" or "change that"?  Come on, now, guys..:-)
>You've got the source - if you don't like something about it, change
>the sucker!

Just for the record, you can't just go into the Icon source tree and
change things.  Gotta know the language and the implementation.  For
many, especially those who don't spend their lives grubbing around in
systems programming languages like C, altering things would not be
practical.

By "customer" I think the poster simply meant "user."  The Icon Project
is distinguished from most academically based research efforts in having
one eye on the user at all times.  At least that's been my experience
with them.

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
Newsgroups: comp.lang.icon
Date: Sun, 24 Jan 93 12:19:12 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
Subject: Rremoving entab/detab from Icon

I may have used entab/detab occasionally, but I don't remember using
them.  Moving them to the library would make sense, however, only if
semantic equivalence could be guaranteed, i.e., one could always repair a
program using entab/detab by adding appropriate library loads.  Lacking
such equivalence, it would be a mistake to remove them from the language.
Incompatible change is dangerous--you never know who will get stung, or
with what effect.
 
That principle, of course, can be carried to extremes.  While deleting
merely useless facilities isn't worth the hazard, deleting facilities
that interfere with sensible programming often is justified.  Some of the
changes from K&R C to ANSI C probably fall into that category.
 
The best example I can think of of a terrible language facility that is
almost impossible to remove is the COMMON/EQUIVALENCE stuff in Fortran.
I haven't followed developments in the Fortran world for a long time, but
I know that people have been most hesitant to tinker with COMMON/
EQUIVALENCE because of how the changes might impact programs in use in
critical applications such as aeronautical engineering and nuclear power
plant control.

Newsgroups: comp.lang.icon
Date: Sat, 23 Jan 93 00:10:44 MST
From: whm@shepard.sunquest.com (Bill Mitchell)
Subject: Re: entab/detab

I suspect that usage of entab/detab (mostly the latter) is related to one's
dialects of implementation techniques and input designs.  Personally, in ten
years of Icon programming, I've never had a strong urge for either entabbing
or detabbing and if I've ever used entab/detab, I can't remember it.

detab users: Why do you typically use it?  To make intra-line whitespace
always be blanks?  To make sure that what would print in column N on the
screen is the Nth character in a string?  What else?

My opinion is that entab/detab should have been left as IPL procedures.
I don't think that the idiom they provide is used frequently enough to
justify inclusion in the language.
From: GOMBERG@UCSFVM.BITNET (Dave Gomberg)
Newsgroups: comp.lang.rexx
Subject: Re: OS/2 Linein
Date: 28 Jan 93 18:49:32 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

To close a file in REXX, invoke LINEOUT specifying just the filename:

 x=LINEOUT('c:myfile')

Please let us know if this does not resolve your problem.   Dave

Dave Gomberg    GOMBERG@UCSFVM  Internet node UCSFVM.UCSF.EDU     fax-> 7797
Seven Gateview Court, San Francisco CA 94116-1941      voice-> (415)731-7793
Newsgroups: comp.lang.rexx
From: jbrock@csfb1.fir.fbc.com (John Brock)
Subject: Re: Lower-case alphabetic set
Reply-To: uunet!csfb1!jbrock
Organization: First Boston Corporation
Date: Fri, 22 Jan 1993 18:20:10 GMT

In article <JT.93Jan21151108@fizyk1.fuw.edu.pl>, jt@fuw.edu.pl (Jerzy Tarasiuk) writes:
|> >>>>> On Wed, 6 Jan 1993 15:50:37 GMT, MCMASTER@LSTC2VM.stortek.com (Jim McMaster) said:
|> Jim> Nntp-Posting-Host: lstc2vm.stortek.com
|> Jim> In article <C0E55F.IK5@csfb1.fir.fbc.com>
|> Jim> jbrock@csfb1.fir.fbc.com (John Brock) writes:
|>  >In article <C0CDCz.Co3@csfb1.fir.fbc.com>, jbrock@csfb1.fir.fbc.com (John Brock) writes:
|> >|> How about:
|> >|>   lowercase: procedure
|> >|>   return translate(arg(1), xrange(), translate(xrange()))
|> >|>
|> >|> I like this because it is consise and generic.  It should work as it
|> >|> stands for any language, and it lets me avoid typing out all the upper
|> >|> and lower case letters by hand (which I think looks ugly, even though
|> >|> it's clearly more efficient to do it that way).
|> 
|> I am afraid it is character-set-dependent and implementation-dependent:
|> note every uppercase alpha occurs in input table TWICE, since it isn't
|>  [...deleted...]

You're right!  My procedure depends on the fact that in both ASCII and
EBCDIC the lower case letters occur before the upper case letters.  In
fact it would be possible to devise an 8 bit character set in which all
of the letters were scattered about at random, and even xrange('a','z')
would be meaningless.  To write a lowercase() function that is
completely generic and which reverses the translate() function you
would have to go through the entire character set, test which
characters were affected by translate(), and use only those characters
to build your translate tables.

Maybe REXX should just be given an untranslate() function.

-- 
John Brock
uunet!csfb1!jbrock
jbrock@csfb1.fir.fbc.com
Newsgroups: comp.lang.rexx
From: jt@fuw.edu.pl (Jerzy Tarasiuk)
Subject: Re: Lower-case alphabetic set
Organization: Warsaw University Physics Dept.
Date: Thu, 21 Jan 1993 13:39:31 GMT

>>>>> On Wed, 6 Jan 1993 16:03:11 GMT, MCMASTER@LSTC2VM.stortek.com (Jim McMaster) said:
Jim> Nntp-Posting-Host: lstc2vm.stortek.com
Jim> In article <1993Jan5.064658.4491@schbbs.mot.com>
Jim> TCSAR03@waccvm.corp.mot.com (Germain Leutwyler) writes:
>Here is another routine to translate each letter from uppercase to
>lowercase. You may specify the characters that shouldn'tbe converted
>in the verify function.
>/* TRANSLATION OF CERTAIN CHARACTERS WITHIN STRING "ST" TO LOWERCASE */
>ST=''
>do P=1 to length(ST)
> C=substr(ST,P,1)
> if verify(C,'?!0123456789')/=0 then C=bitxor(C,' ')
> ST=ST||C
>end

It would be better to use verify to check if character belongs to
uppercase alpha:
	if verify(C,'ABCDEFGHIJKLMNOPQRSTUVWXYZ')=0 then C=bitxor(C,' ')

Jim> This works, but only for EBCDIC, and is much slower than the built-in
Jim> translate function.

This works for ASCII, too. ASCII 'A'=0x41,'a'=0x61,' '=0x20
			   EBCDIC 'A'=0xC1,'a'=0x81,' '=0x40
Newsgroups: comp.lang.rexx
From: TTZ488@waccvm.corp.mot.com (Hugh Dunn)
Subject: Re: rexx in tso environme
Organization: Motorola
Date: 21 Jan 1993 05:32:24 MST

>------------------------- Original Article -------------------------
>From: "stephen brackenbury" <stephen.brackenbury@canrem.com>
>
>Greetings,
>
Hello Stephen

>
>These are probably very simple questions, but:
>
> 1) How does one create a Rexx program in TSO?
Put it in a file called 'pgname.CLIST' with the first line of
the file being a REXX comment e.g.   /* REXX */

>
> 2) Does TSO recognize a Rexx program by the same comment card that OS/2
>    recognizes Rexx?
See above

>
> 3) Does it have to be compiled?
No

>
> 4) How is it submitted?  Does it require JCL to run?
Type EX pgname from ready prompt, or you can use JCL steps to run it.

>
> 5) Is there a standard IBM manual or book that someone could recommend
>    to help me get up and running in Rexx TSO?
There is an IBM manual called;
TSO Extensions Version 2 (Procedures Language MVS/REXX Reference)
that I find very useful.
>
>
>If someone could provide me with a short summary of the usual steps
>involved in creating a TSO Rexx program as well as a very simple example
>of a TSO Rexx program I'd be more than grateful.
>
>Thanks in advance!
>
You will REALLY need the manual, espicially if you want to run in
batch mode. Also, there are TSO specifics to the REXX implementation on
MVS.

Hope you find this helpful, however if you need further info the email m
and I'll see if I can help.

Hugh
TTZ488@waccvm.corp.mot.com
Newsgroups: comp.lang.rexx
From: richg@hatch.socal.com (Rich Greenberg)
Subject: Re: Ascii Dictionary Needed!
Organization: Hatch Usenet and E-mail.  Playa del Rey, CA
Date: Tue, 26 Jan 1993 03:38:44 GMT

In article <2962.imc@uk.ac.ox.prg> imc@comlab.ox.ac.uk (Ian Collier) writes:

>This depends on what system the passwords are for.  Certainly on Unix there
>are many guidelines on what passwords should look like, but I never heard of
>any such restrictions on VM except for the blatantly obvious (e.g. no AAAAAAA
>or QWERTY) (note that it does no harm to be safe, however).  The reason is
>that while the Unix passwords file is encrypted and globally readable, VM
>passwords are kept secure (and, I believe, unencrypted) in the CP directory
>- and most VM systems revoke a userid after several successive failed
>attempts at entry.  This means that (as far as I know) it is impossible to
>write an automatic password cracker on a typical VM system.  My first
>password on a VM system at IBM was an English word.  Of course, feel free
>(indeed obliged) to correct me if the above is wrong.

In vanilla VM, passwords can be 1-8 chars, case insensitive, no restrictions.
Its stored encrypted (not a secure encryption tho) in the directory.
The directory is (normally) not readable by anyone except the
sysadmin(s).
Various add-on security packages add additional security such as
format of the password, ageing and revoking.

BTW, in Unix SVR4, the encrypted passwords are moved from /etc/passwd
to /etc/shadow to prevent someone encrypting many possible passwords
and comparing the encrypted value to /etc/passwd.
-- 
Rich Greenberg      Work: rmg50@juts.ccc.amdahl.com   310-417-8999
N6LRT               Play: richg@hatch.socal.com       310-649-0238
What?   Me speak for Amdahl?  Surely you jest....
Newsgroups: comp.lang.rexx
From: ckincy@cs.umr.edu (Charles Kincy)
Subject: Re: How do I get the output of other programs into my REXX program in OS/2?
Date: Thu, 21 Jan 1993 22:26:21 GMT
Organization: University of Missouri - Rolla, Rolla, MO

In article <19930121.063700.419@almaden.ibm.com> pmuellr@vnet.ibm.com (Pat Mueller) writes:
>>I know that I could pipe the utility's output to a file and then use
>>LineIn to get the data, but I would like to try to avoid that
>>cheezy approach.
>
>Pipe it to RXQUEUE, and then read the lines off the queue, as in
>
>   "DIR | RXQUEUE"
>   line.0 = queued()
>   do i = 1 to line.0
>      parse pull line.i
>   end

WOW!!  That's easy.  Thanks a lot.  :)

cpk

-- 
"The WHITE ZONE is for loading and unloading only.  If you gotta load or un-
load, go to the WHITE ZONE.  You'll love it.  It's a way of life!" --Zappa

Technology always seems to keep one step ahead of human wisdom.