[net.lang.c] swap

Schauble@MIT-MULTICS.ARPA (Paul Schauble) (06/08/86)

Can someone construct a version that makes

    int *a, *b;
    swap (*a++,*b++);

work right?

          Paul
          Schauble at MIT-Multics.arpa

rbj@icst-cmr (Root Boy Jim) (06/10/86)

	Can someone construct a version that makes
	
	    int *a, *b;
	    swap (*a++,*b++);
	
	work right?
	
	          Paul
	          Schauble at MIT-Multics.arpa
	
Probably not. In general, macros don't work on arguments that have side effects.

	(Root Boy) Jim Cottrell		<rbj@cmr>
	PEGGY FLEMMING is stealing BASKET BALLS to feed the babies in VERMONT.

geoff@ism780c.UUCP (Geoff Kimbrough) (06/19/86)

In article <1201@brl-smoke.ARPA> Schauble@MIT-MULTICS.ARPA writes:
>Can someone construct a version that makes
>
>    int *a, *b;
>    swap (*a++,*b++);
>
>work right?

#define SWAP(a,b) {int *A= &(a),*B= &(b),temp; temp= *A; *A= *B; *B= temp;}
	/* Or, for more generality.  */
#define SWAP(type,a,b) {type *A = &(a),*B = &(b),temp; temp = *A; *A = *B; \
	*B = temp;}  /* invoked as SWAP( int, *a++, *b++ );     */

As has been pointed out, macros generally don't work when given arguments
with side effects, (arguments? parameters? formals? who cares, if you
understand what I mean)  However, if you're careful to have the arguments
appear ONLY ONCE in the expansion, you can get the results you're after.
This trick only works with macros that have pointers as arguments, of
course.

I *don't* think this macro should be *used*, since it's got to be slower to
do all the extra pointer chasing and such than to break up your statement
into  {  swap(*a,*b); a++; b++; }.  If you're concerned about having to
insert extra braces, I don't even want to tadc tg qgu   0V! !$ A bust ggtt`rgug` readafg af eftaredq ufcgeeefted prggrae wat`2w`ade   sgeet`afg )(/*(<--(no(kurly brace */
		if ( whatever ) {
			hundreds of statements on several pages;
			with 8 space tabs, the code dissappeared off the
			right margin, and gradually walked back, until:
		}
	/* <-- no curly here either */
Took me over an hour just to confirm that the braces matched up.

greg@utcsri.UUCP (Gregory Smith) (06/20/86)

In article <1201@brl-smoke.ARPA> Schauble@MIT-MULTICS.ARPA (Paul Schauble) writes:
>Can someone construct a version that makes
>
>    int *a, *b;
>    swap (*a++,*b++);
>
>work right?
>
#define swap( a,b ) { int *p1,*p2,t;\
	p1= &(a); p2= &(b); t= *p1;*p1= *p2;*p2=t;}

No, it isn't pretty.
how about:

