HDTenEightyP/NetNews huggingface dataset:
From: rro@CS.ColoState.EDU (Rod Oldehoeft)
Subject: More SC '92 language-related sessions
Date: Wed, 11 Nov 1992 23:55:58 GMT
Distribution: na
Organization: Colorado State University

Bert's posting prompts me to also mention some other sessions
at Supercomputing '92 next week:

--Panel discussion:  Which Fortran for High-Performance Computing?
  Moderator:  Cherri Pancake
  Panelists:  Bruce Leasure
		    Guy Steele
		    Joel Williamson
		    Hans Zima

--Panel discussion:  Politically Incorrect Languages for High-
				 Performance Computing
  Moderator:  K. Stuart Smith
  Panelists:  James McGraw
		    David Forslund
		    A. P. Willem Bohm
		    J. C. Browne
		    Ken Kennedy
		    Andy Goforth
		    The "winner" from the previous panel above

--Minisymposium:  Multithreading Computers
  Moderator:  Rod Oldehoeft
  Speakers:   A. P. Willem Bohm
		    Greg Papadopoulos
		    Tony Dahbura

--Workshop:  High Performance Fortran Forum (HPFF)
  Speaker:  David Loveman

--Workshop:  Mapping Programmings to Massively Parallel Computer
             Systems
  Speaker:  John Feo

--Workshop:  Systems for Writing Portable Programs for Parallel/
		   Distributed Computers
  Speakers:  Cherri Pancake
		   Adam Kowala
		   Tim Mattson
		   Ian Foster
		   Al Geist
		   James McGraw
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: 10 Nov 92 15:28:39 PST
Organization: Missionaria Phonibalonica

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:

static char
hook_returning_char(void) {
	return 'a' ;
	}

int
main(void) {
	extern void function_expecting_a_hook(char (void)) ;

	function_expecting_a_hook(hook_returning_char) ;
	}

And, in another file, have:


void
function_expecting_a_hook(char hook(void)) ;

	blah() ;
	foo() ;
	bar() ;
	hook() ;	/* Note: invocation of function of unkown name */
	bletch() ;
	}


	<mike
Newsgroups: comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: Pointers
Organization: Purdue University Statistics Department
Date: Thu, 12 Nov 1992 00:44:57 GMT

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.

I see no reason why the function even has to have a name known to the unit
calling it.  It is quite possible that the function can be changed without
the unit knowing that this has happened.  The compiler cannot resolve problems,
because it does not have the slightest idea of what the function is.

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.
-- 
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: peter@ferranti.com (peter da silva)
Subject: Re: Pointers
Organization: Xenix Support, FICC
Date: Tue, 10 Nov 1992 21:57:13 GMT

In article <1992Nov5.014143.15635@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
>    First: in both, you should avoid having loops.  In the case of GO TO,
>    you should try not to branch backward.  In the case of pointers, you 
>    should try to avoid cyclic data structures.

If you think I'm going to give up doubly-linked circular lists because you
don't like pointers, you've got another think coming.

>    Second: in both, you should avoid aliasing.  In the case of GO TO,
>    you should avoid branching to the same label for many disparate
>    reasons.  In the case of pointers, you should try to avoid have
>    two pointers to the same thing *at all*.

Same objection.

>    Third: you should avoid non-local references.  In the case of GOTO,
>    you should not branch from one program unit to another (even if you
>    *know* the target is all statically allocated or that it's still on
>    the active call stack, etc.).  In the case of pointers, you should 
>    avoid pointing at separately generated data - like from one global
>    array to a different one or from one complicated structure to
>    another.

OK, I'll throw away all my generic symbol table code because it's
politically incorrect. Not.

As for your analogies, an analogy is like instant coffee.
-- 
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: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 13 Nov 92 00:58:03
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Nov7.115620.29967@syacus.acus.oz.au>
	<1992Nov10.024021.8724@linus.mitre.org>
	<BEVAN.92Nov11191720@beluga.cs.man.ac.uk>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: bevan@cs.man.ac.uk's message of 11 Nov 92 19:17:20 GMT

In article <BEVAN.92Nov11191720@beluga.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:

   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.

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). 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. I don't know about RCC or "el(alpha)".
Turbo Pascal is a CPM/MSDOS specialty language--it's not difficult to
be a "portable systems programming language" for a single machine.

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.

					Thomas.
Newsgroups: comp.lang.misc
From: tlai@cs.toronto.edu (Tony Wen Hsun Lai)
Subject: Re: Pointers
Organization: Department of Computer Science, University of Toronto
Date: 10 Nov 92 17:54:39 GMT

In article <1992Nov10.024021.8724@linus.mitre.org> crawford@boole.mitre.org (Randy Crawford) writes:
[stuff deleted]
>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.  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.

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?
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 10:04:11 GMT
Organization: Hewlett-Packard Laboratories, Bristol, UK.

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

