HDTenEightyP/NetNews huggingface dataset:
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Indirection
Organization: Purdue University Statistics Department
Date: Thu, 19 Nov 1992 13:58:11 GMT

In article <id.GT2V.7OE@ferranti.com> peter@ferranti.com (peter da silva) writes:

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

>Personally, I think that making indirection a prefix operator was a bigger
>mistake than any of these.

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.
-- 
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: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Followup-To: comp.lang.misc
Date: 22 Nov 92 01:38:04
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<nevin-191192004649@90.20.3.209>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: nevin@apple.com's message of 19 Nov 92 08:53:49 GMT

In article <nevin-191192004649@90.20.3.209> nevin@apple.com (Nevin ":-]" Liber) writes:

   In article <TMB.92Nov19002135@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas
   M. Breuel) wrote:
   > 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.

   If you could elaborate on what these are, I'm sure that many of us would
   find that an interesting topic to discuss.

Some of the main assumptions are that characters are 8bits, that
the smallest addressable unit is a character, and that the number
of bits in a "machine word" is divisible by the number of bits per
character. Note that these are _not_ assumptions that are written
into the ANSI C standard. They are simply assumptions that C
programmers commonly make. The main fault of the C language is
that it doesn't force programmers to be aware of the places
where they make such assumptions.

   > 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,

   I don't see anything wrong with getting rid of features that people aren't
   using.  If those features were popular, C probably wouldn't be as popular
   as it is today.  We have lots of CISC archetectures with cool features that
   very few people ever find useful.  Why waste the silicon?

It is not necessarily a question of adding lots of features, but more
a question of what kinds of (largely unnecessary) assumptions C
programs like to make about word sizes and representations.  This
constrains the kind of choices that chip designers have among equally
RISCy designs.  Furthermore, it is pretty clear that there are lots of
people who do want more runtime safety (Apple's push for Dylan is just
one example), however, at the same time, they also do not want to
throw away all their old C code.

Perhaps my above assessment was a little too negative. Compromises are
already being made. For example, the Sparc has some support for tagged
arithmetic. Furthermore, with 64bit machines, it will be easier to
find space for tags in integers, pointers, and IEEE single-precision
floating point.

					Thomas.
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 19 Nov 92 00:34:55 GMT

: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
: Message-ID: <Bxw0H0.6EF@mentor.cc.purdue.edu>
::: I do not see how any system of references will enable writing
:::                 *fill(*descriptor)
::: any faster.
:: How about         fill(descriptor)  ?
: "This does not compute."  The module which produces the contents of
: fill and descriptor is compiled separately from the one that calls it.
: In addition, I specified that there may even be run-time changes, which
: the calling module does not know.

As I have attempted to point out three times now, one can write

         fr(dr)        instead of           *fp(*dp)

because the *declaration* of a reference makes the indirection
implicit during use, while declaration of a pointer does not.
Either notation can have *all* of the properties mentioned
by Herman Rubin above.

This means that reference notations are identically fast, will map
identically to machine instructions, yet are more flexible to change
(since changes can be introduced at the definition site instead of at
every use site), and involve a simpler notation at the use site. 
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.lang.misc
From: a866700@hp9000.csc.cuhk.hk (Wong Siu To)
Subject: Awk and Sed info. wanted
Organization: The Chinese University of Hong Kong
Date: Tue, 24 Nov 1992 05:55:23 GMT

Hi there,

Maybe it's not the appropriate groups to ask such question, but I've no
idea about which group I should post my question :-(

I'd like to know if there's any group which is about Awk and Sed ?

Where can I get any doc. about Awk and Sed on Internet ?

How can I strip off control characters (e.g. ^M) in a text file using
Sed ?

Hope that these are not FAQs :-)

Any help will be much appreciated.  Thanks in advance.

Regards,
-- 
----------------------------------------------------------------------
S.T. Wong             	            [] BITNET: A866700@CUCSC.BITNET      
Computer Services Centre            [] Internet: stwong@cuhk.hk 
The Chinese University of Hong Kong [] Tel. No: (852) 609 8825
Newsgroups: comp.lang.misc
Date: Fri, 20 Nov 1992 01:30:03 -0500 
From: Nicholas Weidmann <nw24+@andrew.cmu.edu>
Subject: Re: Indirection
	<Bxyut0.Jo@mentor.cc.purdue.edu>

Excerpts from netnews.comp.lang.misc: 19-Nov-92 Indirection Herman
Rubin@pop.stat.pu (701)

> In article <id.GT2V.7OE@ferranti.com> peter@ferranti.com (peter da
> silva) writes:

> 			..........................

> >Personally, I think that making indirection a prefix operator was a bigger
> >mistake than any of these.

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


		Build your own compiler and SHUT UP !!!!
Xref: sparky comp.lang.misc:3785 comp.arch:10912
From: nevin@apple.com (Nevin ":-]" Liber)
Newsgroups: comp.lang.misc,comp.arch
Subject: Re: Hardware Support for Numeric Algorithms
Date: 19 Nov 92 09:09:31 GMT
Followup-To: comp.lang.misc
Organization: Apple Computer, Inc.

In article <Bxv2t2.4FH@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu
(Herman Rubin) wrote:
> 	The use of | for or.  The vertical bar has been used in mathematics
> 	for other things for years.

You hypocrite!  The above statement says that mathematicians have been
overloading the vertical bar with vastly DIFFERENT meanings FOR YEARS. 
Furthermore, you've been complaining for years that most of our languages,
especially many assembly languages, don't allow overloading of operators,
even though you've wanted that feature.

However, when a computer language designer overloads the meaning of
vertical bar with "or", you complain:

> 	The notation of .OR. for it in some versions of Fortran
> 	was far better.

A self-consistent position is not one of your virtues.
___
NEVIN ":-)" LIBER, RISC Porting Specialist/Blue Meanie, Mac System Software
 email:     nevin@apple.com        paper:  Apple Computer, Inc.
 voice:     (408) 974-MIX1                 20525 Mariani Avenue, MS: 81-GC
 AppleLink: BADENOV                        Cupertino, CA 95014
Newsgroups: comp.lang.misc
From: nevin@apple.com (Nevin ":-]" Liber)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: Thu, 19 Nov 1992 00:10:31 GMT
Organization: Apple Computer, Inc.
Followup-To: comp.lang.misc

In article <Bxvs9I.L22@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu
(Herman Rubin) wrote:
> What is the correct association in a << b + c?

It associates as  a << (b+c).

> Everyone I showed 
> this to came up with the same answer; but that answer is wrong in C!

Well, considering I NEVER saw the << operator symbol before using C, how
could it be wrong??  I could see people getting it wrong if they think of
the shift left operator as a power operator.  A while ago I played around
with changing the precedence of the C operators, but never found a
different order that I was more comfortable with.  If you really don't like
the precedence rules, and since no one but you will ever, ever try to read
your code, it is fairly trivial to write a preprocessor that inserts the
appropriate parentheses the enforce any precedence rules you wish.  How
would YOU, Herman Rubin, define the precedence rules??  BE EXPLICIT!

> One
> cannot even get the compiler to consider spacing in resolving this.

I'll leave the rebuttal for this to people with more free time on their
hands. :-)

> I 
> would just as soon go the the APL idea, which only distinguishers unary
> and binary.

So, why aren't you using APL??

> It would help if we could get a more complicated set of 
> parentheses,

Adding lots of complexity for negligible, if an, gain is a bad, bad idea.

> or allow explicit temporaries to be used to break up the
> operation stream;

What stops you from doing this now??

> Put one
> precedence for unary operators and another for binary operators, or even
> equate the infix notation x FOO y with !FOO(x,y); those of us who want 
> to use user-defined operators would find this a lot preferable to not
> allowing them at all, even if we had to use parentheses all the time.

Funny, I just don't see you getting along with 2 + 3 * 5 evaluating as 25
instead of 17.  Besides, don't you always complain that LISP has too many
parentheses??  If you really want this stuff, it's fairly simple to write
an infix -> postfix converter for LISP.
___
NEVIN ":-)" LIBER, RISC Porting Specialist/Blue Meanie, Mac System Software
 email:     nevin@apple.com        paper:  Apple Computer, Inc.
 voice:     (408) 974-MIX1                 20525 Mariani Avenue, MS: 81-GC
 AppleLink: BADENOV                        Cupertino, CA 95014
Newsgroups: comp.lang.misc
From: dave@alex.uchicago.edu (Dave Griffith)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: University of Chicago
Date: Wed, 18 Nov 1992 00:21:15 GMT

In article <Bxvs9I.L22@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>I agree that this complexity of syntax analysis is very weak.  Put one
>precedence for unary operators and another for binary operators, or even
>equate the infix notation x FOO y with !FOO(x,y); those of us who want 
>to use user-defined operators would find this a lot preferable to not
>allowing them at all, even if we had to use parentheses all the time.

So you're advocating that a programming language implement a syntax which
is directly incompatible with that commonly used in mathematics. Addition, 
multiplication, and exponentiation certainly have different precedences in
common usage. How many times, I wonder, have you against precisely that sort 
of language construction. 