#define swap(a,b) fswap(&(a),&(b))
fswap(a,b) int *a,*b;
{	etc.


-- 
"Shades of scorpions! Daedalus has vanished ..... Great Zeus, my ring!"
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg

allan@cs.strath.ac.uk (Allan Black) (06/20/86)

In article <1201@brl-smoke.ARPA> Schauble@MIT-MULTICS.ARPA writes:
>Can someone construct a version that makes
>    int *a, *b;
>    swap (*a++,*b++);
>work right?

#define swap(p,q) {int *x = &(p), *y = &(q); int z = *x; *x = *y; *y = z;}

This will only work for type 'int'; if you want to make it more general, try
something like:
{long *x = (long)(&(p)) etc.
But be careful with something like that - there's no typechecking, so you
can easily mix pointers up, with disastrous results!

-- 
UUCP:	...!seismo!mcvax!ukc!strath-cs!allan
DARPA:	allan%cs.strath.ac.uk@ucl-cs	JANET:	allan@uk.ac.strath.cs

"This doesn't seem to be working, sir!"
"Yes, but I was trying to ignore it so that YOU wouldn't look stupid!"
				-- Monty Python's Flying Circus

steve@anasazi.UUCP (Steve Villee) (06/20/86)

> Can someone construct a version that makes
> 
>     int *a, *b;
>     swap (*a++,*b++);
> 
> work right?
> 
>           Paul
>           Schauble at MIT-Multics.arpa

--------------------------------

#define swap(x, y) \
  if (1) \
  { \
    register int *xp, *yp, t; \
    xp = &(x); \
    yp = &(y); \
    t = *xp; \
    *xp = *yp; \
    *yp = t; \
  } \
  else

--------------------------------

The "if (1) ... else" allows the user to put a semicolon after the macro
invocation, and makes code such as

  if (today == tuesday)
    swap(*a++, *b++);
  else
    swap(*c++, *d++);

work correctly.

--- Steve Villee (ihnp4!mot!anasazi!steve)
    International Anasazi, Inc.
    7500 North Dreamy Draw Drive, Suite 120
    Phoenix, Arizona 85020
    (602) 870-3330

ark@alice.UucP (Andrew Koenig) (06/22/86)

> #define swap(x, y) \
>   if (1) \
>   { \
>     register int *xp, *yp, t; \
>     xp = &(x); \
>     yp = &(y); \
>     t = *xp; \
>     *xp = *yp; \
>     *yp = t; \
>   } \
>   else
>
> --------------------------------
>
> The "if (1) ... else" allows the user to put a semicolon after the macro
> invocation, and makes code such as
> 
>   if (today == tuesday)
>     swap(*a++, *b++);
>   else
>     swap(*c++, *d++);
> 
> work correctly.

On the other hand, if you forget a semicolon:

	if (x < y)
		swap (x, y)
	printf ("%d %d\n", x, y);

you will spend a long time wondering why it doesn't print anything.

Of course, if you write in C++, you can say:

	inline void swap (int& x, int& y)
	{
		register int t = x;
		x = y;
		y = t;
	}

and be done with it.  It's a true function, the compiler checks
types for you, you can define several swap functions for different
types, and so on.

levy@ttrdc.UUCP (Daniel R. Levy) (06/22/86)

In article <2595@ism780c.UUCP>, geoff@ism780c.UUCP (Geoff Kimbrough) writes:
>I *don't* think this macro should be *used*, since it's got to be slower to
>do all the extra pointer chasing and such than to break up your statement
>into  {  swap(*a,*b); a++; b++; }.  If you're concerned about having to
>insert extra braces, I don't even want to tadc tg qgu   0V! !$ A bust ggtt`rgug` readafg af eftaredq ufcgeeefted prggrae wat`2w`ade   sgeet`afg )(/*(<--(no(kurly brace */

Hey, try taking the bubble gum out of your mouth when you post :-).

>		if ( whatever ) {
>			hundreds of statements on several pages;
>			with 8 space tabs, the code dissappeared off the
>			right margin, and gradually walked back, until:
>		}
>	/* <-- no curly here either */
>Took me over an hour just to confirm that the braces matched up.

What does this have to do with swap() macro?
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy

levy@ttrdc.UUCP (Daniel R. Levy) (06/23/86)

In article <370@anasazi.UUCP>, steve@anasazi.UUCP (Steve Villee) writes:
>> Can someone construct a version that makes
>>
>>     int *a, *b;
>>     swap (*a++,*b++);
>>
>> work right?
>>           Paul Schauble at MIT-Multics.arpa
>
>#define swap(x, y) \
>  if (1) \
>  { \
>    register int *xp, *yp, t; \
>    xp = &(x); \
>    yp = &(y); \
>	...
>--- Steve Villee (ihnp4!mot!anasazi!steve)

CAUTION.  This will fail on:

	register int i, j;
	swap(i,j);
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy

throopw@dg_rtp.UUCP (Wayne Throop) (06/23/86)

> Schauble@MIT-MULTICS.ARPA
> Can someone construct a version that makes
>     int *a, *b;
>     swap (*a++,*b++);
> work right?

Yes.  It's rather simple actually.  Based on an idea I posted a couple
of weeks ago.  (I am assuming by "work right", you mean that it acts
like you wrote {tmp = *a; *a = *b; *b = tmp; a++; b++;} )

        #define swap(a,b) \
        {   int *pa = &(a), *pb = &(b), tmp;\
            tmp = *pa; *pa = *pb; *pb = tmp;\
        }

Naturally, this version is less efficent than the more usual swap
macros, it can't be applied to register variables, and it might cause
problems if used something like "if(foo) swap(a,b); else bar();", which
looks like it ought to work but actually willn't.  Despite these
problems, it does fit the description of what was wanted.


This leads to an interesting portability/maintainability/debugability
check that lint might be enhanced to do.  (Yes, I said the dirty word
"portability".  Root Boy can now tune out...).

Consider a function declared like so:

    /*MACROLIKE*/ int f();

If lint would generate warnings when arguments with side-effects are
passed to "f", it would then be possible to find all such places and
"fix" them so that the function f could be replaced by a macro.  For
another use, during debug f could be a function (so that it could be
"traced" in dbx, for example), and yet when it passed this lint check it
could safely be replaced by a macro in a "production" version, and have
a good chance of not breaking.

--
"... and my name is 'Sylvester', not 'George'!"
"But I can't say 'Sylvester', George."
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw

zben@umd5.UUCP (Ben Cranston) (06/24/86)

Paul Schauble <Schauble@mit-multics.arpa> asks:
> Can someone construct a version that makes
>     int *a, *b;
>     swap (*a++,*b++);
>> work right?

Steve Villee <ihnp4!mot!anasazi!steve> replies:

> #define swap(x, y) \
>   if (1) \
>   { \
>     register int *xp, *yp, t; \
>     xp = &(x); \
>     yp = &(y); \
>     t = *xp; \
>     *xp = *yp; \
>     *yp = t; \
>   } \
>   else

and goes on to site some special cases in which the "if" implementation 
is a big win.  Other examples have also been given.

Since the original question was about swapping (int *)s, why do not the
given examples involve (int **)s, i.e. pointers to pointers to ints?

Nailing jelly to a tree again...

-- 
                    umd5.UUCP    <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"

markb@sdcrdcf.UUCP (Mark Biggar) (06/25/86)

In article <3007@utcsri.UUCP> greg@utcsri.UUCP (Gregory Smith) writes:
>In article <1201@brl-smoke.ARPA> Schauble@MIT-MULTICS.ARPA (Paul Schauble) writes:
>>Can someone construct a version that makes
>>
>>    int *a, *b;
>>    swap (*a++,*b++);
>>
>>work right?
>>
>#define swap( a,b ) { int *p1,*p2,t;\
>	p1= &(a); p2= &(b); t= *p1;*p1= *p2;*p2=t;}
>
>No, it isn't pretty.
>how about:
>
>#define swap(a,b) fswap(&(a),&(b))
>fswap(a,b) int *a,*b;
>{	etc.

BOTH of these die a horrible death if either argument is declared
"register".

Mark Biggar
{allegra,burdvax,cbosgd,hplabs,ihnp4,akgua,sdcsvax}!sdcrdcf!markb

mouse@mcgill-vision.UUCP (der Mouse) (06/25/86)

In article <1228@brl-smoke.ARPA>, rbj@icst-cmr (Root Boy Jim) quotes
> 	Can someone construct a version that makes
> 	    int *a, *b;
> 	    swap (*a++,*b++);
> 	work right?
and writes
> Probably not. In general, macros don't work on arguments that have side effects.

How about the following, which assumes the  arguments have addresses (no
bitfields  or  register  variables  need  apply).    I  would  advise  C
portability purists to hit n; this code is pretty gross.

#define swap(x,y) \
{ register char *t1 = (char *)&(x);	\
  register char *t2 = (char *)&(y);	\
  register int n = sizeof((x));		\
  register int i;			\
  for (i=0;i<n;i++)			\
   { *t1 ^= *t2;			\
     *t2 ^= *t1;			\
     *t1 ^= *t2;			\
    }					\
}

I *told* you it was gross.   But it should work, if not  on all machines
out there,  on a  large subclass  (let's see, byte-addressable machines,
any other restrictions folks?).
-- 
					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     philabs!micomvax!musocs!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
        mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse
ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa

"Come with me a few minutes, mortal, and we shall talk."

gof@nosc.ARPA (06/26/86)

A pair of easy swap(x,y) routines that uses *No* temporary
storage can be seen below:

#define swap(x,y)   (y^=(x^=(y^=x)))

int swap_all(x,y,size)

    char  *x,*y;
    int   size;

{   int   count;
    for (count = 0 ; count < size ;count++)
       swap(x[count],y[count]);
    return(count);
}


It works quickly and, if used with the function, can swap any
size or type data area.  For simple int or long types the macro
will work fine as long as you avoid the usual problems such as
swap(a++,y++)   or anything similar.  A normal call to the
function to swap two arrays might be:

     float  first[100], second[100];
             .
	     .
	     .
     swap_all(first,second,sizeof(first));
             .
	     .
	     

It is a good idea that the sizeof() argument be the smaller of
the two areas to avoid swapping to much data.
---------------------------------------------------------------------
Jerry Fountain  (crash!gof@noscvax.ARPA)

wcs@ho95e.UUCP (#Bill_Stewart) (06/29/86)

In article <1201@brl-smoke.ARPA> Schauble@MIT-MULTICS.ARPA writes:
>Can someone construct a version that makes
>    int *a, *b;
>    swap (*a++,*b++);
>work right?

I'm not sure I can define what "work right" means in a swap :-)
-- 
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

rgenter@BBN-LABS-B.ARPA (Rick Genter) (06/29/86)

One small problem: you forgot to increment t1 and t2 inside the for loop.
--------
Rick Genter 				BBN Laboratories Inc.
(617) 497-3848				10 Moulton St.  6/512
rgenter@labs-b.bbn.COM  (Internet new)	Cambridge, MA   02238
rgenter@bbn-labs-b.ARPA (Internet old)	linus!rgenter%BBN-LABS-B.ARPA (UUCP)

gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/30/86)

In article <733@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) writes:
>I'm not sure I can define what "work right" means in a swap :-)

It may be amusing and/or instructive to contemplate the fact that
there is no way to write a function that exchanges the contents of
two variables in a language where parameters are passed "by name".

chris@umcp-cs.UUCP (Chris Torek) (07/01/86)

In article <1836@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn
(VLD/VMB) <gwyn>) writes:
>It may be amusing and/or instructive to contemplate the fact that
>there is no way to write a function that exchanges the contents of
>two variables in a language where parameters are passed "by name".

