HDTenEightyP/NetNews huggingface dataset:
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Pointers
Organization: University of Jyvaskyla, Finland
Date: Thu, 12 Nov 1992 14:15:32 GMT

In article <1992Nov12.103513.14043@rdg.dec.com> jch@rdg.dec.com (John Haxby) writes:
>In article <1992Nov12.081454.23507@jyu.fi>, sakkinen@jyu.fi (Markku Sakkinen) writes:
>|> Actually, I think, _all_ variables in CLU are references,
>|> except those of atomic types.  (Pretty much like LISP.)
>
>CLU has only two flavours of cluster: mutable and immutable.
>Procedure (and iterator) parameter passing is by sharing (rather than
>value or reference) since there is no notion of value or reference, only
>of the name of an object which may be one of many names.
>
>The implementation uses pointers left, right and centre for practically
>everything -- the exceptions might be int, char, bool and possibly float.
>For the VAX implementation, the native VAX implementation--the
>language is not interested in grubby pointers and references, only in names.

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'.

----------------------------------------------------------------------
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: andy@research.canon.oz.au (Andy Newman)
Subject: New Release of Tim Long's ICI Available
Organization: Canon Information Systems Research Australia
Date: Tue, 10 Nov 1992 03:05:13 GMT


For your information...

There is a new release of Tim Long's ICI language interpreter
available on extro.ucc.su.oz.au in pub/ici.cpio.Z. This version
contains some documentation! Tim has gone on a rather long holiday
and wont be contactable or able to fix bugs but if anyone finds major
problems I'd like to hear about them and may be able to help.

Enjoy.

-- 
Andy Newman (andy@research.canon.oz.au)
"Ignorance is curable, stupidity isn't." - Bill Campbell
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 11 Nov 92 14:25:20 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.uni-duisburg.de
NNTP-Posting-Host: du9ds3.uni-duisburg.de

In <721458276@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:

>: 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).

You forgot Prolog.

[...]

>Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|  | /   Dept. of Electr. Eng.   |   Sorry, the above really good fortune has
|  |/    Inst. f. Dataprocessing |      been CENSORED because of obscenity"
From: anw@maths.nott.ac.uk (Dr A. N. Walker)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 12 Nov 92 15:20:32 GMT
Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker)
Organization: Maths Dept., Nott'm Univ., UK.

In article <BxIoDv.72J@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu
(Herman Rubin) writes:
[various uses of pointers to functions, to arrays of pointers, etc.,
deleted]

	Indeed these things all have their uses, but they too are all
in Algol, and have been for 24 years now.  Two examples that may [or
may not!] gladden Dr Rubin's heart:

  a) a self-seeding PRNG:

	PROC REAL myrand := REAL: (myseed; myrand := myprng);

     ["myrand" is a pointer to a procedure that delivers a real.  It is
      initialised to point to a procedure that first does the seeding, then
      makes "myrand" point instead to the real PRNG.  The result of following
      the pointer and then obeying the procedure is delivered as the first
      PRN.  Uses of "myrand" after the first go straight to "myprng";  note
      that only one procedure is actually called, as "myrand" itself is a
      pointer, *not* a procedure.]

   b) a self-buffering geometric random-number generator:

	INT bufsize = 1024;
	[bufsize] REAL buffer;  INT bufp;
	[bufsize] PROC REAL geombuff;
	PROC REAL geom := geombuff[bufsize] :=
	   REAL: (fill buffer; geom := geombuff[1]; buffer[bufp := 1]);
	FOR i TO bufsize - 1
	   DO geombuff[i] := REAL: (geom := geombuff[bufp +:= 1]; buffer[bufp])
	   OD;
	PROC fill buffer = ( ... some code to generate the random numbers
		and fill buffer with them ...);

     ["geom" points to one of an array of (anonymous) procedures.  All but
      one of these simply returns an element of "buffer", having updated
      "geom";  the last instead fills the buffer and reinitialises the
      various pointers.  Here there is an implied context switch (but only
      one, except when the buffer is filled) each time "geom" is used, so
      we don't get the full benefits of the buffering unless a heavily-
      optimising compiler recognises that the procedure denotation inside
      the DO-loop can be in-lined.]

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 13 Nov 1992 17:43:58 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world
NNTP-Posting-Host: telecaster.think.com