However, you did suggest something that had been implemented dozens of times
over the last twenty years.  There is still hope for you.

-- 
Dave Griffith, Information Resources, University of Chicago,
Department of Surgery                       dave@alex.bsd.uchicago.edu
Strong currency, strong whiskey, and strong typing
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Fri, 20 Nov 1992 10:21:48 GMT
Subject: Re: languages which allow the introduction of new operators
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.misc

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

   As to designing compilers, this is a massive operation, not to be done by
   one or two people.

Really?

Perhaps Herman has some notion of ``compiler'' that has more weight than I do.
I have written compilers on my little ownsome, and at least one of them was
done part-time at home, for fun. The latter isn't one that's ready for the wide
world to trample over -- it's part of a bootstrap -- but the design certainly
didn't need more than one person.

Unless, of course, you count the accumulated wisdom of the people whose books
and papers on compilers adorn my shelves and filing cabinet. But I don't think
that's what Herman meant.

[No, there are no clever optimisations in the compiler, and Herman wouldn't be
interested in the language -- it has stacks, and closures, and dynamic typing,
and you can't get close to the raw machine for speed.]

--

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.
Newsgroups: comp.lang.misc
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: Pointers
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Tue, 17 Nov 1992 12:51:41 GMT

Oh, yes in my original rebuttal that C was the start of all these good
high level ideas, because ALGOL and Simula implemented many of these
things before C, I meant to add that C was not just the beginning of
this style of machine-orinted pseudo-HLL.  It had a heritage from CPL to
BCPL to B and then finally to C.  So in fact there was a whole lot of
heritage that C picked up from, prior to C.  The low level lvalue and
rvalue concepts that are not needed in HLLs were certainly in BCPL. 

-- 
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.
Newsgroups: comp.lang.misc
From: oz@nexus.yorku.ca (Ozan Yigit)
Subject: Re: New Release of Tim Long's ICI Available
Organization: York University
Date: Thu, 19 Nov 1992 00:50:26 GMT

andy@research.canon.oz.au (Andy Newman) writes:

>There is a new release of Tim Long's ICI language interpreter
>available on extro.ucc.su.oz.au in pub/ici.cpio.Z.

For ease and speed of access, I made it available in nexus.yorku.ca,
under pub/oz. [for anti-perl types, here is your chance to have your
swiss-army-whatever and enjoy it too. :-)]

oz
---
Not all good things come with three    | electric: oz@nexus.yorku.ca
pages of dogma and an attitude. - anon | phone:[416] 736 2100 x33976
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 16 Nov 92 18:44:25 GMT
	<TMB.92Nov14145619@pollux.idiap.ch> <Bxq7y0.IJ@mentor.cc.purdue.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: hrubin@mentor.cc.purdue.edu's message of 14 Nov 92 22:03:35 GMT

In article <Bxq7y0.IJ@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:

   This would be a totally non-optimizing syntax translator, and this
   is an important part of any compiler, but it seems that language
   people ignore it.

As long as you can write a grammar for your language, you can use TXL%
to transform it to your hearts desire.


   How many languages have the capabilities of fixed point arithmetic?

I don't know _how_ many; I know one that does: Ada.

bevan


% For those who've never heard of TXL, here is some of the blurb from
  the README :-

Here's the language prototyping tool you've been waiting for!  TXL is a
generalized source-to-source translation system suitable for rapidly
prototyping computer languages and langauge processors of any kind.  It
has been used to prototype several new programming languages as well as
specification languages, command languages, and more traditional program
transformation tasks such as constant folding, type inference and source
optimization.  

For more FTP to anonymous@qusuna.qucis.queensu.ca (130.15.1.100)
and hunt around the directories.
Newsgroups: comp.lang.misc
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: languages which allow the introduction of new operators
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Mon, 16 Nov 92 16:45:39 GMT

In article <1992Nov12.082643.8415@arb-phys.uni-dortmund.de> wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke) writes:
>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.

Not to mention APL and J, which allow you to define functions AND
operators (in the mathematical sense of the term).




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 14 Nov 92 09:46:20 GMT
	<1992Nov7.115620.29967@syacus.acus.oz.au>
	<1992Nov10.024021.8724@linus.mitre.org>
	<BEVAN.92Nov11191720@beluga.cs.man.ac.uk>
	<TMB.92Nov13005803@arolla.idiap.ch>
Organization: Department of Computer Science, University of Manchester
In-reply-to: tmb@arolla.idiap.ch's message of 13 Nov 92 00:58:03 GMT

