HDTenEightyP/NetNews huggingface dataset:
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 19 Nov 92 12:30:41 GMT
	<722061195@sheol.UUCP> <BxxH8K.C4t@mentor.cc.purdue.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: hrubin@pop.stat.purdue.edu's message of 18 Nov 92 20:07:31 GMT

In article <BxxH8K.C4t@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
   It has been pointed out that there were other possibilities from the
   palette of available characters.  And if they didn't *care*, as you 
   put it, which I am almost sure most of them will deny, that is an
   explicit statement to the mathematical and scientific community that
   they will have to establish their own CS programs to develop it

Unless you are going to deal with the full 2 dimensional nature of
mathematical notation, anything you produce is a compromise.  The only
question then is how much of a compromise.  I fail to see why being
able to define "**" is so important when it is generally accepted that :-  

   ---
   \
   /
   ---

is represented as sigma(...).  If you cannot accept this translation,
then use a language that allows the two dimensional notation.  I have
mentioned Galaxy at least 4 times now and the best response I've got
is "I will look at it".  In the context of a flexible macro processor,
TXL has been suggested (by others and by me) and again, there has been
no feedback.  Why not give some feedback as to why these languages are
inappropriate instead of continually harping on about other languages
that don't fill your requirements?

bevan
Newsgroups: comp.lang.misc
From: moliver@pyramid.com (Mike Oliver)
Newsgroups: comp.lang.misc
Subject: Re: Indirection
Date: 20 Nov 92 19:24:40 GMT
Organization: Pyramid Technology

In article <Bxyut0.Jo@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>                                                        As I understand it,
>*x in C denotes the object referred to by x, the object "found" AT x.

Yes.

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

But this flies in the face of hundreds of years of consistent usage of
the @ symbol in retail trade, where it implies a multiplication (10
items @ $3 each => $30).  This is precisely the sort of ambiguity I
thought you wanted to avoid :-)

(Is it a coincidence that C uses the same symbol as its multiplication
operator and as its dereference operator ?  Was Brian Kernighan an
accountant in a past life ?  Followups to alt.conspiracy)

It's been suggested that C doesn't use the @ symbol (for anything at
all) because it was the default line-kill character in early versions
of Unix.  I've never managed to square this with the use of the #
character to identify preprocessor directives, since # was the default
character-erase character.  Maybe that's why the # has to be the first
character on a preprocessor directive line.

I seem to recall that PL/M-86 and its descendants use the @ symbol as a
address-of operator, the equivalent of C's unary &; this the exact
opposite of your proposed usage.

Cheers, Mike.

moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 16 Nov 92 13:55:34
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<BxpsHo.MID@mentor.cc.purdue.edu> <721864322@sheol.UUCP>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: throopw@sheol.UUCP's message of 16 Nov 92 00:15:16 GMT

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

   : From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
   : This is not a change in subject.  It is the question of whether one
   : is allowed to directly use the machine hardware, or whether one must
   : HOPE that the compiler writer considered what you are doing when the
   : compiler was produced.  

   Nonsense.  Even if your notation is a pointer notation, you must HOPE
   that the compiler writer will translate that into the machine
   instructions you think are best for your task.

In fact, more importantly, if you use pointer notation when you mean
array indexing, you are going to get less then optimal performance on
different hardware. Array indexing can be transformed relatively
easily by a compiler into pointer code, but the reverse transformation
is much harder.

This lesson generalizes: if you provide a wide array of high-level
abstractions, the compiler can choose the best implementation for the
given hardware, and if you choose your abstractions well, there need
not be any runtime cost associated with this. On the other hand, if
you program directly in terms of low-level features, you may be able
to optimize your code for one particular architecture (but only if you
know exactly what you are doing), but you will get poor performance on
other architectures.

					Thomas.
Newsgroups: comp.lang.misc
From: craven@cg.emr.ca (Jim Craven)
Subject: Looking for a PVM/Linda Discussion Group & FAQ list?
Reply-To: craven@cg.emr.ca
Organization: Dept. of Energy, Mines & Resources, Canada
Date: Fri, 20 Nov 1992 21:12:08 GMT