In article <mwm.2mib@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
>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.

That's an implementation extension, not part of the language.  As such,
there are few constraints on how the extension is provided.  If C didn't
use pointer notation for its procedure variable declarations, an
implementation could provide an extensions that allows arithmetic on
procedure variables.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.misc
From: bs@gauss.mitre.org (Robert D. Silverman)
Subject: Re: A challenge to the anti-goto
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Thu, 5 Nov 1992 20:58:32 GMT

In article <1992Nov3.183725.11681@oracle.us.oracle.com> akao@.com (Adam Kao) writes:
 
stuff deleted....


:
:Herman, for a programmer, the program isn't some figure, or illustration,
:or formula which can be ignored after sufficiently understanding the text.
:_The_program_is_the_product_.  I'm very glad that you finally made an
:attempt to give us real code, but what you gave us _is_not_a_program_.
 
I think all of Herman's detractors are missing the point.

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 that
his objectives are the same as yours. His objective is "speed", and he doesn't
give a hoot about portability, readability, or any of the other programming
style criteria you guys keep harping about.


:I suspect that, to you, the program itself just isn't that important,
 
Bingo!

:so you didn't spend much time on it.  Try to understand that, for us,
 
I disagree. He probably spent a LOT of time on it. But he was spending
time on figuring out the fastest way to do something and the efficiency
of his code on a particular machine. 

: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.

: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?

 
I would call what everyone is criticizing Herman for:

An overemphasis on form and structure, rather than content.

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Purdue University Statistics Department
Date: Thu, 5 Nov 1992 15:07:10 GMT

In article <GLEW.92Nov4072629@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:


			....................

>Emphasize. As usual, Knuth is an arbiter of good taste in programming
>style. For example, his example of programming state machines with gotos
>is cleaner than the usual case state/variable structure.  His suggestion of 
>never allowing fallthrough into a label often clarifies code.

This may or may not be the case.  Natural fallthroughs occur frequently.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 12 Nov 1992 21:47:10 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com


I think this whole thread is incredibly silly.

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
available syntax and used it for some other meaning.  Thus, in C, a
function declaration where the name is preceded by a "*" indicates that
it's a variable that can be assigned dynamically rather than a name that
should be linked.  This is analogous to PL/I's requirement that a procedure
variable declaration have the keyword "variable" in it.

Outside the declaration, you don't even have to think of it as a pointer.
All uses of function pointers act just like they do in languages with
procedure variables: assignments reassign the variable, while using it in a
function call syntax causes the referenced function to be called.

C function pointers aren't like any other pointers in the language.  You
can't do pointer arithmetic on them.  You're not allowed to indirect
through one except when it's in a function call syntax, and in the latter
case the indirection isn't required.  You can't cast between them and
non-function pointers.

One difference between C and most of the other languages with procedure
variables is that C doesn't have nested procedures.  In the other
languages, a procedure variable generally includes both a code pointer and
an environment (in the traditional languages, which don't allow nested
procedures to be returned, this is usually a stack frame pointer).  C
doesn't require environments to be associated with functions because
they're all defined in the global environment, so the C designers could
simply implement procedure variables as pointers to the actual code, and
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.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Pointers
Organization: Los Alamos National Laboratory
Date: Fri, 6 Nov 1992 19:06:10 GMT

In article <1de603INN5qv@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> [...]
|> And it's possible to have aliasing without pointer variables.  Fortran has
|> this problem because parameters are passed by reference -- their solution
|> was simply to legislate that programs are not permitted to pass array
|> parameters (or is it all parameters) in such a fashion that such aliases
|> would occur.  It's not possible to detect this statically in the general
|> case.