In article <TMB.92Nov13005803@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
   Much as I dislike C, I disagree. FORTH doesn't even come close in
   either efficiency or usability (imagine: syntax even worse than that
   of C).

What is this opinion based upon, a simple threaded interpreted FORTH?
If you have the money you can buy FORTH compilers generating native
code.  BTW I'm disspointed at the syntax jibe, there is a perfectly
good reason for FORTH to have the syntax that it does, which is more
than can be said for most languages.


   Oberon and Algol-68 (Turing as far as I know as well) are
   higher-level, with associated runtime costs and difficulties for
   low-level access/interfacing.

The alleged runtime costs of Oberon and Turing didn't seem to deter
their use as the implementation language for operating systems
(Lillith is a mixture of Oberon and Modula-2; a BSD compatible OS
has been written in Turing).


   I don't know about RCC or "el(alpha)".

el(alpha) - systems programming language.  Attempts to be what C used
to be i.e. a high level language that knows about real hardware
addresses and in/out ports ... etc.  

Essential Language el(alpha) - A Reduced Expression Set Language for
Systems programming
Tan Watanabe, Hideyuki Arai and Hohbun Umetani
SIGPLAN Notices 26(1):85-98

ALEC - A Language with an Extensible Compiler
Implemented using RCC (a system developed by the first author below)
on an ICL 1906A

ALEC - A User Extensible Scientific Programming Language
R. B. E. Napper, R. N. Fisher
The Computer Journal 19(1):25-31


   Turbo Pascal is a CPM/MSDOS specialty language--it's not difficult
   to be a "portable systems programming language" for a single
   machine.

You mean much as C was to begin with?  Are you claiming that it is
impossible to port Turbo Pascal to other environments?  The fact that
it hasn't been done is irrelevant, there is probably little incentive
given the tiny workstation market compared to the PC market.


   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.

Name the problems and we can find out.

bevan
Newsgroups: comp.lang.misc
Subject: TMS 7000/7010
From: <BUSCHMAN@NDSUVM1.BITNET>
Date: Mon, 23 Nov 1992 16:34:00 CST
Organization: North Dakota Higher Education Computer Network

Could someone please send me e-mail about the language:


                          TMS 7000
                          TMS 7010

     I'm interested in know a what this language is and where they use it.
                               Thanks!   Greg
                                  internet:  Buschman@Vm1.Nodak.edu
From: nevin@apple.com (Nevin ":-]" Liber)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 19 Nov 92 08:53:49 GMT
Followup-To: comp.lang.misc
Organization: Apple Computer, Inc.

In article <TMB.92Nov19002135@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas
M. Breuel) wrote:
> 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.

If you could elaborate on what these are, I'm sure that many of us would
find that an interesting topic to discuss.

> 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,

I don't see anything wrong with getting rid of features that people aren't
using.  If those features were popular, C probably wouldn't be as popular
as it is today.  We have lots of CISC archetectures with cool features that
very few people ever find useful.  Why waste the silicon?

It's simply a feedback loop.  I much prefer it to having hardware and
software people totally oblivious to each other.
___
NEVIN ":-)" LIBER, RISC Porting Specialist/Blue Meanie, Mac System Software
 email:     nevin@apple.com        paper:  Apple Computer, Inc.
 voice:     (408) 974-MIX1                 20525 Mariani Avenue, MS: 81-GC
 AppleLink: BADENOV                        Cupertino, CA 95014
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: 18 Nov 92 13:17:53 PST
Organization: Missionaria Phonibalonica

In <Bxw0H0.6EF@mentor.cc.purdue.edu>, hrubin@mentor.cc.purdue.edu (Herman Rubin) wrote:
> In article <waterman.722038647@chaos.cs.brandeis.edu> waterman@cs.brandeis.edu writes:
> 
> 			............................
> 
> >>I do not see how any system of references will enable writing
> 
> >>	*fill(*descriptor)
> 
> >>any faster. 
> 
> >How about
> >	fill(descriptor)  ?
> 
> >Remeber, the dereferencing of the names 'fill' and 'descriptor'
> >are done only once, at _compile_ time, and don't take up a single
> >iota of energy at _run_ time.
> 
> "This does not compute."  The module which produces the contents of
> fill and descriptor is compiled separately from the one that calls it.
> In addition, I specified that there may even be run-time changes, which
> the calling module does not know.  

So? Why do you keep assuming that people are using C syntax? There
have been languages for 20+ years that would take the exact syntax
given, and do exactly what you want with it.

Your continued failure to understand this utterly trivial point isn't
doing your net-image any good.

	<mike

Newsgroups: comp.lang.misc