HDTenEightyP/NetNews huggingface dataset:
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc
Subject: Use of hardware capabilities.  Was: Re: Pointers
Date: 10 Nov 92 14:24:01 GMT
Organization: Purdue University Statistics Department

In article <1992Nov9.121317.3914@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:
>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>>Computer hardware quite properly uses pointers, and any software that
>>does not is just making life difficult for the users.

>Firstly, computer hardware does not necessarily use pointers.

>Secondly, where different architectures do use pointers, the definition
>of them can be quite different. As I have already said, Unisys A Series
>have quite a different kind of pointer to that which C likes. In fact
>the hardware defines a higher level more problem oriented kind of pointer
>than C.

>Thirdly, if you want direct access to hardware capabilities, then you may
>as well use assembler. The disadvantages should be well known. Such languages
>are solutions or 'how' oriented, not problem and 'what' oriented. This means
>that you are not implementation independent, which makes portability difficult.
>This also makes maintainability difficult. This style of programming locks
>you into certain ways of doing things, instead of giving you the freedom
>that higher level languages give you.

It is very difficult to be completely implementation independent, but I
agree it is a good idea to be partially portable and partially implementation
independent.  The current HLLs clearly do not have enough in them to do this;
a very simple example is the process of packing or unpacking floats, which
is mainly portable in use, but not in design.  The infamous 4.2 BSD frexp(),
which used portable code to do something weaker, and often took a long time
to do something simple (it could have even gone on forever), is an example.

In addition, assemblers have atrocious syntax.  At least provide the 
programmer with a good macro processor (a totally non-optimizing mini
compiler, which can use types, storage locations, etc.) to get around 
this.  Even in assemblers which appear to have the same syntax, they
do not; the order of the arguments is not constant for a given instruction.

Portability of certain ends does not mean portability of the means.

>Customers are becoming more sophisticated, and do not like to be locked
>into closed systems (proprietary systems are not necessarily closed), or
>into Unix for that matter. 

But is not locking into a HLL being locked into a closed system?  

Which languages allow the introduction of new operators?  Syntax is
important for both producing code and understanding it.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.lang.misc
From: a566@mindlink.bc.ca (Arne F. Hermann)
Subject: BBX SAVEP question
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 6 Nov 1992 21:11:59 GMT

At the risk of asking something offensive to some:  what scheme is used in
BASIS BBx Prog. 2 by the 'savep' command?  I'll qualify the reasons for
asking by saying that there are several commercial (and quite overpriced)
programs out there that will 'unencode' a savep'd program.  This is probably
a common
question but I'm kinda new to this forum (pls excuse).  I would welcome and
greatly appreciate a response to both this group and my e-mail address (cause
I don't always get time to read here!).  Thanks in advance.
                                                                -Arne

--
 --------------------------------------------------------------------------
| Arne F. Hermann            "BUSHMUSTDIECRACKHEROINSMACKPCPSPEEDAK-47DOPE |
| a566@mindlink.bc.ca         KILLREVOLUTIONGUNUZIKENNEDYKILLQUAYLEPEACE"  |
|                             ^^^^Spook Fodder - Hey NSA! Are ya listening?|
| "There are no philosophical absolutes but this one"                      |
|
Newsgroups: comp.lang.misc
From: dhinds@leland.Stanford.EDU (David Hinds)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 6 Nov 92 23:00:30 GMT

In article <1de9ckINNfj7@life.ai.mit.edu> tmb@ai.mit.edu writes:
>
>I do write and use long-running programs (weeks, months) that use
>multiple workstations extensively in my work.
>
>For such programs, I find that correctness and maintainability are of
>paramount importance.  Efficiency, on the other hand, is of much
>less importance.  If I run my program once for 9 weeks, I'm going to be
>much better off than if I speed it up by 30% but have to run it twice
>(for a total of 12 weeks) because I introduced some error.

Sorry, I think correctness/maintainability and efficiency are usually
orthogonal and one can usually have both.  I don't think paying
attention to efficiency has anything to do with whether or not it is a
good idea to "test" a program by letting it run for six weeks.  And
I'd expect that the speedup from "no attention to efficiency" to
"reasonable attention to efficiency" is often much more than 30%.  A
little profiling and tuning can go a long way.  And I usually run my
programs a lot more than twice.

Also, I find that rewriting code to improve its efficiency sometimes
helps me turn up bugs, if doing the "same thing" a different way gives
me a different result.  Careful profiling can also give useful data
for debugging.

When I write code, I'll try to get it running correctly first, and then
worry about efficiency, but I do eventually worry about it.  The programs
I'm developing take up to a few days on a small parallel supercomputer or
cluster of fast workstations.  And most of the code I write is reused a
lot, so tuning it impacts everything I do.  I would not start a long run
with new code without testing it first.

>I think the idea that scientific programmers have to squeeze every last
>cycle out of their machines is a myth passed on from generation to
>generation and is out of touch with the modern economic realities of
>programming. The only people who have to squeeze every last cycle out
>of their programs are real-time programmers and software/hardware
>vendors who are concerned with looking good on benchmarks.

That is an odd myth; I'd say that scientific programmers write a lot
of bad "efficient" code mainly because they write bad code, period.  I
know enough of them that are plenty eager to get as many cycles as
they can, but wouldn't spend a half-hour profiling their garbage code
to see why it takes so long in the first place.

        - David Hinds
          dhinds@allegro.stanford.edu
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc
Subject: languages which allow the introduction of new operators
Summary: lisp, of course... and maybe some others
Date: 11 Nov 92 02:11:54 GMT

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <BxI802.7EL@mentor.cc.purdue.edu>
: Which languages allow the introduction of new operators?  

Lisp.  Forth.  Postscript.  Smalltalk.  Full PL/I had the ability
to coin new statement types and keywords (though not new
expression syntax).

(To some extent, it depends on what counts as an "operator".)

: Syntax is important for both producing code and understanding it.

In Lisp, one can have any syntax one wishes, by manipulating reader
macros.  There have also been several experimental languages with
tailorable expression syntax over the years, but the feature tends to
remain unused, and the languages die out (according to discussions I've
seen on comp.compilers).
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: Pointers
Newsgroups: comp.lang.misc
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 13 Nov 92 00:37:37 PST
Organization: Missionaria Phonibalonica

In <1dujcuINNru4@early-bird.think.com>, barmar@think.com (Barry Margolin) wrote:
> C function pointers aren't like any other pointers in the language.  You
> can't do pointer arithmetic on them.

Actually, you *can* do arithmetic on them. It's just not very
portable. I've actually seen this done in production C code.

	<mike
Newsgroups: comp.lang.misc
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Pointers
Organization: University of Jyvaskyla, Finland
Date: Fri, 13 Nov 1992 07:28:34 GMT

In article <1dujcuINNru4@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
> ...
>C's function pointers are almost exactly like the procedure variables that
>many other languages have.  As in many other aspects, C has overloaded an

Indeed, I have always found it helpful to think of procedure variables
in languages like Modula-2 as actually being only pointers to procedures,
since no other operations are applicable to them than those
of pointer variables.

> ...
>case the indirection isn't required.  You can't cast between them and
>non-function pointers.

In K&R C you could (char*), and in C++ you can (void*).

 ...
>they specified the declaration syntax accordingly.  But when you look at
>C++ and its member function pointers, you see that these are more like the
>traditional procedure variables (the environment in this case is the "self"
>object); however, they've kept C's function "pointer" syntax for declaring
>them.

Actually, they are farther away from traditional procedure variables
than are ordinary function pointers.  A "member function pointer" is more
like an offset:  it does not by itself designate an object, and not even a
specific function in the case of virtual functions (dynamic binding
occurs, depending on the actual class of the object with which
the "member function pointer" is applied).

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.misc
From: jch@rdg.dec.com (John Haxby)
Subject: Re: Pointers
Organization: Digital Equipment Corporation
Date: Fri, 13 Nov 1992 10:28:13 GMT

In article <1992Nov12.141532.16375@jyu.fi>, sakkinen@jyu.fi (Markku Sakkinen) writes:

|> Don't be fooled by words.  Maybe the CLU literature does not much use
|> the word 'reference' (I don't remember), but I cannot see any semantic
|> difference between CLU variables (of non-atomic types) and reference
|> (or pointer) variables in many other languages.  'By sharing' is
|> exactly the same as 'by reference'.

In CLU, x in

	p1 = proc (x: int) ... end p1
and
	p2 = proc (x: string) ... end p2

is passed by sharing.  In the VAX implementation, the p1 has its
argument passed by value, the second by reference (in the grubby
depths).  In the PCLU implementation, both procedure calls pass
a CLUREF structure (by value) which contains the value of an integer
or a pointer to string data.  `By sharing' allows the implementation of
the compiler to choose the mechanism for passing the parameter to
a procedure, the only requirement is that changing the contents of a
mutable argument is reflected in all instances of the argument.

Don't mix implementation strategies with language semantics.

-- 
John Haxby, Definitively Wrong.
Digital				<jch@rdg.dec.com>
Reading, England		<...!uknet!wessex!jch>

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.
From: horse@netlink.cts.com (Kirk J. Parker)
Newsgroups: comp.lang.misc
Subject: Compressed numbers in COBOL
Date: 13 Nov 92 00:39:41 GMT
Organization: NetLink Online Communications, San Diego CA

Anyone know how a "compressed" number is stored in COBOL?  It seems to 
pack 13 digits in 8 bytes.  Any info would be apre~rciated.

Kirk

--                    
INTERNET:  horse@netlink.cts.com (Kirk J. Parker)
UUCP:   ...!ryptyde!netlink!horse
NetLink Online Communications * Public Access in San Diego, CA (619) 453-1115
Newsgroups: comp.lang.misc
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Pointers
Organization: University of Jyvaskyla, Finland
Date: Thu, 12 Nov 1992 08:14:54 GMT

In article <1992Nov11.155149.14744@rdg.dec.com> jch@rdg.dec.com (John Haxby) writes:
> ...
>In CLU, you can pass paramaters of type PROCTYPE to accomplish exactly
>the same thing, or you can use type parameterization (genericism if you like)
>for a similar mechanism for, often, much the same purpose.  CLU doesn't
>have references, yet alone pointers.
> ...

Actually, I think, _all_ variables in CLU are references,
except those of atomic types.  (Pretty much like LISP.)

It is a bad thing, IMO, that many languages force programmers
to use pointers or references even for purposes that would be
better solved by other means.  I would recommend people to read
Hoare's classic paper, "Recursive data structures" (Int. J. of
Computer and Information Sciences, Vol. 4 (1975) No. 2).
It's been reprinted at least in "Essays in Computing Science"
by Hoare and Jones (Prentice-Hall 1989).

It seems that not all objections against pointers in Hoare's paper
are extremely relevant, and some others have been obsoleted
by techical progress.  Enough good points still remain.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.lang.misc
From: jch@rdg.dec.com (John Haxby)
Subject: Re: Pointers
Organization: Digital Equipment Corporation
Date: Wed, 11 Nov 1992 15:51:49 GMT

In article <BxIoDv.72J@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
	...

|> >ALGOL 68 and SIMULA 67 have user-defined types, dynamic memory, and
|> >free-form syntax, no?  And why do you need explicit pointers to functions
|> >when you can have procedure types, like Modula-2?
|> 
|> You need explicit pointers to functions when the caller does not know
|> the name of the function being called, but the caller has received a
|> pointer to the function.  The same holds for pointers to arrays of
|> pointers, and to array descriptors.  If several parts of a program
|> are using the same double buffer, and are even compiled separately,
|> using a pointer to the active buffer, and another one to the refill
|> buffer, would be an excellent way to do things.

No you don't.  In Algol 68, procedures are types like anything else
so you can pass a ref proc to a procedure and let the normal coercian
de-reference and de-procedure (ie call) as necessary.  The typing
system requires that only procedures with the right mode (signature) can
be passed as parameters in this way so that the mode of the procedure
is known at compile time.

In CLU, you can pass paramaters of type PROCTYPE to accomplish exactly
the same thing, or you can use type parameterization (genericism if you like)
for a similar mechanism for, often, much the same purpose.  CLU doesn't
have references, yet alone pointers.

In Modula 3, the type system allows you to pass things as REFANY to
allow the anonyimty you crave in C, but in a type-safe fashion.  Indeed,
the Modula 3 mechanism provides rather more than the C mechanism because
you can tell what you are doing so you don't need to worry about the
more bizarre syntactic mechanisms :-)

As someone said in response (I think) to something I said, everything begins
to look like a nail when you only have a pointer to a hammer. In other languages,
older and newer, you have a choice of tools and you can choose the right one
for the job.  [I have four planes and a bastard file: you can do anything with
a bastard file and enough patience and wood; but the right plane will do the job
in a fraction of the time and it will do it right first time].


-- 
John Haxby, Definitively Wrong.
Digital				<jch@rdg.dec.com>
Reading, England		<...!uknet!wessex!jch>

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.
From: akao@.com (Adam Kao)
Newsgroups: comp.lang.misc
Subject: Re: A challenge to the anti-goto
Date: 6 Nov 92 02:52:52 GMT
Organization: Oracle Corporation, Redwood Shores, CA
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <1992Nov5.205832.8919@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
>I think all of Herman's detractors are missing the point.

Don't lump me in with all of Herman's detractors.


>For Herman, the program IS NOT the product.
>The result of the computation is.
>Herman is not a programmer. He is a mathematician. Stop trying to pretend ...

Do you think I disagree with these statements?


>He probably spent a LOT of time on it...

He probably took a machine language routine and translated it at the
keyboard into something resembling C.  He never ran it through a
compiler, which could have saved us all much time and traffic.


>:the program is the first thing we look at, often the _only_ thing,
>Ah. Wonderful. So you never bother checking on whether the algorithm
>itself is well suited to your architecture.

Logic is a wonderful thing.  Sarcasm is not.


>:and provides the bulk of our understanding.  For us, a program is
>This is fine, but not for numerically intensive, and mathematically
>deep algorithms. How does checking the code tell you if it is the most
>efficient method for yor machine?

Herman admitted there were typos that would compile while breaking
the algorithm.  How am I supposed to tell if it _works_?


>I would call what everyone is criticizing Herman for:
>An overemphasis on form and structure, rather than content.

You completely miss my point, probably because you insist on seeing
me as part of a faceless horde.

The code Herman posted isn't efficient, it's BROKEN.  Will fixing the typos
hurt the efficiency?  How about adding comments?  How about whitespace?

And what is it doing on USENET, anyway?  So we can all ignore it?  No,
so we can READ it.  In this context, there is NOTHING more important
than making it READABLE.

Once again:  we asked for a program because it's the most concrete,
factual form of communication.  Herman gave us handwaving code.


Adam
Newsgroups: comp.lang.misc
From: aldavi01@starbase.spd.louisville.edu (Arlie Davis)
Subject: Re: languages which allow the introduction of new operators
Date: Thu, 12 Nov 1992 21:03:26 GMT
Reply-To: Arlie Davis <aldavi01@starbase.spd.louisville.edu>
Organization: University of Louisville

In <1992Nov12.082643.8415@arb-phys.uni-dortmund.de> wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:

> >   >Lisp.  Forth.  Postscript.  Smalltalk.  Full PL/I had the ability
> >   >to coin new statement types and keywords (though not new
> >   >expression syntax).
> >
> >   You forgot Prolog.
> Add Ada, Algol68, TeX as well.

While you're at it, add shell script.  :)

-- 
lrwx------   1 aldavi01 emacsstu       9 Jun  6 12:43 .signature -> /dev/null
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: Pointers
Newsgroups: comp.lang.misc
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 11 Nov 92 09:26:04 PST
Organization: Missionaria Phonibalonica

In <BxJzzv.4H7@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) wrote:
> In article <mwm.2lp7@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:

This all started when herman said:
> >> >> You need explicit pointers to functions when the caller does not know
> >> >> the name of the function being called, but the caller has received a
> >> >> pointer to the function.

> >> I will consider any suggestions to do this in a better manner, but I
> >> am not willing to make it any less flexible, nor to put any more burdens
> >> on the writers of the subprogram, nor of the (usually separately compiled)
> >> fill functions.
> 
> >You want to make it better? Two things you can do. First, throw away
> >the silly attachment to pointers per se, and let the compiler handle
> >the trivia. When you call a function with a function as an argument,
> >you give it the name of the function as the argument. When you receive
> >a function as an argument, you declare it - AND USE IT - as a
> >function. That means you can drop the extra "*" on the call, and on
> >the reference to the function in the call. No explicit pointers
> >needed; they are all implicit, and might not be there at all,
> >depending on how good your compiler is.
> 
> The function is not an argument to something else.  I do not see how 
> the code will run any better if we have to use something like
> 
> 	superfill(*fl,*des)
> 
> than what I have suggested.

Herman, the code probably won't _run_ any better. It will never run
any worse, as a "dumb" implementation would map it directly back to
the pointers you used. The point is that your original statement -
about needing explicit pointers - is _wrong_. I know it's wrong; I do
just what you're talking about in a language with no explicit pointers
all the time. The original code I posted showed such a case exactly. I
apologize for using identifiers that made things clearer instead of
your favorite one-letter-with-no-relation-to-the-problem style.

> So just as many pointers are used, anyhow.

That's for the dumb compiler, or the worst-case for the smart
compiler. By getting rid of the explicit pointers, you make it
possible for a compiler to notice cases where all the functions being
passed in are known, and to generate better code to take advantage of
that.  In the extreme case, only one such function is used, and a good
compiler will generate inline code for it.

	<mike
Newsgroups: comp.lang.misc
From: slee@cse.unl.edu (Shiuh-Haw Lee)
Newsgroups: comp.lang.misc
Subject: HELP: RMCOBOL-85 -- Educational Version Restriction ???
Date: 11 Nov 92 03:02:14 GMT
Organization: University of Nebraska--Lincoln
NNTP-Posting-Host: cse.unl.edu


Hi,
  I am a student learning COBOL programming right now and the compiler that 
I am using is the RMCOBOL-85 Educational Version which came with the book.  When
I try to open 5 files, it gives me an error message saying "Educational Version
Restriction."  


<The following codes work fine.>

FILE-CONTROL.
	
	SELECT DATA-FILE ASSIGN TO INPUT-OUTPUT, "INVENT.DAT" 
		ORGANIZATION LINE SEQUENTIAL.
	SELECT SORT-WORK-FILE ASSIGN TO INPUT-OUTPUT.
	SELECT BOOK-OUTPUT-FILE ASSIGN TO PRINT, "BOOKS4.LIS".
	SELECT VIDEO-OUTPUT-FILE ASSIGN TO PRINT, "VIDEOS4.LIS".

<The following codes give error message.>

FILE-CONTROL.

	SELECT DATA-FILE ASSIGN TO INPUT-OUTPUT, "INVENT.DAT" 
		ORGANIZATION LINE SEQUENTIAL.
	SELECT SORT-WORK-FILE ASSIGN TO INPUT-OUTPUT.
	SELECT SORTED-DATA-FILE ASSIGN TO INPUT-OUTPUT, "INVENT.SRT"
		ORGANIZATION LINE SEQUENTIAL.  
    SELECT BOOK-OUTPUT-FILE ASSIGN TO PRINT, "BOOKS4.LIS".  
	SELECT VIDEO-OUTPUT-FILE ASSIGN TO PRINT, "VIDEOS4.LIS".


I wonder if there is any other way that I can use 5 files besides getting a
Commercial Version?  Is it possible to combine the last two lines in the above
code into one line yet be able to do the same task?

Any help would be appreciated.  
Thanks.



--
+-------------------------------------------------------------------+
| Shiuh H. Lee    |  E-mail :  slee@cse.unl.edu                     |
+-------------------------------------------------------------------+