How so?  It seems rather simple.  I have here a C program that effects
call-by-name and does indeed perform a swap:

/*
 * Call by name example of swap.
 *
 * Call by name is done by passing `thunks', where a `thunk' is a
 * function that returns the address of an argument.  In this case
 * calling the function provided via `f1' returns the address of
 * the first argument; indirecting through this address produces
 * the argument itself, as an lvalue (i.e., `named').  Similarly,
 * indirection through f2's return value names the second argument.
 */
swap(f1, f2)
	int *(*f1)(), *(*f2)();
	/* `pointer to function returning pointer to int' */
{
	int t;
	
	t = *(*f1)();
	*(*f1)() = *(*f2)();
	*(*f2)() = t;
}

/*
 * Here are the variables we will address for swap().
 */
int	a, b;

/*
 * Here are the two `thunk' functions.
 */
int *
addr_a()
{

	return (&a);
}

int *
addr_b()
{

	return (&b);
}

/*
 * Finally, demonstrate that swap() does indeed work:
 */
/*ARGSUSED*/
main(argc, argv)
	int argc;
	char **argv;
{

	a = 3;
	b = 7;
	swap(addr_a, addr_b);
	printf("should be 7, 3: a = %d, b = %d\n", a, b);
	exit(0);
}

/*
 * Incidentally, `swap' can be passed a thunk that names an expression;
 * here is what a call-by-name compiler might generate for `a+b':
 *
 * int *
 * addr_aplusb()
 * {
 *	int t = a + b;
 *
 *	return (&t);
 * }
 */
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

