HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 6 Nov 1992 16:20:19 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Nov5.184831.16328@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
>C has actually committed two sins against array users - both as a
>result of this coercion to pointer.  First, it is not notationally
>convenient in C to program procedures which handle variable sized
>conformable arrays.  Second, the coercion to pointer makes it 
>impossible for the C compiler to *locally* determine whether 
>incoming pointers are aliased.  If the user were offered a choice,
>then he could declare the incoming arguments as pointers if he
>wanted to *allow* aliasing, and he could declare them as arrays
>(with or without variable dimensions) when he wanted to disallow
>aliasing.

I don't think either of these sins is related to its array->pointer
coercion feature.

The problem with variable-sized multidimensional arrays is due to the fact
that C includes interior array dimensions as part of the static type of an
array.  Note that GCC provides variable-sized arrays as an extension, using
the intuitive notation.

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.


-- 
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, 13 Nov 1992 22:50:59 GMT

In article <BxnrI0.10M@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
|> [...]
|> Even if you have the greater capablility, do you have to insist on
|> making things complicated by using it? [...]

Frankly, I find much of your code very difficult to follow
because pointers make the thing more complicated than it needs
to be.  I don't need the address of the function.  Therefore, 
I don't need a variable whose explicit semantics is that it 
holds such an address, and I actually don't *want* to have to 
`dereference' the thing to get the semantics I really *do* 
want.  The very fact I need a dereferencing operator in C and 
I wouldn't if functions were first-class objects is a clear 
demonstration that the pointer implementation is *more*  
complicated from the user's perspective.

-- 
J. Giles
Newsgroups: comp.lang.misc
From: kers@hplb.hpl.hp.com (Chris Dollin)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 13 Nov 92 09:31:49 GMT
Organization: Hewlett-Packard Laboratories, Bristol, UK.

In article ... hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   Some of these allow some flexibility in expression syntax.  But how
   many of these could conveniently unpack a floating point number into
   its exponent and mantissa?  In particular, could you write

	   exponent, mantissa =.U float

In Pop, you could write

	floating_thing.Hermans_dismantle -> (exponent, mantissa)

so long as you'd defined Hermans_dismantle somewhere as a procedure with the
appropriate effect. 

At the moment, you'd have to hack the Pop compiler to make this generate
in-line code. If there was a machine instruction to do the job, I should
imagine this might take the compiler-writer, oh, half-an-hour or so. Then
there's the rest of the week for documenting, porting, testing, checking, and
justifying the extension to Pop users who'd rather have an even faster garbage
collector. 
--

Regards,    | "Layered protocols give the software implementor a chance to
Kers.       | ruin his performance in each layer." - Don Gillies
Newsgroups: comp.lang.misc
From: jch@rdg.dec.com (John Haxby)
Subject: Re: Pointers
Organization: Digital Equipment Corporation
Date: Fri, 13 Nov 1992 10:41:32 GMT

In article <TMB.92Nov13005803@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

|> The only language that I would imagine might be a serious alternative
|> to C among those that you have listed is Modula-2, but I'm not
|> sufficiently familiar with its low-level features to say whether it
|> could cover the same breadth of system-programming problems that C
|> covers.

Modula 3 covers at least the system-programming problems that C does.
Modula 2+ was used to implement the Topaz operating system; Modula 3
inherits a good deal from that.  There are some things that C is dramatically
bad at that Modula 3 is equally dramatically good at.  I don't work for
SRC, though I do work for DEC :-)

-- 
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: fpf@lyra.gasco.com (Frank Ferguson x3584)
Newsgroups: comp.lang.misc
Subject: Better Basic BCD Math Module
Date: 13 Nov 92 01:06:29 GMT
Article-I.D.: gasco.1992Nov13.010629.23233
Distribution: na
Organization: NorthWest Natural Gas Company of Portland Oregon





Hi.
I'm using a product called "Better Basic" by Summit Software 
Technology---now, sadly, out of business.  This package has the
charm of a virtual memory module which allows the declaration of, for
example, arrays of almost limitless size in memory (or other accessable
mass storage device).   I'm looking for a the BCDMATH module which was
available as an option for this program.  (that's binary coded decimal
math module).  If you have such, perhaps you could contact me at my
email address.

Thanks Much
Francis Ferguson
fpf@gasco.com
From: ernie@s850.mwc.edu (Ernest C Ackermann)
Newsgroups: comp.lang.misc
Subject: tips on C for Pascal programmers
Date: 13 Nov 1992 16:30:47 -0500
Organization: Mary Washington College, CPSC Dept.
NNTP-Posting-Host: s850.mwc.edu
Summary: Tips about C for Pascal programmers
X-Newsreader: TIN [version 1.1 PL6]

I'm teaching a class of Pascal programmers that want to move to C
quickly.  Does anyone have or know about a guide or tip sheet that
compares the syntax of Pascal with C?

Thanks in advance. Please post a response here or use email.

ernie@s850.mwc.edu
-- 
ernie@s850.mwc.edu		uunet!s850!ernie
Ernest C. Ackermann
Department of Computer Science	 Mary Washington College
Fredericksburg, VA 22401-5358	 703 - 899 - 4031
Newsgroups: comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: Pointers
Organization: Purdue University Statistics Department
Date: Wed, 11 Nov 1992 01:39:17 GMT

In article <mwm.2lit@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
>In <BxIoDv.72J@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) wrote:
>> In article <92Nov10.125426est.47525@neat.cs.toronto.edu> tlai@cs.toronto.edu (Tony Wen Hsun Lai) 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.

>No, you don't need *explicit* pointers to functions. It's perfectly
>reasonable (and I would argue, preferable) to allow function names
>in argument lists. In C-oid style, this would be:

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

I found this difficult to read, and it does not seem that it handles
the situation I envision.  The way that I would want to use pointers
would be to have fl as the pointer to a fill function, and des as the
pointer to a descriptor array, of which the first two arguments would
be pointers to the current element of the buffer and the bounding position,
and then when it is needed make sure that the current element is correct,
and issue the call

	*fl(*des);

The calling subprogram need not know anything about *fl except that it
fills the buffer, and does not need to know anything about *des except
that the first element of *des is the pointer to the current element of
the buffer, and the second element is the pointer to the bound.

It is quite possible that the calling subprogram might even use several
of these, and again I point out that this subprogram need not know 
anything more that the names of the pointers.

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.
-- 
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: wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke)
Subject: Re: languages which allow the introduction of new operators
Organization: Institut f. Arbeitsphysiologie a.d. Uni Dortmund
Date: Fri, 13 Nov 92 07:38:09 GMT

In article <BxLxqu.96C@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>In article <1992Nov12.082643.8415@arb-phys.uni-dortmund.de> wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
>>Add Ada, Algol68, TeX as well.
>
>Some of these allow some flexibility in expression syntax.  But how
>many of these could conveniently unpack a floating point number into
>its exponent and mantissa?  In particular, could you write
>
>	exponent, mantissa =.U float
If this is the point, there is some clarification needed. You want to
have a result which is really *2* values. Most languages don't allow
this. You need a (possibly implicitly constructed) structure to make
this sort of assignment possible. Defining an unary operator which
returns a struct is possible at least in C++ and Algol68. As we know
Herman is interested in *very* efficient solutions, one could trie C++
with embedded asm code (conditionalised for the machines on which it can
be used) in the operator definition. If GNU C++ is this operator may be
even onlined. The syntax has to be changed to something like
struct {int exponent; double mantissa} e_m;
e_m Isplittedfrom floatvalue;
if the operator is called Isplittedfrom.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke,
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-4600 Dortmund 1, Tel. 0231-1084-257
Newsgroups: comp.lang.misc
From: mwj@rz.uni-jena.de (Johannes Waldmann)
Subject: need info on FP ftp sites
Organization: Friedrich-Schiller-University Jena, Germany
Date: Fri, 06 Nov 1992 17:03:29 GMT

Hello net, I'm looking for ftp-able information on Backus' 
FP language. I'm interested in both discussion of the language
and publicly available implementations. Is there somthing
like comp.lang.fp or a related mailing list?

Please email. Thanx v/m. Johannes.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 11 Nov 92 19:17:20 GMT
	<1992Nov7.115620.29967@syacus.acus.oz.au>
	<1992Nov10.024021.8724@linus.mitre.org>
Organization: Department of Computer Science, University of Manchester
In-reply-to: crawford@boole.mitre.org's message of 10 Nov 92 02:40:21 GMT

In article <1992Nov10.024021.8724@linus.mitre.org> crawford@boole.mitre.org (Randy Crawford) writes:
   I defy the critics in this forum to devise a programming language which has 
   the ability to outperform C given the constraints I have listed above.

Why devise, there are _thousands_ of languages already.  Off the top
of my head, the following would all give C a run for its money, but
verifying it might me quite a difficult task:- el(alpha), FORTH,
Turing, various Algol 68 subsets, RCC, Modula II, Oberon(-2) and Turbo
Pascal.  I'm sure a perusal of the regularly posted language list
would produce others (e.g. SIMULA and Y, but I can't comment on code
quality of available compilers).  Anyway what is the point of the
comparision?  There is little point in fighting a battle with a
language that has 23 years head start, no matter how bad the original
language is, just look at FORTRAN (with plenty of hindsight of
course).


   Ever build a compiler to run in 20K of RAM and produce executables
   which must run in an equally tiny space?  What language would you
   prefer, Ada, PL/1 or perhaps Pascal?  Good luck.

Unless you are incredibly unfortunate, these days you'd use a cross
compiler so the size of the compiler is immaterial.  That said, I'd
probably go with Ada (don't knock it unless you've tried it).  If I
really had to do the development in 20K, I'd choose FORTH every time
there is no competition (IMHO of course :-).


   If you hope to design a language as powerful and flexible as C with
   a compiler as small, portable and simple, you will have to consider
   as Dennis Ritchie did what it is you cannot live without in a
   programming language.  I suspect that even with 23 years of
   hindsight that he did not have, your end product will look a lot
   like K&R C.

With hindsight, I'd either have gone with SIMULA or (given that the
compiler was relatively expensive), implemented an Algol 68 subset.


   Remember too, that when C was born in 1969, most programmers were
   still fighting with 300 baud modems, paper tape, and columnar punch
   cards.  A terse powerful programming language like C, with
   user-defined types, dynamic memory and free-form syntax was a huge
   step forward.

Even over Algol 68 and SIMULA-67?


   In a lot of ways, more modern languages are still trying to catch
   up.  It was 1992 before Ada 9X offered us pointers to functions.
   But two decades ago they were available in C.

I don't think any language is seriously trying to catch up with C with
regard technical issues, the languages that hade them before C
certainly, but not from C.  I think the quote regarding Algol 68 comes
to mind here ...

bevan
Newsgroups: comp.lang.misc
From: zou@ccs.northeastern.edu (Chendong Zou)
Subject: LALR grammar
Organization: College of CS, Northeastern U
Date: Thu, 5 Nov 1992 15:47:05 GMT

Hi:

I am now try to design a grammar to preprocess some technical papers using a
LALR parser.

I wonder if there is a general rule to design a grammar to guarantee it to be
a LALR(1). For sometimes, if you do some tricky changes, a non-LALR(1) grammar
will become a LALR(1).

Any suggestions? or can you recommend some books to read?

Please email me directly.
Thank you!

-- Zou

Newsgroups: comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Pointers
Organization: Los Alamos National Laboratory
Date: Thu, 12 Nov 1992 20:30:14 GMT

If the only things you can do with a pointer are to dereference it,
pass it as a procedure argument, or assign it from another of the same
type, then you never needed the pointer to begin with.  What you needed 
was for the data type to which it points to be a first-class type.  

Dr. Rubin's use of pointers to functions is exactly of that form.
He can do nothing with them except dereference, pass, or assign them.
He would actually get *greater* capability if the language he used
allowed `function' to be a first-class data type with assignment,
partial application (currying), and composition as it's defined
operations.

-- 
J. Giles
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Thu, 12 Nov 1992 08:56:29 GMT
Subject: Re: languages which allow the introduction of new operators
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.misc

In article ... veit@du9ds3.uni-duisburg.de (Holger Veit) writes:

   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.

He forgot (if he ever heard of) Pop11, too.

But Herman might not think of those things as ``operators''. Consider the Pop11
definition:

    define 5 ++( x, y ); lvars x, y; x + y + 1 enddefine;

The ``5'' is the precedence (it happens to be the same as ``+'') and makes
``++'' a (nominally infix) operator, so expressions such as

    x ++ y, f(x) ++ g(h(y), z)

work. But (in Pop) an operator is *just* a procedure with a pleasant calling
syntax; writing ``x ++ y'' just means ``push x, push y, call ++'' (Pop is an
open-stack language), ``x * y'' means ``push x, push y, call -'', and ``f(x)''
means ``push x, call f''. *Some* procedure calls are coded in-line, but this is
not a property of being (syntactically) operators; it is a property of being a
particular procedure, such as fast_front, or fi_+.

I *think*, from earlier discussions, that Herman thinks being-an-operator is
something to do with translating-to-an-instruction (with the appropriate
effect). In which case, as usual, He and Us are talking past each other.
--

Regards,    | "See the darkness all around   is coming down on you."
Kers.       | - Renaissnace, ``Running Hard''.
Newsgroups: comp.lang.misc
From: jch@rdg.dec.com (John Haxby)
Subject: Re: Pointers
Organization: Digital Equipment Corporation
Date: Thu, 12 Nov 1992 10:35:13 GMT

