From info-dylan-request Thu Nov 19 12:41:54 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22764; Thu, 19 Nov 92 12:41:55 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22760; Thu, 19 Nov 92 12:41:54 -0500
Received: from halcyon.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02722; Thu, 19 Nov 92 12:49:02 -0500
	for info-dylan@cambridge.apple.com
Received: by halcyon.com id AA01428
  (5.65c/IDA-1.4.4 for info-dylan@cambridge.apple.com); Thu, 19 Nov 1992 09:41:31 -0800
Date: Thu, 19 Nov 1992 09:41:31 -0800
From: Ray Jackson <raj@halcyon.halcyon.com>
Message-Id: <199211191741.AA01428@halcyon.com>
To: farrow@stephanie.hc.ti.com, info-dylan@cambridge.apple.com
Subject: Re: Capacity Alert.



From info-dylan-request Thu Nov 19 13:45:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25961; Thu, 19 Nov 92 13:45:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25955; Thu, 19 Nov 92 13:45:22 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02972; Thu, 19 Nov 92 13:52:39 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA28217; Thu, 19 Nov 92 13:44:42 -0500
Received: by easynet.crl.dec.com; id AA22753; Thu, 19 Nov 92 13:44:39 -0500
Message-Id: <9211191844.AA06242@taunton.crl.dec.com>
To: samp@kurz-ai.com (Sam Pilato)
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com
Subject: Re: #f = #none ? 
In-Reply-To: Your message of "Thu, 19 Nov 92 10:18:44 EST."             <9211191518.AA16847@taiyo.kurz-ai.com> 
Date: Thu, 19 Nov 92 13:44:37 -0500
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Thu, 19 Nov 92 10:18:44 EST
    From: samp@kurz-ai.com (Sam Pilato)
    
       (multiple-value-call #'foo
         (if frob-p
    	 (values :frob frob-val)
    	 (values))
         :blech bletch-val)
    
    
    I agree with Fry.  I would much prefer being able to:
    
    (foo :frob  (if frob-p frob-val <use-the-default-value>)
         :blech bletch-val)

I wasn't disagreeing with Fry.  But I would not like there
to be some distinguished value which could not be passed
in, because it would be interpreted as "use the default value".
What if you remodularize your code, so that the appropriate
place to do the defaulting is not in that function, but instead
in a function three levels of call down?

The multiple-value-call construct has the correct semantics.
The syntax is awkward.  However, you can package it up in
macros:

(defaulting foo :frob (if frob-p frob-val :use-default)
                :blech bletch-val).


From info-dylan-request Thu Nov 19 14:39:28 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28702; Thu, 19 Nov 92 14:39:30 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28698; Thu, 19 Nov 92 14:39:28 -0500
Received: from alpha.Xerox.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03172; Thu, 19 Nov 92 14:46:46 -0500
	for info-dylan@cambridge.apple.com
Received: from fliff.wrc.xerox.com ([13.0.33.96]) by alpha.xerox.com with SMTP id <11751>; Thu, 19 Nov 1992 11:41:13 PST
Received: by fliff.wrc.xerox.com (4.1/SMI-4.1-wrc)
	id AA01137; Thu, 19 Nov 92 14:41:11 EST
Message-Id: <9211191941.AA01137@fliff.wrc.xerox.com>
To: Bob Kerns <rwk@crl.dec.com>
Cc: samp@kurz-ai.com (Sam Pilato), cfry@mit.edu,
        info-dylan@cambridge.apple.com
Subject: Re: #f = #none ? 
In-Reply-To: Your message of "Thu, 19 Nov 92 10:44:37 PST."
             <9211191844.AA06242@taunton.crl.dec.com> 
Date: 	Thu, 19 Nov 1992 11:41:07 PST
From: Jim Mayer <mayer@wrc.xerox.com>

> From: Bob Kerns <rwk@crl.dec.com>
> 
>     Date: Thu, 19 Nov 92 10:18:44 EST
>     From: samp@kurz-ai.com (Sam Pilato)
>     
>        (multiple-value-call #'foo
>          (if frob-p
>     	 (values :frob frob-val)
>     	 (values))
>          :blech bletch-val)
>     
>     
>     I agree with Fry.  I would much prefer being able to:
>     
>     (foo :frob  (if frob-p frob-val <use-the-default-value>)
>          :blech bletch-val)
> 

In my experience with common lisp, I have often wished for a value
that could be conventionally used to indicate "the default".  Often
NIL ends up being used that way (but suffers from the usual punning
problems).  For example, I have run into the following sort of
construct a number of times:

    (define-method my-method (#rest args #key thing)
      (apply fubar-1 thing: <use-the-default> another-thing: ... args))

Without some way to specify "use the default value for THING" one
either has to know what value to assign to THING, or operate on the
rest list.

Another, perhaps more important, advantage of allowing #none is that
is simplifies the semantics of default value assignment.  We could
define the defaulting semantics for keyword arguments as follows:

    (define-method my-method (#key ((a1 t1) v1) ((a2 t2) v2) ...)
	... stuff ...)

becomes

    (define-method my-method (#key pa1 pa2 ...)
       (bind (((a1 t1) (if (eq pa1 #none) v1 pa1))
              ((a2 t2) (if (eq pa2 #none) v2 pa2))
	      ...)
         ... stuff ...))

> I wasn't disagreeing with Fry.  But I would not like there
> to be some distinguished value which could not be passed
> in, because it would be interpreted as "use the default value".
> What if you remodularize your code, so that the appropriate
> place to do the defaulting is not in that function, but instead
> in a function three levels of call down?

Why is that a problem?  Under the semantics I gave above, #none is a
perfectly good value.  If no default is given, it is passed right
through and the "right" thing would happen at the fuction that was
prepared to do the defaulting.

> 
> The multiple-value-call construct has the correct semantics.
> The syntax is awkward.  However, you can package it up in
> macros:
> 
> (defaulting foo :frob (if frob-p frob-val :use-default)
>                 :blech bletch-val).
> 

-- Jim Mayer
                                        Phone: (716) 422-9407
Webster Research Center                 Intelnet phone: 8*222-9407
Xerox Corporation                       Internet Email: mayer@wrc.xerox.com
800 Phillips Road, 0128-29E             XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580                 Facsimile: (716) 265-7133









From info-dylan-request Thu Nov 19 14:55:56 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29586; Thu, 19 Nov 92 14:55:58 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29580; Thu, 19 Nov 92 14:55:56 -0500
Received: from talcott.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03273; Thu, 19 Nov 92 15:03:12 -0500
	for info-dylan@cambridge.apple.com
Received: by kurz-ai.com (MC 2.0/SMI-4.0)
	id AA14058; Thu, 19 Nov 92 14:46:22 EST
Received: by taiyo.kurz-ai.com (4.1/SMI-4.0)
	id AA17195; Thu, 19 Nov 92 14:45:11 EST
Date: Thu, 19 Nov 92 14:45:11 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9211191945.AA17195@taiyo.kurz-ai.com>
To: rwk@crl.dec.com
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com
In-Reply-To: Bob Kerns's message of Thu, 19 Nov 92 13:44:37 -0500
Subject: #f = #none ? 

   Date: Thu, 19 Nov 92 13:44:37 -0500
   From: Bob Kerns <rwk@crl.dec.com>
   X-Mts: smtp

   (multiple-value-call #'foo
     (if frob-p
     (values :frob frob-val)
     (values))
     :blech bletch-val)


I agree with Fry.  I would much prefer being able to:

(foo :frob  (if frob-p frob-val <use-the-default-value>)
     :blech bletch-val)

   I wasn't disagreeing with Fry.  But I would not like there
   to be some distinguished value which could not be passed
   in, because it would be interpreted as "use the default value".
   What if you remodularize your code, so that the appropriate
   place to do the defaulting is not in that function, but instead
   in a function three levels of call down?

   The multiple-value-call construct has the correct semantics.
   The syntax is awkward.  However, you can package it up in
   macros:

   (defaulting foo :frob (if frob-p frob-val :use-default)
		   :blech bletch-val).

I'd still rather use a built-in #none =/= #f, than use a defaulting
macro.  That #none can be passed down those three levels where, in the
defaulting function, Dylan resolves it to the specified default.

Notice that if one hard-codes arguments like ":frob #none", say to
make it clear to the programmer that they have chosen not to override
a default, then Dylan may leave that part out of the call if it likes.
(Of course, Dylan could instead supply #none for all such missing
arguments if it knows the number of legal keywords for a function and
prefers to work with fixed-arity functions.)

From info-dylan-request Thu Nov 19 15:30:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01541; Thu, 19 Nov 92 15:30:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01536; Thu, 19 Nov 92 15:30:30 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03363; Thu, 19 Nov 92 15:37:48 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA06547; Thu, 19 Nov 92 15:29:50 -0500
Received: by easynet.crl.dec.com; id AA25281; Thu, 19 Nov 92 15:29:48 -0500
Message-Id: <9211192029.AA06993@taunton.crl.dec.com>
To: Jim Mayer <mayer@wrc.xerox.com>
Cc: samp@kurz-ai.com    (Sam Pilato), cfry@mit.edu,
        info-dylan@cambridge.apple.com
Subject: Re: #f = #none ? 
In-Reply-To: Your message of "Thu, 19 Nov 92 11:41:07 PST."             <9211191941.AA01137@fliff.wrc.xerox.com> 
Date: Thu, 19 Nov 92 15:29:47 -0500
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Thu, 19 Nov 1992 11:41:07 PST
    From: Jim Mayer <mayer@wrc.xerox.com>
    
    Why is that a problem?  Under the semantics I gave above, #none is a
    perfectly good value.  If no default is given, it is passed right
    through and the "right" thing would happen at the fuction that was
    prepared to do the defaulting.
    
It suffers from the same punning problems as NIL.  Anytime
you try encoding this out-of-band information in-band in
the data object, you incur risk of punning.  Consider a
compiler or macro cogitating about what to do with this
#none argument.

From info-dylan-request Thu Nov 19 16:58:06 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05524; Thu, 19 Nov 92 16:58:07 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05520; Thu, 19 Nov 92 16:58:06 -0500
Received: from alpha.Xerox.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03623; Thu, 19 Nov 92 17:05:22 -0500
	for info-dylan@cambridge.apple.com
Received: from fliff.wrc.xerox.com ([13.0.33.96]) by alpha.xerox.com with SMTP id <11801>; Thu, 19 Nov 1992 13:59:46 PST
Received: by fliff.wrc.xerox.com (4.1/SMI-4.1-wrc)
	id AA01417; Thu, 19 Nov 92 16:59:43 EST
Message-Id: <9211192159.AA01417@fliff.wrc.xerox.com>
To: moon@cambridge.apple.com (David A. Moon)
Cc: meehan@src.dec.com, info-dylan@cambridge.apple.com
Subject: Re: Multiple values, revised proposal 
In-Reply-To: Your message of "Fri, 06 Nov 92 14:13:40 PST."
             <9211062211.AA05028@cambridge.apple.com> 
Date: 	Thu, 19 Nov 1992 13:59:38 PST
From: Jim Mayer <mayer@wrc.xerox.com>

Consider for a moment a language Dylan++ :-) that had the following
features:

(1) #f is the only false falue

(2) #t is the only true value

(3) #none is returned by when, unless, and cond on the failure path.

(4) unspecified keyword parameters with no default value are
    assigned #none.

(5) If #none is passed as the value of a keyword parameter, and that
    parameter specifies a default value, then the default value is used.

(5) A new form, "apply-values" that looks like

	(apply-values function v1 v2 ... vk <form returning multiple values>)

    In common lisp, apply-values could be defined as:

	(apply function v1 v2 ... vk
	       (multiple-value-list <form returning multiple values>))

(6) A new form, "ensure-values" that looks like

	(ensure-values min max <form>)

    The "max" value can be given as #none to indicate no limit.
    In common lisp, with NIL used instead of #none, ensure-values
    could be defined as:

        (let* ((args (multiple-value-list <form>))
               (nargs (length args)))
	  (cond
	    ((< nargs min)
	     (apply #'values
		    (append args (make-sequence 'list (- min nargs)))))
	    ((and max (< max nargs))
	     (apply #'values (subseq args 0 max)))
	    (t
	     (apply #'values args))))
   

Now, we can rewrite bind in terms of method application:

    (bind ((<parameter specification> <form>)) <stuff>)

becomes

    (apply-values (method (<parameter specification>) <stuff>)
      (ensure-values <number of required parameters>
		     <number of required parameters or #none
		      if #rest or #key is given>
		     <form>))

This definition has the standard Dylan semantics as far as missing and
extra return values are concerned.  It also has the following nice
properties:

(1) Keword arguments can be used for both argument and return values.

(2) The "bind" form can now be treated as a macro.  Its semantics are
completely specified in terms of "method", "apply-values", and
"ensure-values".

(3) The defaulting and ignoring of return values is pushed into the
"syntactic sugar" of the language and is kept out of the core.

My personal preference would be eliminate the defaulting and ignoring
of return values.  The construct that David Moon mentioned in his
article could then be written using keyword result values:

  (bind ((frobby #key path-to-frobby (find-frobby name)))
    (if frobby
      ;; There is one
      (do-something-with name frobby path-to-frobby)
      ;; No frobby with that name exists
      (do-something-else name)))

  ;; Returns a value and an optional keyword result value
  ;;  The frobby with that name, or #f if there isn't one
  ;;  The path by which that frobby was found
  (define find-frobby (method (name)
    (bind ((x ..la de dah..))
      (when (umpty ump...)
        (when (something something something...)
          (bind ((frobby (do dah ...)))
            (unless (no-good? frobby)
              (values frobby path-to-frobby: (foo fah)))))))))

I find this quite clear and easy to write.

It could be argued that efficiency concerns prohibit using keyword
result values this way.  I'm not sure that I agree with that, but if
it was a concern I wonder if it doesn't apply to function call as
well.  For example, if Dylan really wants to support optional return
values, perhaps optional arguments should be put back in the language.
In that case, the example could be written as:

  (bind ((frobby #optional path-to-frobby (find-frobby name)))
    (if frobby
      ;; There is one
      (do-something-with name frobby path-to-frobby)
      ;; No frobby with that name exists
      (do-something-else name)))

which seems very clean to me.

-- Jim Mayer
                                        Phone: (716) 422-9407
Webster Research Center                 Intelnet phone: 8*222-9407
Xerox Corporation                       Internet Email: mayer@wrc.xerox.com
800 Phillips Road, 0128-29E             XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580                 Facsimile: (716) 265-7133

       



    





From info-dylan-request Thu Nov 19 21:27:29 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10839; Thu, 19 Nov 92 21:27:30 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10835; Thu, 19 Nov 92 21:27:29 -0500
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04083; Thu, 19 Nov 92 21:34:49 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08589; Thu, 19 Nov 92 21:26:23 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 212537.27450; Thu, 19 Nov 1992 21:25:37 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA04888; Thu, 19 Nov 92 14:43:47 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA07804; Thu, 19 Nov 92 14:43:45 PST
Date: Thu, 19 Nov 92 14:43:45 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211192243.AA07804@eagle.sharebase.com>
To: mayer@wrc.xerox.com, rwk@crl.dec.com
Subject: Re: #f = #none ?
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com, samp@kurz-ai.com

From: Bob Kerns <rwk@crl.dec.com>
/// 
///     Date: Thu, 19 Nov 1992 11:41:07 PST
///     From: Jim Mayer <mayer@wrc.xerox.com>
/// 
///     Why is that a problem?  Under the semantics I gave above, #none is a
///     perfectly good value.  If no default is given, it is passed right
///     through and the "right" thing would happen at the fuction that was
///     prepared to do the defaulting.

Aha!  This really seems like the core issue to resolve with #none -- whether
or not it should be considered part of <object>.  If it is not, then this
passing down won't work as expected.  Then again, proper initial design of
the inter-layer protocols would avoid this problem.

/// It suffers from the same punning problems as NIL.  Anytime
/// you try encoding this out-of-band information in-band in
/// the data object, you incur risk of punning.  Consider a
/// compiler or macro cogitating about what to do with this
/// #none argument.

I think the Dylan spec says that dynamic typing is possible (I sure hope it
does!), and it is as complex a matter for #none as for any other dynamically
typed situation as far as the compiler is concerned.  It _must_ emit code with
a conditional on the dope-vector/type-tag of what it is passed.  Optimizations
_do_ abound, and _should_ be made by a suitable Dylan compiler, so #none should
pose no new difficulties in that regard.  By the time the compiler has figured
out where it can emit statically typed code, it is not at all difficult to
handle #none correctly.

Aside:  IF WE ARE SERIOUSLY CONSIDERING #NONE, WE NEED TO TALK ABOUT WHAT
    CLASS IT WILL BE.  I SUGGEST MAKING IT _NOT_ INHERIT OBJECT BEHAVIOR SO
    THAT METHODS THAT DO NOT SPECIALIZE ON ARGUMENTS CAN BE GUARANTEED OF NOT
    RECEIVING #NONE FOR A REQUIRED ARGUMENT BY THE METHOD-DISPATCH PROCEDURE.

Sorry about the CAPs, but I haven't really heard from anyone on this topic,
and I don't see how this discussion can continue without it.  What class should
#none be?  Should it even _have_ a class?  (I think it should)

	-- Scot

From info-dylan-request Fri Nov 20 16:40:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13070; Fri, 20 Nov 92 16:40:55 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13066; Fri, 20 Nov 92 16:40:53 -0500
Received: from vnet.ibm.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05775; Fri, 20 Nov 92 16:48:17 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9211202148.AA05775@brazil.cambridge.apple.com>
Received: from CLTVM3 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7156;
   Fri, 20 Nov 92 16:40:06 EST
Date: Fri, 20 Nov 92 16:09:44 EST
From: "Sujal H. Badami" <BADAMI@CLTVM3.VNET.IBM.COM>
To: BADAMI%CHARLOTT@CLTVM3.VNET.IBM.COM, info-dylan@cambridge.apple.com
Subject: subscription request

Please add the following name in the mailing list:
 badami@cltvm3.vnet.ibm.com

Thanks.

-Sujal

From info-dylan-request Fri Nov 20 19:55:52 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17050; Fri, 20 Nov 92 19:55:53 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17046; Fri, 20 Nov 92 19:55:52 -0500
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06305; Fri, 20 Nov 92 20:03:19 -0500
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA21182; Fri, 20 Nov 92 19:55:19 EST
Message-Id: <9211210055.AA21182@MIT.EDU>
Date: Fri, 20 Nov 92 19:52:33 EST
From: cfry@MIT.EDU (Christopher Fry)
To: samp@kurz-ai.com (Sam Pilato)
Subject: Re: #f = #none ? 
Cc: rwk@crl.dec.com, cfry@MIT.EDU, info-dylan@cambridge.apple.com

> Date: Thu, 19 Nov 92 14:45:11 EST
> From: samp@kurz-ai.com (Sam Pilato)
> To: rwk@crl.dec.com
> Cc: cfry@MIT.EDU, info-dylan@cambridge.apple.com
> In-Reply-To: Bob Kerns's message of Thu, 19 Nov 92 13:44:37 -0500
> Subject: #f = #none ? 
> 
>    Date: Thu, 19 Nov 92 13:44:37 -0500
>    From: Bob Kerns <rwk@crl.dec.com>
>    X-Mts: smtp
> 
>    (multiple-value-call #'foo
>      (if frob-p
>      (values :frob frob-val)
>      (values))
>      :blech bletch-val)
> 
> 
> I agree with Fry.  I would much prefer being able to:
> 
> (foo :frob  (if frob-p frob-val <use-the-default-value>)
>      :blech bletch-val)

Some very intersting discussions after this caused me to think of yet
another way out of the problem here. I'm not claiming the
below is great, just some more food for thought.

If our problem is getting to explcitly use a default value,
how about a function that, given the name of a function and the name of
one of its arguments, returns the value of the default for that
function. SO:

(defun foo (a &optional (b (+ 2 3)) ...)

(foo 1 (get-default-value 'foo 'b))


One problem is that if we've got
(defun foo (a &optional (b (+ a 3)) ...)
 then it doesn't work so well without special hacks.
I guess dylan doesn't have this particular problem but ...

We can all imagine how we could hack the interpreter to
avoid us having to specify ANY args to get-default-value.
But the above soluation is just an add-on, provided its easy
to write it in the environoment.
For the sake of other programming tools, I'd hope it
would be easy to write.

From info-dylan-request Fri Nov 20 20:30:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17898; Fri, 20 Nov 92 20:30:15 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17894; Fri, 20 Nov 92 20:30:14 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06388; Fri, 20 Nov 92 20:37:42 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA11801; Fri, 20 Nov 92 20:29:43 -0500
Received: by easynet.crl.dec.com; id AA22055; Fri, 20 Nov 92 20:29:41 -0500
Message-Id: <9211210129.AA18179@taunton.crl.dec.com>
To: cfry@MIT.EDU (Christopher Fry)
Cc: samp@kurz-ai.com (Sam Pilato), info-dylan@cambridge.apple.com
Subject: Re: #f = #none ? 
In-Reply-To: Your message of "Fri, 20 Nov 92 19:52:33 EST."             <9211210055.AA21182@MIT.EDU> 
Date: Fri, 20 Nov 92 20:29:40 -0500
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    If our problem is getting to explcitly use a default value,
    how about a function that, given the name of a function and the name of
    one of its arguments, returns the value of the default for that
    function. SO:

I like this, a lot.  Information should be explicit and
represented, not closed and hidden.

From info-dylan-request Sat Nov 21 09:14:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27520; Sat, 21 Nov 92 09:14:23 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27516; Sat, 21 Nov 92 09:14:22 -0500
Received: from [192.135.231.242] by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06946; Sat, 21 Nov 92 09:21:53 -0500
	for info-dylan@cambridge.apple.com
Received: from dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk with SMTP (PP) 
          id <7352-0@magician.dcs.qmw.ac.uk>; Sat, 21 Nov 1992 14:16:52 +0000
Received: by debara.dcs.qmw.ac.uk (4.1/QMW-Minimal-1.14) id AA03469;
          Sat, 21 Nov 92 14:26:29 GMT
From: eliot@dcs.qmw.ac.uk
Message-Id: <9211211426.AA03469@debara.dcs.qmw.ac.uk>
Subject: <boolean> (was Re: object-class)
To: info-dylan@cambridge.apple.com
Date: Sat, 21 Nov 92 14:26:29 GMT
In-Reply-To: <"nene.cl.ca.253:20.11.92.12.24.16"@cl.cam.ac.uk>; from "Olly Stephens" at Nov 20, 92 12:23 pm
X-Mailer: ELM [version 2.3 PL11]

><boolean> class is a good idea.  I had half implemented it once but
>decided to stick to the book. If #t and #f are the only instances
>of it, it allows specialisation on <boolean>.  Of course, the
>method
>
>  (as <boolean> <object>)
>
>would be useful and very easy to implement - if object is already
><boolean> return it, otherwise return #t.

If you add <boolean> (which I think is a good idea) you should really add
<true> & <false> as its subclasses, make <boolean> an abstract class, and
make #t the sole instance of <true> & #f the sole instance of <false>.
If you have separate classes for true & false then its possible to define the
basic control structures using polymorphism on #t & #f and lambda (method).

This is what Smalltalk and Self do and its very elegant indeed, no built-in
control structures other than message send.


Here's the Smalltalk (my DYLAN is not fluent enough yet!):

    True methods for controlling

    ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
	^trueAlternativeBlock value


    False methods for controlling

    ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
	^falseAlternativeBlock value

The above are the implementations of ifTrue:ifFalse: in classes True & False.
trueAlternativeBlock and falseAlternativeBlock are both closures. ^ is
return result from method, and value is the message that causes closures to
evaluate themselves.

I don't have the DYLAN book to hand so I won't embarrass myself trying to
translate.  DYLAN equivalents anyone?


If you don't include <true> & <false>, and stick with <boolean> then there's
an infinite regress problem in methods on <boolean>, which means you always
have to rely on if, instead of messages.

This might illustrate that one of the major differences between DYLAN and
Smalltalk/Self is that while DYLAN is "objects all the way down", Smalltalk/Self
are in addition "messages all the way down".

--
Eliot Miranda,  Lecturer	email:	eliot@dcs.qmw.ac.uk
Department of Computer Science	ARPA:	eliot%dcs.qmw.ac.uk@nsf.ac.uk
Queen Mary Westfield College	UUCP:	eliot@qmw-dcs.uucp
Mile End Road, LONDON E1 4NS	Tel:	071 975 5229 (+44 71 975 5229)
				Fax:	081 980 6533 (+44 81 980 6533)

From info-dylan-request Sat Nov 21 20:23:08 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA09930; Sat, 21 Nov 92 20:23:11 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09925; Sat, 21 Nov 92 20:23:08 -0500
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07479; Sat, 21 Nov 92 20:30:41 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA00777; Sat, 21 Nov 92 20:25:15 -0500
Received: from woodstock.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 202441.15736; Sat, 21 Nov 1992 20:24:41 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA03682; Sat, 21 Nov 92 15:35:18 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA08608; Sat, 21 Nov 92 15:35:16 PST
Date: Sat, 21 Nov 92 15:35:16 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211212335.AA08608@eagle.sharebase.com>
To: eliot@dcs.qmw.ac.uk, info-dylan@cambridge.apple.com
Subject: Re:  <boolean> (was Re: object-class)

WARNING:  THE FOLLOWING MESSAGE MAY BE LONG AND TEDIOUS IF YOU AREN'T
    INTERESTED IN OBJECT-ORIENTED LANGUAGE-DESIGN.  YOU MIGHT WANT TO JUNK
    THIS NOW.

From: eliot@dcs.qmw.ac.uk
/// ><boolean> class is a good idea.  I had half implemented it once but
/// >decided to stick to the book. If #t and #f are the only instances
/// >of it, it allows specialisation on <boolean>.  Of course, the
/// >method
/// >
/// >  (as <boolean> <object>)
/// >
/// >would be useful and very easy to implement - if object is already
/// ><boolean> return it, otherwise return #t.
/// 
/// If you add <boolean> (which I think is a good idea) you should really
/// add <true> & <false> as its subclasses, make <boolean> an abstract
/// class, and make #t the sole instance of <true> & #f the sole instance
/// of <false>.  If you have separate classes for true & false then its
/// possible to define the basic control structures using polymorphism on
/// #t & #f and lambda (method).
/// 
/// This is what Smalltalk and Self do and its very elegant indeed, no
/// built-in control structures other than message send.
/// 

I agree, but in principle, Dylan would be able to do this already, since one
method argument specializer is the 'singleton' value.  A method with a
singleton value specializer for one of its parameters will only be invoked by
the dispatcher when/if the argument passed is equal, although I'm a bit foggy
on whether it has to be id? or same?  Anyone out there know for sure?

/// 
/// Here's the Smalltalk (my DYLAN is not fluent enough yet!):
[...stuff deleted...]
/// 
/// I don't have the DYLAN book to hand so I won't embarrass myself trying
/// to translate.  DYLAN equivalents anyone?
/// 

This can't be properly translated to Dylan (I don't think) since Dylan has no
proper way of specifying lazy evaluation of arguments to functions.  In fact,
adding this to Dylan would be highly nontrivial since it would require a _lot_
of typing info (which may not be availible) in order to do the dispatch right.

If, on the other hand, it's OK if both the then and else blocks are evaluated
_both_, the following will do it (I think):

	(define-method my-if ((singleton #t) then else)
		then)
	(define-method my-if ((singleton #f) then else)
		else)

/// 
/// If you don't include <true> & <false>, and stick with <boolean> then
/// there's an infinite regress problem in methods on <boolean>, which
/// means you always have to rely on if, instead of messages.
///

I agree that this is not an optimal solution for an OOPL to take, but pattern
matching is _very_ expensive.  For example, in the current spec, I cannot
specialize on a parameter to a method such that the method will be invoked for
parameters that are general instances of some class C only when some slot of
that class has a particular value.  In other words, I can specialize on value
_or_ on class, but not on a combination of the two.  Coming from HOPE and
Prolog this seems like a real weakness, since in _both_ of those languages
message-passing can be used as the only control construct (well, with
recursion)

However, HOPE and Prolog 'records' or 'structures' are not true objects since
there is no inheritance of slots/behaviours.  This is a problem which I have
never been able to find an adequate solution to.  How can one make the
'constructor' function for a class so transparent that it can be made to work
_backwards_ to 'deconstruct' an element of the class into its respective
[visible] slots?

If such a system of 'constructor' definition is ever found that is compatible
with the object-oriented paradigm, you can be sure that that's the bus I'll
be on!

///
/// This might illustrate that one of the major differences between DYLAN
/// and Smalltalk/Self is that while DYLAN is "objects all the way down",
/// Smalltalk/Self are in addition "messages all the way down".
/// 

Can either Smalltalk or Self specialize on _both_ class and value?  Or even
just on class and class of a slot of the object being passed?

///
/// -- Eliot Miranda,  Lecturer        email:  eliot@dcs.qmw.ac.uk
/// Department of Computer Science  ARPA:   eliot%dcs.qmw.ac.uk@nsf.ac.uk
/// Queen Mary Westfield College    UUCP:   eliot@qmw-dcs.uucp Mile End
/// Road, LONDON E1 4NS    Tel:    071 975 5229 (+44 71 975 5229)
/// 				Fax:    081 980 6533 (+44 81 980 6533)

+------------------------+-----------------------------------------------+
|Scot Dyer_Rivenburgh    | "Land of song," said the warrior bard,	 |
|dyer@eagle.sharebase.com| "Though all the world betrays thee,		 |
+------------------------+  One sword, at least, thy rights shall guard, |
|(He's right, you know.) |  One faithful harp shall praise thee."	 |
+------------------------+-----------------------------------------------+

From info-dylan-request Sun Nov 22 00:31:31 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13857; Sun, 22 Nov 92 00:31:32 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13853; Sun, 22 Nov 92 00:31:31 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07676; Sun, 22 Nov 92 00:39:08 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA10666; Sun, 22 Nov 92 00:33:15 -0500
Received: by easynet.crl.dec.com; id AA02953; Sun, 22 Nov 92 00:33:14 -0500
Message-Id: <9211220533.AA29164@taunton.crl.dec.com>
To: dyer@eagle.sharebase.com (Scot Dyer)
Cc: eliot@dcs.qmw.ac.uk, info-dylan@cambridge.apple.com
Subject: Re: <boolean> (was Re: object-class) 
In-Reply-To: Your message of "Sat, 21 Nov 92 15:35:16 PST."             <9211212335.AA08608@eagle.sharebase.com> 
Date: Sun, 22 Nov 92 00:33:13 -0500
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Sat, 21 Nov 92 15:35:16 PST
    From: dyer@eagle.sharebase.com (Scot Dyer)
    /// I don't have the DYLAN book to hand so I won't embarrass myself trying
    /// to translate.  DYLAN equivalents anyone?

    
    This can't be properly translated to Dylan (I don't think) since Dylan has no
    proper way of specifying lazy evaluation of arguments to functions.  In fact,
    adding this to Dylan would be highly nontrivial since it would require a _lot_
    of typing info (which may not be availible) in order to do the dispatch right.
    
Please forgive any syntactic errors, since I'm at home
without my Dylan manual, and Scheme is not my native
language, but:

(if cond true false) =>

(define-method my-if ((singleton #t) then else)
  (then))
(define-method my-if ((singleton #f) then else)
 (else))

(my-if cond (lambda () then) (lambda () else))
    
    I agree that this is not an optimal solution for an OOPL to take, but pattern
    matching is _very_ expensive.  For example, in the current spec, I cannot
    specialize on a parameter to a method such that the method will be invoked for
    parameters that are general instances of some class C only when some slot of
    that class has a particular value.  In other words, I can specialize on value
    _or_ on class, but not on a combination of the two.

You can do this in two stages:

(define frobulate (frob)
  (frobulate-on-slot frob (frob-impellor frob)))

(define-method frobulate-on-slot ((frob hairy-frob) (impellor neoprene))
  (frobulate-thoroughly frob impellor))

This is easy enough, that I do not see it as a major issue.
It's just too hard for the language to embody the entire range
of things you might want to specialize on.  It's better to let
the programmer take over this, and not hair up the language.

From moon Mon Nov 23 11:43:17 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28000; Mon, 23 Nov 92 11:43:21 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27993; Mon, 23 Nov 92 11:43:17 -0500
Message-Id: <9211231643.AA27993@cambridge.apple.com>
Date: Mon, 23 Nov 92 11:46:47 EST
From: moon (David A. Moon)
To: Bob Kerns <rwk@crl.dec.com>, dyer@eagle.sharebase.com (Scot Dyer)
Subject: Re: <boolean> (was Re: object-class) 
Cc: eliot@dcs.qmw.ac.uk, info-dylan@cambridge.apple.com

> Date: Sun, 22 Nov 92 00:33:13 -0500
> From: Bob Kerns <rwk@crl.dec.com>
> 
>     Date: Sat, 21 Nov 92 15:35:16 PST
>     From: dyer@eagle.sharebase.com (Scot Dyer)
>     
>     This can't be properly translated to Dylan (I don't think) since Dylan has no
>     proper way of specifying lazy evaluation of arguments to functions.
>     
> Please forgive any syntactic errors, since I'm at home
> without my Dylan manual, and Scheme is not my native
> language, but:
> 
> (if cond true false) =>
> 
> (define-method my-if ((singleton #t) then else)
>   (then))
> (define-method my-if ((singleton #f) then else)
>  (else))
> 
> (my-if cond (lambda () then) (lambda () else))

This is exactly the same way that Smalltalk does it, although Mr. Dyer might
not have noticed that because Smalltalk obscures the creation of closures as
the arguments to if by using syntax (square brackets).

And you all thought I had long ago stopped reading this very digressive
discussion, with its programming examples in Common Lisp, Scheme, and
Smalltalk (but not Dylan).

From info-dylan-request Mon Nov 23 13:42:23 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04169; Mon, 23 Nov 92 13:42:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04165; Mon, 23 Nov 92 13:42:23 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10274; Mon, 23 Nov 92 13:50:11 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA07037; Mon, 23 Nov 92 13:44:31 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA17748; Mon, 23 Nov 1992 13:42:18 -0500
Date: Mon, 23 Nov 1992 13:42:18 -0500
Message-Id: <9211231842.AA17748@lakatos.osf.org>
To: eliot@dcs.qmw.ac.uk
Cc: info-dylan@cambridge.apple.com
In-Reply-To: eliot@dcs.qmw.ac.uk's message of Sat, 21 Nov 92 14:26:29 GMT <9211211426.AA03469@debara.dcs.qmw.ac.uk>
Subject: <boolean> (was Re: object-class)
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

   ...If you have separate classes for true & false then its possible
   to define the basic control structures using polymorphism on #t &
   #f and lambda (method)....

Elegant, perhaps, but what does it add to the ease of reading or
writing programs, or even to the ease of defining Dylan's semantics?

	-s

From info-dylan-request Mon Nov 23 14:33:52 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06875; Mon, 23 Nov 92 14:33:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06869; Mon, 23 Nov 92 14:33:52 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10671; Mon, 23 Nov 92 14:41:41 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA00329; Mon, 23 Nov 92 14:33:21 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA17774; Mon, 23 Nov 1992 14:31:10 -0500
Date: Mon, 23 Nov 1992 14:31:10 -0500
Message-Id: <9211231931.AA17774@lakatos.osf.org>
To: rwk@crl.dec.com
Cc: info-dylan@cambridge.apple.com
Cc: cfry@MIT.EDU, samp@kurz-ai.com
In-Reply-To: Bob Kerns's message of Fri, 20 Nov 92 20:29:40 -0500 <9211210129.AA18179@taunton.crl.dec.com>
Subject: #f = #none ? 
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

       If our problem is getting to explcitly use a default value, how
       about a function that, given the name of a function and the
       name of one of its arguments, returns the value of the default
       for that function.

   I like this, a lot.  Information should be explicit and
   represented, not closed and hidden.

In effect, this makes keyword names part of the dynamic structure of
the language, not just its static structure.  I don't like this,
because it is using environment operations (or "meta-operations" if
you prefer) as ordinary operations.  Environments need dynamic
operations on argument lists; running code should not.

	-s



From alms Mon Nov 23 19:49:59 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16346; Mon, 23 Nov 92 19:50:03 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16332; Mon, 23 Nov 92 19:49:59 -0500
Message-Id: <9211240049.AA16332@cambridge.apple.com>
Date: Mon, 23 Nov 1992 20:00:12 -0500
To: info-dylan@cambridge.apple.com, eliot@dcs.qmw.ac.uk
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: <boolean> (was Re: object-class)

At  2:26 PM 11/21/92 +0000, eliot@dcs.qmw.ac.uk wrote:
> 
> Here's the Smalltalk (my DYLAN is not fluent enough yet!):
> 
>     True methods for controlling
> 
>     ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
>         ^trueAlternativeBlock value
> 
> 
>     False methods for controlling
> 
>     ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock
>         ^falseAlternativeBlock value
> 
> The above are the implementations of ifTrue:ifFalse: in classes True & False.
> trueAlternativeBlock and falseAlternativeBlock are both closures. ^ is
> return result from method, and value is the message that causes closures to
> evaluate themselves.
> 
> I don't have the DYLAN book to hand so I won't embarrass myself trying to
> translate.  DYLAN equivalents anyone?

(define-generic-function dispatching-if (value true-clause false-clause))

(define-method dispatching-if ((value (singleton #f))
                               (true-clause <function>)
                               (false-clause <function>))
  (false-clause))

(define-method dispatching-if ((value <object>) ;anything besides #f is true
                               (true-clause <function>)
                               (false-clause <function>))
  (true-clause))


If you only want to allow #t to count as 'true' then you would change the
second method definition to specialize on (singleton #t) rather than
<object>.

dispatching-if could be used as follows:

(dispatching-if some-value
                (method () (print "It was true."))
                (method () (print "It was false.")))


From alms Mon Nov 23 19:50:03 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16351; Mon, 23 Nov 92 19:50:11 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16347; Mon, 23 Nov 92 19:50:03 -0500
Message-Id: <9211240050.AA16347@cambridge.apple.com>
Date: Mon, 23 Nov 1992 20:00:16 -0500
To: mayer@wrc.xerox.com, rwk@crl.dec.com, dyer@eagle.sharebase.com (Scot Dyer)
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: #f = #none ?
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com, samp@kurz-ai.com

At  2:43 PM 11/19/92 -0800, Scot Dyer wrote:
> From: Bob Kerns <rwk@crl.dec.com>
> /// 
> ///     Date: Thu, 19 Nov 1992 11:41:07 PST
> ///     From: Jim Mayer <mayer@wrc.xerox.com>
> /// 
> ///     Why is that a problem?  Under the semantics I gave above, #none is a
> ///     perfectly good value.  If no default is given, it is passed right
> ///     through and the "right" thing would happen at the fuction that was
> ///     prepared to do the defaulting.
> 
> Aha!  This really seems like the core issue to resolve with #none -- whether
> or not it should be considered part of <object>.  If it is not, then this
> passing down won't work as expected.  Then again, proper initial design of
> the inter-layer protocols would avoid this problem.
> 
> /// It suffers from the same punning problems as NIL.  Anytime
> /// you try encoding this out-of-band information in-band in
> /// the data object, you incur risk of punning.  Consider a
> /// compiler or macro cogitating about what to do with this
> /// #none argument.

Our original design of Dylan had an object called $unsupplied.  We ended
up abandoning it for exactly the reasons Bob is pointing out.  People got
tripped up by it too often.  They ended up passing it around in an effort
to default their protocols, but then (because they were treating it as
data) it ended up messing up other protocols.

I think that it's extremely unlikely that we would reconsider this decision
at this time.  There are other solutions to the problem, and there are
plenty of other problems in Dylan which don't yet have existing solutions.


From info-dylan-request Mon Nov 23 20:10:54 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16696; Mon, 23 Nov 92 20:10:56 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16691; Mon, 23 Nov 92 20:10:54 -0500
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12047; Mon, 23 Nov 92 20:18:44 -0500
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA18813; Mon, 23 Nov 92 20:13:08 EST
Message-Id: <9211240113.AA18813@MIT.EDU>
Date: Mon, 23 Nov 92 20:14:05 EST
From: cfry@MIT.EDU (Christopher Fry)
To: Stavros Macrakis <macrakis@osf.org>
Subject: Re: #f = #none ? 
Cc: rwk@crl.dec.com, info-dylan@cambridge.apple.com

> Date: Mon, 23 Nov 1992 14:31:10 -0500
> To: rwk@crl.dec.com
> Cc: info-dylan@cambridge.apple.com
> Cc: cfry@MIT.EDU, samp@kurz-ai.com
> In-Reply-To: Bob Kerns's message of Fri, 20 Nov 92 20:29:40 -0500 <9211210129.AA18179@taunton.crl.dec.com>
> Subject: #f = #none ? 
> From: Stavros Macrakis <macrakis@osf.org>
> Sender: macrakis@osf.org
> 
>        If our problem is getting to explcitly use a default value, how
>        about a function that, given the name of a function and the
>        name of one of its arguments, returns the value of the default
>        for that function.
> 
>    I like this, a lot.  Information should be explicit and
>    represented, not closed and hidden.
> 
> In effect, this makes keyword names part of the dynamic structure of
> the language, not just its static structure.  I don't like this,
> because it is using environment operations (or "meta-operations" if
> you prefer) as ordinary operations.  Environments need dynamic
> operations on argument lists; running code should not.

I have a hard time separating out the "environment" from the
"running code". Maybe that's just the kind of programs I write.
In any case, if one of the things your "running code" is not allowed to
do is redefine functions, then the "stand-alone-application compiler"
should be able to grab the default value of some referenced fn and
tuck it away so that it can be used to effectively replace the call
to the (get-default-value ...) fn
when it is "called" by the running code, and no one will be the wiser.
In this scheme you wouldn't be able to do stuff like:
(get-default-value (intern (concatenate 'string "foo-" "bar"))
                   (if *dead?* 'arg1 'arg2))
but would be forced to limit yourself to:
(get-default-value 'foo-bar 'arg1), or maybe make it a macro and
leave off the quotes altogether. I'd be happy with that
limitation for almost all my uses of such a capability. 

From info-dylan-request Tue Nov 24 08:47:42 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04754; Tue, 24 Nov 92 08:47:44 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04750; Tue, 24 Nov 92 08:47:42 -0500
Received: from magician.dcs.qmw.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12794; Tue, 24 Nov 92 08:55:31 -0500
	for info-dylan@cambridge.apple.com
Received: from dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk with SMTP (PP) 
          id <3609-0@magician.dcs.qmw.ac.uk>; Tue, 24 Nov 1992 13:50:26 +0000
Received: by sterling.dcs.qmw.ac.uk (4.1/QMW-Minimal-1.14) id AA24164;
          Tue, 24 Nov 92 13:59:16 GMT
From: eliot@dcs.qmw.ac.uk
Message-Id: <9211241359.AA24164@sterling.dcs.qmw.ac.uk>
Subject: Re: <boolean> (was Re: object-class)
To: macrakis@osf.org (Stavros Macrakis)
Date: Tue, 24 Nov 92 13:59:15 GMT
Cc: info-dylan@cambridge.apple.com
In-Reply-To: <9211231842.AA17748@lakatos.osf.org>; from "Stavros Macrakis" at Nov 23, 92 1:42 pm
X-Mailer: ELM [version 2.3 PL11]

>
>   ...If you have separate classes for true & false then its possible
>   to define the basic control structures using polymorphism on #t &
>   #f and lambda (method)....
>
>Elegant, perhaps, but what does it add to the ease of reading or
>writing programs, or even to the ease of defining Dylan's semantics?
>
>	-s
>
Take a look at Smalltalk and Self and see what you think.

You can always make the programs easier to read by introducing syntactic
sugar for lambda creation, which is what Smalltalk and Self do.
In Smalltalk you construct a zero-arg lambda by writing statements inside [ ]

e.g.
	a > b ifTrue: [a] ifFalse: [b]
		      ^             ^ lambda that returns b
		      ^ lambda that returns a


>writing programs, or even to the ease of defining Dylan's semantics?
Its clearly easier to define new control semantics with this approach.
One no longer needs to augment the compiler to do so.

Thats not the same thing as having a small, concise definition of control
semantics.  In Smalltalk & Self control semantics are spread throughout
several relevant classes.

The point is that if a subset of the language has the expressive power to
implement parts of the language outside thsi subset then the language is
overspecified.  There are good reasons (such as efficiency) for doing this,
but its not necessary.


-- 
Eliot Miranda,  Lecturer	email:	eliot@dcs.qmw.ac.uk
Department of Computer Science	ARPA:	eliot%dcs.qmw.ac.uk@nsf.ac.uk
Queen Mary Westfield College	UUCP:	eliot@qmw-dcs.uucp
Mile End Road, LONDON E1 4NS	Tel:	071 975 5229 (+44 71 975 5229)
				Fax:	081 980 6533 (+44 81 980 6533)

From info-dylan-request Tue Nov 24 13:22:08 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18212; Tue, 24 Nov 92 13:22:09 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18208; Tue, 24 Nov 92 13:22:08 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13718; Tue, 24 Nov 92 13:30:02 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9211241830.AA13718@brazil.cambridge.apple.com>
Via: uk.ac.open; Tue, 24 Nov 1992 16:49:35 +0000
Received: from hcrlpost.open.ac.uk by mercury.open.ac.uk with SMTP (PP) 
          id <26345-0@mercury.open.ac.uk>; Tue, 24 Nov 1992 16:12:51 +0000
Date: 24 Nov 92 16:13:13 U
From: Stuart Watt <S.N.K.Watt@open.ac.uk>
Subject: RE: <boolean> (was Re: object-class)
To: eliot@dcs.qmw.ac.uk
Cc: info-dylan@cambridge.apple.com

> Thats not the same thing as having a small, concise definition of control
> semantics.  In Smalltalk & Self control semantics are spread throughout
> several relevant classes.

I'd agree. Unfortunately, method dispatch is not complete enough to describe a
good set of control forms. Other forms, such as bind-exit, deal with scoping
and pure O-O approaches get weak here. Continuation-passing is better at this,
and is a concise definition of control. I still think that message-passing best
fits into Dylan as an "invisible cond" in the dispatch system. 

What about a type macro system? <true> could be a synonym for (singleton #t),
but I always feel guilty adding stuff to small languages. Perhaps this can be
integrated with the forthcoming definition of macros so as not to be too big.

Stuart Watt
Human Cognition Research Laboratory, 
The Open University, Milton Keynes, MK7 6AA. UK.
Email: S.N.K.Watt@open.ac.uk; Tel: +44 908 655013; Fax: +44 908 653169

From info-dylan-request Tue Nov 24 13:31:33 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18686; Tue, 24 Nov 92 13:31:35 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18680; Tue, 24 Nov 92 13:31:33 -0500
Received: from earth.med.ohio-state.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13811; Tue, 24 Nov 92 13:39:29 -0500
	for info-dylan@cambridge.apple.com
Received: from [128.146.78.12] (max.med.ohio-state.edu) by earth.med.ohio-state.edu (4.1/5.901120)
	id AA03242; Tue, 24 Nov 92 13:26:55 EST
Date: Tue, 24 Nov 92 13:26:54 EST
Message-Id: <9211241826.AA03242@earth.med.ohio-state.edu>
To: info-dylan@cambridge.apple.com, info-dylan-request@cambridge.apple.com
From: amra@med.ohio-state.edu
Subject: unsubscribe

Please unsubscribe me.
---------------------------------------------------------------------
Nasir K. Amra                                 
Laboratory for Knowledge Based Medical Systems
Ohio State University
571 Health Science Library,376 W. 10th , Columbus, Ohio, 43210
Tel.: (614)-292-8614
Fax: (614)-292-7072
email:amra@med.ohio-state.edu


From info-dylan-request Tue Nov 24 13:34:42 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18836; Tue, 24 Nov 92 13:34:45 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18830; Tue, 24 Nov 92 13:34:42 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13875; Tue, 24 Nov 92 13:42:35 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA27245; Tue, 24 Nov 92 13:34:22 -0500
Received: from woodstock.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 133351.29813; Tue, 24 Nov 1992 13:33:51 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA19214; Tue, 24 Nov 92 09:04:55 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA09843; Tue, 24 Nov 92 09:04:54 PST
Date: Tue, 24 Nov 92 09:04:54 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211241704.AA09843@eagle.sharebase.com>
To: alms@cambridge.apple.com, dyer@eagle.sharebase.com, mayer@wrc.xerox.com,
        rwk@crl.dec.com
Subject: Re: #f = #none ?
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com, samp@kurz-ai.com

Oopth!  An 8:45 is too early for me to post posting correction:

        3) Use this special form in the places where #f is currently supplied
           as a bottom value.  If desired, multiple special forms could be

    One for (parameter-specified?...) one for (variable-bound-by-bind?...) etc.
    I do prefer the idea of having a single (specified?...) special-form,
    though...

           given (along the vein of slot-initialized?), or all these could be
           unified under a single name.  In all other cases, an attempt to
           access these values should result in an exception.

	-- Scot

From info-dylan-request Tue Nov 24 13:36:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18948; Tue, 24 Nov 92 13:36:39 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18943; Tue, 24 Nov 92 13:36:35 -0500
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13909; Tue, 24 Nov 92 13:44:30 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA07376; Tue, 24 Nov 92 13:34:35 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 133348.29792; Tue, 24 Nov 1992 13:33:48 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA19170; Tue, 24 Nov 92 09:00:53 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA09827; Tue, 24 Nov 92 09:00:51 PST
Date: Tue, 24 Nov 92 09:00:51 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211241700.AA09827@eagle.sharebase.com>
To: alms@cambridge.apple.com, dyer@eagle.sharebase.com, mayer@wrc.xerox.com,
        rwk@crl.dec.com
Subject: Re: #f = #none ?
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com, samp@kurz-ai.com

From alms@cambridge.apple.com Mon Nov 23 17:18:46 1992
Date: Mon, 23 Nov 1992 20:00:16 -0500
|At  2:43 PM 11/19/92 -0800, Scot Dyer wrote:
|> From: Bob Kerns <rwk@crl.dec.com>
|> ///
|> ///     Date: Thu, 19 Nov 1992 11:41:07 PST
|> ///     From: Jim Mayer <mayer@wrc.xerox.com>
|> ///
|> ///     Why is that a problem?  Under the semantics I gave above, #none is a
|> ///     perfectly good value.  If no default is given, it is passed right
|> ///     through and the "right" thing would happen at the fuction that was
|> ///     prepared to do the defaulting.
|>
|> Aha!  This really seems like the core issue to resolve with #none -- whether
|> or not it should be considered part of <object>.  If it is not, then this
|> passing down won't work as expected.  Then again, proper initial design of
|> the inter-layer protocols would avoid this problem.
|>
|> /// It suffers from the same punning problems as NIL.  Anytime
|> /// you try encoding this out-of-band information in-band in
|> /// the data object, you incur risk of punning.  Consider a
|> /// compiler or macro cogitating about what to do with this
|> /// #none argument.
|
|Our original design of Dylan had an object called $unsupplied.  We ended
|up abandoning it for exactly the reasons Bob is pointing out.  People got
|tripped up by it too often.  They ended up passing it around in an effort
|to default their protocols, but then (because they were treating it as
|data) it ended up messing up other protocols.

Any language construct can be abused.  While this consideration has effected
many language designs, I have yet to see one that prohibits hard to read, hard
to maintain code yet!  :-)  This is a valid consideration, though, although I
might be faster to use it as a reason to leave out multiple-inheritance than
functional condition handling.

|I think that it's extremely unlikely that we would reconsider this decision
|at this time.  There are other solutions to the problem, and there are
|plenty of other problems in Dylan which don't yet have existing solutions.

I can understand this.  It is difficult to do cleanly, and would require
revision of method-dispatch (IMHO) to do it right.  Some would say this was
a 'hack.'

Since #none (or some equivalent bottom value) is not going to be provided in
Dylan, I have a proposal which might satisfy a large number of those concerned
about the use of #f.  Of course, I expect some people will have problems with
parts of this, so I'll try to make it modular in the hopes that it can serve
as a basis for resolving what concerns remain about the current handling of
#f as a bottom value.

	1) Provide a <boolean> class, and let people explicitely cast to it
	   for the 'anything but #f is true' cases.

	2) Provide a special-form predicate for testing if a bottom condition
	   is being returned.  I say a special form since it needs to be given
	   a parameter that may not normally evaluate without causing an error.
	   Possible names (and semmantics for which cases return #t and #f)
	   include:	bound?/unbound?
			specified?/unspecified?  (I like these, personally)
			provided?
			initialized?/uninitialized?

	3) Use this special form in the places where #f is currently supplied
	   as a bottom value.  If desired, multiple special forms could be
	   given (along the vein of slot-initialized?), or all these could be
	   unified under a single name.  In all other cases, an attempt to
	   access these values should result in an exception.

	   These places where #f is currently supplied include: bind, optional
	   parameters, and where else?

What do people think of this?  Is it a fair compromise?

I don't want Dylan to contain hygenic problems.  If the designers of Dylan have
found #none to be one, I think it should be abandoned (at least in 'Dylan'),
but in order to do so hygenically we need some way to avoid LISPs 'nil [or #f]
is either a bottom value or a real value.'  What do _you_ think of this, alms?

	-- Scot

From info-dylan-request Tue Nov 24 15:00:26 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23157; Tue, 24 Nov 92 15:00:27 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23153; Tue, 24 Nov 92 15:00:26 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14256; Tue, 24 Nov 92 15:08:23 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA03888; Tue, 24 Nov 92 15:02:38 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA18534; Tue, 24 Nov 1992 15:00:27 -0500
Date: Tue, 24 Nov 1992 15:00:27 -0500
Message-Id: <9211242000.AA18534@lakatos.osf.org>
To: eliot@dcs.qmw.ac.uk
Cc: info-dylan@cambridge.apple.com
In-Reply-To: eliot@dcs.qmw.ac.uk's message of Tue, 24 Nov 92 13:59:15 GMT <9211241359.AA24164@sterling.dcs.qmw.ac.uk>
Subject: <boolean> (was Re: object-class)
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

eliot@dcs.qmw.ac.uk says:

   >   ...define the basic control structures using polymorphism on #t &
   >   #f and lambda (method)....

   You can always make the programs easier to read by introducing syntactic
   sugar for lambda creation, which is what Smalltalk and Self do.

Yes, they will be easier to read, but much more error-prone to write,
since accidentally using () rather than [] will radically change the
meaning of your program.  Unless you propose that "if" be a special
form which closure-quotes its arguments, as opposed to (say) *if.  But
that would bring us back to where we started in practical terms.
Aesthetically, it's nicer perhaps.

	-s

From info-dylan-request Tue Nov 24 16:20:45 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25354; Tue, 24 Nov 92 16:20:47 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25350; Tue, 24 Nov 92 16:20:45 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14505; Tue, 24 Nov 92 16:28:42 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA01172; Tue, 24 Nov 92 16:22:20 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA18550; Tue, 24 Nov 1992 16:19:56 -0500
Date: Tue, 24 Nov 1992 16:19:56 -0500
Message-Id: <9211242119.AA18550@lakatos.osf.org>
To: alms@cambridge.apple.com
Cc: mayer@wrc.xerox.com, rwk@crl.dec.com, dyer@eagle.sharebase.com,
        cfry@mit.edu, samp@kurz-ai.com, info-dylan@cambridge.apple.com
In-Reply-To: Andrew LM Shalit's message of Mon, 23 Nov 1992 20:00:16 -0500 <9211240050.AA16347@cambridge.apple.com>
Subject: #f = #none ?
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

   Our original design of Dylan had an object called $unsupplied.  We ended
   up abandoning it for exactly the reasons Bob is pointing out.  People got
   tripped up by it too often....

Clearly there are many ways to trip up with $unsupplied.  But what is
the logic behind identifying the boolean value false with the absence
of an argument, or, worse perhaps, non-#f-ness with the boolean value
true?  Surely there are many ways to trip up with all that as well?

   I think that it's extremely unlikely that we would reconsider this decision
   at this time.  There are other solutions to the problem, and there are
   plenty of other problems in Dylan which don't yet have existing solutions.

I'm sure many of us would be interested in hearing about these
problems.

	-s

From alms Wed Nov 25 15:44:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02292; Wed, 25 Nov 92 15:44:55 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02287; Wed, 25 Nov 92 15:44:53 -0500
Message-Id: <9211252044.AA02287@cambridge.apple.com>
Date: Wed, 25 Nov 1992 15:55:21 -0500
To: info-dylan
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: info-dylan@cambridge.apple.com

>   ...If you have separate classes for true & false then its possible
>   to define the basic control structures using polymorphism on #t &
>   #f and lambda (method)....

While this is a simplification in theory, I don't think it would simplify
the practice of programming in Dylan.  It might be different in Self and
Smalltalk.

If you allow the user to define methods on IF, then it also makes things
much harder for the compiler.

   -Andrew


From alms Wed Nov 25 17:25:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03683; Wed, 25 Nov 92 17:26:26 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03657; Wed, 25 Nov 92 17:25:53 -0500
Message-Id: <9211252225.AA03657@cambridge.apple.com>
Date: Wed, 25 Nov 1992 17:36:21 -0500
To: alms@cambridge.apple.com, dyer@eagle.sharebase.com, mayer@wrc.xerox.com,
        rwk@crl.dec.com, dyer@eagle.sharebase.com (Scot Dyer)
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: #f = #none ?
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com, samp@kurz-ai.com

At  9:00 AM 11/24/92 -0800, Scot Dyer wrote:
> From alms@cambridge.apple.com Mon Nov 23 17:18:46 1992
> 
> |Our original design of Dylan had an object called $unsupplied.  We ended
> |up abandoning it for exactly the reasons Bob is pointing out.  People got
> |tripped up by it too often.  They ended up passing it around in an effort
> |to default their protocols, but then (because they were treating it as
> |data) it ended up messing up other protocols.
> 
> Any language construct can be abused.  While this consideration has effected
> many language designs, I have yet to see one that prohibits hard to read, hard
> to maintain code yet!  :-)  This is a valid consideration, though, although I
> might be faster to use it as a reason to leave out multiple-inheritance than
> functional condition handling.

The problem wasn't abuse.  The problem was that they had a hard time under-
standing how to properly use it (partly because we couldn't explain a proper
way to use it).

> |I think that it's extremely unlikely that we would reconsider this decision
> |at this time.  There are other solutions to the problem, and there are
> |plenty of other problems in Dylan which don't yet have existing solutions.
> 
> I can understand this.  It is difficult to do cleanly, and would require
> revision of method-dispatch (IMHO) to do it right.  Some would say this was
> a 'hack.'
> 
> Since #none (or some equivalent bottom value) is not going to be provided in
> Dylan, I have a proposal which might satisfy a large number of those concerned
> about the use of #f.  Of course, I expect some people will have problems with
> parts of this, so I'll try to make it modular in the hopes that it can serve
> as a basis for resolving what concerns remain about the current handling of
> #f as a bottom value.
> 
>         1) Provide a <boolean> class, and let people explicitely cast to it
>            for the 'anything but #f is true' cases.
> 
>         2) Provide a special-form predicate for testing if a bottom condition
>            is being returned.  I say a special form since it needs to be given
>            a parameter that may not normally evaluate without causing an error.
>            Possible names (and semmantics for which cases return #t and #f)
>            include:     bound?/unbound?
>                         specified?/unspecified?  (I like these, personally)
>                         provided?
>                         initialized?/uninitialized?
> 
>         3) Use this special form in the places where #f is currently supplied
>            as a bottom value.  If desired, multiple special forms could be
>            given (along the vein of slot-initialized?), or all these could be
>            unified under a single name.  In all other cases, an attempt to
>            access these values should result in an exception.
> 
>            These places where #f is currently supplied include: bind, optional
>            parameters, and where else?
> 
> What do people think of this?  Is it a fair compromise?

I think this solution is bigger than the problem it solves.  But perhaps that's
just because I'm conservative.  To really judge I'd need to see a complete
proposal, I'd need to try programming in the resulting language, and I'd need
to try to explain the resulting language to a beginner.

Now for a meta comment:

In general, we are going to be very conservative in changes we make to Dylan
at this time.  We want to avoid complications or untested changes to the basic
language model.  We want to make it easier to compile the language and deliver
small, efficient applications.  We want to make the language more accessible to
static language programmers.  And we want to fix things which simply cannot work
as currently specified.

There are lots of directions that people could take Dylan.  I'd love to see
people explore some of these directions in their own implementations.  If an idea
prove itself, we'll probably use it in the future (or some other language
will).

So, keep exploring, but please understand if we don't follow at this time.

   -Andrew Shalit
    alms@cambridge.apple.com


From alms Wed Nov 25 20:15:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03683; Wed, 25 Nov 92 17:26:26 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03657; Wed, 25 Nov 92 17:25:53 -0500
Message-Id: <9211252225.AA03657@cambridge.apple.com>
Date: Wed, 25 Nov 1992 17:36:21 -0500
To: alms@cambridge.apple.com, dyer@eagle.sharebase.com, mayer@wrc.xerox.com,
        rwk@crl.dec.com, dyer@eagle.sharebase.com (Scot Dyer)
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: #f = #none ?
Cc: cfry@mit.edu, info-dylan@cambridge.apple.com, samp@kurz-ai.com

At  9:00 AM 11/24/92 -0800, Scot Dyer wrote:
> From alms@cambridge.apple.com Mon Nov 23 17:18:46 1992
> 
> |Our original design of Dylan had an object called $unsupplied.  We ended
> |up abandoning it for exactly the reasons Bob is pointing out.  People got
> |tripped up by it too often.  They ended up passing it around in an effort
> |to default their protocols, but then (because they were treating it as
> |data) it ended up messing up other protocols.
> 
> Any language construct can be abused.  While this consideration has effected
> many language designs, I have yet to see one that prohibits hard to read, hard
> to maintain code yet!  :-)  This is a valid consideration, though, although I
> might be faster to use it as a reason to leave out multiple-inheritance than
> functional condition handling.

The problem wasn't abuse.  The problem was that they had a hard time under-
standing how to properly use it (partly because we couldn't explain a proper
way to use it).

> |I think that it's extremely unlikely that we would reconsider this decision
> |at this time.  There are other solutions to the problem, and there are
> |plenty of other problems in Dylan which don't yet have existing solutions.
> 
> I can understand this.  It is difficult to do cleanly, and would require
> revision of method-dispatch (IMHO) to do it right.  Some would say this was
> a 'hack.'
> 
> Since #none (or some equivalent bottom value) is not going to be provided in
> Dylan, I have a proposal which might satisfy a large number of those concerned
> about the use of #f.  Of course, I expect some people will have problems with
> parts of this, so I'll try to make it modular in the hopes that it can serve
> as a basis for resolving what concerns remain about the current handling of
> #f as a bottom value.
> 
>         1) Provide a <boolean> class, and let people explicitely cast to it
>            for the 'anything but #f is true' cases.
> 
>         2) Provide a special-form predicate for testing if a bottom condition
>            is being returned.  I say a special form since it needs to be given
>            a parameter that may not normally evaluate without causing an error.
>            Possible names (and semmantics for which cases return #t and #f)
>            include:     bound?/unbound?
>                         specified?/unspecified?  (I like these, personally)
>                         provided?
>                         initialized?/uninitialized?
> 
>         3) Use this special form in the places where #f is currently supplied
>            as a bottom value.  If desired, multiple special forms could be
>            given (along the vein of slot-initialized?), or all these could be
>            unified under a single name.  In all other cases, an attempt to
>            access these values should result in an exception.
> 
>            These places where #f is currently supplied include: bind, optional
>            parameters, and where else?
> 
> What do people think of this?  Is it a fair compromise?

I think this solution is bigger than the problem it solves.  But perhaps that's
just because I'm conservative.  To really judge I'd need to see a complete
proposal, I'd need to try programming in the resulting language, and I'd need
to try to explain the resulting language to a beginner.

Now for a meta comment:

In general, we are going to be very conservative in changes we make to Dylan
at this time.  We want to avoid complications or untested changes to the basic
language model.  We want to make it easier to compile the language and deliver
small, efficient applications.  We want to make the language more accessible to
static language programmers.  And we want to fix things which simply cannot work
as currently specified.

There are lots of directions that people could take Dylan.  I'd love to see
people explore some of these directions in their own implementations.  If an idea
prove itself, we'll probably use it in the future (or some other language
will).

So, keep exploring, but please understand if we don't follow at this time.

   -Andrew Shalit
    alms@cambridge.apple.com


From info-dylan-request Thu Nov 26 11:37:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03841; Thu, 26 Nov 92 11:37:05 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03835; Thu, 26 Nov 92 11:37:04 -0500
Received: from magician.dcs.qmw.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18193; Thu, 26 Nov 92 11:45:10 -0500
	for info-dylan@cambridge.apple.com
Received: from dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk with SMTP (PP) 
          id <26614-0@magician.dcs.qmw.ac.uk>; Thu, 26 Nov 1992 16:39:46 +0000
Received: by debara.dcs.qmw.ac.uk (4.1/QMW-Minimal-1.14) id AA19846;
          Thu, 26 Nov 92 16:50:13 GMT
From: eliot@dcs.qmw.ac.uk
Message-Id: <9211261650.AA19846@debara.dcs.qmw.ac.uk>
Subject: Re: <boolean> <true> & <false>
To: info-dylan@cambridge.apple.com
Date: Thu, 26 Nov 92 16:50:13 GMT
In-Reply-To: <9211252044.AA02287@cambridge.apple.com>; from "Andrew LM Shalit" at Nov 25, 92 3:55 pm
X-Mailer: ELM [version 2.3 PL11]

>
>>   ...If you have separate classes for true & false then its possible
>>   to define the basic control structures using polymorphism on #t &
>>   #f and lambda (method)....
>
>While this is a simplification in theory, I don't think it would simplify
>the practice of programming in Dylan.  It might be different in Self and
>Smalltalk.
>
>If you allow the user to define methods on IF, then it also makes things
>much harder for the compiler.
>
>   -Andrew
>
I'm not sugesting one replace the IF special form by methods.  The
compiler can in-line the Smalltalk-style methods/lambda version of IF, but then
debugging the code reveals that the compiler has treated the IF message
specially.  So if one is concerned about efficiency then use hard-wired control
structures.  

My feeling is that if you introduce a class <boolean> which allows
you to specialise methods on <boolean> and non-<boolean> you should introduce
<true> & <false>, since its likely you will want to specialise methods on
<true> & <false>.

-- 
Eliot Miranda,  Lecturer	email:	eliot@dcs.qmw.ac.uk
Department of Computer Science	ARPA:	eliot%dcs.qmw.ac.uk@nsf.ac.uk
Queen Mary Westfield College	UUCP:	eliot@qmw-dcs.uucp
Mile End Road, LONDON E1 4NS	Tel:	071 975 5229 (+44 71 975 5229)
				Fax:	081 980 6533 (+44 81 980 6533)

From info-dylan-request Fri Nov 27 17:53:21 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05228; Fri, 27 Nov 92 17:53:22 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05224; Fri, 27 Nov 92 17:53:21 -0500
Received: from GOTTLOB.TIP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20113; Fri, 27 Nov 92 18:01:41 -0500
	for info-dylan@cambridge.apple.com
Received: from gottlob.tip.cs.cmu.edu by GOTTLOB.TIP.CS.CMU.EDU id aa04578;
          27 Nov 92 17:55:39 EST
To: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Robust Dylan implementations available?
Date: Fri, 27 Nov 92 17:55:37 EST
Message-Id: <4566.722904937@GOTTLOB.TIP.CS.CMU.EDU>
From: Robert_Harper@GOTTLOB.TIP.CS.CMU.EDU

I'm considering using Dylan in a sophomore-level computer science course here
at CMU, and was wondering whether there is a stable implementation available
that will run on DecStation's and Sparc's.  I don't subscribe to the dylan
mailing list, so if you have specific information or advice, please mail me
directly.  Thank you.

Bob Harper
(rwh@cs.cmu.edu)

From alms Mon Nov 30 10:11:36 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23040; Mon, 30 Nov 92 10:11:39 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23035; Mon, 30 Nov 92 10:11:36 -0500
Message-Id: <9211301511.AA23035@cambridge.apple.com>
Date: Mon, 30 Nov 1992 10:22:44 -0500
To: info-dylan@cambridge.apple.com, eliot@dcs.qmw.ac.uk
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: <boolean> <true> & <false>

At 26 Nov 16:50 GMT, eliot@dcs.qmw.ac.uk wrote:
> >
> >>   ...If you have separate classes for true & false then its possible
> >>   to define the basic control structures using polymorphism on #t &
> >>   #f and lambda (method)....
> >
> >While this is a simplification in theory, I don't think it would simplify
> >the practice of programming in Dylan.  It might be different in Self and
> >Smalltalk.
> >
> >If you allow the user to define methods on IF, then it also makes things
> >much harder for the compiler.
> >
> >   -Andrew
> >
> I'm not sugesting one replace the IF special form by methods.  The
> compiler can in-line the Smalltalk-style methods/lambda version of IF, but then
> debugging the code reveals that the compiler has treated the IF message
> specially.  So if one is concerned about efficiency then use hard-wired control
> structures.  
> 
> My feeling is that if you introduce a class <boolean> which allows
> you to specialise methods on <boolean> and non-<boolean> you should introduce
> <true> & <false>, since its likely you will want to specialise methods on
> <true> & <false>.

Do you want <true> and <false> to be subclassable?  If not, why not just use
(singleton #t) and (singleton #f) instead?  If so, do instances of subclasses
of <false> also appear as false to IF?



From info-dylan-request Mon Nov 30 11:39:48 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25225; Mon, 30 Nov 92 11:39:49 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25221; Mon, 30 Nov 92 11:39:48 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23377; Mon, 30 Nov 92 11:48:31 -0500
	for info-dylan@cambridge.apple.com
Return-Path: <john@linus.mitre.org>
Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S)
	id AA18788; Mon, 30 Nov 92 11:42:37 -0500
Posted-Date: Mon, 30 Nov 92 11:42:34 EST
Received: by thelonius.mitre.org (5.61/RCF-4C)
	id AA09771; Mon, 30 Nov 92 11:42:35 -0500
Message-Id: <9211301642.AA09771@thelonius.mitre.org>
To: info-dylan@cambridge.apple.com
Subject: Re: get-default-value (was Re: #f = #none ?)
Date: Mon, 30 Nov 92 11:42:34 EST
From: john@linus.mitre.org

Sorry about contributing to this thread a week late, but:

Christopher Fry (cfry@MIT.EDU) writes:

  If our problem is getting to explcitly use a default value, how
  about a function that, given the name of a function and the name of
  one of its arguments, returns the value of the default for that
  function. SO:

  (defun foo (a &optional (b (+ 2 3)) ...)
  (foo 1 (get-default-value 'foo 'b))

  One problem is that if we've got

  (defun foo (a &optional (b (+ a 3)) ...)

  then it doesn't work so well without special hacks.
  I guess dylan doesn't have this particular problem but ...

Yes it does, since keyword defaults are arbitrary forms:

  (method (a #key (b (+ a 3)) (c (make-default-whatever))))

John Burger
john@mitre.org

From info-dylan-request Mon Nov 30 11:57:58 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25799; Mon, 30 Nov 92 11:57:59 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25795; Mon, 30 Nov 92 11:57:58 -0500
Received: from RIVERSIDE.SCRC.Symbolics.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23552; Mon, 30 Nov 92 12:06:41 -0500
	for info-dylan@brazil.cambridge.apple.com
Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 959771; 30 Nov 1992 11:59:30-0500
Date: Mon, 30 Nov 1992 11:56-0500
From: Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
Subject: #f = #none ?
To: info-dylan@brazil.cambridge.apple.com
In-Reply-To: <9211242119.AA18550@lakatos.osf.org>
Message-Id: <19921130165640.6.NAHA@LILIKOI.SCRC.Symbolics.COM>

    Date: Tue, 24 Nov 1992 16:19 EST
    From: Stavros Macrakis <macrakis@osf.org>

       Our original design of Dylan had an object called $unsupplied.  We ended
       up abandoning it for exactly the reasons Bob is pointing out.  People got
       tripped up by it too often....

Perhaps a special form ARGUMENT-SUPPLIED-P (or some appropriate name)
could be introduced.  It would take the name of a keyword argument as
argument and return T iff the argument were supplied.

    Clearly there are many ways to trip up with $unsupplied.  But what is
    the logic behind identifying the boolean value false with the absence
    of an argument, or, worse perhaps, non-#f-ness with the boolean value
    true?  Surely there are many ways to trip up with all that as well?

       I think that it's extremely unlikely that we would reconsider this decision
       at this time.  There are other solutions to the problem, and there are
       plenty of other problems in Dylan which don't yet have existing solutions.

    I'm sure many of us would be interested in hearing about these
    problems.



From info-dylan-request Tue Dec  1 07:34:40 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19711; Tue, 1 Dec 92 07:34:43 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19707; Tue, 1 Dec 92 07:34:40 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01151; Tue, 1 Dec 92 07:43:25 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Tue, 1 Dec 1992 13:36:43 +0100
Received: by miles.ircam.fr, Tue, 1 Dec 1992 13:36:42 +0100
Date: Tue, 1 Dec 1992 13:36:42 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212011236.AA06101@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: Why <empty-list> and <pair>? or More heresy...

All this talk of the lack of a need for <true> and <false> classes has
made me wonder why it is necessary to have an <empty-list> class.  Why
can't people just use `(singleton '())'?  Given that, why even have a
<pair> class?  Programs can distinguish between a <pair> instance and
an <empty-list> instance using the same `(singleton '()).  This change
would definitely simplify the class structure.  Granted, in some cases
programmers might need to employ two methods to flag list arguments
that must be non-empty, such as for `(setter car)', but in most cases
they need to handle '() specially anyway and would be writing a
separate method for it.

It could even be argued that #F should also be used as the bottom
value for <list>.  It seems that the real reason to want to use '() is
so that people can `cdr' and `car' it without first checking and that 

	(instance? '() <list>) => #T 

thereby making declarations easier or no need to resort to 

	(or (singleton #F) <list>)

I like these efficiency features, but if people want symmetry, then
one might consider using #F instead of '().

I actually still prefer automatic void values (changed the name to
avoid collision with the usual connotations of bottom value), where
the void value is an instance of the class and could be customized to
have special properties for efficiency (such as '()).  Programs can
access the void value and use it for singleton dispatching.  This
makes the use of a void value (such as '()) both efficient and
symmetrical.

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-42772492
bachrach@ircam.fr


From alms Tue Dec  1 11:16:31 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00713; Tue, 1 Dec 92 11:16:34 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00708; Tue, 1 Dec 92 11:16:31 -0500
Message-Id: <9212011616.AA00708@cambridge.apple.com>
Date: Tue, 1 Dec 1992 11:27:50 -0500
To: info-dylan@cambridge.apple.com,
        Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Why <empty-list> and <pair>? or More heresy...

At  1:36 PM 12/1/92 +0100, Jonathan Bachrach wrote:
> All this talk of the lack of a need for <true> and <false> classes has
> made me wonder why it is necessary to have an <empty-list> class.  Why
> can't people just use `(singleton '())'?  Given that, why even have a
> <pair> class?  Programs can distinguish between a <pair> instance and
> an <empty-list> instance using the same `(singleton '()).  This change
> would definitely simplify the class structure.  Granted, in some cases
> programmers might need to employ two methods to flag list arguments
> that must be non-empty, such as for `(setter car)', but in most cases
> they need to handle '() specially anyway and would be writing a
> separate method for it.

I think it would be perfectly reasonable to do away with <empty-list>,
and use (singleton '()) instead.  Note that () would be an instance
of <list> but not of <pair>.


From info-dylan-request Tue Dec  1 12:25:16 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02598; Tue, 1 Dec 92 12:25:17 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02594; Tue, 1 Dec 92 12:25:16 -0500
Received: from nic.cerf.net by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02208; Tue, 1 Dec 92 12:34:07 -0500
	for info-dylan@cambridge.apple.com
Received: from reticular.com by nic.cerf.net (4.1/CERFnet-1.0)  id AA02950; Tue, 1 Dec 92 09:29:46 PST
Date: Tue, 1 Dec 92 09:29:45 PST
Message-Id: <9212011729.AA02950@nic.cerf.net>
From: Dan R. Ballard <ballard@reticular.com>
To: info-dylan@cambridge.apple.com
Cc: ballard@reticular.com
Subject: Dylan Mailing List

I understand there is a Dylan mailing list.  Please add me to it.

Thanks,

 ---------------------------
Dan Ballard
Reticular Systems, Inc.
6265 Greenwich Dr., Suite #201
San Diego, CA 92122
Internet:  ballard@reticular.com
Phone: (619) 457-0709
FAX:    (619) 457-1926
---------------------------


From info-dylan-request Tue Dec  1 12:28:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02664; Tue, 1 Dec 92 12:28:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02660; Tue, 1 Dec 92 12:28:53 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02284; Tue, 1 Dec 92 12:37:43 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA15998; Tue, 1 Dec 92 12:31:52 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 123025.7485; Tue, 1 Dec 1992 12:30:25 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA16107; Tue, 1 Dec 92 08:41:30 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA12353; Tue, 1 Dec 92 08:41:29 PST
Date: Tue, 1 Dec 92 08:41:29 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9212011641.AA12353@eagle.sharebase.com>
To: Jonathan.Bachrach@ircam.fr, info-dylan@cambridge.apple.com
Subject: Re:  Why <empty-list> and <pair>? or More heresy...

/// From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
/// Subject: Why <empty-list> and <pair>? or More heresy...
///
/// [...stuff deleted...]
///
/// It could even be argued that #F should also be used as the bottom
/// value for <list>.  It seems that the real reason to want to use '() is
/// so that people can `cdr' and `car' it without first checking and that

Gack!  Grand Heretic that I am, I don't want to see Dylan have NIL!  This would
be to parallel one of LISP's grand mistakes by not providing a proper bottom
list distinguishable from false...

I do agree that (singleton '()) seems more in keeping with the rest of the
specification, though.

///         (instance? '() <list>) => #T
/// 
/// thereby making declarations easier or no need to resort to
/// 
///         (or (singleton #F) <list>)
/// 
/// I like these efficiency features, but if people want symmetry, then
/// one might consider using #F instead of '().

It doesn't seem that efficient to me.  Anyway, isn't '() considered a <list>?
I think <list> is an abstract class from which both <empty-list> and <pair>
inherit.  This is reason enough for me to want to leave <list>, <empty-list>
and <pair> -- different classes for different underlying representations seems
natural...

/// I actually still prefer automatic void values (changed the name to
/// avoid collision with the usual connotations of bottom value), where
/// the void value is an instance of the class and could be customized to
/// have special properties for efficiency (such as '()).  Programs can
/// access the void value and use it for singleton dispatching.  This
/// makes the use of a void value (such as '()) both efficient and
/// symmetrical.

We're not going to get them.  Let's move on.

	-- Scot

From info-dylan-request Tue Dec  1 12:53:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03202; Tue, 1 Dec 92 12:53:07 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03198; Tue, 1 Dec 92 12:53:05 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02388; Tue, 1 Dec 92 13:01:57 -0500
	for info-dylan@cambridge.apple.com
Return-Path: <john@linus.mitre.org>
Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S)
	id AA04269; Tue, 1 Dec 92 12:55:59 -0500
Posted-Date: Tue, 01 Dec 92 12:55:56 EST
Received: by thelonius.mitre.org (5.61/RCF-4C)
	id AA10177; Tue, 1 Dec 92 12:55:57 -0500
Message-Id: <9212011755.AA10177@thelonius.mitre.org>
To: info-dylan@cambridge.apple.com
Subject: Re: Why <empty-list> and <pair>? ...
Date: Tue, 01 Dec 92 12:55:56 EST
From: john@linus.mitre.org

Jonathan Bachrach (Jonathan.Bachrach%ircam.FR@princeton.edu) writes:

  All this talk of the lack of a need for <true> and <false> classes
  has made me wonder why it is necessary to have an <empty-list>
  class.  Why can't people just use `(singleton '())'?

Well, <EMPTY-LIST> and (SINGLETON '()) ARE interchangeable when used
as specializers, but I think it's worth noting that they're NOT the
same thing.  There are many operations in Dylan that require a class
as an argument, not just a specializer, e.g. INSTANCE?, AS, SUBCLASS?,
etc.  In CommonLisp, I often find it convenient to use the class NULL,
rather than the type-specifier (EQL '()), those being the analogues of
<EMPTY-LIST> and (SINGLETON '()) in Dylan.

Which is not to say that <EMPTY-LIST>, and to a lesser degree <PAIR>,
don't have their problems.  For instance, are they instantiable?  The
collection class heterarchy diagram seems to indicate that they are,
although they're not listed in the section "The Instantiable
Collection Classes".  If they ARE instantiable, I should be able to do
the following:

  (MAKE <EMPTY-LIST> SIZE: 5 FILL: #F)
  (MAKE <PAIR>       SIZE: 5 FILL: #F)

The first is obviously problematic.  But if <EMPTY-LIST> and <PAIR>
are NOT instantiable, it seems a rather odd situation, since usually
abstract classes are ABOVE instantiable classes in the heterarchy.

BTW, exactly what is the denotation of "abstract class"?  The
"Language Overview" section says MAKE cannot be called on an abstract
class, but that's obviously not true, as page 51 says when it explains
why MAKE need not return a direct instance of its argument class.
Does "abstract class" simply mean there are no direct instances?  Then
<EMPTY-LIST> and <PAIR> are clearly not abstract, and thus I presume
(perhaps rashly) that they ARE instantiable.

Which still doesn't mean I can call MAKE on them without getting an
error.  Maybe the examples above ought simply to have undefined
results, and an implementation can signal an error, or return the
obvious results:

  (MAKE <EMPTY-LIST> SIZE: 5 FILL: #F) => '()
  (MAKE <PAIR>       SIZE: 5 FILL: #F) == (MAKE <LIST> SIZE: 5 FILL: #F)

John Burger
john@mitre.org

From info-dylan-request Tue Dec  1 14:48:26 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05980; Tue, 1 Dec 92 14:48:28 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05974; Tue, 1 Dec 92 14:48:26 -0500
Received: from gmdzi.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20439; Tue, 1 Dec 92 14:57:11 -0500
	for info-dylan@cambridge.apple.com
Received: by gmdzi.gmd.de id AA17964
  (5.65c/IDA-1.4.4 for info-dylan@cambridge.apple.com); Tue, 1 Dec 1992 20:50:50 +0100
Date: Tue, 1 Dec 1992 20:50:50 +0100
From: Keith Playford <Keith.Playford@gmd.de>
Message-Id: <199212011950.AA17964@gmdzi.gmd.de>
To: john@linus.mitre.org
Cc: info-dylan@cambridge.apple.com
In-Reply-To: john@linus.mitre.org's message of Tue, 1 Dec 1992 18:55:56 +0100 <9212011755.AA10177@thelonius.mitre.org>
Subject: Why <empty-list> and <pair>? ...

> From: john@linus.mitre.org
> Posted-Date: Tue, 01 Dec 92 12:55:56 EST
> 
> Jonathan Bachrach (Jonathan.Bachrach%ircam.FR@princeton.edu) writes:
> 
>   All this talk of the lack of a need for <true> and <false> classes
>   has made me wonder why it is necessary to have an <empty-list>
>   class.  Why can't people just use `(singleton '())'?
>
> [...]
> 
> Which is not to say that <EMPTY-LIST>, and to a lesser degree <PAIR>,
> don't have their problems. [...]

Yes, why not finally take the bull by the horns and eliminate both
<empty-list> and <pair>, leaving just <list> to fend for itself as an
instantiable sequence class? Pairs could be retained disjointly as a
special-case tuple type if felt sufficiently useful, as could improper
list notation (if _really_ necessary) but with (a . b) always being
interpreted as a list with an improper tail rather than as a pair.

If it's decided to use the class heterarchy to discriminate empty from
non-empty, then I'd much rather <non-empty-list> be used in place of
<pair> and, again, have a <pair> class defined disjointly. Defining
methods for things like mapping and shallow-copying functions on
<pair> is awful.

This list/pair hang-up is a bit of Lisp tradition I could quite
happily learn to live without.

-- Keith --


From alms Wed Dec  2 10:57:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18842; Wed, 2 Dec 92 10:57:39 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18836; Wed, 2 Dec 92 10:57:14 -0500
Message-Id: <9212021557.AA18836@cambridge.apple.com>
Date: Wed, 2 Dec 1992 11:08:49 -0500
To: info-dylan
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Monthly FAQ Posting

Dylan(tm) FAQ December 2, 1992

This memo answers questions which are frequently asked about the Dylan
programming language.

The latest version of this memo is available by anonymous ftp from
cambridge.apple.com in the file /pub/dylan/dylan-faq.txt. We expect to
make other Dylan documents available for ftp from the same directory.

Changes since the last version of the FAQ are marked by the string '+++'.

The Dylan manual is not available in electronic form, but a bound copy
may be requested by sending your name and address to
dylan-manual-request@cambridge.apple.com.  (Applelink users should
send to dylan-request@cambridge.apple.com@internet#.)  As of this writing,
there is no charge for the manual.

If you want to keep up with Dylan news, consider joining the info-dylan
mailing list, described below.


*****General Questions About Dylan******

* What is Dylan?

  Dylan is a new Object Oriented Dynamic Language (OODL), developed by the
  Eastern Research and Technology Lab of Apple Computer.  Dylan was
  designed to make the advantages of OODLs available for commercial
  programming on a variety of computing devices.
  
  Dylan most closely resembles CLOS and Scheme.  Other languages which
  influenced the design of Dylan include Smalltalk, Self, and OakLisp.
  
  Dylan is consistently object-oriented.  It is not a procedural language
  with an object-oriented extension.  To this end, Dylan does not attempt
  to be compatible with any previously existing programming language.

* What is the target audience for Dylan?

  The target audience for Dylan is software application programmers, most
  of whom are currently using static languages such as C and C++.
  We realize that the current manual is more appropriate for people
  already familiar with OODLs.  We have plans for additional documents
  directed at static language programmers.

* How does Dylan differ from previous OODLs?

  Dylan is designed to allow the powerful and flexible programming
  techniques and development environments associated with OODLs,
  while also allowing the small, fast delivered applications currently
  associated with static languages.

  Unlike many dynamic languages, Dylan's design consciously enables the
  runtime environment to execute without the development environment
  present. In addition, Dylan will let you selectively 'turn-off'
  dynamic capabilities when they are no longer needed, allowing more
  efficient compilation.

* Are there any public mailing lists for discussing Dylan?

  Yes.  There are four mailing lists of interest to the public.  Three
  of these addresses have a corresponding administrative address.
  If you want to be added to or removed from a mailing list, send mail
  to the administrative address, not the mailing list address.

  info-dylan@cambridge.apple.com
  info-dylan-request@cambridge.apple.com (administration)
  info-dylan-req@cambridge.apple.com@internet# (admin from Applelink)
  This is a two-way mailing list for discussing any and all issues
  related to Dylan.
  
  announce-dylan@cambridge.apple.com
  announce-dylan-request@cambridge.apple.com (administration)
  announce-d-req@cambridge.apple.com@internet# (admin from Applelink)
  This is a mailing list for major announcements about Dylan (new implement-
  ation availability, new manual availability, etc).  This mailing list is
  for people who want to keep up on Dylan news, but don't want the quantity
  of mail that comes through info-dylan.

  dylan-builders@cambridge.apple.com
  dylan-builders-request@cambridge.apple.com (administration)
  d-builders-req@cambridge.apple.com@internet# (admin from Applelink)
  This is a two-way mailing list for people who are working on Dylan
  implementations or who are considering working on an implementation.
  If you want to join this list, please send mail describing your plans
  to dylan-builders-request.

  dylan-comments@cambridge.apple.com
  This is a one way mailing list for sending comments to the people working
  on Dylan at Apple.  Most Dylan discussions can take place on info-dylan.

* Does Apple have an implementation of Dylan?

  Apple hasn't announced plans to release an implementation of Dylan.
  However, we are working on implementations, and our implementation
  efforts have been an important proving ground for the Dylan design.

* Will there be Apple products based on Dylan?

  Apple has not announced any use of Dylan in products.

* +++ Is Dylan related to the Apple PDA project called Newton?

  No. Dylan is being created by Apple's Advanced Technology Group, and no
  product-specific implementations of Dylan have been announced yet.
  If you are looking for more information on Newton development, you need to
  contact the Newton Developer Relations at NEWTON.DEVS@applelink.apple.com

* Are there third-party implementations of Dylan available?

  Several third-parties have expressed interest in implementing
  Dylan.  A group at DEC has succeeded in implementing a language
  based on the Dylan manual.  They describe it as follows:

      Thomas, a compiler written at Digital Equipment Corporation's
      Cambridge Research Laboratory, is now available to the
      public.  Thomas compiles a language compatible with the
      language described in the book "Dylan(TM) an object-oriented
      dynamic language" by Apple Computer Eastern Research and
      Technology, April 1992.
      
      The Thomas system is written in Scheme and is available to
      run under any one of three public implementations of Scheme:
      MIT's CScheme, DEC's Scheme->C, and Marc Feeley's Gambit.  It
      can run on a wide range of machines including the Macintosh,
      PC compatibles, Vax, MIPS, Alpha, and 680x0.  Thomas
      generates IEEE compatible Scheme code.  The entire system
      (including sources) is available by anonymous ftp from:
      
             crl.dec.com:pub/DEC/Thomas
             gatekeeper.pa.dec.com:pub/DEC/Thomas
             altdorf.ai.mit.edu:archive/Thomas

  We've also made Thomas available in the Dylan ftp directory at
  cambridge.apple.com.

  +++ Thanks to Marc Feeley, Thomas embedded in Gambit is now available
  as a stand-alone Macintosh application.  We've placed this in the
  ftp directory on cambridge.apple.com.

* Is Dylan a proprietary language?  Why is the Dylan name trademarked?

  We want Dylan to be available on as many computers as possible.  To this
  end, we are encouraging groups outside Apple to implement Dylan.

  It is our intention to license the Dylan trademark to any implementation
  which passes a standard test suite.  The purpose of the trademark is to
  ensure quality and consistency among implementations.

* What should I do if I want to implement Dylan?

  Send mail to dylan-builders-request@cambridge.apple.com.  We are
  putting together a program to support implementors, and we want to hear
  from you.  (Applelink users should send mail to
  d-builders-req@applelink.apple.com@internet#.)

  +++ If you've written an implementation of Dylan and want to release it,
  please contact us for a trademark license.

* Is the Dylan language design frozen?

  We don't plan changes to the general structure of the language, but we
  expect to continue working on the details.  We also expect to specify
  some extensions and libraries.
  
  We welcome your comments on the Dylan design.  Your feedback is very
  important to the further evolution of the language.  We haven't
  specified a limited review period.
  
  Please understand that because of the amount of mail we are receiving,
  we may not be able to respond to your message in detail.

* Are design clarifications available?

  We are working on design clarifications.  They will be made available
  via anonymous ftp from cambridge.apple.com.

* Is there a group which promotes the use of object-oriented dynamic
  languages?

  Yes.  There is an OODL special interest group of MADA.  MADA is a group
  which champions object-oriented programming on the Macintosh.  The OODL
  sig is currently focusing on Macintosh Common Lisp, but it intends to
  expand to other languages and environments.
  
  To subscribe to the OODL sig mailing list from Applelink send mail to
  OODL.SIG. Internet subscriptions should be requested from
  oodl-sig-request@cambridge.apple.com.


*****Questions about the Dylan Language Design******


* Is Apple planning to specify an alternate syntax for Dylan?

  Yes.  We recognize that many people prefer an algebraic syntax, and
  we plan to create and document such a syntax for Dylan.

* Are there plans to specify a standard i/o package for Dylan?

  Simple i/o will probably be specified in an optional library, rather
  than in the core language.  A single i/o system wouldn't make sense on
  all computing devices because of the variation in user interfaces and
  storage systems.

* Will Dylan specify a standard threading mechanism?

  We recognize that threads are important and that most implementations of
  Dylan will support them.  We haven't yet decided whether a standard
  thread mechanism would be appropriate for all platforms.

* Why is 'make' allowed to return a previously allocated instance, or an
  object which is an indirect instance of the class passed to 'make'?

  We feel that this is a very important abstraction mechanism.  A class
  should have flexibility in how it implements 'make', as long as the object
  returned fulfills the protocol of the class.
  
  For example, this allows a library to document a single abstract class
  which is supported by several undocumented implementation classes. The
  abstract class can choose which implementation class to instantiate
  based on the additional arguments to 'make'.  This allows optimizations
  which are transparent to the clients of the library.

  The default method for 'make' of a user-defined class returns a fresh
  direct instance of the requested class.

* The Dylan manual doesn't require implementations to optimize tail
  recursion. Was this an intentional omission, or an editorial oversight?

  It was an editorial oversight.  Dylan implementations will be required
  to be properly tail recursive.

* The Dylan manual doesn't say much about modules.  Will this be
  specified in the future?

  Dylan modules will be further specified in an upcoming design note.
  At this time we expect modules to exist only at compile-time, not at
  runtime.  Non-portable extensions may support runtime module operations.

* Can the 'method' special form be used to create closures?

  Yes.

* I don't understand how setter variables work.  Is 'setter' a special
  form?

  'setter' just provides an alternate way to spell variable names.  For
  example, the following are all legal spellings of variable names:

    foo
    bar
    (setter foo)
    (setter quux)
  
  'setter' is pure syntax, and nothing more.  It's probably unnecessarily
  confusing to make setter variables look like function calls.  For this
  reason, we are considering changing the syntax of setter variables.

* Why not just have 'setter' be a function which takes a getter function
  as an argument and returns the corresponding setter function?

  If we did this, the action of exporting a getter function would
  automatically export the setter as well.  We believe that it's important
  to allow the getter and setter to be exported and imported independently.
  The design of setter variables allows this.

* What kind of object is used to return multiple values?

  When a function returns multiple values, the return values are not
  stored in a wrapper object;  they are returned directly.  For example,
  if a function returns "the values 4 and 5", it returns two integers.  It
  does not return a data structure which contains two integers.
  
  Returning multiple values is similar to calling a function with more
  than one argument.  When passing multiple objects as arguments to a
  function, the objects do not have to be stored in a single data
  structure before they are passed.

* Is the specification of sealing complete?

  No.  We expect the specification of sealing to evolve as we gain
  implementation experience.
  
  At this point, we believe that sealing operations should be expressed
  declaratively, as compile-time operations, rather than as run-time
  operations.  In the Dylan manual they are described as run-time operations.

* Will Dylan include 'eval'?

  Some implementations may choose to support 'eval', but we do not have
  plans to add it to the language standard.  We feel that the delivery
  of applications which are space efficient requires the separation of
  development time activity from runtime activity.

* Will Dylan include an application framework?

  We recognize the value of application frameworks, especially cross-
  platform application frameworks.  Unfortunately, because of the great
  variation in computing platforms, a single application framework will
  not be part of the Dylan language.  On each platform, there should either
  be a Dylan-specific application framework, or Dylan should be able to use
  application frameworks written in other languages.

* Will Dylan interface to other languages?
  
  We recognize that seamless integration with other languages, especially
  C and C++, is essential.  We are working on addressing this issue.  The
  solutions may not be part of the Dylan language proper.


From info-dylan-request Wed Dec  2 11:18:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19019; Wed, 2 Dec 92 11:18:19 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19013; Wed, 2 Dec 92 11:18:18 -0500
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01382; Wed, 2 Dec 92 11:27:08 -0500
	for info-dylan@cambridge.apple.com
Received: from ontologic.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA23092; Wed, 2 Dec 92 11:07:41 -0500
Message-Id: <9212021607.AA23092@uu.psi.com>
Received: from capricorn.ARPA by ontos AA02474; Wed, 2 Dec 92 11:02:51 EST
Received: by capricorn AA16232; Wed, 2 Dec 92 11:02:48 EST
Date: Wed, 2 Dec 92 11:02:48 EST
From: Bryan Lockwood <ontologic!capricorn!lockwood@uu.psi.com>
To: info-dylan@cambridge.apple.com
Subject: request to be added to the mailing list

My mailing address is lockwood@ontos.com. I've got the book on Dylan,
and I'd like to keep up on the latest developments.

****** REPLY TO: lockwood@ontos.com  mail header may be incorrect
Bryan Lockwood               | ONTOS, Inc., 3 Burlington Woods
lockwood@ontos.com           | Burlington, MA 01803
uunet!uupsi!ontos!lockwood   | (617) 272-8101      (Fax)
(800) 388-7110 x291 (Direct) | (617) 272-7110 x291 (Front desk)
--

From info-dylan-request Wed Dec  2 12:15:50 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19637; Wed, 2 Dec 92 12:16:01 -0500
Received: from alink-gw.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19631; Wed, 2 Dec 92 12:15:50 -0500
Received: by alink-gw.apple.com (5.65/27-Sep-1991-eef)
	id AA08161; Wed, 2 Dec 92 09:12:55 -0800
	for 
Date: 02 Dec 92 17:07 GMT
From: MADA@AppleLink.Apple.COM (MADA Admin, Steve Mann,PAS)
Subject: Call for Authors
To: INFO-DYLAN@CAMBRIDGE.APPLE.COM
Cc: MADA.EDITOR@AppleLink.Apple.COM (MADA Editor, M E Califf,IVC)
Message-Id: <723316388.1703115@AppleLink.Apple.COM>

MADA is looking for authors for FrameWorks, our bimonthly technical journal.
For those of you not familiar with MADA (formerly the MacApp Developers
Association), we are a nonprofit services organization dedicated to promoting
object-oriented technologies.  Because of our roots, our membership has strong
interests in the Macintosh and MacApp, but we are actively expanding the scope
of our activities.
 
We are interested in articles about all object-oriented technologies and
languages--technical tips, product reviews, intermediate and advanced
tutorials, and other technical subjects.  Our readers are primarily serious,
advanced programmers, with a strong interest in the latest and best OO
technologies.  We're specifically interested in finding authors that are fluent
in LISP, SmallTalk, and particularly Dylan.  Authors need not be previously
published, but we prefer writers who are technically competent, enthusiastic,
and can develop coherent sentences and paragraphs. MADA pays all FrameWorks
authors.
 
Interested parties should contact:
 
    Mary Elaine Califf  at MADA.EDITOR@applelink.apple.com or
    Steve Mann          at MADA@applelink.apple.com
 
to discuss possible articles, reviews, or article series, or to find out more
about MADA.
 
 

From info-dylan-request Wed Dec  2 13:57:03 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20615; Wed, 2 Dec 92 13:57:05 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20611; Wed, 2 Dec 92 13:57:03 -0500
Received: from helen.oit.itd.umich.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06050; Wed, 2 Dec 92 14:06:03 -0500
	for info-dylan@cambridge.apple.com
Received: by oit.itd.umich.edu (4.1/1123-1.0(us))
	id AA01951; Wed, 2 Dec 92 13:58:28 EST
Date: Wed, 2 Dec 92 13:58:28 EST
From: Kenneth Knight <krk@oit.itd.umich.edu>
Message-Id: <9212021858.AA01951@oit.itd.umich.edu>
To: info-dylan@cambridge.apple.com
Subject: Working with generic functions

This is a bit of a change from the message that have been posted
lately, but I can't seem to find the answer myself so here goes...
 
I am writing methods to do some basic combinatorics (permutation, r-permutation
, combinations, and so on). The problem is that I'd like to access the 'permute'
function in two ways: 1. as P(n) for permuting an entire set of objects; and,
2. as P(n,r) for permuting n objects in r subsets. I have factorial written
and it works. My problem is that from what I can tell (and what Thomas,
thank Mark Feeley for a nice embedded version) I can not create two methods
called 'permute' with different number of parameters. The param-lists are
not congruent. I would very much like to call both of the functions 'permute'
but I do not want the aggrivation of having to type (permute 6 6) to find out
how many permutations are in a 6 objet set. Is there a way I can manage this?

  ** Ken **

From moon Wed Dec  2 20:44:59 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25305; Wed, 2 Dec 92 20:45:04 -0500
Received: from dynamic-3.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25287; Wed, 2 Dec 92 20:44:59 -0500
Message-Id: <9212030144.AA25287@cambridge.apple.com>
Date: Wed, 02 Dec 92 20:47:18 EST
From: moon (David A. Moon)
To: Kenneth Knight <krk@oit.itd.umich.edu>
Subject: Re: Working with generic functions
Cc: info-dylan@cambridge.apple.com

> Date: Wed, 2 Dec 92 13:58:28 EST
> From: Kenneth Knight <krk@oit.itd.umich.edu>
>  
> I am writing methods to do some basic combinatorics (permutation, r-permutation
> , combinations, and so on). The problem is that I'd like to access the 'permute'
> function in two ways: 1. as P(n) for permuting an entire set of objects; and,
> 2. as P(n,r) for permuting n objects in r subsets. I have factorial written
> and it works. My problem is that from what I can tell (and what Thomas,
> thank Mark Feeley for a nice embedded version) I can not create two methods
> called 'permute' with different number of parameters. The param-lists are
> not congruent. I would very much like to call both of the functions 'permute'
> but I do not want the aggrivation of having to type (permute 6 6) to find out
> how many permutations are in a 6 objet set. Is there a way I can manage this?

Use keyword arguments.

(define-method permute (n #key (r n)) ...)
(permute 6)
(permute 6 r: 4)

You might want to choose a more mnemonic keyword name than r.

From info-dylan-request Thu Dec  3 02:15:19 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03817; Thu, 3 Dec 92 02:15:22 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03812; Thu, 3 Dec 92 02:15:19 -0500
Received: from gmdzi.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07731; Thu, 3 Dec 92 02:24:15 -0500
	for info-dylan@cambridge.apple.com
Received: from hera.gmd.de (hera) by gmdzi.gmd.de with SMTP id AA07053
  (5.65c/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Thu, 3 Dec 1992 08:17:49 +0100
Received: from qw3.gmd.de by hera.gmd.de with SMTP id AA23145
  (5.65c/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Thu, 3 Dec 1992 08:07:13 +0100
Date: Thu, 3 Dec 1992 08:07:13 +0100
From: Tom Gordon <thomas@hera.gmd.de>
Message-Id: <199212030707.AA23145@hera.gmd.de>
To: info-dylan@cambridge.apple.com
Subject: Re: Monthly FAQ Posting
Cc: hertz@hera.gmd.de, bolz@hera.gmd.de


> From alms@cambridge.apple.com Wed Dec  2 17:13:57 1992
...

> Dylan(tm) FAQ December 2, 1992
> 
> This memo answers questions which are frequently asked about the Dylan
> programming language.
>
> * Will there be Apple products based on Dylan?
> 
>   Apple has not announced any use of Dylan in products.
> 
> * +++ Is Dylan related to the Apple PDA project called Newton?
> 
>   No. Dylan is being created by Apple's Advanced Technology Group, and no
>   product-specific implementations of Dylan have been announced yet.
 

This is a surprise and a disappointed.  Am I mistaken, or didn't Scully
announce Dylan at the same time as Newton, and specifically claim that 
Dylan would be the programming language for Newton?  This is certainly the
interpretation that has been promulgated in some magazines, such as Byte.

And now I must read here that Dylan is not even "related" to Newton, let
alone intended to be its principal programming language.

One of the main reasons many of us have been interested in Dylan, as opposed
to some other Lisp dialect, is because of the major committed to Dylan 
implied by its choice for the Newton range of products.   Now I'm left
wondering just how strong Apple's commitment to Dylan really is.  Will
it be another non-start, like Apple's version of Smalltalk?

Tom Gordon
GMD


From info-dylan-request Thu Dec  3 03:45:40 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05681; Thu, 3 Dec 92 03:45:43 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05676; Thu, 3 Dec 92 03:45:40 -0500
Received: from sol.UVic.CA by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07890; Thu, 3 Dec 92 03:54:41 -0500
	for info-dylan@cambridge.apple.com
Received: from [128.189.76.146] (mac2LIBR060.esg.comp.UVic.CA) by sol.UVic.CA (4.1/SMI-4.0.3-UVic-2.38TMX)
	id AA19500; Thu, 3 Dec 92 00:48:35 PST
Date: Thu, 3 Dec 92 00:48:34 PST
Message-Id: <9212030848.AA19500@sol.UVic.CA>
To: info-dylan@cambridge.apple.com
From: marykuca@sol.UVic.CA (Brent Marykuca)
Subject: Re: Monthly FAQ Posting

>> From alms@cambridge.apple.com Wed Dec  2 17:13:57 1992
>...
>
>> Dylan(tm) FAQ December 2, 1992
>> 
>>...
>> * +++ Is Dylan related to the Apple PDA project called Newton?
>> 
>>   No. Dylan is being created by Apple's Advanced Technology Group, and no
>>   product-specific implementations of Dylan have been announced yet.
>
>This is a surprise and a disappointed.  Am I mistaken, or didn't Scully
>announce Dylan at the same time as Newton, and specifically claim that 
>Dylan would be the programming language for Newton?

I am certain that this is not the case.  I'm sure I read nearly every news
release and promotional blurb about Newton and never saw any mention of
Dylan.

>And now I must read here that Dylan is not even "related" to Newton, let
>alone intended to be its principal programming language.

From things that I have read around the net and elsewhere, Newton will be
released soon, i.e. within the next three or four months.  From what I read
here, Dylan, while largely specified, is still brand-new.  It seems
unlikely that Apple would base a "revolutionary" technology like Newton on
(sorry, everyone) an untested and unproven language.

>One of the main reasons many of us have been interested in Dylan, as opposed
>to some other Lisp dialect, is because of the major committed to Dylan 
>implied by its choice for the Newton range of products.

I don't want to get into a discussion of Newton in this forum, except to
say that it would probably go nowhere if you could only program it in
Dylan.

>Now I'm left
>wondering just how strong Apple's commitment to Dylan really is.  Will
>it be another non-start, like Apple's version of Smalltalk?
>
I wonder about this too.  As a C/C++ programmer just looking into Dylan for
kicks, I am finding that it's not nearly as bad (forgive me) as I thought
it would be.  I am looking forward to seeing an implementation of Dylan
with reasonable performance, but fear that it may not ever arrive.

>
>Tom Gordon
>GMD


___________________________________________________________________________
Brent Marykuca:::::::Computing User Services/Education Services Group, UVic
Apple Research Partnership Program::::::UVic Department of Computer Science


From info-dylan-request Thu Dec  3 05:10:17 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07284; Thu, 3 Dec 92 05:10:22 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07279; Thu, 3 Dec 92 05:10:17 -0500
Received: from gmdzi.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08080; Thu, 3 Dec 92 05:19:18 -0500
	for info-dylan@cambridge.apple.com
Received: from hera.gmd.de (hera) by gmdzi.gmd.de with SMTP id AA06543
  (5.65c/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Thu, 3 Dec 1992 11:12:48 +0100
Received: from qw3.gmd.de by hera.gmd.de with SMTP id AA25096
  (5.65c/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Thu, 3 Dec 1992 11:02:09 +0100
Date: Thu, 3 Dec 1992 11:02:09 +0100
From: Tom Gordon <thomas@hera.gmd.de>
Message-Id: <199212031002.AA25096@hera.gmd.de>
To: info-dylan@cambridge.apple.com
Subject: Re: Monthly FAQ Posting


> From: marykuca@sol.UVic.CA (Brent Marykuca)
> Subject: Re: Monthly FAQ Posting
> Content-Length: 2215
> 
> >This is a surprise and a disappointed.  Am I mistaken, or didn't Scully
> >announce Dylan at the same time as Newton, and specifically claim that 
> >Dylan would be the programming language for Newton?
> 
> I am certain that this is not the case.  I'm sure I read nearly every news
> release and promotional blurb about Newton and never saw any mention of
> Dylan.
> 

I may have been mistaken about Byte, but the German language MACup magazine's
report on Newton was very clear (MACup, September, 1992, page 58):

"Dylan -- Newton's Programming Language

Newton's operating system and applications are specified in a new object-
oriented dynamic language called Dylan ..."

> 
> >From things that I have read around the net and elsewhere, Newton will be
> released soon, i.e. within the next three or four months.  From what I read
> here, Dylan, while largely specified, is still brand-new.  It seems
> unlikely that Apple would base a "revolutionary" technology like Newton on
> (sorry, everyone) an untested and unproven language.
> 

I too had wondered how it is possible that Newton would be released before 
Dylan is finished, but we do know that Apple has several implementations
of Dylan and that they are trying to assure that changes to the language
are minimal and upwards-compatible.  Also, perhaps the current Newton software
really is only "specified" in Dylan, but implemented in, perhaps,
assembly language.  Finally, I do not agree that Dylan is "untested and 
unproven", as it is a conservative consolidation of well-tested design
concepts from Scheme, Smalltalk and CLOS.  There is nothing revolutionary
about Dylan, except Apple's intention to really commit to a Scheme-like
language for a product like Newton (if this would only be the case).

> 
> I don't want to get into a discussion of Newton in this forum, except to
> say that it would probably go nowhere if you could only program it in
> Dylan.
> 

Just as there are a multitude of programming environments for the Mac, 
even though Pascal was originally chosen as its native language, so
to would I expect there to be other alternatives for Newton, at least with
time.   

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

Aside from the non-authoritative report in MACup, there is considerable
circumstantial evidence supporting the claim that Newton and Dylan *are*
very well related:

1) Larry Tesler, an Apple Vice-President, wrote the forward to the Dylan
book, and just also happens to be one of the leaders of the Newton
group (also according to MACup).   Larry was also one of the prominent
members of the Smalltalk group at Xerox before going to Apple, and was, if
I remember my history correctly, the father of the Dynabook idea, which
lead to Newton.   Smalltalk was a central part of the Dynabook idea, so
it would be natural for Dylan to play the same role for Newton.

2) Apple's choice of the ARM610 processor for the Newton was motivated by,
among other factors, the need for on-chip support for garbage collection.
Why, if programmer's are going to be responsible for memory management,
using languages like C++?

To sum up, I do not want to continue to spread rumours, which I didn't
start, about Dylan's role for Newton.   I have no idea why Apple is 
hedging its bet here.  Perhaps there are some internal wars at Apple
between Dylan and C++ factions.  Who knows.  But I am concerned and
somewhat worried.   It would be comforting to hear some announcement soon
about just what role Apple intends Dylan to play in future Apple
products.

Tom Gordon
GMD

From info-dylan-request Thu Dec  3 05:34:00 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07853; Thu, 3 Dec 92 05:34:05 -0500
Received: from jumbo.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07847; Thu, 3 Dec 92 05:34:00 -0500
Received: from apple.com by jumbo.apple.com with SMTP (5.64/26-Oct-1992-eef)
	id AA23033; Thu, 3 Dec 92 02:44:24 PST
	for info-dylan@cambridge.apple.com
Received: from pamir.inria.fr by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA14555; Thu, 3 Dec 92 02:36:57 -0800
	for info-dylan@cambridge.apple.com
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 03 Dec 92 11:35:22+0100
X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
	Relayed; 03 Dec 92 11:36:00 GMT
Date: 03 Dec 92 11:36:00 GMT
From: Ranson <ranson@LANNION.cnet.fr>
Message-Id: <m0mxDvV-00000bC(a)lamd01>
To: info-dylan@cambridge.apple.com, thomas@hera.gmd.de
Subject: Re: Monthly FAQ Posting

I don't have any official info on the matter, but here are a few tidbits:

- Obviously, the first Newtons cannot be Dylan-based. The Newton projet is
several years old, and I don't think Apple had a running implementation of
Dylan a year ago.

- I have read somewhere that a *future* generation of Newtons will use Dylan.
Judging from the Dylan specs and the foreword to the Dylan book, it seems quite
likely.

- A few weeks ago, there was a job offer from Apple, for a position related to
*both* Newton and Dylan.

So, there is still hope...
     Daniel.



From info-dylan-request Thu Dec  3 09:51:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18636; Thu, 3 Dec 92 09:51:12 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18632; Thu, 3 Dec 92 09:51:11 -0500
Received: from gmdzi.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08576; Thu, 3 Dec 92 10:00:15 -0500
	for info-dylan@cambridge.apple.com
Received: from hera.gmd.de (hera) by gmdzi.gmd.de with SMTP id AA23903
  (5.65c/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Thu, 3 Dec 1992 15:52:19 +0100
Received: from qw3.gmd.de by hera.gmd.de with SMTP id AA09057
  (5.65c/IDA-1.4.4); Thu, 3 Dec 1992 15:41:11 +0100
Date: Thu, 3 Dec 1992 15:41:11 +0100
From: Tom Gordon <thomas@hera.gmd.de>
Message-Id: <199212031441.AA09057@hera.gmd.de>
To: info-dylan@cambridge.apple.com, thomas@hera.gmd.de, ranson@LANNION.cnet.fr
Subject: Correction: Dynabook and Alan Kay


Correction:   Alan Kay, not Larry Tesler, is the father of the Dynabook
idea.  Sorry for the misinformation. Does anyone know what Alan Kay is
up to these days?

Tom Gordon

From info-dylan-request Thu Dec  3 11:55:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23925; Thu, 3 Dec 92 11:55:12 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23921; Thu, 3 Dec 92 11:55:11 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08904; Thu, 3 Dec 92 12:04:18 -0500
	for info-dylan@cambridge.apple.com
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA29149; Thu, 3 Dec 92 11:02:11 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA09297; Thu, 3 Dec 1992 10:57:00 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA01415; Thu, 3 Dec 92 10:58:10 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA06311; Thu, 3 Dec 92 10:58:10 CST
Date: Thu, 3 Dec 92 10:58:10 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9212031658.AA06311@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: Software Development Progress


The conversation about Dylan/Newton was really interesting.  Thanks to
the participants for some good debate.  I'd like to use that as a
springboard for some issues about Dylan I've been pondering.  

One of the nice things about Smalltalk is that it is has a well
conceived development environment BUILT-IN.  Development environments
for C/C++ are big business.  That's because the systems of any
complexity written in these languages are huge and require tools just
to keep track of them.  But Lisp is not that much better.  I have been
a Lisp programmer on very large systems and it is quite apparent that
we could really use a better strategy for maintaining and modifying
these systems.  

The Smalltalk approach is a good one.  But I'm not convinced it's the
best one.  There are plenty of good ideas for how to make software
easier and more modular.  Look in some of the Software Technology
papers or in the Electronic CAD industry where they have even worse
headaches than C/C++ programmers.

I don't think Dylan can be more than "yet another language" if these
issues aren't addressed.  In my estimation, the MAC revolutionized the
operating system world.  It took years, but finally the rest of the
industry is getting in line -- as evidenced by MicroSoft Windows, Open
Windows, etc.  (Unix is glitch in that progress.  But I hope "Pink"
can fix that.)  In retrospect, it seems to me (though I'm an invalid
historian) like Apple just took its cues from the existing research
(ala Smalltalk) and built on the best ideas.

Not just their operating system's easy functionality but it's COMPLETE
interconnectedness with the machine.  If Apple can do the same thing
for software development that it did for operating systems then, it
may still take years, but hopefully the rest of the industry will
again get in line.  The latch-key technology of the new DUO-DOCK
system is spawned from this mold.  How about a latch-key style
technology for software development?

-- Rob.


PS.  You can somewhat gather my position on patents from my comments.
Which needless to say does not reflect the opinions of the company I
work for.


PSS. What about latch-key OODBs and Interface Managers, too?

From cassels Thu Dec  3 12:22:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24777; Thu, 3 Dec 92 12:22:58 -0500
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24772; Thu, 3 Dec 92 12:22:53 -0500
Message-Id: <9212031722.AA24772@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Thu, 3 Dec 1992 12:27:36 -0400
To: info-dylan@cambridge.apple.com, farrow@stephanie.hc.ti.com (Rob Farrow)
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: Software Development Progress

>The conversation about Dylan/Newton was really interesting.  Thanks to
>the participants for some good debate.  I'd like to use that as a
>springboard for some issues about Dylan I've been pondering.  
>
>One of the nice things about Smalltalk is that it is has a well
>conceived development environment BUILT-IN.  Development environments
>for C/C++ are big business.  That's because the systems of any
>complexity written in these languages are huge and require tools just
>to keep track of them.  But Lisp is not that much better.  I have been
>a Lisp programmer on very large systems and it is quite apparent that
>we could really use a better strategy for maintaining and modifying
>these systems.  

There is some discussion of our (the Apple Cambridge Dylan group) thinking
in the preface to the Dylan book.  We are certainly aware that development
environments are important in the process of building systems, and are
building an environment for our implementations of Dylan.  Other groups
building Dylan implementations are focussing on environment issues as well.

Some of us believe that the quality of the environment is more important to
programmer productivity than the choice of language.  For us, Dylan the
language is simply an enabler for a superior environment.  (I note the
problems people have had with producing good C++ development environments,
and the language restrictions/workarounds required.)


I'm interested in your experiences in building large Lisp systems.  No
doubt your input could help us design a better development environment.

 - Which development environment(s) have you used?
 - What helped most in that environment?
 - What that was present in the environment got in your way?
 - What that wasn't present would have helped significantly?


From info-dylan-request Thu Dec  3 12:24:54 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24839; Thu, 3 Dec 92 12:24:56 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24833; Thu, 3 Dec 92 12:24:54 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09122; Thu, 3 Dec 92 12:34:00 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA01433@relay.tek.com>; Thu, 3 Dec 92 09:09:40 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA27430; Thu, 3 Dec 92 09:10:26 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA19947; Thu, 3 Dec 92 09:01:17 PST
Date: Thu, 3 Dec 92 09:01:17 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9212031701.AA19947@goldfish.MITRON.TEK.COM>
To: info-dylan@cambridge.apple.com
In-Reply-To: Tom Gordon's message of Thu, 3 Dec 1992 08:07:13 +0100 <199212030707.AA23145@hera.gmd.de>
Subject: Monthly FAQ Posting

   Date: Thu, 3 Dec 1992 08:07:13 +0100
   From: Tom Gordon <thomas@hera.gmd.de>
   > From alms@cambridge.apple.com Wed Dec  2 17:13:57 1992
   ...

   > Dylan(tm) FAQ December 2, 1992
   > 
   > This memo answers questions which are frequently asked about the Dylan
   > programming language.
   >
   > * Will there be Apple products based on Dylan?
   > 
   >   Apple has not announced any use of Dylan in products.
   > 
   > * +++ Is Dylan related to the Apple PDA project called Newton?
   > 
   >   No. Dylan is being created by Apple's Advanced Technology Group, and no
   >   product-specific implementations of Dylan have been announced yet.


   This is a surprise and a disappointed.  Am I mistaken, or didn't Scully
   announce Dylan at the same time as Newton, and specifically claim that 
   Dylan would be the programming language for Newton?  This is certainly the
   interpretation that has been promulgated in some magazines, such as Byte.

   And now I must read here that Dylan is not even "related" to Newton, let
   alone intended to be its principal programming language.

   One of the main reasons many of us have been interested in Dylan, as opposed
   to some other Lisp dialect, is because of the major committed to Dylan 
   implied by its choice for the Newton range of products.   Now I'm left
   wondering just how strong Apple's commitment to Dylan really is.  Will
   it be another non-start, like Apple's version of Smalltalk?


I read nothing in the FAQ that should disappoint you. This part of the
FAQ is more interesting for what it doesn't say than what it does say.
The part about the relationship between Dylan and Newton simply says
they are being created by two different groups within Apple. In that
sense only, it says, they are not related. It doesn't say that the
Newton group is not using or interested in using Dylan.

It is useful to read between the lines as well as the lines
themselves.
--
Patrick Logan         patl@goldfish.mitron.tek.com
Mitron Corporation    (503) 690-8350    FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006

From info-dylan-request Thu Dec  3 13:52:40 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27366; Thu, 3 Dec 92 13:53:19 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27347; Thu, 3 Dec 92 13:52:40 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09590; Thu, 3 Dec 92 13:58:22 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.lancaster.central1; Thu, 3 Dec 1992 17:29:30 +0000
From: Mr R Johnson <erb008@central1.lancaster.ac.uk>
Message-Id: <28753.9212031729@central1.lancaster.ac.uk>
Subject: unsubscribe
To: info-dylan@cambridge.apple.com
Date: Thu, 3 Dec 92 17:29:28 GMT
X-Mailer: ELM [version 2.3.010 PL11]

I've tried the info-request id and the admin id for 
this list but failed to stem the flow.
Can somebody please stop the Dylan messages coming please.

Robin

___________________________________________________________________________
Robin Johnson
Dept Educational Research, University of Lancaster, Lancaster, LA1 4YL, UK
Tel 0524 65201 x 2893              Fax 0524 844788  
JANET: erb008@lancaster            BITNET/EARN: erb008@lancaster.ac.uk
Internet: erb008@lancaster.ac.uk   uucp: erb008%lancaster@ukc
----------------------------------------------------------------------------

From info-dylan-request Thu Dec  3 14:34:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28575; Thu, 3 Dec 92 14:34:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28571; Thu, 3 Dec 92 14:34:11 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09778; Thu, 3 Dec 92 14:43:19 -0500
	for info-dylan@cambridge.apple.com
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA05449; Thu, 3 Dec 92 13:41:13 CST
Received: from moby.csc.ti.com (moby) by tilde.csc.ti.com id AA16350; Thu, 3 Dec 1992 13:36:03 -0600
Received: by moby.csc.ti.com (4.1/SMI-4.1)
	id AA10576; Thu, 3 Dec 92 13:36:02 CST
Date: Thu, 3 Dec 92 13:36:02 CST
From: ford@moby.csc.ti.com (Steve Ford)
Message-Id: <9212031936.AA10576@moby.csc.ti.com>
To: info-dylan@cambridge.apple.com
Cc: ford@moby.csc.ti.com
Subject: Newton and Dylan


PC Week August 17 1992

"the Cupertino, Calif., company also plans to use it to develop applications
for its Newton personal digital assistant, officials said.

MacWEEK June 22 1992

"Apple told developers gathered at a closed-session briefing here last week
that the new language would let them build compact applications on many
platforms, including the Macintosh, Unix workstations and the company's
recently announced Newton Personal Digital Assistants, sources said."

Release 1.0 June 15 1992

"Newton, by contrast, is implemented in C and C++ and runs on the ARM 610 RISC
chip (for now).  It will eventually offer its own development tools and 
scripting language, but Apple is vague on that right now.  One candidate is
Dylan, a so-far-experimental LISP-like language user development at Apple's
Advanced Technology Group.  Its main advantage over LISP is that it is a
language, not an environment, and can work easily in standard operating
environments (or in Newton's)."

PC Week June 1 1992

"Earlier in the week, Apple revealed that its Advanced Technology Group had
developed Dylan, a programming language for developing PDA applications."

related articles in:

San Jose Mercury News May 27 1992

MacWEEK Sept 14 1992

AI Expert July 1992


From straz Thu Dec  3 14:35:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28642; Thu, 3 Dec 92 14:35:23 -0500
Received: from [90.223.0.88] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28636; Thu, 3 Dec 92 14:35:18 -0500
Message-Id: <9212031935.AA28636@cambridge.apple.com>
Date: Thu, 3 Dec 1992 14:37:28 -0500
To: Tom Gordon <thomas@hera.gmd.de>
From: Steve Strassmann <straz@cambridge.apple.com>
Subject: Re: Monthly FAQ Posting
Cc: info-dylan@cambridge.apple.com

>Date: Thu, 3 Dec 1992 11:02:09 +0100
>From: Tom Gordon <thomas@hera.gmd.de>
>To: info-dylan@cambridge.apple.com
>Subject: Re: Monthly FAQ Posting
>
>I may have been mistaken about Byte, but the German language MACup magazine's
>report on Newton was very clear (MACup, September, 1992, page 58):

I'm sure MACup magazine is a very nice magazine, but they are not authorized
to speak on Apple's behalf about Newton plans. For that matter, I'm not authorized
either. That's why we just want to talk about Dylan on this list.

>Correction:   Alan Kay, not Larry Tesler, is the father of the Dynabook
>idea.  Sorry for the misinformation. Does anyone know what Alan Kay is
>up to these days?

Alan Kay is an Apple Fellow, and aside from having an active lecture
schedule, oversees advanced research projects within Apple. Most notable is
his Vivarium project, which concerns learning environments for young children.



From info-dylan-request Thu Dec  3 15:57:20 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01382; Thu, 3 Dec 92 15:57:21 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01378; Thu, 3 Dec 92 15:57:20 -0500
Received: from gate.demon.co.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10275; Thu, 3 Dec 92 16:06:29 -0500
	for info-dylan@cambridge.apple.com
Received: from quercus.demon.co.uk by gate.demon.co.uk id aa02502;
          3 Dec 92 20:51 GMT
Date: Thu, 3 Dec 1992 20:59:11 +0000
To: info-dylan@cambridge.apple.com
From: Howard@quercus.demon.co.uk
Subject: Newton and Dylan
Message-Id:  <9212032052.aa02502@gate.demon.co.uk>

I am not sure where this thread is heading, nor am I sure whether it can
justify its bandwidth.

The Dylan FAQ quite clearly discourages people from assuming that Dylan is
dependent upon Newton, or vice versa.  A number of (respected and
respectable!) Apple employees have spelled out that they are not authorised
to make any further comment.  Both products are clearly important and
sensitive issues, and neither has been released.

So why the desperate need to try to draw an Apple employee to agree to an
association?  Neither do I see it fulfilling any useful purpose - if Dylan
implementations do become successful, I am sure that Dylan will be offered
on every hardware platform possible, including Newton.

In the meantime, I for one would rather get on with the here and now of
discussing Dylan, leaving matters Newton to private discussions with the
Newton Developer support scheme.  Please (and remembering that this is a
group mail list, and not a newsgroup)?

Howard.
Howard Oakley,                      * Howard@quercus.demon.co.uk
EHN & DIJ Oakley, Brooklands Lodge, * AppleLink UK0392
Park View Close, Wroxall, Ventnor,  * CompuServe 70734,120
Isle of Wight UK PO38 3EQ           * Tel +44 983 853605, fax 853253 


From info-dylan-request Fri Dec  4 00:01:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13073; Fri, 4 Dec 92 00:01:02 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13069; Fri, 4 Dec 92 00:01:01 -0500
Received: from uu3.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11170; Fri, 4 Dec 92 00:10:10 -0500
	for info-dylan@cambridge.apple.com
Received: from panix.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AB11210; Thu, 3 Dec 92 23:47:57 -0500
Received: by panix.com (5.64/A/UX-2.01-AMR)
	id AA05341; Thu, 3 Dec 92 23:46:19 EST
From: fhd@panix.com (Frank Deutschmann)
Message-Id: <9212040446.AA05341@panix.com>
Subject: Dylan rather than CL -- why?
To: info-dylan@cambridge.apple.com
Date: Thu, 3 Dec 92 23:46:18 EST


I'm new to Dylan and this group (just finished skimming the
Dylan book), so please accept my appologies if this is a FAQ or
"taboo" ( :-) ) subject!

In Ike Nassi's Preface to the Dylan book, he says something along the
lines of Common Lisp being for exploratory programming with some
delivery capability, and Dylan being aimed at delivery with some
exploratory capability.  I would really like some clarification of
this statement from someone with Lisp/CLOS, Scheme, and Dylan
experience; my intent is certainly not to provoke a language war, but
rather as Dylan is "the new kid on the block" (so to speak), I would
like to know what its benefits are over the languages I'm experienced
with.

My main questions are:
	1) Is Dylan simply a slimmed down CLOS, stripped of hoggish
features?
	2) What is the motive for a "smaller" language?  Is the
prime motivator run-time overhead, developer learning curve, or
something else?
	3) Why seperate the developmet environment from the language?
	This is the most difficult for me to understand: OO languages that did
not specify their development environment (C++, Ada, Prolog [not OO])
are now stuck with a multitude of development environment, each with
its own set of quirks and developer learning curve.  While most have
some commonality (the Smalltalk-lik "browser" seems to have caught on,
to say the least), each environment is incompatabile with the others
for a particular language, requiring that developers spend time
re-learning the development environment when they switch (which
happens often, as developers move from project to project).
	It also seems to me that those languages which have attached
environments (Smalltalk, Objective-C, and the Symbolics environment [though not
strictly *A language specification*]) have had the biggest impact on
the programming world: I believe that it is the close relationship
between language and development environment which has made these
language systems, and the OO concepts they introduced, change the way
the world thinks about systems development.
	So when the development environment is so important to end
product, and the language is "oriented toward delivery," why separate
the environment from the language?  Clearly, one of the arguments may
well be that to keep memory footprint small, you don't want to deliver
the development environment with the product.  But that seems a rather
irrelevant argument; virtually all current Lisp environments have the
capability to deliver "stripped" systems.  In addition, where the
target hardware can support it, it is nice to have at least some of
the development environment present, to allow end-user programming and
live system debugging.
	A more significant argument which I could forsee would be the
desire not to dictate a paradigm for programming in a group
environment.  One of the most significant drawbacks to Smalltalk,
IMHO, is its lack of support for large scale projects which involve
many developers; while third parties have developed environments which
provide improved support, that, of course, eliminates some of the
benefits of having a standard development environment.  I would think
Dylan would provide far more benefit if a standard development
environment, which has implicit support for large-scale development
effots, had been specified with the language.

	4) What about compatability with (meaning "linkage to")
existing languages, such as Lisp, C, Scheme, Prolog?  The Dylan book,
so far as I can see, make no mention of capability for inter-language
calls, though that would seem to be a real nice feature to have,
especially on systems short of horsepower (where you would probably
like to drop into C for some tasks).  I can't help mentioning the
Poplog envionment here: with all languages easily interacting, the
"synergy" can really help get systems built, with each language used
for what it does best.  I think that the continued preocupation to
come up with one do-all best general purpose language has been a real
step backwards -- better to have some "killer" concepts which
languages stick to, with languages aimed at specific problems and tied
together with a powerfull development environment.

Interested to hear you comments,
-frank

From info-dylan-request Fri Dec  4 00:15:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13461; Fri, 4 Dec 92 00:15:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13457; Fri, 4 Dec 92 00:15:53 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11239; Fri, 4 Dec 92 00:25:04 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA11005; Fri, 4 Dec 92 00:19:12 -0500
Received: from casimir.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 001824.7587; Fri, 4 Dec 1992 00:18:24 EST
Received: by casimir.lanu.ca.us (Smail3.1.28.1 #4)
	id m0mxUz8-000B3YC; Thu, 3 Dec 92 20:49 PST
Message-Id: <m0mxUz8-000B3YC@casimir.lanu.ca.us>
To: info-dylan@cambridge.apple.com
Subject: Re : Dylan and Newton
Date: Thu, 03 Dec 92 20:49:50 -0800
From: Michael Maciag <mmm@casimir.lanu.ca.us>

I was told by an Apple employee that the current implementation of
Dylan has proven "too slow" for the Newton. That would seem hardly
suprising. The idea of TWO leading-edge technologies in one
product seemed extremely {aggressive | attractive | foolish}.
=========================================================================
Michael Maciag		mmm@casimir.lanu.ca.us		uunet!casimir!mmm
=========================================================================

From info-dylan-request Fri Dec  4 06:54:56 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22731; Fri, 4 Dec 92 06:55:00 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22726; Fri, 4 Dec 92 06:54:56 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11664; Fri, 4 Dec 92 07:04:04 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Fri, 4 Dec 1992 11:51:06 +0000
Date: Fri, 4 Dec 92 11:51:36 GMT
Message-Id: <25605.9212041151@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Newton and Dylan
To: Steve Ford <ford@moby.csc.ti.com>, info-dylan@cambridge.apple.com
In-Reply-To: Steve Ford's message of Thu, 3 Dec 92 13:36:02 CST

> PC Week August 17 1992

> Its main advantage over LISP is that it is a language, not an environment, 
> and can work easily in standard operating environments (or in Newton's)."

0. Dylan is a dialect of Lisp.

1. There are a number of Lisps that are languages, not environments.
   Moreover, the move towards being a language (not an enviroment) is
   a general trend within Lisp.  For example: EuLisp, Scheme (to a
   large extent), ISLisp (the ISO dialect).

2. Lisp's problems working in standard environments are for the most
   part not due to the environmental aspects of Lisp.  Instead, they're
   due to storage management and data representation issues.

3. It seems reasonable to say InterLisp is an environment, but how
   about Common Lisp?  To a large extent, it depends on how it's
   implemented.  Common Lisp can be packaged as a shared library
   (see WCL), and (given a suitable linker) could be linked with C
   procedures rather than being an environment into which C procedures
   were loaded.

4. Of course, there are environmental aspects to Common Lisp such as
   TRACE, COMPILE, LOAD, DESCRIBE, and (some would say) SYMBOL-FUNCTION.
   Some of them (TRACE, DESCRIBE) could be defined in a language-only
   Lisp (assuming we allow an I/O library).  Others (COMPILE-FILE,
   LOAD) are there to make it possible to define systems tools in
   Lisp in an operating system independent way.  I find it hard to
   see this as a bad thing, although it's not the only good way to
   do a Lisp.

-- jeff

From info-dylan-request Fri Dec  4 08:23:02 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25716; Fri, 4 Dec 92 08:23:03 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25711; Fri, 4 Dec 92 08:23:02 -0500
Received: from travis.csd.harris.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11798; Fri, 4 Dec 92 08:32:10 -0500
	for info-dylan@cambridge.apple.com
Received: from amber.ssd.csd.harris.com by travis.csd.harris.com (5.61/harris-5.1)
	id AA08006; Fri, 4 Dec 92 08:26:06 -0500
Received: by amber (5.61/CX/UX-5.0)
	id AA16268; Fri, 4 Dec 92 08:26:02 -0500
Date: Fri, 4 Dec 92 08:26:02 -0500
From: brent@amber.ssd.csd.harris.com (Brent W. Benson)
Message-Id: <9212041326.AA16268@amber>
To: info-dylan@cambridge.apple.com
In-Reply-To: Frank Deutschmann's message of Thu, 3 Dec 92 23:46:18 EST <9212040446.AA05341@panix.com>
Subject: Dylan rather than CL -- why?

fhd@panix.com (Frank Deutschmann) writes:

> 3) Why seperate the developmet environment from the language?

Here are two reasons I feel are important, one of which you
mentioned.

	o delivery - you don't want to deliver the environment.  At
	some point you need to deliver an application and make the
	break between environment and language.  Why not specify that
	break up front?  While some Lisp systems provide ways to trim
	down a Lisp image, it's not the same as producing a .o file
	that can be linked with other languages that follow certain
	conventions.

	o flexibility - it's not clear that the same development
	environment will work on every machine that one might program
	in Dylan.  Requiring a certain type of environment might
	restrict the spread of the language (sounds like a virus or
	something :-).

I would highly recommend the article "Lisp: Good News, Bad News, How
to Win Big" by Richard Gabriel of Lucid.  It's available in LaTeX form
by anonymous ftp from bongo.garnet.cs.cmu.edu in /pub/good-bad-win.
He talks about "the right thing" approach to designing systems.  This
might correspond to producing the best possible Dylan with a perfect
integrated environment.  This project takes years to complete, but is
wonderful when it is done.  The other approach is "worse is better."
This corresponds to providing a Dylan that is easy to implement, is
flexible, and works well with other languages.  Not quite as
satisfying, but it's out there and people are using it to solve real
problems.  He ends up describing a next-generation Lisp that is very
close to Dylan.  Great article.

Brent Benson                     
Harris Computer Systems

From nassi Fri Dec  4 09:45:26 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29800; Fri, 4 Dec 92 09:45:29 -0500
Received: from nassi.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29794; Fri, 4 Dec 92 09:45:26 -0500
Message-Id: <9212041445.AA29794@cambridge.apple.com>
Date: Fri, 4 Dec 1992 09:48:44 -0500
To: info-dylan@cambridge.apple.com, fhd@panix.com (Frank Deutschmann)
From: nassi@cambridge.apple.com (Ike Nassi)
Subject: Re: Dylan rather than CL -- why?

At 11:46 PM 12/3/92 -0500, Frank Deutschmann wrote:
>In Ike Nassi's Preface to the Dylan book, he says something along the
>lines of Common Lisp being for exploratory programming with some
>delivery capability, and Dylan being aimed at delivery with some
>exploratory capability.  I would really like some clarification of
>this statement from someone with Lisp/CLOS, Scheme, and Dylan
>experience; my intent is certainly not to provoke a language war, but
>rather as Dylan is "the new kid on the block" (so to speak), I would
>like to know what its benefits are over the languages I'm experienced
>with.

I was referring to Apple's implementations of these languages in that
paragraph, not the languages per se.  It was meant to forestall any
misunderstanding that our Dylan work was meant to replace our Macintosh
Common Lisp product.

---------------------------------------------------------------------------
Ike Nassi                        | Applelink: NASSI
Phone: 617/374-5300              | Fax:   617/374-5353
                                 


From info-dylan-request Fri Dec  4 11:11:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03782; Fri, 4 Dec 92 11:12:03 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03774; Fri, 4 Dec 92 11:11:57 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12611; Fri, 4 Dec 92 11:21:04 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Fri, 4 Dec 1992 16:13:09 +0000
Date: Fri, 4 Dec 92 16:13:29 GMT
Message-Id: <28300.9212041613@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Dylan rather than CL -- why?
To: "Brent W. Benson" <brent@amber.ssd.csd.harris.com>,
        info-dylan@cambridge.apple.com
In-Reply-To: Brent W. Benson's message of Fri, 4 Dec 92 08:26:02 -0500

> fhd@panix.com (Frank Deutschmann) writes:
> 
> > 3) Why seperate the developmet environment from the language?
> 
> Here are two reasons I feel are important, one of which you
> mentioned.
> 
> 	o delivery - you don't want to deliver the environment.  At
> 	some point you need to deliver an application and make the
> 	break between environment and language.  Why not specify that
> 	break up front?

You typically don't want to deliver the _language_ either.
If you're delivering the language -- ie if users of the application
are going to me adding Lisp code -- why deprive them of useful tools?

> 	                 While some Lisp systems provide ways to trim
> 	down a Lisp image, it's not the same as producing a .o file
> 	that can be linked with other languages that follow certain
> 	conventions.

True, but not necessarily relevant.  You can compile a Lisp file to a
.o file and link it with other .o files plus a library.  This is a
possible implementation of CL.  However, the library would be large.
Smaller libraries that do not contain the development env (eg, they
would nto contain the compiler) could also be supplied.  The WCL
implementation is pretty much along these lines.

> 	o flexibility - it's not clear that the same development
> 	environment will work on every machine that one might program
> 	in Dylan. 

It's also not clear that the same I/O will not work...

Of course, Dylan the language doesn't have I/O.  But that doesn't
mean there cannot be an I/O library.

>                   Requiring a certain type of environment might
> 	restrict the spread of the language (sounds like a virus or
> 	something :-).

I agree with that part.

> I would highly recommend the article "Lisp: Good News, Bad News, How
> to Win Big" by Richard Gabriel of Lucid.

A problem with RPG's position is that be puts Common Lisp in the
"right thing" camp whereas it is in fact "worse is better" in many
respects.  For instance, no one thinks packages are the right way
to do "modules", but they're available now and work fairly well
(eg, with CL's "worse is better" macros).

Anyway, I think the main reasons for separating the language and
environment are (a) conceptual modularity and (b) to allow a wider
range of implementations (in particular, ones that include only the
language).

-- jd

From info-dylan-request Fri Dec  4 11:42:47 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05015; Fri, 4 Dec 92 11:42:50 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05008; Fri, 4 Dec 92 11:42:47 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12780; Fri, 4 Dec 92 11:51:58 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA05561@relay.tek.com>; Fri, 4 Dec 92 08:30:41 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA13778; Fri, 4 Dec 92 08:31:27 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA26793; Fri, 4 Dec 92 08:22:11 PST
Date: Fri, 4 Dec 92 08:22:11 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9212041622.AA26793@goldfish.MITRON.TEK.COM>
To: scheme@mc.lcs.mit.edu, info-dylan@cambridge.apple.com
In-Reply-To: Brent W. Benson's message of Fri, 4 Dec 92 08:26:02 -0500 <9212041326.AA16268@amber>
Subject: LISP: Good News, Bad News, How to Win Big

   Date: Fri, 4 Dec 92 08:26:02 -0500
   From: brent@amber.ssd.csd.harris.COM (Brent W. Benson)
   fhd@panix.com (Frank Deutschmann) writes:
   >> 3) Why seperate the developmet environment from the language?

   > Here are two reasons I feel are important, one of which you
   > mentioned.

   >        o delivery - you don't want to deliver the environment.  At
   >        some point you need to deliver an application and make the
   >        break between environment and language.  Why not specify that
   >        break up front?  While some Lisp systems provide ways to trim
   >        down a Lisp image, it's not the same as producing a .o file
   >        that can be linked with other languages that follow certain
   >        conventions.

Some applications are better when the environment is included in the
delivery. The most prominent example may be GNU Emacs.

   >        o flexibility - it's not clear that the same development
   >        environment will work on every machine that one might program
   >        in Dylan.  Requiring a certain type of environment might
   >        restrict the spread of the language (sounds like a virus or
   >        something :-).

I agree that it isn't necessary (at this time, anyway) to make too
many requirements about the development environment. Certainly
developing using a Newton-like device, it would have to be different
in some ways from developing using a Mac IIfx. At the same time, I
would probably prefer to develop applications for a Newton-like device
as well as for Macintosh using the Mac IIfx within the same
environment.

   > I would highly recommend the article "Lisp: Good News, Bad News, How
   > to Win Big" by Richard Gabriel of Lucid.  It's available in LaTeX form
   > by anonymous ftp from bongo.garnet.cs.cmu.edu in /pub/good-bad-win.

GNU Emacs is an interesting example in regard to this paper. It is
very close to being "the right thing" and it has spread on top of the
viruses that are Unix and C.

I think this is because it corresponds to the point from my previous
post to the scheme list: it fits in with the Unix and C world well
enough and is a demonstrable success story of using LISP.
--
Patrick Logan         patl@goldfish.mitron.tek.com
Mitron Corporation    (503) 690-8350    FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006

From info-dylan-request Fri Dec  4 12:10:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06451; Fri, 4 Dec 92 12:10:45 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06447; Fri, 4 Dec 92 12:10:43 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12981; Fri, 4 Dec 92 12:19:54 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 4 Dec 1992 18:12:29 +0100
Received: by miles.ircam.fr, Fri, 4 Dec 1992 18:12:25 +0100
Date: Fri, 4 Dec 1992 18:12:25 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212041712.AA00208@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: collection classes

I've implemented the collection classes and have the following wish list:

NEW <SEQUENCE> GENERIC-FUNCTION'S

 The following function seems indispensible to me:

 (define-generic-function position (sequence element #key test count))

 I suggest adding the following function to the offered set functions:

 (define-generic-function difference (sequence1 sequence2 #key test)) 

 The following insertion function's are very useful for many sequences classes
 (like gap-list's).  It is difficult to write many of the sequence methods 
 because `add' does not specify where the new-element is inserted.

 (define-generic-function insert (sequence new-element insertion-position))
 (define-generic-function insert! (mutable-sequence new-element insertion-position))
 (define-generic-function insert-sequence 
     (sequence insertion-sequence insertion-position))
 (define-generic-function insert-sequence!
     (mutable-sequence insertion-sequence insertion-position))

DESTRUCTIVE <MUTABLE-SEQUENCE> FUNCTIONS

  It seems crucial to be able to destructively concatenate sequences:

  (define-generic-function concatenate! (mutable-sequence #rest rest-sequences))

  I would also like to see the following destructively functions added:

  (define-generic-function choose! (predicate mutable-sequence))
  (define-generic-function choose-by! (predicate test-sequence mutable-value-sequence))

NEW SETTER

  There seems no reason to me why a setter was not provided for `last':

  (define-generic-function (setter last) (new-value mutable-sequence)) 

NEW INIT-KEYWORD FOR <TABLE>

  I would like to see <table> take `test:' as an init-keyword:

  (make <table> #key (test =))

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-42772492
bachrach@ircam.fr


From moon Fri Dec  4 12:21:34 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07051; Fri, 4 Dec 92 12:21:37 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07045; Fri, 4 Dec 92 12:21:34 -0500
Message-Id: <9212041721.AA07045@cambridge.apple.com>
Date: Fri, 04 Dec 92 12:26:09 EST
From: moon (David A. Moon)
To: fhd@panix.com (Frank Deutschmann)
Subject: Re: Dylan rather than CL -- why?
Cc: info-dylan@cambridge.apple.com

> From: fhd@panix.com (Frank Deutschmann)
> Date: Thu, 3 Dec 92 23:46:18 EST
> 
> ....
>         4) What about compatability with (meaning "linkage to")
> existing languages, such as Lisp, C, Scheme, Prolog?  The Dylan book,
> so far as I can see, make no mention of capability for inter-language
> calls, though that would seem to be a real nice feature to have,
> especially on systems short of horsepower (where you would probably
> like to drop into C for some tasks).

We think multi-language interoperability is really important, but the
Dylan book doesn't make any provision for it.  As most people who have
read the book have noticed, it is incomplete.  However, we would not
want to put in multi-language interoperability in a way that required
every Dylan implementation to include a large suite of languages.  It
ought to remain valid to produce a system where everything is in Dylan
and no other languages are present, for situations where that is appropriate.

From info-dylan-request Fri Dec  4 12:54:03 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08664; Fri, 4 Dec 92 12:54:05 -0500
Received: from [17.201.40.10] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08659; Fri, 4 Dec 92 12:54:03 -0500
Received: from [17.201.56.61] by newton.apple.com (4.1/SMI-4.1)
	id AA27783; Fri, 4 Dec 92 09:57:06 PST
Message-Id: <9212041757.AA27783@newton.apple.com>
Date: Fri, 4 Dec 1992 09:58:03 -0800
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
From: kend@newton.apple.com (Ken Dickey)
Subject: Re: Dylan rather than CL -- why?
Cc: brent@amber.ssd.csd.harris.com, info-dylan@cambridge.apple.com

>> fhd@panix.com (Frank Deutschmann) writes:
>> 
>> > 3) Why seperate the developmet environment from the language?
...
>> 
>>       o delivery - you don't want to deliver the environment.  At
>>       some point you need to deliver an application and make the
>>       break between environment and language.  Why not specify that
>>       break up front?
>
>You typically don't want to deliver the _language_ either.
>If you're delivering the language -- ie if users of the application
>are going to me adding Lisp code -- why deprive them of useful tools?

There is no attempt at depravation. It is rather the other way around. 
Unless you draw a clear distinction between the language and the
development environment, you can never ship without the development
environment because you don't know what you can seal off.  Smalltalk-80 was
notorious for this as you could not just "ship binaries"-- you had to ship
the development environment.  Languages such as Scheme or Dylan allow you
to cleanly seal off parts of all of a system.  You can link together an
application rather than just do image snapshots (much nicer to program your
car's engine controller with 1/2 8^).

-Ken                    {note new address: kend@newton.apple.com}


From alms Fri Dec  4 14:08:37 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10592; Fri, 4 Dec 92 14:08:41 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10583; Fri, 4 Dec 92 14:08:37 -0500
Message-Id: <9212041908.AA10583@cambridge.apple.com>
Date: Fri, 4 Dec 1992 14:20:23 -0500
To: info-dylan@cambridge.apple.com,
        Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: collection classes

At  6:12 PM 12/4/92 +0100, Jonathan Bachrach wrote:
> I've implemented the collection classes and have the following wish list:
> 
> NEW <SEQUENCE> GENERIC-FUNCTION'S
> 
>  The following function seems indispensible to me:
> 
>  (define-generic-function position (sequence element #key test count))

(define-method position ((s <sequence>) (e <object>) #key (test id?)
                                                          (count 0))
  (find-key s (curry test e) skip: count))


>  I suggest adding the following function to the offered set functions:
> 
>  (define-generic-function difference (sequence1 sequence2 #key test)) 
> 
>  The following insertion function's are very useful for many sequences classes
>  (like gap-list's).  It is difficult to write many of the sequence methods 
>  because `add' does not specify where the new-element is inserted.
> 
>  (define-generic-function insert (sequence new-element insertion-position))
>  (define-generic-function insert! (mutable-sequence new-element insertion-position))
>  (define-generic-function insert-sequence 
>      (sequence insertion-sequence insertion-position))
>  (define-generic-function insert-sequence!
>      (mutable-sequence insertion-sequence insertion-position))
> 
> DESTRUCTIVE <MUTABLE-SEQUENCE> FUNCTIONS
> 
>   It seems crucial to be able to destructively concatenate sequences:
> 
>   (define-generic-function concatenate! (mutable-sequence #rest rest-sequences))
> 
>   I would also like to see the following destructively functions added:
> 
>   (define-generic-function choose! (predicate mutable-sequence))
>   (define-generic-function choose-by! (predicate test-sequence mutable-value-sequence))
> 
> NEW SETTER
> 
>   There seems no reason to me why a setter was not provided for `last':
> 
>   (define-generic-function (setter last) (new-value mutable-sequence)) 
> 
> NEW INIT-KEYWORD FOR <TABLE>
> 
>   I would like to see <table> take `test:' as an init-keyword:
> 
>   (make <table> #key (test =))

I think all the rest of these are pretty reasonable, though I worry a bit about
library bloat.


From info-dylan-request Fri Dec  4 14:44:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11529; Fri, 4 Dec 92 14:44:59 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11525; Fri, 4 Dec 92 14:44:57 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13657; Fri, 4 Dec 92 14:54:10 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 4 Dec 1992 20:47:20 +0100
Received: by miles.ircam.fr, Fri, 4 Dec 1992 20:47:18 +0100
Date: Fri, 4 Dec 1992 20:47:18 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212041947.AA00377@miles.ircam.fr>
To: piazza@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Jeff Piazza's message of Fri, 4 Dec 92 13:42:46 -0500 <9212041842.AA09975@cambridge.apple.com>
Subject: collection classes

Thanks for your feedback.  Here are some more thoughts.

   Date: Fri, 4 Dec 92 13:42:46 -0500
   From: Jeff Piazza <piazza@cambridge.apple.com>

   ....

   Also, although add and add! don't *always* specify where new-element
   is inserted, i.e., they don't specify the same location for all
   collections, nonetheless subclasses of <sequence> may specify more
   precise behavior for these functions.  Compare, for example, the
   general description of add! on p.105 and the specific description for
   deques on p.114.

The problem is that it's difficult to cleanly implement default
versions of some of the <sequence> methods without knowing where `add'
inserts it's new-element in the <sequence>.  One could I suppose use
`concatenate' to implement these default method's but using `insert'
would be easier and would also be very useful for other <sequence>
classes.  For example, <stretchy-vector>'s and <list>'s could easily
implement `insert' and I maintain, would add a very useful function.

BTW, given the way sealing goes, it appears to be very difficult to
add new functionality to <sequence>.  Thus it is prudent to consider
exactly what those functions should be.  (BBTW, I think you guys have
done a very good job.)  This is a good segue into the next response.

   Mutability, as described on pp.127-128, refers only to the ability to
   change an individual element of the collection.  These functions would
   additionally require that the sequences being modified be able to
   change their size, something that a simple-vector, for instance, can't
   do.

So how do you do `nconc' with lists?  Perhaps there should be a
<stretchy-sequence> abstract class.  It is very useful to have
`concatenate!'.  In fact, I couldn't live without it.  I would also
really like to see the destructive `choose' methods.  It appears that
`insert!' should be a <stretchy-sequence> method as well.

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-42772492
bachrach@ircam.fr


From info-dylan-request Fri Dec  4 15:26:41 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12696; Fri, 4 Dec 92 15:26:42 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12691; Fri, 4 Dec 92 15:26:41 -0500
Received: from uu3.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13889; Fri, 4 Dec 92 15:35:56 -0500
	for info-dylan@cambridge.apple.com
Received: from panix.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA18056; Fri, 4 Dec 92 14:48:53 -0500
Received: by panix.com (5.64/A/UX-2.01-AMR)
	id AA06880; Fri, 4 Dec 92 14:44:05 EST
From: fhd@panix.com (Frank Deutschmann)
Message-Id: <9212041944.AA06880@panix.com>
Subject: Re: Dylan rather than CL -- why?
To: osf.org!macrakis@uu3.psi.com (Stavros Macrakis)
Date: Fri, 4 Dec 92 14:44:05 EST
Cc: info-dylan@cambridge.apple.com
In-Reply-To: <9212041603.AA13736@lakatos.osf.org>; from "Stavros Macrakis" at Dec 4, 92 11:03 am

> 					      In addition, where the
>    target hardware can support it, it is nice to have at least some of
>    the development environment present, to allow end-user programming and
>    live system debugging.
> 
> Ah, but here you're pulling the whole environment back in.  What IS an
> important goal is to be able to do dump analysis.  But that doesn't
> necessarily require having the development environment loaded in the
> standard execution environment.

Certainly dump analysis is important, but debugging an active
production system can be even more useful/important.

Consider the case of a system with an extensive and complicated (from
the developer's perspective!) user interface: when a user of this
system discovers an intermittent problem which seems to only happen at
random intervals, crash dumps (even forced crash dumps) are virtually
useless most of the time.  What is really needed isthe capability for
the user to call a help line saying: "It's happening now!" and then
have a developer "attach" to the system's debugging environment.

I can say that this is most useful from experience; for my current
system project (a distributed financial trading system with ~150 users
on three continents using three synchronized databases and multiple
domain-specific compute-server processes) we incorporated a GDB
"client" into the system, allowing a developer to use GDB to
"attach" to the remotely executing system and do some basic
debugging.  This system has been a big success; we have been able to
track down many problems which had been open for several months,
thereby improving service to our end-users.  

However, it would be even more useful if more development support
could be provided at this level: currently, given that the system is
built in C, we are pretty much limited to error-detection; a fix
requires a recompile and subsequent shutdown and redistribution of
executables.  If we had a development environment built into the
system, we would be able to make changes to the executing software,
and prevent any interruption to end-user's work.  Furthermore, if this
development environment were "linked" to the main development and code
control environment, we would have the capability to track and fold
such changes into the master source inventory, preventing versioning
problems.  For today's large-scale end-user oriented systems, it seems
like this would be a rather important development!

To further the above argument with a rather controversial point,
consider the following: in my business, "time to market" (while we
don't sell our software, our end-users are our "market") is
everything.  Our business uses the software we develop to gain
competitive edge; frequently, the difference of only a few days can
mean large differences in business revenue.  In this environment,
software testing is a difficult subject: on the one hand, you don't
want error-prone software; on the other hand, we can't afford (from a
time to market perspective) exhaustive testing.  Today, we do the best
we can.  However, if we were able to bring the cost of fixing certain
software errors down -- in particular user interface problems -- we
could then spend more time with exhaustive testing on the most
critical parts, and let morte of the less critical errors slide by, to
be fixed when they happen in the production environment.  While this
may sound rather outrageous, in a time constrained environment, you
have little choice.

Of course, the arguments of "use a better development
language/environment" (as opposed to C) come readily to mind as more
appropriate first-cut solutions to the problem than "permitting"
software errors; however, I think we still need to come to terms with
the fact that today's time-constrained business climate precludes
software proofs, which of course means that some quantity of errors
will always occur (in fact, it's not clear to me that with "proved"
software errors, particularly semantic errors, would be a thing of the
past).  As business software developers, we need to rank potential
errors in terms of severity, and then allocate our detection and
resolution capabilities according to risk.  Today, while not all
errors are equally severe, the cost of locating and fixing an error is
constant; I feel that my developer's life would be much improved if we
could allocate our expensive detection and resolution skills to the
serious errors (errors with potential to have large-scale negative
impact on the business), and sole the less serous errors at a lower
cost (on-line software analysis and software change).

Just some more thoughts; thanks to everyone for the replies to my
previous letter!

-frank




From info-dylan-request Fri Dec  4 15:45:55 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13129; Fri, 4 Dec 92 15:45:56 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13124; Fri, 4 Dec 92 15:45:55 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14034; Fri, 4 Dec 92 15:55:10 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Fri, 4 Dec 1992 20:48:14 +0000
Date: Fri, 4 Dec 92 20:48:39 GMT
Message-Id: <17448.9212042048@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Dylan rather than CL -- why?
To: kend@newton.apple.com
Cc: brent@amber.ssd.csd.harris.com, info-dylan@cambridge.apple.com

> >> fhd@panix.com (Frank Deutschmann) writes:
> >> 
> >> > 3) Why seperate the developmet environment from the language?
> ...
> >> 
> >>       o delivery - you don't want to deliver the environment.  At
> >>       some point you need to deliver an application and make the
> >>       break between environment and language.  Why not specify that
> >>       break up front?
> >
> >You typically don't want to deliver the _language_ either.
> >If you're delivering the language -- ie if users of the application
> >are going to me adding Lisp code -- why deprive them of useful tools?
> 
> There is no attempt at depravation. It is rather the other way around. 
> Unless you draw a clear distinction between the language and the
> development environment, you can never ship without the development
> environment because you don't know what you can seal off.

I would say EVAL is more of a problem than the development env here.
You can't find everything that can ever be called, because the program
might construct an expression that called anything it wants.

However, there are a number of ways to deal with that problem.
For instance, you could add a rule that said nothing could be
called via EVAL that wasn't also called (or referenced) directly;
or the implementation could provide such a facility as an extension.

> Smalltalk-80 was
> notorious for this as you could not just "ship binaries"-- you had to ship
> the development environment.  Languages such as Scheme or Dylan allow you
> to cleanly seal off parts of all of a system.  You can link together an
> application rather than just do image snapshots (much nicer to program your
> car's engine controller with 1/2 8^).

You're right to say that's how CL applications are (usually) built.
You load files into Lisp and save an image.  But Common Lisp could be
implemented in a way that let you build an application by linking
some .o files with a library.

Moreover, you could save images that didn't include the dev env.
You can already do this with Lucid CL.

In short, while I share the concern about applications, and agree
that a clear separation between lang and env is a good idea, I don't
think that separating them in the implementation (as opposed to the
language definition) it's the only good way to do Lisp.  Of course,
it depends in part on what's in the env and what depends on it.
SmallTalk has a greater problem that Common Lisp in this respect.

-- jd

From info-dylan-request Fri Dec  4 16:03:49 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13561; Fri, 4 Dec 92 16:03:50 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13557; Fri, 4 Dec 92 16:03:49 -0500
Received: from everest.den.mmc.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14137; Fri, 4 Dec 92 16:11:34 -0500
	for info-dylan@cambridge.apple.com
Received: from orion.den.mmc.com by everest.den.mmc.com (4.1/1.34.a)
	id AA02423; Fri, 4 Dec 92 13:59:17 MST
Received: by orion.den.mmc.com (orion# aliases for this host.mmc.generic.062090)
Date: Fri, 4 Dec 92 13:55:21 MST
From: Robin Kladke (303) 977-9760 <robin@orion.den.mmc.com>
Message-Id: <9212042055.AA16545@orion>
To: ranson@lannion.cnet.fr
Subject: Re: Monthly FAQ Posting
Cc: info-dylan@cambridge.apple.com

The job opportunity you alluded to your message was posted by Larry Tesler
and it specifically denies that the May demo of Newton was written in Dylan
.  It enigmatically states that the relationship between this Dylan programming
opportunity and Newton is not something for public disclosure.  I have 
included the message.  I think the bottom line is that Apple doesn't want to
commit to a relationship between the two this early in the game.

Enclosure follows:
From garrett@ssv.den.mmc.com Mon Sep 21 14:46:30 1992
Received: by orion.den.mmc.com (orion# aliases for this host.mmc.generic.062090)
Received: by ssvfred (4.1/1.34)
	id AA00299; Mon, 21 Sep 92 14:49:09 MDT
Date: Mon, 21 Sep 92 14:49:09 MDT
From: garrett@ssv.den.mmc.com (Fred Garrett)
Message-Id: <9209212049.AA00299@ssvfred>
To: robin@orion.den.mmc.com, kimber@ssvfred, cole@ssvfred, anhalt@ssvfred
Subject: Recruiting assistance requested
Status: R

FYI -
----- Begin Included Message -----

>From tesler@newton.apple.com Fri Sep 18 09:11:41 1992
Date: Fri, 18 Sep 92 07:59:56 PDT
To: OODL.SIG$@applelink.apple.com, OODL-SIG-IN@cambridge.apple.com
From: tesler@newton.apple.com
Subject: Recruiting assistance requested
Content-Length: 1312

If you know of an experienced software engineer with object-oriented and
dynamic programming language experience who might be interested in a job
where she or he could program in Dylan, in a diverse group of people
developing innovative product software, please encourage her or him to send
a resume to me at the post office or email address below (NOT TO THE
MAILING LIST).

The work location is Apple's exquisite new R&D Center in Cupertino,
California, near San Jose, where almost every engineer will have a fully
enclosed private office.  The work is related to the Newton project, so the
candidate should be someone more interested in mass market handheld
products than in large workstations that have memory and wattage to burn.

I cannot say in public how the work is related to the Newton project. 
However, I will take this opportunity to deny the rumor that the Newton
software that Apple demonstrated at CES in May was written in Dylan.

I appreciate your mentioning this opportunity to acquaintances.

Larry Tesler

**********************************************
Larry Tesler, V.P. Newton Group, Apple Computer, Inc.
USMail: 20525 Mariani Ave., MS: 50T, Cupertino, CA, 95014
Internet: tesler@newton.apple.com
Phone: (408) 974-2219, Fax: (408) 974-1794
**********************************************



----- End Included Message -----






From info-dylan-request Fri Dec  4 16:24:38 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14011; Fri, 4 Dec 92 16:24:39 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14006; Fri, 4 Dec 92 16:24:38 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14270; Fri, 4 Dec 92 16:33:53 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA12269; Fri, 4 Dec 92 16:27:48 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA20296; Fri, 4 Dec 1992 16:25:35 -0500
Date: Fri, 4 Dec 1992 16:25:35 -0500
Message-Id: <9212042125.AA20296@lakatos.osf.org>
To: fhd@panix.com
In-Reply-To: Frank Deutschmann's message of Fri, 4 Dec 92 14:44:05 EST <9212041944.AA06880@panix.com>
Subject: Dylan rather than CL -- why?
Cc: info-dylan@cambridge.apple.com
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

fhd@panix.com (Frank Deutschmann) said:

   >    ...where the target hardware can support it, it is nice to
   >    have at least some of the development environment present, to
   >    allow end-user programming and live system debugging.

I replied:

   > Ah, but here you're pulling the whole environment back in....

Deutschmann continued:

   ... debugging an active production system can be even more
   useful/important....

The issue is not whether it should be possible to have a development
environment in the running system when you DO want it.  (Which I agree
is useful in many circumstances.)  I think that's a given.  The issue
is whether it should be possible to have a running system WITHOUT a
development environment when you DON'T want it.  The latter is not
possible if you don't make a clean distinction between development
environment and execution environment, while making such a clean
distinction doesn't hurt in the other case.

Also, to reply to another point, if you want a standard development
environment, you can certainly define one without building it into the
language, just as you can define a standard linear-programming package
or a standard graphic-interface package (although of course its
implementation is much more closely linked to the language
implementation than these examples).  There are surely a lot of areas
where standard interfaces are desirable.  In fact, I could go through
the arguments why that is more important than standardization of
development environments if it's not obvious.

	-s

From alms Fri Dec  4 17:32:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15390; Fri, 4 Dec 92 17:32:09 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15380; Fri, 4 Dec 92 17:32:04 -0500
Message-Id: <9212042232.AA15380@cambridge.apple.com>
Date: Fri, 4 Dec 1992 17:43:51 -0500
To: info-dylan
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject:  A Tiny MOP, in Scheme (fwd)

Forwarded message:

Date: 1 Dec 92 19:21:40 GMT
From: gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.scheme,comp.object,comp.lang.lisp,comp.lang.clos
Subject: A Tiny MOP, in Scheme


This message will be of interest to: (i) People who are interested in
metaobject protocols, particularly metaobject protocols for Lisp-based
object-oriented languages; and (ii) people who are interested in Lisp-
based object-oriented languages like CLOS and Dylan.  In this message,
we announce the public availability of the Scheme implementation of a
`kernelized' CLOS, with a metaobject protocol.  (If you are interested
only in OO languages, and not metaobject protocols, you can skip the
third, fourth and fifth paragraphs of this message.)

One stumbling block for people interested in playing with the metaobject
protocol (MOP) ideas has been the relative complexity of working in
Common Lisp.  This has been a particular obstacle for undergraduates and
others who normally work in Scheme (or a very reduced Common Lisp).  To
try and address this, we have designed and implemented a Scheme
embedding of a core subset of CLOS, with a corresponding core MOP.

Since our primary goal is pedagogical in nature, we have been able to
produce an extremely lean language, MOP and implementation.  The
implementation is even simpler than the simple CLOS found in `The Art of
the Metaobject Protocol,' weighing in at around 850 lines of code,
including (some) comments and documentation.

By making the new language and MOP be the core of CLOS and the CLOS MOP,
rather than some completely new language, our goal was to make possible
for people to work with existing written materials -- primarily `The Art
of the Metaobject Protocol' (AMOP) -- when playing with this system.
(It should also be possible for people working with Tiny CLOS to get
value from reading papers about others MOPs, such as ABLC/R, 3KRS and
others.)  A side benefit of this approach is that Tiny CLOS is close to
a core of Dylan, so people interested in that language may find value in
playing with Tiny CLOS as well.)

The MOP in Tiny CLOS is very simple -- 8 introspective procedures and 9
intercessory generics -- but it retains much of the power of both of the
MOPs found in AMOP.  Even though the Tiny CLOS implementation itself
isn't optimized, this MOP is amenable to optimization, using techniques
like those mentioned in AMOP.  In fact, the slot access protocol used in
this MOP is such that it should be possible to get better performance
than is possible with the CLOS MOP.

While it isn't our primary goal, Tiny CLOS can also be used by those who
are simply intereted in CLOS/Dylan style OO languages.  That is, you can
play with the base language without even thinking about the MOP.  A
great deal has already been said and written about how to learn, think
about and teach OOP and CLOS-like languages, so we won't say any more
about that.  But, it is important to point out a significant difference
between Tiny CLOS and CLOS/Dylan.  In Tiny CLOS, slot names are not
required to be symbols, they can be any Scheme datum (object).  (They
are compared using eq?.)  This means that one can use the lexical
scoping mechanisms of Scheme to achieve a greater degree of
encapsulation than is possible in CLOS.  For more on this, see the
second and third examples in the examples file.

Accompanying Tiny CLOS is a file of examples, that show how the base
language works, and how to use the MOP to do several common extensions.
Other things people might want to write are: before and after methods,
slot filling initargs, beta-like languages, singleton methods etc.

To make distribution simple, Tiny CLOS is available by anonymous ftp
from parcftp.xerox.com:/pub/mops.  There are five files of interest:

  
 tiny-annouce.text  This message.

 support.scm        Just a bunch of useful stuff.
                    (All implementation specific mods (are supposed
                    to) go in here.)
 tiny-clos.scm      The main program.
 tiny-examples.scm  A few little examples of using this language
                    and this MOP.
 tiny-rpp.text      The reflective processor program for this
                    MOP.  This file was generated, by hand, from
                    tiny-clos.scm by removing all the code that
                    deals with bootstrapping or grounding out
                    the tower.  That is, this is the code/protocol
                    that you should `think of' as running at the
                    next level, when ignoring issues of circularity.


MIT Scheme 11.74 is the only Scheme we have access to, so that is the
only Scheme in which we have run this stuff.  But, it should run with
only minor mods in other Schemes as well.  (Please send us those mods
so they can be included in the sources!)


This language, this MOP, and this implementation should not be treated
as any sort of finished product.  This whole thing was cranked out
relatively quickly, in response to an immediate need for simplified
Scheme embeddings of this stuff.  We are very interested in any
suggestions or improvements you might have or make.  So, please send
them in!

(It is also worth knowing that this is the first Scheme program I have
written in 10 years, so I'm willing to believe I have a lot to learn
about good Scheme style.  Rather than just snickering, please let me
know about stupid things this code does in that regard.)

One other note.  You will notice that these files have a copyright
notice on them, as is the fashion these days.  It isn't copyleft, it is
somewhat more liberal than that.  If you have any questions about it,
send us mail.

Finally, please let us know if you decide to play with this stuff, and
if you want to be on the mops@parc.xerox.com mailing list.  (Note,
please don't use this mailing list for adminstrative stuff.  It is for
technical questions and discussions.  For administrative stuff, send
mail to Gregor@parc.xerox.com.)





From info-dylan-request Fri Dec  4 17:37:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15505; Fri, 4 Dec 92 17:37:20 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15501; Fri, 4 Dec 92 17:37:18 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14557; Fri, 4 Dec 92 17:46:34 -0500
	for info-dylan@cambridge.apple.com
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA29922; Fri, 4 Dec 92 16:44:17 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA15468; Fri, 4 Dec 1992 16:38:58 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA06177; Fri, 4 Dec 92 16:40:14 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA06815; Fri, 4 Dec 92 16:40:13 CST
Date: Fri, 4 Dec 92 16:40:13 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9212042240.AA06815@stephanie.hc.ti.com>
To: macrakis@osf.org
Cc: fhd@panix.com, info-dylan@cambridge.apple.com
In-Reply-To: Stavros Macrakis's message of Fri, 4 Dec 1992 16:25:35 -0500 <9212042125.AA20296@lakatos.osf.org>
Subject: Dylan rather than CL -- why?




>Also, to reply to another point, if you want a standard development
>environment, you can certainly define one without building it into the
>language, just as you can define a standard linear-programming package
>or a standard graphic-interface package (although of course its
>implementation is much more closely linked to the language
>implementation than these examples). 

I don't believe that development environment facilities are less
closely related to the language implementation than are
graphic-interface packages.  The basic capabilities/hooks for keeping
functions, evaluation stacks, documentation, etc. have to be well
considered by the implementation.  This kind of access is essential to
modular design of separable development environments.

The only way to ensure the power is available, is for the developers
of Dylan set forth a standard for implementations which includes the
protocols and conventions necessary for separation of development
environments from the execution module.  By placing these consistency
requirements in the hands of language and environment developers, they
will allow the users to use a different environment by simply plugging
in a the new one.


-- Rob.

From info-dylan-request Fri Dec  4 17:59:13 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16024; Fri, 4 Dec 92 17:59:15 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16019; Fri, 4 Dec 92 17:59:13 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14751; Fri, 4 Dec 92 18:08:30 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA16972; Fri, 4 Dec 92 18:02:05 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA20320; Fri, 4 Dec 1992 17:59:52 -0500
Date: Fri, 4 Dec 1992 17:59:52 -0500
Message-Id: <9212042259.AA20320@lakatos.osf.org>
To: farrow@stephanie.hc.ti.com
Cc: fhd@panix.com, info-dylan@cambridge.apple.com
In-Reply-To: Rob Farrow's message of Fri, 4 Dec 92 16:40:13 CST <9212042240.AA06815@stephanie.hc.ti.com>
Subject: Dylan rather than CL -- why?
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

I said:

   >...if you want a standard development environment, you can
   >certainly define one without building it into the language, just
   >as you can define a standard linear-programming package or a
   >standard graphic-interface package (although of course its
   >implementation is much more closely linked to the language
   >implementation than these examples).

   I don't believe that development environment facilities are less
   closely related to the language implementation than are
   graphic-interface packages.

Please reread my message; we agree.  I said that "its" (i.e. the
development environment's) implementation is more closely linked to
the language implementation than are "these" examples (LP and GUI).

   The basic capabilities/hooks for keeping functions, evaluation
   stacks, documentation, etc. have to be well considered by the
   implementation.  This kind of access is essential to modular design
   of separable development environments.

In general, these hooks do not need to be part of the execution
environment, and require non-zero overhead.

	-s

From info-dylan-request Fri Dec  4 19:25:09 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18818; Fri, 4 Dec 92 19:25:12 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18813; Fri, 4 Dec 92 19:25:09 -0500
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15139; Fri, 4 Dec 92 19:33:49 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA01036; Fri, 4 Dec 92 19:27:39 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 192634.10378; Fri, 4 Dec 1992 19:26:34 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA03965; Fri, 4 Dec 92 14:22:20 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA14623; Fri, 4 Dec 92 14:22:18 PST
Date: Fri, 4 Dec 92 14:22:18 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9212042222.AA14623@eagle.sharebase.com>
To: fhd@panix.com, macrakis@osf.org
Subject: Re:  Dylan rather than CL -- why?
Cc: info-dylan@cambridge.apple.com

This thread should probably be re-named to 'Eval - Pro's and Con's'

If people _use_ eval, then [practically] the whole development environment
must be included.  If they don't, however, it shouldn't be.  This is a
job for a specialized linker, IMHO.  I think leaving eval out of the spec
was an error, since only those who use it must pay the price...

	-- Scot

From info-dylan-request Fri Dec  4 19:43:44 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19298; Fri, 4 Dec 92 19:43:45 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19293; Fri, 4 Dec 92 19:43:44 -0500
Received: from pnlg.pnl.gov by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15245; Fri, 4 Dec 92 19:52:56 -0500
	for info-dylan@cambridge.apple.com
Received: from ccmail.pnl.gov by pnlg.pnl.gov; Fri, 4 Dec 92 16:37 PST
Received: from ccMail-SMTP-Gateway (V0.990/PMDF V3.1) by ccmail.pnl.gov; Fri, 4
 Dec 92 16:37 PST
Date: Fri, 4 Dec 92 16:37 PST
From: Peter M White <pm_white@pnlg.pnl.gov>
Subject: LISP, Scheme, ?
To: info-dylan@cambridge.apple.com
Message-Id: <B6851599D67F200136@pnlg.pnl.gov>
X-Ccmail-Date: 12/4/92 4:23PM
X-Envelope-To: info-dylan@cambridge.apple.com


     All:
     
     I am new to object oriented-programming and dynamic languages.  Most of my 
     3GL experience has been with C.  I'm looking for an implementation of LISP, 
     Scheme, or any other languauge that runs under DOS/Windows that would be a 
     good place to learn the fundamentals of a language like Dylan.  Also, if 
     you know of any particular texts that would be helpful please let me know.
     
     Thanks,
     Peter White
     internet: pm_white@pnl.gov  

From alms Fri Dec  4 19:53:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15390; Fri, 4 Dec 92 17:32:09 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15380; Fri, 4 Dec 92 17:32:04 -0500
Message-Id: <9212042232.AA15380@cambridge.apple.com>
Date: Fri, 4 Dec 1992 17:43:51 -0500
To: info-dylan
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject:  A Tiny MOP, in Scheme (fwd)

Forwarded message:

Date: 1 Dec 92 19:21:40 GMT
From: gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.scheme,comp.object,comp.lang.lisp,comp.lang.clos
Subject: A Tiny MOP, in Scheme


This message will be of interest to: (i) People who are interested in
metaobject protocols, particularly metaobject protocols for Lisp-based
object-oriented languages; and (ii) people who are interested in Lisp-
based object-oriented languages like CLOS and Dylan.  In this message,
we announce the public availability of the Scheme implementation of a
`kernelized' CLOS, with a metaobject protocol.  (If you are interested
only in OO languages, and not metaobject protocols, you can skip the
third, fourth and fifth paragraphs of this message.)

One stumbling block for people interested in playing with the metaobject
protocol (MOP) ideas has been the relative complexity of working in
Common Lisp.  This has been a particular obstacle for undergraduates and
others who normally work in Scheme (or a very reduced Common Lisp).  To
try and address this, we have designed and implemented a Scheme
embedding of a core subset of CLOS, with a corresponding core MOP.

Since our primary goal is pedagogical in nature, we have been able to
produce an extremely lean language, MOP and implementation.  The
implementation is even simpler than the simple CLOS found in `The Art of
the Metaobject Protocol,' weighing in at around 850 lines of code,
including (some) comments and documentation.

By making the new language and MOP be the core of CLOS and the CLOS MOP,
rather than some completely new language, our goal was to make possible
for people to work with existing written materials -- primarily `The Art
of the Metaobject Protocol' (AMOP) -- when playing with this system.
(It should also be possible for people working with Tiny CLOS to get
value from reading papers about others MOPs, such as ABLC/R, 3KRS and
others.)  A side benefit of this approach is that Tiny CLOS is close to
a core of Dylan, so people interested in that language may find value in
playing with Tiny CLOS as well.)

The MOP in Tiny CLOS is very simple -- 8 introspective procedures and 9
intercessory generics -- but it retains much of the power of both of the
MOPs found in AMOP.  Even though the Tiny CLOS implementation itself
isn't optimized, this MOP is amenable to optimization, using techniques
like those mentioned in AMOP.  In fact, the slot access protocol used in
this MOP is such that it should be possible to get better performance
than is possible with the CLOS MOP.

While it isn't our primary goal, Tiny CLOS can also be used by those who
are simply intereted in CLOS/Dylan style OO languages.  That is, you can
play with the base language without even thinking about the MOP.  A
great deal has already been said and written about how to learn, think
about and teach OOP and CLOS-like languages, so we won't say any more
about that.  But, it is important to point out a significant difference
between Tiny CLOS and CLOS/Dylan.  In Tiny CLOS, slot names are not
required to be symbols, they can be any Scheme datum (object).  (They
are compared using eq?.)  This means that one can use the lexical
scoping mechanisms of Scheme to achieve a greater degree of
encapsulation than is possible in CLOS.  For more on this, see the
second and third examples in the examples file.

Accompanying Tiny CLOS is a file of examples, that show how the base
language works, and how to use the MOP to do several common extensions.
Other things people might want to write are: before and after methods,
slot filling initargs, beta-like languages, singleton methods etc.

To make distribution simple, Tiny CLOS is available by anonymous ftp
from parcftp.xerox.com:/pub/mops.  There are five files of interest:

  
 tiny-annouce.text  This message.

 support.scm        Just a bunch of useful stuff.
                    (All implementation specific mods (are supposed
                    to) go in here.)
 tiny-clos.scm      The main program.
 tiny-examples.scm  A few little examples of using this language
                    and this MOP.
 tiny-rpp.text      The reflective processor program for this
                    MOP.  This file was generated, by hand, from
                    tiny-clos.scm by removing all the code that
                    deals with bootstrapping or grounding out
                    the tower.  That is, this is the code/protocol
                    that you should `think of' as running at the
                    next level, when ignoring issues of circularity.


MIT Scheme 11.74 is the only Scheme we have access to, so that is the
only Scheme in which we have run this stuff.  But, it should run with
only minor mods in other Schemes as well.  (Please send us those mods
so they can be included in the sources!)


This language, this MOP, and this implementation should not be treated
as any sort of finished product.  This whole thing was cranked out
relatively quickly, in response to an immediate need for simplified
Scheme embeddings of this stuff.  We are very interested in any
suggestions or improvements you might have or make.  So, please send
them in!

(It is also worth knowing that this is the first Scheme program I have
written in 10 years, so I'm willing to believe I have a lot to learn
about good Scheme style.  Rather than just snickering, please let me
know about stupid things this code does in that regard.)

One other note.  You will notice that these files have a copyright
notice on them, as is the fashion these days.  It isn't copyleft, it is
somewhat more liberal than that.  If you have any questions about it,
send us mail.

Finally, please let us know if you decide to play with this stuff, and
if you want to be on the mops@parc.xerox.com mailing list.  (Note,
please don't use this mailing list for adminstrative stuff.  It is for
technical questions and discussions.  For administrative stuff, send
mail to Gregor@parc.xerox.com.)





From info-dylan-request Mon Dec  7 07:35:52 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03870; Mon, 7 Dec 92 07:35:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03865; Mon, 7 Dec 92 07:35:52 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00992; Mon, 7 Dec 92 07:45:29 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08546; Mon, 7 Dec 92 07:39:05 -0500
Received: from leafusa.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 073840.11853; Mon, 7 Dec 1992 07:38:40 EST
Received: from titan.HQ.Ileaf.COM by HQ.Ileaf.COM (4.1/SMI-4.0-leafusa) for info-dylan@cambridge.apple.com
	id AA18529; Mon, 7 Dec 92 07:29:45 EST
Received: by titan.HQ.Ileaf.COM (4.1/SMI-4.0-hq) for pm_white@pnlg.pnl.gov
	id AA00433; Mon, 7 Dec 92 07:32:23 EST
Date: Mon, 7 Dec 92 07:32:23 EST
From: prs@titan.HQ.Ileaf.COM (Paul Schmidt)
Message-Id: <9212071232.AA00433@titan.HQ.Ileaf.COM>
To: info-dylan@cambridge.apple.com, pm_white@pnlg.pnl.gov
Subject: Re:  LISP, Scheme, ?

XLisp, by David Betz is a good publicly available Lisp for the PC.
I'm not sure where on the nets it can be found, but it is available
from BIX, and probably Compu$erve as well.

From info-dylan-request Mon Dec  7 11:15:51 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13697; Mon, 7 Dec 92 11:15:52 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13693; Mon, 7 Dec 92 11:15:51 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01479; Mon, 7 Dec 92 11:25:28 -0500
	for info-dylan@cambridge.apple.com
Return-Path: <john@linus.mitre.org>
Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S)
	id AA18853; Mon, 7 Dec 92 11:18:27 -0500
Posted-Date: Mon, 07 Dec 92 11:18:23 EST
Received: by thelonius.mitre.org (5.61/RCF-4C)
	id AA11380; Mon, 7 Dec 92 11:18:24 -0500
Message-Id: <9212071618.AA11380@thelonius.mitre.org>
To: info-dylan@cambridge.apple.com
Subject: Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)
Date: Mon, 07 Dec 92 11:18:23 EST
From: john@linus.mitre.org

Scot Dyer (dyer@eagle.sharebase.com) writes:

  I think leaving eval out of the spec was an error,
  since only those who use it must pay the price...

I think an operator like EVAL might be rather complicated in a
language with multiple syntaxes, such as Dylan is intended to be.
Must EVAL handle all possible syntaxes, e.g.

  (EVAL '(SET! Y (+ X 2)))	; Lisp-like syntax
  (EVAL "y = x + 2 ;")		; Algol-like syntax
  ...				; etc.

Note that there are almost certainly expressions that are ambiguous,
unless the syntax is specified (in a keyword argument?).

Also note that EVAL for non-LISP syntaxes is probably quite
complicated, and must include a lexer and all the attendant machinery.
Youch.

This problem might be simplified by having the EVAL module define
object types to represent syntax-independent program-fragments.  These
might be necessary anyway, for a multiple-syntax language.  EVAL would
be handed such structures, instead of syntactic expressions.  (Is it
the Pop language that has these sorts of structures?)

I'm fairly agnostic about all of this, however.  I never use EVAL in
Lisp, and the only excusable use for it I can see is READ-EVAL-PRINT
loops in certain kinds of user interfaces, such as programming
environments.  Which is what started this discussion ...

John Burger
john@mitre.org

From moon Mon Dec  7 11:46:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15216; Mon, 7 Dec 92 11:46:14 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15210; Mon, 7 Dec 92 11:46:11 -0500
Message-Id: <9212071646.AA15210@cambridge.apple.com>
Date: Mon, 07 Dec 92 11:51:00 EST
From: moon (David A. Moon)
To: john@linus.mitre.org
Subject: Re: Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)
Cc: info-dylan@cambridge.apple.com

> Date: Mon, 07 Dec 92 11:18:23 EST
> From: john@linus.mitre.org
> 
> I think an operator like EVAL might be rather complicated in a
> language with multiple syntaxes, such as Dylan is intended to be.

I think you have the Lisp EVAL and READ functions confused with each
other.

Dylan includes neither.

From info-dylan-request Mon Dec  7 11:47:38 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15315; Mon, 7 Dec 92 11:47:39 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15311; Mon, 7 Dec 92 11:47:38 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01611; Mon, 7 Dec 92 11:57:16 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212071657.AA01611@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa18548; 7 Dec 92 11:50:21 EST
To: john@LINUS.MITRE.ORG
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?) 
In-Reply-To: Your message of Mon, 07 Dec 92 11:18:23 -0500.
             <9212071618.AA11380@thelonius.mitre.org> 
Date: Mon, 07 Dec 92 11:50:13 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    I think an operator like EVAL might be rather complicated in a
    language with multiple syntaxes, such as Dylan is intended to be.
    Must EVAL handle all possible syntaxes, e.g.
    
      (EVAL '(SET! Y (+ X 2)))	; Lisp-like syntax
      (EVAL "y = x + 2 ;")		; Algol-like syntax
      ...				; etc.
    
This shouldn't be a problem.  Eval operates not a text string (surface
syntax) but on the internal representation of a program.  This is easily
confused in Lisp because the mapping from surface syntax to internal form
is so simple and direct.  In a C-like syntax, the mapping at "read time"
and "print time" would be more complex, but I would hope that the resulting
internal program representation would be common across all surface
syntaxes, so the same EVAL could be used.

I've got no problem with leaving Eval out of the base Dylan spec.  It
probably should be standardized as an optional facilty, however, so that
all implmentations that do provide EVAL provide it in a compatible way.

-- Scott

===========================================================================
Scott E. Fahlman			Internet:  sef+@cs.cmu.edu
Senior Research Scientist		Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University		Latitude:  40:26:33 N
5000 Forbes Avenue			Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================

From info-dylan-request Mon Dec  7 13:08:51 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17766; Mon, 7 Dec 92 13:08:53 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17762; Mon, 7 Dec 92 13:08:51 -0500
Received: from bunsen.cs.byu.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01967; Mon, 7 Dec 92 13:17:45 -0500
	for info-dylan@cambridge.apple.com
Received: by bunsen.cs.byu.edu (5.57/Ultrix3.0-C)
	id AA18556; Mon, 7 Dec 92 11:15:09 -0700
Date: Mon, 7 Dec 92 11:15:09 -0700
Message-Id: <9212071815.AA18556@bunsen.cs.byu.edu>
To: info-dylan@cambridge.apple.com
From: beus@bunsen.cs.byu.edu
Subject: Info wanted on Dylan

How do I obtain a description of the language?

                Thanks, in advance.


From info-dylan-request Mon Dec  7 14:08:39 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19373; Mon, 7 Dec 92 14:08:41 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19368; Mon, 7 Dec 92 14:08:39 -0500
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02151; Mon, 7 Dec 92 14:17:40 -0500
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA11853; Mon, 7 Dec 92 14:11:20 EST
Message-Id: <9212071911.AA11853@MIT.EDU>
Date: Mon, 07 Dec 92 13:59:53 EST
From: cfry@MIT.EDU (Christopher Fry)
To: john@linus.mitre.org
Subject: Re: Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)
Cc: info-dylan@cambridge.apple.com

> Return-Path: <john@linus.mitre.org>
> Posted-Date: Mon, 07 Dec 92 11:18:23 EST
> To: info-dylan@cambridge.apple.com
> Subject: Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)
> Date: Mon, 07 Dec 92 11:18:23 EST
> From: john@linus.mitre.org
> 
> Scot Dyer (dyer@eagle.sharebase.com) writes:
> 
>   I think leaving eval out of the spec was an error,
>   since only those who use it must pay the price...
>
 John Burger writes: 
> I think an operator like EVAL might be rather complicated in a
> language with multiple syntaxes, such as Dylan is intended to be.
> Must EVAL handle all possible syntaxes, e.g.
> 
>   (EVAL '(SET! Y (+ X 2)))      ; Lisp-like syntax
>   (EVAL "y = x + 2 ;")          ; Algol-like syntax
>   ...                           ; etc.

Moon Writes:
>I think you have the Lisp EVAL and READ functions confused with each
> other.
I bet Moon's right here. To handle multiple syntaxes, a READ function should
take an additional arg [probably keyword] which indicates which syntax you're
using ie :lisp  or :infix.
Presumably :lisp would be the default and other language syntaxes would be provided as 
libraries that could be added on.

Moon Also Writes:
> Dylan includes neither. [eval or read]

I knew eval wasn't provided but didn't read the book carefully enough to 
note that READ wasn't. Sometimes I use statements like:
(my-own-eval (read ...))
Implementing READ is pretty complex due to a myriad of nit-picking details.
Its nice to have that functionality built in or at least loadable in a
standard library.

I notice PRINT isn't part of Dylan either so Dylan is "coherent" in not providing
any one of READ, EVAL, PRINT in its core.

From info-dylan-request Mon Dec  7 14:51:00 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20459; Mon, 7 Dec 92 14:51:02 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20454; Mon, 7 Dec 92 14:51:00 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02328; Mon, 7 Dec 92 15:00:39 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA19860; Mon, 7 Dec 92 14:54:28 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 145312.25229; Mon, 7 Dec 1992 14:53:12 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA21993; Mon, 7 Dec 92 11:07:07 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA15766; Mon, 7 Dec 92 11:07:05 PST
Date: Mon, 7 Dec 92 11:07:05 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9212071907.AA15766@eagle.sharebase.com>
To: info-dylan@cambridge.apple.com, john@linus.mitre.org
Subject: Re:  Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)

From: john@linus.mitre.org
/// 
/// Scot Dyer (dyer@eagle.sharebase.com) writes:
/// 
///   I think leaving eval out of the spec was an error,
///   since only those who use it must pay the price...
/// 
/// I think an operator like EVAL might be rather complicated in a
/// language with multiple syntaxes, such as Dylan is intended to be.
/// Must EVAL handle all possible syntaxes, e.g.
/// 
///   (EVAL '(SET! Y (+ X 2)))      ; Lisp-like syntax
///   (EVAL "y = x + 2 ;")          ; Algol-like syntax
///   ...                           ; etc.

Seems like simple 'polymorphism' (overloading) to me.  And only users linking
to the method for eval'ing a string actually need it included (if the type of
the object they're evaling can be deduced by the compiler).  Of course, it
_is_ a rational argument against implementing a feature that it might be hard
to do so...

/// Note that there are almost certainly expressions that are ambiguous,
/// unless the syntax is specified (in a keyword argument?).

..especially if you'd have hygenic problems doing it right:

	(EVAL "y = x + 2 ;")
	==> "y = x + 2 ;"
or	==> {the value of (+ x 2)}

/// Also note that EVAL for non-LISP syntaxes is probably quite
/// complicated, and must include a lexer and all the attendant machinery.
/// Youch.

There aren't many applications for eval, I'll give you that.  There are
probably even less with an Algol style grammer...  Perhaps not allowing
eval with alternate grammers?  Eval is a pretty LISPy idea anyway, and I doubt
non-LISP nuts would even be able to think of a use for it.

/// This problem might be simplified by having the EVAL module define
/// object types to represent syntax-independent program-fragments.  These
/// might be necessary anyway, for a multiple-syntax language.  EVAL would
/// be handed such structures, instead of syntactic expressions.  (Is it
/// the Pop language that has these sorts of structures?)

I don't know about Pop, but it seems like the output of the parser would be
LISP style code, yes?  This would be easiest to implement, I think, although
I doubt that any internal representation will be part of the spec unless eval
gets included (which it probably won't)

/// I'm fairly agnostic about all of this, however.  I never use EVAL in
/// Lisp, and the only excusable use for it I can see is READ-EVAL-PRINT
/// loops in certain kinds of user interfaces, such as programming
/// environments.  Which is what started this discussion ...

It is elegant, at least, to be able to write the read-eval-print loop.

In a language with dynamic environments and a good ability to manipulate them
(closures), eval can be a powerful tool for many tasks, like writing meta-
interpretters and rule-based systems.  These are probably things which most
Dylan users (converted C programmers in the vast majority, probably) won't
want to do.

/// John Burger
/// john@mitre.org

	-- Scot

From info-dylan-request Mon Dec  7 16:27:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23052; Mon, 7 Dec 92 16:27:19 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23047; Mon, 7 Dec 92 16:27:18 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02742; Mon, 7 Dec 92 16:36:57 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA09221; Mon, 7 Dec 92 16:30:40 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA13638; Mon, 7 Dec 1992 16:28:25 -0500
Date: Mon, 7 Dec 1992 16:28:25 -0500
Message-Id: <9212072128.AA13638@lakatos.osf.org>
To: dyer@eagle.sharebase.com
Cc: john@linus.mitre.org, info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Mon, 7 Dec 92 11:07:05 PST <9212071907.AA15766@eagle.sharebase.com>
Subject:  Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

Moon's note was pretty laconic, but the basic problem here is indeed
that you are confusing "read" and "eval".  The expression

	(eval '(+ 1 2))

is the same as

	(eval (read "(+ 1 2)"))

because read is being used to read the program.  You can presume that
there will be some syntax for "quote" in an infix syntax as well.
Suppose this syntax is << ... >>.  Then

	eval(<<1 + 2>>)

would be the same as

	eval(algol-read("1+2")).

If of course you want to mix quoted expression syntax and language
syntax, you will simply have to use the appropriate "read" function.
Thus, you'd have for instance:

	(eval (algol-read "1+2"))
and
	eval(read("(+ 1 2)")).

There is no problem here at all.

As for:

   There aren't many applications for eval, I'll give you that.  There
   are probably even less with an Algol style grammer...

There are legitimate applications for eval, and they have absolutely
nothing to do with the syntax of the language.  Perhaps you are
confusing syntax with the ability to manipulate syntax trees as data
structures?  Most language systems do not give you this capability,
but there's nothing inherent about it.

	-s

From info-dylan-request Mon Dec  7 18:30:29 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25777; Mon, 7 Dec 92 18:30:30 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25773; Mon, 7 Dec 92 18:30:29 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03160; Mon, 7 Dec 92 18:40:09 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA02057; Mon, 7 Dec 92 18:33:56 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 183202.15663; Mon, 7 Dec 1992 18:32:02 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA24366; Mon, 7 Dec 92 14:50:27 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA15967; Mon, 7 Dec 92 14:50:25 PST
Date: Mon, 7 Dec 92 14:50:25 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9212072250.AA15967@eagle.sharebase.com>
To: dyer@eagle.sharebase.com, macrakis@osf.org
Subject: Re:  Eval - Pro's and Con's (was Re:  Dylan rather than CL -- why?)
Cc: info-dylan@cambridge.apple.com, john@linus.mitre.org

From: Stavros Macrakis <macrakis@osf.org>
/// There are legitimate applications for eval, and they have absolutely
/// nothing to do with the syntax of the language.  Perhaps you are
/// confusing syntax with the ability to manipulate syntax trees as data
/// structures?  Most language systems do not give you this capability,
/// but there's nothing inherent about it.

I don't mean to say there aren't 'legitimate' uses of eval.  There
are.  Unfortunately, eval, like nil, has earned LISP a rotten
reputation because of the haphazard treatment of the environment eval
is supposed to use.  Without dynamic scope, eval becomes near to
meaningless unless some way to specify an environment is provided.

I did list meta-interpretters and rule-based programming as
applications for eval.  I don't think they will be of interest to Dylan
developers because Apple has made quite an effort to emphasize that
Dylan is for application programming, not AI.  I for one am hard
pressed to find uses for eval that 'conventional' programmers would
want.  Eval is simply not conventional.

You're right about me mixing up the grammar issue, tho', but we _all_
have, by assuming that the underlying internal program representation
is lists (as opposed to, say, vectors).  The Dylan manual says nothing
about this, but it doesn't say anything about eval, either.  LISPs
_reader_ doesn't really do all the work I associate with parsing so I
tend to forget about it.  An Algol-style parser, tho' is quite a
different story.  I would expect a Dylan that provided eval to include
a <expression> class that would be used for programs; this is a less
biased (towards LISP) approach that seems more consistant with the rest
of Dylan.

How you'd get around Dylan's static scoping, tho' is another matter,
which would need another class (<environment>) and a heap of supporting
built-ins, and frankly I don't think the people at Apple are that
interested in fixing all of LISPs problems as much as making Dylan
palatable to those just being weened from 'C.'

	-- Scot

From info-dylan-request Tue Dec  8 03:02:17 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10242; Tue, 8 Dec 92 03:02:19 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10237; Tue, 8 Dec 92 03:02:17 -0500
Received: from hplb.hpl.hp.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03754; Tue, 8 Dec 92 03:11:56 -0500
	for info-dylan@cambridge.apple.com
Received: from cdollin.hpl.hp.com by hplb.hpl.hp.com; Tue, 8 Dec 92 08:03:36 GMT
Received: by wol.hpl.hp.com
	(16.6/15.6+ISC) id AA15905; Tue, 8 Dec 92 08:07:05 GMT
Date: Tue, 8 Dec 92 08:07:05 GMT
From: Chris Dollin <kers@hplb.hpl.hp.com>
Message-Id: <9212080807.AA15905@wol.hpl.hp.com>
To: info-dylan@cambridge.apple.com
Subject: Re:  Eval - Pro's and Con's

Someone tangled in a sequence of attributions says:

| This problem might be simplified by having the EVAL module define
| object types to represent syntax-independent program-fragments.  These
| might be necessary anyway, for a multiple-syntax language.  EVAL would
| be handed such structures, instead of syntactic expressions.  (Is it
| the Pop language that has these sorts of structures?)

No (not yet, anyway). Pop [*1] has an EVAL equivalent, ``popval'', which takes
a list and compiles and executes the program (fragment) in the list. Unlike
EVAL, which takes a list which is more-or-less a syntax tree, popval's list is
just a token sequence. Pop also has ``compile'', which takes an input source
and ``compiles'' (ie, executes) that; the source is either a file identifier
(string, word (like a symbol), device) or a character repeater.

Pop programs also have access to the ``code-planting'' routines of the Pop
compiler, so they can generate code on the fly. This makes writing compilers
for suitable languages (Lisp, ML, Prolog, Scheme, and of course Pop itself)
fairly straightforward. Perhaps it is this that the original poster was
reminded of?

[*] As appearing in the Poplog environment. Further Pop questions can be
directed to comp.lang.pop.

Regards,    | "Layered protocols give the software implementor a chance to
Kers.       | ruin his performance in each layer." - Don Gillies

From info-dylan-request Tue Dec  8 06:00:49 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13774; Tue, 8 Dec 92 06:00:51 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13770; Tue, 8 Dec 92 06:00:49 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03925; Tue, 8 Dec 92 06:10:24 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212081110.AA03925@brazil.cambridge.apple.com>
Via: uk.ac.open; Tue, 8 Dec 1992 11:00:52 +0000
Received: from hcrlpost.open.ac.uk by mercury.open.ac.uk with SMTP (PP) 
          id <22381-0@mercury.open.ac.uk>; Tue, 8 Dec 1992 11:00:48 +0000
Date: 8 Dec 92 11:01:26 U
From: Stuart Watt <S.N.K.Watt@open.ac.uk>
Subject: RE: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: info-dylan@cambridge.apple.com

Stavros Macrakis writes:
>There are legitimate applications for eval

If Dylan is intended for C++/Object Pascal people, eval is mostly redundant,
and it is easy to add something like a Scheme interpreter if required.

In Procyon Common Lisp, eval is never delivered, print, format, and read are
optional, and each makes 100-150K difference to the size of the delivered
system. In a typical application, only a subset of read is required (such as
read-line and custom code), and this is much smaller. The same goes for print
(using write-string). 

I think Dylan has its standards just about right here, but then, I never liked
eval. There is a big issue hovering below the surface here. eval is used for
REP loops, and REP loops are part of things like "command-line" interfaces, but
not usually anything to do with GUIs. I wouldn't want to see eval put in to
help develop the wrong kind of system. 

>Perhaps you are confusing syntax with the ability to manipulate syntax
>trees as data structures?

Surely this is more the responsibility of a Dylan version of lex/yacc; surely
again an external library for this kind of stuff is called for. It could even
provide good old read into the bargain. 

Regards, Stuart Watt
Human Cognition Research Laboratory,
The Open University, Walton Hall, Milton Keynes, MK7 6AA. UK.


From info-dylan-request Tue Dec  8 08:41:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18542; Tue, 8 Dec 92 08:41:07 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18534; Tue, 8 Dec 92 08:41:01 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04124; Tue, 8 Dec 92 08:50:41 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 8 Dec 1992 13:43:47 +0000
Date: Tue, 8 Dec 92 13:44:21 GMT
Message-Id: <17804.9212081344@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: Scot Dyer <dyer@eagle.sharebase.com>, info-dylan@cambridge.apple.com,
        john@linus.mitre.org
In-Reply-To: Scot Dyer's message of Mon, 7 Dec 92 11:07:05 PST

> There aren't many applications for eval, I'll give you that.  There are
> probably even less with an Algol style grammer...  Perhaps not allowing
> eval with alternate grammers?  Eval is a pretty LISPy idea anyway, and I
> doubt non-LISP nuts would even be able to think of a use for it.

I think the actual situation is almost the opposite.

These days, Lisp programmer know that EVAL should be used only in a
narrow range of cases and they know all the techniques that can be
used instead of EVAL.  It's people new to Lisp who tend to use EVAL,
especially in cases where it's not really needed, and who invent all
kinds of bizarre ways to use it.

Moreover, I think the range of applications is almost independent of
the style of grammar.

> I don't know about Pop, but it seems like the output of the parser would be
> LISP style code, yes?  This would be easiest to implement, I think, although
> I doubt that any internal representation will be part of the spec unless eval
> gets included (which it probably won't)

One of the main alternatives to EVAL is macros, and it helps to be
able to manipluate what are in effect parse trees instead of less
structured representations such as strings.

One of the advantages of Lisp-style code is that it (or a subset of
it) can double as an internal represetnation for other syntaxes.

> /// I'm fairly agnostic about all of this, however.  I never use EVAL in
> /// Lisp, and the only excusable use for it I can see is READ-EVAL-PRINT
> /// loops in certain kinds of user interfaces, such as programming
> /// environments.  Which is what started this discussion ...

I too am fairly agnostic.  I don't mind of some dialects of Lisp omit
EVAL.  I think there's more than one good way to do Lisp.  However, I
will defend EVAL against claims that it should always be excluded from
any good language.

> In a language with dynamic environments and a good ability to manipulate them
> (closures), eval can be a powerful tool for many tasks, like writing meta-
> interpretters and rule-based systems.  These are probably things which most
> Dylan users (converted C programmers in the vast majority, probably) won't
> want to do.

In my experience, meta-interpreters and rule-based systems can usually
get by w/o EVAL.  A typical trick is to take an expression in a macro-call
that might be evaluated and have the macro expand to something that
includes

  #'(lambda () <expr>)

rather than

  (quote <expr>)

-- jd

From info-dylan-request Tue Dec  8 09:04:39 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19691; Tue, 8 Dec 92 09:04:40 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19687; Tue, 8 Dec 92 09:04:39 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04200; Tue, 8 Dec 92 09:14:24 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 8 Dec 1992 14:07:34 +0000
Date: Tue, 8 Dec 92 14:08:08 GMT
Message-Id: <18191.9212081408@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: RE: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: Stuart Watt <S.N.K.Watt@open.ac.uk>, info-dylan@cambridge.apple.com
In-Reply-To: Stuart Watt's message of 8 Dec 92 11:01:26 U

> There is a big issue hovering below the surface here. eval is used for
> REP loops, and REP loops are part of things like "command-line" interfaces,
> but not usually anything to do with GUIs. I wouldn't want to see eval put 
> in to help develop the wrong kind of system. 

What?  EVAL just does the eval part.  It's READ and PRINT that are
the "wrong kind" of interface.

However, one of the key advantages of Lisp is that there's a defined
external representation for a wide range of data object.  One of the
things that keeps me from using other languages is that I usually
have to write a bunch of tedious I/O routines before I can try things
out.

This is not to say that READ and PRINT should be delivered in
applications though, or that they're useful in every case.
However, their usefulness is not confined to "command-line"
interfaces.

-- jd

From info-dylan-request Tue Dec  8 09:28:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20829; Tue, 8 Dec 92 09:28:07 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20824; Tue, 8 Dec 92 09:28:05 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04286; Tue, 8 Dec 92 09:37:50 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212081437.AA04286@brazil.cambridge.apple.com>
Via: uk.ac.open; Tue, 8 Dec 1992 14:31:07 +0000
Received: from hcrlpost.open.ac.uk by mercury.open.ac.uk with SMTP (PP) 
          id <25502-0@mercury.open.ac.uk>; Tue, 8 Dec 1992 14:31:03 +0000
Date: 8 Dec 92 14:31:44 U
From: Stuart Watt <S.N.K.Watt@open.ac.uk>
Subject: RE: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: info-dylan@cambridge.apple.com

JD writes (re: READ and PRINT)
>However, their usefulness is not confined to "command-line"
>interfaces.

Well, I would say that read probably is only useful for this. read is
positively dangerous to deliver as it will make Lisp parsing so easy that my
favourite word processor will want me to enter styles in parentheses! print I
have no real problems with, although if read is not going to be delivered
printing will change as the read-print equivalence is not so important. 

eval is a totally separate issue. Personally, I can't see much justification
for it, as apply is good enough for most purposes. An interpreter is an obvious
choice for an external (and very optional) module. 

What I was trying to get at is that the traditional streamy Lisp IO is a
development environment thing, like MPW and the UNIX shell. Users want
something different, like "no" instead of #f. Similarly, on input, people don't
necessarily want "1/1" to be interpreted as a rational, they may just want to
use it as a name. Doing IO yourself (say using a custom parser) is the only
safe way, although print and read may be (and are!) great for development. 

Regards, Stuart

From info-dylan-request Tue Dec  8 11:03:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25487; Tue, 8 Dec 92 11:03:02 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25483; Tue, 8 Dec 92 11:03:01 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04641; Tue, 8 Dec 92 11:12:45 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 8 Dec 1992 15:45:02 +0000
Date: Tue, 8 Dec 92 15:45:31 GMT
Message-Id: <19000.9212081545@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: Scot Dyer <dyer@eagle.sharebase.com>, macrakis@osf.org
In-Reply-To: Scot Dyer's message of Mon, 7 Dec 92 14:50:25 PST
Cc: info-dylan@cambridge.apple.com, john@linus.mitre.org

> I don't mean to say there aren't 'legitimate' uses of eval.  There
> are.  Unfortunately, eval, like nil, has earned LISP a rotten
> reputation because of the haphazard treatment of the environment eval
> is supposed to use. 

Really?  Lisp has a rotten reputation among people who know so much
about it that they're bothered by a particular semantics for EVAL
rather than by EVAL in general?  And this gives _Lisp_ (rather
than the particular dialects that have this version of EVAL) a rotten
reputation?  

> Without dynamic scope, eval becomes near to
> meaningless unless some way to specify an environment is provided.

Which is way EVAL tends to have such an argument in purely
lexical languages (eg, Scheme implementations and dialects).

> I did list meta-interpretters and rule-based programming as
> applications for eval.

And you can often get by w/o it there too.  (At least I do.)

However, there are times when the alternative to EVAL is to write a
specialized EVAL fo your own, and then you could often save time by
using Lisp's EVAL.  Think of cases where the user enters an expression
and you want to produce a function that evaluates it, for instance.
Or suppose you use Lisp as an "extension language", as in Emacs or
AutoCAD.

>  I don't think they will be of interest to Dylan
> developers because Apple has made quite an effort to emphasize that
> Dylan is for application programming, not AI.  I for one am hard
> pressed to find uses for eval that 'conventional' programmers would
> want.  Eval is simply not conventional.

>   frankly I don't think the people at Apple are that
> interested in fixing all of LISPs problems as much as making Dylan
> palatable to those just being weened from 'C.'

But dynamic languages aren't "conventional".  If the aim is to
appeal to C programmer without departing from the conventional,
then Dylan isn't what you want.

Somewhere in the background of this discussion seems to be the
idea that Lisp is a single language with certain "bad" properties
that someone (but not the designers of Dylan) might want to fix.
But in fact there are a number of different Lisps, some of which
have already fixed these things (even though many of the "bad" 
properties also turn out to be "good" for certian purposes).  

What I'm saying may look contradictory.  Some things have been
fixed, but they're not really bad.  The way this gets resolved
is to say there's more than one good way to do Lisp.  There
can be different kinds of Lisp, aimed perhaps at different tasks,
with different advantages and disadvantages -- just as there
can be different programming languages generally.

Dylan is one way reasonably good way of doing Lisp.  But it isn't
as far from the rest of Lisp as it may seem.  Dylan is very close
to Scheme (+ part of CLOS), to ISO's ISLisp, and to EuLisp Level 0.
Common Lisp isn't the only Lisp to compare it to, and these other
Lisps have already moved Lisp in a direction very similar to Dylan's.

-- jd

From info-dylan-request Tue Dec  8 12:24:46 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28693; Tue, 8 Dec 92 12:24:48 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28688; Tue, 8 Dec 92 12:24:46 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05021; Tue, 8 Dec 92 12:34:32 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA17422; Tue, 8 Dec 92 12:25:33 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 122433.14135; Tue, 8 Dec 1992 12:24:33 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA06048; Tue, 8 Dec 92 08:44:27 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA16371; Tue, 8 Dec 92 08:44:25 PST
Date: Tue, 8 Dec 92 08:44:25 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9212081644.AA16371@eagle.sharebase.com>
To: dyer@eagle.sharebase.com, info-dylan@cambridge.apple.com,
        jeff@aiai.edinburgh.ac.uk, john@linus.mitre.org
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

From jeff@aiai.edinburgh.ac.uk Tue Dec  8 07:14:57 1992
/// In my experience, meta-interpreters and rule-based systems can usually
/// get by w/o EVAL.  A typical trick is to take an expression in a macro-call
/// that might be evaluated and have the macro expand to something that
/// includes
/// 
///   #'(lambda () <expr>)
/// 
/// rather than
/// 
///   (quote <expr>)

While this is true, sometimes one wants to allow a rule to given actual code
to execute, thus temporarily losing some of the interpretter/search engine's
overhead.  Eval is one of the cleanest ways to do this I know of.

	-- Scot

From info-dylan-request Tue Dec  8 12:42:37 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29129; Tue, 8 Dec 92 12:42:39 -0500
Received: from jumbo.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29123; Tue, 8 Dec 92 12:42:37 -0500
Received: from apple.com by jumbo.apple.com with SMTP (5.64/26-Oct-1992-eef)
	id AA21789; Tue, 8 Dec 92 09:53:33 PST
	for info-dylan@cambridge.apple.com
Received: from yonge.csri.toronto.edu by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA24104; Tue, 8 Dec 92 09:46:02 -0800
	for info-dylan@cambridge.apple.com
Received: from alias by yonge.csri.toronto.edu with UUCP id <14440>; Tue, 8 Dec 1992 12:44:40 -0500
Received: from dino.alias.com by barney.alias.com with SMTP id AA14814
	(5.65a/IDA-1.4.2 for info-dylan@cambridge.apple.com); Tue, 8 Dec 92 11:34:52 -0500
Received: by dino.alias.com id AA02013
	(5.65a/IDA-1.4.2 for info-dylan@cambridge.apple.com); Tue, 8 Dec 92 11:34:52 -0500
From: chk@alias.com (C. Harald Koch)
Message-Id: <9212081634.AA02013@dino.alias.com>
Subject: Subscription Request
To: info-dylan@cambridge.apple.com
Date: 	Tue, 8 Dec 1992 11:34:50 -0500
X-Mailer: ELM [version 2.4 PL8]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 497       

could you please add the address

	dylan-readers@alias.com

To the info-dylan list? We have several people here interested, and we'll
manage the distribution locally.

Thanks,

-- 
Main's Law: For every       | C. Harald Koch  Alias Research, Inc. Toronto, ON
action, there is an equal   | chk@alias.com                (work-related mail)
and opposite goverment      | chk@gpu.utcs.utoronto.ca     (permanent address)
program.                    | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)

From info-dylan-request Tue Dec  8 13:08:46 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29901; Tue, 8 Dec 92 13:08:48 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29896; Tue, 8 Dec 92 13:08:46 -0500
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05271; Tue, 8 Dec 92 13:18:33 -0500
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA29142; Tue, 8 Dec 92 13:11:44 EST
Message-Id: <9212081811.AA29142@MIT.EDU>
Date: Tue, 08 Dec 92 13:04:43 EST
From: cfry@MIT.EDU (Christopher Fry)
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
Cc: Scot Dyer <dyer@eagle.sharebase.com>, macrakis@osf.org,
        info-dylan@cambridge.apple.com, john@linus.mitre.org

I want to second Jeff Dalton's remarks to Scott Dyer.
Here's a few more bits:

Scot writes:
>>  I don't think they will be of interest to Dylan
>> developers because Apple has made quite an effort to emphasize that
>> Dylan is for application programming, not AI.  I for one am hard
>> pressed to find uses for eval that 'conventional' programmers would
>> want.  Eval is simply not conventional.

Fry: If you could manage to come up with a definitive description of
what an "AI" program is and what an "application" program is [which I doubt] then 
I'd say this: Yesterday's "AI" program is today's "conventional" program.

Scot:
>>   frankly I don't think the people at Apple are that
>> interested in fixing all of LISPs problems as much as making Dylan
>> palatable to those just being weened from 'C.'

Jeff:
>But dynamic languages aren't "conventional".  If the aim is to
>appeal to C programmer without departing from the conventional,
>then Dylan isn't what you want.

If the aim is simply to appeal to C programmer's then just give them C.
If a C programmer doesn't have to stretch and learn any new concepts 
to become a good Dylan programmer, then why should they bother to
learn Dylan at all? If fact, why bother to develop Dylan in the first
place?

Eval is useful in a lot more places than read-eval-print loops, just as
are read and print. If your model of eval is that REP is the only significant
use of eval, then I'd say you have some old, limited model of lisp.

I'd also say that my quess is beginning lisp programmers don't use eval.
They use + and aref. When they get beyond the "conventional" part of
lisp, THEN they start using EVAL.

Whether eval & read are part of a "library" or not I don't really care.
I do care that I'm able to easily have a consistent LARGE functionality in
my development environment [including eval and read] and that I can easily
include them in a application if I like. Its also nice to make the
application small and if the stand-alone-app generator notices that
eval and read aren't used, it should feel free to cut them out [as with
any other unused functions]. [But provide me with a way to
force their inclusion just in case I want to give the user the ability to
call a fn that's not used elsewhere in the program.]

In the past, libraries have been a major source of inconsistencies, ie
I'm using Mcl2.0.3 but lib:foo.lisp only works for mcl2.0.4. I trust the folks
at Apple are concerned about this issue and will come up with something clever
to mitigate these problems that lesser languages/environments have.

From info-dylan-request Tue Dec  8 13:41:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00947; Tue, 8 Dec 92 13:41:08 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00942; Tue, 8 Dec 92 13:41:04 -0500
Received: from talcott.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05489; Tue, 8 Dec 92 13:50:51 -0500
	for info-dylan@cambridge.apple.com
Received: by kurz-ai.com (MC 2.0/SMI-4.0)
	id AA15861; Tue, 8 Dec 92 13:40:38 EST
Received: by taiyo.kurz-ai.com (4.1/SMI-4.0)
	id AA24092; Tue, 8 Dec 92 13:41:02 EST
Date: Tue, 8 Dec 92 13:41:02 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9212081841.AA24092@taiyo.kurz-ai.com>
To: info-dylan@cambridge.apple.com
Subject: RE: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

The Apple event object model is a protocol for allowing applications
to control each other and work collaboratively.  In effect it
specifies a standard "syntax" of structured-object event descriptions
for which a target application must determine the appropriate set of
local data and the appropriate method to apply to them.

Is it useful to consider what READ/EVAL, foreign "expression"
interfaces, foreign function interfaces, and foreign application
interfaces have or should have in common?  Applications/processes may
have more and more the look of actors having functional contracts,
interfaced in more complex ways than UNIX pipes.

For example, the reader for "(+ 1 2)" may be a foreign process, and
deliver '(+ 1 2) for my home process to evaluate.  More realistically,
a speech recognizer may do the "reading", and deliver an event object
for me to "evaluate".

From info-dylan-request Tue Dec  8 14:37:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02457; Tue, 8 Dec 92 14:37:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02453; Tue, 8 Dec 92 14:37:30 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05664; Tue, 8 Dec 92 14:47:15 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA17843@relay.tek.com>; Tue, 8 Dec 92 11:30:24 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA13740; Tue, 8 Dec 92 11:31:05 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA04193; Tue, 8 Dec 92 11:21:22 PST
Date: Tue, 8 Dec 92 11:21:22 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9212081921.AA04193@goldfish.MITRON.TEK.COM>
To: info-dylan@cambridge.apple.com
In-Reply-To: Sam Pilato's message of Tue, 8 Dec 92 13:41:02 EST <9212081841.AA24092@taiyo.kurz-ai.com>
Subject: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

[Does anyone want to talk about Dylan? Only half joking.]

   Date: Tue, 8 Dec 92 13:41:02 EST
   From: samp@kurz-ai.COM (Sam Pilato)
   The Apple event object model is a protocol for allowing applications
   to control each other and work collaboratively. [...]

   Is it useful to consider what READ/EVAL, foreign "expression"
   interfaces, foreign function interfaces, and foreign application
   interfaces have or should have in common? [...]

   For example, the reader for "(+ 1 2)" may be a foreign process, and
   deliver '(+ 1 2) for my home process to evaluate.  More realistically,
   a speech recognizer may do the "reading", and deliver an event object
   for me to "evaluate".

Inter-application communication and EVAL are two separate issues.

I may have an application that does not have EVAL, but it will connect
with another application as a client or a server. For example, a help
server can be contacted to display help on some topic. EVAL is not
needed.

Some other application may have IAC and EVAL, and in particular it may
allow some other application to connect and do "remote evaluation".
For example, a window system server may allow clients to connect and
send functions to the server, extending the capabilities of what the
server is capable of doing without involving the remote client. (Can
you say NeWS?)

In both of samp's examples, the server application is apparently a
language evaluator and the client wants something evaluated. There is
no demonstration of IAC having anything in common with EVAL.
--
Patrick Logan         patl@goldfish.mitron.tek.com
Mitron Corporation    (503) 690-8350    FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006

From info-dylan-request Tue Dec  8 15:03:25 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03170; Tue, 8 Dec 92 15:03:28 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03165; Tue, 8 Dec 92 15:03:25 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05784; Tue, 8 Dec 92 15:13:12 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 8 Dec 1992 18:21:44 +0000
Date: Tue, 8 Dec 92 18:02:08 GMT
Message-Id: <20233.9212081802@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: RE: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: Stuart Watt <S.N.K.Watt@open.ac.uk>, info-dylan@cambridge.apple.com
In-Reply-To: Stuart Watt's message of 8 Dec 92 14:31:44 U

> JD writes (re: READ and PRINT)
> >However, their usefulness is not confined to "command-line"
> >interfaces.
> 
> Well, I would say that read probably is only useful for this. 

That's certainly not the only thing _I_ use it for.  READ is useful
whenever I have a stream or sequence of characters and want the
corresponding Lisp object.  The characters don't have to come from a
command-line interface.  On the other hand, I don't expecially mind
if they do.  I use Unix (cough, spit, gasp).

> read is positively dangerous to deliver as it will make Lisp parsing so
> easy that my favourite word processor will want me to enter styles in
> parentheses! 

I like Lisp's syntax.  And, in any case, having READ in the language
(or, rather, the I/O library) doesn't mean applications will use it
as part of their user interface.  

> print I
> have no real problems with, although if read is not going to be delivered
> printing will change as the read-print equivalence is not so important. 

> eval is a totally separate issue. Personally, I can't see much justification
> for it, as apply is good enough for most purposes. 

I hardly ever use EVAL, and I don't mind using a Lisp dialect that
omits it.  On the other hand, I think the backlash against EVAL that
we've seen in recent years has been a bit excessive.

> What I was trying to get at is that the traditional streamy Lisp IO is a
> development environment thing, like MPW and the UNIX shell.

What do you mean?  That in a different _development_ env, you wouldn't
have PRINT and READ?  I don't think that's so.  You might have _no_
development env and still have PRINT and READ, for instance.

> Users want something different, like "no" instead of #f. Similarly, on 
> input, people don't necessarily want "1/1" to be interpreted as a rational,
> they may just want to use it as a name. Doing IO yourself (say using a
> custom parser) is the only safe way, although print and read may be (and
> are!) great for development. 

This is an argument against using PRINT and READ when they're not
appropriate, not an argument for eliminating them altogether.

Of course, if what you want is for a language to be useful for a
fairly narrow range of applications and nothing else, then all sorts
of restrictions start making more sense.

-- jd

From info-dylan-request Tue Dec  8 15:03:29 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03176; Tue, 8 Dec 92 15:03:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03172; Tue, 8 Dec 92 15:03:29 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05787; Tue, 8 Dec 92 15:13:15 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 8 Dec 1992 18:21:59 +0000
Date: Tue, 8 Dec 92 18:04:52 GMT
Message-Id: <20255.9212081804@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: dyer@eagle.sharebase.com (Scot Dyer), info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Tue, 8 Dec 92 08:44:25 PST

> >From jeff@aiai.edinburgh.ac.uk Tue Dec  8 07:14:57 1992
> /// In my experience, meta-interpreters and rule-based systems can usually
> /// get by w/o EVAL.  A typical trick is to take an expression in a macro-
> /// call that might be evaluated and have the macro expand to something that
> /// includes
> /// 
> ///   #'(lambda () <expr>)
> /// 
> /// rather than
> /// 
> ///   (quote <expr>)
> 
> While this is true, sometimes one wants to allow a rule to given actual code
> to execute, thus temporarily losing some of the interpretter/search engine's
> overhead.  Eval is one of the cleanest ways to do this I know of.

I'm not sure what you mean.  If I have a rule like this:

(defrule rule-1
  (if <conditions>
      then <Lisp code>))

then I can handle it as above.

-- jd

From info-dylan-request Tue Dec  8 16:47:25 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06061; Tue, 8 Dec 92 16:47:27 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06056; Tue, 8 Dec 92 16:47:25 -0500
Received: from media-lab.media.mit.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06258; Tue, 8 Dec 92 16:57:13 -0500
	for info-dylan@cambridge.apple.com
Received: by media-lab.mit.edu (5.57/DA1.0.3)
	id AA08275; Tue, 8 Dec 92 16:50:57 -0500
Date: Tue, 8 Dec 92 16:50:57 -0500
From: Michael B. Johnson <wave@MEDIA-LAB.MEDIA.MIT.EDU>
Message-Id: <9212082150.AA08275@media-lab.mit.edu>
To: info-dylan@cambridge.apple.com
In-Reply-To: Sam Pilato's message of Tue, 8 Dec 92 13:41:02 EST <9212081841.AA24092@taiyo.kurz-ai.com>
Subject: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

   Date: Tue, 8 Dec 92 13:41:02 EST
   From: samp@kurz-ai.com (Sam Pilato)

   The Apple event object model is a protocol for allowing applications
   to control each other and work collaboratively.  In effect it
   specifies a standard "syntax" of structured-object event descriptions
   for which a target application must determine the appropriate set of
   local data and the appropriate method to apply to them.

   Is it useful to consider what READ/EVAL, foreign "expression"
   interfaces, foreign function interfaces, and foreign application
   interfaces have or should have in common?  Applications/processes may
   have more and more the look of actors having functional contracts,
   interfaced in more complex ways than UNIX pipes.

   For example, the reader for "(+ 1 2)" may be a foreign process, and
   deliver '(+ 1 2) for my home process to evaluate.  More realistically,
   a speech recognizer may do the "reading", and deliver an event object
   for me to "evaluate".

Absolutely.  If you couldn't have READ/EVAL, I'm not interested in
Dylan.  I might as well be writing in C.


-->  Michael B. Johnson
-->  MIT Media Lab      --  Computer Graphics & Animation Group
-->  (617) 253-0663     --  wave@media-lab.media.mit.edu

From info-dylan-request Tue Dec  8 17:09:59 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03176; Tue, 8 Dec 92 15:03:31 -0500
Full-Name: 
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03172; Tue, 8 Dec 92 15:03:29 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05787; Tue, 8 Dec 92 15:13:15 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 8 Dec 1992 18:21:59 +0000
Date: Tue, 8 Dec 92 18:04:52 GMT
Message-Id: <20255.9212081804@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
To: dyer@eagle.sharebase.com (Scot Dyer), info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Tue, 8 Dec 92 08:44:25 PST

> >From jeff@aiai.edinburgh.ac.uk Tue Dec  8 07:14:57 1992
> /// In my experience, meta-interpreters and rule-based systems can usually
> /// get by w/o EVAL.  A typical trick is to take an expression in a macro-
> /// call that might be evaluated and have the macro expand to something that
> /// includes
> /// 
> ///   #'(lambda () <expr>)
> /// 
> /// rather than
> /// 
> ///   (quote <expr>)
> 
> While this is true, sometimes one wants to allow a rule to given actual code
> to execute, thus temporarily losing some of the interpretter/search engine's
> overhead.  Eval is one of the cleanest ways to do this I know of.

I'm not sure what you mean.  If I have a rule like this:

(defrule rule-1
  (if <conditions>
      then <Lisp code>))

then I can handle it as above.

-- jd

From info-dylan-request Tue Dec  8 18:02:24 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08023; Tue, 8 Dec 92 18:02:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08019; Tue, 8 Dec 92 18:02:24 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06531; Tue, 8 Dec 92 18:12:12 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by world.std.com (5.65c/Spike-2.0)
	id AA22630; Tue, 8 Dec 1992 18:05:36 -0500
Message-Id: <199212082305.AA22630@world.std.com>
To: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Cc: dyer@eagle.sharebase.com (Scot Dyer), info-dylan@cambridge.apple.com
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?) 
In-Reply-To: Your message of "Tue, 08 Dec 92 18:04:52 GMT."
             <20255.9212081804@subnode.aiai.ed.ac.uk> 
Date: Tue, 08 Dec 92 18:05:35 -0500
From: Bob Kerns <rwk@world.std.com>

    Date: Tue, 8 Dec 92 18:04:52 GMT
    From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
    
    > While this is true, sometimes one wants to allow a rule to given actual code
    > to execute, thus temporarily losing some of the interpretter/search engine's
    > overhead.  Eval is one of the cleanest ways to do this I know of.
    
    I'm not sure what you mean.  If I have a rule like this:
    
    (defrule rule-1
      (if <conditions>
          then <Lisp code>))
    
    then I can handle it as above.

Right.  After all, if you want to lose the interpretter/search engine's
overhead, you certainly want to lose EVAL's overhead, and run compiled!

From info-dylan-request Tue Dec  8 18:51:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08880; Tue, 8 Dec 92 18:51:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08876; Tue, 8 Dec 92 18:51:11 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06654; Tue, 8 Dec 92 19:00:58 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA24836; Tue, 8 Dec 92 18:54:30 EST
Received: from thailand.gensym by Gensym.COM (4.0/SMI-4.0)
	id AA25164; Tue, 8 Dec 92 17:02:25 EST
Received: by thailand.gensym (4.1/SMI-4.1)
	id AA10602; Tue, 8 Dec 92 17:07:13 EST
Date: Tue, 8 Dec 92 17:07:13 EST
From: bhyde@thailand.Gensym.COM (Ben A. Hyde)
Message-Id: <9212082207.AA10602@thailand.gensym>
To: info-dylan@cambridge.apple.com
Subject: Fat language features.

It seems polite to take Dylan on it's own terms and not attempt to
ask it to be something else.

Dylan, it seems to me, attempts to be the C (or maybe C++) of dynamic
languages.  Big complex features, like eval, fall out of the design
because of this.

It doesn't take much wit to pile on requests for big complex features.
Just pick some chapter in your favorite big language.  Ada... tasking 
and generics?  C... concise infix notation?  Lisp... deftype, eval, 
format?

My favorite list of big features comes from things I always seem to
build when ever I implement an application.  How about: extremely fast 
document save and restore, undo, micro-tasking, built in support for
styles, or hypercard style inheritance?

Most big features like these would be hard work to implement in C or
Dylan.  Most of them could have a better implementation if the base 
language included them.  Neither of these is a good reason to push
Dylan away from the goal of being the C of dynamicly typed languages, 
i.e. the one the wins in the marketplace.

  - ben hyde












From info-dylan-request Tue Dec  8 19:38:46 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA09881; Tue, 8 Dec 92 19:38:48 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09877; Tue, 8 Dec 92 19:38:46 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06788; Tue, 8 Dec 92 19:48:35 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA26724; Tue, 8 Dec 92 19:42:17 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 194138.10727; Tue, 8 Dec 1992 19:41:38 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA08950; Tue, 8 Dec 92 15:42:16 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA16873; Tue, 8 Dec 92 15:42:14 PST
Date: Tue, 8 Dec 92 15:42:14 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9212082342.AA16873@eagle.sharebase.com>
To: jeff@aiai.edinburgh.ac.uk, rwk@world.std.com
Subject: Re: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)
Cc: dyer@eagle.sharebase.com, info-dylan@cambridge.apple.com

/// Right.  After all, if you want to lose the interpretter/search engine's
/// overhead, you certainly want to lose EVAL's overhead, and run compiled!

This is why it's important to use a DYnamic LANguage.

I don't know about everyone else, but I'm sick of this thread and my mail
reader doesn't have a kill file.  Can we please talk about DYLAN?

	-- Scot

From info-dylan-request Tue Dec  8 22:00:38 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12750; Tue, 8 Dec 92 22:00:39 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12746; Tue, 8 Dec 92 22:00:38 -0500
Received: from research.nj.nec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07004; Tue, 8 Dec 92 22:10:28 -0500
	for info-dylan@cambridge.apple.com
Received: by research.nj.nec.com (4.0/YDL1.8-920115.13)
	id AA18790(research.nj.nec.com); Tue, 8 Dec 92 22:04:01 EST
Received: by overdrive.ccrl.NJ.NEC.COM (4.1/EMS1.6-920330.08)
	id AA26540(overdrive.ccrl.NJ.NEC.COM); Tue, 8 Dec 92 22:04:05 EST
From: zilla@ccrl.nj.nec.com	(John Lewis)
Received: by sun029 (4.1/CNC-Client)
	id AA08631; Tue, 8 Dec 92 22:03:29 EST
Date: Tue, 8 Dec 92 22:03:29 EST
Message-Id: <9212090303.AA08631@sun029>
To: info-dylan@cambridge.apple.com
Subject: read, eval, and damaged languages

Most large programs eventually need to have an input language.
In my opinion this is where read and eval are useful outside
of AI (isn't it?).

This goes not just for emacs and autocad, with extension languages
that are explicitly lisp, but also for Microsoft Word and Excel.
In Unix it seems that each major program has its own input language, 
and each such language is incompatible with the others and poorly designed.  

I would think that input languages should be implemented
using read, eval, and lisp macros, and a small amount of programming.
This would provide greater consistency and power for (advanced) users 
and eliminate the continual reinvention of parsers and evaluators 
for ad hoc languages.

People would object to the lisp-like syntax of these input languages,
but Dylan's alternate syntax might address this.

It would be ironic if Dylan were used to implement a damaged language
like Make/Awk/Perl, when Dylan itself is 'hiding' a much better language.

Is this thinking incorrect?  I am not used to Lisp without read and eval!

I favor Dylan with *optional* eval and read, so that 'large'
implementations can provide these features without including them
as implementation-specific (and incompatible) extensions.  
Of course, ideally, applications that do not use them should not 
pay the size price.

From info-dylan-request Wed Dec  9 03:46:09 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20246; Wed, 9 Dec 92 03:46:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20236; Wed, 9 Dec 92 03:46:09 -0500
Received: from vm.op.dlr.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07381; Wed, 9 Dec 92 03:55:40 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212090855.AA07381@brazil.cambridge.apple.com>
Resent-Message-Id: <9212090855.AA07381@brazil.cambridge.apple.com>
Received: from gsoc0007.rm.op.dlr.de by VM.OP.DLR.DE (IBM VM SMTP R1.2.2MX) with TCP; Wed, 09 Dec 92 09:47:16 MEZ
Resent-Date: Wed, 09 Dec 1992  0848 MET
Resent-From: Mohamed Saliya <SALIYA@VM.OP.DLR.DE.SALIYA@gsoc0007.rm.op.dlr.de>
Date: 
Resent-Date: Wed, 09 Dec 1992  0850 MET
From: 
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
To: 
Resent-To: <info-dylan@cambridge.apple.com>
Comments: Message forwarded by Mohamed Saliya <SALIYA>

***Message text starts here**********************************
***Message text starts here**********************************


From info-dylan-request Wed Dec  9 03:47:20 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20270; Wed, 9 Dec 92 03:47:24 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20266; Wed, 9 Dec 92 03:47:20 -0500
Received: from vm.op.dlr.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07389; Wed, 9 Dec 92 03:56:55 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212090856.AA07389@brazil.cambridge.apple.com>
Resent-Message-Id: <9212090856.AA07389@brazil.cambridge.apple.com>
Received: from gsoc0007.rm.op.dlr.de by VM.OP.DLR.DE (IBM VM SMTP R1.2.2MX) with TCP; Wed, 09 Dec 92 09:50:28 MEZ
Resent-Date: Wed, 09 Dec 1992  0848 MET
Resent-From: Mohamed Saliya <SALIYA@VM.OP.DLR.DE.SALIYA@gsoc0007.rm.op.dlr.de>
Resent-Date: Wed, 09 Dec 1992  0850 MET
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
Date: 
Resent-Date: Wed, 09 Dec 1992  0855 MET
From: 
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
To: 
Resent-To: <info-dylan@cambridge.apple.com>
Comments: Message forwarded by Mohamed Saliya <SALIYA>

***Message text starts here**********************************
***Message text starts here**********************************
***Message text starts here**********************************
please unsubscribe me until 28 feb 1993, since i am too busy to look into 
the mail until then. with regards ... Saliya


From info-dylan-request Wed Dec  9 04:07:44 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20381; Wed, 9 Dec 92 04:07:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20377; Wed, 9 Dec 92 04:07:44 -0500
Received: from vm.op.dlr.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07534; Wed, 9 Dec 92 04:16:52 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212090916.AA07534@brazil.cambridge.apple.com>
Resent-Message-Id: <9212090916.AA07534@brazil.cambridge.apple.com>
Received: from gsoc0007.rm.op.dlr.de by VM.OP.DLR.DE (IBM VM SMTP R1.2.2MX) with TCP; Wed, 09 Dec 92 09:48:19 MEZ
Resent-Date: Wed, 09 Dec 1992  0848 MET
Resent-From: Mohamed Saliya <SALIYA@VM.OP.DLR.DE.SALIYA@gsoc0007.rm.op.dlr.de>
Resent-Date: Wed, 09 Dec 1992  0850 MET
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
Date: 
Resent-Date: Wed, 09 Dec 1992  0853 MET
From: 
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
To: 
Resent-To: <info-dylan@cambridge.apple.com>
Comments: Message forwarded by Mohamed Saliya <SALIYA>

***Message text starts here**********************************
***Message text starts here**********************************
***Message text starts here**********************************
please unsubscribe me until 28 feb 1993, since i am too busy to look into 
the mail until then. with regards ... Saliya


From info-dylan-request Wed Dec  9 04:08:28 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20403; Wed, 9 Dec 92 04:08:39 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20394; Wed, 9 Dec 92 04:08:28 -0500
Received: from vm.op.dlr.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07537; Wed, 9 Dec 92 04:18:04 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212090918.AA07537@brazil.cambridge.apple.com>
Resent-Message-Id: <9212090918.AA07537@brazil.cambridge.apple.com>
Received: from gsoc0007.rm.op.dlr.de by VM.OP.DLR.DE (IBM VM SMTP R1.2.2MX) with TCP; Wed, 09 Dec 92 09:49:24 MEZ
Resent-Date: Wed, 09 Dec 1992  0848 MET
Resent-From: Mohamed Saliya <SALIYA@VM.OP.DLR.DE.SALIYA@gsoc0007.rm.op.dlr.de>
Resent-Date: Wed, 09 Dec 1992  0850 MET
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
Date: 
Resent-Date: Wed, 09 Dec 1992  0854 MET
From: 
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
To: 
Resent-To: <info-dylan@cambridge.apple.com>
Comments: Message forwarded by Mohamed Saliya <SALIYA>

***Message text starts here**********************************
***Message text starts here**********************************
***Message text starts here**********************************
please unsubscribe me until 28 feb 1993, since i am too busy to look into 
the mail until then. with regards ... Saliya


From info-dylan-request Wed Dec  9 04:09:54 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20447; Wed, 9 Dec 92 04:10:01 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20442; Wed, 9 Dec 92 04:09:54 -0500
Received: from vm.op.dlr.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07569; Wed, 9 Dec 92 04:19:08 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212090919.AA07569@brazil.cambridge.apple.com>
Resent-Message-Id: <9212090919.AA07569@brazil.cambridge.apple.com>
Received: from gsoc0007.rm.op.dlr.de by VM.OP.DLR.DE (IBM VM SMTP R1.2.2MX) with TCP; Wed, 09 Dec 92 09:51:33 MEZ
Resent-Date: Wed, 09 Dec 1992  0848 MET
Resent-From: Mohamed Saliya <SALIYA@VM.OP.DLR.DE.SALIYA@gsoc0007.rm.op.dlr.de>
Resent-Date: Wed, 09 Dec 1992  0850 MET
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
Date: 
Resent-Date: Wed, 09 Dec 1992  0856 MET
From: 
Resent-From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
To: 
Resent-To: <info-dylan@cambridge.apple.com>
Comments: Message forwarded by Mohamed Saliya <SALIYA>

***Message text starts here**********************************
***Message text starts here**********************************
***Message text starts here**********************************
please unsubscribe me until 28 feb 1993, since i am too busy to look into 
the mail until then. with regards ... Saliya


From brunnock Wed Dec  9 10:06:21 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26424; Wed, 9 Dec 92 10:06:21 -0500
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26420; Wed, 9 Dec 92 10:06:21 -0500
Date: Wed, 9 Dec 92 10:06:21 -0500
From: Sean Brunnock <brunnock>
Message-Id: <9212091506.AA26420@cambridge.apple.com>
To: info-dylan-temp
Subject: problems with the info-dylan mailing list


I have disabled the info-dylan mailing list until I receive
assurances from postmaster@vm.op.dlr.de that the problem has been
resolved.

All mail being sent to info-dylan are being saved to a file. When
the list is reactivated, I'll send a digest of relevant mail.

Thank you for your patience.

Sean Brunnock

From bengtb@stacken.kth.se Wed Dec  9 11:17:50 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27237; Wed, 9 Dec 92 11:17:50 -0500
Received: from alex.stacken.kth.se by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08511; Wed, 9 Dec 92 11:27:41 -0500
	for info-dylan@cambridge.apple.com
Received: by alex.stacken.kth.se id AA09695
  (5.65c/IDA-1.4.4 for info-dylan@cambridge.apple.com); Wed, 9 Dec 1992 17:20:59 +0100
Date: Wed, 9 Dec 1992 17:20:59 +0100
From: Bengt Baverman <bengtb@stacken.kth.se>
Message-Id: <199212091620.AA09695@alex.stacken.kth.se>
To: info-dylan@cambridge.apple.com, info-thomas@crl.dec.com
Subject: Using <deque> class in Dylan under Thomas.
Cc: bengtb@stacken.kth.se

I have been playing around with Dylan and Thomas a couple of days now, but I
cannot understand how to use <deque>. Why do I get this response from Thomas:

	? (define q (make <deque>))


	;Value: q

	? (push q 'foo)

	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...

	? (push q (singleton 'foo))

	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...

	? (push q 4711)

	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...
	
Is this me? Have I misunderstod Dylan or is this a bug in Thomas?

Bengt Baverman
bengtb@alex.stacken.kth.se


From samp@kurz-ai.com Wed Dec  9 11:58:21 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27617; Wed, 9 Dec 92 11:58:21 -0500
Received: from talcott.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08620; Wed, 9 Dec 92 12:08:15 -0500
	for info-dylan@cambridge.apple.com
Received: by kurz-ai.com (MC 2.0/SMI-4.0)
	id AA18660; Wed, 9 Dec 92 11:24:18 EST
Received: by taiyo.kurz-ai.com (4.1/SMI-4.0)
	id AA24578; Wed, 9 Dec 92 11:24:32 EST
Date: Wed, 9 Dec 92 11:24:32 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9212091624.AA24578@taiyo.kurz-ai.com>
To: info-dylan@cambridge.apple.com, patl@goldfish.mitron.tek.com
In-Reply-To: Patrick Logan's message of Tue, 8 Dec 92 11:21:22 PST
Subject: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)


   Inter-application communication and EVAL are two separate issues.

   I may have an application that does not have EVAL, but it will connect
   with another application as a client or a server. For example, a help
   server can be contacted to display help on some topic. EVAL is not
   needed.

   Some other application may have IAC and EVAL, and in particular it may
   allow some other application to connect and do "remote evaluation".
   For example, a window system server may allow clients to connect and
   send functions to the server, extending the capabilities of what the
   server is capable of doing without involving the remote client. (Can
   you say NeWS?)

   In both of samp's examples, the server application is apparently a
   language evaluator and the client wants something evaluated. There is
   no demonstration of IAC having anything in common with EVAL.

I think some type of EVAL _is_ implied by inter-application
communication, but we might mean different things by EVAL.

What can be meant by an EVAL in Dylan?  Dylan doesn't define EVAL, nor
does it even define a correspondence between Dylan source-code syntax
and Dylan evaluable objects (in Lisp, forms), historically mediated in
the Lisp family by a READ contract.

To consider introducing EVAL into Dylan, I assume we're defaulting to
a Lisp-like evaluator, so we're talking about advertising a contract
for the interpretation of some currently unspecified classes of Dylan
objects as function calls (or variables or constants -- or
application-interpreted tokens -- to be resolved).

Who constructs these objects?  The constructors might be explicitly
provided in Dylan; they might be implicitly provided by providing only
a READ function interpreting an external syntax (Dylan syntax or
otherwise); an interface may be defined allowing a foreign body of
code to cause the construction of some Dylan object (such as
isomorphic to an Apple event object) needing interpretation by Dylan
as a foreign function being called.  (I.e., Dylan is the "language" of
the foreign function, but the caller need not know Dylan syntax.)

In the last case, (let's call it ...?) EVALSERVE interprets an object,
dispatching on operator name, class, and class of (recursively
interpreted) operands, as a function call or token resolution.  To me
that counts as evaluation.

(I'm not a computer language implementer, but it seems that the server
aspect of a foreign function interface _could_ get away with not
distinguishing READ from EVAL, and accept only strings (or character
streams) in Dylan syntax.  I guess it depends on whether you want a
foreign _language_ interface as well as or instead of a foreign
_function_ interface.  A foreign _application_ interface implies a
distinction, though, since cooperating applications shouldn't need to
know each other's source-language syntax.)

To me, this topic does seem relevant to Dylan, however small you want
to make it, if Dylan is to be embeddable in larger, foreign,
environments.  I'm asking whether Dylan best provides separate EVAL
and EVALSERVE, or a single eval for both purposes, or neither.

From samp@kurz-ai.com Wed Dec  9 18:20:25 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03042; Wed, 9 Dec 92 18:20:25 -0500
Received: from talcott.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09548; Wed, 9 Dec 92 18:30:20 -0500
	for info-dylan@cambridge.apple.com
Received: by kurz-ai.com (MC 2.0/SMI-4.0)
	id AA19338; Wed, 9 Dec 92 16:08:38 EST
Received: by taiyo.kurz-ai.com (4.1/SMI-4.0)
	id AA24708; Wed, 9 Dec 92 16:08:51 EST
Date: Wed, 9 Dec 92 16:08:51 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9212092108.AA24708@taiyo.kurz-ai.com>
To: info-dylan@cambridge.apple.com, patl@goldfish.mitron.tek.com
In-Reply-To: Patrick Logan's message of Wed, 9 Dec 92 09:03:01 PST
Subject: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

   Date: Wed, 9 Dec 92 09:03:01 PST
   From: Patrick Logan <patl@goldfish.mitron.tek.com>

       Date: Wed, 9 Dec 92 11:24:32 EST
       From: samp@kurz-ai.COM (Sam Pilato)

	   [...]

       I think some type of EVAL _is_ implied by inter-application
       communication, but we might mean different things by EVAL.

       [...]

       In the last case, (let's call it ...?) EVALSERVE interprets an object,
       dispatching on operator name, class, and class of (recursively
       interpreted) operands, as a function call or token resolution.  To me
       that counts as evaluation.

   I think we are talking about two different things: an evaluator for
   the Dylan language that is integrated with, changes, and extends the
   same Dylan environment used to implement the application; and an
   evaluator for a language that is implemented in the application, which
   may be a "meta-circular" implementation of Dylan, but it does not
   change or extend the "original" Dylan's environment.

   Does that make sense?

Yes, I think I understand your distinction.  In the first case you're
talking about a traditional EVAL, and in the second case any other
language using Dylan code for its interpreter.

In particular, the "other" language I'm talking about has code objects
something like Apple event objects, and Dylan (or perhaps more likely
an application written in Dylan) handles some subset of those events,
via a kind of "evaluation".

If it handles an application-defined and perhaps foreign-extensible
variety of events, and if the event objects can be mapped to Dylan
"forms" (currently nonexistent), then the language begins to look like
a nice inter-application interface.  I'm wondering whether a native
EVAL in Dylan might serve as a handy, generic, and efficient
implementation of that language.

From bengtb@stacken.kth.se Wed Dec  9 18:24:54 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03139; Wed, 9 Dec 92 18:24:54 -0500
Received: from alex.stacken.kth.se by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09556; Wed, 9 Dec 92 18:34:43 -0500
	for info-dylan@cambridge.apple.com
Received: by alex.stacken.kth.se id AA10341
  (5.65c/IDA-1.4.4 for info-dylan@cambridge.apple.com); Thu, 10 Dec 1992 00:27:59 +0100
Date: Thu, 10 Dec 1992 00:27:59 +0100
From: Bengt Baverman <bengtb@stacken.kth.se>
Message-Id: <199212092327.AA10341@alex.stacken.kth.se>
To: bengtb@stacken.kth.se, info-dylan@cambridge.apple.com,
        patl@goldfish.mitron.tek.com
Subject: Re: Using <deque> class in Dylan under Thomas.

>I am using the scc kit for Thomas 1.1 and the <deque> functions work
>as expected. Maybe it is a bug with some other kit or something in
>your installation.

The version of Thomas that I use is:
Thomas 1.1 system running on MacGambit 1.9.1 as printed at startup.

Bengt Baverman
bengtb@alex.stacken.kth.se




From greg@huey.Jpl.Nasa.Gov Thu Dec 10 12:52:02 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01270; Thu, 10 Dec 92 12:52:02 -0500
Received: from huey.jpl.nasa.gov by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11019; Thu, 10 Dec 92 13:02:03 -0500
	for info-dylan@cambridge.apple.com
Received: from hanna.JPL.NASA.GOV by huey.Jpl.Nasa.Gov (4.1/SMI-4.1+DXRm2.2)
	id AA24177; Thu, 10 Dec 92 09:50:55 PST
Date: Thu, 10 Dec 92 09:50:55 PST
From: greg@huey.Jpl.Nasa.Gov (Greg Wanish)
Message-Id: <9212101750.AA24177@huey.Jpl.Nasa.Gov>
To: info-dylan@cambridge.apple.com
Subject: add me to you mailing list: info-dylan


Please add me to you 'info-dylan' mailing list.


			- Thank You,
			
			   Greg Wanish
			   greg@huey.jpl.nasa.gov
			   
			   
			   

From brunnock Thu Dec 10 13:44:34 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02529; Thu, 10 Dec 92 13:44:36 -0500
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02525; Thu, 10 Dec 92 13:44:34 -0500
Date: Thu, 10 Dec 92 13:44:34 -0500
From: Sean Brunnock <brunnock>
Message-Id: <9212101844.AA02525@cambridge.apple.com>
To: info-dylan
Subject: info-dylan up again


I have restored the info-dylan mailing list. I have not received
any expalanation from the postmaster at the site in question.

Below are the messages that were sent to info-dylan in the past 24 hours.

Sean Brunnock

Date: Wed, 9 Dec 1992 17:20:59 +0100
From: Bengt Baverman <bengtb@stacken.kth.se>
Message-Id: <199212091620.AA09695@alex.stacken.kth.se>
To: info-dylan@cambridge.apple.com, info-thomas@crl.dec.com
Subject: Using <deque> class in Dylan under Thomas.
Cc: bengtb@stacken.kth.se

I have been playing around with Dylan and Thomas a couple of days now, but I
cannot understand how to use <deque>. Why do I get this response from Thomas:

	? (define q (make <deque>))


	;Value: q

	? (push q 'foo)

	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...

	? (push q (singleton 'foo))

	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...

	? (push q 4711)

	*** ERROR -- runtime-error
	*** Going back to Thomas toplevel...
	
Is this me? Have I misunderstod Dylan or is this a bug in Thomas?

Bengt Baverman
bengtb@alex.stacken.kth.se


Date: Wed, 9 Dec 92 11:24:32 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9212091624.AA24578@taiyo.kurz-ai.com>
To: info-dylan@cambridge.apple.com, patl@goldfish.mitron.tek.com
In-Reply-To: Patrick Logan's message of Tue, 8 Dec 92 11:21:22 PST
Subject: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)


   Inter-application communication and EVAL are two separate issues.

   I may have an application that does not have EVAL, but it will connect
   with another application as a client or a server. For example, a help
   server can be contacted to display help on some topic. EVAL is not
   needed.

   Some other application may have IAC and EVAL, and in particular it may
   allow some other application to connect and do "remote evaluation".
   For example, a window system server may allow clients to connect and
   send functions to the server, extending the capabilities of what the
   server is capable of doing without involving the remote client. (Can
   you say NeWS?)

   In both of samp's examples, the server application is apparently a
   language evaluator and the client wants something evaluated. There is
   no demonstration of IAC having anything in common with EVAL.

I think some type of EVAL _is_ implied by inter-application
communication, but we might mean different things by EVAL.

What can be meant by an EVAL in Dylan?  Dylan doesn't define EVAL, nor
does it even define a correspondence between Dylan source-code syntax
and Dylan evaluable objects (in Lisp, forms), historically mediated in
the Lisp family by a READ contract.

To consider introducing EVAL into Dylan, I assume we're defaulting to
a Lisp-like evaluator, so we're talking about advertising a contract
for the interpretation of some currently unspecified classes of Dylan
objects as function calls (or variables or constants -- or
application-interpreted tokens -- to be resolved).

Who constructs these objects?  The constructors might be explicitly
provided in Dylan; they might be implicitly provided by providing only
a READ function interpreting an external syntax (Dylan syntax or
otherwise); an interface may be defined allowing a foreign body of
code to cause the construction of some Dylan object (such as
isomorphic to an Apple event object) needing interpretation by Dylan
as a foreign function being called.  (I.e., Dylan is the "language" of
the foreign function, but the caller need not know Dylan syntax.)

In the last case, (let's call it ...?) EVALSERVE interprets an object,
dispatching on operator name, class, and class of (recursively
interpreted) operands, as a function call or token resolution.  To me
that counts as evaluation.

(I'm not a computer language implementer, but it seems that the server
aspect of a foreign function interface _could_ get away with not
distinguishing READ from EVAL, and accept only strings (or character
streams) in Dylan syntax.  I guess it depends on whether you want a
foreign _language_ interface as well as or instead of a foreign
_function_ interface.  A foreign _application_ interface implies a
distinction, though, since cooperating applications shouldn't need to
know each other's source-language syntax.)

To me, this topic does seem relevant to Dylan, however small you want
to make it, if Dylan is to be embeddable in larger, foreign,
environments.  I'm asking whether Dylan best provides separate EVAL
and EVALSERVE, or a single eval for both purposes, or neither.

Date: Wed, 9 Dec 92 16:08:51 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9212092108.AA24708@taiyo.kurz-ai.com>
To: info-dylan@cambridge.apple.com, patl@goldfish.mitron.tek.com
In-Reply-To: Patrick Logan's message of Wed, 9 Dec 92 09:03:01 PST
Subject: Eval - Pro's and Con's (was Re: Dylan rather than CL -- why?)

   Date: Wed, 9 Dec 92 09:03:01 PST
   From: Patrick Logan <patl@goldfish.mitron.tek.com>

       Date: Wed, 9 Dec 92 11:24:32 EST
       From: samp@kurz-ai.COM (Sam Pilato)

	   [...]

       I think some type of EVAL _is_ implied by inter-application
       communication, but we might mean different things by EVAL.

       [...]

       In the last case, (let's call it ...?) EVALSERVE interprets an object,
       dispatching on operator name, class, and class of (recursively
       interpreted) operands, as a function call or token resolution.  To me
       that counts as evaluation.

   I think we are talking about two different things: an evaluator for
   the Dylan language that is integrated with, changes, and extends the
   same Dylan environment used to implement the application; and an
   evaluator for a language that is implemented in the application, which
   may be a "meta-circular" implementation of Dylan, but it does not
   change or extend the "original" Dylan's environment.

   Does that make sense?

Yes, I think I understand your distinction.  In the first case you're
talking about a traditional EVAL, and in the second case any other
language using Dylan code for its interpreter.

In particular, the "other" language I'm talking about has code objects
something like Apple event objects, and Dylan (or perhaps more likely
an application written in Dylan) handles some subset of those events,
via a kind of "evaluation".

If it handles an application-defined and perhaps foreign-extensible
variety of events, and if the event objects can be mapped to Dylan
"forms" (currently nonexistent), then the language begins to look like
a nice inter-application interface.  I'm wondering whether a native
EVAL in Dylan might serve as a handy, generic, and efficient
implementation of that language.

Date: Thu, 10 Dec 1992 00:27:59 +0100
From: Bengt Baverman <bengtb@stacken.kth.se>
Message-Id: <199212092327.AA10341@alex.stacken.kth.se>
To: bengtb@stacken.kth.se, info-dylan@cambridge.apple.com,
        patl@goldfish.mitron.tek.com
Subject: Re: Using <deque> class in Dylan under Thomas.

>I am using the scc kit for Thomas 1.1 and the <deque> functions work
>as expected. Maybe it is a bug with some other kit or something in
>your installation.

The version of Thomas that I use is:
Thomas 1.1 system running on MacGambit 1.9.1 as printed at startup.

Bengt Baverman
bengtb@alex.stacken.kth.se


From info-dylan-request Fri Dec 11 11:19:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10084; Fri, 11 Dec 92 11:19:12 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10076; Fri, 11 Dec 92 11:19:04 -0500
Received: from [129.247.160.10] by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12821; Fri, 11 Dec 92 11:27:43 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212111627.AA12821@brazil.cambridge.apple.com>
Received: from gsoc0007.rm.op.dlr.de by VM.OP.DLR.DE (IBM VM SMTP R1.2.2MX) with TCP; Fri, 11 Dec 92 17:20:47 MEZ
Date: 11.12.1992 1718 MET
From: Mohamed Saliya <SALIYA@gsoc0007.rm.op.dlr.de>
To: <info-dylan@cambridge.apple.com>
Comments: Message forwarded by Mohamed Saliya <SALIYA>

***Message text starts here**********************************
please unsubscribe me until 28 feb 1993, since i am too busy to look into 
the mail until then. with regards ... Saliya





From info-dylan-request Mon Dec 14 08:04:24 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21611; Mon, 14 Dec 92 08:04:29 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21607; Mon, 14 Dec 92 08:04:24 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16106; Mon, 14 Dec 92 08:11:11 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Mon, 14 Dec 1992 14:03:47 +0100
Received: by miles.ircam.fr, Mon, 14 Dec 1992 14:03:44 +0100
Date: Mon, 14 Dec 1992 14:03:44 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212141303.AA07895@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: method return values' types

It is quite clear to me that being able to declare the return types of
method's is very important.  Unfortunately, at present, DYLAN
provides no mechanism for doing so -- only a future way to declare
return types of generic-function's.  Of course this is insufficient as
method's of the same generic-function could have different return
types.  

In order to expedite the design of such a feature I propose the
following syntax:

  (define-method variable-name parameter-list form-1 form-2 ...)

  where parameter-list ::=
  ({required | (required specializer)}*
   [#next next]
   [#rest rest]
   [#key {keyparam | ([keyword] keyparam [default])}*]
   [#result {result-type | (result-type-1 result-type-2 ...)}]) 
		
I opted to name the return-value token `#result' but other better
names might be `#return' or more succinctly `#:' or `#=>'.  

What do people think?

-- Jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-42772492
bachrach@ircam.fr

From moon Mon Dec 14 12:02:47 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27333; Mon, 14 Dec 92 12:02:51 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27329; Mon, 14 Dec 92 12:02:47 -0500
Message-Id: <9212141702.AA27329@cambridge.apple.com>
Date: Mon, 14 Dec 92 12:04:51 EST
From: moon (David A. Moon)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: method return values' types
Cc: info-dylan@cambridge.apple.com

> Date: Mon, 14 Dec 1992 14:03:44 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> 
> It is quite clear to me that being able to declare the return types of
> method's is very important.  Unfortunately, at present, DYLAN
> provides no mechanism for doing so -- only a future way to declare
> return types of generic-function's.  Of course this is insufficient as
> method's of the same generic-function could have different return
> types.  
> 
> In order to expedite the design of such a feature I propose the
> following syntax:
> 
>   (define-method variable-name parameter-list form-1 form-2 ...)
> 
>   where parameter-list ::=
>   ({required | (required specializer)}*
>    [#next next]
>    [#rest rest]
>    [#key {keyparam | ([keyword] keyparam [default])}*]
>    [#result {result-type | (result-type-1 result-type-2 ...)}]) 
>                 
> I opted to name the return-value token `#result' but other better
> names might be `#return' or more succinctly `#:' or `#=>'.  
> 
> What do people think?

We are working on something much like this.  It isn't ready to publish yet.
I think we all agree that it's important.

From info-dylan-request Tue Dec 15 15:01:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07185; Tue, 15 Dec 92 15:01:06 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07181; Tue, 15 Dec 92 15:01:05 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21585; Tue, 15 Dec 92 15:08:16 -0500
	for info-dylan@cambridge.apple.com
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA03735; Tue, 15 Dec 92 14:06:32 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA08758; Tue, 15 Dec 1992 14:00:52 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA28645; Tue, 15 Dec 92 14:01:36 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA08851; Tue, 15 Dec 92 14:01:35 CST
Date: Tue, 15 Dec 92 14:01:35 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9212152001.AA08851@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: HELP - Thomas for SPARC



I would like to use Thomas on a SPARC with Scheme->C.  Has anyone
already determined the required C file changes for this?

Tx

-- Rob.

P.S. Is there a Thomas list I could direct this too?

From info-dylan-request Tue Dec 15 15:26:26 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07720; Tue, 15 Dec 92 15:26:28 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07716; Tue, 15 Dec 92 15:26:26 -0500
Received: from aswad.nada.kth.se by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21710; Tue, 15 Dec 92 15:33:33 -0500
	for info-dylan@cambridge.apple.com
Received: by aswad.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0)
	id AA03380; Tue, 15 Dec 92 21:26:51 +0100
Date: Tue, 15 Dec 92 21:26:51 +0100
From: d90-awe@nada.kth.se
Message-Id: <9212152026.AA03380@aswad.nada.kth.se>
To: farrow@stephanie.hc.ti.com (Rob Farrow)
Cc: info-dylan@cambridge.apple.com, info-thomas@dec.crl.com
Subject: HELP - Thomas for SPARC
In-Reply-To: <9212152001.AA08851@stephanie.hc.ti.com>
References: <9212152001.AA08851@stephanie.hc.ti.com>

Rob Farrow writes:
 > I would like to use Thomas on a SPARC with Scheme->C.  Has anyone
 > already determined the required C file changes for this?

I have built Thomas for Sparc using Scheme->C. I just took all
system-specific files from the SPARC-patches of the latest version of
SCC and incorporated them in the relevant files in Thomas. 

Then, SCC dumped core when trying to compile a scheme-file. However,
once I had rebuilt SCC without optimizing, that worked too.

I can try to make diff-files from the Thomas-dist if anyone is
interested.

 > 
 > P.S. Is there a Thomas list I could direct this too?

Yes, info-thomas@dec.crl.com.

/assar

From info-dylan-request Tue Dec 15 15:29:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07783; Tue, 15 Dec 92 15:29:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07779; Tue, 15 Dec 92 15:29:30 -0500
Received: from aswad.nada.kth.se by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21722; Tue, 15 Dec 92 15:36:43 -0500
	for info-dylan@cambridge.apple.com
Received: by aswad.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0)
	id AA03388; Tue, 15 Dec 92 21:29:36 +0100
Date: Tue, 15 Dec 92 21:29:36 +0100
From: d90-awe@nada.kth.se
Message-Id: <9212152029.AA03388@aswad.nada.kth.se>
To: farrow@stephanie.hc.ti.com (Rob Farrow)
Cc: info-dylan@cambridge.apple.com, info-thomas@crl.dec.com
Subject: HELP - Thomas for SPARC

Rob Farrow writes:
 > I would like to use Thomas on a SPARC with Scheme->C.  Has anyone
 > already determined the required C file changes for this?

I have built Thomas for Sparc using Scheme->C. I just took all
system-specific files from the SPARC-patches of the latest version of
SCC and incorporated them in the relevant files in Thomas. 

Then, SCC dumped core when trying to compile a scheme-file. However,
once I had rebuilt SCC without optimizing, that worked too.

I can try to make diff-files from the Thomas-dist if anyone is
interested.

 > 
 > P.S. Is there a Thomas list I could direct this too?

Yes, info-thomas@crl.dec.com.

/assar

From info-dylan-request Tue Dec 15 17:46:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA09970; Tue, 15 Dec 92 17:46:07 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09965; Tue, 15 Dec 92 17:46:05 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22151; Tue, 15 Dec 92 17:53:14 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA23447; Tue, 15 Dec 92 17:46:28 EST
Received: from ireland.gensym by gensym.com (4.1/SMI-4.1)
	id AA00309; Tue, 15 Dec 92 17:23:40 EST
Date: Tue, 15 Dec 92 17:23:40 EST
From: jra@gensym.com (Jim Allard)
Message-Id: <9212152223.AA00309@gensym.com>
Received: by ireland.gensym (4.1/SMI-4.1)
	id AA01266; Tue, 15 Dec 92 17:26:42 EST
To: info-dylan@cambridge.apple.com
Subject: IEEE NaN and Trichotomy

Being somewhat of a late-comer to the discussion I don't know if this has been
addressed before, but I wanted to address my surprise at the explicit rejection
of IEEE NaN comparison behavior in Dylan.

On pages 75 and 147 there are mentions that floats follow IEEE conventions
except within comparisons, where the IEEE behavior would harm trichotomy and
therefore cannot be used.  No alternate behavior is described.  Though I do not
know what within the language depends on trichotomy and so cannot know the
fallout of this suggestion, I would urge the Dylan designers to revisit this
issue and consider adopting a fully compliant IEEE float behavior.

I also have a suggestion (which may be completely wrong) that partial orderings
could be handled if the possibility is allowed of users optionally writing more
binaryX comparitor methods, which would be used by comparitors other than = and
< when available, but still falling back to the two required comparitors when
the optional ones weren`t supplied.

My concerns about dropping IEEE NaN comparisons maninly have to do with
implementation speed issues made difficult by this choice.  Other concerns for
me would be getting Dylan users to understand a non-compliant behavior and
Dylan missing out on industrial standards and practices that tie-in with the
IEEE standard.

If Dylan programs do not use the IEEE behavior, then implementors of Dylan
compilers will have to figure out how to implement behavior other than what is
built-in to the math processors they are presented with.  Controlling
generation of NaNs within a program is one approach, though a difficult one.
The IEEE standard allows implementations to choose between generating NaN
results on overflows or to raise a SIGFPE exception.  Many vendor's processors
have switches that allow the programmer to choose between behaviors.  So one
choice a Dylan implementor could make is to always raise SIGFPE on NaN
generation, turning that into a Dylan exception, making NaNs not be valid
floats within a Dylan program, and so NaNs are not an issue within the
comparison operations.  However, issues surrounding the use of these switches
can be difficult.  On the IBM Risc System 6000 for example, setting the switch
that causes SIGFPE on overflow harms performance, since the process using this
switch must be run in serial mode, eliminating the low level parallelism of the
machine.  Another problem with this approach is that users could return NaNs
from foreign code.  Finally, this approach contradicts the general movement I
seem to be seeing amongst vendors of new architectures towards allowing NaN
generation as the default behavior.

Another approach is to go ahead and allow NaNs to be generated within the
arithmetic, to explicitly detect NaNs within comparison operation
implemenations, and then do whatever behavior Dylan eventually defines for NaN
comparison.  I would guess this is what the Dylan designers expected to occur.
This might be done when comparing A and B by emitting instructions to check the
following:

  (and (not (< a b)) (not (< b a)))

This works since IEEE says that comparisons involving NaN always return false.
The problem with this approach is that all floating point comparisons must use
variants of this check before running.  This would be a required floating point
performance deficiency within Dylan, which would give ammunition to those who
fight high-level languages as fat and slow.

A final approach is to not specially handle NaNs, let binary< and binary=
operations return #f, and therefore allow a NaN to be seen as greater than
other float values.  Given the intent of NaN within IEEE floats, this would be
a very odd choice.

As for my other concerns, I think it is difficult enough to get programmers
used to one set of choices around the complex issue of NaN handling.  To have
Dylan introduce another set of choices raises the learning curve for new
programmers.

Within my work I run into a lot of process control engineers.  They have told
me that NaNs are used in some process control systems to represent values from
sensors that are known to not be currently providing accurate values, and that
they commonly implement the logic on these values to be fail-safe, given IEEE
behavior on comparisons with NaN.  So, for example, safety checks are done such
that when readings on a valve position come back as NaN, then safety checks
will fail, since the safety predicates are written to always return true when
safe.  This individual also said that there were ISA standards for use of NaN
where sensors failed, though I haven't been able to confirm that.  I would
expect that many such practices have emerged around IEEE floats in different
industries, and non-standard IEEE behavior in Dylan would alienate those
industries.

The desire to use only two comparitors, binary= and binary<, as the basis of
all ordering within Dylan comparisons seems to be the motivation for trichotomy
requirements.  However, this would imply to me that implementations may not
make use of specific, optimized operations for comparitors like <=, but would
force both binary< and binary= to be used, which introduces another potential
performance loss.  Partially ordered sets are explicitly excluded from the
Dylan comparitor protocol, given trichotomy.

A suggestion for partially ordered comparisons is to provide generic functions
for binary>, binary>=, and binary<=, to allow users to optionally provide
methods for these generic functions along with the required binary= and binary<
methods (required assuming they want ordering), and to change the definitions
of the >, >=, and <= methods so that they will call the optional binary
ordering methods in preference to binary< and binary= when possible.  The
documentation for these binary comparitor generic functions could suggest that
for partial orderings that the binary comparitors return #f when the comparison
is inconclusive.  This is needed for stable sorts, and would follow the IEEE
float convention of returning false for inconclusive comparisons.

Note that this suggestion would depend upon an introspective function I've not
yet seen defined, which would determine if there is a method defined for a
particular set of arguments to a generic function.  To get compile-time method
selection for inlining of comparitors, a version that could determine if a
method is defined given given the types of the arguments to a generic function
would also be required.

Any thoughts or interest on this?

Jim

-------------------------------------------------------------------------------
Jim Allard                                        jra@gensym.com
Manager of Languages, Interpreters, & Compilers   (617) 547-2500
Gensym Corporation
125 CambridgePark Drive
Cambridge, MA  02140
-------------------------------------------------------------------------------

From info-dylan-request Tue Dec 15 17:56:03 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10195; Tue, 15 Dec 92 17:56:05 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10188; Tue, 15 Dec 92 17:56:03 -0500
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22240; Tue, 15 Dec 92 18:03:11 -0500
	for info-dylan@cambridge.apple.com
Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA07804; Tue, 15 Dec 92 17:43:46 -0500
Received: from qm by hirollers.atg.amex-trs.com (AIX 3.2/UCB 5.64/3.2.083191-American Express Advanced Technology Group)
	id AA30042; Tue, 15 Dec 1992 15:16:21 -0700
Message-Id: <9212152216.AA30042@hirollers.atg.amex-trs.com>
Date: 15 Dec 92 15:03:15 U
From: "Darin Deforest" <darin_deforest@unixmail.atg.amex-trs.com>
Subject: unsubscribe
To: info-dylan@cambridge.apple.com, info-dylan-request@cambridge.apple.com

                       Subject:                               Time:3:01 PM
        ATG MEMO       unsubscribe                            Date:12/15/92
unsubscribe
Please remove Darin Deforest from the list



From cassels Wed Dec 16 15:29:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16142; Wed, 16 Dec 92 15:29:19 -0500
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16136; Wed, 16 Dec 92 15:29:14 -0500
Message-Id: <9212162029.AA16136@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Wed, 16 Dec 1992 15:32:08 -0400
To: info-dylan@cambridge.apple.com, jra@gensym.com (Jim Allard)
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: IEEE NaN and Trichotomy

>Being somewhat of a late-comer to the discussion I don't know if this has been
>addressed before, but I wanted to address my surprise at the explicit rejection
>of IEEE NaN comparison behavior in Dylan.
>
>On pages 75 and 147 there are mentions that floats follow IEEE conventions
>except within comparisons, where the IEEE behavior would harm trichotomy and
>therefore cannot be used.  No alternate behavior is described.  Though I do not
>know what within the language depends on trichotomy and so cannot know the
>fallout of this suggestion, I would urge the Dylan designers to revisit this
>issue and consider adopting a fully compliant IEEE float behavior.
>
>I also have a suggestion (which may be completely wrong) that partial orderings
>could be handled if the possibility is allowed of users optionally writing more
>binaryX comparitor methods, which would be used by comparitors other than = and
>< when available, but still falling back to the two required comparitors when
>the optional ones weren`t supplied.
>
>My concerns about dropping IEEE NaN comparisons maninly have to do with
>implementation speed issues made difficult by this choice.  Other concerns for
>me would be getting Dylan users to understand a non-compliant behavior and
>Dylan missing out on industrial standards and practices that tie-in with the
>IEEE standard.
>
[Much detail elided.]
>
>Any thoughts or interest on this?

The idea behind requiring trichotomy is to allow all comparisons to be done
with a single call to binary< or binary=:
  (<= a b) => (not (> a b)) => (not (binary< b a))

Of course, introducing a NOT makes this <= differ from IEEE comparison,
since all comparisons involving NaNs are supposed to return #f.  The
presumption is (and we should be more explicit about this in the book) that
the implementor will use the normal IEEE operations for binary< and
binary=.  Then <=, >=, etc. will work correctly so long as no input is a
NaN, and will give the (IEEE) wrong answer when presented with a NaN.

So this choice (making Dylan's comparison operators differ from IEEE
comparisons) *was* made with performance issues in mind.  Other issues
involved are ease of programmer-defined comparisons (the Dylan programmer
only defines 2 comparison methods, rather than 7 or 16 or however many IEEE
ones might have to be defined), and possibility of clever compiler
optimizations (dropping trichotomy limits the inferences possible from (> b
a)).

I think that the majority of Dylan programs and programmers will benefit
from the current definition of comparison operations, which agrees with the
usual mathematical interpretation.  That said, your arguments about use of
NaNs are compelling.  So I'd propose adding an IEEE library to Dylan which
defines IEEE comparison operators in the way you suggest -- providing
default methods for binary<= and binary>=, etc.  The IEEE library could
define all the other IEEE-required functions, too.  Note that the Dylan
module system would allow you to choose whether to use <, <=, etc. (the
Dylan names) to refer to the IEEE comparisons, or to rename them to names
which don't conflict with the standard names.

I haven't thought about whether partial order comparisons are the same or
different from IEEE comparison operators.


From info-dylan-request Fri Dec 18 15:03:41 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15970; Fri, 18 Dec 92 15:03:43 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15966; Fri, 18 Dec 92 15:03:41 -0500
Received: from uu4.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28826; Fri, 18 Dec 92 15:10:42 -0500
	for info-dylan@cambridge.apple.com
Received: from tahiti.UUCP by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA08752; Fri, 18 Dec 92 14:48:47 -0500
Received: from uruguay.evtech.com by evtech.com (4.1/SMI-4.1)
	id AA03458; Fri, 18 Dec 92 13:36:25 CST
Date: Fri, 18 Dec 92 13:36:25 CST
From: jbone@evtech.com (Jeff Bone)
Message-Id: <9212181936.AA03458@evtech.com>
To: info-dylan@cambridge.apple.com
Subject: which jbone@splat.dell.com



From moon Fri Dec 18 18:06:54 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20257; Fri, 18 Dec 92 18:07:02 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20251; Fri, 18 Dec 92 18:06:54 -0500
Message-Id: <9212182306.AA20251@cambridge.apple.com>
Date: Fri, 18 Dec 92 18:09:25 EST
From: moon (David A. Moon)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: collection classes
Cc: info-dylan@cambridge.apple.com

> Date: Fri, 4 Dec 1992 18:12:25 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> 
> I've implemented the collection classes and have the following wish list:
> ....
>  The following insertion function's are very useful for many sequences classes
>  (like gap-list's).  It is difficult to write many of the sequence methods 
>  because `add' does not specify where the new-element is inserted.
> 
>  (define-generic-function insert (sequence new-element insertion-position))
>  (define-generic-function insert! (mutable-sequence new-element insertion-position))
>  (define-generic-function insert-sequence 
>      (sequence insertion-sequence insertion-position))
>  (define-generic-function insert-sequence!
>      (mutable-sequence insertion-sequence insertion-position))
> ....
>   (define-generic-function concatenate! (mutable-sequence #rest rest-sequences))

I believe all of these are subsumed by an improved version of replace-subsequence! that 
we are thinking about and will probably adopt.  I like the idea of one function doing the 
work of five.

>   I would also like to see the following destructively functions added:
>   (define-generic-function choose! (predicate mutable-sequence))
>   (define-generic-function choose-by! (predicate test-sequence mutable-value-sequence))

I don't understand what you propose these will do.

> ....
>   There seems no reason to me why a setter was not provided for `last':
>   (define-generic-function (setter last) (new-value mutable-sequence)) 

Good point, I think we should add this.  By the way in Dylan the new-value
argument goes at the end.

>   I would like to see <table> take `test:' as an init-keyword:
>   (make <table> #key (test =))

In general this is a good idea but there are a lot of very complex issues
associated with it and we would need to see a specific proposal.

From owner-info-dylan Sat Dec 19 14:43:50 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18247; Sat, 19 Dec 92 14:43:50 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18243; Sat, 19 Dec 92 14:43:50 -0500
Received: from comback.login.qc.ca by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00319; Sat, 19 Dec 92 14:51:25 -0500
	for info-dylan@brazil.cambridge.apple.com
Received: by comback.login.qc.ca (/\==/\ Smail3.1.21.1 #21.6)
	id <m0n3A6n-0000CsC@comback.login.qc.ca>; Sat, 19 Dec 92 14:45 EST
Received: by mtrpls (920330.SGI/920502.SGI.AUTO)
	for comback!cambridge.apple.com!info-dylan id AA25426; Sat, 19 Dec 92 14:41:00 -0500
Date: Sat, 19 Dec 92 14:41:00 -0500
From: comback!mtrpls!kaveh@brazil.cambridge.apple.com (Kaveh Kardan)
Message-Id: <9212191941.AA25426@mtrpls>
To: info-dylan@cambridge.apple.com
Subject: Dylan schedule


What is the time frame for freezing the definition of Dylan?  I am assuming
this will be necessary before Apple releases a commercial Dylan for the Mac.

Kaveh
------------
Kaveh Kardan                                        kaveh@mtrpls.login.qc.ca
Metropolis Graphics Ltd
Montreal Canada                                     phone/fax: (514)842-6172

From owner-info-dylan Sun Dec 20 12:24:39 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22143; Sun, 20 Dec 92 12:24:41 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22138; Sun, 20 Dec 92 12:24:39 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01381; Sun, 20 Dec 92 12:32:20 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Sun, 20 Dec 1992 18:24:33 +0100
Received: by miles.ircam.fr, Sun, 20 Dec 1992 18:24:31 +0100
Date: Sun, 20 Dec 1992 18:24:31 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212201724.AA00310@miles.ircam.fr>
To: moon@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: David A. Moon's message of Fri, 18 Dec 92 18:09:25 EST <9212182306.AA20251@cambridge.apple.com>
Subject: collection classes

   Date: Fri, 18 Dec 92 18:09:25 EST
   From: moon@cambridge.apple.com (David A. Moon)

   ...  By the way in Dylan the new-value argument goes at the end ...

I previously proposed to change Dylan so that the new-value parameter
is first in the parameter list of a setter function.  I feel very
strongly about this and here's why.

The problem is felt when there are `#rest' args.  First, resulting
parameter lists are ugly:

  (define-method (setter aref) ((array <array>) #rest indices-and-new-value) ...)

Second, it is computationally expensive (in both time and space) to
strip off the new-value argument.  Maybe this wouldn't cost for
builtin functions like `aref' that have special compiler support, but
it will for user-defined setter functions with `#rest'.

Third, the new-value argument really doesn't belong there: it's
not part of the #rest args.

Fourth, there is no way to dispatch on the type of the new-value.  This
gets back to the response to one of my earlier comments by David Moon:

   Date: Wed, 30 Sep 92 15:57:04 EDT
   From: moon@cambridge.apple.com (David A. Moon)

   ...
   > Finally, now that Dylan has types, there are no rules for
   > type-checking.  For instance, what types of objects can someone
   > legally assign to another object of a given type.

   There is no operation in Dylan that assigns an object to another object.  
   Dylan does not have any operation like = in C++.

   I think you'll find that all of what you would call Dylan's type checking 
   rules are expressed in terms of method applicability.  That simplification is 
   quite intentional on the part of the language designers, I believe.

My point is that without an ability to define new-value's type,
there's no way to have the legality of assignment automatically
subsumed under method applicability.  

It seems to me that the only advantage to have the new-value parameter
at the end is that a `setter' function call would look very similar to
a `set!'.

  ((setter aref) a 1 2 99.0)  ~= (set! (aref a 1 2) 99.0)

I can understand that desire, but to me the price is too high and the
alternative is acceptable:

  ((setter aref) 99.0 a 1 2)

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784096
bachrach@ircam.fr

From owner-info-dylan Sun Dec 20 12:36:59 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22748; Sun, 20 Dec 92 12:37:00 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22742; Sun, 20 Dec 92 12:36:59 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01454; Sun, 20 Dec 92 12:44:41 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Sun, 20 Dec 1992 18:36:55 +0100
Received: by miles.ircam.fr, Sun, 20 Dec 1992 18:36:53 +0100
Date: Sun, 20 Dec 1992 18:36:53 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212201736.AA00327@miles.ircam.fr>
To: moon@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: David A. Moon's message of Fri, 18 Dec 92 18:09:25 EST <9212182306.AA20251@cambridge.apple.com>
Subject: choose! and choose

   Date: Fri, 18 Dec 92 18:09:25 EST
   From: moon@cambridge.apple.com (David A. Moon)

   > Date: Fri, 4 Dec 1992 18:12:25 +0100
   > From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
   > ...
   >   I would also like to see the following destructively functions added:
   >   (define-generic-function choose! (predicate mutable-sequence))
   >   (define-generic-function choose-by! (predicate test-sequence mutable-value-sequence))

   I don't understand what you propose these will do.

They would be more powerful `remove!' functions that take a general
predicate instead of an element to remove (as in `remove!').  They
would mutate the mutable-sequence such that only the ``chosen''
elements remain.  They return the mutated argument.

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784096
bachrach@ircam.fr


From owner-info-dylan Sun Dec 20 12:58:36 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23747; Sun, 20 Dec 92 12:58:38 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23743; Sun, 20 Dec 92 12:58:36 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01526; Sun, 20 Dec 92 13:06:20 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Sun, 20 Dec 1992 18:24:33 +0100
Received: by miles.ircam.fr, Sun, 20 Dec 1992 18:24:31 +0100
Date: Sun, 20 Dec 1992 18:24:31 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212201724.AA00310@miles.ircam.fr>
To: moon@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: David A. Moon's message of Fri, 18 Dec 92 18:09:25 EST <9212182306.AA20251@cambridge.apple.com>
Subject: collection classes

   Date: Fri, 18 Dec 92 18:09:25 EST
   From: moon@cambridge.apple.com (David A. Moon)

   ...  By the way in Dylan the new-value argument goes at the end ...

I previously proposed to change Dylan so that the new-value parameter
is first in the parameter list of a setter function.  I feel very
strongly about this and here's why.

The problem is felt when there are `#rest' args.  First, resulting
parameter lists are ugly:

  (define-method (setter aref) ((array <array>) #rest indices-and-new-value) ...)

Second, it is computationally expensive (in both time and space) to
strip off the new-value argument.  Maybe this wouldn't cost for
builtin functions like `aref' that have special compiler support, but
it will for user-defined setter functions with `#rest'.

Third, the new-value argument really doesn't belong there: it's
not part of the #rest args.

Fourth, there is no way to dispatch on the type of the new-value.  This
gets back to the response to one of my earlier comments by David Moon:

   Date: Wed, 30 Sep 92 15:57:04 EDT
   From: moon@cambridge.apple.com (David A. Moon)

   ...
   > Finally, now that Dylan has types, there are no rules for
   > type-checking.  For instance, what types of objects can someone
   > legally assign to another object of a given type.

   There is no operation in Dylan that assigns an object to another object.  
   Dylan does not have any operation like = in C++.

   I think you'll find that all of what you would call Dylan's type checking 
   rules are expressed in terms of method applicability.  That simplification is 
   quite intentional on the part of the language designers, I believe.

My point is that without an ability to define new-value's type,
there's no way to have the legality of assignment automatically
subsumed under method applicability.  

It seems to me that the only advantage to have the new-value parameter
at the end is that a `setter' function call would look very similar to
a `set!'.

  ((setter aref) a 1 2 99.0)  ~= (set! (aref a 1 2) 99.0)

I can understand that desire, but to me the price is too high and the
alternative is acceptable:

  ((setter aref) 99.0 a 1 2)

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784096
bachrach@ircam.fr

From owner-info-dylan Tue Dec 22 12:17:07 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21599; Tue, 22 Dec 92 12:17:09 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21594; Tue, 22 Dec 92 12:17:07 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05846; Tue, 22 Dec 92 12:25:09 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA25613; Tue, 22 Dec 92 12:18:11 EST
Received: from ireland.gensym by gensym.com (4.1/SMI-4.1)
	id AA01893; Tue, 22 Dec 92 12:02:08 EST
Date: Tue, 22 Dec 92 12:02:08 EST
From: jra@gensym.com (Jim Allard)
Message-Id: <9212221702.AA01893@gensym.com>
Received: by ireland.gensym (4.1/SMI-4.1)
	id AA03520; Tue, 22 Dec 92 12:05:52 EST
To: info-dylan@cambridge.apple.com
In-Reply-To: Robert A. Cassels's message of Wed, 16 Dec 1992 15:32:08 -0400 <9212162029.AA16136@cambridge.apple.com>
Subject: Re: IEEE NaN and Trichotomy

Robert Cassels responds:

> The idea behind requiring trichotomy is to allow all comparisons to be done
> with a single call to binary< or binary=:
>   (<= a b) => (not (> a b)) => (not (binary< b a))

Sorry I missed that conversion.  I guess I hadn't got enough Wheaties or
something that day.  I think that I've been so immersed in the asymmetry of
IEEE floats that it didn't occur to me.

> So this choice (making Dylan's comparison operators differ from IEEE
> comparisons) *was* made with performance issues in mind.

I agree that a single, additional "not" is an insignificant cost.  Perhaps I
should have sprinkled some smileys in my note?  Arguments about language
design and politics are similar in that everyone believes they are dead right,
even though the range of opinions on a topic may be miles wide.  As I've
mentioned before, I never intend to minimize the architect's difficulties in
making the trade-offs required to complete a language design, and I do really
like Dylan.  But if we all agreed all the time what would there be to discuss?

Anyway, you might still find some who would triumphantly point to this one
"not" instruction and then denigrate high-level languages as always slower
than macho low-level languages, but my previous performance criticism is now
reduced to a desire to not give those folks any ground to stand on.  I do
still beleive arithmetic is one of these litmus tests for the C programmer
types that you hope to draw to Dylan.

As an FYI about my motivation for the comparison implementation options in my
previous note, I kept looking for a way to avoid giving the "wrong" IEEE
answer.  I was inclined towards this approach since I felt it was consistent
with the pains that have been taken to keep Dylan "safe", so I had expected an
error on NaN comparison.

> Other issues involved are ease of programmer-defined comparisons...

> I think that the majority of Dylan programs and programmers will benefit
> from the current definition of comparison operations, which agrees with the
> usual mathematical interpretation.  That said, your arguments about use of
> NaNs are compelling.  So I'd propose adding an IEEE library to Dylan which
> defines IEEE comparison operators in the way you suggest -- providing
> default methods for binary<= and binary>=, etc.  The IEEE library could
> define all the other IEEE-required functions, too.  Note that the Dylan
> module system would allow you to choose whether to use <, <=, etc. (the
> Dylan names) to refer to the IEEE comparisons, or to rename them to names
> which don't conflict with the standard names.

I agree with the desire for ease of comparison definitions and including the
math operations in a module is fine.  I still would be a little concerned that
the subtle difference in behavior between Dylan <= and IEEE-math <= could be a
source of confusion for novice users.  That was the reason I made the
suggestion that I did for these methods.  In the absence of binary<= methods,
they would provide the existing behavior.

Jim

-------------------------------------------------------------------------------
Jim Allard                                        jra@gensym.com
Manager of Languages, Interpreters, & Compilers   (617) 547-2500
Gensym Corporation
125 CambridgePark Drive
Cambridge, MA  02140
-------------------------------------------------------------------------------

From cassels Tue Dec 22 15:11:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24056; Tue, 22 Dec 92 15:11:57 -0500
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24050; Tue, 22 Dec 92 15:11:53 -0500
Message-Id: <9212222011.AA24050@cambridge.apple.com>
Date: Tue, 22 Dec 1992 15:15:30 -0400
To: info-dylan@cambridge.apple.com, jra@gensym.com (Jim Allard)
From: Robert A. Cassels <cassels@cambridge.apple.com>
X-Sender: cassels@ministry.cambridge.apple.com
Subject: Re: IEEE NaN and Trichotomy

At 12:02 PM 12/22/92 -0500, Jim Allard wrote:
>Robert Cassels responds:
>
>> The idea behind requiring trichotomy is to allow all comparisons to be done
>> with a single call to binary< or binary=:
>>   (<= a b) => (not (> a b)) => (not (binary< b a))
>
>Sorry I missed that conversion.  I guess I hadn't got enough Wheaties or
>something that day.  I think that I've been so immersed in the asymmetry of
>IEEE floats that it didn't occur to me.
>
>> So this choice (making Dylan's comparison operators differ from IEEE
>> comparisons) *was* made with performance issues in mind.
>
>I agree that a single, additional "not" is an insignificant cost.  Perhaps I
>should have sprinkled some smileys in my note?  Arguments about language
>design and politics are similar in that everyone believes they are dead right,
>even though the range of opinions on a topic may be miles wide.  As I've
>mentioned before, I never intend to minimize the architect's difficulties in
>making the trade-offs required to complete a language design, and I do really
>like Dylan.  But if we all agreed all the time what would there be to discuss?
>
>Anyway, you might still find some who would triumphantly point to this one
>"not" instruction and then denigrate high-level languages as always slower
>than macho low-level languages, but my previous performance criticism is now
>reduced to a desire to not give those folks any ground to stand on.  I do
>still beleive arithmetic is one of these litmus tests for the C programmer
>types that you hope to draw to Dylan.

Of course the compiler would turn (not (binary< ...)) into the most
efficient machine instruction(s), which might be a branch-less-or-equal and
wouldn't necessarily need an explicit "not" instruction.  The issue here
isn't what machine instructions get generated (I assume we can write
sufficiently clever compilers), but what the programmer writes to get what
effect.

>As an FYI about my motivation for the comparison implementation options in my
>previous note, I kept looking for a way to avoid giving the "wrong" IEEE
>answer.  I was inclined towards this approach since I felt it was consistent
>with the pains that have been taken to keep Dylan "safe", so I had expected an
>error on NaN comparison.

I have no objection to signalling an exception on NaN comparisons.  (It's
what I did with NaN comparisons for Symbolics machines.)  I haven't looked
at what performance implications that might have on which platforms.  (And
you're concerned about a "not" instruction.  :-)

>> Other issues involved are ease of programmer-defined comparisons...
>
>> I think that the majority of Dylan programs and programmers will benefit
>> from the current definition of comparison operations, which agrees with the
>> usual mathematical interpretation.  That said, your arguments about use of
>> NaNs are compelling.  So I'd propose adding an IEEE library to Dylan which
>> defines IEEE comparison operators in the way you suggest -- providing
>> default methods for binary<= and binary>=, etc.  The IEEE library could
>> define all the other IEEE-required functions, too.  Note that the Dylan
>> module system would allow you to choose whether to use <, <=, etc. (the
>> Dylan names) to refer to the IEEE comparisons, or to rename them to names
>> which don't conflict with the standard names.
>
>I agree with the desire for ease of comparison definitions and including the
>math operations in a module is fine.  I still would be a little concerned that
>the subtle difference in behavior between Dylan <= and IEEE-math <= could be a
>source of confusion for novice users.  That was the reason I made the
>suggestion that I did for these methods.  In the absence of binary<= methods,
>they would provide the existing behavior.

I suspect that "novice" users would be confused by the asymmetry of IEEE
comparisons.


From alms Tue Dec 22 15:16:23 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24113; Tue, 22 Dec 92 15:16:26 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24109; Tue, 22 Dec 92 15:16:23 -0500
Message-Id: <9212222016.AA24109@cambridge.apple.com>
Date: Tue, 22 Dec 1992 15:27:15 -0500
To: info-dylan@cambridge.apple.com, jra@gensym.com (Jim Allard),
        Robert A. Cassels <cassels@cambridge.apple.com>
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: IEEE NaN and Trichotomy

At  3:15 PM 12/22/92 -0400, Robert A. Cassels wrote:
> At 12:02 PM 12/22/92 -0500, Jim Allard wrote:
> >Robert Cassels responds:
> >
> 
> >As an FYI about my motivation for the comparison implementation options in my
> >previous note, I kept looking for a way to avoid giving the "wrong" IEEE
> >answer.  I was inclined towards this approach since I felt it was consistent
> >with the pains that have been taken to keep Dylan "safe", so I had expected an
> >error on NaN comparison.
> 
> I have no objection to signalling an exception on NaN comparisons.  (It's
> what I did with NaN comparisons for Symbolics machines.)  I haven't looked
> at what performance implications that might have on which platforms.  (And
> you're concerned about a "not" instruction.  :-)

If my memory serves me correctly, signalling an exception on NaN comparisons
wouldn't bee IEEE compatible.  You have to return #f.

  -Andrew


From moon Wed Dec 23 12:03:12 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00394; Wed, 23 Dec 92 12:03:14 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00390; Wed, 23 Dec 92 12:03:12 -0500
Message-Id: <9212231703.AA00390@cambridge.apple.com>
Date: Wed, 23 Dec 92 12:06:12 EST
From: moon (David A. Moon)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: choose! and choose
Cc: info-dylan@cambridge.apple.com

> Date: Sun, 20 Dec 1992 18:36:53 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> 
>    Date: Fri, 18 Dec 92 18:09:25 EST
>    From: moon@cambridge.apple.com (David A. Moon)
> 
>    > Date: Fri, 4 Dec 1992 18:12:25 +0100
>    > From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
>    > ...
>    >   I would also like to see the following destructively functions added:
>    >   (define-generic-function choose! (predicate mutable-sequence))
>    >   (define-generic-function choose-by! (predicate test-sequence mutable-value-sequence))
> 
>    I don't understand what you propose these will do.
> 
> They would be more powerful `remove!' functions that take a general
> predicate instead of an element to remove (as in `remove!').  They
> would mutate the mutable-sequence such that only the ``chosen''
> elements remain.  They return the mutated argument.

Now I see what you mean.  That seems like a reasonable idea.

From owner-info-dylan Mon Dec 28 16:47:02 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15185; Mon, 28 Dec 92 16:47:04 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15181; Mon, 28 Dec 92 16:47:02 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13566; Mon, 28 Dec 92 16:55:49 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA23735; Mon, 28 Dec 92 16:48:38 EST
Received: from ireland.gensym by gensym.com (4.1/SMI-4.1)
	id AA07236; Mon, 28 Dec 92 15:58:13 EST
Date: Mon, 28 Dec 92 15:58:13 EST
From: jra@gensym.com (Jim Allard)
Message-Id: <9212282058.AA07236@gensym.com>
Received: by ireland.gensym (4.1/SMI-4.1)
	id AA00314; Mon, 28 Dec 92 16:02:35 EST
To: info-dylan@cambridge.apple.com
Subject:  Re: IEEE NaN and Trichotomy

Robert Cassels writes:

>Of course the compiler would turn (not (binary< ...)) into the most
>efficient machine instruction(s), which might be a branch-less-or-equal and
>wouldn't necessarily need an explicit "not" instruction.  The issue here
>isn't what machine instructions get generated (I assume we can write
>sufficiently clever compilers), but what the programmer writes to get what
>effect.

Actually, I believe the compiler would not be allowed to perform this
transformation, since it would change the IEEE result for NaN arguments.  Weird
stuff, isn't it?

Andrew LM Shalit writes:

>If my memory serves me correctly, signalling an exception on NaN comparisons
>wouldn't bee IEEE compatible.  You have to return #f.

I must admit, I have only read things written by others who I must assume read
the standard.  In those documents there appeared to be two valid choices,
signalling or returning NaNs.

Jim

-------------------------------------------------------------------------------
Jim Allard                                        jra@gensym.com
Manager of Languages, Interpreters, & Compilers   (617) 547-2500
Gensym Corporation
125 CambridgePark Drive
Cambridge, MA  02140
-------------------------------------------------------------------------------

From owner-info-dylan Thu Dec 31 10:36:58 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12827; Thu, 31 Dec 92 10:36:59 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12823; Thu, 31 Dec 92 10:36:58 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01301; Thu, 31 Dec 92 10:46:09 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Thu, 31 Dec 1992 16:37:39 +0100
Received: by miles.ircam.fr, Thu, 31 Dec 1992 16:37:35 +0100
Date: Thu, 31 Dec 1992 16:37:35 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199212311537.AA09127@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: define and set! with multiple-values

I propose to extend `set!' and `define' to allow accomodate
multiple-values.  The syntax would be:

  (set! place-1 place-2 ... new-value) => new-value

which could be translated into:

  (bind ((tmp-1 tmp-2 ... new-value))
    (set! place-1 tmp-1)	
    (set! place-2 tmp-2)	
    ...
    (values tmp-1 tmp-2 ...))

an example would be:

  ? (set! x y (location window))
  10
  20
  ?

Along these lines I also propose to extend define to accomodate
multiple-values as follows

  (define variable-name-1 variable-name-2 ... initial-value) =>
    (values variable-name-1 variable-name-2 ...)

Of course I propose to allow variable-name-k to include a type
declaration as in:

  ? (define (x <integer>) (y <integer>) (location window))
  x
  y
  ?

This extension is completely backward compatible with the current
Dylan specification.

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784096
bachrach@ircam.fr

From owner-info-dylan Thu Dec 31 11:27:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14092; Thu, 31 Dec 92 11:27:36 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14088; Thu, 31 Dec 92 11:27:35 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01504; Thu, 31 Dec 92 11:36:48 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA20209@relay.tek.com>; Thu, 31 Dec 92 08:23:08 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA03845; Thu, 31 Dec 92 08:23:29 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA11433; Thu, 31 Dec 92 08:11:11 PST
Date: Thu, 31 Dec 92 08:11:11 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9212311611.AA11433@goldfish.MITRON.TEK.COM>
To: info-dylan@cambridge.apple.com
In-Reply-To: Jonathan Bachrach's message of Thu, 31 Dec 1992 16:37:35 +0100 <199212311537.AA09127@miles.ircam.fr>
Subject: define and set! with multiple-values

   Date: Thu, 31 Dec 1992 16:37:35 +0100
   From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
   I propose to extend `set!' and `define' to allow accomodate
   multiple-values.  The syntax would be:
   ... specific proposal omitted ...

I would rather see your goals met by usign a more general solution:
macros (i.e. syntax extensions). What is the status of macros for
Dylan?

Rather than having multiple and possibly conflicting proposals for
changing this, that, and the other standard Dylan special form, Dylan
needs a macro facility. This should allow everyone to develop
portable, new, special forms that others can choose to use (and
modify) to their hearts' content. If some new syntax becomes widely
used and succesful, then it would have empirical evidence for being
adopted into the language proper.

I don't care if the macros are hygienic or not, but something is
needed before too long.
--
Patrick Logan         patl@goldfish.mitron.tek.com
Mitron Corporation    (503) 690-8350    FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006

From owner-info-dylan Thu Dec 31 11:38:52 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14375; Thu, 31 Dec 92 11:38:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14371; Thu, 31 Dec 92 11:38:52 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01538; Thu, 31 Dec 92 11:48:06 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212311648.AA01538@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa16301; 31 Dec 92 11:40:05 EST
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of Thu, 31 Dec 92 16:37:35 +0100.
             <199212311537.AA09127@miles.ircam.fr> 
Date: Thu, 31 Dec 92 11:39:55 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    I propose to extend `set!' and `define' to allow accomodate
    multiple-values.

Can you give some exaples showing how these new forms would improve the
expressiveness or clarity of a program?  Or are you just proposing these
for the sake of symmetry?  That's a slippery slope...

I rather like the current scheme in which the curse of multiple values is
confined to a single form, BIND.  In fact, I'd like to find some way to
eliminate Common-Lisp-like multiple values from DYLAN altogether.  There
must be some better way to pass back possibly useful but rarely used extra
information from a function to its caller.

-- Scott


From owner-info-dylan Thu Dec 31 11:54:56 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14678; Thu, 31 Dec 92 11:54:57 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14674; Thu, 31 Dec 92 11:54:56 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01609; Thu, 31 Dec 92 12:04:10 -0500
	for info-dylan@cambridge.apple.com
Return-Path: <john@linus.mitre.org>
Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S)
	id AA17332; Thu, 31 Dec 92 11:56:48 -0500
Posted-Date: Thu, 31 Dec 92 11:56:44 EST
Received: by thelonius.mitre.org (5.61/RCF-4C)
	id AA16148; Thu, 31 Dec 92 11:56:45 -0500
Message-Id: <9212311656.AA16148@thelonius.mitre.org>
To: info-dylan@cambridge.apple.com
Subject: define and set! with multiple values
Date: Thu, 31 Dec 92 11:56:44 EST
From: john@linus.mitre.org

Jonathan Bachrach (Jonathan.Bachrach%ircam.FR@princeton.edu) writes:

  I propose to extend `set!' and `define' to allow accomodate
  multiple-values.  The syntax would be:

    (SET! PLACE-1 PLACE-2 ... NEW-VALUE) => NEW-VALUE

I think the goal is a good one, but I'd suggest a different syntax:
using a VALUES form as the place instead:

  (SET! (VALUES PLACE-1 PLACE-2 ...) NEW-VALUE)

Or, translating your later example:

  (SET! (VALUES X Y) (LOCATION WINDOW))

I believe this has a number of advantages.  First, the current
(simpler) syntax is retained: SET! still takes two arguments, a place
form and a new-values form.  Thus, multiple values are not treated as
a (particularly) special case.

Second, conceptual clarity: SET! can still be explained as it
currently is on page 61:

  Subsequent evaluations of PLACE will yield NEW-VALUE.

Again using your example, (VALUES X Y) is made to return whatever
(LOCATION WINDOW)) returns, by in turn altering X and Y.  In another
example, SET! can be used to swap two (or "rotate" more) values, e.g.

  (SET! (VALUES OLD NEW) (VALUES NEW OLD))

This can be done with your syntax, but I find the above much clearer
than

  (SET! OLD NEW (VALUES NEW OLD))

Third, the VALUES syntax is more compatible with other Lisps,
including CommonLisp, where the VALUES form of SETF is a common
extension.  Moreover, the CommonLisp analogue, SETF, actually takes
any number of place/new-value pairs, e.g.

  (SETF PI      (COMPUTE-PI 10)
        HALF-PI (/ PI 2))

Your proposal would disallow this.

Finally, the VALUES syntax could be implemented (probably) with a
macro extension to SET!, as is usually done in CommonLisp.  I think
this is in line with what Patrick Logan (patl@goldfish.mitron.tek.com)
suggested:

  I would rather see your goals met by using a more general solution:
  macros (i.e. syntax extensions).

Your proposal requires completely NEW syntax, however.

As for extending DEFINE! in a similar manner, I think that could be
done using the VALUES syntax as well, though I find it less important
than for SET! case.

John Burger
john@mitre.org

From owner-info-dylan Thu Dec 31 13:46:12 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16324; Thu, 31 Dec 92 13:46:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16320; Thu, 31 Dec 92 13:46:12 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01883; Thu, 31 Dec 92 13:55:26 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA13306; Thu, 31 Dec 92 13:48:01 EST
Received: from thailand.gensym by gensym.com (4.1/SMI-4.1)
	id AA10900; Thu, 31 Dec 92 13:41:14 EST
Date: Thu, 31 Dec 92 13:41:14 EST
From: bhyde@gensym.com (Ben A. Hyde)
Message-Id: <9212311841.AA10900@gensym.com>
Received: by thailand.gensym (4.1/SMI-4.1)
	id AA17095; Thu, 31 Dec 92 13:48:43 EST
To: info-dylan@cambridge.apple.com
Subject: re: define and set! with multiple-values 

> Scott_Fahlman writes...
> Can you give some examples showing how these new forms would improve the
> expressiveness or clarity of a program?  Or are you just proposing these
> for the sake of symmetry?  That's a slippery slope...

Hear Hear!

> I rather like the current scheme in which the curse of multiple values is
> confined to a single form, BIND.  In fact, I'd like to find some way to
> eliminate Common-Lisp-like multiple values from DYLAN altogether.  There
> must be some better way to pass back possibly useful but rarely used extra
> information from a function to its caller.

As a programmer I like and enjoy multiple return values, it would be
sad to see them go.  The one time I listen in on the implementation of
multiple return values in Lisp they added an amazing amount of
confusion to the design meetings about function calling.  The time
spent on that complexity would have bought lots of cool valuable
things.

It would be interesting research to find out what the complexity/pain
for programmer and implementer of stricter rules placing stricter
rules on return value count.

The current design is, to my mind, just right.  We know a lot about how
to implement this kind of design. We know that it is pleasant to
program in this design.  We don't know enought about stricter designs
other than that they seem (or are) unpleasant.

I hope we know how to implement the current design so that:
    Usage                                     Cost
 - Binds of single values                      None
 - Binds of multiple values.                   Slight
 - Calls where it is lexically apparent that
   - zero return values are needed             None
   - one return value is needed                None
   - Unknown return values are needed          None
 - Functions that return
   - one value                                 ~none
   - N values                                  N * ~none
More columns are needed for the sealed cases.

The C programmer, having been denied the pleasures of multiple return
values, will assume they are new, suspect and probably evil.  Making
the cost claim like the one above will go part way toward calming his
fears.

- ben hyde






From owner-info-dylan Thu Dec 31 14:59:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16905; Thu, 31 Dec 92 14:59:58 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16901; Thu, 31 Dec 92 14:59:57 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02013; Thu, 31 Dec 92 15:09:11 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9212312009.AA02013@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa16366; 31 Dec 92 15:01:36 EST
To: "Ben A. Hyde" <bhyde@GENSYM.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of Thu, 31 Dec 92 13:41:14 -0500.
             <9212311841.AA10900@gensym.com> 
Date: Thu, 31 Dec 92 15:01:22 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    As a programmer I like and enjoy multiple return values, it would be
    sad to see them go.

I think that makes you nearly unique.  The vast majority of Common Lisp
programmers I've talked to consider multiple values to be an ugly blot on
the language (one of many), but a perhaps-necessary evil.
Multiple values do make life *much* harder for implementors.

    It would be interesting research to find out what the complexity/pain
    for programmer and implementer of stricter rules placing stricter
    rules on return value count.
    
I wasn't suggesting "stricter rules on return value count".  I was
suggesting the very strict rule that *every* function should return exactly
one value, and if you want to pass back a bunch of things you do it in a
sequence or as a side effect or something like that.  Then count on the
"sufficiently smart compiler" to avoid having to actually heap-allocate the
return sequence.  But I don't have a specific proposal to make right now.

There are definitely cases where you want to return multiple values without
consing, and we must provide for these cases, but it seems a shame to
complicate normal function calls and returns in order to allow for these
relatively rare cases.

-- Scott

===========================================================================
Scott E. Fahlman			Internet:  sef+@cs.cmu.edu
Senior Research Scientist		Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University		Latitude:  40:26:33 N
5000 Forbes Avenue			Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================

From owner-info-dylan Thu Dec 31 15:52:09 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17423; Thu, 31 Dec 92 15:52:11 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17419; Thu, 31 Dec 92 15:52:09 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02111; Thu, 31 Dec 92 16:01:23 -0500
	for info-dylan@cambridge.apple.com
Return-Path: <ramsdell@linus.mitre.org>
Received: from celebes.mitre.org by linus.mitre.org (5.61/RCF-4S)
	id AA22952; Thu, 31 Dec 92 15:54:01 -0500
Posted-Date: Thu, 31 Dec 92 15:53:58 EST
Received: by celebes.mitre.org (5.61/RCF-4C)
	id AA00630; Thu, 31 Dec 92 15:53:59 -0500
Message-Id: <9212312053.AA00630@celebes.mitre.org>
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Cc: ramsdell@linus.mitre.org, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of "Thu, 31 Dec 92 15:01:22 EST."
             <9212312009.AA02013@brazil.cambridge.apple.com> 
Date: Thu, 31 Dec 92 15:53:58 EST
From: John D. Ramsdell <ramsdell@linus.mitre.org>

> From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
...
> Multiple values do make life *much* harder for implementors.

In Scheme implementations with compilers that use continuation-passing
conversion, a return of some number of values is transformed into an
application of the continuation to the return values, i.e., just
another procedure call.  Multiple values do not make life harder for
those implementations.  One of the reasons some people would like to
make sure that extra return values are not silently ignored is because
it allows implementations to use the same calling mechanism for both
calls and returns.

By the way, I like multiple return values is Scheme--I'm one of the
ones who lead the fight to have them accepted in Scheme's next revision!

John

From owner-info-dylan Thu Dec 31 16:21:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17713; Thu, 31 Dec 92 16:24:16 -0500
Received: from [90.1.0.15] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17697; Thu, 31 Dec 92 16:21:05 -0500
Received: from apple.com by jumbo.apple.com with SMTP (5.64/26-Oct-1992-eef)
	id AA19857; Thu, 31 Dec 92 13:27:00 PST
	for info-dylan@cambridge.apple.com
Received: from [90.133.56.37] by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA19555; Thu, 31 Dec 92 13:22:51 -0800
	for info-dylan@cambridge.apple.com
Message-Id: <9212312122.AA19555@apple.com>
Date: Thu, 31 Dec 1992 13:23:09 -0800
To: info-dylan@cambridge.apple.com
From: ksand@apple.com
Subject: re: define and set! with multiple-values

>As a programmer I like and enjoy multiple return values, it would be
>sad to see them go.  The one time I listen in on the implementation of
>multiple return values in Lisp they added an amazing amount of
>confusion to the design meetings about function calling.  The time
>spent on that complexity would have bought lots of cool valuable
>things.

Concerning the use of multiple return values, I've always wondered
what is the difference concerning returning multiple values and returning
a list (or a collection class object). In other words can't the programmer
already control the return statements?

Cheers,
Kent

---
ksand@apple.com


From owner-info-dylan Thu Dec 31 16:41:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17926; Thu, 31 Dec 92 16:41:58 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17922; Thu, 31 Dec 92 16:41:57 -0500
Received: from inet-gw-2.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02274; Thu, 31 Dec 92 16:51:13 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-2.pa.dec.com; id AA16959; Thu, 31 Dec 92 13:43:50 -0800
Received: by myrtle.pa.dec.com; id AA03946; Thu, 31 Dec 92 13:44:16 -0800
Message-Id: <9212312144.AA03946@myrtle.pa.dec.com>
To: ksand@apple.com
Cc: info-dylan@cambridge.apple.com
Subject: re: define and set! with multiple-values
In-Reply-To: Message of Thu, 31 Dec 1992 13:23:09 -0800
    from ksand@apple.com
    <9212312122.AA19555@apple.com>
Date: Thu, 31 Dec 92 13:44:15 -0800
From: meehan@src.dec.com
X-Mts: smtp


    Concerning the use of multiple return values, I've always wondered
    what is the difference concerning returning multiple values and returning
    a list (or a collection class object). In other words can't the programmer
    already control the return statements?

Sure, but you could make the same argument and say that all functions 
should be PASSED exactly one argument, since you can bundle up anything 
you like in a list.  It certainly complicates implementations to 
allow more than one argument to be passed to a function, but that's 
a price we're willing to pay.  Those of us on the "multiple values 
as continuations" bandwagon want the symmetry between calling and 
returning. 

From owner-info-dylan Thu Dec 31 16:50:33 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18092; Thu, 31 Dec 92 16:50:41 -0500
Received: from [90.1.0.15] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18086; Thu, 31 Dec 92 16:50:33 -0500
Received: from apple.com by jumbo.apple.com with SMTP (5.64/26-Oct-1992-eef)
	id AA20100; Thu, 31 Dec 92 13:56:34 PST
	for info-dylan@cambridge.apple.com
Received: from [90.133.56.37] by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA21521; Thu, 31 Dec 92 13:52:22 -0800
	for info-dylan@cambridge.apple.com
Message-Id: <9212312152.AA21521@apple.com>
Date: Thu, 31 Dec 1992 13:52:41 -0800
To: info-dylan@cambridge.apple.com
From: ksand@apple.com
Subject: re: define and set! with multiple-values

>    Concerning the use of multiple return values, I've always wondered
>    what is the difference concerning returning multiple values and returning
>    a list (or a collection class object). In other words can't the programmer
>    already control the return statements?

>Sure, but you could make the same argument and say that all functions 
>should be PASSED exactly one argument, since you can bundle up anything 
>you like in a list.  It certainly complicates implementations to 
>allow more than one argument to be passed to a function, but that's 
>a price we're willing to pay.  Those of us on the "multiple values 
>as continuations" bandwagon want the symmetry between calling and 
>returning. 

I see, so it's an issue of symmetry vs. asymmetry concerning calling
chains. There are implementations where one single parameter is allowed
to be passed (classical Mactoolbox PB calls), but those are usually
limitations based on the implementation (or variable argument use 
as with XCMD style standalone code).

So the ultimate issue is the culture, where C programmers happily accept
one return value, pointer or whatever, while the continuation people like
a more symmetric approach. Personally I think it's a question of experience
and learning, where the multiple values case could be suddenly something
useful, but from a practical point of view the need is not that earth
shattering.

Anyway, that's my private opinion.

Cheers,
Kent 
---
ksand@apple.com


From owner-info-dylan Thu Dec 31 16:57:49 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18214; Thu, 31 Dec 92 16:57:51 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18209; Thu, 31 Dec 92 16:57:49 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02365; Thu, 31 Dec 92 17:07:04 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA20582@relay.tek.com>; Thu, 31 Dec 92 13:51:36 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA09505; Thu, 31 Dec 92 13:53:00 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA13428; Thu, 31 Dec 92 13:40:41 PST
Date: Thu, 31 Dec 92 13:40:41 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9212312140.AA13428@goldfish.MITRON.TEK.COM>
To: info-dylan@cambridge.apple.com
In-Reply-To: ksand@apple.COM's message of Thu, 31 Dec 1992 13:23:09 -0800 <9212312122.AA19555@apple.com>
Subject: Benefit of multiple values.

   Date: Thu, 31 Dec 1992 13:23:09 -0800
   From: ksand@apple.COM
   Concerning the use of multiple return values, I've always wondered
   what is the difference concerning returning multiple values and returning
   a list (or a collection class object).

Having (values ...) and (bind ...) forms are a convenience factor for
returning multiple values, receiving multiple values, and choosing to
ignore some of the values returned. Forcing programmers to handle all
of this in data structures just provides more opportunities to get
something wrong.

With a macro facility, one could write macros to package a structure
and unpack it on the other end, but then if enough people like your
macros, why not make it a part of the language? Once it is a part of
the language then the compiler can step in and optimize things, like
put multiple values in registers or on the stack to reduce superfluous
cons'ing.
--
Patrick Logan         patl@goldfish.mitron.tek.com
Mitron Corporation    (503) 690-8350    FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006

From owner-info-dylan Thu Dec 31 21:26:39 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21357; Thu, 31 Dec 92 21:26:40 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21353; Thu, 31 Dec 92 21:26:39 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02774; Thu, 31 Dec 92 21:35:53 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by world.std.com (5.65c/Spike-2.0)
	id AA09136; Thu, 31 Dec 1992 21:28:21 -0500
Message-Id: <199301010228.AA09136@world.std.com>
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Cc: "Ben A. Hyde" <bhyde@GENSYM.COM>, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of "Thu, 31 Dec 92 15:01:22 EST."
             <9212312009.AA02013@brazil.cambridge.apple.com> 
Date: Thu, 31 Dec 92 21:28:20 -0500
From: Bob Kerns <rwk@world.std.com>

    Date: Thu, 31 Dec 92 15:01:22 EST
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    
        As a programmer I like and enjoy multiple return values, it would be
        sad to see them go.
    
    I think that makes you nearly unique.  The vast majority of Common Lisp
    programmers I've talked to consider multiple values to be an ugly blot on
    the language (one of many), but a perhaps-necessary evil.
    Multiple values do make life *much* harder for implementors.
    
In my experience, they're not that much work for implementors.

However, the single most annoying fault of C (besides syntax)
is the lack of multiple values.  The two kludgy workarounds,
namely passing arguments by reference and special purupose
data-structures just to hold the return values, are both
problematic from a semantic point of view, and impose both
an expressiveness cost and a modularity cost on the caller
of a module.

The idea that functions return a single value, or (as in C)
return either zero or one value is backwards.  It's a matter
of forcing the thinking to conform to the language, rather
than having the language support thinking clearly about the
algorithm.

If the majority of CL programmers you talk do don't like
multiple-values, I have to suspect that they're mostly
your students, and you're getting a biased sample.  Because
that doesn't square with my experience at all.

(Of course, such anecdotal surveys prove nothing, other than
that we have proven nothing.  My own sample, of course, may
be biased.  It's my *opinion* that most CL programmers do
like and appreciate multiple values.  I've heard far more
complaints that they aren't subject to number-of-values
checking than to their existance.  "Everyone" seems to like
them, they just can't agree what they should do).

Speculating for a moment, perhaps why you think they make
life harder for implementors is that the language makes it
hard to do type inferencing on multiple values because it
makes it hard to declare the types of the multiple values,
and because the "NIL if not supplied" rule makes things
into unions.  I claim that's not multiple values in the
abstract that causes the problem, but rather the specific
semantics in CL, and this could be fixed without throwing
out the baby with the bathwater.  (I'm not sure the optimizations
you'd gain are worth the trouble, however.)


From owner-info-dylan Fri Jan  1 14:19:09 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01447; Fri, 1 Jan 93 14:19:10 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01443; Fri, 1 Jan 93 14:19:09 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03398; Fri, 1 Jan 93 14:28:30 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9301011928.AA03398@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa17048; 1 Jan 93 14:20:35 EST
To: Bob Kerns <rwk@WORLD.STD.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of Thu, 31 Dec 92 21:28:20 -0500.
             <199301010228.AA09136@world.std.com> 
Date: Fri, 01 Jan 93 14:20:29 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    In my experience, they're not that much work for implementors.
    
I guess it depends on how hard you want to try to squeeze out that last
cycle or two of per-call overhead.  Implementing CL-style multiple-value
returns with *no* added cost to calls/returns that expect/return a single
value is difficult.

    However, the single most annoying fault of C (besides syntax)
    is the lack of multiple values.

I wouldn't have put this even in the top ten.  In any case, this is made
much worse in C by the lack of built-in, efficient dynamic storage
management.  In Lisp and Dylan, there is at least the alternative option of
creating and returning a sequence.

    If the majority of CL programmers you talk do don't like
    multiple-values, I have to suspect that they're mostly
    your students, and you're getting a biased sample.  Because
    that doesn't square with my experience at all.
    
Well, most are implementors who are influenced by their awareness of what's
going on inside.  And some are long-time Lispers who liked the conceptual
simplicity of pre-Common Lisps in which functions always return one value.

I don't have the statistics handy, and it may have changed over the years
as people got used to MV, but I believe that the fraction of calls in which
multiple values are returned and actually used by the caller is well below
1%.  So if this were the only consideration, I'd be inclined to say that we
should just return a sequence in those rare cases and count on good GC
technology to make that not too expensive.  that way, the 99+% case incurs
no overhead at all, and the language users have one less complication to
worry about.

There is another problem, however.  Maybe 10% of the functions *could*
return additional values that might be of interest to some of their
callers.  (I'm thinking of something like FLOOR in Common Lisp.)  It's
wasteful to discard these values, because the callers who do want them would
then have to make a second call to get the extra values.  It's wasteful to
return all the values in a sequence, because this makes extra work for the
majority of callers who want just the first value.  And it's wasteful of
space to have two versions of the function around, one returning single
values and one multiple.

So perhaps something like the current MV system in the Dylan book is the
best compromise after all.  I agree that we need improved declaration
facilities for return values, and that topic is being discussed.

Personally, I'd like a separate MV-BIND form to make it visually obvious
that multiple values are being accepted.  (Visually obvious to people, that
is -- compilers will have no trouble telling the MV syntax from the
single-value syntax by counting how many items live within each paren.)
I'm still not convinced that we need multiple values in SET! and DEFINE,
but I'm not violently opposed to this.

-- Scott

===========================================================================
Scott E. Fahlman			Internet:  sef+@cs.cmu.edu
Senior Research Scientist		Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University		Latitude:  40:26:33 N
5000 Forbes Avenue			Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================

From owner-info-dylan Sun Jan  3 11:17:45 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00392; Sun, 3 Jan 93 11:17:46 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00388; Sun, 3 Jan 93 11:17:45 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05107; Sun, 3 Jan 93 11:27:20 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA23926@relay.tek.com>; Sun, 3 Jan 93 08:04:41 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA22770; Sun, 3 Jan 93 08:06:02 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA16835; Sun, 3 Jan 93 07:53:25 PST
Date: Sun, 3 Jan 93 07:53:25 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9301031553.AA16835@goldfish.MITRON.TEK.COM>
To: info-dylan@cambridge.apple.com
In-Reply-To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU's message of Fri, 01 Jan 93 14:20:29 EST <9301011928.AA03398@brazil.cambridge.apple.com>
Subject: define and set! with multiple-values 

   Date: Fri, 01 Jan 93 14:20:29 EST
   From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
   I wouldn't have put this even in the top ten.  In any case, this is made
   much worse in C by the lack of built-in, efficient dynamic storage
   management.  In Lisp and Dylan, there is at least the alternative option of
   creating and returning a sequence.

It is also more convenient in LISPs to pass explicit continuations,
espeically continuations that share a lexical environment with the
calling procedure. (Incredibly awkward in C.) This hasn't been
mentioned yet in this thread of discussion and is an alternative
programmers with experience only in C or Pascal may overlook.
--
Patrick Logan         patl@goldfish.mitron.tek.com
Mitron Corporation    (503) 690-8350    FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006

From owner-info-dylan Sun Jan  3 16:47:56 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04115; Sun, 3 Jan 93 16:47:57 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04111; Sun, 3 Jan 93 16:47:56 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05407; Sun, 3 Jan 93 16:57:35 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by world.std.com (5.65c/Spike-2.0)
	id AA14899; Sun, 3 Jan 1993 16:49:44 -0500
Message-Id: <199301032149.AA14899@world.std.com>
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of "Fri, 01 Jan 93 14:20:29 EST."
             <199301011921.AA14311@world.std.com> 
Date: Sun, 03 Jan 93 16:49:43 -0500
From: Bob Kerns <rwk@world.std.com>

    Date: Fri, 01 Jan 93 14:20:29 EST
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    
        In my experience, they're not that much work for implementors.
        
    I guess it depends on how hard you want to try to squeeze out that last
    cycle or two of per-call overhead.  Implementing CL-style multiple-value
    returns with *no* added cost to calls/returns that expect/return a single
    value is difficult.

Not in my experience.  I don't mean it's *no* work for the
implementor, or that it doesn't require a little bit of thinking,
but the work required is pretty straight-forward and contained.
It's nothing compared to, doing efficient array access, or
having reasonable error messages and warnings, or making efficient
use of registers.  Of all the things a compiler-writer has to
worry about, I'd place this near the bottom of the list of
"difficult issues".

I agree that the techniques to do it with *no* added cost for
the single-value case, while simultaneously *minimizing* cost
for the multiple value case, you have to get achitecture-specific.
Those who implement portable implementations will need a small
library of techniques instead of a single technique, if they
want to take advantage of various interesting tricks you can
do to whittle down the cost of the multiple-value case.
    
        However, the single most annoying fault of C (besides syntax)
        is the lack of multiple values.
    
    I wouldn't have put this even in the top ten.  
It's a close race with the lack of lexical closures.  Both force
you to make datatypes just to communicate values between caller
and callee.
						   In any case, this is made
    much worse in C by the lack of built-in, efficient dynamic storage
    management.  In Lisp and Dylan, there is at least the alternative option of
    creating and returning a sequence.

But then you lose the advantage of declaring the return value type!

    ... FLOOR ...

    So perhaps something like the current MV system in the Dylan book is the
    best compromise after all.  I agree that we need improved declaration
    facilities for return values, and that topic is being discussed.

Ah, you made that argument for me.  Excellent.

    Personally, I'd like a separate MV-BIND form to make it visually obvious
    that multiple values are being accepted.  (Visually obvious to people, that
    is -- compilers will have no trouble telling the MV syntax from the
    single-value syntax by counting how many items live within each paren.)

I prefer the (set! (values x y z) ...) approach to the (set! (x y z) ...)
approach, for exactly this reason.

    I'm still not convinced that we need multiple values in SET! and DEFINE,
    but I'm not violently opposed to this.

I think something like this makes the significantly easier
to use, and helps to avoid cluttering the code in ways that
remind me of spurious datatypes and supplying NULL to C
by-reference arguments that you *hope* the programmer allowed
you to supply NULL to say you didn't want that silly return
value.  (A common source of bugs, I've found).

From owner-info-dylan Sun Jan  3 17:16:21 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04496; Sun, 3 Jan 93 17:16:22 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04491; Sun, 3 Jan 93 17:16:21 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05472; Sun, 3 Jan 93 17:25:59 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by world.std.com (5.65c/Spike-2.0)
	id AA16511; Sun, 3 Jan 1993 17:18:26 -0500
Message-Id: <199301032218.AA16511@world.std.com>
Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of "Sun, 03 Jan 93 16:49:43 EST."
             <199301032149.AA14899@world.std.com> 
Date: Sun, 03 Jan 93 17:18:25 -0500
From: Bob Kerns <rwk@world.std.com>

    Date: Sun, 03 Jan 93 16:49:43 -0500
    From: Bob Kerns <rwk@world.std.com>
    
    Not in my experience.  I don't mean it's *no* work for the
    implementor, or that it doesn't require a little bit of thinking,

By the way, as long as we're into C comparisonsm, what I've never
figured out how to squeeze out (except in certain unusual
architectures) is the cycle or so that goes to return NIL
in the case where in C the function would be declared VOID.

So if you meant to complain of the difficulty of optimizing
both the 1 AND ZERO value cases to the level of C, then yes,
I'll agree it's hard.  In fact, I suspect it's impossible in
many architectures.

If Dylan allowed you to declare zero return values in such
a way that the compiler could tell that it will effect *all*
callees as well as the caller, it could match this.

Of course, I think it's silly to spend too much time optimizing
out a single instruction.  Usually you could use the same time
to optimize out a dozen easier ones, weighted by frequency of
usage.

From owner-info-dylan Mon Jan  4 11:16:25 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17627; Mon, 4 Jan 93 11:16:26 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17623; Mon, 4 Jan 93 11:16:25 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06743; Mon, 4 Jan 93 11:26:09 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA01400; Mon, 4 Jan 93 11:18:34 EST
Received: from thailand.gensym by gensym.com (4.1/SMI-4.1)
	id AA01968; Mon, 4 Jan 93 10:47:38 EST
Date: Mon, 4 Jan 93 10:47:38 EST
From: bhyde@gensym.com (Ben A. Hyde)
Message-Id: <9301041547.AA01968@gensym.com>
Received: by thailand.gensym (4.1/SMI-4.1)
	id AA26289; Mon, 4 Jan 93 10:55:34 EST
To: info-dylan@cambridge.apple.com
Subject: Re: define and set! with multiple-values
  I think I've changed my mind.

  As far as I know it is not possible to implement safe
multiple values with out requiring many functions also set a value
count.  Thus:
  (defun foo (x)
    (+ x x))
must set the value count to as well as do the tiny bit of work
required to do the addition.  Meanwhile
  (defun bar (x)
    (gum x))
doesn't have to set it.

Notice this is the worse kind of purity v.s. efficiency trade off.
We are taxing most functions for a cost that benefits only a
very few functions.  Second, this cost can not be eliminated by a
compiler switch that proclaims that we want to run unsafe.

Such an "unsafe" switch would presumably just ignore the multiple
value count neither setting or checking it.  That doesn't work out
since one of the principle uses of the multiple values is to return an
exceptional additional value.  For example a flag indicating that the
first value is suspect...
  (defun do-next ()
    (multiple-value-bind (score suspect?) (get-value)
      (incf total-score score)
      (when suspect
        (decf confidence))))
The call tree below get-value may have a hundreds of individual
functions that compute get-value's return.  Maybe 20% of them return the
suspect?  flag.  A compiler switch that ignores the value count is
useless on code like this.

Just how bad is the cost of this one additional instruction to set the
return value?  Well that depends on your intuitions about the size
distribution of functions.  

In the system I'm currently working on we have tremendous numbers of
tiny little functions that are created by macros, so lexically they
are extremely common so this extra instruction effects my over all
code size.

In this same system we do a tremendous about of indirect function
calling and most of those functions return no values.  In many cases
the performance tuning bottoms out in places where we scan a data
structure calling a series of functions indirectly and many of those
functions do a very tiny bit of work.  The cost of a small function
call becomes critical at that point.

I like multiple return values.  I find them elegant and pleasant to
use.  In systems I've built we have used them with great satisfaction.
It would be very sad to see them removed from Dylan, but I would be
more likely to adopt Dylan if it didn't have multiple return values.

  - Ben Hyde



From owner-info-dylan Mon Jan  4 12:02:42 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18102; Mon, 4 Jan 93 12:02:43 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18098; Mon, 4 Jan 93 12:02:42 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06878; Mon, 4 Jan 93 12:10:24 -0500
	for info-dylan@cambridge.apple.com
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA10360; Mon, 4 Jan 93 11:09:18 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA06687; Mon, 4 Jan 1993 11:02:22 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA02304; Mon, 4 Jan 93 11:02:38 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA00262; Mon, 4 Jan 93 11:02:39 CST
Date: Mon, 4 Jan 93 11:02:39 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9301041702.AA00262@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: multiple-values alternative with better destructuring


For me multiple values is nice to have when you have auxilliary
information being returned from a function.  I've used this alot in
Common Lisp.  The best example is a predicate which can optionally
give more than just true or false.

The only reason for not returning a list is ease of use/readability.
It is a nuisance to have to return a list and then destructure the
list every time, even though often all you want is the predicate
result.  Even just wrapping FIRST around every call to the function
gets to be error prone and costly.  

One major problem with multiple values, besides funky syntax of the
binding forms, is the inconsistency of handling.  It appears that
DYLAN, correct me if I'm wrong, does not return multiple values from
all the primitive forms (Common Lisp makes this mistake too).  This
can make binding multiple-values a pain, because I now need to be
aware which forms will and won't return multiple-values.

Before I propose a change, I want to discuss destructure bindings. One
of the nice things in the latest Common Lisp standard is
DESTRUCTURING-BIND.  This allows the use of the robust MACRO
lambda-list format to bind values in a nested list.  To me,
destructuring is the key to simplify multiple-values.

Simply allow BIND in DYLAN to do things similar to DESTRUCTURING-BIND
in Common Lisp.  Then change the multiple-values specification to
return only two types of results: one or all.  Normally every function
returns only a single value.  The ALL wrapper would return a list
(always) which contained a complete return value specification,
including any auxilliary values which were specified.

FOR EXAMPLE:

	(bind (((foo &optional bar) (all (zed ..)))
  	       (foo (zed ..)) )
	   (print foo) (print bar))



I think this ALL or ONE approach would simplify the use and
implementation of multiple-values.  Special binders for
multiple-values won't be necessary.  Also, every primitive could
handle multiple-values since they never actually have to be concerned
whether they are or not.  This approach also relates to my experience
that when you are going to use more than one return value, you usually
need all of them.

As a final note I would like to go even further with destructuring to
propose that BIND and SET! use the same format for destructuring.
Bind would not need to include some special magic destructuring format
as in the example above.

Simply allow the same kind of binding formats in BIND that are already
in SETF (and I assume will be in SET!).  Such as:

	(setf (list a b) (list 1 2))
	(bind (((list a b) (list 1 2)) )
	    (print a) (print b))

In order to include the lambda-list syntax, define a new destructure
format called LAMBDA-LIST:

	(bind (((lambda-list foo &optional bar) (all (zed ..)) ))
	    (print foo) (print bar))

SET! could use the same destructuring formats!

	(set! (lambda-list foo &optional bar) (list 1 2))

And of course, it would be nice to be able to define new destructure
formats.  But the LAMBDA-LIST and LIST formats would be standard.

-- Rob.



From gsb Mon Jan  4 13:36:07 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19061; Mon, 4 Jan 93 13:36:09 -0500
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19057; Mon, 4 Jan 93 13:36:07 -0500
Date: Mon, 4 Jan 93 13:36:07 -0500
From: Glenn S. Burke <gsb>
Message-Id: <9301041836.AA19057@cambridge.apple.com>
To: bhyde@gensym.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Ben A. Hyde's message of Mon, 4 Jan 93 10:47:38 EST <9301041547.AA01968@gensym.com>
Subject: define and set! with multiple-values
  I think I've changed my mind.

   Date: Mon, 4 Jan 93 10:47:38 EST
   From: bhyde@gensym.com (Ben A. Hyde)

     As far as I know it is not possible to implement safe
   multiple values with out requiring many functions also set a value
   count.  Thus:
     (defun foo (x)
       (+ x x))
   must set the value count to as well as do the tiny bit of work
   required to do the addition.  Meanwhile
     (defun bar (x)
       (gum x))
   doesn't have to set it.

Wrong.  It can be implemented without penalizing the simple cases.
Only the case where other than one value needs to be recognized costs
more.

   Notice this is the worse kind of purity v.s. efficiency trade off.
   We are taxing most functions for a cost that benefits only a
   very few functions.  Second, this cost can not be eliminated by a
   compiler switch that proclaims that we want to run unsafe.

---------------------------------------------------------------------------
Glenn S. Burke                | gsb@cambridge.apple.com
Phone: 617/374-5313           | Applelink: GSB

From owner-info-dylan Mon Jan  4 13:37:24 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19077; Mon, 4 Jan 93 13:37:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19073; Mon, 4 Jan 93 13:37:24 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07144; Mon, 4 Jan 93 13:45:05 -0500
	for info-dylan@cambridge.apple.com
Return-Path: <john@linus.mitre.org>
Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S)
	id AA28443; Mon, 4 Jan 93 13:37:32 -0500
Posted-Date: Mon, 04 Jan 93 13:37:29 EST
Received: by thelonius.mitre.org (5.61/RCF-4C)
	id AA16809; Mon, 4 Jan 93 13:37:30 -0500
Message-Id: <9301041837.AA16809@thelonius.mitre.org>
To: info-dylan@cambridge.apple.com
Subject: Re: multiple-values alternative with better destructuring
Date: Mon, 04 Jan 93 13:37:29 EST
From: john@linus.mitre.org

Rob Farrow (farrow@stephanie.hc.ti.com) writes:

  It appears that DYLAN, correct me if I'm wrong, does not return
  multiple values from all the primitive forms (Common Lisp makes this
  mistake too).

I'm having trouble figuring out what this means.  I presume you don't
mean that you want +, for instance, to return more than one value.

  This can make binding multiple-values a pain, because I now need to
  be aware which forms will and won't return multiple-values.

They all do.  All CommonLisp forms, and all Dylan forms, return
multiple values.  For most of them, N=1, for some N=0 or N>1.

John Burger
john@mitre.org

From owner-info-dylan Mon Jan  4 13:58:41 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19358; Mon, 4 Jan 93 13:58:42 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19354; Mon, 4 Jan 93 13:58:41 -0500
Received: from cayuga.cs.rochester.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07272; Mon, 4 Jan 93 14:06:22 -0500
	for info-dylan@cambridge.apple.com
Received: from larynx.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/x) id AA29546; Mon, 4 Jan 93 13:58:40 -0500
Received: by larynx.cs.rochester.edu (5.61/x) id AA07541; Mon, 4 Jan 93 13:58:35 -0500
Date: Mon, 4 Jan 93 13:58:35 -0500
From: miller@cs.rochester.edu
Message-Id: <9301041858.AA07541@larynx.cs.rochester.edu>
To: john@linus.mitre.org, info-dylan@cambridge.apple.com
In-Reply-To: john@linus.mitre.org's message of Mon, 04 Jan 93 13:37:29 EST <9301041837.AA16809@thelonius.mitre.org>
Subject: multiple-values alternative with better destructuring

> Date: Mon, 04 Jan 93 13:37:29 EST
> From: john@linus.mitre.org

> They all do.  All CommonLisp forms, and all Dylan forms, return
> multiple values.  For most of them, N=1, for some N=0 or N>1.

> John Burger
> john@mitre.org

Unless dpans changed it...

All commonlisp forms do not; prog1 returns 1 value, you have to use
multiple-value-prog1 to get >1 value; prog2 does not, setq,etc. See page
184-187 in cltl/2 - there are several other special cases where multiple
values are NOT preserved.

If dpans did change any of this, I'd be grateful for a reply. All I
found on cursory examination is the prog1/multiple-value-prog1
distinction does still exist, so "all commonlisp forms" clearly do NOT
return multiple values.




From owner-info-dylan Mon Jan  4 14:20:01 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19690; Mon, 4 Jan 93 14:20:02 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19679; Mon, 4 Jan 93 14:20:01 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07354; Mon, 4 Jan 93 14:27:41 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA04961; Mon, 4 Jan 93 14:19:59 EST
Received: from thailand.gensym by gensym.com (4.1/SMI-4.1)
	id AA02206; Mon, 4 Jan 93 14:02:16 EST
Date: Mon, 4 Jan 93 14:02:16 EST
From: bhyde@gensym.com (Ben A. Hyde)
Message-Id: <9301041902.AA02206@gensym.com>
Received: by thailand.gensym (4.1/SMI-4.1)
	id AA27610; Mon, 4 Jan 93 14:10:13 EST
To: info-dylan@cambridge.apple.com
Cc: @harvard.harvard.edu:gsb@cambridge.apple.com
In-Reply-To: Glenn S. Burke's message of Mon, 4 Jan 93 13:36:07 -0500 <9301041836.AA19057@cambridge.apple.com>
Subject: define and set! with multiple-values
       As far as I know it is not possible to implement safe
     multiple values with out requiring many functions also set a value
     count.  Thus:
  Wrong.  It can be implemented without penalizing the simple cases.
  Only the case where other than one value needs to be recognized costs
  more.

Ouch.  That makes me happy. 

Care to give me a hint as to how this cleverness is managed?  

 - ben hyde



From owner-info-dylan Mon Jan  4 14:20:18 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19706; Mon, 4 Jan 93 14:20:19 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19698; Mon, 4 Jan 93 14:20:18 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07360; Mon, 4 Jan 93 14:27:59 -0500
	for info-dylan@cambridge.apple.com
Received: from tilde.csc.ti.com ([128.247.160.56]) by ti.com with SMTP 
	(5.59/LAI-3.2) id AA15299; Mon, 4 Jan 93 13:26:48 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA12487; Mon, 4 Jan 1993 13:19:53 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA02886; Mon, 4 Jan 93 13:20:14 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA00382; Mon, 4 Jan 93 13:20:14 CST
Date: Mon, 4 Jan 93 13:20:14 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9301041920.AA00382@stephanie.hc.ti.com>
To: john@linus.mitre.org
Cc: info-dylan@cambridge.apple.com
In-Reply-To: john@linus.mitre.org's message of Mon, 04 Jan 93 13:37:29 EST <9301041837.AA16809@thelonius.mitre.org>
Subject: multiple-values alternative with better destructuring


John Burger writes:

>They all do.  All CommonLisp forms, and all Dylan forms, return
>multiple values.  For most of them, N=1, for some N=0 or N>1.


A couple of Common Lisp primitives which don't handle multiple-values
are OR and SOME, there may be others.

Examples:
	(or (values 1 2) nil) ;=> 1
	(or nil (values 1 2)) ;=> (values 1 2)

I have used versions of COND which also didn't handle multiple-values
correctly.  This may be a bug or an implementation dependent behavior.
The major Lisp vendors are pretty good about doing what seems right in
multiple-values cases.  But it would be nicer to simplify what SHOULD
happen.


-- Rob.

From alms Mon Jan  4 14:31:43 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19919; Mon, 4 Jan 93 14:31:46 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19915; Mon, 4 Jan 93 14:31:43 -0500
Message-Id: <9301041931.AA19915@cambridge.apple.com>
Date: Mon, 4 Jan 1993 14:42:22 -0500
To: info-dylan@cambridge.apple.com, jra@gensym.com (Jim Allard)
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: IEEE NaN and Trichotomy

At  3:58 PM 12/28/92 -0500, Jim Allard wrote:
> Robert Cassels writes:
> 
> >Of course the compiler would turn (not (binary< ...)) into the most
> >efficient machine instruction(s), which might be a branch-less-or-equal and
> >wouldn't necessarily need an explicit "not" instruction.  The issue here
> >isn't what machine instructions get generated (I assume we can write
> >sufficiently clever compilers), but what the programmer writes to get what
> >effect.
> 
> Actually, I believe the compiler would not be allowed to perform this
> transformation, since it would change the IEEE result for NaN arguments.  Weird
> stuff, isn't it?
> 
> Andrew LM Shalit writes:
> 
> >If my memory serves me correctly, signalling an exception on NaN comparisons
> >wouldn't bee IEEE compatible.  You have to return #f.
> 
> I must admit, I have only read things written by others who I must assume read
> the standard.  In those documents there appeared to be two valid choices,
> signalling or returning NaNs.

Yes, but in this context 'signalling' means setting a bit which the program
can check at its discretion.  This 'signalling' does not involve (cannot
involve) interrupting the flow of the program, they way 'signalling' in the
Dylan exception system does.

This interpretation is based on e-mail discussions with Jerome Coonen (IEEE
math guru) a couple of years ago.

  -Andrew


From owner-info-dylan Mon Jan  4 14:53:19 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20268; Mon, 4 Jan 93 14:53:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20259; Mon, 4 Jan 93 14:53:19 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07656; Mon, 4 Jan 93 15:00:50 -0500
	for info-dylan@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA29872; Mon, 4 Jan 93 14:53:19 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 145251.9757; Mon, 4 Jan 1993 14:52:51 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA09989; Mon, 4 Jan 93 10:17:36 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA29071; Mon, 4 Jan 93 10:17:34 PST
Date: Mon, 4 Jan 93 10:17:34 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9301041817.AA29071@eagle.sharebase.com>
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, rwk@WORLD.STD.COM
Subject: Re: define and set! with multiple-values
Cc: info-dylan@CAMBRIDGE.APPLE.COM

From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
///     In my experience, they're not that much work for implementors.
/// 
/// I guess it depends on how hard you want to try to squeeze out that last
/// cycle or two of per-call overhead.  Implementing CL-style
/// multiple-value returns with *no* added cost to calls/returns that
/// expect/return a single value is difficult.

This is true when it is not apparent from the CALL that the function will
return multiple values.  A special form (like BIND) can solve this problem.

///     If the majority of CL programmers you talk do don't like
///     multiple-values, I have to suspect that they're mostly your
///     students, and you're getting a biased sample.  Because that doesn't
///     square with my experience at all.
/// 
/// Well, most are implementors who are influenced by their awareness of
/// what's going on inside.  And some are long-time Lispers who liked the
/// conceptual simplicity of pre-Common Lisps in which functions always
/// return one value.
///
/// [...stuff deleted...]
///
/// There is another problem, however.  Maybe 10% of the functions *could*
/// return additional values that might be of interest to some of their
/// callers.  (I'm thinking of something like FLOOR in Common Lisp.)  It's
/// wasteful to discard these values, because the callers who do want them
/// would then have to make a second call to get the extra values.  It's
/// wasteful to return all the values in a sequence, because this makes
/// extra work for the majority of callers who want just the first value.
/// And it's wasteful of space to have two versions of the function around,
/// one returning single values and one multiple.

Conceivably, the fabled "sufficiently smart compiler" should be able to
tell from the call how many of the values will be used, and not compute
the others in most cases where the (values...) form is actually part of
the function definition, yes?

Maybe we need to look at this sideways -- what if a function called in
the usual way returned only the one value, but a function in some
special form -- call it 'squeeze'* -- can arrange to bind extra
values...  Actually, this is just some alternate calling convention to
say that multiple values are requested.  I suppose the current Dylan
BIND form is sufficient for this, but personally, I'd like these extra
values to be named rather than numbered.  I think this is reasonable,
as is Scott's request for a special bind form.  Imagine sqeezing 'floor' for
'fractional-part:'...

Also, there's an issue of code maintainability -- what if a new implementation
for some function F allows me to return more information?  Do I _dare_ add this
information, possibly flubbing up callers?  Do I simply _append_ this as one
additional (un-named) item to be returned?  (Everyone's seen at least one
function whose readability has permentantly been lost to MV -- usually when
playing with it themselves for the first time...)

I don't want to spell out an actual syntax for this proposal, since I
don't want to narrow it unnecissarily, and it's too early for me to
think [on a monday].

+------------------------+-----------------------------------------------+
|Scot Dyer_Rivenburgh    | "Land of song," said the warrior bard,	 |
|dyer@eagle.sharebase.com| "Though all the world betrays thee,		 |
+------------------------+  One sword, at least, thy rights shall guard, |
|(He's right, you know.) |  One faithful harp shall praise thee."	 |
+------------------------+-----------------------------------------------+

* or EXTENDED-CALL, or what have you.  It should have an APPLY equiv., too.
  Damage = 2 new identifiers... Ouch!

From owner-info-dylan Mon Jan  4 15:47:50 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21118; Mon, 4 Jan 93 15:47:51 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21114; Mon, 4 Jan 93 15:47:50 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07829; Mon, 4 Jan 93 15:55:32 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by world.std.com (5.65c/Spike-2.0)
	id AA29511; Mon, 4 Jan 1993 15:47:54 -0500
Message-Id: <199301042047.AA29511@world.std.com>
To: bhyde@gensym.com (Ben A. Hyde)
Cc: info-dylan@cambridge.apple.com
Subject: Re: define and set! with multiple-values I think I've changed my mind. 
In-Reply-To: Your message of "Mon, 04 Jan 93 10:47:38 EST."
             <9301041547.AA01968@gensym.com> 
Date: Mon, 04 Jan 93 15:47:53 -0500
From: Bob Kerns <rwk@world.std.com>

    Date: Mon, 4 Jan 93 10:47:38 EST
    From: bhyde@gensym.com (Ben A. Hyde)
    
      As far as I know it is not possible to implement safe
    multiple values with out requiring many functions also set a value
    count.  Thus:
      (defun foo (x)
        (+ x x))
    must set the value count to as well as do the tiny bit of work
    required to do the addition.  Meanwhile
      (defun bar (x)
        (gum x))
    doesn't have to set it.
    
There are several techniques.  One is to tag the return value
count with the stack-frame that it's targeted for.  Functions
which pass through multiple values simply re-tag.  Calling
for multiple value clears the tag before call, in case some
earlier call left an identical tag.  If the caller doesn't
see its own stack level, it ignores the indicated count,
and knows that the called function returned exactly one value.

    
    I like multiple return values.  I find them elegant and pleasant to
    use.  In systems I've built we have used them with great satisfaction.
    It would be very sad to see them removed from Dylan, but I would be
    more likely to adopt Dylan if it didn't have multiple return values.
    
It would be sad if you didn't adopt Dylan because of an
erroneous assumption about the cost of a feature you
even like!



From owner-info-dylan Mon Jan  4 16:04:52 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21361; Mon, 4 Jan 93 16:04:53 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21357; Mon, 4 Jan 93 16:04:52 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07945; Mon, 4 Jan 93 16:12:35 -0500
	for info-dylan@cambridge.apple.com
Return-Path: <john@linus.mitre.org>
Received: from thelonius.mitre.org by linus.mitre.org (5.61/RCF-4S)
	id AA04701; Mon, 4 Jan 93 16:05:01 -0500
Posted-Date: Mon, 04 Jan 93 16:04:58 EST
Received: by thelonius.mitre.org (5.61/RCF-4C)
	id AA16909; Mon, 4 Jan 93 16:04:59 -0500
Message-Id: <9301042104.AA16909@thelonius.mitre.org>
To: info-dylan@cambridge.apple.com
Subject: Re: multiple values
Date: Mon, 04 Jan 93 16:04:58 EST
From: john@linus.mitre.org

Rob Farrow (farrow@stephanie.hc.ti.com) writes:

  It appears that DYLAN, correct me if I'm wrong, does not return
  multiple values from all the primitive forms (Common Lisp makes this
  mistake too).

I said:

  I'm having trouble figuring out what this means.  ... All CommonLisp
  forms, and all Dylan forms, return multiple values.  For most of
  them, N=1, for some N=0 or N>1.

miller@cs.rochester.edu (among others) replies:

  Unless dpans changed it... All commonlisp forms do not;
  prog1 returns 1 value.

Oh, that's what he meant.  I guess everyone else figured that out.  By
"return" I thought he meant return, and by "form" I though he meant
form.  :-) Yes, PROG1 is a CL operator for which N is always 1.

The dpANS did not change this.

John Burger
john@mitre.org

From owner-info-dylan Wed Jan  6 10:24:24 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23776; Wed, 6 Jan 93 10:24:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23772; Wed, 6 Jan 93 10:24:24 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11716; Wed, 6 Jan 93 10:32:19 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA12276; Wed, 6 Jan 93 10:24:38 EST
Received: from thailand.gensym by gensym.com (4.1/SMI-4.1)
	id AA04635; Wed, 6 Jan 93 10:04:41 EST
Date: Wed, 6 Jan 93 10:04:41 EST
From: bhyde@gensym.com (Ben A. Hyde)
Message-Id: <9301061504.AA04635@gensym.com>
Received: by thailand.gensym (4.1/SMI-4.1)
	id AA14768; Wed, 6 Jan 93 10:12:50 EST
To: info-dylan@cambridge.apple.com
Cc: @harvard.harvard.edu:rwk@world.std.com
Subject: re: define and set! with multiple-values

I want to thank the many people for improving my knowledge of how to
implement multiple values.

I think I'm now completely convinced that multiple values tax only
those forms that do catch, unwind-protect, specbinding, return
multiple values, bind multiple values, prog1, and unoptimized tail
recursive calls.

Unoptimized tail recursive calls are, of course, useful for debugging, but
I believe that the FAQ for Dylan says that optimization of tail recursive
calls is "required."

While I'm convinced that the tax is only a very few instructions on
those forms I notice that in CMU Lisp on my sparc:
 (defun f (x) (g x))                           ->  80 bytes
 (defun f (x) (declare (special x)) (g x))     -> 312 bytes
 (defun f (x) (declare (special x)
                       (values fixnum)) (g x)) -> 173 bytes

  - ben hyde



From owner-info-dylan Wed Jan  6 13:20:28 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26340; Wed, 6 Jan 93 13:20:30 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26336; Wed, 6 Jan 93 13:20:28 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12164; Wed, 6 Jan 93 13:28:27 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by world.std.com (5.65c/Spike-2.0)
	id AA18496; Wed, 6 Jan 1993 13:20:35 -0500
Message-Id: <199301061820.AA18496@world.std.com>
To: gensym!bhyde@harvard.harvard.edu (Ben A. Hyde)
Cc: info-dylan@cambridge.apple.com
Subject: Re: define and set! with multiple-values 
In-Reply-To: Your message of "Wed, 06 Jan 93 10:04:41 EST."
             <9301061504.AA04635@gensym.com> 
Date: Wed, 06 Jan 93 13:20:34 -0500
From: Bob Kerns <rwk@world.std.com>

    While I'm convinced that the tax is only a very few instructions on
    those forms I notice that in CMU Lisp on my sparc:
     (defun f (x) (g x))                           ->  80 bytes
     (defun f (x) (declare (special x)) (g x))     -> 312 bytes
     (defun f (x) (declare (special x)
                           (values fixnum)) (g x)) -> 173 bytes


Special variables are much more expensive than multiple values.


From owner-info-dylan Wed Jan  6 16:24:13 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28714; Wed, 6 Jan 93 16:24:14 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28710; Wed, 6 Jan 93 16:24:13 -0500
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12635; Wed, 6 Jan 93 16:32:10 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9301062132.AA12635@brazil.cambridge.apple.com>
Received: from lisp-pmax1.slisp.cs.cmu.edu by LISP-PMAX1.SLISP.CS.CMU.EDU
          id aa20271; 6 Jan 93 16:23:53 EST
To: Bob Kerns <rwk@WORLD.STD.COM>
Cc: "Ben A. Hyde" <gensym!bhyde@HARVARD.HARVARD.EDU>,
        info-dylan@CAMBRIDGE.APPLE.COM
Subject: cost of multiple-values, ML, destructuring
In-Reply-To: Your message of Wed, 06 Jan 93 13:20:34 -0500.
             <199301061820.AA18496@world.std.com> 
Date: Wed, 06 Jan 93 16:23:40 EST
From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU

    To: "Ben A. Hyde" <gensym!bhyde@harvard.harvard.edu>
    Subject: Re: define and set! with multiple-values 
    Date: Wed, 06 Jan 93 13:20:34 -0500
    From: Bob Kerns <rwk@world.std.com>

    [...]    
    >   While I'm convinced that the tax is only a very few instructions on
    >   those forms I notice that in CMU Lisp on my sparc:
    >   (defun f (x) (g x))                           ->  80 bytes
    >   (defun f (x) (declare (special x)) (g x))     -> 312 bytes
    >   (defun f (x) (declare (special x)
                               (values fixnum)) (g x)) -> 173 bytes
    
    
    Special variables are much more expensive than multiple values.
    
I think that what Ben was pointing out here is that in CMU CL, the cost of
doing a special binding around an unknown-values TR call is 50%> than the
cost of doing the binding around a single-value call.  Which is another way
of saying that the cost of a MV-PROG1 can be as great as 20 instructions.
[There is an implicit MV-PROG1, since the special binding must be undone
after the call returns.]

With the current CMU CL default calling convention, a 
call-for-1-value...return-1-value doesn't have any cycles clearly
attributable to supporting multiple values.  A single-value return does in
effect always indicate the return value count, but does so by incrementing
the return PC, and the return PC always has to be incremented in any case
(to strip off the tag.)

There is considerable complexity in the Python compiler related to multiple
values, but much of this is related to optimizing the /=1 case.  Use is
made of the symmetry between call arguments and return values.  The first
few values are passed in registers at negligible extra cost.  (APPLY f l)
is compiled as (MULTIPLE-VALUE-CALL f (VALUES-LIST l)), which results in
some strange optimization opportunities.  It is an open question whether
this effort would have been better spent on more efficient support for
stack or heap allocated return-value tuples (which might be more widely
useful.)

I believe that ML maintains the symmetry between call & return by saying
that all functions take one *argument* which is "conceptually" a vector
that is normally destructured into separate values.  In SML/NJ there are
optimizations that avoid actually doing the allocation both for call and
return, but I believe that return value vectors (or records) are always
allocated for calls to separately compiled functions.  This is relatively
unnoticeable, since all stack frames are also heap allocated.

The ML approach seems more elegant than Common Lisp multiple values, but I
really can't comment on the attainable efficiency or ease of use.  ML has
convenient & comprehensive object-destructuring facilities integrated into
its declaration mechanisms.  Dylan fixes CL's rather hideous syntax for
receiving multiple values by moving values destructuring into BIND.
Note that SYNTAX-CASE in the pending macro proposal provides for
destructuring of DYLAN code, which is the primary use of DESTRUCTURING-BIND
in CL.

  Rob

From owner-info-dylan Mon Jan 11 14:49:14 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22644; Mon, 11 Jan 93 14:49:15 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22639; Mon, 11 Jan 93 14:49:14 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21218; Mon, 11 Jan 93 14:57:46 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA17936; Mon, 11 Jan 93 14:49:50 EST
Received: from thailand.gensym by gensym.com (4.1/SMI-4.1)
	id AA09820; Mon, 11 Jan 93 14:15:59 EST
Date: Mon, 11 Jan 93 14:15:59 EST
From: bhyde@gensym.com (Ben A. Hyde)
Message-Id: <9301111915.AA09820@gensym.com>
Received: by thailand.gensym (4.1/SMI-4.1)
	id AA02952; Mon, 11 Jan 93 14:24:44 EST
To: info-dylan@cambridge.apple.com
Subject: Re2: MCL support for MOP

> Brent Benson   writes...
> I'm not convinced that it is hard to tree shake code that does not
> contain calls to eval.  I would appreciate it if someone could tell me

Any quoted symbol in the source may have symbol-function applied
sooner or latter.  One simple solution to this is to consider all
quoted symbols as tree roots.  While simple it can be surprising how
many things get quoted to make development more pleasant:
  (defmacro def... (name ...)
    `( ...
       ',name))

More generally any interning can create symbols that can then have
symbol-function applied to them.  I.e. parsing user input can lead to
difficulties knowning what the domain over which intern can operate.
This is can be handled by disallowing intern, and find-symbol.  The
application writer must then implement his own find-symbol/intern if
he desires this functionality.

 - ben 

From owner-info-dylan Mon Jan 11 15:30:14 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23249; Mon, 11 Jan 93 15:30:15 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23244; Mon, 11 Jan 93 15:30:14 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21403; Mon, 11 Jan 93 15:38:47 -0500
	for info-dylan@cambridge.apple.com
Received: by world.std.com (5.65c/Spike-2.0)
	id AA16253; Mon, 11 Jan 1993 15:30:50 -0500
Message-Id: <199301112030.AA16253@world.std.com>
To: bhyde@gensym.com (Ben A. Hyde)
Cc: info-dylan@cambridge.apple.com
Subject: Re: Re2: MCL support for MOP 
In-Reply-To: Your message of "Mon, 11 Jan 1993 14:15:59 EST."
             <9301111915.AA09820@gensym.com> 
Date: Mon, 11 Jan 1993 15:30:49 -0500
From: Bob Kerns <rwk@world.std.com>

    Date: Mon, 11 Jan 93 14:15:59 EST
    From: bhyde@gensym.com (Ben A. Hyde)
    Any quoted symbol in the source may have symbol-function applied
    sooner or latter.

I think the right way to look at this that eval is not the problem,
symbol-function is.  Eval is only problematic in that it is itself a
caller of symbol-function.  (For tree-shaking, that is; eval has
other problems).

In fact, in my coding style, I avoid symbol-function.  I tend
to write macros that define functions, and then store the function
itself in a data-structure, or write #'foo instead of 'foo.

If you use symbol-function, who knows what you might end up
running?  ;=)

Using the symbol-function style also imoses a paging working-set
cost.

From owner-info-dylan Mon Jan 11 15:56:40 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23519; Mon, 11 Jan 93 15:56:42 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23515; Mon, 11 Jan 93 15:56:40 -0500
Received: from cayuga.cs.rochester.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21526; Mon, 11 Jan 93 16:05:14 -0500
	for info-dylan@cambridge.apple.com
Received: from larynx.cs.rochester.edu by cayuga.cs.rochester.edu (5.61/x) id AA29113; Mon, 11 Jan 93 15:57:11 -0500
Received: by larynx.cs.rochester.edu (5.61/x) id AA08801; Mon, 11 Jan 93 15:57:09 -0500
Date: Mon, 11 Jan 93 15:57:09 -0500
From: miller@cs.rochester.edu
Message-Id: <9301112057.AA08801@larynx.cs.rochester.edu>
To: rwk@world.std.com
Cc: bhyde@gensym.com, info-dylan@cambridge.apple.com
In-Reply-To: Bob Kerns's message of Mon, 11 Jan 1993 15:30:49 -0500 <199301112030.AA16253@world.std.com>
Subject: Re2: MCL support for MOP 

> Date: Mon, 11 Jan 1993 15:30:49 -0500
> From: Bob Kerns <rwk@world.std.com>

> In fact, in my coding style, I avoid symbol-function.  I tend
> to write macros that define functions, and then store the function
> itself in a data-structure, or write #'foo instead of 'foo.

> If you use symbol-function, who knows what you might end up
> running?  ;=)

On the flip side, I couldn't live without symbol-function. When I
incrementally redefine a function symbol in a file (e.g. defun of foo),
I don't want to go have to recompile every #' mention of the function, I
want the newest version always. Sure, it loses in the face of a macro,
but that's just another reason to try to avoid macros (or at least get
them right the first time :-).


From owner-info-dylan Mon Jan 11 16:48:16 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24139; Mon, 11 Jan 93 16:48:17 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24135; Mon, 11 Jan 93 16:48:16 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21695; Mon, 11 Jan 93 16:56:51 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA20491; Mon, 11 Jan 93 16:48:56 EST
Received: from thailand.gensym by gensym.com (4.1/SMI-4.1)
	id AA10059; Mon, 11 Jan 93 16:36:42 EST
Date: Mon, 11 Jan 93 16:36:42 EST
From: bhyde@gensym.com (Ben A. Hyde)
Message-Id: <9301112136.AA10059@gensym.com>
Received: by thailand.gensym (4.1/SMI-4.1)
	id AA03802; Mon, 11 Jan 93 16:45:28 EST
To: info-dylan@cambridge.apple.com
Subject: Re2: MCL support for MOP 

Sorry, 
  I seem to have sent mail to info-dylan that I intended to sent to info-mcl
My mail mentioned symbol-function.  Of course, there is no such a beast in 
Dylan.
   - ben


From owner-info-dylan Tue Jan 12 08:45:54 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22916; Tue, 12 Jan 93 08:45:56 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22912; Tue, 12 Jan 93 08:45:54 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23274; Tue, 12 Jan 93 08:54:35 -0500
	for info-dylan@cambridge.apple.com
Received: by world.std.com (5.65c/Spike-2.0)
	id AA27455; Tue, 12 Jan 1993 08:46:30 -0500
Message-Id: <199301121346.AA27455@world.std.com>
To: miller@cs.rochester.edu
Cc: bhyde@gensym.com, info-dylan@cambridge.apple.com
Subject: Re: Re2: MCL support for MOP 
In-Reply-To: Your message of "Mon, 11 Jan 1993 15:57:09 EST."
             <9301112057.AA08801@larynx.cs.rochester.edu> 
Date: Tue, 12 Jan 1993 08:46:29 -0500
From: Bob Kerns <rwk@world.std.com>

    Date: Mon, 11 Jan 93 15:57:09 -0500
    From: miller@cs.rochester.edu
    On the flip side, I couldn't live without symbol-function. When I
    incrementally redefine a function symbol in a file (e.g. defun of foo),
    I don't want to go have to recompile every #' mention of the function, I
    want the newest version always. 

Ah, but you don't need to do this.  #' always gets the latest version.
You only need to update datastructures that contain function pointers,
which is why it's a good idea to combine the initialization of those
data-structures with their definitions, in a macro, so that redefining
the function also updates the datastructure.

				    Sure, it loses in the face of a macro,
    but that's just another reason to try to avoid macros (or at least get
    them right the first time :-).

I don't understand just what you're refering to here.  What loses, how?

From owner-info-dylan Tue Jan 12 18:47:30 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11906; Tue, 12 Jan 93 18:47:32 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11902; Tue, 12 Jan 93 18:47:30 -0500
Received: from pnlg.pnl.gov by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24831; Tue, 12 Jan 93 18:56:13 -0500
	for info-dylan@cambridge.apple.com
Received: from ccmail.pnl.gov by pnlg.pnl.gov; Tue, 12 Jan 93 15:42 PST
Received: from ccMail-SMTP-Gateway (V0.990/PMDF V3.1) by ccmail.pnl.gov; Tue,
 12 Jan 93 15:42 PST
Date: Tue, 12 Jan 93 15:42 PST
From: Larry E Bugbee <le_bugbee@pnlg.pnl.gov>
Subject: Thomas?
To: info-dylan@cambridge.apple.com
Message-Id: <97E74DD909FF200136@pnlg.pnl.gov>
X-Ccmail-Date: 1/12/93 3:36PM
X-Envelope-To: info-dylan@cambridge.apple.com


   I understand there is an implementation of Dylan called Thomas.  Where is 
   it and how might I go about getting a copy?
   
   My thanks,
   
   Larry Bugbee

From owner-info-dylan Wed Jan 13 10:26:13 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22397; Wed, 13 Jan 93 10:26:15 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22391; Wed, 13 Jan 93 10:26:13 -0500
Received: from corton.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26025; Wed, 13 Jan 93 10:34:58 -0500
	for info-dylan@cambridge.apple.com
Received: from syseca.UUCP by corton.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA23029; Wed, 13 Jan 1993 15:35:20 +0100 (MET)
Received: from saturne (DDA_saturne) by syseca.fr (4.0/SMU-4.0 22/11/92 Syseca)
	id AA01816; Wed, 13 Jan 93 13:35:57 GMT
Received: from tobago.saturne by saturne (4.1/SMI-4.1)
	id AA15478; Wed, 13 Jan 93 14:36:37 +0100
Date: Wed, 13 Jan 93 14:36:37 +0100
From: ret@syseca.fr (Philippe RETIF )
Message-Id: <9301131336.AA15478@saturne>
To: info-dylan@cambridge.apple.com
Subject: Request for info about Dylan 
Cc: ret@syseca.fr

Hello everybody,

I am interested by the Dylan language, but I don't
have a lot of info about it right now.
Is it possible to get a summary of the main Dylan's features,
or even an implementation by ftp/email.

Thanks a lot in advance,
Philippe

From owner-info-dylan Wed Jan 13 12:53:54 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28046; Wed, 13 Jan 93 12:54:04 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28026; Wed, 13 Jan 93 12:53:54 -0500
Received: from alex.stacken.kth.se by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26522; Wed, 13 Jan 93 13:02:40 -0500
	for info-dylan@cambridge.apple.com
Received: by alex.stacken.kth.se id AA07048
  (5.65c/IDA-1.4.4 for info-dylan@cambridge.apple.com); Wed, 13 Jan 1993 18:54:25 +0100
Date: Wed, 13 Jan 1993 18:54:25 +0100
From: Bengt Baverman <bengtb@stacken.kth.se>
Message-Id: <199301131754.AA07048@alex.stacken.kth.se>
To: info-dylan@cambridge.apple.com, le_bugbee@pnlg.pnl.gov
Subject: Re: Thomas?

Please, have a look at these FTP sites:
  crl.dec.com:pub/DEC/Thomas
  gatekeeper.pa.dec.com:pub/DEC/Thomas
  altdorf.ai.mit.edu:archive/Thomas

for Thomas. 

You can read more about Dylan and Thomas in the FAQ found in comp.lang.lisp
aswell as comp.lang.scheme.

From owner-info-dylan Wed Jan 13 18:26:39 1993
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08866; Wed, 13 Jan 93 18:26:48 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08847; Wed, 13 Jan 93 18:26:39 -0500
Received: from probitas.cs.utas.edu.au by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28467; Wed, 13 Jan 93 18:35:07 -0500
	for info-dylan@cambridge.apple.com
Received: by probitas.cs.utas.edu.au (AIX 3.2/UCB 5.64/4.03)
          id AA49319; Thu, 14 Jan 1993 10:25:24 +1000
From: charles@probitas.cs.utas.edu.au (Charles Lakos)
Message-Id: <9301140025.AA49319@probitas.cs.utas.edu.au>
Subject: Unsubscribe me
To: info-dylan@cambridge.apple.com
Date: Thu, 14 Jan 93 10:25:23 EET
X-Mailer: ELM [version 2.3 PL8]

unsubscribe info-dylan
-- 
Charles Lakos.                               C.A.Lakos@cs.utas.edu.au
Computer Science Department,                 charles@probitas.cs.utas.edu.au
University of Tasmania,                      Phone:    +61 02 20 2959
Sandy Bay, TAS, Australia.                   Fax:      +61 02 20 2913

