HDTenEightyP/NetNews huggingface dataset:
From: neeri@iis.ethz.ch (Matthias Neeracher)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Integrated Systems Laboratory, ETH, Zurich
	<1992Aug21.000645.10078@news.columbia.edu>
	<1992Aug21.181713.11812@allegro.com>
	<1992Aug26.073312.15322@news.columbia.edu>
Date: Wed, 26 Aug 1992 14:43:45 GMT

In article <1992Aug26.073312.15322@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <1992Aug21.181713.11812@allegro.com> sieler@allegro.com (Stan Sieler) writes:
>
>>You are confusing an implementation with the definition of the language.
>>I have never had "stack dirt" in Pascal's I have used, including some on
>>intrinsically stack-based machines (e.g.: Classic HP3000), as well as on
>>register based machines (e.g.: PA-RISC based HP3000).
>
>Can't say what an implementation you are using does/does not have, but the
>language allows other implementation with the problem to exist and not
>believe they have anything to clean up for.

I'd be very surprised if there were any document by Wirth, ISO, or any other
authority which "allowed" a Pascal implementation to behave like this.

>The test for the condition is 
>whether it's possible to transfer out of a loop, and then go back in with
>out losing any context,

This is clearly illegal in Pascal.

>Why do I want a language where I have to help the compiler out by using
>odd syntax for labels?

Funny, you never seem to complain about numerical labels in Fortran.


>Why would I want to use a language where you need
>FORWARD statements because it doesn't do enough passes to do it without me?

Why slow the compiler down for programmers who wouldn't use the language
anyway :-)

>I have used much "smarter" assemblers than PASCAL's :-).
>
>Let's just say that it was "convenient" that the major weak spot of the
>language became the lynch-pin of an academic "political" event.

Huh? Are you trying to run for President (Read my lips, no new Ada mandates) ?
I don't understand what you mean with this sentence, but if you believe that
Dijkstra's GOTO article was based on the Pascal GOTO, you are mistaken.

>(Indeed
>poorly-formed GOTOs could be harmful.)

And lots of well formed GOTOs unnecessary in modern languages.

Matthias

-----
Matthias Neeracher                                      neeri@iis.ethz.ch
   "You think people really worship the devil?"
   "Sure. It's the perfect religion--you fuck up, you go to heaven"
                                     -- Andrew Vachss, _Sacrifice_
Newsgroups: alt.folklore.computers,alt.religion.computers
From: parry@yoyo.cc.monash.edu.au (Tom J Parry)
Subject: Re: Good source code to read?
Originator: parry@yoyo.cc.monash.edu.au
Organization: Monash University, Melb., Australia.
Date: Sun, 23 Aug 1992 23:43:00 GMT

Vadim Antonov (avg@rodan.UU.NET) wrote:
> In article <STEVEV.92Aug22195049@miser.uoregon.edu> stevev@miser.uoregon.edu (Steve VanDevender) writes:
> >In article <1992Aug23.010444.29042@uwm.edu>
> >markh@csd4.csd.uwm.edu (Hunk) writes:
> >   The Halting problem related to Turing Machines, and there is
> >   no such thing as a Turing Machine.
> >
> >The only reason there isn't such a thing as an ideal Turing
> >machine is that an ideal Turing machine has infinite storage.
> >Any digital computer is functionally equivalent to a Turing
> >machine with a finite storage tape.  Therefore the halting
> >problem still applies to digital computers.  If you write a
> >purported halting problem solver for a digital computer, I can
> >give you a program that it can't decide the halting status of.
> 
> Add "in a time lesser than O(2**capacity of all memory in bits /
> machine clock frequency)".
> 

There is a very nifty way of showing that the Hal;ting problem is
unsolvable. 

Assume that it is solvable and it is available as a function halt(P,I)
where P is the program and I the input to it. halt returns true or
false.

Now write a program (the lecturer here called it funny if I remember
correctly). All funny does is the following:

funny(P)
{
	if halt(P,P)
		while (1) do {};
	else
		exit;
}

In other words, if P halts when given it's own source as input, go into
an infinite loop, if it doesn't halt, exit. So far, given our original
assumption, everytihng is OK.

Now consider what happens if you call funny(funny) [but at the same time
imagine a very straight faced lecturer talking about this funny-funny
creature, it adds to the effect]. Funny calls the halt() function to ask
if it will halt on it's own input (i.e. will funny(funny) halt?), if
halt() says it does halt, then it loops forever, if halt says it loops
forever, it halts.

