HDTenEightyP/NetNews huggingface dataset:
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc,comp.lang.c
Subject: postfix indirection operator in C
Date: 18 Nov 92 01:43:56 GMT
Followup-To: comp.lang.c

: From: peter@ferranti.com (peter da silva)
: Message-ID: <id.SJYU.I62@ferranti.com>
: (I will readily admit that C syntax sucks here: indirection should be a
: postfix operator:

Actually, I often use the C postfix indirection operator "[0]",
in places where it makes the intent clearer.  Especially when
interspersed with array and struct accesses.

( Well... maybe "often" is an exageration.  But really and
  truely, I have treated "[0]" as if it were a simple postfix
  operator now and then.  Works just fine.  Sort of. )
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.lang.misc
Newsgroups: comp.lang.misc

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

   Certainly not from the standpoint of English speakers.  As I understand it,
   *x in C denotes the object referred to by x, the object "found" AT x.  Thus,
   @x would have been at least a somewhat logical notation, at least relatively
   easily understood by users, as well as easy for parsing, etc.

The problem with having prefix indirection and postfix other things, namely,
field selection and subscripting, is that expressions such as

	*x.y,	*x[z]

become ambiguous; is the former ``*(x.y)'' or ``(*x).y''? If all the selectors
are postfix, the problem goes away; there's only one way to interpret

	x^.y,	x^[z]

(with ``^'' as postfix indirection, a la Pascal). It seems silly to introduce a
notation that *forces* bracketing in half the possibilities (not necessarily
half the cases, of course), when just changing its fixity makes the problem go
away.

The C solution, of course, was to introduce *another* postfix, ``->'', for one
case. 

[Some might say that the ambiguities of the examples could be resolved by type
analysis. To this I say (a) prove that there will be no ambiguities left, (b)
one should be able to parse in the absence of type information.]
--

Regards,    | Applicants must also have extensive knowledge of Unix,    | MIT
Kers.       | although they should have sufficiently good programming   | job
            | taste to not consider this an achievement.                | ad.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 19 Nov 92 00:21:35
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Nov10.024021.8724@linus.mitre.org>
	<BEVAN.92Nov11191720@beluga.cs.man.ac.uk> <Bxq1C2.1CC@fiu.edu>
	<mwm.2n45@contessa.palo-alto.ca.us>
	<1992Nov17.121528.28783@syacus.acus.oz.au>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: ian@syacus.acus.oz.au's message of 17 Nov 92 12:15:28 GMT

In article <1992Nov17.121528.28783@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:

   Well, I won't forget it. It is the purpose of computer hardware to run
   software. It is not the purpose of software to be crippled by the
   compromises and limitations of current generation hardware.

   So hardware design must be dictated by software considerations, not
   vice versa, as is so apparent in languages like C.

Actually, sadly, C dictates hardware design these days. I have heard
chip designers for some of the latest, greatest chip sets coming soon
to a workstation near you say "oh, we did this and that because many C
programs assume it; we would really have liked to do this
differently". Most of these are related to how characters, integer
sizes, and pointers interact in the minds of most C programmers.  C's
lack (in fact, intolerance) of runtime typing and array bounds
checking, on the other hand, mean that hardware designers these days
seem to make little effort to support such features, and the
assumptions of C programmers about power-of-two word sizes make it
nearly impossible even to find room for bits to store such information
in. IEEE floating point is another example where (allegedly) software
considerations drove hardware design, with results that aren't quite
as bad as in the case of C.

					Thomas.
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Binary floating point
Organization: Purdue University Statistics Department
Date: Mon, 23 Nov 1992 13:16:26 GMT

In article <1eou72INNe14@network.ucsd.edu> mbk@poincare.ucsd.edu (Matt Kennel) writes:
>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>: In article <722322705@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:

>: 			...................

>:                   e can communicate binary integers across machines
>: >: and implementations; the much used notation 0ddddd for octal and
>: >: 0xdddddddd for hexadecimal, bad as they are, do this explicitly.

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

>Most digital computers have binary floating point, so
>some number like

>+/- B1 * 2^(B2),

>with b1 a number between 0 and 1 expressed as a binary fraction,
>and b2 an integer ought to do the trick.  It is proabably very
>ugly, but isn't this the right idea?

>In the "fortran E exponent model" (from 1959 or so!)

>1000101110010 B 0010101010

This is the general idea.  However, something a little more flexible and
taking a little less time to type, transmit, etc., would be in order.
Typing 64 0's and 1's is too much of a chore, and also increases the
chance of error.

Unfortunately, natural notation like using E for exponent runs into 
problems.  A suggestion:  extend the present octal (I see problems
here for numbers less than 1; maybe they should start with 00) and
hex notation to allow an "integer point" to be inserted as well, and
use P for power of 2 by which the resulting fixed-point number is
to be multiplied.
-- 
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: je@unix.brighton.ac.uk (John English)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 19 Nov 92 12:20:18 GMT
Organization: University of Brighton, UK

hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
: In article <1992Nov13.073809.11835@arb-phys.uni-dortmund.de> wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
: >In article <BxLxqu.96C@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
: >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.
: 
: I believe it is possible in Algol68, but it is not possible in C++.
: C++ does not allow the introduction of new operator symbols; only new
: functions.

Sorry, wrong -- C++ allows existing unary operators to be overloaded
provided the operand is a class object (the operator is defined as a
member function of the class). It can then return anything you want
it to.  New operator SYMBOLS are indeed not allowed (none of that
Algol 68 fun with MONADs, NOMADs and DYADs (what, no DRYADs? :-)
-- 
-------------------------------------------------------------------------------
John English			| "Yes, understanding today's complex world of
Dept. of Computing		|  the future IS a little like having bees live
University of Brighton		|  in your head... but, there they are..."
Janet: je @ unix.brighton.ac.uk	| "People who live in windowed environments
Fax:   0273 642405		|  shouldn't cast pointers"
-------------------------------------------------------------------------------
Newsgroups: comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: Accessing the hardware directly (Was: Pointers)
Organization: Purdue University Statistics Department
Date: Mon, 16 Nov 1992 01:40:10 GMT

In article <92Nov15.195430est.47880@neat.cs.toronto.edu> tlai@cs.toronto.edu (Tony Wen Hsun Lai) writes:
>In article <BxrK6x.A04@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>[stuff deleted]
>>I do not see how any system of references will enable writing

>>	*fill(*descriptor)

>>any faster.  Nor do I trust compiler writers (or government bureaucrats.)
>>And if the lack of pointers in the languages causes hardware to elide pointers
>>in favor of something clumsy like call_by_name, searching the name file, we
>>all lose.  I have also pointed out that I want to use this in cases in which
>>the calling routine does not even know the name.  True, you could read the
>>name, but is that any easier than reading the address?

>I guess you don't like pass by reference?  Pass by reference is almost
>inevitably implemented using pointers, but doesn't involve _explicit_
>pointers set up by the programmer.  You may not need or appreciate
>abstractions for your programming, but if you look at the evolution of
>language design, abstractions are important for designing and writing very
>large, maintainable programs.

What is my notation other than calling the function by an indirect reference,
and passing the argument similarly?  Now I can put the argument reference on
the stack by first reading it into a register and then putting that register
on the stack, but what is gained by that?  And if the machine does not have
a reasonable way to call a function by indirect reference, the only way that
it could be done is by placing the address in the code for the function call
at run time, and this, or any other, modification of code at run time is,
I believe, considered quite objectionable.  Fortran calls only by reference,
and has finally come around to realizing that indirect references (pointers)
can improve the situation.
-- 
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: languages which allow the introduction of new operators
Organization: Purdue University Statistics Department
Date: Mon, 16 Nov 1992 18:14:42 GMT

In article <721862492@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>:: The fact that the language is conceptually
>:: stack based does *not* mean that it has *any* stack at runtime!
>: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
>: Message-ID: <Bxr9vx.KBD@mentor.cc.purdue.edu>
>: This is the case if the considerations for the optimizer were put in by
>: the compiler writer.  Computers are extremely fast sub-imbeciles.  If we
>: had a group of compiler people who would do their best to incorporate
>: considerations which users see in their optimizers, and produce their
>: optimizers so that these improvements can be quickly inserted, we may
>: get reasonable results.

>Yeah, right, it's all those lazy compiler people who just aren't doing
>their best.  Just like those lazy statisticians.  If we had a group of
>statisticians who would do their best to incorporate the statistical
>considerations which users actually see into their statistical models,
>and produce their models so that improvements can be quickly inserted,
>we might avoid all the misuses of statistics by poor, hard-working,
>long-suffering scientists in other fields.

As a statistician, I have absolutely no right to tell the client what
the model should be.  Nor do I have a catalog of models from which the
client can choose.  I WILL question the client on the assumptions, and
point out the consequences, and I MAY suggest that certain assumptions
can be dropped or generalized without affecting the analysis.

Now I may or may not be able to devise an algorithm to handle the data.
It may even be that there is nowhere near enough data.  It may be that
all the methods I know of attacking the problem require too much computing
to be useful.  BUT I WILL NOT TELL THE CLIENT WHAT THE MODEL SHOULD BE,
EVEN IF ASKED.  Any client who wants me to even work at this must make
me a co-investigator in the field.

>: The semantic model of the language can, however, greatly inhibit the
>: programmer.  

>True.  Just like all those nit-picky details they try to teach in
>statistics classes can inhibit a scientist's creativity with numbers. 

If my programming style will cause incorrect results to occur, it can
be criticized.  But, for example, nobody has claimed that the use of 
gotos WILL produce wrong answers.  I am quite willing to admit that
some of the methods I want to use in programming are dangerous.  So
is using a statistical method for an incorrect model, and this is 
done not just daily, and not even just hourly, but probably every
second.
-- 
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: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 13 Nov 92 09:23:44 GMT
	<mwm.2lx7@contessa.palo-alto.ca.us> <BxKvEy.Fnq@mentor.cc.purdue.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: hrubin@mentor.cc.purdue.edu's message of 12 Nov 92 00:44:57 GMT

In article <BxKvEy.Fnq@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
   Let me repeat that I am assuming separate compilation, and only
   communication blocks to integrate the modules.  The unit calling
   the function refilling the buffer knows only how to find the
   function identifier and enough of the buffer descriptor to use the
   buffer and to know how much is left in it. 

This has absolutely no bearing on the issue.

   [deleted]
   Now indirection (pointers) gives an easy way to do this.  None of
   the critics of pointers have come up with anything not more clumsy
   in implementation.

As has already been pointed out, any language that has procedures as
first class types can do this without explicit pointers (Algol 68,
Scheme and ML come to mind but there are plenty of others).  If the
implementation uses pointers, fine, however there is no need for me
the user to have to deal with this.  There is little point in me
giving an example in any of these languages as I refuse to use two
characters names and as such the code will probably be labelled
"verbose" and unreadable by Herman.

bevan
Newsgroups: comp.lang.misc
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.misc
Subject: Hardware and software (Re: Pointers)
Date: 18 Nov 92 01:05:34 GMT
Article-I.D.: network.1ec4suINNjuo
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

ian@syacus.acus.oz.au (Ian Joyner) writes:
: His main point was that this was a successful attempt at developing a
: machine by considering the software first, not the hardware, but as
: soon as it was shown that this was possible, it was quickly forgotten.
: 
: Well, I won't forget it. It is the purpose of computer hardware to run
: software.

For better or for worse, I think practice has shown
that hardware designers who consider physics first, and software second,
seem to be more reliably successful.

Software is a mushy moving target.

: It is not the purpose of software to be crippled by the
: compromises and limitations of current generation hardware.

I don't think it really has any choice in the matter, actually.

: So hardware design must be dictated by software considerations, not
: vice versa, as is so apparent in languages like C.

I think that few of C's *problems* are a result of being dictated by
hardware considerations.

: -- 
: Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
: "Where is the man with all the great directions?...You can't imagine it,
:  how hard it is to grow, Can you imagine the order of the universe?" ABWH
: Disclaimer:Opinions and comments are personal.

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
From: dave@alex.uchicago.edu (Dave Griffith)
Subject: El(Alpha)
Organization: University of Chicago
Date: Tue, 17 Nov 1992 19:39:04 GMT

In article <BEVAN.92Nov16163936@beluga.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>In article <Bxq1C2.1CC@fiu.edu> feathers@serss0 (Michael Feathers) writes:
>   [ nearly all the article because I essentially agree with it ]
>
>   Ada, Eiffel, El(Alpha), and Turing are all great for their
>   application domains but I think that they are subsets of C and
>   C++'s application domains.  
>

Alright, you've piqued my interest.  I've stolen vast swaths of Ada, Eiffel,
and Turing for the language design I'm working on, but have never heard of 
El(Alpha).  Any information about the language, particularly availablility of
a reference manual, would be greatly appreciated.  


-- 
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       dave@alex.bsd.uchicago.edu
Strong currency, strong whiskey, and strong typing
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.misc
Subject: Re: Binary floating point
Date: 24 Nov 92 01:52:20 GMT
Organization: CWI, Amsterdam

In article <By67JE.CCz@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
 > >1000101110010 B 0010101010
 > 
 > This is the general idea.  However, something a little more flexible and
 > taking a little less time to type, transmit, etc., would be in order.
 > Typing 64 0's and 1's is too much of a chore, and also increases the
 > chance of error.
 > 
 > Unfortunately, natural notation like using E for exponent runs into 
 > problems.  A suggestion:  extend the present octal (I see problems
 > here for numbers less than 1; maybe they should start with 00) and
 > hex notation to allow an "integer point" to be inserted as well, and
 > use P for power of 2 by which the resulting fixed-point number is
 > to be multiplied.

You know what Herman.  There are languages that provide what you want!
Ada:  13#c.18644#e+12
meens c.18644 in base 13 notation multiplied by 13 to the power 12.
Fairly general I would think.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Summary: I still see no "semantic model" issues here
Date: 21 Nov 92 02:13:53 GMT

::: The semantic model of the language can, however, greatly inhibit the
::: programmer.  Try communicating floating binary from one machine to
::: another; the only semi-portable way I have seen are to convert to
::: higher precision floating decimal, transmit that, and convert back.
:: What does that have to do with the semantic model of the language?
:: That's a very hardware related issue. [...] internal
:: float format [...]

: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <Bxz8px.FBx@mentor.cc.purdue.edu>
: Did I say anything about matching the internal representations of
: the numbers?  We can communicate binary integers across machines
: and implementations; the much used notation 0ddddd for octal and
: 0xdddddddd for hexadecimal, bad as they are, do this explicitly.

So, what does this have to do with the semantic model of the language?
What prevents one from converting the floats to binary representation
in ascii, transmitting that, reading the result, and doing the
inverse conversion?

Presumably Herman is complaining either that it isn't built into the
syntax of the language (which is not a semantic model issue), or that
it isn't available in the standard runtime package of the language
(which is STILL not a semantic model issue).  (The former is a
syntactic issue, the latter an application feature coverage issue.  
Again, *NEITHER* is a semantic model issue.)

One more possibility is that Herman is complaining that one can't
portably write a convert-to-binary-ascii routine without access to
operations on floating point numbers not in the language.  But it'd
still be questionable if this were a semantic model issue.  If this IS
what Herman means, I'd appreciate his being specific as to what
operations are missing.

Semantic model issues are things such as "do side-effects exist
explicitly in the language" and "can operators be short-circuiting" and
"what is the argument passage model" and "do names specify variables or
values" and "must all types be known at compile-time" and "is
mixed-mode arithmetic allowed (borderline...)" and so on and on.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
From: S.Courtenage@cs.ucl.ac.uk (SA Courtenage)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 16 Nov 92 18:41:33 GMT


Just out of interest, Gofer (a functional language v.similar to Haskell)
allows the following to be defined.


------ cut here for Gofer script ------------
>

>(#) :: Int -> Int -> Int
>(#) n m = n + m + 1

--------------- end cut ---------------------

Typing

	3 # 4

then gives the result 8.

Haskell is more sophisticated in this respect, through its type classes.

Simon Courtenage		Email: scourten@uk.ac.ucl.cs
Dept of Computer Science
University College London
London WC1E
England
From: jnelson@eecs.wsu.edu (nelson jeffrey w - CS422)
Newsgroups: comp.lang.misc
Subject: Information needed
Keywords: RPG
Date: 16 Nov 92 18:36:19 GMT
Article-I.D.: serval.1992Nov16.183619.25194
Organization: School of EECS, Washington State University


	This is my first post to the news, so be gentle on my style....
	I need some information about RPG used by IBM on their AS400 mini-computers.  I don't know
where to find any information on this subject.  Could someone direct me to a news group or a good 
reference on this subject?   Any information would be helpful.
	By the way, I thought it was interesting that we had some IBM recruiters on campus and they
couldn't tell me anything about the language, except that they have heard the name before.  So much 
for those recruiters, huh.
	Thanks in advance for any information!
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Summary: confusing the abstract with the concrete
Date: 14 Nov 92 02:21:03 GMT

:: From: kers@hplb.hpl.hp.com (Chris Dollin) writes:
:: Message-ID: <KERS.92Nov12085629@cdollin.hpl.hp.com>
:: [...]  define 5 ++( x, y ); lvars x, y; x + y + 1 enddefine; [...]
: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
: Message-ID: <BxMCxA.3nM@mentor.cc.purdue.edu>
: [...] I would accept that as the insertion of the ++ operator.

:: (Pop is an open-stack language), ``x * y'' means ``push x, push y,
:: call -'', and ``f(x)'' means ``push x, call f''.
: But I would object to any language which insists that we use a
: strictly stack machine.  Pushing, popping, and calling are to be
: avoided unless necessary.  Otherwise things just run too slowly to be
: of more than theoretical use.

This is yet another case of confusing the abstract notation with a
concrete implementation.  Just because the abstract semantics has the
model of a stack is NO reason to suppose that this forces one to
implement the model using an explicit stack with explicit push and pop
operations.  (Not being intimately familiar with Pop, it may be that
Pop *does* require an explicit stack in the implementation, but that
can't be told just from what Chris said.  Certainly he explicitly said
that the "call" operation may be open-coded in such a way as to
involve no actual call operation at runtime, as a property of the
operation, thus:)

:: *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_+.


( BTW, note the difference between a stack explicit in the notation, vs
  one explicit in the implementation.  This is the opposite of the case
  of pointers vs references previously discussed. )
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw