HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (Peter da Silva)
Subject: Re: PL/1 non-local goto versus setjmp/longjmp
Organization: Xenix Support, FICC
Date: Tue, 18 Aug 1992 14:54:47 GMT

In article <mwm.1jk3@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
> In <id.VJBS.0DK@ferranti.com>, peter@ferranti.com (Peter da Silva) wrote:
> > Personally, I'd prefer if C had no goto at all, but an organized system of
> > contexts, so you could perform setjmp/longjmp operations within a routine.

> I'm not quite sure what you mean by "organized system of contexts"? If
> this mechanism would allows multilevel loop breaks. If not, I'd like
> more details on it.

Basically, imagine integrating setjmp/longjmp with the language to a greater
extent. Instead of writing:

	retry:
		insert amazing mass of nested loops here {
			goto retry;
		}
		and put in some more code here
		if something horrible happens {
			goto fail;
		}
		and still more code
	fail:

You use a formal setup like so:

	context foo: {
		insert amazing mass of nested loops here {
			continue foo;
		}
		and put some more code here
		if something horrible happens {
			break foo;
		}
		and still more code
	}

Now, to generalize:

	context foo;

	...

	context foo: {
		yadda yadda yadda
		bar(foo);
	}

void bar(foo)
context foo;
{
	blah blah blah;
	if something horrible happens {
		break foo;
	}
}

But putting it directly in the language, you allow for more optimizations.
By replacing goto, you clean up a messy part of the language without losing
any general capability (switches with good optimization and this context
can replace every use of goto).

As a further elaboration (my long-term fantasy, real coroutine support in C):

	context other, self;
	stack_t otherstack[MIN_STACK + 20*STACK_FRAME + 20*30*sizeof(int)];
	extern void token(context, context);

	bind other: otherstack, token, (self);
	bind self;

	while((t = pause(other, 1)) != EOF) {
		handle_token(t);
		if we need to bail out
			(void)pause(other, 0);
	}


token(other)
context other;
{
	char buf[whatever];

	while(gets(buf)) {
		parse tokens here;
		if it looks like a foo
			if(!pause(other, foo))
				break;
		...
	}
}

Yes, you can build subroutine libraries that do this, but they're inherently
non-portable. This sort of thing should be part of the language, and is much
more important to me than expanding the type structure with object-oriented
stuff.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: dg@polly.dgupta.hpl.hp.com (Dipankar Gupta)
Newsgroups: comp.lang.misc
Subject: Re: PL/1 non-local goto versus setjmp/longjmp Re: CISC Microcode
Date: 20 Aug 92 16:27:16 GMT
Organization: Hewlett-Packard Laboratories, Bristol, UK

In article <id.KTGS.0N5@ferranti.com> peter@ferranti.com (Peter da Silva) writes:

[Elided]

| Basically, imagine integrating setjmp/longjmp with the language to a greater
| extent. ...

[More elided]

| But putting it directly in the language, you allow for more optimizations.
| By replacing goto, you clean up a messy part of the language without losing
| any general capability (switches with good optimization and this context
| can replace every use of goto).

[Stll more elided]

| Yes, you can build subroutine libraries that do this, but they're inherently
| non-portable. This sort of thing should be part of the language, and is much
| more important to me than expanding the type structure with object-oriented
| stuff.

What you describe was generalised by Peter Landin in '65, who called
it the J operator. It has been adopted, in particular, by languages
like Scheme and ML which use it to define powerful control structures.
(The FP/Lisp community calls it ``call with current continuation'' or
call/cc).  For examples of the usages that you outlined, see the
Scheme stream-based IO or the Cornell work on Concurrent ML.

Cheers,
Dipankar Gupta
Hewlett-Packard Laboratories
Bristol UK

PS: I don't think that ML has continuations as a part of the Standard,
but the New Jersey implementation provides call/cc as a first-class
language element.

References:
[1] Landin, P. A correspondence between Algol 60 and Church's lambda
notation: Part 1 [C. ACM 8(2) pp89-101, Feb. 1965]

[2] Clinger, W and Rees, J (eds). Revised^4 Report on the Algorithmic
Language Scheme.
--
--
Newsgroups: comp.lang.misc,comp.edu,comp.lang.forth,comp.lang.fortran
From: davis@pacific.mps.ohio-state.edu ("John E. Davis")
Subject: Re: Small Language Wanted
Followup-To: comp.lang.fortran
Reply-To: davis@pacific.mps.ohio-state.edu  (John E. Davis)
Organization: "Dept. of Physics, The Ohio State University"
Date: Sun, 23 Aug 1992 06:06:05 GMT

In article <41910@skye.dcs.ed.ac.uk> gvw@epcc.ed.ac.uk (Greg Wilson) writes:
>  I regularly lambast physicists for using "old" languages like Fortran,
>  so I feel I should set a good example for students by using some
>  modern ideas myself)

   First of all, I have a PhD in Physics and it is true that like most
physicists that I know, I have never taken a course in computer science.  I
learned Fortran (from the VAX/VMS Fortran manual) because I was presented a
problem which required a numerical solution and the only available canned
routines were in Fortran.  Since that time, I have taught myself pascal, C,
and Lisp and I consider myself to be a better C programmer than most and I
feel much more comfortable with C than I do with Fortran.  However, I still
feel that Fortran is superior to C for numerical work in many respects.  The
ANSI C has improved the situation a bit (Old K&R C might take something like
`x = (a * b) / c' and rearrange it as `x = a * (b / c)' which could be deadly
for many algorithms).  In addition, C has nothing equivalent to Fortrans **
operator nor does it have complex types.  And arrays, C has no true array type
like Fortran does (One must use pointers to pointers ... to pointers).  Yes
Fortran is still superior to C for what it is intended to do: Numerical Work.
Anyone who ``regularly lambast physicists for using "old" languages like
Fortran'' is a little ignorant in my view.

  The only real thing that I miss in Fortran 77 is a pointer type.  There are
many times when I wanted to pass pointers to functions through common blocks.


--
     _____________
#___/John E. Davis\_________________________________________________________
#
# internet: davis@amy.tch.harvard.edu
#   bitnet: davis@ohstpy
#   office: 617-735-6746
#
Newsgroups: comp.lang.misc
From: laverman@cs.rug.nl (Bert Laverman)
Subject: Re: PL/1 non-local goto versus setjmp/longjmp
Originator: laverman@rug16
Organization: Dept. of Computing Science, Groningen University
Date: Thu, 20 Aug 1992 07:44:23 GMT


[Impressive demonstration by Peter removed]
I'm sorry, but aren't you just implementing Exceptions here?

Greetings, Bert
-- 
#include <std/disclaimer>

  Bert Laverman,  Dept. of Computing Science, Groningen University
  Friendly mail to: laverman@cs.rug.nl      The rest to: /dev/null
From: jack@dcs.glasgow.ac.uk (Jack Campin)
Newsgroups: comp.lang.misc
Subject: Re: Ideas for time-series manipulation language
Date: 17 Aug 92 15:38:00 GMT
Reply-To: jack@dcs.glasgow.ac.uk (Jack Campin)
Organization: COMANDOS Project, Glesga Yoonie

tgl+@cs.cmu.edu (Tom Lane) wrote:
> I'm thinking about designing a language in which discrete time series are a
> fundamental data type.  I have vague memories of having seen similar ideas
> before, so I'm hoping someone can point me to prior work.
> The data I want to manipulate comes as series of observations taken at
> certain intervals of time (not necessarily the same interval for each
> series).
> I want to be able to refer to such a series as a single data object;
> to perform operations on such objects (eg, to add corresponding elements
> of two series to deliver a sum series), and to define functions that work
> on such objects (integration and correlation might be examples).  I want
> the functions to be able to work incrementally as new values are added to
> each data series (lazy evaluation might help here).

Try this:

AUTHOR: Wadge William W.
TITLE: Lucid, the dataflow programming language
IMPRINT: London Academic Press 1985
SERIES: Studies in data processing (Brighton College of Technology. Automatic
          Programming Information Centre) v.22
OTHER AUTHORS: Ashcroft Edward A.

-- 
--  Jack Campin    room G092, Computing Science Department, Glasgow University,
17 Lilybank Gardens, Glasgow G12 8RZ, Scotland   TEL: 041 339 8855 x6854 (work)
INTERNET: jack@dcs.glasgow.ac.uk or via nsfnet-relay.ac.uk    FAX: 041 330 4913
BANG!net: via mcsun and uknet     BITNET: via UKACRL    UUCP: jack@glasgow.uucp
Newsgroups: comp.lang.misc,comp.lang.scheme,comp.lang.forth,comp.edu
From: campbell@redsox.bsw.com (Larry Campbell)
Subject: Re: Small Language Wanted
Organization: The Boston Software Works, Inc.
Date: Sat, 22 Aug 1992 15:45:50 GMT


In article <174fbuINNppn@agate.berkeley.edu>, bh@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
> Could everyone who follows up this flame war please remove
> comp.lang.logo from the newsgroup list?  Thank you.

Likewise for comp.lang.scheme, please.
-- 
Larry Campbell             The Boston Software Works, Inc., 120 Fulton Street
campbell@redsox.bsw.com    Boston, Massachusetts 02109 (USA)
Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
Subject: Re: Small Language Wanted
Organization: Indiana University, Bloomington
Date: Fri, 21 Aug 1992 17:12:08 GMT

In article <1992Aug21.144444.11414@ncsu.edu> jwb@eos.ncsu.edu writes:
>Mike Coughlin writes:
>>   As a user of Fortran, I must protest the idea that Fortran is an 
>> old language. Since structured programming concepts were introduced
>> into Fortran many years ago, there are no "modern" programming ideas
>> that are need in Fortran to accomplish its purpose of scientific
>> and mathematical computation. The mathematical notation used by 
>
>Of course one can express "scientific and mathematical computations"
>in Fortran, C, TeX, PostScript, etc.  However, the tremendous interest
>in "object-oriented" programming among engineers and scientists shows
>that they have finally come to realize that the structure and
>organization of data are important---not exactly one of Fortran's
>strong points.

Not to fan a flame war, but indeed C++ is _excellent_ for working with
complex numbers, etc.  And, nobody will accuse you of using an outdated
language.

I used Fortran up until about 2 years ago.  It does do about anything that
you want, and DEC's Fortran compiler for VMS is probably the best single
compiler that I've ever met (in terms of optimization).  But, the lack
of structures, pointers, and recursion are crippling.  I know that they are
adding/have added some of these features, but they still aren't everywhere,
yet.

C is an excellent language for scientific stuff, and C++ even better.

Check out the flame-war du jour in soc.college for more information on
how Scheme "is great|sucks" compared to C which "is great|sucks".

	Darrin
-- 

mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu

"It's a marvel of vegetable containment..."
From: peter@ferranti.com (Peter da Silva)
Subject: Re: PL/1 non-local goto versus setjmp/longjmp
Organization: Xenix Support, FICC
Date: Fri, 21 Aug 1992 16:20:43 GMT

In article <1992Aug20.074423.4841@cs.rug.nl> laverman@cs.rug.nl (Bert Laverman) writes:
> [Impressive demonstration by Peter removed]
> I'm sorry, but aren't you just implementing Exceptions here?

Well, sort of. You can *use* this to implement exceptions (for example,
set up an inheritance mechanism) but the same is true of longjmp/setjmp.
Plus, you don't traditionally combine exceptions and coroutines into a
single concept.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Xref: sparky comp.lang.misc:2751 comp.lang.logo:168 comp.lang.scheme:2067 comp.lang.forth:2988 comp.edu:1294
From: mikc@hal.gnu.ai.mit.edu (Mike Coughlin)
Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
Subject: Re: Small Language Wanted
Date: 21 Aug 92 14:01:11 GMT
Organization: /etc/organization

In article <41910@skye.dcs.ed.ac.uk> gvw@epcc.ed.ac.uk (Greg Wilson) writes:
>[apologies if this is a re-post --- problems first time around]
>
>Hello.  I am looking for a small language to use and modify for teaching
>purposes.  Features I want include:
>
>* small, simple implementation in C (at most one week for a senior
>  student with a C/Unix background to read and understand source).
>
>* very simple syntax --- preferably only a single syntactic form,
>  like Scheme, Logo, and Forth.
>
>* textual scoping of variables (which (sigh) rules out Logo itself)
>
>* logical, integer, floating-point, and string data types (I'm
>  happy to have single characters treated as 1-length strings)
>
    Your goals are mutually exclusive. You ask for a simple language
and then want to include many complicated features. There are versions
of Forth available in the form of C programs. You can get a good one
by ftp from prep.ai.mit.edu as part of the gnu collection. Look for 
the file called tile.2.1.tar.Z. Since it is written in C and does
not exactly follow usual Forth practices, it is named a "threaded
interpretive language" or TIL.
 
>  I regularly lambast physicists for using "old" languages like Fortran,
>  so I feel I should set a good example for students by using some
>  modern ideas myself)
  As a user of Fortran, I must protest the idea that Fortran is an 
old language. Since structured programming concepts were introduced
into Fortran many years ago, there are no "modern" programming ideas
that are need in Fortran to accomplish its purpose of scientific
and mathematical computation. The mathematical notation used by 
physicists is an old language and they don't have much interest in
changing it. So why should they want to switch from Fortran? Perhaps
if other computing languages included things like exponential operations
( ** ), and complex number arithmetic there would be more reason to use
something besides Fortran.
  The best new idea that physicists (and every other programmer) should
use is extensive commenting so human beings can read source listings.
That would be the greatest advance since digital computers were invented.
   Of course if you want a language that can be modified to include any
new idea that you want to try, Forth is a very good choice. And I've
heard that Lisp and Scheme are good for that too.
Newsgroups: comp.lang.misc
From: esh@boron.tekbspa.com (Edward S. Hirgelt)
Subject: Re: Origin of "dope vector"
Organization: Direct Interfaces Corporation @ Teknekron
Date: Thu, 20 Aug 1992 22:08:59 GMT


On 19 Aug 92 20:56:11 GMT,
rro@cs.ColoState.EDU (Rod Oldehoeft) said:

Rod>                                   The oldest reference I
Rod> have for this particular term is Gries' 1971 book, where
Rod> the reference is:

Rod> ... "For arrays this template is called a dope vector or
Rod> information vector. ...

I'm not sure of the exact first use, but I first encountered ``dope
vector'' in reading the PL/I reference manuals for the OS 360 in late
1969. Gries was at that time pretty IBM oriented so his use may have
derived from the same PL/I documentation. PL/I had already been around
for a while in 1969 so the terminology is prabably older. 

Good luck in your search,
Ed


--
Ed Hirgelt			esh@tss.com
Direct Interfaces Corporation
San Jose, Ca.
Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Re: Small Language Wanted
Followup-To: comp.lang.misc,comp.edu
Organization: Dept. of Computer Science, University of Ottawa
Date: Fri, 21 Aug 92 23:15:11 GMT

In article <1992Aug21.153733.5683@coe.montana.edu> oususalg@cs.montana.edu (Glassy) writes:
>In article <1992Aug21.144444.11414@ncsu.edu> jwb@eos.ncsu.edu writes:
>!Mike Coughlin writes:
>	[...Fortran works...]
>
>!Of course one can express "scientific and mathematical computations"
>!in Fortran, C, TeX, PostScript, etc.  However, the tremendous interest
>!in "object-oriented" programming among engineers and scientists shows
>!that they have finally come to realize that the structure and
>!organization of data are important---not exactly one of Fortran's
>!strong points.                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>^^^^^^^^^^^^^^^
>
>Have you taken a look at Fortran-90 lately?  If you have, you'll have
>noted that the structure and organization of data are indeed strong
>points in F90.  As far as the recent (1980-present) fashionable
>interest in object-oriented this-and-that, F90 supports data-hiding via
>modules, generic subprograms, operator and function overloading...

Seeing as how I haven't seen any Fortran-90 compilers around, the
improved features in this "new" language are largely irrelevant.  From
what I can see, most of the people that have been writing code in
Fortran are still using the features of Fortran-77.  

If you develop F90 code, you're throwing away portability, because
it's not clear that many people actually have access to a F90
compiler.  It certainly isn't something that gets bundled as the
"standard Fortran compiler" on the university mainframes.  If YOU
develop F90 code, I certainly won't be able to use it, because between
the dozen or so different systems I have access to, NONE of them has
an F90 compiler.  Several of them have quite nice F77 compilers...
All of them have C (in at least K&R form), some have C++, most have
Lisp, and some have Forth.  No F90 on the list...

The even BIGGER problem is the fact that these improved features
really make it a new language.  The fact that it may be backwards
compatible is NOT a bonus.  It just means that a lot of people will
continue to write "old style" FORTRAN code, and just ignore the
features that have been added.  And the people that want to go OOP
will have to do it in what is, in essence, a new language.  And
this means that there's not much cost to ACTUALLY going to a new
language, like C++.

Scientists and engineers use FORTRAN because it is the language that
they were taught.  I would be surprised if there are very many
universities that are teaching their new undergrads FORTRAN-90 right
now.  They're either teaching F77, because they have (a) Texts for
that, (b) Compilers for that, and (c) Instructors with 15 years of
experience at teaching FORTRAN-77.

FORTRAN 77 will never die - like it or not - and I seriously doubt
that it will be supplanted by FORTRAN 90.

-- 
Christopher Browne
cbbrowne@csi.uottawa.ca
University of Ottawa
Master of System Science Program
From: ilsjohn@smartstar.com (john mcdowall)
Newsgroups: comp.lang.misc
Subject: Re: Ideas for time-series manipulation language
Keywords: time series, semantics
Date: 21 Aug 92 23:22:12 GMT
Organization: SmartStar Corp. / Signal Technolgy Inc.