Now this leaves us with a problem. It doesn't work. The halt() function
is wrong in this case. We must then find our error. Considering that the
program above is pretty straightforward, legal and correct, the only
thing suspect here is our assumption that halt() is computable. Therefor
it can not be.

It may not be the most mathematical of proofs but it sure is a fun one
[oops, no pun intended].

-- 
Tom J Parry.
Your reality is a figment of my imagination.
From: ALAN@VM1.McGill.CA (Alan Greenberg)
Newsgroups: alt.folklore.computers
Subject: Re: If parallel ports are unidirectional, how can PostScript work?
Date: 25 Aug 92 22:11:47 GMT
Organization: McGill University

In article <BtGGrx.Bx2@world.std.com>
dpbsmith@world.std.com (Daniel P. B. Smith) writes:
 
>A few years go by.  I see PostScript printers on PC parallel ports.  And
>I see them on LAN's.  I ask the PC people how the problem of reading the
>feedback that comes back from the printer is handled.  They say: "Huh?
>It's a printer.  It's output only. Nothing comes back."
 
 The 8 data leads on the original IBM PC (and its clones) were
 unidirectional, as onw would expect, given that it was a straight
 implementation of the Centronics printer interface.  On the PS/2
 (and its clones), the data flow was made bi-directional.
 
 There are some LAN adapters which attach to the printer port
 on PCs.  If it is a PS/2-style port, the bidirectional
 byte path is used.  If it is an old-style PC port, the inbound
 data is sent by toggling the printer ready signal.  Slows the
 data down a bit (but not as much as one would imagine), but an
 innovative solution!
 
>Also, there are fair number of stalled and mysteriously aborted jobs.
 
 Sounds more like a badly configured system than a design bug.
 
 Alan
From: koen@blade.stack.urc.tue.nl (Koen Holtman)
Newsgroups: alt.folklore.computers
Subject: Re: On the care and feeding of GOTOS
Date: 31 Aug 92 13:38:12 GMT

rh@smds.com (Richard Harter) writes:
 [....]
>Or at least you can interpret them that way.  As Knuth observed in one
>of his essays, proof of correctness of goto/label programming is very
>simple -- for each label there is an assertion that states what conditions
>must be satisfied for a legitimate transfer to that label.  For each
>goto there must be a proof that the preconditions for transferring to
>the target label hold.

This method is only sufficient for proving _partial_ correctness, that
is `if the program halts, it will have produced the right result'

For proving _total_ correctness, the program halts and gives the
right result, you need more than that.

Let's see.. Take an integer variable PUX that does not apear in the
original program, and replace all GOTO X statements by 
PUX:=PUX-1;GOTO X. Now prove with Knuth's method that during the
execution of the new program, the value of PUX will never drop
below zero. Assume any initial value for PUX that you want, and no,
infinity does not count as an integer.

If your program contains any (ack! ugh!) _structured_ loop constructs,
also add a PUX:=PUX-1 to the end of each loop body. 

If you can prove that PUX will never drop below zero, then you know that
the program will end. Needless to say, proving this is slightly unsimple
in most cases.

 [....]
>Of course this is only theoretical -- very few programmers document each
>label with the preconditions for transferring to the label.  [The number
>zero springs to mind.]

Very few programmers document their code at all....

But if they do:

FILRR     BLWP @0       file not open, give up

I would say `file not open' is the precondition of FILRR.

ObFolklore: what assembly am I using?

>Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Koen Holtman                  TUE computing science     "Dat zieje wel"
koen@blade.stack.urc.tue.nl    (Ax:*p)==(*p&p!=&x)         --Multatuli
From: zlsiida@fs1.mcc.ac.uk (dave budd)
Newsgroups: alt.folklore.computers
Subject: Re: ISO date format
Date: 26 Aug 92 13:01:39 GMT
Organization: Manchester Computing Centre

In article <BtKC5s.IpG@news.cso.uiuc.edu> pereckas@uxa.cso.uiuc.edu (pereckas michael s) writes:

>sverkerw@Minsk.docs.uu.se (Sverker Wiberg) writes:

>>kjell@elixir.e.kth.se (Kjell Rilbe) writes:
>>>Hey, I didn't know this date format was used anywhere outside Sweden! 

>I'm American, and I always use it.  Of course, I use SI units in
>everyday life, too.  It sorts nicely, it makes perfect sense, and I
>can always say it is an international standard if anyone asks why I
>use it.  When I create files with a date in the name, I always use the
>related format yymmdd, which is compact and shows up in order when
>sorted.