[Remarking on my Pop example with ``define 5 ++ (x, y) ...''

   If you could write 

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

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

Well, it seems that this is just a quibble over an (admittedly unpleasant)
definition syntax; I've just checked and conformed that

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

is an acceptable form (the ``lvars'' are required for historical reasons; the
Pop9X standard may well make them the default for formal parameters). There are
good Popish reasons for needing the precedence annotation.

   I would definitely
   allow far more complicated versions, as defining the power operator 
   differently depending on the types of the arguments.  

Steve Kinght's ``objectclass'' will allow this, although I don't recall whether
it allows operator definitions too. [Discussion on Pop can now take place on
comp.lang.pop, yipee!]

   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.

Pop doesn't insist on a stack *machine*, but it's *model* is stack-based. A Pop
compiler is entitled to elide pushes, pops, and calls where the difference
cannot be seen. But Pop the language is, ineluctably, stack-based, and I wasn't
suggesting that Herman code in Pop; I was pointing out that what the rest of
the programming community see as ``user-defined operators'', and what Herman
means by ``u. d. o's'', are *different things*, and suggesting we agree on some
language. 


--

Regards,    | "Layered protocols give the software implementor a chance to
Kers.       | ruin his performance in each layer." - Don Gillies
Newsgroups: comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Xenix Support, FICC
Date: Wed, 11 Nov 1992 18:25:48 GMT

In article <BxDH7G.8Cn@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
> Those who rewrote my code without gotos had to work to do it.

Who cares?

The goal, after all, isn't eliminating the gotos. It's producing maintainable
code. The version I wrote from your code had just as many gotos (some were
switch statements, but it's a 5 minute job to convert them all back and
forth), but it was a lot more readable and maintainable. And I probably spent
less time on it than you spent on the code in the first place.

Frankly, your coding style as we've seen it on the net is so bad nobody can
take seriously any claim that minor syntax changes will make an atom of
difference to your productivity.

You're like someone who's been driving power boats around all his life, and
has no feel for the water. You need to do some sailing... sure, it's not
directly productive time, but neither is flaming on the net. Go, spend some
time learning how to write readable code and then come back. You'll be able
to explain things a lot better, and maybe make your point effectively enough
that people understand.
-- 
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: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: languages which allow the introduction of new operators
Organization: Purdue University Statistics Department
Date: Fri, 13 Nov 1992 14:27:30 GMT

In article <17434@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>
>> 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.

>Why do you object to the use of a stack machine (on which those operations
>are fast)?  If a stack language on a stack machine will run n times as fast
>as a non-stack language on a non-stack machine of equal technology level, why
>not use a stack machine?

>Don't some languages insist (for reasonable performance) that the processor
>provide registers and addressing modes?

HOW can a stack machine be fast?  One of the features of an efficient program
is to have the quantities needed available in registers.  A dozen or two
registers are usually needed to get decent performance, and often it would
help to have hundreds.  On of my friends in the computing center here tells
me that the 256 registers on the CYBER 205 (more than 220 not tied up by
system operations) is not always enough.

But code such as push x; push y; push procedure Z; execute; pop result to w;
will not execute fast compared to 
		
	w = x Z y,

where registers are used.  Also, efficient programming should take into account
which addressing modes are available.

>> Getting any speed out of machines requires that we think of speed in
>> coding, rather than the fact that it is possible in principle to operate
>> with a stack machine with no registers.  This also ignores hardware, such
>> as vector machines, where the use of a control register or control stream
>> introduces basic bit operations which did not exist before, and which are
>> utterly stupid as a means of efficient computation on a stack machine.

>There's no reason why special hardware can't be added to a stack machine.
>You could, for example, add a pair of FIFO "stacks", which might be useful
>for signal processing operations.

It will still not help if more versatile register-type operatations are
appropriate.  

There is an ongoing discussion in comp.arch of the advantages and disadvantages
of stack machines.  
-- 
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: t901580@mp.cs.niu.edu (wiseman john jeffery)
Subject: Availability of MIX language implementation
Summary: Where can I find implementation of MIX language described by Knuth? 
Keywords: MIX, assembly, D. E. Knuth
Organization: Northern Illinois University
Date: Fri, 6 Nov 1992 21:59:24 GMT

Does anyone know where I could find an implementation of the MIX programming
language as described by Knuth in The Art of Computer Programming, vol. 1?

I'm looking for something that will run on a PC...

Thanks,
John Wiseman (t901580@mp.cs.niu.edu)

P.S. email would be appreciated.
Newsgroups: comp.lang.misc
From: chrysler@psych.umn.edu (Susan Chrysler)
Subject: Is there a PowerBuilder newsgroup?
Keywords: PowerBuilder, Windows
Organization: University of Minnesota
Date: Thu, 5 Nov 1992 18:27:47 GMT

Hi - Sorry if these are the wrong groups to ask but ...

I'm looking for information about any users or newsgroup concerned with  
PowerBuilder running in an IBM - Windows environment.  In particular I need  
info on creating re-usable CD-ROM objects in PowerBuilder.

Please replay by e-mail:
chrysler@text2.psych.umn.edu

Thanks in advance,
Sue Chrysler
Department of Psychology
University of Minnesota
Newsgroups: comp.lang.misc
From: hiren@teknetix.com (Hiren Shah)
Subject: ld: Undefined symbol Problem
Organization: Teknetix
Date: Tue, 10 Nov 1992 21:17:40 GMT

Hi:
 
I am trying to "make" a program and foll. are the errors that I get:
 
ld: Undefined symbol
   _sin
   _cos
   _pow
   _floor
   _get_wmShellWidgetClass
   _get_applicationShellWidgetClass
   _dlopen
   _dlclose
   _dlsym
*** Error code 2
make: Fatal error: Command failed for target `xdbx'
 
 
I assume that one/two of the libraries are broken(one of them
probably being the math library ...)
 
Can I just ftp the libraries fromn somewhere or do I have to get the
compiler. ?  Or is there someway to fix it ?
 
Any suggestions will be appreciated.
 
Thanks
 
Hiren
 
Please reply to
hiren@teksun.teknetix.com
 
Newsgroups: comp.lang.misc
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: Re: languages which allow the introduction of new operators
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 13 Nov 1992 08:13:10 GMT

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

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

Why do you object to the use of a stack machine (on which those operations
are fast)?  If a stack language on a stack machine will run n times as fast
as a non-stack language on a non-stack machine of equal technology level, why
not use a stack machine?

Don't some languages insist (for reasonable performance) that the processor
provide registers and addressing modes?

> Getting any speed out of machines requires that we think of speed in
> coding, rather than the fact that it is possible in principle to operate
> with a stack machine with no registers.  This also ignores hardware, such
> as vector machines, where the use of a control register or control stream
> introduces basic bit operations which did not exist before, and which are
> utterly stupid as a means of efficient computation on a stack machine.

There's no reason why special hardware can't be added to a stack machine.
You could, for example, add a pair of FIFO "stacks", which might be useful
for signal processing operations.

--

Nick_Janow@mindlink.bc.ca
From: tmb@orac.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 7 Nov 92 23:34:31
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Nov5.202412.7266@linus.mitre.org> <1de9ckINNfj7@life.ai.mit.edu>
	<1992Nov6.230030.16637@leland.Stanford.EDU>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: orac.idiap.ch
In-reply-to: dhinds@leland.Stanford.EDU's message of Fri, 6 Nov 92 23:00:30 GMT

In article <1992Nov6.230030.16637@leland.Stanford.EDU> dhinds@leland.Stanford.EDU (David Hinds) writes:

   In article <1de9ckINNfj7@life.ai.mit.edu> tmb@ai.mit.edu writes:
   >I do write and use long-running programs (weeks, months) that use
   >multiple workstations extensively in my work.
   >
   >For such programs, I find that correctness and maintainability are of
   >paramount importance.  Efficiency, on the other hand, is of much
   >less importance.

   Sorry, I think correctness/maintainability and efficiency are usually
   orthogonal and one can usually have both.

Of course you can have both. But you seem to have lost track of the
origins of this argument: Rubin claims that "programming languages for
scientists and mathematicians" should have all sorts of esotheric
features to support manual optimizing and they should give you very
low-level access to the machine. But writing correct, maintainable
code in such a language is an arduous and time consuming task, and
many people apparently don't even know how to.

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

					Thomas.
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: Fri, 13 Nov 1992 15:22:34 GMT

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:

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

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.  The above operation is hardware on some machines.  And also,
a list is NOT a struct.  The idea that a function or operation may 
return many values, and that the languages should allow this explicitly,
SHOULD have gotten into programming languages on day 2.  Many machines
in the early days of programming languages explicitly did return more
than one result.
-- 
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: wr@polly.informatik.uni-dortmund.de (Wilfried Rupflin)
Newsgroups: comp.lang.misc
Subject: ISE Eiffel rel. 3  --  alternatives?
Date: 13 Nov 1992 08:19:03 GMT
Organization: CS Department, Dortmund University, Germany
Distribution: world
NNTP-Posting-Host: polly


Does anybody know whether in the new release of ISE Eiffel will
be significant improvements with respect to installation in a
typical workstation environment?

The current release (2.3) requires all Eiffel users to have
*write* access to the *installation* directory! This is not
only nonsense because of security aspects but simply
impossible in an environment where software partitions of
file servers are mounted read-only by their clients.

Will it make sense to wait for the new release
(announced for Sept. 30th)?


Wilfried Rupflin



PS for the impatient:

A few weeks ago a got hands on a *pre*release of the Mjolner
environment for the new (and very powerful) BETA language
for SPARC (final versions for Sun-3, HP 9000, Apollo 3000, and MAC
have been available for some time already). I must say that
I am impressed of the high quality of the implementation.
(Further information: mjolner@mjolner.dk.)


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: Thu, 12 Nov 1992 14:32:54 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.

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