chris@umcp-cs.UUCP (Chris Torek) (07/02/86)

In article <1836@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB)
<gwyn>) wrote:
>>It may be amusing and/or instructive to contemplate the fact that
>>there is no way to write a function that exchanges the contents of
>>two variables in a language where parameters are passed "by name".

In article <2225@umcp-cs.UUCP> I replied:
>I have here a C program that effects call-by-name and does
>indeed perform a swap:

What I failed to consider, of course, is the classic problem with
call by name: arrays.  Watch what happens when I `swap' `i' and
`a[i]', using an expanded form of the swap function (this is
necessary to avoid compiler dependencies in this particular case).

Ah well, at least I caught my error myself. . . .

swap(f1, f2)
	int *(*f1)(), *(*f2)();
{
	int t1, t2;

	t1 = *(*f1)();
	t2 = *(*f2)();
	*(*f1)() = t2;
	*(*f2)() = t1;
}

int	a[10], i;

int *
addr_asubi()
{

	return (&a[i]);
}

int *
addr_i()
{

	return (&i);
}

/*ARGSUSED*/
main(argc, argv)
	int argc;
	char **argv;
{

	a[3] = 6;
	a[6] = 1;
	i = 3;
	swap(addr_i, addr_asubi);

	/*
	 * Want i to become 6 and a[3] to become 3, with a[6] left
	 * undisturbed.  That is not what happens.  Figure out what
	 * it will in fact do, before you run it.
	 */
	printf("`should' be 6, 3, 1: i = %d, a[3], a[6] = %d\n",
		i, a[3], a[6]);
	exit(0);
}
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