I got sick'n'tired of the difference between US mm dd yy and UK dd mm yy
and the posssible (though rare) confusion, and so switched to yy mm dd some 
time ago.  Nobody has ever questioned it, so I guess they find it clear 
enough.  I use the old UK system for stuff like cheques though.  What I like 
about yy mm dd is that it fits the standard idea in numbering systems that 
the rightmost digit changes fastest.  Putting yy first alerts the reader 
to the format.

+---------------------------------------------------------------------+
|  What should always be remembered about England is that from 1950   |
|  to 1957 one of the most popular acts on RADIO was a VENTRILOQUIST  |
|  Dave Budd, MCC, Oxford Rd, Manchester, England   (44)061-275-6033  |
+---------------------------------------------------------------------+
Newsgroups: alt.folklore.computers,alt.religion.computers
From: parry@yoyo.cc.monash.edu.au (Tom J Parry)
Subject: Re: Good source code to read?
Originator: parry@yoyo.cc.monash.edu.au
Organization: Monash University, Melb., Australia.
Date: Wed, 26 Aug 1992 03:26:11 GMT

Vadim Antonov (avg@rodan.UU.NET) wrote:
> 
> You fell in the very same trap. For the beginning, a halting
> analyzer which is able to handle any program which can run on
> the machine WILL NOT BE ABLE to run on the same machine simply
> because it will require additional memory (for the source program
> and for the primitive itself). It still has NOTHING to do with
> the solvability of the halting problem.
> 

does that not assume that the analyzer must RUN the program? Assuming such
a program existed, is it not possible that a scanning the source/object
code could be enough. In this case you do not need the same amount of
memory as the program you are analysing would need if it were running.

-- 
Tom J Parry.
Your reality is a figment of my imagination.
Xref: sparky alt.folklore.computers:13600 comp.unix.misc:3507
From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 1 Sep 92 21:27:41 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <1992Aug31.100545.9840@unmvax.cs.unm.edu> ctm@ardi.com (Clifford T. Matthews) writes:
[entire personal attack and other offensive stuff deleted]

The argument comes down to a quite simple point:

Matthews claims that his code duplicates the assembler algorithm.  It doesn't,
rather it mimics it using longword arithmetic to circumvent the problem of
being ignorant of the potential for algorithmic failure.  On many machines the
use of extra precision is either unavailable or a potentially severe tradeoff
of either space or speed.  In any case, there is always a problem since this
is a "pyramid structure" argument because how can you implement the last
generation of the algortihm for a given precision arithmetic when you just
ran out of bits?