In article <1992Nov12.081454.23507@jyu.fi>, sakkinen@jyu.fi (Markku Sakkinen) writes:
|> 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.)

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.


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

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Pointers
Organization: Purdue University Statistics Department
Date: Fri, 13 Nov 1992 13:59:28 GMT

In article <1992Nov12.200950.8846@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:

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

>C.A.R. Hoare proved that the concepts of pointers and GOTOs are
>*isomorphic* - which is a lot stronger than a mere analogy.  The
>consequence of this observation is that *any* valid argument against
>GOTOs is equally valid against pointers.  Period.  As I keep saying,
>you cannot do any coding at all without GOTOs, it's just that most 
>of the ones you use are hidden under an interface (IF/ELSE, DO/ENDDO,
>SELECT/CASE, procedure calls, etc.) which capture the *specific* semantics
>of the flow control the user has in mind.  The same kinds of interfaces
>need to be designed and applied to data structures to eliminate *raw*
>pointer instances.

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.


-- 
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: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Pointers
Organization: Purdue University Statistics Department
Date: Fri, 13 Nov 1992 14:13:11 GMT

In article <1992Nov12.203014.11596@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
>If the only things you can do with a pointer are to dereference it,
>pass it as a procedure argument, or assign it from another of the same
>type, then you never needed the pointer to begin with.  What you needed 
>was for the data type to which it points to be a first-class type.  