tainter@ihlpg.UUCP (Tainter) (07/03/86)

> In article <1836@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn
> (VLD/VMB) <gwyn>) writes:
> >It may be amusing and/or instructive to contemplate the fact that
> >there is no way to write a function that exchanges the contents of
> >two variables in a language where parameters are passed "by name".
> 
> How so?  It seems rather simple.  I have here a C program that effects
> call-by-name and does indeed perform a swap:
> 
[Original program deleted for brevity]
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
> UUCP:	seismo!umcp-cs!chris
> CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu
Now lets show that it doesn't work:

swap(f1, f2)
	int *(*f1)(), *(*f2)();
{
	int t;
	
	t = *(*f1)();
	*(*f1)() = *(*f2)();
	*(*f2)() = t;
}
 
int	c[4], d;
 
int *
addr_c_sub_d()
{
       return(&c[d]);
}

int *
addr_d()
{
 	return (&d);
}

/*ARGSUSED*/
main(argc, argv)
	int argc;
	char **argv;
{
	d = 2;
	c[0] = 3;
	c[1] = 3;
	c[2] = 1;
	c[3] = 3;
	swap(addr_d,addr_c_sub_d);
	printf("should be 1, 2: d = %d, c[2] = %d\n", d, c[2]);
	exit(0);
}

--j.a.tainter