The fact that gcc implements the DP trick indicates that it is true that a
compiler can use second-rate tricks, it in no way validates any claims of
superiority to hand assembly.  It would be interesting to find a version of
GCC that can generate MS-DOS-compatible code for execution on 8086/88 and/or
80286 where this algorithm can't be done.  Curiously enough the minimum gcc
implementation is for 80386.  (That's why there are GNU-ish projects; they
need Microsoft or Borland's "inferior" compilers to get implemented.)

The ultimate point of all of this is that, as others have pointed out, C
is not the panacea that Matthews and others believe it is.  His misguided
belief in the algorithm he stumbled across in no way affects the technical
merits of any of my arguments against the expediency of hll usage, especially
C.  High-level language was developed with the understanding of a tradeoff
of performance vs. development ease.  Matthews wants to handwave that into
the notion that the tradeoff is nonexistent.  And we never got into the
more substantive issues of interrupt handling w/foreground handling in
real-time or the *efficient* use of co-routines, etc.

This is not an attack on the work of Richard Stallman and other fine
programmers, who use both assembler and hll where they see fit.  The parameters
of their requirements guide them as necessary.  Their position isn't as far
afield from mine as Matthews et al would indicate.  I just refuse to ascribe
larger-than-life properties to compilers.

An interesting additional point about C was brought up several times on the
newsgroup: that it isn't *high* enough.  Higher-still languages may be
implemented as efficient interpreters at the top level, where all of the
internals could be implemented comprehensively in assembler to improve the
performance.   While C could be used as a model for this, a better version
written in assembler could be a potential goal for any given implementation.
Languages such as APL come to mind, etc.

cjl
Newsgroups: alt.folklore.computers
From: fetrow@biostat.washington.edu (David Fetrow)
Subject: Re: Branching in HLL vs. Assembler (was Re: The need for an assembler)
Organization: Biostatistics, School of Public Health, Univ. of Wash.
Date: Wed, 2 Sep 1992 00:32:48 GMT

In article <180bscINN2jd@rodan.UU.NET> avg@rodan.UU.NET (Vadim Antonov) writes:
>In article <1992Sep1.083701.2898@pollux.lu.se> magnus@thep.lu.se (Magnus Olsson) writes:
>>Speaking of spaghetti code, one common reason for writing spaghetti
>>code was (is?) the lack of a line-renumbering utility in primitive
>>BASICs...
>>
>> [example deleted]
>>
>>Horrible? Yes, of course, but the alternative (manually renumbering
>>maybe hundreds of lines) would be even worse.
>
>And writing a 10-lines long program to do it automatically is 
>obviously above mental abilities of both users and authors of
>such BASIC interpreters.
>
>Not funny.
>

 Well, it's a LITTLE more complicated than that. You have to renumber the
GOTOs to match the new labels. Say 100 lines of BASIC.

 If anyone is interested: At ftp.biostat.washington.edu in /pub/sun4 I
stuck the binary for Chipmunk Basic Interpreter for a SPARC (as shipped
with the marveleous p2c [Pascal to C] translator program). Yes, you too
can recall those thrilling days of yesteryear.........



-- 
 - dave fetrow-					fetrow@biostat.washington.edu

 "Never underestimate the ability of large potential profits to
  make technically inferior technology into a workable standard."
From: malmberg@umsa8.umd.edu (Norwin Malmberg)
Newsgroups: alt.folklore.computers
Subject: Re: GOTOs
Date: 1 Sep 92 15:04:05 GMT

IQTI400@INDYCMS.IUPUI.EDU (macphil) writes:

[snip]
>There are scenarios where a GOTO is a timesaver in the short-haul and
>even more where it's an immediate convenience.  There are very few
>situations where they are absolutely, positively necessary.  The
>ability to distinguish these situations is fairly rare when it comes
>to the off-the-shelf, run-of-the-mill programmer/analyst simply
>because most are not *good* programmers writing high-quality code.

>I'm betting 99+% of COBOL programs used by the average business for
>doing nothing more than running various sort/summary/total reports
>would be significantly improved by allowing businesses to purchase
>a COBOL compiler which flagged "GOTO" as a syntax error.  Similar
>arguments could be made for many other languages in their native
>habitats.  Only when you get to extremely complex situations could
>you start attempting to make serious efforts against this argument.

>I'm not a COBOL-bigot, I'm just pointing this out as one of the
>most-abused languages which can be highly procedural and fairly
>easy to read when used properly.

OK, I'll admit it - I used to program in COBOL.

I have seen all too many COBOL programs where the person had been told
"You should never use a GOTO".  In general, these programs contain
strange switches to handle control flow, force you to flip pages all
over the place when trying to trace how they work (since every little
thing is handled by a separate paragraph, usually not on the same page),
and generally are a pain to trace.  They also have a tendancy to exhibit
strange bugs because of all those switches.

In particular, there is the "read records from a file and process them
until there are no more records".  Doing this without a GOTO usually
looks like this:

MOVE "NO" TO NO-MORE-RECORDS.
PERFORM READ-AND-PROCESS UNTIL NO-MORE-RECORDS = "YES".

READ-AND-PROCESS.
  READ IN-FILE AT END
    MOVE "YES" TO NO-MORE-RECORDS.
  IF NO-MORE-RECORDS NOT = "YES"
    PERFORM PROCESS-RECORD.

Rather clumsy.  By comparison, it looks fairly clean using a GOTO:

READ-RECORD.
   READ IN-FILE AT END
     GO TO NEXT-ROUTINE.
   [Process record]
        .
        .
        .
   GO TO READ-RECORD.
NEXT-ROUTINE.
    etc.

In general, GOTOs can be used in COBOL in a clean manner, producing more
readable code than not using them.  I will admit that it is possible to
write spaghetti using GOTOs, but avoiding GOTOs at all costs often ends
up with even more confusing code.

Speaking for myself,

Norwin Malmberg
malmberg@umsa.umd.edu
From: pete@minster.york.ac.uk
Newsgroups: alt.folklore.computers
Subject: Re: Longtime PDP-11 users, tune in now
Date: 3 Sep 92 12:25:29 GMT
Organization: Department of Computer Science, University of York, England
X-Newsreader: Tin 1.1 PL5

Michel BILLAUD (billaud@mistral.greco-prog.fr) wrote:
: 
: Other gigabytes are saved when poor student X types "rm *>bak" instead
: of "rm *.bak". The Unix way of garbage collecting ?  :-)

Not funny. Something like this once happened to me on a keyboard with a
sticking shift key. Caused much aggravation, but fortunately everything
that was zapped was on tape too...