If you know of anything in the subject line, please send me any
info.  Thanks,

Jim
---
Love is like the ozone layer,            |Jim Craven (craven@cg.emr.ca)|
   You don't miss it until it's gone.    |Geological Survey of Canada  |
        ---Frank Drebbin, Police Squad   |1 Observatory Cres., Ottawa  |
-----------------------------------------|K1A 0Y3 (613) 996-9935-------|

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:38:41 GMT

hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
>There IS a way to get some of this, and I have been assured by those
>who supposedly know that this can even be done, and at not too great
>a cost.  That is to allow a really powerful macro language, which 
>would be a syntactical translator from what the user wants to write
>to what some processor can read.  

This is going back 30 years. There was a project at Cambridge (I think, or
maybe Oxford) on a General Purpose MacroGenerator (GPM). This developed a
language called CPL, which I gather was the forerunner of ideas that went
into BCPL, then into B and into C. However, those who worked on this
realised how much further they could push these ideas and took off more
in the direction of HLLs. After all instructions in a language are just
macros. But with a compiler you can achieve much more than just generate
machine code. In fact generation of machine code becomes a somewhat
secondary function compared to helping organise software, and automatically
do proof checking on it. Chris Reade in his book "Elements of Functional
Programming" has some good comments on these more important functions of
languages and compilers.

P.S. I basically disagreed with your car analogies. I think the level of
control over raw machine resources that you are advocating would be rather
like braking a car by sticking your feet through the floor, rather like
the Flintstones. Saying that a compiler writer is like a mechanic who
does not know how a car works is the opposite of reality.

A compiler is actually more like the controls in a car. The pedals, steering
wheel, and other controls in a car, 'compile' your intentions into something
that the car understands. That is because the designer of a car understands
how the car works, so that everyone who drives the car does not need to.
A compiler writer in fact also has intimate understanding of the underlying
machine, so that every programmer does not need to. However, if they are
really interested, they can find out about this level. And when they
really understand it, then they realise you don't need to know a lot
about how hardware works, but that this *is* best left to a compiler.
-- 
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.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 13 Nov 92 09:32:24 GMT
	<1992Nov12.082643.8415@arb-phys.uni-dortmund.de>
	<BxLxqu.96C@mentor.cc.purdue.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: hrubin@pop.stat.purdue.edu's message of 12 Nov 92 14:32:54 GMT

In article <BxLxqu.96C@mentor.cc.purdue.edu> 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

Since you didn't explain the notation, I assume that ".U" means "unpack"
(why the "."?).  Therefore, in Haskell :-

  let (exponent, mantissa) = unpack float
  in ...

bevan
Newsgroups: comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Pointers
Organization: Xenix Support, FICC
Date: Thu, 19 Nov 1992 20:31:07 GMT