Quite true.  Fortran commits the same error as C, but in the reverse
direction.  What I want is for the language to allow aliasing, allow
the user to explicitly state whether things are *really* aliased or
not (with *NOT ALIASED* and the default).  The fact that the non-alias
legislation is not statically determinable is not relevant to me: I'm
perfectly willing to take that responsibility for my use of the code.

The point is that aliasing is an *inherent* part of what pointers do,
it is merely a rarely used possibility with arrays (one which I'm
perfectly willing to do completely without).  The distinction is 
therefore naturally divided - if you *call* something an array, the
compiler assumes it's not aliased to anything; if you *call* something
a pointer the compiler assumes that it might be aliased.  In short, 
part of the distinction you make between pointers and arrays is the
explicit control over aliasing I mentioned in the preceding paragraph.

Thus, if you coerce one to the other in every procedure call, you have
lost a useful distinction.  It's a bad idea to coerce arrays to pointers.

-- 
J. Giles
Newsgroups: comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Purdue University Statistics Department
Date: Sun, 8 Nov 1992 00:54:51 GMT

In article <TMB.92Nov7233431@orac.idiap.ch> tmb@idiap.ch writes:

			........................

>Since scientists and mathematicians generally only have little time to
>spend on programming they (including myself) are probably better off
>choosing a programming language that supports safety and reuse (i.e.,
>a language with GC, runtime checks, polymorphism) and that is simple
>and regular enough so that it can be mastered fully in a short amount
>of time.

Since Algol, which ignored much that mathematicians were already doing,
there has been no language designed with the constructs used in mumerical
computations foremost, or even particularly important.  Fortran was 
designed for small programming jobs, not library functions, but it did
consider what is needed for numerical computation.

Those who rewrote my code without gotos had to work to do it.  I am not
opposed to using "structured" ideas when they help, but they often do 
not, and figuring out what is happening with a batch of unlabeled blocks
and break statements is much harder than following a natural goto
control path.  It is the way that mathematicians think, and redefining
continue to be different from Fortran is not going to help.  Requiring
a function call when a goto is what is really wanted, and hoping that 
the compiler can decide if this is what is wanted, or a call-return 
situation with full context switching, is not going to help.  

Also, forcing an unnatural syntax is not going to help.  I can, with
some difficulty, read and write Polish or reverse Polish notation.
With few exceptions, assemblers are essentially Polish.  Lisp is
essentially Polish except for the "standard" arithmetic operations.
Requiring the writing of pow(x,y) (or is it pow(y,x)?) instead of
x^y is forcing Polish without even using its power.
-- 
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)
From: jlg@cochiti.lanl.gov (J. Giles)
Newsgroups: comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 12 Nov 92 20:20:01 GMT
Organization: Los Alamos National Laboratory

In article <id.DDWU.KZ4@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <BxDH7G.8Cn@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
|> > Those who rewrote my code without gotos had to work to do it.
|> 
|> Who cares?
|> 
|> The goal, after all, isn't eliminating the gotos. It's producing maintainable
|> code. The version I wrote from your code had just as many gotos (some were
|> switch statements, but it's a 5 minute job to convert them all back and
|> forth), but it was a lot more readable and maintainable. And I probably spent
|> less time on it than you spent on the code in the first place.
|> 
|> Frankly, your coding style as we've seen it on the net is so bad nobody can
|> take seriously any claim that minor syntax changes will make an atom of
|> difference to your productivity.

And yet, You're the one who just finished defending the use of *raw*
pointers in the same way that Dr. Rubin uses *raw* GOTOs.  You obviously
*understand* the concept of replacing such monstrosities with legible
structures, yet you support doing so only in *one* case.  Why?

-- 
J. Giles
Newsgroups: comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Pointers
Organization: Los Alamos National Laboratory
Date: Thu, 5 Nov 1992 21:35:41 GMT

In article <1dbqs8INN7qo@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> [...]
|> That's a silly guideline.  The most common reason to use pointers is
|> precisely *because* you need multiple references to the same data.  In
|> object-based programming, an object may be in different relationships with
|> other objects, and relationships are usually implemented as pointers
|> between objects.  For instance, in a family tree model, a person might have
|> pointers to its parents, children, and siblings; any particular person is
|> likely to be referenced by the children array of two parents and a parent
|> pointer of some children.