The other source of ideas for treating discrete time
series as objects is the work done at MIT by Gary Kopec
and several other people. His thesis is:

"The Representation of Discrete-Time Signals and
Systems in Programs" May 1980. 

There has been a lot of follow up work since by
Brad Meyers and several other people. We have been 
using this work extensively in a commercial product
for several years, and have found it a powerful way
to treat data.

John McDowall
ilsjohn@smartstar.com
From: mike@adpgate.UUCP ( ADP OPuS)
Newsgroups: comp.lang.misc
Subject: ACTOR
Date: 20 Aug 92 17:30:54 GMT
Organization: ADP Dealer Services R&D, Portland, OR

in seeing a SIG for comp.lang.actor on the net?
From: rro@cs.ColoState.EDU (Rod Oldehoeft)
Newsgroups: comp.lang.misc
Subject: Origin of "dope vector"
Date: 19 Aug 92 20:56:11 GMT
Reply-To: rro@cs.ColoState.EDU
Organization: Colorado State University

I'm writing up a little paper on array implementation and
manipulation.  I use the term "dope vector" for the data
structure that holds lower and upper bounds and subscripting
multipliers for each dimension.  The oldest reference I
have for this particular term is Gries' 1971 book, where
the reference is:

... "For arrays this template is called a dope vector or
information vector. ...

The terms are underlined, but still it seems to be a term
in common use at that time.  Does anyone know where the
term was first coined?

-- 
|--------------------------------------------------------------|
| Rod Oldehoeft                    Email: rro@cs.colostate.edu |
| Computer Science Department      Voice: 303/491-5792         |
| Colorado State University        Fax:   303/491-6639         |
| Fort Collins, CO  80523                                      |
|--------------------------------------------------------------|
| Three outstanding attitudes---obliviousness to the growing   |
| disaffection of constituents, primacy of self-aggrandizement,|
| and the illusion of invulnerable status---are persistent     |
| aspects of folly.   ---Barbara Tuchman, "The March of Folly" |
|--------------------------------------------------------------|
Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
From: elsbernd@arctecserv-2.informatik.uni-kl.de (Klaus Elsbernd)
Subject: Re: Small Language Wanted
Reply-To: elsbernd@arctecserv-2.informatik.uni-kl.de (Klaus Elsbernd)
Organization: University of Kaiserslautern, Germany
Date: Fri, 21 Aug 1992 08:29:44 GMT

In article <41910@skye.dcs.ed.ac.uk>, gvw@epcc.ed.ac.uk (Greg Wilson) writes:
|> [apologies if this is a re-post --- problems first time around]
|> 
|> Hello.  I am looking for a small language to use and modify for teaching
|> purposes.  Features I want include:
|> 
|> * small, simple implementation in C (at most one week for a senior
|>   student with a C/Unix background to read and understand source).
|> 
|> * very simple syntax --- preferably only a single syntactic form,
|>   like Scheme, Logo, and Forth.
|> 
|> * textual scoping of variables (which (sigh) rules out Logo itself)
|> 
|> * logical, integer, floating-point, and string data types (I'm
|>   happy to have single characters treated as 1-length strings)
|>  ...
You can try siod (Scheme In One Defun, Version 2.4)
available at world.std.com, BU.EDU (128.197.2.6), or try archie.
(If you like, I can mail it to you.)

Some advertisement copied from an other news group copied from \ldots:
(Don't know the original poster)
vvvvvv
What is SIOD? It is an extremely small scheme implementation in C
arranged as set of subroutines that can be called from any main
program for the purpose of introducing an interpreted extension
language.

How small is it? Compiling using the VAX/VMS C compiler results in a
total of 16333 bytes of executable code.

What features?
 * Lisp calls C and C calls lisp transparently
 * no hassle in C coded functions due to GC or EVAL considerations.
 * ability to hook into the read-eval-print loop without modifying the code.
 * ability to extend the datatypes without modifying the code.
 * mark-and-sweep or stop-and-copy GC selectable at runtime.
 * readmacros
 * macros
 * backquote (quasi-quote)
 * optionally loadable pratt (infix-language) parser

Platforms?
 * VAX/VMS * VAX UNIX * SUN-3 * SUN-4 * AMIGA * MACINTOSH * MIPS * CRAY
^^^^^^^

If you wan't a more complex system try kernel, a dynamic lisp interpreter
published (source code included) at Addison Wesley
(or try my extensions to it).

MfG

Klaus Elsbernd

elsbernd@dfki.uni-kl.de
elsbernd@informatik.uni-kl.de