>Dr. Rubin's use of pointers to functions is exactly of that form.
>He can do nothing with them except dereference, pass, or assign them.
>He would actually get *greater* capability if the language he used
>allowed `function' to be a first-class data type with assignment,
>partial application (currying), and composition as it's defined
>operations.

Even if you have the greater capablility, do you have to insist on
making things complicated by using it?  I use pointers both for 
functions and for descriptors.  I use pointers to get a more powerful
version of COMMON blocks.  I use pointers because any non-brain-damaged
machine uses them.  In fact, Fortran (at least up to F77) uses only
pointers, but all pointers are fixed!
-- 
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: wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke)
Subject: Re: languages which allow the introduction of new operators
Organization: Institut f. Arbeitsphysiologie a.d. Uni Dortmund
Date: Thu, 12 Nov 92 08:26:43 GMT

In article <TB06.92Nov11165010@CS1.CC.Lehigh.EDU> tb06@CS1.CC.Lehigh.EDU (TERRENCE MONROE BRANNON) 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.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke,
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-4600 Dortmund 1, Tel. 0231-1084-257
Newsgroups: comp.lang.misc
From: erasmus@cs.ufh.ac.za (Mr S Erasmus)
Subject: Compiler Validation Suite
Organization: Dept Comp Science, Univ Fort Hare
Date: Wed, 11 Nov 1992 18:43:09 GMT
Summary: I need hints/advice on a CVS for a VHLL
Keywords: Validation

As part of a CS project I have to construct a Compiler Validation Suite
for a VHLL called Slim (because it is based on sets, lists and mappings).
I'm only aware of CVS's for HLL's like Pascal, M-2 and Ada.

Does anybody have info on CVS's for other languages, especially higher level 
ones?  I'd appreciate any feedback.  

You can reach me at  Erasmus@cs.ufh.ac.za

Thanks

Stoffel
Newsgroups: comp.lang.misc
From: "elliott chapin" <elliott.chapin@canrem.com>
Subject: pointers
Reply-To: "elliott chapin" <elliott.chapin@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 13 Nov 92 15:51:49 EST

SJ>probably go with Ada (don't knock it unless you've tried it).  If I
SJ>really had to do the development in 20K, I'd choose FORTH every time
SJ>there is no competition (IMHO of course :-).

Indeed.  I just finished my 1st live kernel.  It takes up 1233 bytes on
disk and isn't even minimal.

Elliott Chapin
---
  DeLuxe 1.12 #4315  elliott.chapin@canrem.com
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044