I seldom use explicit pointers for this kind of structure.  It 
consists of a *set* of individuals and *sets* of directed arcs 
between these individuals.  The directed arcs are not semantically 
just pointers, they are ordered pairs whose elements are drawn from 
the set of individuals.  Each such set of arcs defines one of
the relations you mentioned above: parenthood, siblinghood, etc..
While these may be *implemented* internally using pointers, the 
finite, non-looping, non-aliased nature of these sets allows more 
efficient code development which is easier to prove correct, optimize, 
maintain, etc..  For example, suppose I wish to perform some operation 
on all individuals - I needn't even *look* at the sets of arcs if the 
order of processing the individuals is not relevant (or, if the order 
is intended to be, say, alphabetical so the sets of arcs you mention 
are all irrelevant). 

In fact, I never think in terms of multiple *pointers* to a single 
object - though I might think in terms of multiple references of 
more restricted, more easily handled, optimizable, and debuggable
kinds.

-- 
J. Giles
Newsgroups: comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Pointers
Organization: Los Alamos National Laboratory
Date: Fri, 13 Nov 1992 22:40:22 GMT

In article <Bxnqv5.J71@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
|> [...]
|> Why do some people find it necessary to hide simple devices under 
|> interfaces?  The insistence on the use of these interfaces is like
|> the joke about the mathematician who pours the water out of the bucket
|> and turns off the stove to reduce the problem to the previous case.

Why do some people want to hide simple devices under a mountain of
confusing implementation detail?  It's like those ugly buildings
from a few years back where all the girders, cables, and vent ducts
were deliberately left exposed.  Bletch.

Yes, there are simple devices like `sets' whose operations are
insert an element, delete an element, test for membership, union
and intersection of pairs of sets, set difference, etc..  When 
don't use an interface, then the code will be filled with linked
lists, pointers, loops, etc. - or whatever implementation technique
you chose to use.  This means that you can't see whether you've 
*really* got sets at all!!  For all you know, some part of that
mess of detail misuses the access protocol appropriate to sets 
and is generating wrong, but plausible results.  Further, if you 
decide to alter your implementation of sets to use bit strings
or hash tables instead, you must change your *whole* code and
not just the interfaces.  Bletch.

The same goes for all other structured data types.  Yes, you *can*
implement arrays by doing all the address arithmetic yourself:
explicitly.  No sane programmer would do so except as a last
resort for optimization purposes.  Such optimizations would be
carried out as careful transformations of the high-level construct,
not rewrites at the low-level.  You write most of your array
computations using the high-level interface in order to 1) have
a better chance of writing correct code and 2) to allow the
compiler to take advantage of known properties of arrays to 
optimize better (like, no two parts of the same array are
aliased to one another - something you *don't* necessarily
know if you've messed around with raw address calculations
yourself).

-- 
J. Giles
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: languages which allow the introduction of new operators
Newsgroups: comp.lang.misc
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 13 Nov 92 11:44:30 PST
Organization: Missionaria Phonibalonica

In <Bxns5v.5uJ@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) wrote:
> In article <17434@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
> >Why do you object to the use of a stack machine (on which those operations
> >are fast)?  If a stack language on a stack machine will run n times as fast
> >as a non-stack language on a non-stack machine of equal technology level, why
> >not use a stack machine?
>
> HOW can a stack machine be fast?  One of the features of an efficient program
> is to have the quantities needed available in registers.

Not quite - delete "registers", and replace it with "fastest available
memory". Most architechtures put that memory in a seperate address
space with special address modes, but neither is required.  There are
machines where the registers are just a particularly fast piece of
ram; there are machines where that address may be set by the
programmer; there are even machines that map the top of the stack into
high-speed memory. The latter would be quite appropriate for a being a
fast stack machine, even though it wasn't designed for that.

	<mike