Botched mail message

[perdue%hplabs.csnet@csnet-relay.arpa]

Mike, here is a copy of one of the messages I got back after
attempting to send mail to Tim Tillson at FSD.  Note that the address
shown is "hpfclp!twt@csnet-relay.arpa", but what I actually typed in as
the address was "hpfclp!twt".  Thanks for looking into this.

As I mentioned, I have received something around 15 replies of this
general nature.

UUCP X.1
>From uhplabs Mon Jun 17 07:40:58 1985 remote from hpatlS
>From COMSAT@MIT-MC  Mon Jun 17 04:11:57 1985 remote from hplabs
Received: by HP-VENUS id AA02358; Mon, 17 Jun 85 04:11:57 pdt
Date: Mon, 17 Jun 85 03:34:37 EDT
From: Communications Satellite <hplabs!COMSAT@MIT-MC>
Received: by HP-VENUS via CSNET; 17 Jun 1985 04:11:54-PDT (Mon)
Received: from su-ai.arpa by csnet-relay.arpa id a022463; 17 Jun 85 3:35 EDT
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Jun 85  00:33:36 PDT
To: "@SU-AI.ARPA:hplabs!perdue%hplabs.csnet@csnet-relay.arpa"@SU-AI
Via:  CSNet; 17 Jun 85 4:11-PDT
Subject: Msg of Monday, 17 June 1985 03:34-EDT
Message-Id: <[MIT-MC].545653.850617>

============ A copy of your message is being returned, because: ============
"PGS@MIT-MC.ARPA" at MIT-MC is an unknown recipient.
============ Failed message follows: ============
Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 03:32:52 EST
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Jun 85  00:22:18 PDT
Received: from hplabs by csnet-relay.csnet id ac22393; 17 Jun 85 3:19 EDT
Received: by HP-VENUS id AA18871; Sun, 16 Jun 85 16:27:57 pdt
Message-Id: <8506162327.AA18871@HP-VENUS>
Date: Sun, 16 Jun 1985 20:25:00 -0000
To: hpfclp!twt@csnet-relay.arpa
Subject: Interesting Common LISP mail
From: perdue%hplabs.csnet@csnet-relay.arpa
Source-Info:  From (or Sender) name not authenticated.

Here is an especially interesting piece of mail that was sent out to
the Common LISP distribution list.  Note the suggestion of a more or
less official group of implementors of Common LISP for conventional
architectures.

     -Cris

UUCP X.1
>From uhplabs Wed Jun 12 03:39:56 1985 remote from hpatlS
>From Moon@stony-brook.scrc.symbolics.com  Wed Jun 12 00:21:21 1985 remote from hplabs
Received: by HP-VENUS id AA05084; Wed, 12 Jun 85 00:21:21 pdt
Mail-From: HP-VENUS received 12-Jun-85 00:22:24
Received: by HP-VENUS id AA05040; Wed, 12 Jun 85 00:20:56 pdt
Date: Tue, 11 Jun 85 23:51 EDT
From: "David A. Moon" <hplabs!Moon@stony-brook.scrc.symbolics.com>
Received: by HP-VENUS via CSNET; 12 Jun 1985 00:20:53-PDT (Wed)
Received: from su-ai.arpa by csnet-relay.arpa id a024133; 12 Jun 85 0:00 EDT
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85  20:52:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252533; Tue 11-Jun-85 23:49:29-EDT
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C>
Via:  CSNet; 12 Jun 85 0:20-PDT
Subject: Adjustable and displaced arrays
Cc: common-lisp@SU-AI
In-Reply-To: <FAHLMAN.12118411695.BABYL@CMU-CS-C.ARPA>
Message-Id: <850611235159.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 11 Jun 1985  21:43 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>


    OK, if we accept Moon's view of the proper semantics for all this, and
    if we decide not to outlaw displacing to adjustable arrays, then the
    Fortran machines probably have to forego cacheing and let each call to
    Aref potentially grovel the headers of both arrays (or a whole chain of
    arrays).  Maybe that is not so bad, since none of this affects
    Simple-Vectors, and they are the only kind of array that really HAS to
    be fast.

    However, the vendors of non-microcodable machines may feel, with some
    justification, that they don't want to slow down ALL references to
    non-simple arrays just so that the obscure case of adjusting an array
    that is displaced to will work properly.  Perhaps the right move is to
    unbundle the SIMPLE declaration and allow the user to declare that an
    array is NOT-DISPLACED, even if it is not simple in other respects.

Sure.  I would think that an appropriate way to proceed would be for the
implementors on non-Lisp machines to get together and agree on a common
set of language extensions to deal with this sort of issue.  At a later
time, those extensions can be moved into the standard language, once
they are well-debugged and agreed to be the right thing for all machines
that need them.  Until that happens, programs that use the extensions won't
be portable to all implementations (but they will probably be portable to
almost all implementations if the extensions are designed right, e.g. as
ignorable declarations).


-------



-------