In article <mwm.2mx5@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
> (define name car)
> (define func cdr)
> (define handlers '(("plugh" . plughfunc) ... ))

Great. All the pointers are still there. Plus you've added an "address"
operator (quote) instead of the indirection operator.

> Note the added comments - did I assume correctly there?

Yes.

> That loop gets turned into:

> (do ((string (getline) (getline)))
>     ((or
>      (null? string)
>      (zero? ((lookup (firstword line) handlers) (remainder line))))))

Which is precisely the same code with all the same pointers.

All this does is change the syntax around minimally. It hasn't done anything
for the semantics. Where the semantics *do* change is that lisp is a much
safer language. That's got nothing to do with pointers.

> > (I will readily admit that C syntax sucks here: indirection should be a
> > postfix operator:

> Actually, there's no need for the indirection *at all* for any use of
> C function pointers.

Well, yes, but I'm talking in the general case. In any case, ANSI C has turned
(...) into an indirection operator, though they had to leave the explicit
indirection in the declaration. Personally, I prefer the older semantics
because it made the language more symmetrical and comprehensible (yes, the
extra indirection operator made the language clearer: some people don't
like the parens in lisp, but they sure make the syntax and semantics closer
than in (say) Logo).
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Tue, 17 Nov 1992 09:58:26 GMT
Subject: Re: languages which allow the introduction of new operators
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.lang.misc

In article ... throopw@sheol.UUCP (Wayne Throop) writes:

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

It is, perhaps, unfortunate in this instance that Pop's model makes it rather
hard for an implementation to avoid actually having a stack. When calling
system procedures (those things often thought of as ``built-ins'', like ``+''
and ``=''), it should be easy enough to pass parameters via registers, rather
than on the value stack. However, when calling user procedures, this is much
more difficult; you don't know how many arguments they take, how many results
they return, or indeed what procedure they *are* (since, by default, they're
all variables to allow for incremental development and redefinition).

So, the Pop compiler is free to eliminate stack use where it can prove its not
necessary. It's just that the proofs are, in general, impossible.

Any more Pop questions should be taken to comp.lang.pop.



--

Regards | "Always code as if the guy who ends up maintaining your code will be
Kers.   | a violent psychopath who knows where you live." - John F. Woods
From: peter@ferranti.com (peter da silva)
Subject: Re: Pointers
Organization: Xenix Support, FICC
Date: Fri, 20 Nov 1992 17:57:48 GMT

In article <BEVAN.92Nov14094620@tiger.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) 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.

I have tried a couple of times to use Modula-2 as a serious alternative
to C.

> Name the problems and we can find out.

Complete lack of anything like a standard runtime library. Not even all
compilers provide the InOut library specified in Wirth, and those that
do all end up having custom extensions for stuff I can do using stdio
in C. Wirth has a poor track record here: the Pascal runtime was unusable
for nontrivial applications, and Modula doesn't have a well specified
runtime I/O system at all.

It's annoying. I'd much rather use Modula-2 for non-trivial projects, but
I'm not prepared to define my own runtime. I already did that once, for
Ratfor...
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.lang.misc
From: jmc@mas1.UUCP (John M. Cooney)
Newsgroups: comp.lang.misc
Subject: Imbedded Languages
Date: 23 Nov 92 16:16:31 GMT
Organization: Measurex Automation Systems, Cupertino CA

I am designing a product which requires a powerful and efficient macro
facility.  I would rather purchase and extend an existing language
than develop my own.  The language must run on Windows, OS/2 and Unix.
If it includes an integrated editor and debugger all the better.

I would appreciate any input on language systems or suppliers which
might help me resolve this problem.

Thanks in advance,

	John M. Cooney
	mas1!jmc@apple.com
	408-864-6787

                         ----- End of Message -----
Newsgroups: comp.lang.misc
From: von@cory.Berkeley.EDU (Steve Von Worley)
Subject: Dataflow Languages
Organization: University of California, at Berkeley
Date: Mon, 23 Nov 1992 06:41:57 GMT

Hi.  I'm writing a survey covering dataflow languages, and need 
references.  Please respond by email, and thanks in advance.

Steve
-- 
Steve Von Worley
von@cory.berkeley.edu
Computer Science Gradual Student
University of California at Berzerkly 
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Pointers
Organization: Purdue University Statistics Department
Date: Thu, 19 Nov 1992 20:35:53 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 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.

The feedback loop is far more insidious than you make it to be.  Languages
are provided which lack features, and to get those features into a program
requires doing things which are not recognized as such.  Thus if a particular
machine instruction is used for some purpose, how does the hardware designer
find out about it?  They consult the language people, and except for the
GNU people, almost none of them seem to pay attention to the mathematicians,
physicists, chemists, etc.

So the hardware people consider C to be the be-all and end-all, and design
their hardware accordingly.  This would be like saying that mathematicians
should not teach proofs and arguments, because most people ignore them.  
They do, and we all suffer.
-- 
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: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Pointers
Organization: University of Jyvaskyla, Finland
Date: Tue, 17 Nov 1992 09:59:55 GMT

In article <1992Nov13.102813.9215@rdg.dec.com> jch@rdg.dec.com (John Haxby) writes:
>In article <1992Nov12.141532.16375@jyu.fi>, sakkinen@jyu.fi (Markku Sakkinen) writes:
>
>|> [ ... ] I cannot see any semantic
>|> difference between CLU variables (of non-atomic types) and reference
>|> (or pointer) variables in many other languages.  'By sharing' is
>|> exactly the same as 'by reference'.
>
>In CLU, x in
>
>	p1 = proc (x: int) ... end p1
>and
>	p2 = proc (x: string) ... end p2
>
>is passed by sharing.  In the VAX implementation, the p1 has its
>argument passed by value, the second by reference (in the grubby
>depths).  In the PCLU implementation, both procedure calls pass
>a CLUREF structure (by value) which contains the value of an integer
>or a pointer to string data.  `By sharing' allows the implementation of
>the compiler to choose the mechanism for passing the parameter to
>a procedure, the only requirement is that changing the contents of a
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
>mutable argument is reflected in all instances of the argument.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Don't mix implementation strategies with language semantics.

Sorry, but seems like you are discussing implementation strategies,
not I.  The marked quote above says that the semantic effect is _as if_
the parameter were passed by reference;  I couldn't care less how
a particular compiler actually implements it.  (I have just pointed
out in another thread, in comp.lang.modula2, that by-value and
by-reference are equivalent for immutable parameters, so we have
no argument about that.)

I would say that LISP, CLU etc. are _not_ simpler than Pascal, Ada etc.
because they have no explicit pointers -- but they are simpler because
they have essentially _only_ pointers.  There are no value assignments
for complex objects, as a primitive language feature.

The drawback of that simplicity is that you get a lot of potential
aliassing problems, which would not be necessary in those languages
in which value semantics is available.  In a fashion, C and its derivatives
have the worst of both worlds.  On one hand, you must explicitly take care
of pointers.  On the other hand, value semantics isn't applicable to arrays.
(Jim Giles has posted sufficiently about the drawbacks of C arrays,
so I need not repeat any of that.)

Well, I think I have beaten this subject to death for my part.
Sorry for boring the audience.

----------------------------------------------------------------------
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: lwv26@cas.org (Larry W. Virden)
Subject: Embedded languages (Was: Re: Imbedded Languages)
Followup-To: comp.lang.misc
Reply-To: lvirden@cas.org (Larry W. Virden)
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Tue, 24 Nov 1992 03:41:43 GMT


There are occasional references to an embedded languages catalog being
maintained by someone on the net.  I know of the two projects to catalog
computer languages that are on going - I am trying to track down the home
site for this third effort.  Any pointers?
-- 
Larry W. Virden                 UUCP: osu-cis!chemabs!lvirden
Same Mbox: BITNET: lvirden@cas  INET: lvirden@cas.org
Personal: 674 Falls Place,   Reynoldsburg, OH 43068-1614
Xref: sparky comp.lang.misc:3800 comp.lang.rexx:1328
From: jmc@mas1.UUCP (John M. Cooney)
Newsgroups: comp.lang.misc,comp.lang.rexx
Subject: Imbedded Languages
Date: 19 Nov 92 21:17:31 GMT
Organization: Measurex Automation Systems, Cupertino CA

I am designing a product which requires a powerful and efficient macro
facility.  I would rather purchase and extend an existing language
than develop my own.  The language must run on Windows, OS/2 and Unix.
If it includes an integrated editor and debugger all the better.

I would appreciate any input on language systems or suppliers which
might help me resolve this problem.

Thanks in advance,

	John M. Cooney
	mas1!jmc@apple.com
	408-864-6787

                         ----- End of Message -----
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 13 Nov 92 17:36:33 GMT
	<KERS.92Nov12085629@cdollin.hpl.hp.com>
	<BxMCxA.3nM@mentor.cc.purdue.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: hrubin@pop.stat.purdue.edu's message of 12 Nov 92 20:00:45 GMT

In article <BxMCxA.3nM@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
   If you could write 

   define	(x ++ y) x+y+1

   I would accept that as the insertion of the ++ operator.

Ah, so now that your given an example of a language in which you can
do the desired operation, you complain about the syntax!  How about
the following :-

 infix 0 ++

 x ++ y = x+y+1


Note 1. I've arbitrarily chosen the associativity and precedence as
        you didn't state any preference.
     2. "++" is already defined in Haskell, so you'd need to explicitly
	override the default definition, this would be done at the
	module level.

bevan
Newsgroups: comp.lang.misc