Pete Fenelon
--
*Peter Fenelon -- Research Associate -- Software Safety Assessment Procedures*
Dept. of Computer Science, University of York, York, Y01 5DD (+44/0)904 433388
EMAIL: pete@minster.york.ac.uk `There's no room for enigmas in built up areas'
Newsgroups: alt.folklore.computers
From: sasrer@unx.sas.com (Rodney Radford)
Subject: Re: Apple /// (and MANY other computers)
Date: Fri, 28 Aug 1992 05:45:36 GMT
Organization: SAS Institute Inc.
Keywords: antique

kenm@compctr.ccs.csus.edu (Ken Montgomery) writes:

      (impressive list of old computers deleted to save space)

>	So, are there any others out there? What do you have/would like
>to have? I hope to find an Apple I, and I'd like to add a NeXT to my
>collection some day.  Well???

Well this was actually discussed a few months ago when everyone posted
there list.  I did as well, but since then my list has changed and now
consists of: 9 3000/4000/3500 Apollo workstations, a TRS-80 Model I (with
builtin 300 baud modem), a TRS-80 Model 2, 2 TRS-80 Model IIIs, a TRS-80
Model IV, a TRS-80 Model IVP, 2 Apple II+s, an Apple IIe, two 8088 IBM
clones, an 8080 based Sol, a Pet 2001, an Atari 400, 2 Corvus Constellation
systems, and probably several others that I cannot think of right now!

Just call me the CCAA - Cary Computer Adoption Agency: got a computer that
needs a home, or a home that needs a computer? Who do you call? CCAA!!!

--
---
Rodney Radford          || Computer Graphics/Imaging
sasrer@unx.sas.com      || SAS Institute, Inc.
(919) 677-8000 x7703    || Cary, NC  27513

Newsgroups: alt.folklore.computers
From: brumby@nella11.cc.monash.edu.au (Stephen McNamara)
Subject: Re: Coke machine at CMU
Organization: Monash University, Melb., Australia.
Date: Fri, 4 Sep 1992 10:26:12 GMT

9125113g@lux.latrobe.edu.au (Mitch Davis) writes:

>In article <BtxJ98.Iw6@xcluud.sccsi.com> paul@xcluud.sccsi.com (Paul Hutmacher) writes:
>>In article <87501@netnews.upenn.edu> jarnot@kin.lap.upenn.edu (Kevin J. Jarnot) writes:
>>>I have recently heard of a Coke machine at CMU that is connected to the 
>>>Internet.  Anyone have the whole story???
>>I'd like the ip address so I could ftp a Coke or something.
>From "The Hacker Test":
> > 0023 Have you ever wanted to download pizza?
>I know what you mean...

   A pizza shop that was local to me used to advertise 'Computerised Pizza
Delivery'. I was always intending to go in and ask what baud rates they
supported.

   How long does it take to d/load a pizza at 1200 baud? (All I can afford.)


-- 
     The Silver Brumby of          brumby@yoyo.cc.monash.edu.au
      the Silicon Plains

      The grass is always greener on the other side of the network.
From: rorschak@daimi.aau.dk (Jesper Lauridsen)
Newsgroups: alt.folklore.computers
Subject: Re: 24-hour clocks (was: Microwave ovens ...)
Date: 30 Aug 92 11:49:36 GMT
Organization: Danish Trainspotter Society

klaus@diku.dk (Klaus Ole Kristiansen) writes:

>HT (the local bus company) gets around this by changing the date at a
>time where no train or bus is going. This means that not only can a bus
>leave at 24, it can also leave at 25 or 26. A friend of mine once had
>a ticket issued 27:15. That's right, 27 o'clock!

I have a train ticket with a date stamp of 34:something on it (bought
past midnight (but not much)).

-- 
I have things to do and News to read
Newsgroups: alt.folklore.computers
From: sverkerw@Minsk.docs.uu.se (Sverker Wiberg)
Subject: Re: The Need For An Assembler
Organization: UDAC, Uppsala, Sweden
Date: Tue, 25 Aug 1992 22:13:55 GMT

ddb@tdkt.kksys.com (David Dyer-Bennet) writes:
> SW> A chainsaw is the only tool anyone will ever need.
> SW> No! A scalpel is the only tool anyone will ever need!
> SW> Is not!
> SW> Is so!
> SW> (fight ensues)

>Yes.  But which is which?

And who will win?
--
#include<stddisclaim.h>	         Every interesting data structure is recursive.
sverkerw@mizar.docs.uu.se (Sverker Wiberg)		                  /Cons
     This mission is too important for me to allow you to jeopardize it. -- HAL
     We're on a mission from God.                             -- Blues Brothers
Newsgroups: alt.folklore.computers