rbj@icst-cmr (Root Boy Jim) (07/03/86)

	In article <2225@umcp-cs.UUCP> I replied:
	>I have here a C program that effects call-by-name and does
	>indeed perform a swap:
	
	What I failed to consider, of course, is the classic problem with
	call by name: arrays.  Watch what happens when I `swap' `i' and
	`a[i]', using an expanded form of the swap function (this is
	necessary to avoid compiler dependencies in this particular case).

Okay, so at least Chris and I are talking about the same thing.
	
	Ah well, at least I caught my error myself. . . .

Ah, but why not fix it too? Who says you have to evaluate f1 & f2 each
time you reference them? 
	
	swap(f1, f2)			swap(f1, f2)
	int *(*f1)(), *(*f2)();		int *(*f1)(), *(*f2)();
	{				{
		int t1, t2;		int t1, t2, *a1, *a2;
	
		t1 = *(*f1)();		t1 = *(a1 = (*f1)());
		t2 = *(*f2)();		t2 = *(a2 = (*f2)());
		*(*f1)() = t2;		*a1 = t2;
		*(*f2)() = t1;		*a2 = t1;
	}				}

By definition you say? Whaddya want, swapping or call by name? To the
outside world, swap is atomic, so who cares what happens inside?
This way, t2 is unneeded as well.

	-- 
	In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
	UUCP:	seismo!umcp-cs!chris
	CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

Now recite with me the Hacker's Prayer:

	Our father, UART in heaven, Hallowed Call by Name ...

	(Root Boy) Jim Cottrell		<rbj@icst-cmr.arpa>
OMNIVERSAL AWARENESS?? Oh, YEH!! First you need 4 GALLONS of JELL-O
and a BIG WRENCH!!... I think you drop th'WRENCH in the JELL-O as if
it was a FLAVOR, or an INGREDIENT...  ...or...I...um...WHERE'S the
WASHING MACHINES?

gwyn@BRL.ARPA (VLD/VMB) (07/03/86)

No, you just implemented an elaborate form of "call by reference".
"Call by name" is quite something else, and if you think about it
you'll realize that swapping "by name" would mean that the names
have to be reassociated with different objects, which is contrary
to the meaning of names in this context.  I haven't seen call-by-
name included in any language since Algol.

aka@cbrma.UUCP (07/07/86)

In article <2225@umcp-cs.UUCP> chris@maryland.UUCP (Chris Torek) writes:
>In article <1836@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn
>(VLD/VMB) <gwyn>) writes:
>>It may be amusing and/or instructive to contemplate the fact that
>>there is no way to write a function that exchanges the contents of
>>two variables in a language where parameters are passed "by name".
>
>How so?  It seems rather simple.  I have here a C program that effects
>call-by-name and does indeed perform a swap:

[ ... fragmen
x	39    T cd018211043435 cbuxd05279     cbuxd    local   
40    T cd018211590636 cbuxd06482     cbuxd    local   
41    T cd018213050437 cbuxa07806     cbuxa    local   
42    T cd018213051338 cbuxb07820     cbuxb    local   
43    T cd018213052139 cbuxd07838     cbuxd    local   
44    T cd018213052740 cblpe07854     cblpe    local   
45    T cd01

friesen@psivax.UUCP (Stanley Friesen) (07/08/86)

In article <1946@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes:
>  I haven't seen call-by-name included in any language since Algol.

	What about LISP? Or is LISP older than Algol?
-- 

				Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ??

ambar@mit-eddie.MIT.EDU (Jean Marie Diaz) (07/09/86)

In article <1321@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
>In article <1946@brl-smoke.ARPA> gwyn@BRL.ARPA (VLD/VMB) writes:
>>
>>  I haven't seen call-by-name included in any language since Algol.
>
>	What about LISP? Or is LISP older than Algol?

LISP and Pascal are both descendants of Algol 60.
-- 

					AMBAR
		"I need something to change your mind...."

daveh@cbmvax.cbm.UUCP (Dave Haynie) (07/10/86)

> 
>>
>>	What about LISP? Or is LISP older than Algol?
> 
> LISP and Pascal are both descendants of Algol 60.
> -- 
> 
> 					AMBAR

LISP a descendent of Algol 60?!!?!  The earliest ancestor of LISP I've
heard of is IPL, which was developed by Newell, Shaw, and Simon at
Carnegie-Mellon in the fifties.  IPL stands for Information Processing
Language.  LISP itself was invented by John McCarthy (at MIT, I believe)
and was first formally described in papers presented in 1960 and 1961.  The 
first progamming guide on LISP was "LISP 1.5 Programmer's Manual" published
in 1961.  The first AI Language I've heard of being based on Algol at
all is SAIL, which was presented in a paper sometime around 1972.

-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Dave Haynie    {caip,ihnp4,allegra,seismo}!cbmvax!daveh

	"I don't feel safe in this world no more, 
	 I don't want to die in a nuclear war,
	 I want to sail away to a distant shore
	 And live like an ape man."
				-The Kinks

	These opinions are my own, though for a small fee they be yours too.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

franka@mntgfx.UUCP (07/15/86)

In article <2498@mit-eddie.MIT.EDU> ambar@mit-eddie.UUCP (Jean Marie Diaz) writes:
>LISP and Pascal are both descendants of Algol 60.
>-- 

	Unfortunately, this is not true.  PASCAL IS a descendant of ALGOL 60.
The evolution of LISP has nothing to do with that of ALGOL, FORTRAN, or any
other language of that era.  People who are interested might check out
Wexelblat's "History of Programming Languages" where John McCarthy includes
a paper on the history of LISP (if anybody knows this, he should).  I'm not
sure of the publisher (I have my copy at home), but it's whoever publishes the
ACM Monograph series.
				Frank Adrian
				Mentor Graphics, Inc.

jsdy@hadron.UUCP (Joseph S. D. Yao) (08/02/86)

I'm surprised nobody seems to know this.

LISP 2.0 [1] is a child of mating LISP 1.5 with ALGOL 60.

I was sure there were some MIT/SDC folk reading this.	;-)

[1] Sammet, Jean, _Programming_Languages:_History_and_Fundamentals_.
    Prentice-Hall, Inc., New Jersey, 1969.
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
			jsdy@hadron.COM (not yet domainised)