From troot Thu Sep  3 11:06:23 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00354; Thu, 3 Sep 92 11:06:23 -0400
Date: Thu, 3 Sep 92 11:06:23 -0400
From: Prime Minister <troot>
Full-Name: Prime Minister
Message-Id: <9209031506.AA00354@cambridge.apple.com>
Apparently-To: info-dylan

hello again


From alms@cambridge.apple.com Tue Sep 15 11:44:13 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12383; Tue, 15 Sep 92 11:44:13 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9209151544.AA12383@cambridge.apple.com>
Date: Tue, 15 Sep 1992 11:54:44 -0500
To: info-dylan
From: alms@cambridge.apple.com
Subject: New Dylan mailing lists

I'm very happy to announce the formation of three new mailing lists
for discussions specific to the Dylan programming language.

Because of your interest in OODLs, we've taken the liberty of adding you
to the first of these lists (info-dylan).  If you'd like to be removed,
please send a note to info-dylan-request@cambridge.apple.com.

The three lists we've created are:

 info-dylan@cambridge.apple.com
 info-dylan-request@cambridge.apple.com (administration)

   This is a two-way mailing list for any and all discussions of Dylan,
   including language design issues, implementation issues, marketting
   issues, syntax issues, etc.

 announce-dylan@cambridge.apple.com
 announce-dylan-request@cambridge.apple.com (administration)

   This is a mailing for major announcements about Dylan, such as the
   availability of new implementations, new versions of the manual, etc.
   This mailing list should be _much_ lower volume than info-dylan.
   Everything sent to this list is also sent to info-dylan.

 dylan-builders@cambridge.apple.com
 dylan-builders-request@cambridge.apple.com (administration)

   This is a two-way mailing list for people who are working on Dylan
   implementations.  If you'd like to be added to this list, please send
   a note describing your implementation plans to dylan-builders-request.


We appreciate the support of all the OODL-SIGers for Dylan.  Members of
the Dylan team at Apple will be participating in these mailing lists.
We look forward to hearing your thoughts on Dylan, and sharing our ideas
with you.

We'll be posting an updated Dylan FAQ sheet to this list in a couple of
days.

   -Andrew Shalit


----------------------------------------
Andrew Shalit (alms@cambridge.apple.com)
Apple Computer
1 Main Street, 7th floor
Cambridge, MA 02142


From tesler@newton.apple.com Fri Sep 18 01:48:12 1992
Received: from newton.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05670; Fri, 18 Sep 92 01:48:12 -0400
Received: from  by newton.apple.com (4.1/SMI-4.1)
	id AB10272; Thu, 17 Sep 92 22:50:56 PDT
Date: Thu, 17 Sep 92 22:50:56 PDT
Message-Id: <9209180550.AB10272@newton.apple.com>
To: info-dylan@cambridge.apple.com
From: tesler@newton.apple.com
Subject: Recruiting assistance requested

Well, I don't know whether info-dylan is also for employment opportunity
announcements, but it is better to apologize than ask permission, so...

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


From bruce@waits.media.mit.edu Mon Sep 21 09:43:55 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26991; Mon, 21 Sep 92 09:43:55 -0400
Received: from dearth.media.mit.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13853; Mon, 21 Sep 92 09:49:28 -0400
	for info-dylan@cambridge.apple.com
Received: from waits by dearth.media.mit.edu (NX5.67c/NX3.0M)
	id AA02931; Mon, 21 Sep 92 09:41:57 -0400
Received: by waits.media.mit.edu (NX5.67c/NX3.0S)
	id AA00352; Mon, 21 Sep 92 09:44:15 -0400
Date: Mon, 21 Sep 92 09:44:15 -0400
From: bruce blumberg <bruce@waits.media.mit.edu>
Message-Id: <9209211344.AA00352@waits.media.mit.edu>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: info-dylan@cambridge.apple.com
Subject: please add me to the email list

Hi

Please add me to whatever email list you have for information on dylan. Thanks

bruce blumberg

bruce@media.mit.edu

p.s please use the above email address rather than the reply address.




From kevin@scic.intel.com Wed Sep 23 17:24:21 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22332; Wed, 23 Sep 92 17:24:21 -0400
Received: from t.iWarp.intel.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19468; Wed, 23 Sep 92 17:30:09 -0400
	for dylan-builders@cambridge.apple.com
Received: from sv002.scic.intel.com by t.iWarp.intel.com (4.1/iWarpT.4.61); Wed, 23 Sep 92 14:27:32 PDT
Received: from [137.102.207.12] (mc005.scic.intel.com) by sv002.scic.intel.com (4.1/SCICX.1.10); Wed, 23 Sep 92 14:27:26 PDT
Message-Id: <9209232127.AA29148@sv002.scic.intel.com>
Sender: kevin@scic.intel.com
Date: Wed, 23 Sep 1992 14:28:01 -0800
To: info-dylan@cambridge.apple.com, dylan-builders@cambridge.apple.com
From: kevin@scic.intel.com (Kevin Altis)
Subject: dylan availability

I would like to know what OS platforms and processors Dylan will be
available on. Dylan will be available for Newton, but will you also be able
to use it for developing applications for the Mac Plus, Quadra, and
PowerBooks? How about Windows, Windows NT, UNIX?

Have other companies announced plans for Dylan implementations? I know of
the DEC "Thomas" implementation written in Scheme, but haven't heard of
others.

Also, if there are any estimates on time (man months) and other costs for
implementing Dylan on a given processor or OS platform I would be
interested in hearing from you. I realize this is a bit vague, but Dylan
was designed to run on machines with limited resources, so there are a lot
of opportunities to use Dylan (instead of C or Assembler) with existing and
upcoming processors and specialized chips if the development time isn't too
long.

ka




From dane@hld9.hlds.com Thu Sep 24 11:59:47 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00312; Thu, 24 Sep 92 11:59:47 -0400
Received: from NOVA.UNIX.PORTAL.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21933; Thu, 24 Sep 92 12:05:38 -0400
	for info-dylan@cambridge.apple.com
Return-Path: <hld4!hld9.hlds.com!dane>
Received: by nova.unix.portal.com (5.65b/4.1 1.150) 
	id AA08664; Thu, 24 Sep 92 09:02:52 -0700
Received: by portal.unix.portal.com (1.334) 
	id AA04342; Thu, 24 Sep 92 09:02:47 -0700
Received: from hld9.hlds.com by hlds.com (4.1/SMI-4.1)
	id AA26091; Thu, 24 Sep 92 09:04:28 PDT
Received: by hld9.hlds.com (4.1/SMI-4.1)
	id AA06099; Thu, 24 Sep 92 09:01:36 PDT
Date: Thu, 24 Sep 92 09:01:36 PDT
From: dane@hld9.hlds.com (Dane Collins)
Message-Id: <9209241601.AA06099@hld9.hlds.com>
To: info-dylan@cambridge.apple.com
Subject: mailing list

Please add me to the mailing list.
Thanks.

Dane Marc Collins
High Level Design Systems, 5201 Great America Parkway, Santa Clara, CA 95054
(408) 982-2550

From riesbeck@lyonesse.ils.nwu.edu Thu Sep 24 14:20:04 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01813; Thu, 24 Sep 92 14:20:04 -0400
Received: from casbah.acns.nwu.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22454; Thu, 24 Sep 92 14:26:01 -0400
	for info-dylan@cambridge.apple.com
Received: from lyonesse.ils.nwu.edu by casbah.acns.nwu.edu (4.1/SMI-ACNS-1.03)
	id AA07204; Thu, 24 Sep 92 13:23:23 CDT
Return-Path: <riesbeck@lyonesse.ils.nwu.edu>
Received: by lyonesse.ils.nwu.edu (4.0/SMI-4.0)
	id AA12941; Thu, 24 Sep 92 13:32:53 CDT
Date: Thu, 24 Sep 92 13:32:53 CDT
From: riesbeck@lyonesse.ils.nwu.edu (Chris Riesbeck)
Message-Id: <9209241832.AA12941@lyonesse.ils.nwu.edu>
To: info-dylan@cambridge.apple.com
Subject: subscribe


Please subscribe me to the info-dylan mailing list.

Thanks
Chris
-----


From piaw@pure.com Thu Sep 24 15:53:35 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02699; Thu, 24 Sep 92 15:53:35 -0400
Received: from uu4.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22731; Thu, 24 Sep 92 15:59:28 -0400
	for info-dylan@cambridge.apple.com
Received: from pure.com by uu4.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA22732; Thu, 24 Sep 92 15:48:10 -0400
Received: from fuji ([192.9.200.9]) by pure.pure.com (5.65c/PURE-SERVER-1.0)
	id AA28473; Thu, 24 Sep 1992 12:36:28 -0700
Date: Thu, 24 Sep 1992 12:36:28 -0700
From: piaw@pure.com  (Na Choon Piaw)
Message-Id: <199209241936.AA28473@pure.pure.com>
Received: by fuji (4.1/CLIENT-1.0)
	id AA14160; Thu, 24 Sep 92 12:35:27 PDT 
To: info-dylan@cambridge.apple.com
Subject: please add me to your list.
Reply-To: piaw@pure.com


Piaw
A Puritan is someone who is deathly afraid that someone somewhere is having fun.

From @opus.iarc.mco.edu:habboub@soleil.iarc.mco.edu Sun Sep 27 15:35:08 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05061; Sun, 27 Sep 92 15:35:08 -0400
Received: from opus.iarc.mco.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27534; Sun, 27 Sep 92 15:41:28 -0400
	for info-dylan@cambridge.apple.com
Received: from soleil.iarc.mco.edu. by opus.iarc.mco.edu with SMTP ; 
          Sun, 27 Sep 92 15:23:24 EST
Received: by soleil.iarc.mco.edu. (4.0/SMI-4.0)
	id AA18886; Sun, 27 Sep 92 15:32:10 EDT
Date: Sun, 27 Sep 92 15:32:10 EDT
From: habboub@soleil.iarc.mco.edu (Mahmoud Habboub)
Message-Id: <9209271932.AA18886@soleil.iarc.mco.edu.>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]


I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From news@informatik.uni-kiel.dbp.de Sun Sep 27 15:54:33 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05164; Sun, 27 Sep 92 15:54:33 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27633; Sun, 27 Sep 92 16:00:54 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 20:57:34 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 20:57:07 +0100
Date: Sun, 27 Sep 1992 20:57:07 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0013964.000717623827]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: mail@informatik.uni-kiel.dbp.de
Message-Id: <11373@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]



I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.



From news@informatik.uni-kiel.dbp.de Sun Sep 27 17:59:41 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05619; Sun, 27 Sep 92 17:59:41 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27787; Sun, 27 Sep 92 18:06:01 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 23:02:28 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:01:51 +0100
Date: Sun, 27 Sep 1992 23:01:51 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0014479.000717631311]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11374@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]





I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.




From news@informatik.uni-kiel.dbp.de Sun Sep 27 18:21:43 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05725; Sun, 27 Sep 92 18:21:43 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27853; Sun, 27 Sep 92 18:28:03 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 23:24:46 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:06:46 +0100
Date: Sun, 27 Sep 1992 23:06:46 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0014517.000717631606]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11375@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]







I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.





From news@informatik.uni-kiel.dbp.de Sun Sep 27 18:26:12 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05741; Sun, 27 Sep 92 18:26:12 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27881; Sun, 27 Sep 92 18:32:32 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 23:29:08 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:28:47 +0100
Date: Sun, 27 Sep 1992 23:28:47 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0014564.000717632927]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11376@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]









I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.






From news@informatik.uni-kiel.dbp.de Sun Sep 27 18:30:58 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05775; Sun, 27 Sep 92 18:30:58 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27912; Sun, 27 Sep 92 18:37:18 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 23:33:56 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:33:27 +0100
Date: Sun, 27 Sep 1992 23:33:27 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0014607.000717633207]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11377@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]











I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.







From news@informatik.uni-kiel.dbp.de Sun Sep 27 18:40:30 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05823; Sun, 27 Sep 92 18:40:30 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27944; Sun, 27 Sep 92 18:46:51 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 23:38:17 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:37:48 +0100
Date: Sun, 27 Sep 1992 23:37:48 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0014677.000717633468]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11378@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]













I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.








From news@informatik.uni-kiel.dbp.de Sun Sep 27 18:46:27 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05858; Sun, 27 Sep 92 18:46:27 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27979; Sun, 27 Sep 92 18:52:47 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 23:49:29 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:49:04 +0100
Date: Sun, 27 Sep 1992 23:49:04 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0015106.000717634144]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11379@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]















I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.









From news@informatik.uni-kiel.dbp.de Sun Sep 27 18:51:52 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05909; Sun, 27 Sep 92 18:51:52 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28007; Sun, 27 Sep 92 18:58:12 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Sun, 27 Sep 1992 23:54:56 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:54:30 +0100
Date: Sun, 27 Sep 1992 23:54:30 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0015307.000717634470]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11380@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]

















I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.










From news@informatik.uni-kiel.dbp.de Sun Sep 27 18:57:14 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05938; Sun, 27 Sep 92 18:57:14 -0400
Received: from ixgate.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28054; Sun, 27 Sep 92 19:03:34 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by mta ixgate.gmd.de in /PRMD=GmD/ADMD=DbP/C=DE/; Relayed;
               Mon, 28 Sep 1992 00:00:11 +0100
X400-Received: by /PRMD=uni-kiel/ADMD=dbp/C=de/; Relayed;
               Sun, 27 Sep 1992 23:59:51 +0100
Date: Sun, 27 Sep 1992 23:59:51 +0100
X400-Originator: news@informatik.uni-kiel.dbp.de
X400-Recipients: info-dylan@cambridge.apple.com
X400-Mts-Identifier: [/PRMD=uni-kiel/ADMD=dbp/C=de/;majestix 0015340.000717634791]
X400-Content-Type: P2-1984 (2)
From: " (Mahmoud Habboub)" <habboub@soleil.iarc.mco.edu>
Sender: news@informatik.uni-kiel.dbp.de
Message-Id: <11381@majestix.informatik.uni-kiel.dbp.de>
To: info-dylan@cambridge.apple.com
Subject: [info-thomas@crl.dec.com: "Thomas" system now available]



















I'm forwarding this since it might be of interest to subscribers to
info-dylan and the fact that it didn't look like it was posted to any
of the Dylan lists.
-------------------------------------------------------

Date: 25 Sep 92 19:00:23 GMT
From: info-thomas@crl.dec.com
Organization: DEC Cambridge Research Lab
Subject: "Thomas" system now available
Newsgroups: comp.compilers,comp.object,comp.lang.functional,comp.lang.scheme
To: scheme@mc.lcs.mit.edu

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

In building Thomas, our goals (in order of priority) were:

(1) To learn about the Dylan(TM) language, by building an
    implementation based solely on the description in the book.

(2) To help others learn about the language by producing source code
    for an implementation that was well structured, easy to read, and
    was publically available.

(3) To build a system we could use to actually write small Dylan(TM)
    programs, to get a feel for the language through using it.

We feel we have met these three goals as well as can be expected in a four
week project with three people.  It was never our intention to produce an
implementation that performs well, and Thomas has no optimizations of any
kind.  It does not perform well.  This reflects our goals and not
necessarily the design of the language itself.

Thomas is NOT Dylan(TM).  We have not received approval for the use of the
trademark, and we have not received a copy of a test suite other than the
examples from the book itself.  We may, at some future date, pursue these
issues with Apple.  The Thomas system was built with no direct input, aid,
assistance or discussion with Apple.  All design and implementation
decisions in Thomas reflect choices by the Thomas implementors based on
reading the book published by Apple.  These decisions must not be
construed in any way as deriving from Apple Computer Corporation or its
employees.

We have made every effort to minimize the differences between Thomas and
Dylan(TM), and to remove bugs, but help from others would be greatly
appreciated.  The original development team consisted of:

          Matt Birkholz (Birkholz@crl.dec.com)
          Jim Miller (JMiller@crl.dec.com)
          Ron Weiss (RWeiss@crl.dec.com)

In addition, Joel Bartlett (Bartlett@wrl.dec.com), Marc Feeley
(Feeley@iro.umontreal.ca), Guillermo Rozas (Jinx@zurich.ai.mit.edu) and
Ralph Swick (Swick@crl.dec.com) contributed time and energy to the initial
release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.











From alms@cambridge.apple.com Tue Sep 29 14:44:53 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01951; Tue, 29 Sep 92 14:44:53 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9209291844.AA01951@cambridge.apple.com>
Date: Tue, 29 Sep 1992 14:57:29 -0500
To: kevin@scic.intel.com (Kevin Altis), info-dylan@cambridge.apple.com,
        dylan-builders@cambridge.apple.com
From: alms@cambridge.apple.com
Subject: Re: dylan availability

> I would like to know what OS platforms and processors Dylan will be
> available on. Dylan will be available for Newton, but will you also be able
> to use it for developing applications for the Mac Plus, Quadra, and
> PowerBooks? How about Windows, Windows NT, UNIX?

Hmmm... No one else bit, so I'll say the little that I can.

Although Apple hasn't announced any plans for releasing Dylan as
a product, we have said that we would like Dylan to be available
for as many computing platforms as possible.  We aren't targeting it
as a niche language, but as a general purpose language.

So, the answer to your question really depends on how successful
we are.  If we're successful, the answer will be "every platform
and every processor".

> Have other companies announced plans for Dylan implementations? I know of
> the DEC "Thomas" implementation written in Scheme, but haven't heard of
> others.

No other companies have announced plans.

> Also, if there are any estimates on time (man months) and other costs for
> implementing Dylan on a given processor or OS platform I would be
> interested in hearing from you. I realize this is a bit vague, but Dylan
> was designed to run on machines with limited resources, so there are a lot
> of opportunities to use Dylan (instead of C or Assembler) with existing and
> upcoming processors and specialized chips if the development time isn't too
> long.

This really depends on what kind of implementation you want.  The
Thomas compiler took four people four weeks, I believe (perhaps a bit
less than that).  An optimizing native-code compiler with a first-rate
development environment would take many person-years of implementation
effort.

  -Andrew


From rwk@crl.dec.com Tue Sep 29 15:00:05 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02535; Tue, 29 Sep 92 15:00:05 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03813; Tue, 29 Sep 92 15:06:40 -0400
	for alms@cambridge.apple.com
Received: by crl.dec.com; id AA27156; Tue, 29 Sep 92 15:03:37 -0400
Received: by easynet.crl.dec.com; id AA03711; Tue, 29 Sep 92 15:03:46 -0400
Message-Id: <9209291903.AA05326@taunton.crl.dec.com>
To: alms@cambridge.apple.com
Cc: kevin@scic.intel.com    (Kevin Altis), info-dylan@cambridge.apple.com,
        dylan-builders@cambridge.apple.com
Subject: Re: dylan availability 
In-Reply-To: Your message of "Tue, 29 Sep 92 14:57:29 CDT."             <9209291844.AA01951@cambridge.apple.com> 
Date: Tue, 29 Sep 92 15:03:44 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Tue, 29 Sep 1992 14:57:29 -0500
    From: alms@cambridge.apple.com
    This really depends on what kind of implementation you want.  The
    Thomas compiler took four people four weeks, I believe (perhaps a bit
    less than that).  An optimizing native-code compiler with a first-rate
    development environment would take many person-years of implementation
    effort.

... just like any other such industrial-strength compiler.  But this
old compiler writer thinks Dylan would be a bit easier to write compilers
for than a lot of them.  Still, most of the work involved in writing
a compiler is scarcely affected by the choice of language.

From twl@cs.brown.edu Tue Sep 29 15:12:12 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03035; Tue, 29 Sep 92 15:12:12 -0400
Received: from cs.brown.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03914; Tue, 29 Sep 92 15:18:48 -0400
	for alms@cambridge.apple.com
Received: from boojum.cs.brown.edu by cs.brown.edu (5.64+/Doorknob-1.5)
	id AA16997; Tue, 29 Sep 92 15:15:56 -0400
Received: by boojum.cs.brown.edu (5.64+/BrownCS-1.2)
	id AA20947; Tue, 29 Sep 92 15:15:54 -0400
Date: Tue, 29 Sep 92 15:15:54 -0400
From: twl@cs.brown.edu (Ted "Theodore" W. Leung)
Message-Id: <9209291915.AA20947@boojum.cs.brown.edu>
To: Bob Kerns <rwk@crl.dec.com>
Cc: alms@cambridge.apple.com, kevin@scic.intel.com (Kevin Altis),
        info-dylan@cambridge.apple.com, dylan-builders@cambridge.apple.com
In-Reply-To: <9209291903.AA05326@taunton.crl.dec.com>
Subject: Re: dylan availability 

Bob Kerns writes:
> But this old compiler writer thinks Dylan would be a bit easier to
> write compilers for than a lot of them.

What did you have in mind when you said this?  The only thing that I
can think of that's a little easier is that there's trivial syntax
analysis.  The runtime system need to be fairly complicated (if you're
not embedding in lisp), and all the generic function and  multiple
inheritance stuff should add complexity to a compiler.  Just look what
happened between C and C++....

Ted

From kevin@scic.intel.com Tue Sep 29 15:17:34 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03288; Tue, 29 Sep 92 15:17:34 -0400
Received: from t.iWarp.intel.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03966; Tue, 29 Sep 92 15:24:09 -0400
	for dylan-builders@cambridge.apple.com
Received: from sv002.scic.intel.com by t.iWarp.intel.com (4.1/iWarpT.4.61); Tue, 29 Sep 92 12:21:11 PDT
Received: from [137.102.207.12] (mc005.scic.intel.com) by sv002.scic.intel.com (4.1/SCICX.1.10); Tue, 29 Sep 92 12:21:05 PDT
Message-Id: <9209291921.AA27766@sv002.scic.intel.com>
Sender: kevin@scic.intel.com
Date: Tue, 29 Sep 1992 12:21:39 -0800
To: info-dylan@cambridge.apple.com, dylan-builders@cambridge.apple.com
From: kevin@scic.intel.com (Kevin Altis)
Subject: Re: dylan availability

>> Also, if there are any estimates on time (man months) and other costs for
>> implementing Dylan on a given processor or OS platform I would be
>> interested in hearing from you. I realize this is a bit vague, but Dylan
>> was designed to run on machines with limited resources, so there are a lot
>> of opportunities to use Dylan (instead of C or Assembler) with existing and
>> upcoming processors and specialized chips if the development time isn't too
>> long.
>
>This really depends on what kind of implementation you want.  The
>Thomas compiler took four people four weeks, I believe (perhaps a bit
>less than that).  An optimizing native-code compiler with a first-rate
>development environment would take many person-years of implementation
>effort.

I don't really care about recreating a development environment on a lot of
different processors, but an optimizing native-code compiler would be nice.
Compiling on one machine for different target machines is fine with me and
probably the only way when you're talking about simulations. I don't expect
to do any development on a Newton or a graphics board, etc. but I expect to
be able to write code, run simulations for a target processor or at least
do a compatibility check, then move the code to a specific target machine.

ka


From rwk@crl.dec.com Tue Sep 29 16:45:26 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06747; Tue, 29 Sep 92 16:45:26 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04187; Tue, 29 Sep 92 16:52:00 -0400
	for alms@cambridge.apple.com
Received: by crl.dec.com; id AA01771; Tue, 29 Sep 92 16:49:03 -0400
Received: by easynet.crl.dec.com; id AA05910; Tue, 29 Sep 92 16:49:02 -0400
Message-Id: <9209292049.AA12894@taunton.crl.dec.com>
To: twl@cs.brown.edu (Ted "Theodore" W. Leung)
Cc: alms@cambridge.apple.com, kevin@scic.intel.com    (Kevin Altis),
        info-dylan@cambridge.apple.com, dylan-builders@cambridge.apple.com
Subject: Re: dylan availability 
In-Reply-To: Your message of "Tue, 29 Sep 92 15:15:54 EDT."             <9209291915.AA20947@boojum.cs.brown.edu> 
Date: Tue, 29 Sep 92 16:49:00 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Tue, 29 Sep 92 15:15:54 -0400
    From: twl@cs.brown.edu (Ted "Theodore" W. Leung)
    
    Bob Kerns writes:
    > But this old compiler writer thinks Dylan would be a bit easier to
    > write compilers for than a lot of them.
    
    What did you have in mind when you said this?  The only thing that I
    can think of that's a little easier is that there's trivial syntax
    analysis.  The runtime system need to be fairly complicated (if you're
    not embedding in lisp), and all the generic function and  multiple
    inheritance stuff should add complexity to a compiler.  Just look what
    happened between C and C++....

To avoid getting into a long discussion, let me just point out that you
have to read what I said.  Languages like ADA and Common Lisp impose lots
of burdens on the compiler writer which are absent in Dylan because of
its simplicity.  The point isn't that it's a whole lot easier, but rather
that they're all hard, but Dylan isn't especially hard.

The object system isn't that hard.  (I've written object systems.  Object
systems are a friend of mine.  C++ is no object system ;=).  Compared to
the overall size of a commercial-grade compiler, it's not going to be the
determinant.

One of the best advantages is that you're going to get to write the compiler
in Dylan instead of C++.  Lisp has proven to be a very good language for
writing compilers in.

From rwk@crl.dec.com Tue Sep 29 16:56:21 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07181; Tue, 29 Sep 92 16:56:21 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04253; Tue, 29 Sep 92 17:02:57 -0400
	for alms@cambridge.apple.com
Received: by crl.dec.com; id AA02715; Tue, 29 Sep 92 17:00:02 -0400
Received: by easynet.crl.dec.com; id AA06214; Tue, 29 Sep 92 17:00:00 -0400
Message-Id: <9209292059.AA13727@taunton.crl.dec.com>
Cc: twl@cs.brown.edu (Ted "Theodore" W. Leung), alms@cambridge.apple.com,
        kevin@scic.intel.com    (Kevin Altis), info-dylan@cambridge.apple.com,
        dylan-builders@cambridge.apple.com
Subject: Re: dylan availability 
In-Reply-To: Your message of "Tue, 29 Sep 92 16:49:00 EDT."             <9209292049.AA12894@taunton.crl.dec.com> 
Date: Tue, 29 Sep 92 16:59:58 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Tue, 29 Sep 92 16:49:00 -0400
    From: Bob Kerns <rwk>
    To avoid getting into a long discussion, let me just point out that you
    have to read what I said.

That didn't come out right.  Try this instead:  "... you shouldn't read
too much into what I said."  I.e. I wasn't making a strong claim, just
that it's not among the worst of the bunch.

I didn't mean to imply that you were careless in your reading, or anything
like that.  Sorry it came out that way.

From twl@cs.brown.edu Tue Sep 29 17:28:15 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08345; Tue, 29 Sep 92 17:28:15 -0400
Received: from cs.brown.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04331; Tue, 29 Sep 92 17:34:51 -0400
	for alms@cambridge.apple.com
Received: from boojum.cs.brown.edu by cs.brown.edu (5.64+/Doorknob-1.5)
	id AA21552; Tue, 29 Sep 92 17:31:55 -0400
Received: by boojum.cs.brown.edu (5.64+/BrownCS-1.2)
	id AA21033; Tue, 29 Sep 92 17:31:52 -0400
Date: Tue, 29 Sep 92 17:31:52 -0400
From: twl@cs.brown.edu (Ted "Theodore" W. Leung)
Message-Id: <9209292131.AA21033@boojum.cs.brown.edu>
To: Bob Kerns <rwk@crl.dec.com>
Cc: twl@cs.brown.edu (Ted "Theodore" W. Leung), alms@cambridge.apple.com,
        kevin@scic.intel.com (Kevin Altis), info-dylan@cambridge.apple.com,
        dylan-builders@cambridge.apple.com
In-Reply-To: <9209292059.AA13727@taunton.crl.dec.com>
Subject: Re: dylan availability 

Bob Kerns writes:
>     Date: Tue, 29 Sep 92 16:49:00 -0400
>     From: Bob Kerns <rwk>
>     To avoid getting into a long discussion, let me just point out that you
>     have to read what I said.
> 
> That didn't come out right.  Try this instead:  "... you shouldn't read
> too much into what I said."  I.e. I wasn't making a strong claim, just
> that it's not among the worst of the bunch.
> 
> I didn't mean to imply that you were careless in your reading, or anything
> like that.  Sorry it came out that way.

No need to worry.  I'm not overly sensitive, and I saw your point.  

It would be nice to write in Dylan, but there's the chicken and egg
problem.  I've never seen a garbage collector written in LISP, and
even compilers like gambit, etc need some C or assembler stubs.  Also,
there are ome situations where you won't be able to use Dylan to write the
compiler, because you want to do more nasty low level hacking.

If this discussion continues, perhaps we should restrict it to
dylan-builders or email...

Ted

From camex!Camex.COM!kent@uunet.UU.NET Tue Sep 29 19:21:34 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12725; Tue, 29 Sep 92 19:21:34 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04687; Tue, 29 Sep 92 19:28:08 -0400
	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 AA08893; Tue, 29 Sep 92 19:25:09 -0400
Message-Id: <9209292325.AA08893@relay1.UU.NET>
Received: from camex.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 192459.29064; Tue, 29 Sep 1992 19:24:59 EDT
Date: Tue, 29 Sep 92 18:27:56 EDT
From: kent@Camex.COM
To: rwk@crl.dec.com, uunet!cs.brown.edu!twl@uunet.UU.NET
Subject: Re: dylan availability
Cc: alms@cambridge.apple.com, dylan-builders@cambridge.apple.com,
        info-dylan@cambridge.apple.com, kent@Camex.COM, kevin@scic.intel.com,
        twl@cs.brown.edu

>If this discussion continues, perhaps we should restrict it to
>dylan-builders or email...

Please don't, this is interesting stuff!  If I get a vote, I say keep going.

-kb

From rwk@crl.dec.com Tue Sep 29 19:48:04 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13668; Tue, 29 Sep 92 19:48:04 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04774; Tue, 29 Sep 92 19:54:40 -0400
	for alms@cambridge.apple.com
Received: by crl.dec.com; id AA18072; Tue, 29 Sep 92 19:51:45 -0400
Received: by easynet.crl.dec.com; id AA08735; Tue, 29 Sep 92 19:51:43 -0400
Message-Id: <9209292351.AA26134@taunton.crl.dec.com>
To: kent@Camex.COM
Cc: uunet!cs.brown.edu!twl@uunet.UU.NET, alms@cambridge.apple.com,
        dylan-builders@cambridge.apple.com, info-dylan@cambridge.apple.com,
        kevin@scic.intel.com, twl@cs.brown.edu
Subject: Re: dylan availability 
In-Reply-To: Your message of "Tue, 29 Sep 92 18:27:56 EDT."             <9209292325.AA08893@relay1.UU.NET> 
Date: Tue, 29 Sep 92 19:51:42 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Tue, 29 Sep 92 18:27:56 EDT
    From: kent@Camex.COM
    Please don't, this is interesting stuff!  If I get a vote, I say keep going.

At risk of starting a meta-discussion:

I think info-dylan probably should be restricted to discussions
about the language visible to a user (that is, "can I write it
this way?" sorts of stuff).  dylan-builders should probably
be of interest to those interested in how to implement dylan,
or detailed issues of meaning that primarly affect implementation.

Probably, general discussions like how to write compilers in
terms of themselves, or the use of subprimitives, or why you
don't HAVE to write stubs, probably don't belong on either one,
unless they relate to a specific implementation.

However, since I don't have a constructive suggestion for where
to move them, and I *do* believe those of us who have done a
few Lisps should share our experience, I'm not going to propose
forbidding them.  At the same time, I would hate to distract
Apple's Dylan folks from such important stuff as >> finally telling
us about macros << (dig, dig, message to follow).

My suggestion:  have such discussions for now on dylan-builders.
Responding to such things would be on a volunteer basis, and would
not fall on Apple's shoulders.  If the volume becomes a problem,
move it to a separate list.  If it grows beyond bounds, some of
the more experienced folk will drop out, depending on their
circumstances and patience, and can still stay on dylan-builders.

A varient would be the same plan, except on info-dylan.

O Keeper of the Lists, What Think Ye?

From mcw@cs.rice.edu Tue Sep 29 22:26:52 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19611; Tue, 29 Sep 92 22:26:52 -0400
Received: from cs.rice.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05035; Tue, 29 Sep 92 22:33:30 -0400
	for info-dylan@cambridge.apple.com
Received: by cs.rice.edu (AA24322); Tue, 29 Sep 92 21:30:36 CDT
Date: Tue, 29 Sep 92 21:30:36 CDT
From: mcw@cs.rice.edu (Michael Wirth)
Message-Id: <9209300230.AA24322@cs.rice.edu>
To: info-dylan@cambridge.apple.com
Subject: Re: dylan availability
Cc: mcw@cs.rice.edu

Re the appropriate forum for the current thread on general dylan complier
issues.

Since there aren't several competing commercial implementations of Dylan for
each platform of interest yet :-), I suspect that most of us potential Dylan
users are also interested in compiler implementation issues.  I know I am.
So please keep the current discussion on info-dylan.

On the other hand, if you want to discuss internal matters for a specific
implementation (e.g., Thomas), then I suspect dylan-builders is the right
place.

Mike Wirth

PS:  I've been a member of the ACM's SIGPLAN for over twenty years, not becasue
I expect to write many compilers, but because that's where the interesting
issues about programming languages get discussed.

From camex!Camex.COM!kent@uunet.UU.NET Wed Sep 30 10:03:41 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15855; Wed, 30 Sep 92 10:03:41 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05737; Wed, 30 Sep 92 10:10:21 -0400
	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 AA28197; Wed, 30 Sep 92 10:07:20 -0400
Message-Id: <9209301407.AA28197@relay1.UU.NET>
Received: from camex.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 100612.11128; Wed, 30 Sep 1992 10:06:12 EDT
Date: Wed, 30 Sep 92 09:40:33 EDT
From: kent@Camex.COM
To: uunet!crl.dec.com!rwk@uunet.UU.NET
Subject: Re: dylan availability
Cc: alms@cambridge.apple.com, dylan-builders@cambridge.apple.com,
        info-dylan@cambridge.apple.com, kent@Camex.COM, kevin@scic.intel.com,
        twl@cs.brown.edu

>My suggestion: have such discussions for now on dylan-builders.

This would be OK by me, except I'm not building a Dylan implementation
and the announcement I saw for dylan-builders looked like it was only
for people who are--for it asked for specifics about the planned
implementation.  I figured I didn't qualify.

If dylan-builders is open to "plain old folks" for lurking, add me to
the lurker list and move the thread over there.


Thanks for everybody's meta-patience.


-kb

--
Kent Borg            kent@camex.com or (when it is *working*) kentborg@aol.com
                                            H:(617) 776-6899  W:(617) 426-3577
As always, things look better when some costs are left out.
						      -Economist 3-28-92 p. 94

From alms@cambridge.apple.com Wed Sep 30 12:23:03 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19415; Wed, 30 Sep 92 12:23:03 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9209301623.AA19415@cambridge.apple.com>
Date: Wed, 30 Sep 1992 12:35:37 -0500
To: Bob Kerns <rwk@crl.dec.com>, kent@Camex.COM
From: alms@cambridge.apple.com
Subject: Re: dylan availability
Cc: uunet!cs.brown.edu!twl@uunet.UU.NET, alms@cambridge.apple.com,
        dylan-builders@cambridge.apple.com, info-dylan@cambridge.apple.com,
        kevin@scic.intel.com, twl@cs.brown.edu

> 
> Date: Tue, 29 Sep 92 19:51:42 -0400
> From: Bob Kerns <rwk@crl.dec.com>
>
> At risk of starting a meta-discussion:
> 
> I think info-dylan probably should be restricted to discussions
> about the language visible to a user (that is, "can I write it
> this way?" sorts of stuff).  dylan-builders should probably
> be of interest to those interested in how to implement dylan,
> or detailed issues of meaning that primarly affect implementation.

That was pretty much our intention, except that info-dylan isn't
restricted to language design and usage discussions.  It can also
include marketting discussions, programming environment discussions, 
discussions of particular implementations, etc.

I think that there will inevitably be a bit of wandering on both
lists.  That's the nature of the net, and it's not necessarily a
bad thing.


> Date: Wed, 30 Sep 92 09:40:33 EDT
> From: kent@Camex.COM
>
> >My suggestion: have such discussions for now on dylan-builders.
> 
> This would be OK by me, except I'm not building a Dylan implementation
> and the announcement I saw for dylan-builders looked like it was only
> for people who are--for it asked for specifics about the planned
> implementation.  I figured I didn't qualify.
> 
> If dylan-builders is open to "plain old folks" for lurking, add me to
> the lurker list and move the thread over there.

The dylan-builders list is open to anyone who is interested in practical
issues of implementing Dylan.

I hope this clarifies things.

  -Andrew


From bachrach@miles.ircam.fr Wed Sep 30 13:44:20 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21224; Wed, 30 Sep 92 13:44:20 -0400
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06425; Wed, 30 Sep 92 13:50:54 -0400
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Wed, 30 Sep 1992 18:46:51 +0100
Received: by miles.ircam.fr, Wed, 30 Sep 1992 18:46:49 +0100
Date: Wed, 30 Sep 1992 18:46:49 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199209301746.AA07685@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: Dylan's type system

Howdy who!

Dylan goes part way towards permitting the specification of types.
Unfortunately, in my opinion, it falls short.  In the name of
consistency, ease of use, type safety, and efficiency, Dylan should
provide a mechanism to specify the type of an object everytime an
object is declared.  (To all those that don't want to specify types,
power to you, I still want it to be optional.)  As it stands now, the
only time one can truly specify the type of an object is with the bind
construct.  There are many places where one would like to specify the
type of an object but is not allowed.  There is an ugly work around
that works in many cases and that involves using a new lexical
variable introduced and typed by bind.  Alas, this circumvents type
checking (among many other things).

I now state the places where one can't specify the type of an object
and suggest a syntax:

1. define

There is no way to specify the type of a module variable introduced
with define.

Suggested syntax:  (define (big-integer <integer>) 100000000)
Problem: Possible confusion with Scheme syntax?  Too bad.

2. non-specialized parameters

It would be nice to be able to specify the type of a parameter without
incurring the dispatch penalty.  Let's say that a parameter has the
same type in all the methods for a particular generic-function.  The
programmer really doesn't want to incur the overhead of specialization
for this parameter, because the specialization is really only
performing a kind of type-checking.  Perhaps there could be a flag (or
maybe sealing a class does this now) for turning off dispatching when
a parameter has only one specializer (where dispatching is really just
doing a kind of type-checking anyways).

Suggested syntax: ???

3. #key

There is no way to specify the type of a keyword parameter.  I
understand that there might be some confusion between a type and a
specialization and that it is difficult to use keyword parameters for
specialization, but this really falls short in terms of being able to
specify the types of the parameters.  In common-lisp, one can always
fall back on declare for these key parameters and non-specialized
parameters. 

Suggested syntax:  #key ((default <number>) 1) ... and all the combinations
Problem: Confusion with specialization... there must be a way!!!

4. #rest

There should be a way to specify the type of the rest parameters.  It
is silly to only be able to be able to specify the type of only the
number in the method +, for example.

Suggested syntax: #rest (numbers <number>)
Problem: Confusion with numbers being a <number>...

5. return types

There needs to be a way to specify return values in `define-method' AND 
`define-generic-function' because the return values might differ
in the methods of a given generic-function (i.e., they could be subclasses of
the return-values of the generic-function).  For users that want maximal 
efficiency and/or type-checking, it is crucial to provide a convenient mechanism
for specifying the return-values.

Suggested syntax: (define-method name (... #returns <integer>) ...) or
                  (define-method name (... #: <integer>) ...) 
Problem: still a bit heavy-handed

====

For efficiency's sake, it has proven very useful (in Sather) to be
able to specify that an object is precisely of a particular type, not
just a particular type or any of its subclasses.  By specifying the
exact type of an object, one can circumvent dispatching, which is
particularly expensive for accessing an object's slots in a
multiple-inheritance language (i.e., calculating the offset of a slot
each time it is referenced, even with caching).

One obvious implementation optimization (that is taken in Sather) is
to provide separate copies of each of the methods for each subclass of
each specializer where each specializer is replaced with an exact type
specification.  Although, this increases code size, it dramatically
improves performance.  (I could give an example if anyone was
interested.)

The previous optimization only works for parameters and it seems
crucial to have this precision with lexical variables as well.

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.  How type-checking
for parameters and return-values?

-- jonathan bachrach

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

From moon Wed Sep 30 15:53:00 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24219; Wed, 30 Sep 92 15:53:00 -0400
Full-Name: David Moon
Message-Id: <9209301953.AA24219@cambridge.apple.com>
Date: Wed, 30 Sep 92 15:57:04 EDT
From: moon (David A. Moon)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: Dylan's type system
Cc: info-dylan@cambridge.apple.com

> Date: Wed, 30 Sep 1992 18:46:49 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> ....

This was an interesting message, but right now I just want to comment on one 
part of it:

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

From balr!vpnet!akcs.rafeek@clout.chi.il.us Thu Oct  1 10:25:01 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11985; Thu, 1 Oct 92 10:25:01 -0400
Received: from clout.chi.il.us by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08136; Thu, 1 Oct 92 10:31:50 -0400
	for info-dylan@cambridge.apple.com
Received: from balr by clout.chi.il.us with uucp
	(Smail3.1.26.7 #1) id m0maRGM-00047zC; Thu, 1 Oct 92 09:12 CDT
Received: by balr.balr.com (/\==/\ Smail3.1.21.1 #21.4)
	id <m0maRAa-0002bBC@balr.balr.com>; Thu, 1 Oct 92 09:06 CDT
Received: by vpnet.chi.il.us (/\=-/\ Smail3.1.18.1 #18.27)
	id <m0maQhS-0000EqC@vpnet.chi.il.us>; Thu, 1 Oct 92 08:36 CDT
Message-Id: <m0maQhS-0000EqC@vpnet.chi.il.us>
Date: Thu, 1 Oct 92 08:36 CDT
To: info-dylan@cambridge.apple.com
From: akcs.rafeek@vpnet.chi.il.us (Rafeek M. Kottai)
Subject: Add name to list.

Dylan user group,

Please add my name to the list for Dyalan info. My address is as follows:

akcs.rafeek@vpnet.chi.il.usa

rafeek
. 

From stodghil@cs.cornell.edu Thu Oct  1 11:21:09 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14343; Thu, 1 Oct 92 11:21:09 -0400
Received: from THIALFI.CS.CORNELL.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08250; Thu, 1 Oct 92 11:27:56 -0400
	for info-dylan@cambridge.apple.com
Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99C)
	id AA12659; Thu, 1 Oct 92 11:24:44 -0400
Received: from HEL.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D)
	id AA16179; Thu, 1 Oct 92 11:24:43 -0400
From: stodghil@cs.cornell.edu (Paul Stodghill)
Message-Id: <9210011524.AA14559@hel.cs.cornell.edu>
Received: by hel.cs.cornell.edu (5.67/N-0.13)
	id AA14559; Thu, 1 Oct 92 11:24:37 -0400
To: info-dylan@cambridge.apple.com
Subject: Questions about reflective operations on functions and methods
Date: Thu, 01 Oct 92 11:24:37 -0400

1) Are the methods of APPLICABLE-METHOD?, SORTED-APPLICABLE-METHODS, etc.,
for <generic>'s frozen? If not, what is supposed to happen if I substitute
other methods in their place.

2) What is supposed to happen if I create new methods for these generics.
For instance, can I add methods to these generics in such a way that

	(<object> <keyword> ...)

is a function application a la Smalltalk?

3) If the answer to question #1 is Yes, and the answer to #2 is No, what is
the motivation for including these generics in the language specification?

From alms@cambridge.apple.com Thu Oct  1 15:44:22 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24213; Thu, 1 Oct 92 15:44:22 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210011944.AA24213@cambridge.apple.com>
Date: Thu, 1 Oct 1992 15:57:12 -0500
To: stodghil@cs.cornell.edu (Paul Stodghill), info-dylan@cambridge.apple.com
From: alms@cambridge.apple.com
Subject: Re: Questions about reflective operations on functions and methods

> 1) Are the methods of APPLICABLE-METHOD?, SORTED-APPLICABLE-METHODS, etc.,
> for <generic>'s frozen? If not, what is supposed to happen if I substitute
> other methods in their place.

In general, the current manual doesn't sufficiently specify which
branches of which generic functions are frozen.  We are going to
specify this as part of the next round of language design, which
we're about to start.

> 2) What is supposed to happen if I create new methods for these generics.
> For instance, can I add methods to these generics in such a way that
> 
> 	(<object> <keyword> ...)
> 
> is a function application a la Smalltalk?

The Dylan manual does not say that these functions are used by the Dylan
runtime in performing function calls.  So, if you added methods to them,
it wouldn't necessarily have any effect on the system at all.

> 3) If the answer to question #1 is Yes, and the answer to #2 is No, what is
> the motivation for including these generics in the language specification?

That's a good question.  It may be that, lacking any intercessory capability,
these functions aren't terribly useful.  I can imagine APPLICABLE-METHOD?
being useful as a sort of safety check, even without a full meta-object
protocol.  It's harder for me to see how SORTED-APPLICABLE-METHODS would
be useful, except perhaps by the programming environment.

Opinions?

  -Andrew


From stodghil@cs.cornell.edu Thu Oct  1 16:04:56 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25108; Thu, 1 Oct 92 16:04:56 -0400
Received: from THIALFI.CS.CORNELL.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08795; Thu, 1 Oct 92 16:11:47 -0400
	for info-dylan@cambridge.apple.com
Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99C)
	id AA17541; Thu, 1 Oct 92 16:08:33 -0400
Received: from HEL.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D)
	id AA01837; Thu, 1 Oct 92 16:08:38 -0400
From: stodghil@cs.cornell.edu (Paul Stodghill)
Message-Id: <9210012008.AA14822@hel.cs.cornell.edu>
Received: by hel.cs.cornell.edu (5.67/N-0.13)
	id AA14822; Thu, 1 Oct 92 16:08:30 -0400
To: alms@cambridge.apple.com, info-dylan@cambridge.apple.com
Subject: Re: Questions about reflective operations on functions and methods 
In-Reply-To: Your message of Thu, 01 Oct 92 15:57:12 -0500.
             <9210011944.AA24213@cambridge.apple.com> 
Date: Thu, 01 Oct 92 16:08:29 -0400


> That's a good question.  It may be that, lacking any intercessory capability,
> these functions aren't terribly useful.  I can imagine APPLICABLE-METHOD?
> being useful as a sort of safety check, even without a full meta-object
> protocol.  It's harder for me to see how SORTED-APPLICABLE-METHODS would
> be useful, except perhaps by the programming environment.

> Opinions?

Yes. But first a question: how concerned are you about the efficiency of
compiler generated code? If this is a concern, then I'm not sure that you
want the language to be too reflective, certainly not in a destructive
manner. If compiler-issues are not high priority, then go ahead and make
the language competely reflective. Could be way cool. For instance, hygenic
macros would be easy to implement if the user could add methods to EVAL.

>   -Andrew


From stodghil@cs.cornell.edu Thu Oct  1 16:08:51 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25260; Thu, 1 Oct 92 16:08:51 -0400
Received: from THIALFI.CS.CORNELL.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08824; Thu, 1 Oct 92 16:15:42 -0400
	for info-dylan@cambridge.apple.com
Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99C)
	id AA17569; Thu, 1 Oct 92 16:12:29 -0400
Received: from HEL.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99D)
	id AA01996; Thu, 1 Oct 92 16:12:34 -0400
From: stodghil@cs.cornell.edu (Paul Stodghill)
Message-Id: <9210012012.AA14856@hel.cs.cornell.edu>
Received: by hel.cs.cornell.edu (5.67/N-0.13)
	id AA14856; Thu, 1 Oct 92 16:12:26 -0400
To: info-dylan@cambridge.apple.com
Subject: Subscribe me please!
Date: Thu, 01 Oct 92 16:12:25 -0400

I realize this message should go to info-dylan-req, but it already did.
Twice. Someone, _puh-lease_ subscribe me to this list!

(If I already am subscribed, my apologies, but it doesn't look like I am).


From lynch@ils.nwu.edu Thu Oct  1 16:27:21 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26052; Thu, 1 Oct 92 16:27:21 -0400
Received: from aristotle.ils.nwu.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08880; Thu, 1 Oct 92 16:34:11 -0400
	for info-dylan@cambridge.apple.com
Received: from [129.105.100.156] by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05)
	id AA16450; Thu, 1 Oct 92 15:30:13 CDT
Date: Thu, 1 Oct 92 15:30:12 CDT
Message-Id: <9210012030.AA16450@aristotle.ils.nwu.edu>
To: info-dylan@cambridge.apple.com
From: lynch@ils.nwu.edu
Subject: Re: Questions about reflective operations on functions and methods

>> 1) Are the methods of APPLICABLE-METHOD?, SORTED-APPLICABLE-METHODS, etc.,
>> for <generic>'s frozen? If not, what is supposed to happen if I substitute
>> other methods in their place.
>
>In general, the current manual doesn't sufficiently specify which
>branches of which generic functions are frozen.  We are going to
>specify this as part of the next round of language design, which
>we're about to start.
>
>> 2) What is supposed to happen if I create new methods for these generics.
>> For instance, can I add methods to these generics in such a way that
>> 
>> 	(<object> <keyword> ...)
>> 
>> is a function application a la Smalltalk?
>
>The Dylan manual does not say that these functions are used by the Dylan
>runtime in performing function calls.  So, if you added methods to them,
>it wouldn't necessarily have any effect on the system at all.

Just a quick interjection.  PLEASE make this explicit as well, if this is
the case.

>> 3) If the answer to question #1 is Yes, and the answer to #2 is No, what is
>> the motivation for including these generics in the language specification?
>
>That's a good question.  It may be that, lacking any intercessory capability,
>these functions aren't terribly useful.  I can imagine APPLICABLE-METHOD?
>being useful as a sort of safety check, even without a full meta-object
>protocol.  It's harder for me to see how SORTED-APPLICABLE-METHODS would
>be useful, except perhaps by the programming environment.
>
>Opinions?

If they're really not useful, perhaps they should be part of an
implementation suggestions, rather than language spec.
"TANSTAAFL" Rich lynch@ils.nwu.edu


From alms@cambridge.apple.com Thu Oct  1 16:52:31 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26823; Thu, 1 Oct 92 16:52:31 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210012052.AA26823@cambridge.apple.com>
Date: Thu, 1 Oct 1992 17:01:09 -0500
To: stodghil@cs.cornell.edu (Paul Stodghill), alms@cambridge.apple.com,
        info-dylan@cambridge.apple.com
From: alms@cambridge.apple.com
Subject: Re: Questions about reflective operations on functions and methods

> > That's a good question.  It may be that, lacking any intercessory capability,
> > these functions aren't terribly useful.  I can imagine APPLICABLE-METHOD?
> > being useful as a sort of safety check, even without a full meta-object
> > protocol.  It's harder for me to see how SORTED-APPLICABLE-METHODS would
> > be useful, except perhaps by the programming environment.
> 
> > Opinions?
> 
> Yes. But first a question: how concerned are you about the efficiency of
> compiler generated code?  If this is a concern, then I'm not sure that you
> want the language to be too reflective, certainly not in a destructive
> manner.

Our goal for Dylan is not to produce a research language, but to produce
a language which can be used to deliver commercial quality applications.
We've had to moderate reflective operations to achieve this goal.

> If compiler-issues are not high priority, then go ahead and make
> the language competely reflective. Could be way cool. For instance, hygenic
> macros would be easy to implement if the user could add methods to EVAL.

I don't expect that we'll be going in this direction.  We'd certainly encourage
anyone who wants to do research on extending Dylan in these directions, though.

  -Andrew


From gsb Thu Oct  1 17:16:07 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27778; Thu, 1 Oct 92 17:16:07 -0400
Date: Thu, 1 Oct 92 17:16:07 -0400
From: Glenn S. Burke <gsb>
Full-Name: Glenn S. Burke
Message-Id: <9210012116.AA27778@cambridge.apple.com>
To: Jonathan.Bachrach@ircam.fr
In-Reply-To: Jonathan Bachrach's message of Wed, 30 Sep 1992 18:46:49 +0100 <199209301746.AA07685@miles.ircam.fr>
Subject: Dylan's type system
Cc: info-dylan

   Date: Wed, 30 Sep 1992 18:46:49 +0100
   From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
   . . .
   2. non-specialized parameters

   It would be nice to be able to specify the type of a parameter without
   incurring the dispatch penalty.  Let's say that a parameter has the
   same type in all the methods for a particular generic-function.  The
   programmer really doesn't want to incur the overhead of specialization
   for this parameter, because the specialization is really only
   performing a kind of type-checking.  Perhaps there could be a flag (or
   maybe sealing a class does this now) for turning off dispatching when
   a parameter has only one specializer (where dispatching is really just
   doing a kind of type-checking anyways).

The issue of whether to do type checking vs. doing "dispatching"
should be relegated to the implementation and perhaps more general
optimization suggestions, and need not be specified in the language.
I can imagine an implementation where this sort of optimization is
performed dynamically and automatically, and furthermore it doesn't
necessarily require that the parameter have the same type in all
methods of the generic function, only in the subset being selected
from.

---------------------------------------------------------------------------
Glenn S. Burke                | gsb@cambridge.apple.com
Phone: 617/374-5313           | Applelink: GSB

"My running mate took the lead, was the author, of the Job Training
Partnership Act.  Now, because of a lot of smoke and frenzying of
bluefish out there, going after a drop of blood in the water, nobody
knows that."  George Bush, on NBC-TV's Today show, defending his vice
presidential nominee.  Bush also defended his choice of Quayle with,
"There's something very exciting about putting some confidence in
someone in his 30s or 40s."  11/3/88 [Bushisms]

From alms@cambridge.apple.com Thu Oct  1 17:49:42 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29172; Thu, 1 Oct 92 17:49:42 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210012149.AA29172@cambridge.apple.com>
Date: Thu, 1 Oct 1992 17:58:25 -0500
To: info-dylan
From: alms@cambridge.apple.com
Subject: Dylan FAQ, Monthly Posting

Dylan(tm) FAQ September 21, 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.

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.  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)
  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)
  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)
  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 products based on Dylan.

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

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

* 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 a C or Algol-like 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 cfry@MIT.EDU Thu Oct  1 17:58:58 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29565; Thu, 1 Oct 92 17:58:58 -0400
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09187; Thu, 1 Oct 92 18:05:49 -0400
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA16192; Thu, 1 Oct 92 18:02:27 EDT
Message-Id: <9210012202.AA16192@MIT.EDU>
Date: Thu, 01 Oct 92 18:02:25 EST
From: cfry@MIT.EDU (Christopher Fry)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: Dylan's type system
Cc: info-dylan@cambridge.apple.com

I'd like to second Jonathan Bachrach proposal for being able
to declare types all over the place. 
This makes program understanding programs a lot easier to write, esp,
when you're trying to give the programmer a good error message.

But the real reason I like it is that it serves as documentation.
It will make the code easier to read because the programmer can
indicate their INTENT as they're writting. Even if the
programming environment treated them entirely as comments,
this would still help a coder catch more of their own bugs.

Putting such "comments" in a standardized place makes it easier
for another programmer to see the bugs too. I wouldn't want to
force anybody to specify types everywhere, but for many kinds of 
big programs, my guess is that declaring types in variable defs,
fn args, and fn returned values would save hacker time.

This also leaves the door open for some smart programmer's assistant
to INFER types and fill them in automatically into the user's own
source code. When it came to an ambiguity or contradiction it could 
ask the user what to do with a menu of options.

From rwk@crl.dec.com Thu Oct  1 19:50:31 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03974; Thu, 1 Oct 92 19:50:31 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09391; Thu, 1 Oct 92 19:57:20 -0400
	for alms@cambridge.apple.com
Received: by crl.dec.com; id AA27030; Thu, 1 Oct 92 19:54:22 -0400
Received: by easynet.crl.dec.com; id AA12369; Thu, 1 Oct 92 19:54:21 -0400
Message-Id: <9210012354.AA14649@taunton.crl.dec.com>
To: alms@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
Subject: A few comments on the FAQ
In-Reply-To: Your message of "Thu, 01 Oct 92 17:58:25 CDT."             <9210012149.AA29172@cambridge.apple.com> 
Date: Thu, 01 Oct 92 19:54:19 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

First, a meta-comment.  It would be helpful if you
included a summary of what has changed in each edition
of the FAQ.
    
    * 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.

I think this is incorrect.  I think the correct statement is:
  A single i/o system will be seriously limited in functionality,
  and will fit poorly into many UI environments and storage systems.
  Nonetheless, it is important to have one so that fully portable
  code can be written at all.  Unless customized for a particular
  environment, such code's UI will be very limited, but that is a
  universal tradeoff for portable code.

If you're serious about going after C programmers, you have to at
least do as good a job as ANSI C in this area.  That's not hard,
and it's useful.  But in fact, you can do much better, since you
have an object system and multiple dispatch.  You could specialize
on implementation, so that an alert message on a Mac on a window
stream pops up an alert dialog, on Motif pops up a Motif dialog,
on a serial stream does it serially, etc.

You also have a big advantage over ANSI C in that you don't
have to attend to a myriad compatibility issues.

It should certainly be emphasized that this is a library issue,
not a language issue.
    
    * 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.

Regardless of whether you standardize on a single mechanism, I
think you need to establish some ground rules and guarentees.
For example, CHANGE-CLASS while a method is running on that
object, should not result in overwriting random pieces of memory.
It should do something predictable and reasonably safe, even
if it "is an error" to do it.

Another issue is whether order-of-writes is preserved when viewed from
another process.  If I set A and then set B, am I guarenteed that in
another process, I won't see B set, and later still see the old value
of A?  This may seem obvious, but in multi-processor systems, it's not.
You need to either explicitly make the restriction, or alternatively,
provide a standard way to cause the restriction to be true when
you need it.

    * 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.
    
This doesn't really address the first part of the question.
I would suggest adding something about how returning existing
instances allows optimization by sharing non-mutable instances.
It's recommended that for classes whose instances can be modified,
that fresh instances always be allocated by 'make' to avoid
confusion.
    
    * 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.
Would it help if 'setter' were a keyword instead?
    * 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.
    
Pointing out the inconvenience of doing similar stuff in C
might be helpful here.

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

It seems to me this is properly a library.
    
    * 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.

I did some thinking about this issue for CLIM.  I think it's possible
to design an application framework API which allows portable code which
integrates reasonably in any environment, and can be specialized as
needed for particular environments.  (No, don't look to existing CLIM
for hints, it's not very close).

But this has no part in the language.

One thing that would help a lot of portability-enhanced libraries,
would be the ability to do some link-time specialization.  That is,
to write implementation-specific methods, and have any methods
which only apply to a different implementation be removed from the
final application.

I haven't completely thought out how to make this work for
cross-compilation, but the basic idea is to be able to remove
methods specialized on <implementation>'s which aren't subclasses
of the target implementation.  I want to understand macros before
I make any attempt to understand cross-compilation, however.


From taihou@iss.nus.sg Fri Oct  2 01:39:40 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18381; Fri, 2 Oct 92 01:39:40 -0400
Received: from nuscc.nus.sg by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09840; Fri, 2 Oct 92 01:46:29 -0400
	for info-dylan@cambridge.apple.com
Received: from bochap.iss.nus.sg by nuscc.nus.sg (5.65/1.34)
	id AA26435; Fri, 2 Oct 92 13:43:23 +0800
Received: from chromium.iss.nus.sg by iss.nus.sg (4.1/SMI-4.1)
	id AA16531; Fri, 2 Oct 92 13:44:51 SST
Date: Fri, 2 Oct 92 13:44:51 SST
From: taihou@iss.nus.sg (Tng Tai Hou)
Message-Id: <9210020544.AA16531@iss.nus.sg>
To: info-dylan@cambridge.apple.com
Subject: unsubscribe

Please remove me from the mailing list.
Thanks.

From rme@olympia.msi.com Fri Oct  2 10:55:35 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07400; Fri, 2 Oct 92 10:55:35 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10446; Fri, 2 Oct 92 11:02:30 -0400
	for info-dylan@cambridge.apple.com
Received: from msi.com (via merlin.msi.com) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA20104; Fri, 2 Oct 92 10:59:30 -0400
Received: from olympia.msi.com.msi.COM by msi.com (4.1/SMI-4.1)
	id AA02193; Fri, 2 Oct 92 07:58:56 PDT
Received: by olympia.msi.com.msi.COM (4.1/SMI-4.1)
	id AA01954; Fri, 2 Oct 92 07:59:04 PDT
Date: Fri, 2 Oct 92 07:59:04 PDT
From: rme@olympia.msi.com (Richard M. Emberson)
Message-Id: <9210021459.AA01954@olympia.msi.com.msi.COM>
To: info-dylan@cambridge.apple.com
Subject: C++ and C binding
Cc: rme@olympia.msi.com


I want/need/(will only consider using Dylan if) a C++/C binding. We plan to use
InterViews, a C++ X Window toolkit, and have to "integrate" it into the
Dylan class heirarchy.

Any information would be appreciated.


Richard Emberson
rme@msi.com

From moon Fri Oct  2 18:23:12 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23823; Fri, 2 Oct 92 18:23:12 -0400
Full-Name: David Moon
Message-Id: <9210022223.AA23823@cambridge.apple.com>
Date: Fri, 02 Oct 92 18:27:26 EDT
From: moon (David A. Moon)
To: Bob Kerns <rwk@crl.dec.com>
Subject: Re: A few comments on the FAQ
Cc: alms@cambridge.apple.com, info-dylan@cambridge.apple.com

> Date: Thu, 01 Oct 92 19:54:19 -0400
> From: Bob Kerns <rwk@crl.dec.com>

Bob, I don't want to get into a long discussion, but a couple of your comments
made me feel like responding.  Plus right now I'm trying to find a way to 
avoid fixing a bunch of bugs I found in a program I am working on.

These are my personal comments, not any kind of response from Apple.

>     * 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....
> 
> If you're serious about going after C programmers, you have to at
> least do as good a job as ANSI C in this area....
> ....
> It should certainly be emphasized that this is a library issue,
> not a language issue.

I think there is no disagreement here.  Does the microprocessor in your 
microwave oven have an ANSI C I/O library in it?  I hope not.  That's why I/O 
is not part of the language in C nor in Dylan.

>     * 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.
> 
> Regardless of whether you standardize on a single mechanism, I
> think you need to establish some ground rules and guarentees.
> For example, CHANGE-CLASS while a method is running on that
> object, should not result in overwriting random pieces of memory.
> It should do something predictable and reasonably safe, even
> if it "is an error" to do it.

There is no change-class function in Dylan.

> Another issue is whether order-of-writes is preserved when viewed from
> another process.  If I set A and then set B, am I guarenteed that in
> another process, I won't see B set, and later still see the old value
> of A?  This may seem obvious, but in multi-processor systems, it's not.
> You need to either explicitly make the restriction, or alternatively,
> provide a standard way to cause the restriction to be true when
> you need it.

This seems likely to be highly dependent on the underlying implementation, and 
is one reason why we've been reluctant to specify anything as part of the 
language.  We souldn't want to specify something that some important platforms 
cannot implement efficiently.  Of course, that reluctance militates against 
portability, but that problem is inherent in the current state of the art of 
multiprocessing, isn't it?

>     * 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.
> 
> It seems to me this is properly a library.

Yes, but it's not quite that simple.  It is impossible to implement eval 
portably, that is, using only the facilities provided in the Dylan book.  For 
example, there is no equivalent of Common Lisp symbol-value.  This is quite 
intentional; the space savings comes not from leaving out the eval function 
itself, but from leaving out any representation of the information that eval 
would use.

So it would be a bad idea to require all implementations to include the 
infrastructure needed to make an eval library possible.

> One thing that would help a lot of portability-enhanced libraries,
> would be the ability to do some link-time specialization.  That is,
> to write implementation-specific methods, and have any methods
> which only apply to a different implementation be removed from the
> final application.
> 
> I haven't completely thought out how to make this work for
> cross-compilation, but the basic idea is to be able to remove
> methods specialized on <implementation>'s which aren't subclasses
> of the target implementation.  I want to understand macros before
> I make any attempt to understand cross-compilation, however.

Unless you have two implementations that are completely binary-code-compatible 
(not only processor instruction set, but the whole runtime environment) except 
for the user interface, or whatever these methods deal with, I don't see any 
advantage in removing these methods as late as link time.  It seems like you 
would have to compile your program separately for each implementation, so the 
customization could occur at compile time.  Macros seem like a likely 
implementation technique for compile-time customization, so once they are in 
the language it doesn't seem likely that anything else would have to be added, 
not even a portable way to determine at compile time what implementation is 
the target, since one can always have a convention of separate files defining 
a few macros with different definitions for each implementation.

From rwk@crl.dec.com Fri Oct  2 19:33:24 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26568; Fri, 2 Oct 92 19:33:24 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12007; Fri, 2 Oct 92 19:40:22 -0400
	for moon@cambridge.apple.com
Received: by crl.dec.com; id AA28785; Fri, 2 Oct 92 19:37:20 -0400
Received: by easynet.crl.dec.com; id AA29174; Fri, 2 Oct 92 19:37:20 -0400
Message-Id: <9210022337.AA08689@taunton.crl.dec.com>
To: moon@cambridge.apple.com (David A. Moon)
Cc: alms@cambridge.apple.com, info-dylan@cambridge.apple.com
Subject: Re: A few comments on the FAQ 
In-Reply-To: Your message of "Fri, 02 Oct 92 18:27:26 EDT."             <9210022223.AA23823@cambridge.apple.com> 
Date: Fri, 02 Oct 92 19:37:18 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Fri, 02 Oct 92 18:27:26 EDT
    From: moon@cambridge.apple.com (David A. Moon)
    These are my personal comments, not any kind of response from Apple.

I appreciate them, anyway.

    I think there is no disagreement here.  Does the microprocessor in your 
    microwave oven have an ANSI C I/O library in it?  I hope not.  That's why I/O 
    is not part of the language in C nor in Dylan.
    
Indeed.  But note that there *is* a standard library, that was
standardized as part of the standards process.  There needs to
be some parallel development of the language and the ancilliary
things that will make it a success.  At the very least, there
needs to be a scorecard, of what items are needed, and intended.

Such a scorecard will go a long way toward addressing a lot of
concerns, that the FAQ currently just raises as issues, without
settling them in anyone's mind.

By the way, note that there are a lot of things in the Dylan
language, which are not in ANSI C, and which would be in libraries
if they were, and which I would also hope would not be included
in my microwave.  I'm not saying that's wrong.  But libraries
aren't the only potential mechanism for "deletable modules" in
the language, and this isn't precisely the criteria either of
us are using to choose what should be libraries.

I'm not sure what the criteria are, however.  I suspect
we're both more eager to have optional environmentally-side-effecting
code be in libraries than optional datatypes.  Still, perhaps
some of the fancier datatypes should be made into standard
libaries which are documented with the language.  This will
make the language itself smaller, and might help sell it to
the C crowd.  They are more likely to understand "It's an optional
library" than "it doesn't have to be included if you don't use
it."

    There is no change-class function in Dylan.

That's what I get for sending mail at home, when my manual is
at work.  I was thinking of the instance updating when a class
changes.  If you change a class in such a way that a running
method no longer applies, what happens?  The answer perhaps
lies in a more clear separation of compile-time and runtime.

    This seems likely to be highly dependent on the underlying implementation, and 
    is one reason why we've been reluctant to specify anything as part of the 
    language.  We souldn't want to specify something that some important platforms 
    cannot implement efficiently.  Of course, that reluctance militates against 
    portability, but that problem is inherent in the current state of the art of 
    multiprocessing, isn't it?
    
I don't really think so.  I think it's a language issue.
Specifically, how much of the lower-level non-determinism
is reflected in the language?  This leads to a clear-cut
trade-off:  potential efficiency vs determinism.

If you want to reserve the efficiency, you have to say that
the order is indeterminate in some implications.  Then
people can write portable code.  I don't think that's the
best point in the trade-off curve, however.

I don't claim to know the best answer.  But there are a
number of potential ways to either give the user control,
or establish rules about what the user can expect, that
will make synchonization much easier without placing
undue burdens on implementation.

But even if you throw up your hands and say "We can't
decide the policy", that directly reflects into the language,
and the consequences need to be stated.  You can even require
implementations to state their policies, so users can write
non-portable code that takes advantage of determinism where
present.

    >     * Will Dylan include 'eval'?
    > It seems to me this is properly a library.

    So it would be a bad idea to require all implementations to include the 
    infrastructure needed to make an eval library possible.

Hmm.  Is it really too much to expect that info on external module
interfaces would be available?  If you don't want to spend the space,
don't make any externals, and any evaluation won't be able to reference
anything.

I'm a strong advocate of making interfaces manifest; AppleEvents
only go a short way toward what I'd like to see.  Given all the
work that's being done in Home Automation (q.v. Bill Gate's $14M
house), even microwave oven controllers have need of this.
    
    > One thing that would help a lot of portability-enhanced libraries,
    > would be the ability to do some link-time specialization.  That is,
    > to write implementation-specific methods, and have any methods
    > which only apply to a different implementation be removed from the
    > final application.
    
    Unless you have two implementations that are completely binary-code-compatible 
    (not only processor instruction set, but the whole runtime environment) except 
    for the user interface, or whatever these methods deal with, I don't see any 
    advantage in removing these methods as late as link time.  It seems like you 
    would have to compile your program separately for each implementation, so the 
    customization could occur at compile time.  Macros seem like a likely 
    implementation technique for compile-time customization, so once they are in 
    the language it doesn't seem likely that anything else would have to be added, 
    not even a portable way to determine at compile time what implementation is 
    the target, since one can always have a convention of separate files defining 
    a few macros with different definitions for each implementation.

I'm sorry, I should have been a bit more clear.  I really meant
"as soon as it can be determined that they're not needed.", which
could be compile time, link time, or even sometimes runtime.

Consider, too, dynamic linking, where you may add features
to the mix at runtime.

For example, consider all the code which has to ask the Gestault
managerd what features a particular Mac has.  With dynamic
linking, a lot of code for supporting old hardware can be left
out at link time.  Without dynamic linking, you fall back on
the runtime dispatch.  If you know the target environment at
compile time, the compiler is free to skip irrelevant ones.

I have used the technique of explicitly representing the runtime
environment and supplying it as an argument to methods needing
specialization by environment, quite a bit.  It works quite well,
and is very natural.  It's one of the better arguments for
multimethods, in my opinion.

From rwk@crl.dec.com Fri Oct  2 19:37:43 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26731; Fri, 2 Oct 92 19:37:43 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12048; Fri, 2 Oct 92 19:44:42 -0400
	for moon@cambridge.apple.com
Received: by crl.dec.com; id AA29179; Fri, 2 Oct 92 19:41:39 -0400
Received: by easynet.crl.dec.com; id AA29222; Fri, 2 Oct 92 19:41:39 -0400
Message-Id: <9210022341.AA08752@taunton.crl.dec.com>
Cc: moon@cambridge.apple.com    (David A. Moon), alms@cambridge.apple.com,
        info-dylan@cambridge.apple.com
Subject: Re: A few comments on the FAQ 
In-Reply-To: Your message of "Fri, 02 Oct 92 19:37:18 EDT."             <9210022337.AA08689@taunton.crl.dec.com> 
Date: Fri, 02 Oct 92 19:41:37 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Fri, 02 Oct 92 19:37:18 -0400
    From: Bob Kerns <rwk>
        
    I don't really think so.  I think it's a language issue.
    Specifically, how much of the lower-level non-determinism
    is reflected in the language?  This leads to a clear-cut
    trade-off:  potential efficiency vs determinism.
    
    If you want to reserve the efficiency, you have to say that
    the order is indeterminate in some implications.  Then

Gack.  "in some implementations."  Sorry.

    people can write portable code.  I don't think that's the
    best point in the trade-off curve, however.

From rme@olympia.msi.com Sat Oct  3 19:42:24 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29464; Sat, 3 Oct 92 19:42:24 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13187; Sat, 3 Oct 92 19:49:30 -0400
	for info-dylan@cambridge.apple.com
Received: from msi.com (via merlin.msi.com) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA10400; Sat, 3 Oct 92 19:46:19 -0400
Received: from olympia.msi.com.msi.COM by msi.com (4.1/SMI-4.1)
	id AA06290; Sat, 3 Oct 92 16:45:44 PDT
Received: by olympia.msi.com.msi.COM (4.1/SMI-4.1)
	id AA05245; Sat, 3 Oct 92 16:45:53 PDT
Date: Sat, 3 Oct 92 16:45:53 PDT
From: rme@olympia.msi.com (Richard M. Emberson)
Message-Id: <9210032345.AA05245@olympia.msi.com.msi.COM>
To: info-dylan@cambridge.apple.com
Subject: Questions:
Cc: rme@olympia.msi.com



First, is this an active mailing group?

Next, assuming that it is, I have a *real* need to find out *real* soon if Dylan can be 
	integrated with C++. Specifically, can a Dylan wrapper be put around a C++
	class hierarchy? I need to know within 2-4 weeks if a new product has any hope at
	all of basing its integration on Dylan.

Lastly, any idea when/if commercially support implementations will be available?



		Richard Emberson

		currently at:  rme@msi.com

From meehan@src.dec.com Sat Oct  3 20:08:01 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00818; Sat, 3 Oct 92 20:08:01 -0400
Received: from inet-gw-2.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13244; Sat, 3 Oct 92 20:15:08 -0400
	for info-dylan@cambridge.apple.com
Received: by inet-gw-2.pa.dec.com; id AA10485; Sat, 3 Oct 92 17:12:03 -0700
Received: by myrtle.pa.dec.com; id AA01027; Sat, 3 Oct 92 17:12:02 -0700
Message-Id: <9210040012.AA01027@myrtle.pa.dec.com>
To: rme@olympia.msi.com (Richard M. Emberson)
Cc: info-dylan@cambridge.apple.com
Subject: Re: Questions:
In-Reply-To: Message of Sat, 3 Oct 92 16:45:53 PDT    from rme@olympia.msi.com (Richard M. Emberson)    <9210032345.AA05245@olympia.msi.com.msi.COM>
Date: Sat, 03 Oct 92 17:12:01 -0700
From: meehan@src.dec.com
X-Mts: smtp


    First, is this an active mailing group?

Evidently.

    Next, assuming that it is, I have a *real* need to find out *real* soon if Dylan can be 
    	integrated with C++. Specifically, can a Dylan wrapper be put around a C++
    	class hierarchy? I need to know within 2-4 weeks if a new product has any hope at
    	all of basing its integration on Dylan.

No.  We're all just getting started with various sorts of prototype 
implementations.  I speak with no particular authority for the language, 
but I think I can say without fear of contradiction that Dylan isn't 
anywhere near ready for product development.
    
    Lastly, any idea when/if commercially support implementations will be available?
    
No.  Stop by in about a year, though.

--Jim Meehan

From bachrach@miles.ircam.fr Sun Oct  4 14:51:56 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08986; Sun, 4 Oct 92 14:51:56 -0400
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13963; Sun, 4 Oct 92 14:58:52 -0400
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Sun, 4 Oct 1992 19:55:24 +0100
Received: by miles.ircam.fr, Sun, 4 Oct 1992 19:55:21 +0100
Date: Sun, 4 Oct 1992 19:55:21 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210041855.AA01084@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: associative methods

In Dylan there are a number of method's that take an unlimited number
of arguments and convert to `binary' methods (e.g., = translates to
binary=).  Unfortunately, there is no way for a user to define their
own and I'm positive that users are going to want their own.  Sure,
one can simulate this conversion, but it is inefficient (i.e., conses
#rest list on heap and is performed at run-time).

One way to make this facility available to users would be to introduce
a new construct such as `define-associative-method' for this facility.
Instead of defining two methods (e.g., = and binary=), one would only
define the binary method and the associative method would be
automatically wrapped around -- all in a very efficient fashion.
There are remaining details to be specified and there is probably
another way to achieve what I want -- any ideas?

-- jonathan bachrach

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


From straz@cambridge.apple.com Sun Oct  4 17:03:41 1992
Received: from [90.223.0.29] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13783; Sun, 4 Oct 92 17:03:41 -0400
Full-Name: Steve Strassmann
Message-Id: <9210042103.AA13783@cambridge.apple.com>
Date: Sun, 4 Oct 1992 17:07:38 -0500
To: rme@msi.com (Richard M. Emberson)
From: Steve Strassmann <straz@cambridge.apple.com>
Subject: re: Questions:
Cc: info-dylan

>Date: Sat, 3 Oct 92 16:45:53 PDT
>From: rme@olympia.msi.com (Richard M. Emberson)
>To: info-dylan@cambridge.apple.com
>Subject: Questions:
>Cc: rme@olympia.msi.com
>
>First, is this an active mailing group?

Yes.

>Next, assuming that it is, I have a *real* need to find out *real* soon if Dylan can be 
>	integrated with C++. Specifically, can a Dylan wrapper be put around a C++
>	class hierarchy? I need to know within 2-4 weeks if a new product has any hope at
>	all of basing its integration on Dylan.

Integrating with C++ is not a feature of Dylan per se - it's up to each
implementor to provide or not as they choose. We designed Dylan with
C/C++ integration in mind, so we sure hope implementors choose to provide this.

>Lastly, any idea when/if commercially support implementations will be available?

None have been officially announced yet.


From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Mon Oct  5 01:53:33 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26427; Mon, 5 Oct 92 01:53:33 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14725; Mon, 5 Oct 92 02:00:48 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210050600.AA14725@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa21979; 5 Oct 92 1:56:57 EDT
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: associative methods 
In-Reply-To: Your message of Sun, 04 Oct 92 19:55:21 +0000.
             <199210041855.AA01084@miles.ircam.fr> 
Date: Mon, 05 Oct 92 01:56:37 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    In Dylan there are a number of method's that take an unlimited number
    of arguments and convert to `binary' methods (e.g., = translates to
    binary=).  Unfortunately, there is no way for a user to define their
    own and I'm positive that users are going to want their own.  Sure,
    one can simulate this conversion, but it is inefficient (i.e., conses
    #rest list on heap and is performed at run-time).
    
    One way to make this facility available to users would be to introduce
    a new construct such as `define-associative-method' for this facility...

In my opinion, your proposed solution is too specialized and doesn't get to
the heart of the problem.  The real problem is that the #rest machinery is
inherently expensive to use, since it is defined as creating a sequence at
runtime.  The proverbial SSC ("sufficiently smart compiler") could prove in
many cases that the sequence is confined within the method's dynamic extent
and can therefore be stack-allocated, but I think that users will become
confused and anxious about which cases heap-allocate and which don't.

For cases like + and =, in which an unlimited number of arguments are
consumed locally, I like the idea of providing some mechanism like the old
Maclisp LEXPRs.  For example, the arglist might contain "#MORE N", which
would bind n to the number of arguments that were passed.  Then the method
can iterate, using some form like (MORE-ARG i) to access each argument i.
In this case, there would be no runtime consing.  #MORE might replace
#REST (with the addition of an ARGS-TO-LIST function), or the two could
coexist as alternative arg-list forms.

Sometime in the near future I plan to write up a detailed proposal on
more-args for people to consider, but I still have to work out some
details.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From lynch@ils.nwu.edu Mon Oct  5 13:14:57 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02568; Mon, 5 Oct 92 13:14:57 -0400
Received: from [129.105.100.1] by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15802; Mon, 5 Oct 92 13:22:16 -0400
	for info-dylan@cambridge.apple.com
Received: from  by aristotle.ils.nwu.edu (4.1/SMI-ILS-1.05)
	id AB06877; Mon, 5 Oct 92 12:17:16 CDT
Date: Mon, 5 Oct 92 12:17:16 CDT
Message-Id: <9210051717.AB06877@aristotle.ils.nwu.edu>
To: info-dylan@cambridge.apple.com
From: lynch@ils.nwu.edu
Subject: Re: Questions about reflective operations on functions and methods

>> 1) Are the methods of APPLICABLE-METHOD?, SORTED-APPLICABLE-METHODS, etc.,
>> for <generic>'s frozen? If not, what is supposed to happen if I substitute
>> other methods in their place.
>
>In general, the current manual doesn't sufficiently specify which
>branches of which generic functions are frozen.  We are going to
>specify this as part of the next round of language design, which
>we're about to start.
>
>> 2) What is supposed to happen if I create new methods for these generics.
>> For instance, can I add methods to these generics in such a way that
>> 
>> 	(<object> <keyword> ...)
>> 
>> is a function application a la Smalltalk?
>
>The Dylan manual does not say that these functions are used by the Dylan
>runtime in performing function calls.  So, if you added methods to them,
>it wouldn't necessarily have any effect on the system at all.

Just a quick interjection.  PLEASE make this explicit as well, if this is
the case.

>> 3) If the answer to question #1 is Yes, and the answer to #2 is No, what is
>> the motivation for including these generics in the language specification?
>
>That's a good question.  It may be that, lacking any intercessory capability,
>these functions aren't terribly useful.  I can imagine APPLICABLE-METHOD?
>being useful as a sort of safety check, even without a full meta-object
>protocol.  It's harder for me to see how SORTED-APPLICABLE-METHODS would
>be useful, except perhaps by the programming environment.
>
>Opinions?

If they're really not useful, perhaps they should be part of an
implementation suggestions, rather than language spec.


From bachrach@miles.ircam.fr Mon Oct  5 13:15:17 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02622; Mon, 5 Oct 92 13:15:17 -0400
Received: from [129.102.1.8] by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15807; Mon, 5 Oct 92 13:22:20 -0400
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Mon, 5 Oct 1992 18:18:04 +0100
Received: by miles.ircam.fr, Mon, 5 Oct 1992 18:18:01 +0100
Date: Mon, 5 Oct 1992 18:18:01 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210051718.AA00601@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: number crunching

There has been some talk on this newsgroup about Dylan replacing C as
a system's programming language.  In addition to this, I would like to
see Dylan serve as a scientific computing language.  I would love to
see Dylan be that language (it's so darn elegant), but there are many
problems with Dylan that, in my opinion, make it too slow for these
applications.

There are two major problems with the current design that I would like
to point out in this letter: (1) representation of numbers and (2)
dispatching on numbers.  I suggest the addition of the short-float
representation and parameterized classes to alleviate some of Dylan's
short-comings.  I would appreciate comments on how to achieve the same
effect in the current Dylan.

Representation:

Dylan desperately needs a short-float representation so as to
alleviate the need to cons floats on call to and return from methods.
This float consing problem plagues LISP implementations and keeps it
from being a serious number-crunching language.

This short-float lack is exacerbated by a lack of a floating-point
vector type.  Imagine having to store boxed floats in a vector for
computing serious matrix operations, it would cons tremendously!  This
is what a programmer would have to use with the current Dylan design.
With a short-float, at least the programmer could store the floats
directly in the vector (without pointers).

It's clear that the short-float would not suffice for serious number
crunchers who demand even more precision.  I guess with current
compiler technology, one can at least compile away the pointers in the
code of a particular method -- the problem is the storage format and
the consing that happens when a method calls another method with float
args and/or return values.  Perhaps some of this overhead goes away
with frozen classes.

Dispatching:

Suppose one wanted to write an efficient matrix object that would work
for a variety of element types.  As it stands now in Dylan, one would
declare the elements as numbers, for example, and then write the
matrix methods to operate on matrices of numbers.  Unfortunately, this
would be very slow, because code inside these methods would
necessarily have to dispatch on all numeric arithmetic.  

The obvious thing to do is to then write a separate matrix class and
separate methods for each different type of number (i.e., one for
complex, one for real, one for integer, one for fixpoint, etc.).  Then
all the methods would have the proper types and the compiler could
inline all the arithmetic and the code would run nearly as fast as C.

The problem with this approach is that the user has to meticulously
copy and type each of the methods.  This is completely dissatisfactory.
An alternative approach found in OOSL's (e.g., C++, Eiffel, and
Sather) is to parameterize the class by the type of the element.
These classes get instantiated at compile time and separate copies are
automatically generated with the proper typing.  This makes it very
convenient to construct very efficient objects.

Parameterized classes would also help in solving the first problem,
because one could create a parameterized vector class.

----

What are other people seeing in Dylan that I'm missing.  How is Dylan
going to achieve the same kind of efficiency as C++ or Sather for
number crunching or systems applications?

-- jonathan bachrach

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

From moon Mon Oct  5 16:37:48 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06015; Mon, 5 Oct 92 16:37:48 -0400
Full-Name: David Moon
Message-Id: <9210052037.AA06015@cambridge.apple.com>
Date: Mon, 05 Oct 92 16:42:21 EDT
From: moon (David A. Moon)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: number crunching
Cc: info-dylan@cambridge.apple.com

> Date: Mon, 5 Oct 1992 18:18:01 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>

I don't think anyone has proposed Dylan as a scientific programming language. 
That is not the same thing as a systems programming language.  However, my 
second hand knowledge of numeric programming suggests that that community 
could benefit a lot from object-oriented and higher-order-function programming 
techniques, so scientific programming seems like an interesting direction in 
which to extend Dylan in the future.

I think this ought to be regarded as an extension, rather than something that 
is wrong with Dylan and needs to be fixed.  But then, my own opinion is that 
the trig functions in chapter 14, complex numbers, and floating point numbers 
should all be removed from the Dylan language.  Perhaps you and I are actually 
in agreement there; my reasoning is that if one isn't going to do a serious 
implementation of floating-point, one shouldn't do a half-baked job, instead 
one should not even claim to try.

That's just my own opinion, not Apple's.  But I wonder how other people on 
this list feel.  I know most people who implement Unix C numerics libraries 
don't agree with me at all: from what I've heard they evidently think a 
half-baked job is fine.

One lower-level comment about your message: you need to be more clear on the 
distinction between the language and a particular implementation of the 
language.  You are assuming that the language is implemented a certain way and 
then criticizing the language on that basis.  But how can you be sure that 
that is the only way the language will be implemented?  Better either to 
criticize one particular implementation or to argue that the language as it 
stands cannot be implemented any other way and see if everyone buys that 
argument.

From rwk@crl.dec.com Mon Oct  5 18:05:24 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07667; Mon, 5 Oct 92 18:05:24 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16472; Mon, 5 Oct 92 18:12:45 -0400
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA15103; Mon, 5 Oct 92 18:09:09 -0400
Received: by easynet.crl.dec.com; id AA03768; Mon, 5 Oct 92 18:09:17 -0400
Message-Id: <9210052209.AA00688@taunton.crl.dec.com>
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Cc: info-dylan@cambridge.apple.com
Subject: Re: number crunching 
In-Reply-To: Your message of "Mon, 05 Oct 92 18:18:01 BST."             <199210051718.AA00601@miles.ircam.fr> 
Date: Mon, 05 Oct 92 18:09:15 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Mon, 5 Oct 1992 18:18:01 +0100
    From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
    The problem with this approach is that the user has to meticulously
    copy and type each of the methods.  This is completely dissatisfactory.
    An alternative approach found in OOSL's (e.g., C++, Eiffel, and
    Sather) is to parameterize the class by the type of the element.
    These classes get instantiated at compile time and separate copies are
    automatically generated with the proper typing.  This makes it very
    convenient to construct very efficient objects.

Another way to achieve the same end is with macros.  With
a decent macro system, there's never any reason to copy code.

Often, you can even do this with C's not-quite-macros.

This also gives you control over just which methods you
generate, and when you fall back on generic arithmetic.
With multimethods, you potentially have combinatorically
many methods to generate, but you may only need a few
of them.

From chu@server.cs.jhu.edu Mon Oct  5 18:15:00 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07989; Mon, 5 Oct 92 18:15:00 -0400
Received: from server.cs.jhu.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16509; Mon, 5 Oct 92 18:22:21 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210052222.AA16509@brazil.cambridge.apple.com>
Received: by server.cs.jhu.edu; Mon, 5 Oct 92 18:19:07 -0400
Date: Mon, 5 Oct 92 18:19:05 -0400
From: chu@server.cs.jhu.edu
Sender: chu@server.cs.jhu.edu
To: moon@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: David A. Moon's message of Mon, 05 Oct 92 16:42:21 EDT <9210052037.AA06015@cambridge.apple.com>
Subject: number crunching


   Sender: moon@cambridge.apple.com
   Date: Mon, 05 Oct 92 16:42:21 EDT
   From: moon@cambridge.apple.com (David A. Moon)

	...

   I think this ought to be regarded as an extension, rather than something that 
   is wrong with Dylan and needs to be fixed.  But then, my own opinion is that 
   the trig functions in chapter 14, complex numbers, and floating point numbers 
   should all be removed from the Dylan language.  Perhaps you and I are actually 
   in agreement there; my reasoning is that if one isn't going to do a serious 
   implementation of floating-point, one shouldn't do a half-baked job, instead 
   one should not even claim to try.

   That's just my own opinion, not Apple's.  But I wonder how other people on 
   this list feel.  I know most people who implement Unix C numerics libraries 
   don't agree with me at all: from what I've heard they evidently think a 
   half-baked job is fine.

	...

I was a bit startled upon seeing the above-mentioned numeric features
in the Dylan spec--my first inclination would be to leave them out
(and I'm a Common Lisp programmer!). What was the rationale for
including them?

Phil Chu
Graduate School, Computer Science
Johns Hopkins University
internet: chu@server.cs.jhu.edu

From cfry@MIT.EDU Mon Oct  5 20:19:04 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11328; Mon, 5 Oct 92 20:19:04 -0400
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16978; Mon, 5 Oct 92 20:26:26 -0400
	for moon@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA19019; Mon, 5 Oct 92 20:23:16 EDT
Message-Id: <9210060023.AA19019@MIT.EDU>
Date: Mon, 05 Oct 92 20:12:26 EST
From: cfry@MIT.EDU (Christopher Fry)
To: moon@cambridge.apple.com (David A. Moon)
Subject: Re: number crunching
Cc: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>,
        info-dylan@cambridge.apple.com

There's a bunch of discussion about off-loading functionality to libraries.
One of the claims I see is that this works perfectly fine in C.

From recent experience working with a large corporation that was using 
Unix/C/X/Motif and from comments at the Lisp User's conf, this has not
worked so well. I want the designers of Dylan to at least be aware of
the failure mode so that you can attack it straight on rather than 
discover it the had way.

Our user needs the functionality in Lib-A and in Lib-B.
Lib-A needs Lib-C1.0, but lib-B needs lib-c1.1.

There are lots of variations on this theme. As there gets to be lots
of libraries, the problems start to compound, because then people
make meta-libraries containing version 1.1 of lib-a and version 1.2 of lib-b,
etc. Then 2 meta-libraries overlay enough to kill each other and one doesn't run 
in anything less than system 7.1 whereas another needs 7.0, etc.  The libraries 
come from different vendors so they're always out of sync with each other & the 
operating system, etc.

Yes CL is too big. But its at least self-consistent and complete enough not to 
require lots of libraries. 
I like the idea that Dylan started out with a small lisp. 
Now decide when the middle of Dylan's
life cycle will be and how many megabytes will be on a $4 RAM chip that year.
[Hint, a 64Mbit chip has already been prototyped.]
If $4 is too much, think about how much software costs, and what percentage of a 
product it will be compared to the hardware as hardware costs continue to fall
faster than software costs.

Its ok with me if my toaster has an EVAL in it that is never called. 
Toaster's aren't exactly materially efficient either. If 90% of the code is
wasted, big deal. 


Is C's "Standard IO lib" as standard as everyone would hope? 
I bet not, and it has a LOT less functionality than CL I/O.

From rwk@crl.dec.com Mon Oct  5 20:56:06 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12213; Mon, 5 Oct 92 20:56:06 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17059; Mon, 5 Oct 92 21:03:27 -0400
	for moon@cambridge.apple.com
Received: by crl.dec.com; id AA23549; Mon, 5 Oct 92 21:00:16 -0400
Received: by easynet.crl.dec.com; id AA05376; Mon, 5 Oct 92 21:00:15 -0400
Message-Id: <9210060100.AA00830@taunton.crl.dec.com>
To: moon@cambridge.apple.com (David A. Moon)
Cc: Jonathan Bachrach    <Jonathan.Bachrach@ircam.fr>,
        info-dylan@cambridge.apple.com
Subject: Re: number crunching 
In-Reply-To: Your message of "Mon, 05 Oct 92 16:42:21 EDT."             <9210052037.AA06015@cambridge.apple.com> 
Date: Mon, 05 Oct 92 21:00:13 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Mon, 05 Oct 92 16:42:21 EDT
    From: moon@cambridge.apple.com (David A. Moon)
    
    But then, my own opinion is that 
    the trig functions in chapter 14, complex numbers,
    and floating point numbers should all be removed from
    the Dylan language.

This seems reasonable to me, too.  But again, things like this
should be standardized in parallel with the language.

I think one reason we couldn't agree on subsets in ANSI
is that we were going about it backwards:  Standardize
on everything, and then remove stuff.  I think standardizing
on a core as language, and separatly standanrdizing a set of
fairly independent additional modules, is a lot more likely
to succeed.  Plus you don't have to finish them all at
exactly the same time; you can point to the core, when
it's standardized, as a concrete standard.  And you don't
have this atificial deadline of "No, the language is
frozen", when you want to add something, so long as it
doesn't require changes to the core.

    Perhaps you and I are actually in agreement there; my reasoning is
    that if one isn't going to do a serious implementation of
    floating-point, one shouldn't do a half-baked job, instead one should
    not even claim to try.

I'm not sure I agree with this.  If you mean that you
shouldn't produce implementations with unknown or excessive
error bounds, weird incontinuities, unspecified branch cuts,
and other gotchas, then I agree.  It's better to let the
user up front know he would be  wasting his time, instead
of sucking him in.

But if you mean that it's not worth doing an implementation
that's not fully as efficient as it could be, but is otherwise
well behaved, then I don't think I agree.

From ranson@LANNION.cnet.fr Tue Oct  6 02:48:34 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18395; Tue, 6 Oct 92 02:48:34 -0400
Received: from pamir.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17361; Tue, 6 Oct 92 02:55:59 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 06 Oct 92 07:52:45+0100
X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
	Relayed; 06 Oct 92 07:53:00 GMT
Date: 06 Oct 92 07:53:00 GMT
From: Ranson <ranson@LANNION.cnet.fr>
Message-Id: <m0mc8my-00000sC(a)lamd01>
To: info-dylan@cambridge.apple.com
Subject: Dylan syntax forms
Cc: ranson@lannion.cnet.fr

Is the CAR of a special/macro form evaluated? The manual does not specifies
this. For instance, is this legal?

(define f define)
(f x 2)

My guess is that the answer is no, because the rules on function calls do not
require the function to be evaluated before the arguments. Hence one should be
able to decide if (f x 2) is a syntax form or a function call without any
evaluation.
Is that right? Maybe it should be more explicit.
     Daniel.


From ranson@LANNION.cnet.fr Tue Oct  6 02:50:22 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18447; Tue, 6 Oct 92 02:50:22 -0400
Received: from pamir.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17379; Tue, 6 Oct 92 02:57:43 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 06 Oct 92 07:54:32+0100
X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
	Relayed; 06 Oct 92 07:54:00 GMT
Date: 06 Oct 92 07:54:00 GMT
From: Ranson <ranson@LANNION.cnet.fr>
Message-Id: <m0mc8og-00000dC(a)lamd01>
To: info-dylan@cambridge.apple.com
Subject: Dylan macros
Cc: ranson@lannion.cnet.fr

I don't have access to the documents mentionned a few days ago about mmacros.
COuld we have a few examples here of what these macros will look like?
     Daniel.


From alms@cambridge.apple.com Tue Oct  6 11:09:37 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01165; Tue, 6 Oct 92 11:09:37 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210061509.AA01165@cambridge.apple.com>
Date: Tue, 6 Oct 1992 11:18:57 -0500
To: info-dylan@cambridge.apple.com, Ranson <ranson@LANNION.cnet.fr>
From: alms@cambridge.apple.com
Subject: Re: Dylan syntax forms
Cc: ranson@lannion.cnet.fr

At  7:53 AM 10/6/92 +0000, Ranson wrote:
>
>Is the CAR of a special/macro form evaluated? The manual does not specifies
>this. For instance, is this legal?
>
>(define f define)
>(f x 2)
>
>My guess is that the answer is no, because the rules on function calls do not
>require the function to be evaluated before the arguments. Hence one should be
>able to decide if (f x 2) is a syntax form or a function call without any
>evaluation.
>Is that right? Maybe it should be more explicit.

This will be clarified as part of the macro system.  Offhand, I don't remember
exactly what approach we took.

  -Andrew


From bachrach@miles.ircam.fr Tue Oct  6 14:39:36 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05565; Tue, 6 Oct 92 14:39:36 -0400
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18694; Tue, 6 Oct 92 14:46:01 -0400
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Tue, 6 Oct 1992 19:42:21 +0100
Received: by miles.ircam.fr, Tue, 6 Oct 1992 19:42:18 +0100
Date: Tue, 6 Oct 1992 19:42:18 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210061842.AA00669@miles.ircam.fr>
To: moon@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: David A. Moon's message of Mon, 05 Oct 92 16:42:21 EDT <9210052037.AA06015@cambridge.apple.com>
Subject: number crunching

   According to moon@cambridge.apple.com (David A. Moon) on Mon, 05 Oct 92 16:42:21 EDT

>   I don't think anyone has proposed Dylan as a scientific programming language. 

There are a whole lot of applications that Apple works with that could
very much benefit from good floating-point performance.  Consider
hand-writing recognition (or speech recognition).  This seems to me to
be a crucial technology for Newton and future generations of Apple
computers.  Many of these algorithms use floating-point.  One
possibility is to use a fix-point representation, but it turns out
that for modern RISC processors, floating-point performance is often
better than fix-point performance.  One possibility is to call out to
C for these routines.  This is incredibly unappealing to me.  Like you
said, number crunching applications could benefit from the same
advantages that OODL's offer system's programmers.  It seems to me
that it is worth the effort to figure out how to make floating-point
performance good in Dylan.

>   One lower-level comment about your message: you need to be more clear on the 
>   distinction between the language and a particular implementation of the 
>   language.  You are assuming that the language is implemented a certain way and 
>   then criticizing the language on that basis.  But how can you be sure that 
>   that is the only way the language will be implemented?  Better either to 
>   criticize one particular implementation or to argue that the language as it 
>   stands cannot be implemented any other way and see if everyone buys that 
>   argument.

Please excuse any perceived confusion between implementation and
architecture.  In all fairness, it does appear that there are problems
with the efficiency of Dylan regardless of implementation.  

As far as floating-point goes, the only available Dylan floating-point
formats are the IEEE formats.  Given these formats there is no extra
room for a tag bit unless one's implementing this on a machine with
extra tag bits (which is assumed to not be feasible for almost all
implementations).  Alas, one is forced to implement <float>'s as
`boxed' entities (i.e., allocated on the heap) at least for <vector>'s
for example, because all objects in Dylan must be identifiable, either
by tag or object pointer (and there are no <float-vector>'s).  I
merely voice a need for one more format -- <short-float>, which in an
implementation could be the same as <single-float> (like in CL).

As far as parameterized classes go, the amount of dispatching is
crucial to performance.  The need for parameterized classes is in no
way limited to number crunching applications.  I happened to choose
this example.  It's a general technique for eliminating run-time
dispatching by introducing more type information and trading off code
size for execution speed.  Maybe there is a way to get parameterized
classes through the magic of macros.  It certainly wouldn't be as
integrated as parameterized classes in Sather, where classes are
automatically generated on demand at compile-time when referenced
(i.e., when a variable is declared with an instantiation of the
parameterized class).

-- jonathan

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


From zilla@ccrl.nj.nec.com Tue Oct  6 18:56:13 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09941; Tue, 6 Oct 92 18:56:13 -0400
Received: from research.nj.nec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19426; Tue, 6 Oct 92 19:03:42 -0400
	for info-dylan@cambridge.apple.com
Received: by research.nj.nec.com (4.0/YDL1.8-920115.13)
	id AA09113(research.nj.nec.com); Tue, 6 Oct 92 19:00:24 EDT
Received: by overdrive.ccrl.NJ.NEC.COM (4.1/EMS1.6-920330.08)
	id AA06193(overdrive.ccrl.NJ.NEC.COM); Tue, 6 Oct 92 19:00:25 EDT
Date: Tue, 6 Oct 92 19:00:25 EDT
From: zilla@ccrl.nj.nec.com	(John Lewis)
Message-Id: <9210062300.AA06193@overdrive.ccrl.NJ.NEC.COM>
To: info-dylan@cambridge.apple.com
Subject: dylan scientific/multimedia

> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> There are a whole lot of applications that Apple works with that could
> very much benefit from good floating-point performance.  Consider

> ... that for modern RISC processors, floating-point performance is often
> better than fix-point performance.  One possibility is to call out to

I agree with these comments!  Multimedia in particular is an
application area of interest to Apple developers, and which is
similar to scientific programming-- the 'back end' operations
on data types such as sound and video resemble scientific code
in being highly vectorizable.

I was recently surprised to find that on both Sparc2 and SGI/mips r3000 
machines, a floating point algorithm was (slightly) faster than 
the same algorithm converted to fixed point.

I very much hope that some attention is paid to providing for efficient
numerics in Dylan.  This might take various forms--
Are there currently any Lisp implementations which do floating point
very efficiently?  I don't know of any, so I'm not expecting this
from Dylan either, but it would be nice.

A more primitive approach to efficient vectorizable code is 
'APL in lisp', i.e., code a set of APL-like vector primitives
in C and then either overload particular Lisp/dylan arithmetic
operators, or provide a mini-compiler from standard serial expressions
onto the vector operators.  The latter approach is used in some
extensions to elk scheme which will be part of Elk2.0 in a month or two.

Most minimally, efficient numerics would be possible if there
were an efficient C foreign function interface.  Personally I don't
mind writing some inner loops in C.

I wish:
- That Dylan would have a recommended standard foreign function interface,
  even if it is minimal or high level.
  Developing the FF glue for a large library can be a lot of work;
  one would like this work to be portable.  

- That Dylan provide for homogeneous arrays of short floats and ints.
  If not, vectorized coding can still be done by allocating foreign storage
  on the heap and manipulating this with the C-coded vector ops.
  Someone borrowed my Dylan manual, so i don't know if this is possible.

From ses@sunsite.unc.edu Tue Oct  6 20:37:50 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11865; Tue, 6 Oct 92 20:37:50 -0400
Received: from SunSite.unc.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19574; Tue, 6 Oct 92 20:45:16 -0400
	for info-dylan@cambridge.apple.com
Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88)
	id AA06973; Tue, 6 Oct 92 20:41:09 EDT
Message-Id: <9210070041.AA06973@SunSite.unc.edu>
To: zilla@ccrl.nj.nec.com (John Lewis)
Cc: info-dylan@cambridge.apple.com
Subject: Re: dylan scientific/multimedia 
In-Reply-To: Your message of "Tue, 06 Oct 92 19:00:25 EDT."
             <9210062300.AA06193@overdrive.ccrl.NJ.NEC.COM> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 06 Oct 92 20:41:08 -0400
From: Simon Spero <ses@sunsite.unc.edu>

[meta-note: I only just got added to the lists, so I'm still not 100% 
 up to speed- are the archives  available for WAIS/FTP anywhere?]

   zilla@ccrl.nj.nec.com (John Lewis) writes:
>
>Are there currently any Lisp implementations which do floating point
>very efficiently?  I don't know of any, so I'm not expecting this
>from Dylan either, but it would be nice.

If there's sufficient type information available at compile-time, lisp
is as fast as fortran. It's only when the types are unknown and you have to
dispatch at run-time that things really start to slow down. 

>- That Dylan provide for homogeneous arrays of short floats and ints.
>  If not, vectorized coding can still be done by allocating foreign storage
>  on the heap and manipulating this with the C-coded vector ops.
>  Someone borrowed my Dylan manual, so i don't know if this is possible.

Unboxed vectors would be a big win for small datatypes. At the moment the
only types for which this has been defined are char and unicode-char; a new
subclass of vector which only allowed objects from a single class to be stored
in it would be a big win.

Incidentally, whilst we're on the subject of types; unless I'm missing
something, Dylan doesn't seem to have an equivalent to Common Lisp's
'the'; I guess this can be simulated by having a macro wrap a bind around the
expression, but it'd be nice to have something semi-standard. 

Simon

From rwk@crl.dec.com Tue Oct  6 21:18:52 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12878; Tue, 6 Oct 92 21:18:52 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19639; Tue, 6 Oct 92 21:26:22 -0400
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA29283; Tue, 6 Oct 92 21:22:57 -0400
Received: by easynet.crl.dec.com; id AA23121; Tue, 6 Oct 92 21:22:53 -0400
Message-Id: <9210070122.AA01616@taunton.crl.dec.com>
To: Simon Spero <ses@sunsite.unc.edu>
Cc: zilla@ccrl.nj.nec.com (John Lewis), info-dylan@cambridge.apple.com
Subject: Re: dylan scientific/multimedia 
In-Reply-To: Your message of "Tue, 06 Oct 92 20:41:08 EDT."             <9210070041.AA06973@SunSite.unc.edu> 
Date: Tue, 06 Oct 92 21:22:52 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Tue, 06 Oct 92 20:41:08 -0400
    From: Simon Spero <ses@sunsite.unc.edu>
    Unboxed vectors would be a big win for small datatypes. At the moment the
    only types for which this has been defined are char and unicode-char; a new
    subclass of vector which only allowed objects from a single class to be stored
    in it would be a big win.
    
They'd only be a win for classes which can be enumerated in a small
number of bits.  (Where small is less than or sometimes equal to
the size of a pointer).

A class of vector which can be parametized as to how many bits
are stored per entry, and to which you could add methods for
type coercion to/from a small positive integer to store, would
be good.  There would also be methods for un-coerced access, for
the inner loops of routines, etc.

If some amount of type info is stored in pointers, and you want to
encode something in pointer-size number of bits, you'll need to go to
subprimitive-level unboxed access methods, being suitably careful of
the GC.  This sort of painful thing would be useful in the guts of the
FFI, and for doing 32-bit graphics on 32-bit machines.  (This is
the same issue as unboxed floating-point, in different guise.)

Although ugly, I think this is an important issue.  So long as people
make machines where the word size is as small as the pointer size
is large, good FFI is going to require this sort of thing.  Making
it easy and efficient will go a long way toward acceptance by
C programmers.

From bachrach@miles.ircam.fr Wed Oct  7 11:24:41 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07721; Wed, 7 Oct 92 11:24:41 -0400
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20643; Wed, 7 Oct 92 11:32:02 -0400
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Wed, 7 Oct 1992 16:28:32 +0100
Received: by miles.ircam.fr, Wed, 7 Oct 1992 16:28:30 +0100
Date: Wed, 7 Oct 1992 16:28:30 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210071528.AA00643@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
In-Reply-To: Simon Spero's message of Tue, 06 Oct 92 20:41:08 -0400 <9210070041.AA06973@SunSite.unc.edu>
Subject: RE: dylan scientific/multimedia 

Thank you for all the responses in favor of addressing the numeric
processing needs.  Future technologies demand high performance numeric
processing and it would be short-sighted to not think carefully about
what is needed to get the high-performance demanded of these
applications (e.g., multi-media).  

I truly think it is a mistake to just fall back on a FFI (C) for one's
numeric processing needs.  This is gross and forces THOSE developers
to lose all the advantages of an OODL, the advantages that are so well
articulated in the introduction to the Dylan book.  It definitely
warrants some deep thoughts about how to adapt Dylan for these needs.
I am convinced that Dylan can meet the needs of these users without
major changes: changes that I think would also benefit other users of
Dylan. 

   Date: Tue, 06 Oct 92 20:41:08 -0400
   From: Simon Spero <ses@sunsite.unc.edu>

   [meta-note: I only just got added to the lists, so I'm still not 100% 
    up to speed- are the archives  available for WAIS/FTP anywhere?]

      zilla@ccrl.nj.nec.com (John Lewis) writes:
   >
   >Are there currently any Lisp implementations which do floating point
   >very efficiently?  I don't know of any, so I'm not expecting this
   >from Dylan either, but it would be nice.

   If there's sufficient type information available at compile-time, lisp
   is as fast as fortran. It's only when the types are unknown and you have to
   dispatch at run-time that things really start to slow down. 

This is exactly the point that I've been trying to make in my series
of messages: Dylan needs to go all the way with its type system.  This
is the point of introducing types for key-values, rest args, define's,
and for introducing parameterized classes.  Without the type
information, Dylan is doomed to be slower (e.g., dispatch and cons).
(One way to avoid this overhead would be to use a radical compiler
technique (dynamic compilation) as done in SELF, but I still think
that the resulting code will be slower than Fortran).

   >- That Dylan provide for homogeneous arrays of short floats and ints.
   >  If not, vectorized coding can still be done by allocating foreign storage
   >  on the heap and manipulating this with the C-coded vector ops.
   >  Someone borrowed my Dylan manual, so i don't know if this is possible.

   Unboxed vectors would be a big win for small datatypes. At the moment the
   only types for which this has been defined are char and unicode-char; a new
   subclass of vector which only allowed objects from a single class to be stored
   in it would be a big win.

Parameterized vectors would serve this purpose.  Instead of having a
special vector type for all basic objects, one could have a
parameterized class.  The syntax might be `(<vector> <char>)' for a
vector of characters, `(<vector> <int>)' for a vector of integers, and
`(<vector> <single-float>)' for a vector of floating point values.  I
could give more details...

   Incidentally, whilst we're on the subject of types; unless I'm missing
   something, Dylan doesn't seem to have an equivalent to Common Lisp's
   'the'; I guess this can be simulated by having a macro wrap a bind around the
   expression, but it'd be nice to have something semi-standard. 

If the type information were available then I don't think `the' would
be necessary.

-- jonathan

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


From hmadorf@eso.org Wed Oct  7 13:37:59 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10639; Wed, 7 Oct 92 13:37:59 -0400
Received: from ns3.hq.eso.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20962; Wed, 7 Oct 92 13:45:32 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210071741.AA10022@ns3.hq.eso.org>
Received: from localhost.hq.eso.org by ns3.hq.eso.org (4.1/ eso-1.1)
	id AA10022; Wed, 7 Oct 92 18:41:50 +0100
To: info-dylan@cambridge.apple.com
Subject: floating-point efficiency: Lisp vs. Fortran (FYI)
Date: Wed, 07 Oct 92 18:41:49 +0100
From: hmadorf@eso.org


I would like to second Jonathan Bacharach's view that floating point
efficiency *is* an important issue, at least for those of us out there
thinking about the future of scientific computing in the nineties.
I would like to base my future work on CL or Dylan or whatever
dialect is en vogue and write software that I can port unchanged
from a scalar processor to a vector processor to a massively
parallel processor. D'you think that's far fetched? No, it is not. 
In the era of mobile computing and low hardware cost (1MB of RAM is
cheaper than 2 lines of code) we will increasingly face the
software engineering/portability/maintenance problem.

Here is a cross-posting of a message I posted today on info-mcl. I
would pretty much like language designers to think hard about the
FP-issue. Is science unimportant since there are only so few 
scientists out there (compared to multi-meadia aficionados)?

===============================

Lisp's floating point efficiency
--------------------------------
Simon Spero writes:
>If there's sufficient type information available at compile-time, lisp
>is as fast as fortran. It's only when the types are unknown and you have to
>dispatch at run-time that things really start to slow down.

This does not at all agree with my recent observations. I carried
out the following simple floating-point benchmark: I coded the 
log-factorial function in Fortran-77 and in Lisp (using a simple 
do-loop). The algorithm simply sums up all the log-terms. (The code
is available on request.) I executed the code using

MacTran    & Mac SE/30
MCL        & Mac SE/30
f77	   & Sun Sparc2
Allegro CL & Sun Sparc2

Two versions of the CL code were tested, one without declarations,
the other fully spiced with declarations. The CL-code was compiled
with (speed 3) optimization. The Fortran code was not particularly
optimized. My observations:

1. Declarations had little influence on CL-execution efficiency.
2. The availability of the FP-coprocessor in the SE/30 (as opposed
   to the SE) made a big difference.
3. The Fortran code ran consistently 5 times faster on both hardware
   platforms.
4. The Sparc2 with Allegro CL was about as fast as the SE/30 with
   MacTran.

The most striking thing is the consistency across the compilers and
hardware platforms, almost ruling out any trivial explanation
(such as "the log function is particularly inefficiently implemented
in MCL" or things alike).

I am quite prepared to carry the comparison further, but (despite
the fact that I love Lisp and do all work possible in it) my 
conclusion for the moment is: I cannot recommend Lisp for number
crunching when a simple algorithm is executed for utmost speed.

I recently brought up the Lisp vs. Fortran efficiency issue on the 
info-mcl network. Someone called the comparison foolish, but I do not
think it is. In any case I have not received code or immediate hints that
would invalidate my conclusions above. (I still have to check out 
the optimization document in the /contrib directory in the Apple 
archive.)

Two wishes:

1. I would like to see others report their experience on
FP-efficiency in order to see whether a consensus emerges.

2. I would also like to have the MCL developers pay attention to the
"floating point efficiency issue" as *the* selling/repelling argument 
for many scientists. Advocating all the other nice features (we all
appreciate) that Lisp possesses will not make them turn away from their
beloved, primitive, but veeeeeery fast Fortran, I'm afraid. 


Lisp for scientific computing
-----------------------------
I am delighted about the discussion on Lisp for scientific
computation (which is almost invariably taken to be numeric). Right
now the discussion centres on whether Dylan should incorporate
enough to make it an interesting language to those engaged in 
scientific computing (as I am).

I am currently trying to influence the attitude of my colleagues 
(working mainly in astronomy), and make them aware of the advantages 
of Lisp vs. Fortran or even C, but I need convincing arguments not
strong convictions!

One argument that I have in my pockets is that Lisp is easy to
vectorize. (I have vectorized the whole Lisp language with a few 
macros and the help of CLOS.) The four fundamental arithmetic 
oprators +, -, * and / and all single argument functions operate on 
scalars, lists, vectors and arrays and even on some mixtures of these.
(Is that what some guys call "threading"?)

I am planning to interface this nice language to the Intel i860
vector processor in the backplane of my Sun in order to get the
FP-performance that I cannot squeeze out of Lisp otherwise. (I have
a statistical classifier that is supposed to operate on large data 
sets and that is an ideal algorithm for this kind of vectorization.)

If anyone is interested in the topics above, please contact me in
order to foster exchange of views and experience.

Hans-Martin Adorf

ST Data Analysis Scientist
Space Telescope - European Coordinating Facility
European Southern Observatory
Garching bei Muenchen, FRG

Internet: adorf@eso.org
------- End of Forwarded Message


From Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU Wed Oct  7 16:10:18 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13185; Wed, 7 Oct 92 16:10:18 -0400
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21256; Wed, 7 Oct 92 16:17:53 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210072017.AA21256@brazil.cambridge.apple.com>
Received: from lisp-pmax1.slisp.cs.cmu.edu by LISP-PMAX1.SLISP.CS.CMU.EDU
          id aa07837; 7 Oct 92 16:14:24 EDT
To: John Lewis <zilla@CCRL.NJ.NEC.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: dylan scientific/multimedia 
In-Reply-To: Your message of Tue, 06 Oct 92 19:00:25 -0500.
             <9210062300.AA06193@overdrive.ccrl.NJ.NEC.COM> 
Date: Wed, 07 Oct 92 16:14:15 -0400
From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU


We are planning to develop a highly optimized Dylan implementation at CMU.
Our experience with CMU Common Lisp have give us a pretty good idea of the
problems of efficient numeric coding in Lisp-like type systems.  We are
planning to develop a Dylan implementation with strong emphasis on the
run-time speed of delivered applications.

By far the biggest performance problem is with floating point
representation.  When a float must be tagged, significant memory access and
memory allocation overheads are incurred.

Use of a tagged (32bit - tag) float representation (SHORT-FLOAT) avoids the
memory allocation overheads, but supporting a float format in software
tends to have unpleasant numeric and/or efficiency implications.  Much
serious numeric work requires 64bit floats anyway.

Given a compiler technology that supports the natural (untagged) float
representation, it is generally possible to come close to the performance
(2x or better) of C (or presumably FORTRAN) on RISC processors.  Getting
this close often requires various unnatural steps:
 -- A great deal of attention to program organization and compiler
    diagnostics to ensure that good numeric representations are used.
 -- Hand optimization of multi-dimensional array access loops.
 -- Use of non-portable high-performance binary I/O facilities.

What would be necessary in Dylan to get as good numeric performance as is
available in some Common Lisp implementations?
 -- Specialized array element types are definitely necessary.
 -- Type declarations for module (global) variables would be very useful.
    This is really only necessary for mutable variables.
 -- There also needs to be either a predefined class variable for each
    specialized array element type, or a general class generator which
    produces the specialized class when presented with an element type.
    These classes would be used in slot and variable type declarations.
 -- As long as SET! is basically never used on local variables, it will
    *not* be necessary to allow the type of local variable contents to be
    declared.  This implies that iterations will always be written using
    BIND-METHODS or equivalent forms of recursion.  (Note that the types in
    BIND and method specializers only specify the type of the initial value.)
 -- Efficient small-integer (i.e. array index) arithmetic must be possible.
    The difficulty of proving that small-integer arithmetic doesn't result
    in overlow is one of the major causes of inefficency in Common Lisp
    programs (even non-numeric ones.)

Dynamic method dispatch definitely causes problems for efficient
representation of arguments and return values.  It may only be possible to
do efficient float argument passing once a generic function has been
sealed.

Overall, it seems that Dylan is fundamentally any worse than Common Lisp
for numeric efficiency.  Good numeric performance will require the
availability of some new array and number classes.  These can probably be
regarded as an additional library layer.  (Though I am doubtful of the
usefulness of untyped multi-dimensional arrays.  I guess arrays are
technically part of the level-1 library anyway.)

There are some fundamental problems which Dylan shares with Lisp relating
to run-time checking of function applicability and run-time function/method
redefinition.  However, Dylan's sealing capabilities provide a way to
indicate when this dynamisim is no longer necessary, allowing efficient
compilation.  Common Lisp implementations can offer "block compilation" as
an extension, but the language is defined to be dynamic.  I think it is
much better to generally discourage or forbid run-time function
redefinition, but to allow that the program development environment will
have a way to efficiently support redefinition (at the cost of run-time
speed.)

  Rob

From Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU Wed Oct  7 17:53:53 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14857; Wed, 7 Oct 92 17:53:53 -0400
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21644; Wed, 7 Oct 92 18:01:29 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210072201.AA21644@brazil.cambridge.apple.com>
Received: from lisp-pmax1.slisp.cs.cmu.edu by LISP-PMAX1.SLISP.CS.CMU.EDU
          id aa07911; 7 Oct 92 17:57:40 EDT
To: info-dylan@CAMBRIDGE.APPLE.COM
Subject: small integers
Date: Wed, 07 Oct 92 17:57:37 -0400
From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU


It isn't really clear from the book, but the Dylan <integer> class
evidently supports extended-precision arithmetic.  Since small integers are
ubiquitous, good small-integer preformance is crucial for all manner of
applications.  There must be some way of informing the compiler that
arimthmetic operands are small integers and that the result will be a small
integer.

Suppose <integer> has a subclass <small-integer>.  We could then use this
type to declare arithmetic operands:
    (bind (((x <small-integer>) stuff)
	   ((y <small-integer>) more-stuff))
      (+ x y))

This helps the compiler somewhat, but leaves open the possibility of
integer overflow.  What happens when <small-integer> arithmetic overflows?
In most Lisp implementations (such as Common Lisp), the answer is that a
non-small integer results.  Declarations are necessary on each intermediate
result, so (x+y)*3 becomes:
    (bind (((x <small-integer>) stuff)
	   ((y <small-integer>) more-stuff)
	   ((t1 <small-integer>) (+ x y))
	   ((t2 <small-integer>) (* t1 3)))
      t2)

This sort of stuff certainly makes C & FORTRAN look like higher-level
languages than Lisp.  I am proposing a set of related changes, divided into
two proposals.

    Rob MacLachlan (ram@cs.cmu.edu)

________________________________________________________________
Small/extended integer proposal:

There shall be two disjoint subclasses of <integer>:
    <small-integer>
    <extended-integer>

The result of <small-integer> OP <small-integer> is always a
<small-integer>.  If over or underflow results, then an error should be
signalled.  <extended-integer>s are more "contagious" than
<small-integer>s.  

The result of <small-integer> OP <extended-integer> is always
<extended-integer>.  Over/underflow results in a quiet transition to
extended precision arithmetic.

Numeric operations on non-integers with integer results
(truncate,floor,ceiling,round,/-variants,numerator,denominator, probably
real-part, imag-part) always return <extended-integer>s.

Note that a <small-integer> and an <extended-integer> may have the same
numeric value (such as 5).  In such a case, the class distinction serves to
control the over/underflow behavior.  AS may be used to convert between
integer classes:
    (as <small-integer> some-integer) 
    (as <extended-integer> some-integer) 

Advantages of this proposal:
 -- The <small-integer> type allows the use of efficient hardware-supported
    arithmetic without first checking argument types.
 -- Considering <small-integer> overflow to be an exception allows more
    compact and efficient overflow handling to be compiled.  Delivered
    applications might omit overflow checking entirely.
 -- Considering <small-integer> overflow to be an exception allows complex
    (nested) integer arithmetic expressions to be written much more
    more naturally, since type assertions are not needed on intermediate
    results.
 -- Extended integer support as been pulled out into a separate class which
    one could consider to be an optional library.

Disadvantages of this proposal:
 -- Two more classes.
 -- Conceptual complexity in understanding the distinction between the two
    classes.
 -- Using the class to encode the extensibility attribute may be sort of a
    bad pun, since it seems to clash somewhat with the normal conception of
    subtype relations on integer types.  This is because the conflicting
    demands of inheritance and subtypeness.

________________________________________________________________

Small integer integration proposal:

 -- Sequence keys, array indices and collection sizes are implicitly
    coerced to <small-integer>.  If an <extended-integer> argument is too
    large to be a <small-integer>, then an error should be signalled.
 -- Any integer literal which can be represented as <small-integer> is
    small.

Paraphrase:
    <small-integer> is the default integer class.  The obvious coding of
    integer algorithms do not automatically extend into bignums.  You would
    write extended FACTORIAL like this:
        (define factorial
	  (method (n)
	    (if (= n 0)
		(as <extended-integer> 1)
		(* n (factorial (- n 1))))))

    small-integer factorial could be written:
        (define small-factorial
	  (method ((n <small-integer>))
	    (if (= n 0)
		1
		(* n (small-factorial (- n 1))))))
    [efficient compilation would require recursive type inference or a way
    to declare the type of the recursive call or of all calls to
    small-factorial.]

Advantages of this proposal:
 -- Small integer arithmetic is the default, so efficient proramming comes
    more naturally.

Disadvantages of this proposal:
 -- Small integer arithmetic is the default, so extended integer use
    require awareness additional code and awareness of the distinction
    between small and extended integers.
________________________________________________________________

From frink@fsu.fsufay.edu Wed Oct  7 23:43:50 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21118; Wed, 7 Oct 92 23:43:50 -0400
Received: from fsu.fsufay.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00329; Wed, 7 Oct 92 23:51:25 -0400
	for info-dylan@cambridge.apple.com
Received: by fsu.fsufay.edu (5.61/1.35)
	id AA28822; Wed, 7 Oct 92 23:52:56 -0400
Date: Wed, 7 Oct 92 23:52:56 -0400
From: frink@fsu.fsufay.edu (Mr. George Frink)
Message-Id: <9210080352.AA28822@fsu.fsufay.edu>
To: info-dylan@cambridge.apple.com
Subject: REQUIRED FILES for GAMBIT implementation of THOMAS

	I've been downloading Thomas scheme code by anonymous FTP but am
confused about exactly what I need to run the Gambit implementation. Please
advice me.
	Thank you.
	frink@fsu.fsufay.edu

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Thu Oct  8 03:05:33 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27350; Thu, 8 Oct 92 03:05:33 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00591; Thu, 8 Oct 92 03:13:10 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210080713.AA00591@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa00721; 8 Oct 92 3:09:08 EDT
To: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Wed, 07 Oct 92 17:57:37 -0500.
             <9210072201.AA21644@brazil.cambridge.apple.com> 
Date: Thu, 08 Oct 92 03:09:06 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


I generally like Rob Maclachlan's proposal for small and extended integer
types.  (Not surprising, perhaps, since Rob and I have discussed these
issues before.)

The Common Lisp decision to create a single integer type, with automatic
rollover into bignums as needed, is conceptually very elegant, but I've
gradually, relucantly, come around to the conclusion that it was a mistake
for real programming on real machines.  Assuming that the short-integers
(or fixnums, in CL parlance) are of reasonable size -- 28 bits or more is
typical -- bignums are rarely used, but having them available at all times
is expensive.  The bignum code significantly increases the size of the
runtime system, and if you want fixnum arithmetic to compile efficiently
inline you have to put "fixnum" type-declarations *everywhere*.  I wish I
had a dollar for every (the fixnum ...) form I've written (or that a macro
has written for me) in the past five years.

Under Rob's proposal, small-integer arithmetic would once again be easy and
efficient, and the extended-integer stuff could be an optional facility.
Some very small implementations of Dylan could decline to support extended
numbers at all, and others could load the extended arithmetic code only
when it is used.  Ratios (which often cross over into bignums) could be
supported as yet another optional facility.

I have two quibbles with Rob's proposal:

    Numeric operations on non-integers with integer results
    (truncate,floor,ceiling,round,/-variants,numerator,denominator, probably
    real-part, imag-part) always return <extended-integer>s.

This seems like the wrong default to me if we don't want extended-integers
to be sneaking in the back door all the time.

Second, I think users may find it very confusing to have an
extended-integer 5 and a short-integer 5 that print the same, and it is
awkward not to be able to type in the extended integers.  I think that the
extended integers need to be decorated in some way so that they are
visually different from short integers.  One possibility would be to use a
training decimal point to indicate an extended integer: 5. would be
extended, while 5 is a short-integer.  Alternatively, some # code might be
used.  I'm not sure if any existing language makes this same distinction
and has come up with a better convention.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From sohn@goofy.apple.com Thu Oct  8 11:15:13 1992
Received: from goofy.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21007; Thu, 8 Oct 92 11:15:13 -0400
Received: by goofy.apple.com (5.61/27-Sep-1991-eef)
	id AA00684; Thu, 8 Oct 92 08:19:34 -0700
	for info-dylan@cambridge.apple.com
Date: Thu, 8 Oct 92 08:19:34 -0700
From: a phil sohn <sohn@goofy.apple.com>
Message-Id: <9210081519.AA00684@internal.apple.com>
To: frink@fsu.fsufay.edu, info-dylan@cambridge.apple.com
In-Reply-To: Mr. George Frink's message of Wed, 7 Oct 92 23:52:56 -0400 <9210080352.AA28822@fsu.fsufay.edu>
Subject: REQUIRED FILES for GAMBIT implementation of THOMAS


	You at least need the Gambit Interpreter. The best place to
get this is from walnut.cs.brandeis.edu. (Marc Feeley said that they
are having problems with the ftp server that is recommended in the
Thomas readme file.) It is in the pub/gambit directory. You need the
gambit1.9-interp.sea.hqx file if you are trying to run Thomas on a Mac.

phil sohn

From moon Thu Oct  8 12:09:35 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22543; Thu, 8 Oct 92 12:09:35 -0400
Full-Name: David Moon
Message-Id: <9210081609.AA22543@cambridge.apple.com>
Date: Thu, 08 Oct 92 12:14:24 EDT
From: moon (David A. Moon)
To: hmadorf@eso.org
Subject: Re: floating-point efficiency: Lisp vs. Fortran
Cc: Simon Spero <ses@sunsite.unc.edu>, info-mcl@cambridge.apple.com,
        info-dylan

> Date: Wed, 07 Oct 92 07:30:35 +0100
> From: hmadorf@eso.org
> ....
> Two versions of the CL code were tested, one without declarations,
> the other fully spiced with declarations. The CL-code was compiled
> with (speed 3) optimization. The Fortran code was not particularly
> optimized. My observations:
> 
> 1. Declarations had little influence on CL-execution efficiency.
> .... (I still have to check out 
> the optimization document in the /contrib directory in the Apple 
> archive.)

This is a digression, however I'll mention it anyway.
It helps if you put in correct declarations.  Unfortunately the MCL
compiler does not warn you if you put in declarations that don't make
any difference.  If I remember your code, one problem was that you
said integer where you should have said fixnum; a common pitfall in
Common Lisp declarations.  I think some other Common Lisp compilers
will tell you whether your declarations are working, which I think
is a good idea.

From moon Thu Oct  8 13:52:54 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24044; Thu, 8 Oct 92 13:52:54 -0400
Full-Name: David Moon
Message-Id: <9210081752.AA24044@cambridge.apple.com>
Date: Thu, 08 Oct 92 13:57:43 EDT
From: moon (David A. Moon)
To: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
Subject: Re: small integers
Cc: info-dylan@CAMBRIDGE.APPLE.COM

> Date: Wed, 07 Oct 92 17:57:37 -0400
> From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
> 
> It isn't really clear from the book, but the Dylan <integer> class
> evidently supports extended-precision arithmetic.  Since small integers are
> ubiquitous, good small-integer preformance is crucial for all manner of
> applications.  There must be some way of informing the compiler that
> arimthmetic operands are small integers and that the result will be a small
> integer.

Agreed.

Actually our implementations already have a class named <small-integer> which 
behaves the same as Common Lisp fixnum.  I guess you would say that when we 
argued about whether this class ought to be included in the book, the wrong 
faction won, because writing portable efficient code requires mentioning the 
class <small-integer> from time to time.

> ....
> Small/extended integer proposal:
> 
> There shall be two disjoint subclasses of <integer>:
>     <small-integer>
>     <extended-integer>
> ....
> Note that a <small-integer> and an <extended-integer> may have the same
> numeric value (such as 5).  In such a case, the class distinction serves to
> control the over/underflow behavior.  AS may be used to convert between
> integer classes:
>     (as <small-integer> some-integer) 
>     (as <extended-integer> some-integer) 

This is only my initial reaction, but this strikes me as a really bad idea, 
because it violates the principle that correct programs should be easy to 
write and the burden of micro-optimization should be on programmers who need 
to do micro-optimization, not on all programmers.  It seems to me that you're 
making the language significantly more complicated and hard to understand, 
just to make compiler optimization a little easier.  The specific aspect I 
object to is having two non-id?, non-operationally-equivalent integers with 
the same mathematical value.

Can't we find a less semantically violent way to enable the desired compiler 
optimization?  Correct me if I'm wrong, you've thought a lot more about this 
kind of compiler optimization than I have, but it seems to me that what you 
are really aiming for is a way for the compiler to infer that the results of 
certain operations will lie within the <small-integer> subrange of <integer>, 
given information about the integer subrange of the arguments, supplied either 
by programmer annotation or by type inference.  Is it really necessary to give 
up any hope of being able to do such inference within the existing semantics 
of Dylan (possibly with addition of finer-grained type specifiers for integer 
subranges)?  If so, what is the evidence?

From sohn@goofy.apple.com Thu Oct  8 14:06:35 1992
Received: from goofy.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24329; Thu, 8 Oct 92 14:06:35 -0400
Received: by goofy.apple.com (5.61/27-Sep-1991-eef)
	id AA13155; Thu, 8 Oct 92 11:10:59 -0700
	for info-dylan@cambridge.apple.com
Date: Thu, 8 Oct 92 11:10:59 -0700
From: a phil sohn <sohn@goofy.apple.com>
Message-Id: <9210081810.AA13155@internal.apple.com>
To: kevin@scic.intel.com, info-dylan@cambridge.apple.com
In-Reply-To: Kevin Altis's message of Thu, 8 Oct 1992 10:35:27 -0800 <9210081734.AA00967@sv002.scic.intel.com>
Subject: REQUIRED FILES for GAMBIT implementation of THOMAS



	There are a couple of slight problems with running Thomas on a
Mac that I forgot about.

	The files runtime-collections-generic1.scm and
runtime-collections-generic2.scm have too long of filename. However,
if you rename these and edit the file runtime.scm to load your renamed
files, everything should load ok.

	There is also a problem with the default size of Gambit. You
should up the Application size as far as you can go. I have had
problems running with a 1.5 Meg partition. I suggest 4 Meg. If you
machine seems to hang during loading, you probably need to make the
partition bigger.

	There is a Gambit version 1.9 that was posted a few day ago,
you may want to use this. I could not find the differences other than
an online help system that does not seem to work. 

	If anyone has any problems, give me a hoot.

phil

From moofie@apple.com Thu Oct  8 15:55:40 1992
Received: from goofy.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26810; Thu, 8 Oct 92 15:55:40 -0400
Received: from apple.com by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef)
	id AA21900; Thu, 8 Oct 92 13:00:05 -0700
	for info-dylan@cambridge.apple.com
Received: from [90.190.20.73] by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA06809; Thu, 8 Oct 92 12:59:54 -0700
	for info-dylan@cambridge.apple.com
Message-Id: <9210081959.AA06809@apple.com>
Date: Thu, 8 Oct 1992 13:00:08 -0800
To: info-dylan@cambridge.apple.com
From: moofie@apple.com (Steve Klingsporn)
Subject: Add me?

Subscribe

Can you add me?  Thanks!

Steve Klingsporn
Collaborative Systems Development
Apple Computer, Inc.
---------------------------------------------------------------------------
Steve Klingsporn * Collaborative Systems Development * Apple Computer, Inc.

"There are moments you can reach with people that are pure bliss, but then
 you have to get it again, and it can turn into a futile exercise that can
 undermine your entire existence.  The quest for the perfect moment."

                                     - Robert Smith


From Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU Thu Oct  8 16:27:59 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27551; Thu, 8 Oct 92 16:27:59 -0400
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02290; Thu, 8 Oct 92 16:35:39 -0400
	for moon@cambridge.apple.com
Message-Id: <9210082035.AA02290@brazil.cambridge.apple.com>
Received: from lisp-pmax1.slisp.cs.cmu.edu by LISP-PMAX1.SLISP.CS.CMU.EDU
          id aa09628; 8 Oct 92 16:31:40 EDT
To: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Thu, 08 Oct 92 13:57:43 -0500.
             <9210081752.AA24044@cambridge.apple.com> 
Date: Thu, 08 Oct 92 16:31:36 -0400
From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU

    Date: Thu, 08 Oct 92 13:57:43 EDT
    From: "David A. Moon" <moon@cambridge.apple.com>
    To: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
    Subject: Re: small integers
    Cc: info-dylan@cambridge.apple.com
    
    > ....
    > Small/extended integer proposal:
    > 
    > There shall be two disjoint subclasses of <integer>:
    >     <small-integer>
    >     <extended-integer>
    > ....
    > Note that a <small-integer> and an <extended-integer> may have the same
    > numeric value (such as 5).  In such a case, the class distinction
    > serves to control the over/underflow behavior.  AS may be used to
    > convert between integer classes:
    >     (as <small-integer> some-integer) 
    >     (as <extended-integer> some-integer) 

    The specific aspect I object to is having two non-id?,
    non-operationally-equivalent integers with the same mathematical value.

Well, that does sound sort of bad.  But we already do have
non-operationally-equivalent *numbers* with the same mathematical value:
   (= 0.5 1/2)
   (= 2.0 2)

[b.t.w., I now agree with Scott that it is a bad idea to have extended and
small integers read/print the same way.  However, this is outside the scope
of the current language, since READ and PRINT are part of the unspecified
environment.]

The only reason that we support floats in addition to rationals is that
they are more efficient.  It is widely observed that novice programmers are
confused by distinction between integers and floats --- and they are even
more confused when they discover the difference between floats and real
numbers.

    [this] violates the principle that correct programs should be
    easy to write and the burden of micro-optimization should be on
    programmers who need to do micro-optimization, not on all programmers.

By the above argument, we should eliminate floats, and have 3.14 read as a
rational.  In fairness, you did in fact argue against having floats, but I
think that fractional numbers are a such an important and familiar
concept that they must be supported somehow.

    It seems to me that what you are really aiming for is a way for the
    compiler to infer that the results of certain operations will lie
    within the <small-integer> subrange of <integer>, given information
    about the integer subrange of the arguments[...].  Is it really
    necessary to give up any hope of being able to do such inference within
    the existing semantics of Dylan (possibly with addition of
    finer-grained type specifiers for integer subranges)?  If so, what is
    the evidence?

Given a way to specify integer subranges of arguments, it would be possible
to do as you say (and which CMU CL does.)  The problem is that this
requires the programmer to effectively encode a proof that overflow doesn't
happen.  Admittedly, programmers really ought to be thinking about the
possibility of overflow, but it is definitely harder to code a proof of
non-overflow than to just trust that it doesn't happen and fix it when it
does.

This argument is based on the belief that integers are used primarily as
array indices and loop counters.  Sometimes you really do want extended
integers (such as in rational arithmetic.)  But then the programmer really
knows that they want extended integers.  [b.t.w., this was the reason I
proposed that NUMERATOR, etc. would always return an <extended-integer>.]

    It seems to me that you're making the language significantly more
    complicated and hard to understand, just to make compiler optimization
    a little easier.  Can't we find a less semantically violent way to
    enable the desired compiler optimization?

I feel that I am wearing my "lisp programmer" hat when I advocate this, and
not my "compiler implementor" hat.  Python does the sort of
result-type-proving that you suggest; it isn't terribly hard to implement,
but, from a programmer's perspective, it just doesn't work all that well.

I also feel that the small/extended split is well precedented by C and other
general-purpose programming languages that Dylan hopes to compete with.  In
normal programming languages, extended arithmetic requires an extended
arithmetic library, and extended-5 /= 5.

Note that I deliberately made two proposals, one proposing the overflow
semantics of <small-integer> and the other proposing that <small-integer>
should be the default for literals, sequence lengths, etc.  Adopting the
first proposal and not the second would hide <small-integer> from novice
users, at the cost of requiring explicit coercions to small integers.  If
so, small <extended-integer>s would probably need a distinct immediate
representation to avoid spurious consing.

  Rob

From alms@cambridge.apple.com Thu Oct  8 18:39:37 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08178; Thu, 8 Oct 92 18:39:37 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210082239.AA08178@cambridge.apple.com>
Date: Thu, 8 Oct 1992 18:49:22 -0500
To: John Lewis <zilla@CCRL.NJ.NEC.COM>,
        Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: dylan scientific/multimedia
Cc: info-dylan@CAMBRIDGE.APPLE.COM

At  4:14 PM 10/7/92 -0400, Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU wrote:
>

>What would be necessary in Dylan to get as good numeric performance as is
>available in some Common Lisp implementations?
> -- Specialized array element types are definitely necessary.
> -- Type declarations for module (global) variables would be very useful.
>    This is really only necessary for mutable variables.
> -- There also needs to be either a predefined class variable for each
>    specialized array element type, or a general class generator which
>    produces the specialized class when presented with an element type.
>    These classes would be used in slot and variable type declarations.

We're considering all of these, as well as a system for declaring the
types of return values.


> -- As long as SET! is basically never used on local variables, it will
>    *not* be necessary to allow the type of local variable contents to be
>    declared.  This implies that iterations will always be written using
>    BIND-METHODS or equivalent forms of recursion.  (Note that the types in
>    BIND and method specializers only specify the type of the initial value.)

I think the types specified in BIND and METHOD specializers should also
restrict the subsequent values that can be stored in the variables.  This
would simplify the language and improve efficiency.


> -- Efficient small-integer (i.e. array index) arithmetic must be possible.
>    The difficulty of proving that small-integer arithmetic doesn't result
>    in overlow is one of the major causes of inefficency in Common Lisp
>    programs (even non-numeric ones.)

There are other messages on this, so I won't answer here.


>Overall, it seems that Dylan is fundamentally any worse than Common Lisp
>for numeric efficiency...

[Assuming the word 'not' is missing]

Dylan encourages programmers to include lots of type information.  It's
a very natural thing to do when writing Dylan programs.  In Common Lisp,
declarations have to be tacked on.  Many programmers just don't bother
with them.  To me, this places Dylan at a great advantage over Common Lisp.

  -Andrew


From alms@cambridge.apple.com Thu Oct  8 18:39:54 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08208; Thu, 8 Oct 92 18:39:54 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210082239.AA08208@cambridge.apple.com>
Date: Thu, 8 Oct 1992 18:49:41 -0500
To: info-dylan@cambridge.apple.com, hmadorf@eso.org
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: floating-point efficiency: Lisp vs. Fortran (FYI)

At  6:41 PM 10/7/92 +0100, hmadorf@eso.org wrote:
>
>Lisp for scientific computing
>-----------------------------
>I am delighted about the discussion on Lisp for scientific
>computation (which is almost invariably taken to be numeric). Right
>now the discussion centres on whether Dylan should incorporate
>enough to make it an interesting language to those engaged in 
>scientific computing (as I am).
>
>I am currently trying to influence the attitude of my colleagues 
>(working mainly in astronomy), and make them aware of the advantages 
>of Lisp vs. Fortran or even C, but I need convincing arguments not
>strong convictions!

I think the best argument for the use of an OODL in scientific
computing is that it gives you an interactive environment for
modeling your problem domain.  Once you've created OODL objects
which correspond to your real-world objects, you can do anything
you want with them, very quickly.  You can easily build additional
tools for manipulating the objects, you can easily show different
views of the object, etc.

This is hard to describe, but it's very noticeable when you use
an OODL.

  -Andrew


From alms@cambridge.apple.com Thu Oct  8 19:00:08 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08208; Thu, 8 Oct 92 18:39:54 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210082239.AA08208@cambridge.apple.com>
Date: Thu, 8 Oct 1992 18:49:41 -0500
To: info-dylan@cambridge.apple.com, hmadorf@eso.org
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: floating-point efficiency: Lisp vs. Fortran (FYI)

At  6:41 PM 10/7/92 +0100, hmadorf@eso.org wrote:
>
>Lisp for scientific computing
>-----------------------------
>I am delighted about the discussion on Lisp for scientific
>computation (which is almost invariably taken to be numeric). Right
>now the discussion centres on whether Dylan should incorporate
>enough to make it an interesting language to those engaged in 
>scientific computing (as I am).
>
>I am currently trying to influence the attitude of my colleagues 
>(working mainly in astronomy), and make them aware of the advantages 
>of Lisp vs. Fortran or even C, but I need convincing arguments not
>strong convictions!

I think the best argument for the use of an OODL in scientific
computing is that it gives you an interactive environment for
modeling your problem domain.  Once you've created OODL objects
which correspond to your real-world objects, you can do anything
you want with them, very quickly.  You can easily build additional
tools for manipulating the objects, you can easily show different
views of the object, etc.

This is hard to describe, but it's very noticeable when you use
an OODL.

  -Andrew


From alms@cambridge.apple.com Thu Oct  8 19:03:17 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08178; Thu, 8 Oct 92 18:39:37 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210082239.AA08178@cambridge.apple.com>
Date: Thu, 8 Oct 1992 18:49:22 -0500
To: John Lewis <zilla@CCRL.NJ.NEC.COM>,
        Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: dylan scientific/multimedia
Cc: info-dylan@CAMBRIDGE.APPLE.COM

At  4:14 PM 10/7/92 -0400, Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU wrote:
>

>What would be necessary in Dylan to get as good numeric performance as is
>available in some Common Lisp implementations?
> -- Specialized array element types are definitely necessary.
> -- Type declarations for module (global) variables would be very useful.
>    This is really only necessary for mutable variables.
> -- There also needs to be either a predefined class variable for each
>    specialized array element type, or a general class generator which
>    produces the specialized class when presented with an element type.
>    These classes would be used in slot and variable type declarations.

We're considering all of these, as well as a system for declaring the
types of return values.


> -- As long as SET! is basically never used on local variables, it will
>    *not* be necessary to allow the type of local variable contents to be
>    declared.  This implies that iterations will always be written using
>    BIND-METHODS or equivalent forms of recursion.  (Note that the types in
>    BIND and method specializers only specify the type of the initial value.)

I think the types specified in BIND and METHOD specializers should also
restrict the subsequent values that can be stored in the variables.  This
would simplify the language and improve efficiency.


> -- Efficient small-integer (i.e. array index) arithmetic must be possible.
>    The difficulty of proving that small-integer arithmetic doesn't result
>    in overlow is one of the major causes of inefficency in Common Lisp
>    programs (even non-numeric ones.)

There are other messages on this, so I won't answer here.


>Overall, it seems that Dylan is fundamentally any worse than Common Lisp
>for numeric efficiency...

[Assuming the word 'not' is missing]

Dylan encourages programmers to include lots of type information.  It's
a very natural thing to do when writing Dylan programs.  In Common Lisp,
declarations have to be tacked on.  Many programmers just don't bother
with them.  To me, this places Dylan at a great advantage over Common Lisp.

  -Andrew


From ses@SunSite.unc.edu Thu Oct  8 23:28:58 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05064; Thu, 8 Oct 92 23:28:58 -0400
Received: from [152.2.22.81] by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05907; Thu, 8 Oct 92 23:36:14 -0400
	for moon@cambridge.apple.com
Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88)
	id AA18915; Thu, 8 Oct 92 23:31:59 EDT
Message-Id: <9210090331.AA18915@SunSite.unc.edu>
To: Rob_MacLachlan@lisp-pmax1.slisp.cs.cmu.edu
Cc: "David A. Moon" <moon@cambridge.apple.com>, info-dylan@cambridge.apple.com
Subject: Re: small integers 
In-Reply-To: Your message of "Thu, 08 Oct 92 16:31:36 EDT."
             <9210082035.AA02290@brazil.cambridge.apple.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 08 Oct 92 23:31:59 -0400
From: Simon Spero <ses@SunSite.unc.edu>

One thing that would be nice which might finesse this problem would be to 
extend the notion of singletons to cover slot values; that way one could
have a type specifier along the lines of ( bibble (<integer> min: 0 max:255)),
and let the compiler determine the meaning. Of course, if this is too general,
then dispatching gets even heavier- I just miss Haskell/Miranda style
patterns and guards..
Simon

From surak@ugcs.caltech.edu Fri Oct  9 02:54:06 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13114; Fri, 9 Oct 92 02:54:06 -0400
Received: from through.ugcs.caltech.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06618; Fri, 9 Oct 92 03:01:52 -0400
	for info-dylan@cambridge.apple.com
Received: from irk.ugcs.caltech.edu by through.ugcs.caltech.edu with SMTP 
	(16.6/UGCS:4.42) id AA01317; Fri, 9 Oct 92 00:01:35 -0700
From: surak@ugcs.caltech.edu (Surak of Vulcan)
Received: by irk.ugcs.caltech.edu
	(16.6/UGCS:4.42) id AA08387; Fri, 9 Oct 92 00:01:31 -0700
Message-Id: <9210090701.AA08387@irk.ugcs.caltech.edu>
Subject: missing files in Thomas-1.0
To: info-dylan@cambridge.apple.com
Date: Fri, 9 Oct 92 0:01:30 PDT
X-Mailer: ELM [version 2.3 PL11]

Folks,
	I am trying to get Thomas up and runing on a Mac II, I just 
	got Gambit 1.9, when I (load "load-thomas") it gives me error
	on missing file "msort.scm".

	Any pointers will be appriciated.

Waqar Malik

From ranson@LANNION.cnet.fr Fri Oct  9 03:15:06 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13941; Fri, 9 Oct 92 03:15:06 -0400
Received: from pamir.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06727; Fri, 9 Oct 92 03:22:46 -0400
	for info-dylan@cambridge.apple.com
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 09 Oct 92 08:19:23+0100
X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
	Relayed; 09 Oct 92 08:19:00 GMT
Date: 09 Oct 92 08:19:00 GMT
From: Ranson <ranson@LANNION.cnet.fr>
Message-Id: <m0mdEdQ-00000JC(a)lamd01>
To: info-dylan@cambridge.apple.com, surak@ugcs.caltech.edu
Subject: Re:  missing files in Thomas-1.0

Make sure the file is really missing. If not, I have found that giving more
memory to Gambit helps.
     Daniel.



From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Fri Oct  9 03:19:03 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14104; Fri, 9 Oct 92 03:19:03 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06790; Fri, 9 Oct 92 03:26:48 -0400
	for moon@cambridge.apple.com
Message-Id: <9210090726.AA06790@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa01904; 9 Oct 92 3:22:49 EDT
To: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Thu, 08 Oct 92 13:57:43 -0500.
             <9210081752.AA24044@cambridge.apple.com> 
Date: Fri, 09 Oct 92 03:22:39 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    This is only my initial reaction, but this strikes me as a really bad idea, 
    because it violates the principle that correct programs should be easy to 
    write and the burden of micro-optimization should be on programmers who need 
    to do micro-optimization, not on all programmers.  It seems to me that you're 
    making the language significantly more complicated and hard to understand, 
    just to make compiler optimization a little easier.  The specific aspect I 
    object to is having two non-id?, non-operationally-equivalent integers with 
    the same mathematical value.
    
    Can't we find a less semantically violent way to enable the desired compiler 
    optimization?

This integer business isn't going to come out clean on all dimensions
however we slice it.  The sad truth is that existing (or
foreseeable-future) hardware provides efficient arithmetic for a certain
class of integers, but this class isn't closed under the major arithmetic
operations.  So either you take an exception when one of these operations
overflows or you quietly roll over into an infinite-precision format that
is *much* less efficient.

So how should Dylan deal with this?  Let's try to look at all the
possibilities and see which best meets the goals of Dylan.

1. The current Dylan approach (as I understand the book) would quietly roll
over to an infinite precision format whenever an overflow occurs.  This is
indeed the easiest system in which to write correct code.  If you don't
care at all about efficiency, you never have to worry about overflows or
the size of your integers.

But the price for this bit of added safety is very high.  First, you have
to keep the bignum code around in the runtime system at all times, and that
code is large and complex.  Second, no arithmetic operations on integers
can be open-coded, since you have to allow for bignum operands and
overflows everywhere.  This is not just micro-optimization -- it can slow
these arithmetic operations down by a factor of 4 or more, whether or not
your program ever actually sees a bignum.  You're paying a lot for a
complex facility that most programs do not use.

I think that this option is unacceptable if Dylan aspires to be a language
for writing real code that is competitive with C in efficiency.

2. We could go with the system described in 1 above, but add type
declarations a la Common Lisp.  The problem is that it is not sufficient
just to declare your variables to be fixnum (or small-integer).  You also
have to declare the output of each arithmetic operator to be fixnum, since
two fixnums might produce a bignum.  This is true no matter how smart your
compiler is.  Alternatively, you could declare the variables to have much
smaller ranges, such as (integer -1000 1000), and a sufficiently smart
compiler could then prove that certain arithmetic operations would not
overflow.  But this puts a big load on both the programmer and the
compiler.  Note, for example, that the fact that a loop counter starts at
1000 and counts down to 0 does not allow the compiler to assume short-float
arithmetic unless it can also prove that no code within the body of the
loop alters the counter variable.

Again, I wouldn't call this micro-tuning.  You have to put these delaration
in everywhere unless you're willing to take a BIG hit in performance, and
you have to get them right.  Once you start putting in declarations to get
reasonably efficient code, the risk of getting something wrong is greater
than the risk of getting hit unexpectedly by an overflow, so writing
correct code becomes harder, not easier.

3. The opposite extreme is to throw bignums out altogether.  If any
operation overflows, a condition is signalled.  This does make it a bit
harder for the programmer to write correct code, since there is a new kind
of error that the programmer must worry about.  However, such errors are
rare (especially if we mandate a minimum small-integer size of 28 bits or
so), and usually easy to rule out.  In exchange for this new risk, we get
some major beneifts: the runtime system no longer needs the bignum code,
and the programmer gets maximally efficient integer code without any
hassles over type declarations.

Most programmers (now including me) feel that this trade-off is a good one.
The risk of an occasional overflow is a small price to pay for code that is
maximally efficient without any great effort on the programmer's part.
Most conventional languages adopt this option, and even novice programmers
seem to thrive in this regime.  Having a good condition-handling system
makes overflows that much less fearsome when they do occur.

However, there are occasional situations in which bignums and ratios of
bignums are useful after all, so I don't think that 3 is an optimal choice
for Dylan.

4. Rob's proposal basically makes 3 the default, but allows you to pull in
bignums if you want to use them.  This seems like a nice, intuitive model
to me: if you don't traffic in bignums, they aren't going to appear
unbidden.  In that case, you don't have to keep the bignum code around (or
load it in the first place), and you don't have to write a lot of arcane
declarations to get good performance.  But if you want to play with
bignums, there they are.  The downside, as you point out, is that overflow
policy is now bundled into the data type, so there are two different
flavors of integer 5.  This can be confusing, though less so if we make
these two types look slightly different, as I suggested.

5. We could go with a dual overflow policy, as in 4, but hide the overflow
signal-or-bignum selection somewhere other than in the types of the
operands.  For example, we could have two separate sets of arithmetic
operators, one for fixnums only (signalling an error on overflow) and one
that would allow, and sometimes produce, bignums.  In fact, many Common
Lisp programmers end up doing this with macros: they define a +fix macro
that calls + with the inputs and output declared to be fixnums, and so on.
I think that this is somewhat uglier than 4, but could live with it.  It
certainly doesn't look very object-orietned to have separate function names
for the fixnum-only and maybe-bignum versions of plus.

If we go this way, I would argue that the fixnum-only versions should get
the good names (+, -, etc.), since they are what most programmers will use
most of the time.

6. One other option is to declare, for whole chunks of code, that
arithmetic is to be fixnum-only or maybe-bignum.  This must be done at
compile-time if you want the fixnum-only code to be efficiently open-coded.
The problem here is that this is a rather blunt axe.  You might want to do
some maybe-bignum addition within a loop whose counter is incremented and
tested using fixnum arithmetic.  A big-switch approach doesn't give you
fine enough control to do this.


Those are all the options I can think of.  For my own use, I would rate
these options in descending order as follows: {4 5 6 3 2 1}.  Probably most
of the C++ programmers we want to appeal to would come up with a similar
rating (or maybe would put 3 at the top if they've never learned to like
bignums).  Common Lisp old-timers might rank 2 first, unless, like me,
they've learned to hate these declarations after years of putting them in
for efficiency.

-- Scott

===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From ulrich.kriegel@isst.fhg.de Fri Oct  9 03:32:21 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14519; Fri, 9 Oct 92 03:32:21 -0400
Received: from fhg.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06823; Fri, 9 Oct 92 03:39:55 -0400
	for info-dylan@cambridge.apple.com
From: ulrich.kriegel@isst.fhg.de
Received: by fhg.de (mail-gw.fhg.de) with PRESMTP; Fri, 9 Oct 92 08:35:54 +0100 from FHG-GATEWAY 
Received: by fhg.de (mail-gw.fhg.de) with SMTP; Fri, 9 Oct 92 08:35:50 +0100 from rabbit.isst.fhg.de 
Received: from isst.fhg.de by rabbit.isst.fhg.de with SMTP (PP) 
          id <11148-0@rabbit.isst.fhg.de>; Fri, 9 Oct 1992 08:35:28 +0100
Received: from [192.102.158.50] (iapetus) by mouse.isst (4.1/SMI-4.1) 
          id AA03619; Fri, 9 Oct 92 08:35:19 +0100
Message-Id: <9210090735.AA03619@mouse.isst>
Sender: Ulrich.Kriegel@isst.fhg.de
Date: Fri, 9 Oct 1992 08:36:39 +0100
To: info-dylan@cambridge.apple.com
Subject: Numeric efficiency in dylan (or lisp in general)

I think, it is not necessary for dynamic typed languages to produce highly
efficient numeric code - I doubt, if it is possible at all. Instead of that
one should require that such languages should be "integrable" into the
brave new software world so that one is able to call foreign functions from
dynamic typed languages and vice versa. That does not mean that I neglect
the possibility of generating efficient num. code from lisp, but in general
it will be only possible to reach a numeric efficiency which is "comparable
- half as fast as" to FORTRAN or C.
-- ulrich
---------------------------------------------------------
E.Ulrich Kriegel, ulrich.kriegel@isst.fhg.de, (++49 30) 20372-346 
Fraunhofer Institute for Software Engineering and Systems Engineering
(FhG ISST), Kurstrasse 33, D-O-1086 Berlin, FRG
fax:   (++49 30) 20372-207
=====================================================================


From feeley@IRO.UMontreal.CA Fri Oct  9 08:54:50 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26069; Fri, 9 Oct 92 08:54:50 -0400
Received: from kovic.IRO.UMontreal.CA by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07061; Fri, 9 Oct 92 09:02:37 -0400
	for info-dylan@cambridge.apple.com
Received: by kovic.IRO.UMontreal.CA (4.1-SMI)
	id AA03557; Fri, 9 Oct 92 08:59:16 EDT
Date: Fri, 9 Oct 92 08:59:16 EDT
From: Marc Feeley <feeley@iro.umontreal.ca>
Message-Id: <9210091259.AA03557@kovic.IRO.UMontreal.CA>
To: info-dylan@cambridge.apple.com
Subject: GAMBIT and THOMAS

There was a garbage collector bug in Gambit 1.8.2 that prevents its use
for running Thomas.  The problem was in the GCing of weak-pairs which are
used for collections/populations.

The new release of Gambit, version 1.9, fixes this bug and adds a few
features unrelated to Thomas (better editor, online help, etc).

You can get the interpreter from trex.iro.umontreal.ca (our internet
problem has been fixed now).  There is also a "linker" kit that can
be used to build a standalone Thomas interpreter from the object files (.O)
produced by the Gambit compiler.

Hope this helps...

Marc Feeley

P.S. send any bug reports to gambit@trex.iro.umontreal.ca

From bachrach@miles.ircam.fr Fri Oct  9 09:04:11 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26596; Fri, 9 Oct 92 09:04:11 -0400
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07132; Fri, 9 Oct 92 09:11:43 -0400
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 9 Oct 1992 14:08:01 +0100
Received: by miles.ircam.fr, Fri, 9 Oct 1992 14:08:00 +0100
Date: Fri, 9 Oct 1992 14:08:00 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210091308.AA01721@miles.ircam.fr>
To: ulrich.kriegel@isst.fhg.de
In-Reply-To: ulrich.kriegel@isst.fhg.de's message of Fri, 9 Oct 1992 08:36:39 +0100 <9210090735.AA03619@mouse.isst>
Subject: Numeric efficiency in dylan (or lisp in general)
Cc: info-dylan@cambridge.apple.com

I have worked very long and hard with LISP implementations trying to
achieve good numeric performance.  It is a total MYTH that LISP is
doomed to be slower in numeric performance.  I have been able to
achieve in some cases even better performance than C (e.g., a neural
network simulator using the lucid compiler on a sparc).  As simon
spero wrote: ``if there's sufficient type information available at
compile-time, lisp can be as fast as fortran.''  

This statement is all true within a function, the caveat is when a
function calls other functions that take floating-point arguments or
return floating-point results.  The problem is that the representation
of a float usually requires boxing and unboxing the float args/results
upon function call/return and thus allocating the floats on the heap.
Therein lies the rub. A generational GC can recover this garbage and
thus smoothly spread out the overhead, but this overhead pushes the
ratio of LISP to C runtime more towards 2.  There is one brute force
way around this that keeps the performance ratio more towards 1, such
as passing/returning float vectors instead of floats, but this is a
burden on the programmer.  The real problem to date was that there was
no way to avoid the FP call/return overhead incurred when calling the
floating-point library functions (e.g., `exp').  (I ended up calling C
for these functions and passed one-element vectors to avoid the
boxing.)

With regards to this problem (as Rob MacLachlan mentioned), Dylan has
a nice way to turn off run-time function redefinition (by
freezing/sealing a class).  Given this feature, I think that at least
the FP call/returns to/from the FP library (and to frozen user defined
classes) will not need to box/unbox floats and will run just as fast
as any other language.

In conclusion, Dylan is NOT doomed to be slow to crunch numbers, but
there does need to be some careful attention given to this area in
order to get maximal performance (re: earlier letters on
float-vectors, short-floats, and parameterized types).

-- jonathan bachrach

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




From bachrach@miles.ircam.fr Fri Oct  9 09:12:20 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27015; Fri, 9 Oct 92 09:12:20 -0400
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07194; Fri, 9 Oct 92 09:20:01 -0400
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 9 Oct 1992 14:16:23 +0100
Received: by miles.ircam.fr, Fri, 9 Oct 1992 14:16:21 +0100
Date: Fri, 9 Oct 1992 14:16:21 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210091316.AA01733@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: lisp's numeric efficiency (followup)

There was a tiny problem with my last message:

  The real problem to date was that there was no way to avoid the FP
  call/return overhead incurred when calling the floating-point library
  functions (e.g., `exp').  (I ended up calling C for these functions
  and passed one-element vectors to avoid the boxing.)

This previous problem only definitely pertains to Lucid lisp.  In
fact, I think that CMUCL can compile these library calls very
efficiently.  

The real efficiency problem occurs when calling user-defined FP
functions (because there is no way to turn off dynamism in LISP).

-- jonathan bachrach

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


From feeley@IRO.UMontreal.CA Fri Oct  9 09:42:14 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28671; Fri, 9 Oct 92 09:42:14 -0400
Received: from kovic.IRO.UMontreal.CA by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07269; Fri, 9 Oct 92 09:49:58 -0400
	for info-dylan@cambridge.apple.com
Received: by kovic.IRO.UMontreal.CA (4.1-SMI)
	id AA05490; Fri, 9 Oct 92 09:45:50 EDT
Date: Fri, 9 Oct 92 09:45:50 EDT
From: Marc Feeley <feeley@iro.umontreal.ca>
Message-Id: <9210091345.AA05490@kovic.IRO.UMontreal.CA>
To: thomas@hera.gmd.de
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Tom Gordon's message of Fri, 9 Oct 1992 14:13:29 +0100 <199210091313.AA02872@hera.gmd.de>
Subject: GAMBIT and THOMAS

>Could you make this standalone Thomas interpreter also available for ftp? 
>It may save a lot of people some time, and also reduce communications
>costs.

I'm not sure its a good idea.  The sources to Thomas are not very
stable at this point and I don't want to rebuild the system for every
small change.  Also, the point of DEC's implementation is not only to
play with the language but also its guts.

I don't mind installing a standalone version of Thomas on our FTP
server.  However, I don't want to be in charge of actually building
the system (I am not using Thomas very much at the present time
anyway).  There are also problems with the current error system that
drops into Scheme when there is an error (its not exactly user
friendly).  I think it would be best if the people at DEC or Apple
were in charge of the standalone Thomas interpreter.

Marc Feeley

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Fri Oct  9 11:23:38 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01279; Fri, 9 Oct 92 11:23:38 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07647; Fri, 9 Oct 92 11:31:26 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210091531.AA07647@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa02392; 9 Oct 92 11:27:53 EDT
To: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Numeric efficiency in dylan (or lisp in general) 
In-Reply-To: Your message of Fri, 09 Oct 92 14:08:00 +0000.
             <199210091308.AA01721@miles.ircam.fr> 
Date: Fri, 09 Oct 92 11:27:50 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


I agree with Jonathan Backrach that Lisp can be quite competitive with C in
terms of numerical efficiency.  I spend a lot of my time writing neural-net
simulation code (very float-intensive, and it runs for hours) in CMU CL.
The last time we measured, it was 10%-20% slower than the same code
hand-translated to C by a grad student and run through a first-rate C
compiler on the same machine.  That's close enough to eliminate any desire
I might have to switch this work to C.

I think that Dylan (some widely available implementations, at least) must
aim for comparabale performance if it is to achieve the goal of attracting
people who now program in static languages.  Many people just won't move
over if you tell them their code will run more than 2x slower, regardless
of how nice the Dylan environment is for development.  Runtime efficiency
is more measurable, and thus more real to people, than productivity gains.
That may be irrational in the age of ever-faster machines, but that's how
it is.  I'm not sure what the magic number is.  For me, a penalty of 20%
doesn't matter, but for this neural net code a factor of 2 would matter.

One source of inefficiency is Lisp's (and Dylan's) dynamic typing, or
rather the lack of sufficient type info at compile time.  But I prefer to
think of Common Lisp as having "optional strong typing": You can say as
much or as little as you want about the type of each object and slot.  The
more you say, the better job the compiler can do.  If you just say that an
object is of type <object>, that provides no information -- fine unless
it's in a performance-critical stretch of code.

A second source of inefficiency is the lack of provision for type-tags in
most current architectures, at least in floating-point numbers.  Everyone
has decided that 32-bit and 64-bit floats are standard, and that leaves no
room for a type tag in a 32-bit or 64-bit machine.  Stealing some bits of
the number to use as a tag is not a good solution in general, since it is
inefficient (you have to keep masking off and restoring those tags) and it
leads to problems with the rounding that is build into a good FPU.  So, in
the general case, you have to "box" floating-point numbers and allocate
them on the heap.  But our Python compiler already does a very good job of
avoiding number-consing if you provide enough type info at compile time.

The final source of inefficiency is from the ability to redefine things on
the fly: functions, classes, etc.  This means that some extra cost is
incurred at the seams between redefinable objects, usually in the form of
an extra level of indirection.  It also means that cross-function
optimizations are impossible (or greatly reduced in effectiveness).  This
is where Dylan's "seal it and ship it" orientation is going to be
important.  At some point, you will state that you're done with redefining
things, and ask the compiler to produce a module that has all the seams
welded shut.  If you later want to change something, you throw out that
whole compiled module and go back to the source.

Yes, we need an excellent call out to C for other reasons, but we should
not give up on the goal of providing excellent numerical performance in
(some implemntations of) Dylan.  I'm sure it can be done, and without
severely damaging the beauty of the language for less demanding
programmers.  It's fine with me if we put the whole floating-point package
in a library or optional facility, as long as we standardize what it should
look like if it is around.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From piazza Fri Oct  9 11:33:08 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01708; Fri, 9 Oct 92 11:33:08 -0400
Date: Fri, 9 Oct 92 11:33:08 -0400
From: Jeff Piazza <piazza>
Full-Name: Jeff Piazza
Message-Id: <9210091533.AA01708@cambridge.apple.com>
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Cc: moon, info-dylan
In-Reply-To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU's message of Fri, 09 Oct 92 03:22:39 -0400 <9210090726.AA06790@brazil.cambridge.apple.com>
Subject: small integers 

   Date: Fri, 09 Oct 92 03:22:39 -0400
   From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU

I would have thought this was obvious enough that someone else would
have mentioned it, but no one has, so perhaps it isn't.

Rather than focusing on different integer classes, it's possible to
cast the issue as one of using different operations.  That is, the ADD
operation on a typical CPU doesn't implement addition; it implements a
different operation (like "addition modulo 2^32") that is "close
enough" for most purposes.  Reflecting this in the programming
language, we would have, instead of two different 5's, two different
+'s: one under which the <small-integer> class is closed, and one
under which it isn't.  With the former operation, when the arguments
are provably small integers, the compiler can generate a machine ADD
instruction, and also conclude that the result will be a small
integer.  (This avoids having to declare every intermediate result,
which is certainly unpleasant.)

I can't think of particularly good names this morning, so let's
suppose for now that the two versions of addition are named fix+ and
int+, supported by binary-fix+ and binary-int+, respectively.  Then +
can be re-cast as a macro which expands either into fix+ or int+,
depending on declarations.  The result of this would be that one could
write a correct program easily, or obtain an efficient program with a
small amount of declaration effort.  Where it's necessary to mix the
two kinds of addition, one may write explicit calls to int+ or fix+
with cluttering the code too much.  (A drawback of the "+ as macro"
plan would be that one would have to write (reduce int+ 0 list-o-nums)
where one could write (reduce + 0 list-o-nums) today.)

Note that binary-fix+ (the "mod 2^n" operation under which
<small-integer> is closed) can be realized as a (sealed) generic
function containing only two methods: one handles the case of
small-integer arguments, and the other handles all other cases by
calling binary-int+.  New methods would be added only to binary-int+.

Similar remarks apply to -, *, and /.

Opinions?

/JEP

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Fri Oct  9 12:03:02 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03213; Fri, 9 Oct 92 12:03:02 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08055; Fri, 9 Oct 92 12:10:51 -0400
	for piazza@cambridge.apple.com
Message-Id: <9210091610.AA08055@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa02438; 9 Oct 92 12:06:56 EDT
To: Jeff Piazza <piazza@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Fri, 09 Oct 92 11:33:08 -0500.
             <9210091533.AA01708@cambridge.apple.com> 
Date: Fri, 09 Oct 92 12:06:52 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


Jeff,

This is what I was calling option 5.  I guess I didn't explain it very
well.  Actually, your proposal combines my options 5 (separate fix+ and
int+) and 6 (big switch at compile time) by using a + macro for operations
meant to be controlled by the big switch and the more specialized names
where finer control is required.

I could live with this.  I think having three flavors of +, -, etc. around
may be as confusing for users as having two flavors of 5, but I could
easily be wrong about this.  In either case, the complexity could just be
hidden from beginners.  They wouldn't have to know about the more
specialized operators (or in Rob's probposal, about bignums) until they're
armed with the Parentheses of Power and heading for level 3 of the dungeon.

The approach of bundling the desired behavior into the numeric operands
seems more object-oriented, but I guess that's a religious argument.

-- Scott

From cfry@MIT.EDU Fri Oct  9 13:23:07 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06007; Fri, 9 Oct 92 13:23:07 -0400
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08410; Fri, 9 Oct 92 13:30:57 -0400
	for moon@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA09721; Fri, 9 Oct 92 13:27:32 EDT
Message-Id: <9210091727.AA09721@MIT.EDU>
Date: Fri, 09 Oct 92 13:23:50 EST
From: cfry@MIT.EDU (Christopher Fry)
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Subject: Re: small integers 
Cc: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>, info-dylan@CAMBRIDGE.APPLE.COM

The Lisp machine approach to fixing the efficiency problems by special 
architecture failed in the marketplace.
But for this integer problem, there are now 64 bit microprocessors. 
If this represents a real trend, then suppose you just consider that 
Dylan users that care about speed will have  a 64 bit machine and the
"small" integers will be a LOT bigger than the 28 bits or so now common.
This will alleviate at least some of the need for bignums.

From Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU Fri Oct  9 13:35:32 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06457; Fri, 9 Oct 92 13:35:32 -0400
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08502; Fri, 9 Oct 92 13:43:21 -0400
	for piazza@cambridge.apple.com
Message-Id: <9210091743.AA08502@brazil.cambridge.apple.com>
Received: from lisp-pmax1.slisp.cs.cmu.edu by LISP-PMAX1.SLISP.CS.CMU.EDU
          id aa10512; 9 Oct 92 13:39:52 EDT
To: Jeff Piazza <piazza@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Fri, 09 Oct 92 11:33:08 -0500.
             <9210091533.AA01708@cambridge.apple.com> 
Date: Fri, 09 Oct 92 13:39:49 -0400
From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU


    Rather than focusing on different integer classes, it's possible to
    cast the issue as one of using different operations.

Short-integer-specific operators were used by most pre-Common Lisp
dialects.  It is a proven way to get efficient code.  Most portable Common
Lisp systems manufacture fixnum-specific operators using macros that insert
all possible (THE FIXNUM ...) declarations.

My main objection to relying on special <short-integer> operations (or
Common Lisp output type declarations) is that it makes it difficult to
write polymorphic arithmetic expressions.  For example, I could write:
    (define quadratic
      (method (x a b c)
	(+ (* (+ (* x a) b) x) c)))

This function can be used with any kind of number; if inline expanded
to allow specialized compilation it should also be quite efficient.
However, if special operators or output type assertions are required for
short integers, then short-integer uses will not be efficient.  As Scott
says, having special operators is not very object-oriented.

I also think that type-specific operators have a greater cognitive risk of
introducing bugs.  Since you want the type-specific operation 99.9% of the
time, you get used to always typing it, and somtimes type it when you
shouldn't have.

Another way to look at this is that the more times you have to say
<short-integer>, the more chances you have of being wrong.  Since
<extended-integer> is contagious, the error of using a short operation on
extended operands is not possible.

A slightly unrelated example of how you get into trouble with type-specific
operators comes from CLX (the Common Lisp X library.)  Since integers in
system programs are almost always array indices (non-negative short
integers), CLX defines the INDEX type to be a non-negative FIXNUM, and
defines macros INDEX+, INDEX-, etc., which insert THE declarations.
These INDEX operators ended up being always used, too invariably, in fact.
The operands were indeed always small integers, but were not always
non-negative.  

In particular, in a few places, (INDEX- X) was used to negate an integer.
Since most Common Lisp implementations ignore the non-negative part of the
INDEX declaration, this problem was only detected when Python inferred that
X must be 0, and complained that a subsequent comparison made code
unreachable.

  Rob

From jh@ministry.cambridge.apple.com Fri Oct  9 13:35:46 1992
Received: from jh.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06474; Fri, 9 Oct 92 13:35:46 -0400
Full-Name: John Hotchkiss
Message-Id: <9210091735.AA06474@cambridge.apple.com>
Date: Fri, 9 Oct 1992 13:41:42 -0500
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU,
        Jeff Piazza <piazza@CAMBRIDGE.APPLE.COM>
From: jh@ministry.cambridge.apple.com
Subject: Re: small integers
Cc: info-dylan@CAMBRIDGE.APPLE.COM

>Jeff,
>
>This is what I was calling option 5.  I guess I didn't explain it very
>well.  Actually, your proposal combines my options 5 (separate fix+ and
>int+) and 6 (big switch at compile time) by using a + macro for operations
>meant to be controlled by the big switch and the more specialized names
>where finer control is required.
>
>I could live with this.  I think having three flavors of +, -, etc. around
>may be as confusing for users as having two flavors of 5, but I could
>easily be wrong about this.  In either case, the complexity could just be
>hidden from beginners.  They wouldn't have to know about the more
>specialized operators (or in Rob's probposal, about bignums) until they're
>armed with the Parentheses of Power and heading for level 3 of the dungeon.
>
>The approach of bundling the desired behavior into the numeric operands
>seems more object-oriented, but I guess that's a religious argument.
>

I favor bundling the behavior into the operands. Not only does it seem more
object-oriented, but it presents a more familiar model to programmers from
other languages. 



From davis@ilog.ilog.fr Fri Oct  9 14:25:55 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07636; Fri, 9 Oct 92 14:25:55 -0400
Received: from corton.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08732; Fri, 9 Oct 92 14:33:36 -0400
	for piazza@cambridge.apple.com
Received: from ilog.UUCP by corton.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA24141; Fri, 9 Oct 1992 17:37:03 +0100 (MET)
Date: Fri, 9 Oct 92 16:58:42 +0100
Received: from passy.ilog by ilog.ilog.fr, Fri, 9 Oct 92 16:58:42 +0100
From: davis@ilog.ilog.fr (Harley Davis)
Message-Id: <9210091558.AA25256@ilog.ilog.fr>
Received: by passy.ilog (4.1/SMI-4.1)
	id AA04477; Fri, 9 Oct 92 16:58:41 +0100
To: piazza@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Jeff Piazza's message of Fri, 9 Oct 92 11:33:08 -0400 <9210091533.AA01708@cambridge.apple.com>
Subject: small integers

   Date: Fri, 9 Oct 92 11:33:08 -0400
   From: Jeff Piazza <piazza@cambridge.apple.com>
 
   we would have, instead of two different 5's, two different
   +'s: one under which the <small-integer> class is closed, and one
   under which it isn't.  With the former operation, when the arguments
   are provably small integers, the compiler can generate a machine ADD
   instruction, and also conclude that the result will be a small
   integer.

This solution has been used in Le-Lisp for about 10 years.  It works
quite well within individual functions and for fixnums in general, but
does not address the crucial boxed float problem across function
boundaries.  However, it can solve it within a single function with
just a little compiler cleverness.  The result is that all fixnum and
simple FP programs run at the same efficiency as C but any real
programs are still considerably slower.

The real advantage of this approach is that it is easy to implement
and the user knows exactly what he's getting without having to
second-guess the compiler or read a lot of compiler output messages.
It also provides a very simple form of expression type declaration
without verbose syntax, which allows unboxing of floats within a
function.

This approach combined with return type declarations and sealing
should also allow intramodule optimizations, allow the increase in
implementational complexity is considerable.  For intermodule
optimizations, we would need more details on what the module system
provides.

I don't think the call to fix+ or whatever should be masked by a +
macro.  Furthermore, I don't see how to implement such a macro unless
the Dylan macro system allows access to a lot of compiler information.
I think + should check for overflow and fix+ should not, as Fahlman
suggested when he brought up this idea.  They are really two different
semantic operations, one working on numbers and the other on
representations.

-- Harley Davis

From Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU Fri Oct  9 14:38:09 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08045; Fri, 9 Oct 92 14:38:09 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08774; Fri, 9 Oct 92 14:45:59 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210091845.AA08774@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa04141;
          9 Oct 92 14:42:17 EDT
To: Christopher Fry <cfry@MIT.EDU>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Fri, 09 Oct 92 13:23:50 -0500.
             <9210091727.AA09721@MIT.EDU> 
Date: Fri, 09 Oct 92 14:41:33 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


    But for this integer problem, there are now 64 bit microprocessors. 
    If this represents a real trend, then suppose you just consider that 
    Dylan users that care about speed will have  a 64 bit machine and the
    "small" integers will be a LOT bigger than the 28 bits or so now common.
    This will alleviate at least some of the need for bignums.

If these users (and the builders of the languages they run on) decide to
use 64-bit immediate types and pointers and not try to save space and
swapping by sticking to 32 bits for most things.  Time will tell.  There
was a time when people were tempted to stick with 16 bits, even though 32
bits were newly available.  Unix and C are polluted with the residue of
16-bit thinking.

-- Scott

From Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU Fri Oct  9 15:01:50 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08844; Fri, 9 Oct 92 15:01:50 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08919; Fri, 9 Oct 92 15:09:40 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210091909.AA08919@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa04172;
          9 Oct 92 15:05:33 EDT
To: Harley Davis <davis@ilog.ilog.fr>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Fri, 09 Oct 92 16:58:42 +0000.
             <9210091558.AA25256@ilog.ilog.fr> 
Date: Fri, 09 Oct 92 15:05:21 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


    This solution has been used in Le-Lisp for about 10 years.  It works
    quite well within individual functions and for fixnums in general, but
    does not address the crucial boxed float problem across function
    boundaries.

Huh?  We're talking about integers in this thread, though there have also
been some messages flying around about floats.  Let's try not to muddle the
two -- the issues are rather different.

    I don't think the call to fix+ or whatever should be masked by a +
    macro.  

Why not?  If we're going to have fix+ and int+, hiding them both behind a +
macro with a big compile-time switch seems quite attractive to me.  This
makes it easy to live within the default policy you like (overflow-safe or
efficient) and to change that policy easily.  You don't have to write the
more verbose (ugly, confusing) forms unless you want to micro-manage
things.

    Furthermore, I don't see how to implement such a macro unless
    the Dylan macro system allows access to a lot of compiler information.

I haven't looked closely a the macro stuff as yet, but it had better allow
macros to generate different code based on declarations or something like a
compile-time variable setting.  Else, it's not good enough.

    I think + should check for overflow and fix+ should not, as Fahlman
    suggested when he brought up this idea.  They are really two different
    semantic operations, one working on numbers and the other on
    representations.

Hmmm... I'm not sure what that means.  They both check for overflow of the
fixnum range.  One (fix+) signals an error while the other (int+) rolls
into bignum code.

-- Scott

From kanderso@BBN.COM Fri Oct  9 15:04:00 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08912; Fri, 9 Oct 92 15:04:00 -0400
Received: from KARIBA.BBN.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08943; Fri, 9 Oct 92 15:11:50 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210091911.AA08943@brazil.cambridge.apple.com>
To: info-dylan@cambridge.apple.com
Cc: Kanderson@BBN.COM
From: KAnderson@BBN.COM
Subject: object-class?
Date: Fri, 09 Oct 92 15:05:56 -0400
Sender: kanderso@BBN.COM


On page 92 it says object-class is a generic function.  Does that mean a
user can or should redefine it for some class?

Is it correct to assume the following interpretation about how functional
objects are defined in the Documentation:

[Generic Function] methods can be added by user, unless it its sealed somehow.

[Function] implementation specfic.  It can't be altered in anyway since it
is read only.

[Method] similar to Function?

From ses@SunSite.unc.edu Fri Oct  9 15:38:56 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12183; Fri, 9 Oct 92 15:38:56 -0400
Received: from SunSite.unc.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09020; Fri, 9 Oct 92 15:46:45 -0400
	for info-dylan@cambridge.apple.com
Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88)
	id AA22275; Fri, 9 Oct 92 15:42:29 EDT
Message-Id: <9210091942.AA22275@SunSite.unc.edu>
To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu
Cc: info-dylan@cambridge.apple.com
Subject: Re: Numeric efficiency in dylan (or lisp in general) 
In-Reply-To: Your message of "Fri, 09 Oct 92 11:27:50 EDT."
             <9210091531.AA07647@brazil.cambridge.apple.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 09 Oct 92 15:42:29 -0400
From: Simon Spero <ses@SunSite.unc.edu>

>>an extra level of indirection.  It also means that cross-function
optimizations are impossible (or greatly reduced in effectiveness).  This
is where Dylan's "seal it and ship it" orientation is going to be
important.<<

Sorry if this has been gone over N times before; I've got a question about the
meaning of function freezing, which overlaps slightly into sealing. 
When you freeze a method which is bound to a module variable, do you also 
freeze the value of that variable, or can that variable be changed later
without melting the method first?

Simon

From alms@cambridge.apple.com Fri Oct  9 15:55:29 1992
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15597; Fri, 9 Oct 92 15:55:29 -0400
Full-Name: Andrew L. M. Shalit
Message-Id: <9210091955.AA15597@cambridge.apple.com>
Date: Fri, 9 Oct 1992 16:05:23 -0500
To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu, Simon Spero <ses@SunSite.unc.edu>
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Numeric efficiency in dylan (or lisp in general)
Cc: info-dylan@cambridge.apple.com

At  3:42 PM 10/9/92 -0400, Simon Spero wrote:
>
>>>an extra level of indirection.  It also means that cross-function
>optimizations are impossible (or greatly reduced in effectiveness).  This
>is where Dylan's "seal it and ship it" orientation is going to be
>important.<<
>
>Sorry if this has been gone over N times before; I've got a question about the
>meaning of function freezing, which overlaps slightly into sealing. 
>When you freeze a method which is bound to a module variable, do you also 
>freeze the value of that variable, or can that variable be changed later
>without melting the method first?

In the current spec, there's no such thing as "freezing a method which
is bound to a module variable".  Freezing methods is an operation which
is performed on methods inside a generic function, to prevent them from
being replaced or superceded.

In general, the descriptions of sealing in the manual should be taken
as an indication of our general intentions.  We plan to revamp the
sealing specification as part of the next round of language design.

Currently define-class and define-generic-function create read-only
module variables, and define-method and define create module variables
which can be assigned.  We're considering having all of these forms
create read-only variables, and adding a new form for creating
assignable module variables.

  -Andrew


From Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU Fri Oct  9 16:00:59 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16660; Fri, 9 Oct 92 16:00:59 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09141; Fri, 9 Oct 92 16:08:49 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210092008.AA09141@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa04213;
          9 Oct 92 16:05:11 EDT
To: Simon Spero <ses@SUNSITE.UNC.EDU>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Numeric efficiency in dylan (or lisp in general) 
In-Reply-To: Your message of Fri, 09 Oct 92 15:42:29 -0500.
             <9210091942.AA22275@SunSite.unc.edu> 
Date: Fri, 09 Oct 92 16:05:02 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


I think that the whole issue of freezing is under review by the Apple
folks.  It's pretty clear to all of us what has to be accomplished by
freezing; what's less clear is how to do that in the most reasonable way.

-- Scott

From moon Fri Oct  9 16:40:55 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20496; Fri, 9 Oct 92 16:40:55 -0400
Full-Name: David Moon
Message-Id: <9210092040.AA20496@cambridge.apple.com>
Date: Fri, 09 Oct 92 16:38:00 EDT
From: moon (David A. Moon)
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Subject: Re: small integers 
Cc: info-dylan@CAMBRIDGE.APPLE.COM

> Date: Fri, 09 Oct 92 03:22:39 -0400
> From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU

Scott, this was a good analysis, although I think there are some important points 
you have overlooked.

First, we don't believe in Dylan as an island unto itself, the approach many Lisp 
implementations have taken in the past.  To be successful, many implementations of 
Dylan are going to have to integrate well with the system environment in which they 
find themselves.  I think this would be true even if we were aiming Dylan at the 
Lisp community, but it's all the more true when we say we're aiming Dylan at 
developers who do not now use dynamic languages.  This means both that Dylan 
programs need good access to the facilities that are out there in the system, and 
that it must be possible, efficient, convenient, and natural to write applications 
in a mixture of Dylan and other languages.  This attitude has many implications, 
but the one I want to focus on here is the implication for integers: it is 
impossible to play in the Macintosh world without 32-bit integers; saying that 28 
bits are enough for most programs is only true when you look at Lisp programs in 
isolation.  I imagine most other environments, such as most dialects of Unix, also 
depend on 32-bit integers.

This implies that either small-integers are 32 bits (which is hard to do in a 
run-time typed world; although we could imagine that if we can solve the problem 
for 32-bit single-floats we can use the same solution for 32-bit small-integers) or 
else we can forget about the dream of programs that use small-integers exclusively 
and don't have to include the bignum runtime.

That was my most important point, but I also have a few comments on excerpts from 
your message:

> This integer business isn't going to come out clean on all dimensions
> however we slice it.

Agreed.

> 1. The current Dylan approach ... you have
> to keep the bignum code around in the runtime system at all times, and that
> code is large and complex.  Second, no arithmetic operations on integers
> can be open-coded, since you have to allow for bignum operands and
> overflows everywhere.

This is not quite right.  The combination of the <small-integer> class (behavior 
same as Common Lisp's fixnum type; not the same as Rob MacLachlan's proposed 
<small-integer>), which should be made a standard part of the language in my 
opinion, the pervasiveness of parameter specializers in the preferred Dylan 
programming style, and type inference in the compiler should eliminate the need to 
allow for bignum operands in most places where that is possible and the programmer 
cares about efficiency.  It may still be necessary to check for overflow, but that 
can certainly be open-coded with small cost, especially when the overflow causes a 
type error rather than continuing the computation with bignums.  This is what 
Pascal (at least on the Macintosh) does, so it can't be too expensive, although 
there is a compiler option to turn off the overflow checking.

There are published trace-scheduling-like techniques that allow for continuing the 
computation with bignums without burdening the small-integer path, however I don't 
think we would want to use them (at least not by default) because they expend space 
to gain speed and optimizing space is usually more important.  It's not in the LFP 
'92 paper, but doesn't CMU's Common Lisp compiler do this?

Anyway my point here is that the current Dylan language with the addition of the 
<small-integer> class is not necessarily so bad.  Admittedly we have neither told 
programmers how to use it efficiently nor told implementors what they need to do to 
support that programming style.  But maybe we would be better off doing our duty on 
those things rather than hairing up the language.

> .... Note, for example, that the fact that a loop counter starts at
> 1000 and counts down to 0 does not allow the compiler to assume [small-integer]
> arithmetic unless it can also prove that no code within the body of the
> loop alters the counter variable.

This is one of several reasons why the preferred Dylan programming style avoids 
set! of local variables.  There was some controversy about allowing that operation 
in the language at all, but we took the conservative path and left it in, since 
programmers coming from a Fortran or C (or Common Lisp!) background are likely to 
use it a lot at first until they catch on to the new programming style, and it's 
always good to give people a gradual path into your world.  The built-in Dylan 
iteration operations do not use assignment internally, at least in our 
implementations.  By the way, and I'm sure this will thrill you, I was thinking of 
creating an assignment-free version of the Common Lisp LOOP facility for Dylan (but 
not putting it into the language standard, of course).

> 3. The opposite extreme is to throw bignums out altogether.

As I noted earlier, this requires small-integers to be 32 bits and I'm not sure we 
know how to do that efficiently.

One other point about multiple operators: there are actually four versions of + we 
have been talking about:

 - the "mathematically correct", overflow into bignums version found in Dylan today
 - the same unless the operands are small-integers, then overflow signals an error
 - operands must be small-integers, overflow signals an error
 - operands must be small-integers, overflow wraps around

By the way I don't like the version of the fourth one that also accepts operands 
that aren't small integers.  This seems to me to be a dangerous conflation.

The fourth is what is found in C (overloading for floating point aside) and also 
exists internally in every Common Lisp implementation that I have used enough to 
discover it, however it's never been standardized and the name is different in each 
implementation.  In Macintosh Common Lisp it is %i+, in Symbolics Common Lisp it is 
%32-bit-plus or %24-bit-plus depending on the machine, in Lucid Common Lisp it is 
+& although it seems to turn into + unless optimizing for speed.

I think it's consistent with object orientation for the fourth version of + to have 
a different name from the first version, since they really do different things 
(real addition versus modulo 2^N addition).  Maybe it's been a mistake for Lisp 
implementations to keep this operator an internal secret all these years, and we 
should add such operations to Dylan.  I'm not sure precisely what I think about 
this, but it's something to consider.  Of course it would be better not to hair up 
the language if compiler optimization can do the job.  Also, as Rob MacLachlan 
pointed out in a message today, compiler optimization is more general since the 
same source code can be compiled two different ways depending on what the compiler 
knows about the types involved.

My question of whether it's feasible to eliminate the overflow checking through 
compiler optimization most of the time hasn't been answered yet.  I already know 
it's feasible to eliminate the type checking, so only the overflow checking 
remains.

I still think bundling the overflow behavior into the operands is a dangerous idea.

From pierce@at-ms-mail-server Fri Oct  9 18:11:33 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22754; Fri, 9 Oct 92 18:11:33 -0400
Received: from at-mail-server.vitro.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09478; Fri, 9 Oct 92 18:19:22 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210092219.AA09478@brazil.cambridge.apple.com>
Date: 9 Oct 1992 18:21:39 U
From: "pierce" <pierce@at-ms-mail-server>
Subject: Dylan FFI
To: info-dylan@cambridge.apple.com


David Moon writes:

>>Dylan programs need good access to the facilities that are out there in the
>>system, and that it must be possible, efficient, convenient, and natural to
>>write applications in a mixture of Dylan and other languages. 

I realize this is an implementation issue, but can someone comment on how
Apple's Dylan implementation handles this issue of hybrid programming.

Will a future Apple Dylan implementation be directly linkable in the MPW
environment, or will Dylan require that foreign code be loaded into it like
current Lisp implementations do?

Does having good access to facilities that are out there in the system mean the
ability to call traps, or does it mean that Dylan programs should be able to
take advantage of foreign coded libraries without building code resources out
of them?

More Specifically, Will some future desktop Dylan implementation support access
to MacApp or Bedrock?

-Jonathan Pierce



From Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU Sat Oct 10 00:05:24 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01648; Sat, 10 Oct 92 00:05:24 -0400
Received: from LISP-PMAX1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10107; Sat, 10 Oct 92 00:13:15 -0400
	for moon@cambridge.apple.com
Message-Id: <9210100413.AA10107@brazil.cambridge.apple.com>
Received: from lisp-pmax1.slisp.cs.cmu.edu by LISP-PMAX1.SLISP.CS.CMU.EDU
          id aa10873; 10 Oct 92 0:09:31 EDT
To: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Fri, 09 Oct 92 16:38:00 -0500.
             <9210092040.AA20496@cambridge.apple.com> 
Date: Sat, 10 Oct 92 00:09:22 -0400
From: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU

    Message-Id: <9210092040.AA20496@cambridge.apple.com>
    Date: Fri, 09 Oct 92 16:38:00 EDT
    From: "David A. Moon" <moon@cambridge.apple.com>
    To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    Subject: Re: small integers 

    
    > Date: Fri, 09 Oct 92 03:22:39 -0400
    > From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    
    To be successful, many implementations of Dylan are going to have to
    integrate well with the system environment in which they find
    themselves.  It is impossible to play in the Macintosh world without
    32-bit integers; [...] I imagine most other environments, such as most
    dialects of Unix, also depend on 32-bit integers.

This is exactly why CMU CL has special code generators for signed and
unsigned 32bit arithmetic.  As long as you are doing word-integer
arithmetic, there is no reason to invoke the overhead of arbitrary
precision.

I have given some though to how word-integers might be supported in Dylan.
This is really a corner of the foreign interface problem.  Probably there
should be a fairly clear correspondence between C/C++ types and Dylan
classes; many new classes would need to be introduced as part of the
foreign interface.  Some of those might be <int>, <unsigned-int>, etc.
And of course, those classes should work with C semantics, which I believe
ignores overflow totally.
    
    The combination of the <small-integer> class, the preferred Dylan
    programming style, and type inference in the compiler should eliminate
    the need to allow for bignum operands in most places where that is
    possible and the programmer cares about efficiency.

Well, that hasn't been our experience in Common Lisp.  Our programming
style types all function arguments and instance slots, and our type
inference is good, yet we still find the need to insert many FIXNUM output
type assertions in complex expressions.

    It may still be necessary to check for overflow, but that can certainly
    be open-coded with small cost, especially when the overflow causes a
    type error rather than continuing the computation with bignums.  This
    is what Pascal (at least on the Macintosh) does, so it can't be too
    expensive.

Yes, I agree that the cost of detecting overflow and signalling an error is
small, which is why I propose that <small-integer> overflow should always
signal an error.  However, in an overflow-to-bignum scheme, the only way
that you could signal an error instead of proceeding is if there were an
output type assertion, which won't be true of intermediate results in
complex expressions.
    
    There are published trace-scheduling-like techniques that [...]
    doesn't CMU's Common Lisp compiler do this?

Nope.  Self-style loop splitting would also work, but we'd really rather
not waste compile time and code size dealing with overflows that never
happen.  We just put in declarations until the compiler tells is it's
happy.  This technology does work, I just think we can do better.
    
    My question of whether it's feasible to eliminate the overflow checking
    through compiler optimization most of the time hasn't been answered
    yet.  I already know it's feasible to eliminate the type checking, so
    only the overflow checking remains.

Yes, the handing of overflow is all we are disagreeing about.  My answer is
that:
 -- yes it is usually possible, but
 -- type inference fails often enough to be annoying, and
 -- declaring appropriate subranges imposes a burden not present in other
    languages. 

  Rob

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Sat Oct 10 02:30:35 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05995; Sat, 10 Oct 92 02:30:35 -0400
Received: from [128.2.222.182] by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10221; Sat, 10 Oct 92 02:38:16 -0400
	for moon@cambridge.apple.com
Message-Id: <9210100638.AA10221@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa03194; 10 Oct 92 2:34:14 EDT
To: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Fri, 09 Oct 92 16:38:00 -0500.
             <9210092040.AA20496@cambridge.apple.com> 
Date: Sat, 10 Oct 92 02:33:59 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


<< I think this kind of language-design thread should probably be on
dylan-builders, but since it started here, I won't be the one to move it. >>

Dave,

I just saw Rob's response to this go by, and I agree with most of that, so
I'll just add a point or two.
    
Regarding the interface to a 32-bit outside world: I agree with Rob that
this is best handled by some special 32-bit data types and operators
introduced specifically for this purpose.  (This specialized stuff is
sequestered in a specialized library, of course.)  We've had good success
with this in CMU CL.

Of course, if this 32-bit imported data is woven all through your program,
rather than being handled in a few specialized interface routines, then
maybe you have to get into real bignums after all, and take your
performance hit.  I don't think this would be common, but it is a good
argument against flushing bignums altogether.

    > 1. The current Dylan approach ... 
    
    This is not quite right.  The combination of the <small-integer> class (behavior 
    same as Common Lisp's fixnum type; not the same as Rob MacLachlan's proposed 
    <small-integer>), 

Well, when I said the *current* Dylan approach, I meant the one in the
book, without any <small-integer> class.  The situation with a
small-integer type added (as in Common Lisp) is what I was calling option
2, and is analyzed there.

    ... the pervasiveness of parameter specializers in the preferred Dylan 
    programming style, and type inference in the compiler should eliminate the need to 
    allow for bignum operands in most places where that is possible and the programmer 
    cares about efficiency.

Agreed, most type-checking at the external inputs to arithmetic expressions
can be eliminated without undue pain to the programmer.  However, for
nested expressions, you need operand-type checking for internal values if
some of those might have turned into bignums.

    It may still be necessary to check for overflow, but that 
    can certainly be open-coded with small cost, especially when the overflow causes a 
    type error rather than continuing the computation with bignums.  This is what 
    Pascal (at least on the Macintosh) does, so it can't be too expensive, although 
    there is a compiler option to turn off the overflow checking.
    
Well, that's the crux.  Checking for the overflow is not too bad -- free on
some architectures -- but what do you do when you find one?  What Rob and I
are arguing against is the Common Lisp answer: you automatically roll over
into a bignum unless the user has inserted a (THE FIXNUM ...) around the
operation.  Allowing for the bignum rollover in all the places it *might*
happen is too expensive in many cases, and putting THE around *every*
arithmetic op is too much hassle for the programmer.

So what we're arguing for is an easy, intuitive way to say that we don't
want to worry about bignum rollover (or bignum operands) in certain
programs or parts of programs.  Rob's proposal is one way to indicate this
policy; Jeff Piazza's proposal (separate function names, glued together by
a macro) is another way.  I like both of these suggestions a lot better
than the Common Lisp solution.

I can't tell from your message whether you agree with this.  At times you
seem to favor the "correct" Common Lisp approach, and at other times you
seem to accept the idea of an overflow error under certain conditions.  If
we agree that an overflow error is the right thing in some situations, the
only remaining question is how to indicate where we want this behavior.

    I think it's consistent with object orientation for the fourth version of + to have 
    a different name from the first version, since they really do different things 
    (real addition versus modulo 2^N addition).  Maybe it's been a mistake for Lisp 
    implementations to keep this operator an internal secret all these years, and we 
    should add such operations to Dylan.

This mod-2 addition is similar in spirit to the specialized 32-bit
operators that Rob and I were advocating above for foreign function
interfaces.  You also need something like this in order to implement bignum
arithmetic.  These operators will need to exist, and should probably be
standardized at some point, but they can be hidden away in a specialized
"low-level-tools" facility, where average programmers will never trip over
them.

    Of course it would be better not to hair up 
    the language if compiler optimization can do the job.  Also, as Rob MacLachlan 
    pointed out in a message today, compiler optimization is more general since the 
    same source code can be compiled two different ways depending on what the compiler 
    knows about the types involved.

Ummm... are you now advocating that we encode wraparound policy in the type
of the arguments?  Probably not, since you oppose this move elsewhere, but
then I don't understand your comment above.
    
    My question of whether it's feasible to eliminate the overflow checking through 
    compiler optimization most of the time hasn't been answered yet.  I already know 
    it's feasible to eliminate the type checking, so only the overflow checking 
    remains.
    
I think Rob and I both tried to address this.  If all you say about the
operands is that they are of type <short-float>, then +, -, and * must all
check for overflow and be prepared to handle whatever overflows are found,
one way or another.  This is true regardless of how smart your compiler is.

If the user says that both arguments are of type (integer 0 1024) --
assuming Dylan provides a language in which to state this sort of thing --
then a sufficiently smart compiler can often prove that no overflow will
occur.  But to do this consistently puts an unacceptable burden on the
programmer: if he's interested in efficiency, he must now think about
exactly how big his arguments are allowed to be, he must prove to himself
that overflow is impossible in certain places, and he must worry about
whether the compiler is smart enough to figure this out as well.  In
practice, people just say "fixnum" and then complain about how slow
arithmetic is in Lisp.  It's infinitely easier just to say, one way or
another, that you don't believe overflows will occur in a certain part of
the program, and that you want to get an error signal if you're wrong.

-- Scott

P.S. Can you show me what the "new" style is for implementing an iteration
loop without using SET! ?  I can think of several ways to do this, but all
are ugly and/or inefficient.

From cassels@cambridge.apple.com Sat Oct 10 12:02:34 1992
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22614; Sat, 10 Oct 92 12:02:34 -0400
Full-Name: Bob Cassels
Message-Id: <9210101602.AA22614@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Sat, 10 Oct 1992 12:07:35 -0400
To: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>,
        Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: small integers
Cc: info-dylan@CAMBRIDGE.APPLE.COM

>whether the compiler is smart enough to figure this out as well.  In
>practice, people just say "fixnum" and then complain about how slow
>arithmetic is in Lisp.  It's infinitely easier just to say, one way or
>another, that you don't believe overflows will occur in a certain part of
>the program, and that you want to get an error signal if you're wrong.

This part succinctly captures the dilemma as I see it.  We all agree that
we want fast, efficient, robust code.  And we want it to be easy for the
programmer to write such code.  Ideally we'd like the compiler and runtime
to be simple and easy to implement.  A machine that implements integer
arithmetic "in the instruction set" (c.f. Lisp machines) satisfies the
constraints nicely.  For most special-purpose C/Fortran machines, the set
of constraints can't be satisfied, and something has to give.

[BTW, Scott is correct that the issues for integers and floating-point are
completely different.  In this message I'll keep the focus on integers.]

I believe in clever compilers and I make a living building language
implementations, so I'm perfectly happy writing off the ease of
implementation constraint.

For me, the most important concern is robustness from the *user's* point of
view.  [See below for the user/devloper distinction.]

So can we make it easy to write extremely efficient, robust code on C
machines?  I don't know how to do it.  Your approach (signal overflow)
allows reasonably efficient code for most machines, though on most the
overflow test requires at least one extra instruction per operation.  What
that approach loses is a certain amount of robustness -- what does a user
of an application do when she gets that "error signal"?  That's the moral
equivalent of "out of memory" on a machine where you can't get any more for
some reason.  I would rather not give up that level of robustness, since we
have ways to address it.  [It's fine for a developer to get such error
signals during development, 'cause then she can do something about it.  A
user is SOL.  Of course it is completely wrong to silently truncate the
answer.]

So I personally would prefer a system where the default was to do
arithmetic as mathematically as possible, because that's the way I'd like
to think about the problem.  [If I wanted everything mod 32, I'd say that.]
 Then the question is how to make it as easy as possible for me to write
code that the compiler can turn into efficient machine instructions.  I
would like the compiler to figure out as much as it can about integer
ranges.  In cases where I know something about the range, I should have
easy, natural ways to give the compiler that information.  If I'm willing
to claim without any proof that the integer won't overflow, I should have a
way to say that.  But that last claim shouldn't be so easy or natural to
make, since if I'm wrong the user will suffer.


From cassels@cambridge.apple.com Sat Oct 10 12:51:18 1992
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23774; Sat, 10 Oct 92 12:51:18 -0400
Full-Name: Bob Cassels
Message-Id: <9210101651.AA23774@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Sat, 10 Oct 1992 12:56:20 -0400
To: info-dylan@cambridge.apple.com, "pierce" <pierce@at-ms-mail-server>
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: Dylan FFI

>David Moon writes:
>
>>>Dylan programs need good access to the facilities that are out there in the
>>>system, and that it must be possible, efficient, convenient, and natural to
>>>write applications in a mixture of Dylan and other languages. 
>
>I realize this is an implementation issue, but can someone comment on how
>Apple's Dylan implementation handles this issue of hybrid programming.

These would be product issues, which is why no one can comment on them
beyond Dave's motherhood-and-apple-pie statements.  I would expect the
answers to your questions to change over time, as implementations mature
and as computing platforms change.  Certainly all the alternatives you
mention are possible, and none seem mutually exclusive (ignoring resource
constraints).  It wasn't immediately obvious from your questions whether
you had an opinion about what the right options would be for your intended
uses.

>Will a future Apple Dylan implementation be directly linkable in the MPW
>environment, or will Dylan require that foreign code be loaded into it like
>current Lisp implementations do?
>
>Does having good access to facilities that are out there in the system mean the
>ability to call traps, or does it mean that Dylan programs should be able to
>take advantage of foreign coded libraries without building code resources out
>of them?
>
>More Specifically, Will some future desktop Dylan implementation support access
>to MacApp or Bedrock?


From jbeekman@prodigy.bc.ca Sat Oct 10 14:03:08 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25060; Sat, 10 Oct 92 14:03:08 -0400
Received: from relay.cdnnet.ca by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10719; Sat, 10 Oct 92 14:11:04 -0400
	for info-dylan@cambridge.apple.com
Received: from prodsql.prodigy.bc.ca by relay.CDNnet.CA (4.1/1.14)
	id AA18374; Sat, 10 Oct 92 11:07:32 PDT
Received: from [192.75.166.22] (jupiter) by prodsql.prodigy.bc.ca (4.1/SMI-4.1)
	id AA13369; Sat, 10 Oct 92 11:08:00 PDT
Date: Sat, 10 Oct 92 11:08:00 PDT
Message-Id: <9210101808.AA13369@prodsql.prodigy.bc.ca>
To: info-dylan@cambridge.apple.com
From: jbeekman@prodigy.bc.ca
Subject: sets and bags

The dylan book states:
'all collections in Dylan are "keyed" collections...this choice precludes
pure sets...although it is straightforward to simply ignore the keys for a
collection...'
Why was this particular choice made?  There does not appear to be anything
in the interface for <collection> which would preclude pure Sets, or Bags
for that matter.
Smalltalk provides Sets and they are very useful (Bags less so in my
opinion).  Set semantics are often what is needed and using a keyed
collection seems wasteful of space.  It also feels wrong in the sense that
a keyed collection is not the abstraction desired.

Joerg 


From fpr!fpr.com!jim@uu.psi.com Sat Oct 10 18:30:26 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29392; Sat, 10 Oct 92 18:30:26 -0400
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11027; Sat, 10 Oct 92 18:38:20 -0400
	for info-dylan@cambridge.apple.com
Received: from fpr.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA14219; Sat, 10 Oct 92 18:31:29 -0400
Message-Id: <9210102231.AA14219@uu.psi.com>
Received: by fpr (Mac/gnuucp v6.01) Sat, 10 Oct 1992 18:26:22 EDT
Date: Sat, 10 Oct 1992 18:21:52 -4
From: jim@fpr.com (James E. O'Dell)
Reply-To: jim@fpr.com
To: cassels@cambridge.apple.com
Subject: Re: small integers
Cc: moon@CAMBRIDGE.APPLE.COM, info-dylan@CAMBRIDGE.APPLE.COM
X-Mailer: Mac/gnuucp Mail Reader v6.02
Organization: Fort Pond Research

On Sat, 10 Oct 1992, Robert A. Cassels <cassels@cambridge.apple.com>
wrote:
>>whether the compiler is smart enough to figure this out as well.  In
>>practice, people just say "fixnum" and then complain about how slow
>>arithmetic is in Lisp.  It's infinitely easier just to say, one way or
>>another, that you don't believe overflows will occur in a certain part
of
>>the program, and that you want to get an error signal if you're wrong.
>
>This part succinctly captures the dilemma as I see it.  We all agree
that
>we want fast, efficient, robust code.  And we want it to be easy for the
>programmer to write such code.  Ideally we'd like the compiler and
runtime
>to be simple and easy to implement.  A machine that implements integer
>arithmetic "in the instruction set" (c.f. Lisp machines) satisfies the
>constraints nicely.  For most special-purpose C/Fortran machines, the
set
>of constraints can't be satisfied, and something has to give.

I see the dillema slightly differently. I'd love to write mathematical
simulations
using "correct" arithmetic. Unfortunately, its impossible, since any" real"
simulation
program that I write runs much too slowly in lisp. For all of its faults,
FORTRAN is still 
extremely efficient for writing number crunching code that marches over
large arrays.

Until a Dylan or Lisp implementation can DEMONSTRATE equivalent efficiency,
I don't
believe it will be taken seriously by your target audience.

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Sat Oct 10 19:11:40 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29851; Sat, 10 Oct 92 19:11:40 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11099; Sat, 10 Oct 92 19:19:39 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210102319.AA11099@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa04160; 10 Oct 92 19:15:23 EDT
To: "Robert A. Cassels" <cassels@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Sat, 10 Oct 92 12:07:35 -0500.
             <9210101602.AA22614@cambridge.apple.com> 
Date: Sat, 10 Oct 92 19:15:07 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    So I personally would prefer a system where the default was to do
    arithmetic as mathematically as possible, because that's the way I'd like
    to think about the problem.  [If I wanted everything mod 32, I'd say that.]
     Then the question is how to make it as easy as possible for me to write
    code that the compiler can turn into efficient machine instructions.  I
    would like the compiler to figure out as much as it can about integer
    ranges.  In cases where I know something about the range, I should have
    easy, natural ways to give the compiler that information.  If I'm willing
    to claim without any proof that the integer won't overflow, I should have a
    way to say that.  But that last claim shouldn't be so easy or natural to
    make, since if I'm wrong the user will suffer.
    
Well, I have to agree with most of that except the last sentence.  If we
must choose between robustness (rolling over into bignums) or maximum
efficiency (no bignums and risk an overflow) as the default for programs
written in the most obvious, naive way, the it's politically correct to
choose robustness as the default.

There is a question of degree, however.  We're not talking about just a
little bit of efficiency here.  Declaring everything is sight to be fixnum
is one of the most important ways to improve your code speed in common
lisp.  This often makes a very dramatic difference.  And in this case I
think we are talking about just a little bit of added robustness.
Programmers often talk about the importance of robust code and then, when
the chips are down, go use whatever awful tool gives them the best
speed.

I've got no problem with making robustness the default, as long as I can
*easily* get C-like efficiency (no bignums, thank you very much) when
that's what is most important to me.  If you make that hard in Dylan -- for
my own good, of course -- then I'm liable to go use C instead.  (Well, OK,
*I* won't, but many programmers will...)

Speaking just for myself (Rob is off at the ASPLOS conference), I've come
around to the view that something like Jeff Piazza's proposal is the best
compromise in terms of meeting all the goals people have expressed.  The
default action for arithmetic could be "correct", with the compiler doing
whatever is possible (usually not much) to make the code efficient, based
on the user's declarations.  But there would also be a big switch -- a
declaration or whatever -- that would allow you to choose fixnum arithmetic
(with overflow checking) for some chunks of your program.  And there would
be specialized fix+ and int+ operations that could be used by programmers
who need fine-grained control over the behavior of integer arithmetic.

This seems to meet most of the needs that have been expressed so far.
There is only one integer whose value is 5.  For naive users, correct
arithmetic is the default.  Discussion of the big switch and the
specialized arithmetic functions can be in a section of the manual reserved
for people who want to worry about "micro-tuning".  On the other hand,
people who want maximum no-bignums efficiency can get it with a single
declaration -- no need to write a thousand arcane integer-range
declarations and THE statements.  And people who really feel the need to
mix bignum arithmetic with a fixnum-only loop counter can get that by using
the more specialized functions.

A few details:

I don't think it will work to make + a macro.  It needs to be a generic
function that dispatches on its argument types.  It is the integer method
for binary+ that must somehow turn into different compiled code depending
on some declaration.

Before someone suggests it, I don't like the idea of making + use "correct"
maybe-bignum semantics in all situations, forcing the user to write fixnum+
to get the more efficient fixnum-only form.  Some users will wirte a lot of
fixnum-only code, and we shouldn't force them to make their code ugly in
this way.  So I think the big switch that affects the interpretation of +,
-, and friends is an important feature of this proposal.

I like the names <fixnum> and <bignum> for the two sub-classes of
<integer>, rather than <short-integer> and <long-integer>.  Users would
hardly ever type <bignum>, but would often declare variables to be of type
<integer> or <fixnum>.  I think that <short-integer> is too verbose, and it
seems a bit second-class.  People might not use it when they should.  But
this is just a preference, not a big issue.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From kab Sat Oct 10 19:37:35 1992
Received: from [90.223.0.20] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00459; Sat, 10 Oct 92 19:37:35 -0400
Full-Name: Kim Barrett
Message-Id: <9210102337.AA00459@cambridge.apple.com>
Date: Sat, 10 Oct 92 19:40:45
From: kab (Kim Barrett)
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Subject: Re: small integers 
Cc: "Robert A. Cassels" <cassels@CAMBRIDGE.APPLE.COM>,
        info-dylan@CAMBRIDGE.APPLE.COM

> Before someone suggests it, I don't like the idea of making + use "correct"
> maybe-bignum semantics in all situations, forcing the user to write fixnum+
> to get the more efficient fixnum-only form.  Some users will wirte a lot of
> fixnum-only code, and we shouldn't force them to make their code ugly in
> this way.  So I think the big switch that affects the interpretation of +,
> -, and friends is an important feature of this proposal.

Define a module that imports the Dylan module variable "+" under the name 
"generalized+" and the Dylan module variable "fix+" as "+" ...

From ses@SunSite.unc.edu Sat Oct 10 20:40:57 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01809; Sat, 10 Oct 92 20:40:57 -0400
Received: from SunSite.unc.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11226; Sat, 10 Oct 92 20:48:54 -0400
	for moon@cambridge.apple.com
Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88)
	id AA26238; Sat, 10 Oct 92 20:44:39 EDT
Message-Id: <9210110044.AA26238@SunSite.unc.edu>
To: Rob_MacLachlan@lisp-pmax1.slisp.cs.cmu.edu
Cc: "David A. Moon" <moon@cambridge.apple.com>, info-dylan@cambridge.apple.com
Subject: Re: small integers 
In-Reply-To: Your message of "Sat, 10 Oct 92 00:09:22 EDT."
             <9210100413.AA10107@brazil.cambridge.apple.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 10 Oct 92 20:44:35 -0400
From: Simon Spero <ses@SunSite.unc.edu>

One idea I had for dealing with fixnums overflowing and either turning into
bignums, or signaling and exception was to use the concept of retry handlers;
there could be a pair of retry handlers, one of which would convert the 
result to a bignum and return, the other of which would just re-raise the
condition. The programmer could select which handler he wanted active; the
protocol in force should be determinable statically in most cases.

Another possibility is to add a new pseudo-numeric type called 'long'; this
would be an abstract modelling of a fixed length sequence of binary variables
whose length is precisely equal to the number of bits in the physical
machine's long word. Various operations, such as treating these objects 
as representing binary numbers and performing logical operations, such as
addition modulo 2^k-1 could also be defined, and to save keystrokes, bound
to some single character generic function such as, to pick one out of the hat,
+, in much the same way as + is often used to indicate sequence concatenation.

Of course, such a type would need quite a lot of boxing analysis, but since
we're going to have to do that for floats anyway, we might as well get some
mileage out of our code!
 
Simon

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Sat Oct 10 22:20:21 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03098; Sat, 10 Oct 92 22:20:21 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11307; Sat, 10 Oct 92 22:28:20 -0400
	for kab@cambridge.apple.com
Message-Id: <9210110228.AA11307@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa04228; 10 Oct 92 22:24:22 EDT
To: Kim Barrett <kab@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Sat, 10 Oct 92 19:40:45.
             <9210102337.AA00459@cambridge.apple.com> 
Date: Sat, 10 Oct 92 22:24:16 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    Define a module that imports the Dylan module variable "+" under the name 
    "generalized+" and the Dylan module variable "fix+" as "+" ...


Hmmm...maybe.  There would be a bunch of substitutions to make in the
module header -- not just +.

The problem is to make this easy enough so that the C programmers will feel
that they can get the efficient policy they want without a lot of
complicated gyrations.  This kind of module hackery is certainly more
hassle than just changing the overflow policy with a declaration, but maybe
it can be turned into a no-brainer -- just insert this magic header and the
module becomes fixnum-only.  It would be essential to pre-define all the
generic functions for fixnum-only arithmetic, and to make sure the compiler
understands what to do with them.

A disadvantage is that the whole module would have to have a single default
policy for overflow-handling.  You couldn't switch back and forth for
certain critical functions.  But maybe that's OK.

I'm not crazy about this way of doing it, but it could work.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Sat Oct 10 22:34:27 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03258; Sat, 10 Oct 92 22:34:27 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11345; Sat, 10 Oct 92 22:42:27 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210110242.AA11345@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa04236; 10 Oct 92 22:38:33 EDT
To: Simon Spero <ses@SUNSITE.UNC.EDU>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Sat, 10 Oct 92 20:44:35 -0500.
             <9210110044.AA26238@SunSite.unc.edu> 
Date: Sat, 10 Oct 92 22:38:31 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    One idea I had for dealing with fixnums overflowing and either turning into
    bignums, or signaling and exception was to use the concept of retry handlers;
    there could be a pair of retry handlers, one of which would convert the 
    result to a bignum and return, the other of which would just re-raise the
    condition. The programmer could select which handler he wanted active; the
    protocol in force should be determinable statically in most cases.
    
I don't think this will work.  The fact that a function will return only a
fixnum, if it returns anything at all, must be known at compile time if you
are to generate optimal code.  Handlers are established dynamically, not
lexically, so the compiler could not be sure what policy would be in effect
when a function is called.

I don't understand your other suggestion.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From ses@SunSite.unc.edu Sat Oct 10 23:44:33 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04448; Sat, 10 Oct 92 23:44:33 -0400
Received: from SunSite.unc.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11422; Sat, 10 Oct 92 23:52:33 -0400
	for info-dylan@cambridge.apple.com
Received: from localhost.oit.unc.edu by SunSite.unc.edu (4.1/TAS/11-16-88)
	id AA27010; Sat, 10 Oct 92 23:48:11 EDT
Message-Id: <9210110348.AA27010@SunSite.unc.edu>
To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu
Cc: info-dylan@cambridge.apple.com
Subject: Re: small integers 
In-Reply-To: Your message of "Sat, 10 Oct 92 22:38:31 EDT."
             <9210110238.AA26899@SunSite.unc.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 10 Oct 92 23:48:10 -0400
From: Simon Spero <ses@SunSite.unc.edu>

   Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU writes:

>I don't think this will work.  The fact that a function will return only a
>fixnum, if it returns anything at all, must be known at compile time if you
>are to generate optimal code.  Handlers are established dynamically, not
>lexically, so the compiler could not be sure what policy would be in effect
>when a function is called.

What I was thinking off was trying static analysis to determine which handler
would be in force for a given function; if it can be shown that for all 
invocations the error re-raising version is in force, then one can deduce 
that the only valid return type is fixnum; if this cannot be shown, then 
we're back where we started. This analysis could be simplified by using  some
macro (with-small-integers &rest body),sorry, #rest; force of habitr, which
would set the hander appropriately. The same goes for the bignum version.

The  idea is that the compiler would treat these handlers as special cases
and generate the same code as before when the chosen policy is known at 
compile time.

The advantage of this method is that it doesn't introduce any strange new 
semantics; bignums are generated by overflows triggering an exception/retry 
like mechanism in nearly all implementations now (did it overflow? jump to
bignum code). It's more flexible that the either/or solutions, and is 
conceptually pretty simple.

The big disadvantages are that if the analysis fails, then the result type
is no longer known exactly, and overflowing bignums may cost an extra  
function call. Another hassle is that this introduces yet another potential
place to split. There's probably a show-stopper in there, but I can't quite
see it.
>
>I don't understand your other suggestion.

Well, I was trying to be obfuscuated, but I guess I over did it; what I was 
really doing (I think - it's getting early this side of the pond) was suggesting
a name for the previously proposed machine-length 'integer'; by calling it
'long', programmers who are used to 'C' will automatically intuit its 
non-numeric properties. The usual problems of boxing and unboxing still apply,
but static analysis can get rid of most redundant box/unbox pairs. 

'long' would not be a replacement for the existing integer types; it would 
be an additional integer like type for use by the mathematically impure.

Simon


From zilla@ccrl.nj.nec.com Sun Oct 11 01:49:19 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05214; Sun, 11 Oct 92 01:49:19 -0400
Received: from research.nj.nec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11529; Sun, 11 Oct 92 01:57:15 -0400
	for info-dylan@cambridge.apple.com
Received: by research.nj.nec.com (4.0/YDL1.8-920115.13)
	id AA03355(research.nj.nec.com); Sun, 11 Oct 92 01:53:31 EDT
Received: by overdrive.ccrl.NJ.NEC.COM (4.1/EMS1.6-920330.08)
	id AA13649(overdrive.ccrl.NJ.NEC.COM); Sun, 11 Oct 92 01:53:33 EDT
Date: Sun, 11 Oct 92 01:53:33 EDT
From: zilla@ccrl.nj.nec.com	(John Lewis)
Message-Id: <9210110553.AA13649@overdrive.ccrl.NJ.NEC.COM>
To: scheme@mc.lcs.mit.edu
Subject: scheme/dylan (was Compilation on SPARC)
Cc: info-dylan@cambridge.apple.com

> From: Scott Schwartz <schwartz@roke.cs.psu.edu>
> Subject: Compilation on SPARC
>
> rpg@cs.tulane.edu (Robert Goldman) writes:
>
>   why hasn't anyone else?
>
> My (quite possibly incorrect) observation is that, for most people's
> purposes, an interpreter adequate.  Most people who use scheme seem to
> be either
> 
>  1) doing research on programming languages.  unless they are researching
>     optimization techniques there is no point in writing a compiler at all,
>     and if they are, only one platform is necessary.
> 
>  2) teaching intro cs classes
> 
>  3) using scheme as an embedded command language.
> 
> Only a very small number of scheme developers seem interested in using
> scheme do to actual systems and application programming.  (If I'm
> wrong about that, post lots of messages here!)  I wonder if an
> advantage of Dylan will be that its user community will have different
> goals than the scheme community.

I agree with this.  There should be a language suitable
for programming language research and teaching the issues of
programming language design.  Such a language needs to be free to
change, and to adopt constructs which may not be efficient at
the present time, in the view of some (this is how I view scheme's
numerical system!).  These characteristics are the opposite of those
desired of a 'real' or 'utility' language, i.e., stability and efficiency.

Dylan is aimed at developing 'real' applications, so the burden on 
scheme is now reduced.  I hope Dylan catches on.  Mail to info-dylan
from Rob MacLachlan indicates that a high performance Dylan implementation
is being developed at CMU.  Given the CMU role/experience with Common Lisp
and the possible efficiency of Dylan,  I am greatly looking forward to this.

Although CL, scheme, and dylan should probably be considered as 
having more differences than e.g. C and Pascal, thanks to their macro
systems it should not be too hard to port moderate amounts of
code to Dylan when it becomes available.

j.p.lewis/nec c&c research

From Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU Sun Oct 11 02:29:27 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05769; Sun, 11 Oct 92 02:29:27 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11580; Sun, 11 Oct 92 02:37:25 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210110637.AA11580@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa04370; 11 Oct 92 2:33:48 EDT
To: John Lewis <zilla@CCRL.NJ.NEC.COM>
Cc: scheme@MC.LCS.MIT.EDU, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: scheme/dylan (was Compilation on SPARC) 
In-Reply-To: Your message of Sun, 11 Oct 92 01:53:33 -0500.
             <9210110553.AA13649@overdrive.ccrl.NJ.NEC.COM> 
Date: Sun, 11 Oct 92 02:33:36 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    Dylan is aimed at developing 'real' applications, so the burden on 
    scheme is now reduced.  I hope Dylan catches on.  Mail to info-dylan
    from Rob MacLachlan indicates that a high performance Dylan implementation
    is being developed at CMU.  Given the CMU role/experience with Common Lisp
    and the possible efficiency of Dylan,  I am greatly looking forward to this.
    
I'd better clarify this before the rumors get out of control.  Rob
MacLachlan somewhat overstated the situation in his earlier note.  We in
the CMU Common Lisp project are very much interested in Dylan, but right
now we're engaged only in some preliminary exploration and some kibitzing
on the language design.

We *hope* to mount an effort that will, among other things, produce a
widely available, high-performance implementation of Dylan using much of
the technology that is currently in our Python compiler for Common Lisp
(plus maybe some new tricks).  However, this depends on our ability to put
together the funding and other resources to support such an effort.  We
think that this should be possible, but it is by no means certain at this
point.  We'll let people on this list know when and if our project becomes
more than an exploratory bootleg effort.

We are greatly looking forward to this as well.  I think it culd help Dylan
to "catch on" in several important niches.  I hope it works out that way.

-- Scott
===========================================================================

Scott E. Fahlman
CMU Common Lisp Project (fearless leader)
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From rwk@crl.dec.com Sun Oct 11 21:14:47 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18907; Sun, 11 Oct 92 21:14:47 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12431; Sun, 11 Oct 92 21:22:53 -0400
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA19496; Sun, 11 Oct 92 21:19:16 -0400
Received: by easynet.crl.dec.com; id AA26895; Sun, 11 Oct 92 21:19:14 -0400
Message-Id: <9210120119.AA28848@taunton.crl.dec.com>
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Cc: Simon Spero <ses@SUNSITE.UNC.EDU>, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of "Sat, 10 Oct 92 22:38:31 EDT."             <9210110242.AA11345@brazil.cambridge.apple.com> 
Date: Sun, 11 Oct 92 21:19:12 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Sat, 10 Oct 92 22:38:31 -0400
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    
        One idea I had for dealing with fixnums overflowing and either turning into
        bignums, or signaling and exception was to use the concept of retry handlers;
        there could be a pair of retry handlers, one of which would convert the 
        result to a bignum and return, the other of which would just re-raise the
        condition. The programmer could select which handler he wanted active; the
        protocol in force should be determinable statically in most cases.
        
    I don't think this will work.  The fact that a function will return only a
    fixnum, if it returns anything at all, must be known at compile time if you
    are to generate optimal code.  Handlers are established dynamically, not
    lexically, so the compiler could not be sure what policy would be in effect
    when a function is called.

Right.  To explain further, an important part of fixnum compilation
is that the consumer of the operation is then allowed to not check
for receiving a bignum.

However, extracting out the kernal of the idea....

I could imagine a macro which compiles a block of code both ways,
and restarts the computation using the generic code if it gets
an overflow.  (Side effects outside the scope would have to be
restricted).

One other comment:  Bob Cassels says:
    If I'm willing
    to claim without any proof that the integer won't overflow, I should have a
    way to say that.  But that last claim shouldn't be so easy or natural to
    make, since if I'm wrong the user will suffer.

I think it is critical that this be easier to say, than the more
usual thing, which is to do the calculation wrong, and never
tell the user he's working with corrupt data.  In my theology
of programs, the lowest level of hell is occupied by programs
which appear to do useful work, but actually just lie to you,
especially unpredictably.

As bad as crashing & burning is from the user standpoint, it
is preferable to hidden failure.

Rather than pure declarations that remove safety in favor of
speed, I'd rather see type assertions, that let the user say
"Don't let anything larger than 1024 past here", and which
the compiler can then use to make type inferences, but which
will signal if this is violated.

If you do your checking outside the loop, it is really very
rare that you can't afford to do range checking!

I really think that multiple compilation is a more viable
approach than most people think.  The amount of code involved
in this sort of issue is trivial except in special memory-limited
situations.  Again, it only makes sense to do this sort of
optimization on small pieces of your code.

It's usually better to get the speed improvement by changing
the algorithm, instead.  Provide tools that let the developer
see just where bignums are being used under different circumstances,
and let him write algorithms that don't need large numbers to
get the job done.

Another possibily useful technique is to provide 64-bit integers
for use in interior calculations, and provide ways to store
these.  This then boils down to the same set of issues as
unboxed floating-point.  I find it difficult to imagine an
algorithm "accidentally" overflowing 64 bits.

From gary@dreyfuss.portal.com Mon Oct 12 12:15:34 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00132; Mon, 12 Oct 92 12:15:34 -0400
Received: from NOVA.UNIX.PORTAL.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13266; Mon, 12 Oct 92 12:23:43 -0400
	for info-dylan@cambridge.apple.com
Return-Path: <gary@dreyfuss.portal.com>
Received: by nova.unix.portal.com (5.65b/4.1 1.161) 
	id AA19076; Mon, 12 Oct 92 09:20:13 -0700
Received: by portal.unix.portal.com (1.344) 
	id AA24590; Mon, 12 Oct 92 09:20:11 -0700
Received: by dreyfuss.dreyfuss.portal.com (NX5.67c/NeXT-2.0)
	id AA01192; Mon, 12 Oct 92 00:42:18 -0700
Date: Mon, 12 Oct 92 00:42:18 -0700
From: gary@dreyfuss.portal.com (Gary Lang)
Message-Id: <9210120742.AA01192@dreyfuss.dreyfuss.portal.com>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: info-dylan@cambridge.apple.com
Subject: Add

Please add me to this list.

-g

From moon Tue Oct 13 17:13:10 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14754; Tue, 13 Oct 92 17:13:10 -0400
Full-Name: David Moon
Message-Id: <9210132113.AA14754@cambridge.apple.com>
Date: Tue, 13 Oct 92 17:17:28 EDT
From: moon (David A. Moon)
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Subject: Re: small integers 
Cc: info-dylan

> Date: Sat, 10 Oct 92 02:33:59 -0400
> From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
> ....  At times you
> seem to favor the "correct" Common Lisp approach, and at other times you
> seem to accept the idea of an overflow error under certain conditions.

I think I have consistently said that I favor an overflow error when it is a
type error, that is, when it can be shown that if a bignum were created from 
the overflow it would cause a type error before the next observable 
side-effect.

I think (but I'm not sure about this part) that an overflow in the middle of
a complex arithmetic expression can often be shown either to cause an overflow
at the end (and thus we can reason backwards that it is a type error) or be
handled by using increased precision for the intermediate results in the
arithmetic expression, without going beyond the precision the machine 
supports.  Think about (* (+ x y) z) where we know they are all small integers 
and z is not 0 or -1, and the result is being fed to something that only 
accepts small integers.

More later.

From moon Tue Oct 13 17:13:22 1992
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14763; Tue, 13 Oct 92 17:13:22 -0400
Full-Name: David Moon
Message-Id: <9210132113.AA14763@cambridge.apple.com>
Date: Tue, 13 Oct 92 17:17:41 EDT
From: moon (David A. Moon)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>,
        Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Subject: Re: associative methods
Cc: info-Dylan

> Date: Sun, 4 Oct 1992 19:55:21 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> 
> In Dylan there are a number of method's that take an unlimited number
> of arguments and convert to `binary' methods (e.g., = translates to
> binary=).  Unfortunately, there is no way for a user to define their
> own and I'm positive that users are going to want their own.  Sure,
> one can simulate this conversion, but it is inefficient (i.e., conses
> #rest list on heap and is performed at run-time).
> 
> One way to make this facility available to users would be to introduce
> a new construct such as `define-associative-method' for this facility.
> 
> Date: Mon, 05 Oct 92 01:56:37 -0400
> From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
> 
> In my opinion, your proposed solution is too specialized and doesn't get to
> the heart of the problem.  The real problem is that the #rest machinery is
> inherently expensive to use, since it is defined as creating a sequence at
> runtime.  The proverbial SSC ("sufficiently smart compiler") could prove in
> many cases that the sequence is confined within the method's dynamic extent
> and can therefore be stack-allocated, but I think that users will become
> confused and anxious about which cases heap-allocate and which don't.
> 
> For cases like + and =, in which an unlimited number of arguments are
> consumed locally, I like the idea of providing some mechanism like the old
> Maclisp LEXPRs.

I don't think making small improvements in the rest argument mechanism is a 
good way to tackle this problem.  Much better is to compile out all of the rest argument processing and remove the extra level of function call entirely.

This can be done without going outside the existing Dylan language, so long as 
there is a way for the compiler to know which functions are safe to compile 
inline.  For example (using the Common Lisp way to tell that to the compiler):

  (declaim (inline +))

  (define + (method (#rest numbers)
              (if (empty? numbers) 0 (reduce1 binary+ numbers))))

If the built-in generic function reduce1 is sufficient sealed that the compiler knows what it does with those arguments, that's enough information for the compiler to convert calls to + into calls to binary+, with no runtime overhead.  In (+ a b c), it knows numbers is a 3-element sequence of the values of a, b, and c, and it inlines the if, empty?, and reduce1, yielding

  (binary+ (binary+ a b) c)

And of course this technique works just as well for functions defined by the user that are analogous to + and binary+.  This is not an exotic or difficult optimization.

= to binary= is a little trickier since the necessary higher-order function, a 
cross between reduce1 and every?, is not already built into the language.  
However the same principle applies, the higher-order function just has to be 
defined and declaimed inline.  It would go something like this (simplified to work only for lists instead of general sequences, for ease of exposition):

  (declaim (inline pairwise-every?))

  (define pairwise-every?
          (method (function list)
            (bind-methods ((loop (item list)
                             (cond ((empty? list) #t)
                                   ((function item (car list))
                                    (loop (car list) (cdr list)))
                                   (else: #f))))
              (loop (car list) (cdr list)))))

  (declaim (inline =))

  (define = (method (#rest objects) (pairwise-every? binary= objects)))

What about associativity (only mentioned in the subject line!)?  Well, that's a property of binary+ and binary=, not of + and =, and allows further optimization of the inlining.  For example it would allow the transformation

    (binary+ (binary+ a 2) 5) -> (binary+ a (binary+ 2 5)) -> (binary+ a 7)

However, the Dylan book does not say binary+ and binary= are associative, so there might be non-associative user-defined methods and that transformation might not be correct.  But I guess associativity wasn't the real subject of this discussion anyway.

> For example, the arglist might contain "#MORE N", which
> would bind n to the number of arguments that were passed.  Then the method
> can iterate, using some form like (MORE-ARG i) to access each argument i.
> In this case, there would be no runtime consing.  #MORE might replace
> #REST (with the addition of an ARGS-TO-LIST function), or the two could
> coexist as alternative arg-list forms.

To my way of thinking, this partial proposal is just a strange variation on the existing sequence primitives.  more-arg is element except it gets its first argument from a hidden variable.  Instead of adding to the language such a duplicate mechanism, we would be better off all around making the existing mechanism work usefully.  I don't think it's at all difficult for a compiler to detect that the only use of a #rest parameter is as the first argument to the functions size and element, and compile it the same way that your proposal would compile.  In fact we don't need to be that restrictive, we can certainly also allow it to be the last argument to apply and still not materialize a representation of it as one of the standard sequence classes.  Even if these compiler optimizations were difficult, and they're not, I would still think it is a good tradeoff to make compiler implementation more difficult to make use and understanding of the language less difficult.

> I think that users will become
> confused and anxious about which cases heap-allocate and which don't.

Scott, I think the argument you are really making here is an argument against abstraction.  You are saying that any language that is more abstract than C will cause users to become confused and anxious, because they can't see from the source code exactly what the compiled code is going to be.  There is certainly some evidence for this position, but if it's really true, we may as well give up and go home because there is no hope for us.

I would rather believe that properly implemented and supported abstract languages can be successful and deliver real value to the users.  Getting back to optimization of #rest parameters, this means the compiler has to be accountable and transparent (I think your Python compiler at CMU has taken some giant steps in this direction), and surely it also means that a decent development environment must include good performance analysis tools so users can find the real bottlenecks in their program, instead of relying on superstitions such as "rest arguments are slow" which develop in any user community where the implementation is not accountable and there aren't good tools.

To conclude this overlong message:

So instead of adding warts to the language, let's talk about whether we need a 
standardized way to control inlining, or whether sealing takes care of that, 
or whether it should be an implementation-dependent development environment 
feature, or whether the compiler can do it on its own without any additional 
input from the programmer.  After we deal with that, let's talk about ideas for the programmer's interface to the compiler that make the compiler's optimizations transparent and accountable.

From fpr!fpr.com!jim@uu.psi.com Tue Oct 13 23:50:56 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23784; Tue, 13 Oct 92 23:50:56 -0400
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16749; Tue, 13 Oct 92 23:59:16 -0400
	for info-dylan@cambridge.apple.com
Received: from fpr.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA12151; Tue, 13 Oct 92 23:24:35 -0400
Message-Id: <9210140324.AA12151@uu.psi.com>
Received: by fpr (Mac/gnuucp v6.01) Tue, 13 Oct 1992 22:49:05 EDT
Date: Tue, 13 Oct 1992 22:33:27 -4
From: jim@fpr.com (James E. O'Dell)
Reply-To: jim@fpr.com
To: moon@cambridge.apple.com
Subject: Re: small integers
Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, info-dylan@cambridge.apple.com
X-Mailer: Mac/gnuucp Mail Reader v6.02
Organization: Fort Pond Research

On Tue, 13 Oct 92, moon@cambridge.apple.com (David A. Moon) wrote:
>> Date: Sat, 10 Oct 92 02:33:59 -0400
>> From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
>> ....  At times you
>> seem to favor the "correct" Common Lisp approach, and at other times
you
>> seem to accept the idea of an overflow error under certain conditions.
>
>I think I have consistently said that I favor an overflow error when it is
a
>type error, that is, when it can be shown that if a bignum were created
from 
>the overflow it would cause a type error before the next observable 
>side-effect.

I think that you'll find almost every scientific computer designer is in
favor
of that approach. I think that what you'll find is that in a machine with a
sufficiently
complex architecture (vector or multiple instructiuon issue) that you
will
not be able to catch the error when you desire.

>I think (but I'm not sure about this part) that an overflow in the middle
of
>a complex arithmetic expression can often be shown either to cause an
overflow
>at the end (and thus we can reason backwards that it is a type error) or
be
>handled by using increased precision for the intermediate results in the
>arithmetic expression, without going beyond the precision the machine 
>supports.  Think about (* (+ x y) z) where we know they are all small
integers 
>and z is not 0 or -1, and the result is being fed to something that only

>accepts small integers.

Isn't the problem here that "often" isn't good enough? You either have to
detect
the arithmetic error for sure. If you can't get it for sure then you'd just
as well ignore
it like C and let the programmer deal with it as best he can.

Do you intend that Dylan have arithmetic that is "as good as" FORTRAN or
that
it be "almost as good"? I would argue that for general acceptance of the
language
for both political and technical reasons only "as good as" will do.

Jim

From hmadorf@eso.org Wed Oct 14 07:27:28 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02761; Wed, 14 Oct 92 07:27:28 -0400
Received: from ns3.hq.eso.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17104; Wed, 14 Oct 92 07:35:44 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210141131.AA08427@ns3.hq.eso.org>
Received: from localhost.hq.eso.org by ns3.hq.eso.org (4.1/ eso-1.1)
	id AA08427; Wed, 14 Oct 92 12:31:41 +0100
To: info-dylan@cambridge.apple.com
Subject: floating-point efficiency: Lisp vs. Fortran (FYI)
From: hmadorf@eso.org
Date: Wed, 14 Oct 92 12:31:40 +0100
Sender: hmadorf@eso.org

This is a reposting, since apparently something failed previously.
--------------------

I would like to second Jonathan Bacharach's view that floating point
efficiency *is* an important issue, at least for those of us out there
thinking about the future of scientific computing in the nineties.
I would like to base my future work on CL or Dylan or whatever
dialect is en vogue and write software that I can port unchanged
from a scalar processor to a vector processor to a massively
parallel processor. D'you think that's far fetched? No, it is not. 
In the era of mobile computing and low hardware cost (1MB of RAM is
cheaper than 2 lines of code) we will increasingly face the
software engineering/portability/maintenance problem.

Here is a cross-posting of a message I posted today on info-mcl. I
would pretty much like language designers to think hard about the
FP-issue. Is science unimportant since there are only so few 
scientists out there (compared to multi-meadia aficionados)?

===============================

Lisp's floating point efficiency
--------------------------------
Simon Spero writes:
>If there's sufficient type information available at compile-time, lisp
>is as fast as fortran. It's only when the types are unknown and you have to
>dispatch at run-time that things really start to slow down.

This does not at all agree with my recent observations. I carried
out the following simple floating-point benchmark: I coded the 
log-factorial function in Fortran-77 and in Lisp (using a simple 
do-loop). The algorithm simply sums up all the log-terms. (The code
is available on request.) I executed the code using

MacTran    & Mac SE/30
MCL        & Mac SE/30
f77	   & Sun Sparc2
Allegro CL & Sun Sparc2

Two versions of the CL code were tested, one without declarations,
the other fully spiced with declarations. The CL-code was compiled
with (speed 3) optimization. The Fortran code was not particularly
optimized. My observations:

1. Declarations had little influence on CL-execution efficiency.
2. The availability of the FP-coprocessor in the SE/30 (as opposed
   to the SE) made a big difference.
3. The Fortran code ran consistently 5 times faster on both hardware
   platforms.
4. The Sparc2 with Allegro CL was about as fast as the SE/30 with
   MacTran.

The most striking thing is the consistency across the compilers and
hardware platforms, almost ruling out any trivial explanation
(such as "the log function is particularly inefficiently implemented
in MCL" or things alike).

I am quite prepared to carry the comparison further, but (despite
the fact that I love Lisp and do all work possible in it) my 
conclusion for the moment is: I cannot recommend Lisp for number
crunching when a simple algorithm is executed for utmost speed.

I recently brought up the Lisp vs. Fortran efficiency issue on the 
info-mcl network. Someone called the comparison foolish, but I do not
think it is. In any case I have not received code or immediate hints that
would invalidate my conclusions above. (I still have to check out 
the optimization document in the /contrib directory in the Apple 
archive.)

Two wishes:

1. I would like to see others report their experience on
FP-efficiency in order to see whether a consensus emerges.

2. I would also like to have the MCL developers pay attention to the
"floating point efficiency issue" as *the* selling/repelling argument 
for many scientists. Advocating all the other nice features (we all
appreciate) that Lisp possesses will not make them turn away from their
beloved, primitive, but veeeeeery fast Fortran, I'm afraid. 


Lisp for scientific computing
-----------------------------
I am delighted about the discussion on Lisp for scientific
computation (which is almost invariably taken to be numeric). Right
now the discussion centres on whether Dylan should incorporate
enough to make it an interesting language to those engaged in 
scientific computing (as I am).

I am currently trying to influence the attitude of my colleagues 
(working mainly in astronomy), and make them aware of the advantages 
of Lisp vs. Fortran or even C, but I need convincing arguments not
strong convictions!

One argument that I have in my pockets is that Lisp is easy to
vectorize. (I have vectorized the whole Lisp language with a few 
macros and the help of CLOS.) The four fundamental arithmetic 
oprators +, -, * and / and all single argument functions operate on 
scalars, lists, vectors and arrays and even on some mixtures of these.
(Is that what some guys call "threading"?)

I am planning to interface this nice language to the Intel i860
vector processor in the backplane of my Sun in order to get the
FP-performance that I cannot squeeze out of Lisp otherwise. (I have
a statistical classifier that is supposed to operate on large data 
sets and that is an ideal algorithm for this kind of vectorization.)

If anyone is interested in the topics above, please contact me in
order to foster exchange of views and experience.

Hans-Martin Adorf

ST Data Analysis Scientist
Space Telescope - European Coordinating Facility
European Southern Observatory
Garching bei Muenchen, FRG

Internet: adorf@eso.org
------- End of Forwarded Message


From jeff@aiai.edinburgh.ac.uk Wed Oct 14 10:31:54 1992
Received: from goofy.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11288; Wed, 14 Oct 92 10:31:54 -0400
Received: from apple.com by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef)
	id AA10363; Wed, 14 Oct 92 07:36:42 -0700
	for info-dylan@cambridge.apple.com
Received: from sun2.nsfnet-relay.ac.uk by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA25312; Wed, 14 Oct 92 07:36:30 -0700
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Wed, 14 Oct 1992 15:34:15 +0100
Date: Wed, 14 Oct 92 15:36:12 BST
Message-Id: <29032.9210141436@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: floating-point efficiency: Lisp vs. Fortran (FYI)
To: info-dylan@cambridge.apple.com,
        hmadorf <@brazil.cambridge.apple.com:hmadorf@eso.org>

> Two versions of the CL code were tested, one without declarations,
> the other fully spiced with declarations. The CL-code was compiled
> with (speed 3) optimization. The Fortran code was not particularly
> optimized. My observations:
> 
> 1. Declarations had little influence on CL-execution efficiency.

I have seen a large effect in some cases such as, say, summing
or scaling rows and columns of a matrix.  Some possibilities:

  * The CL you're using doesn't optimize floating point very well.

  * It optimizes floating point fairly well even without declarations
    so that declarations don't make a big difference.

  * Some potential optimizations aren't performed because of the
    way you wrote your code.  (Eg, perhaps you didn't specify
    result types using something like (THE DOUBLE-FLOAT ...).)

  * Your code does things that can't (easily?) be optimized.
    (For instance, it's hard for an implementation to avoid
    heap-allocating floats when passing them to a global procedure.)

  * You're using a non-primitive floating point operation that
    isn't implemented very well.  (For instance, I wouldn't be
    surprised if the log function was inefficiently implemented
    in several Common Lisps.)

  * You're doing some other thing, in addition to fp operations,
    that's inefficient.

-- jd

From cassels Wed Oct 14 11:22:16 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13254; Wed, 14 Oct 92 11:22:22 -0400
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13248; Wed, 14 Oct 92 11:22:16 -0400
Message-Id: <9210141522.AA13248@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Wed, 14 Oct 1992 11:27:39 -0400
To: moon@cambridge.apple.com, jim@fpr.com
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: small integers
Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, info-dylan@cambridge.apple.com

>Do you intend that Dylan have arithmetic that is "as good as" FORTRAN or
>that
>it be "almost as good"? I would argue that for general acceptance of the
>language
>for both political and technical reasons only "as good as" will do.

For someone's definition of "good".


From info-dylan-request Wed Oct 14 15:53:13 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19519; Wed, 14 Oct 92 15:53:17 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19512; Wed, 14 Oct 92 15:53:13 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18280; Wed, 14 Oct 92 16:01:41 -0400
	for moon@cambridge.apple.com
Message-Id: <9210142001.AA18280@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa07010;
          14 Oct 92 15:57:25 EDT
To: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Tue, 13 Oct 92 17:17:28 -0500.
             <9210132113.AA14754@cambridge.apple.com> 
Date: Wed, 14 Oct 92 15:57:13 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


    I think I have consistently said that I favor an overflow error when it is a
    type error, that is, when it can be shown that if a bignum were created from 
    the overflow it would cause a type error before the next observable 
    side-effect.
    
That much was clear.  What wasn't clear to me is whether that means "if and
ONLY if".  In other words, are you still opposed to providing a fixnum-only
switch, or fixnum-only operations, to those who want to operate in that
style.  Reading between the lines, I'll assume that you are.

    I think (but I'm not sure about this part) that an overflow in the middle of
    a complex arithmetic expression can often be shown either to cause an overflow
    at the end (and thus we can reason backwards that it is a type error) 

Yes, but the key word here is "often".  In some cases, the constraint on
the type of the intermediate values is obvious, in some cases the user and
the compiler both have to work pretty hard to satisfy themselves that the
constraint holds, and in some cases it's impossible to get the constraint
you want on an intermediate result without sticking a THE in the middle of
your arithmetic code.

    or be
    handled by using increased precision for the intermediate results in the
    arithmetic expression, without going beyond the precision the machine 
    supports.

This is more efficient that going all the way to bignums, but less
efficient than fixnum-only code.  If you really want that double-precision
operation, fine, but if it's just in there as defensive medicine because
the compiler couldn't *quite* prove that no bignum will appear, then you've
got a language that is less efficient than it should be.  In any case, it
requires a very smart compiler to do this kind of analysis in general.  For
people writing portable code, they have to worry what is going to happen on
the stupidest Dylan compiler that is in general use, not the smartest.

I think we're actually not so far apart.  I'm happy to agree that "correct"
integer arithmetic should be the default.  And I'm willing to agree that,
under the proper circumstances, we can omit overflow errors and signal
errors only on violations of user-specified types.

The "proper circumstance" is that there should be an easy, compact way for
programmers to directly declare the types of all the intermediate results
in some long chain of calculations -- for example, that they are all of
type <fixnum> or are integers within some particular range.  We should not
force users to do this by putting THE statements all through the code,
since this is a big pain and it makes the code nearly unreadable.  Nor
should we require users to come up with some clever, subtle, implicit way of
constraining the intermediate-value types by makign statements about the
ultimate inputs and outputs.

Perhaps a RESTRICT declaration would be the way to go.  (RESTRICT <integer>
<fixnum>) is a type declaration that affects a region of code: a whole
module, part of a module, a single function, or perhaps a block within a
function.  It says that, for the region of code in question, the programmer
is declaring that any <integer> will also be a <fixnum>.  One could
restrict any type A to be a B, as long as B is a subtype of A.  Dave
Touretzky proposed something like this for Common Lisp long ago, but the
idea never got much consideration -- a mistake in my view.

As long as I can make some such blanket declaration of the types I'm using,
then I'm willing to describe everything in terms of types and not overflow
policy.  Admittedly, this is a small extra wart on the current Dylan
definition, but I believe that Common Lisp is paid a very high price for
not including such a wart.

It's a separate question whether we should allow an unsafe compilation
policy that just believes such declarations and omits the type-tests.  I
think we should, but that's because I like languages that encourage good
programming style by making it easy to do the right things; I dislike
languages, like Ada and Pascal, that try to make it hard to do the wrong
thing.  Such unsafe policies should be used very carefully -- if you get it
wrong, Bob Kerns wills end you to the lowest level of hell -- but there are
special situations in which I'm willing to take the chance.  It's OK with
me if nothing like this "unsafe" policy appears in the Dylan spec, as long
as implementations are allowed to include such a policy as a non-standard
extension.

-- Scott

From info-dylan-request Wed Oct 14 16:44:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21068; Wed, 14 Oct 92 16:44:59 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21063; Wed, 14 Oct 92 16:44:57 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18422; Wed, 14 Oct 92 16:53:25 -0400
	for moon@cambridge.apple.com
Message-Id: <9210142053.AA18422@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa07055;
          14 Oct 92 16:49:05 EDT
To: "David A. Moon" <moon@CAMBRIDGE.APPLE.COM>
Cc: info-Dylan@CAMBRIDGE.APPLE.COM
Subject: Re: associative methods 
In-Reply-To: Your message of Tue, 13 Oct 92 17:17:41 -0500.
             <9210132113.AA14763@cambridge.apple.com> 
Date: Wed, 14 Oct 92 16:48:56 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


Dave,

Regarding my #more suggestion.  I guess you're right -- I was being too
conservative on this.  Our compiler (should we get the go-ahead to jump
into this game) will certainly be able to determine whether a #rest
sequence has dynamic extent or not.  It will then be able to generate
optimal non-consing code in most cases, and to warn the user if
unanticipated consing is going to occur.

I was more worried about people who want to write simple compilers on
itty-bitty computers, and about the anxiety of users if they're not sure
just what the compiler will do.  But maybe all Dylan compilers will be
smart enough to do this right, eliminating any need to tamper with #rest
args.  (Or at least, all Dylan compilers used by people who care AT ALL
about efficiency.)
    
I agree that we have to get sealing and inlining right to make this all
work well.
    
So, let's forget about my more-arg suggestion and just make sure that the
various Dylan compilers don't reinforce the myth that rest-args must be
avoided at all costs.

-- Scott
===========================================================================
Scott E. Fahlman
School of Computer Science
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213

Internet: sef+@cs.cmu.edu

From moon Wed Oct 14 18:21:08 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22853; Wed, 14 Oct 92 18:21:11 -0400
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22849; Wed, 14 Oct 92 18:21:08 -0400
Message-Id: <9210142221.AA22849@cambridge.apple.com>
Date: Wed, 14 Oct 92 18:26:32 EDT
From: moon (David A. Moon)
To: jim@fpr.com
Subject: Re: small integers
Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, info-dylan@cambridge.apple.com

> Date: Tue, 13 Oct 1992 22:33:27 -4
> From: jim@fpr.com (James E. O'Dell)
> 
> ...garbled line-wrapped message elided...

When I said "often" I meant that the compiler can often optimize the code, not 
that the code would often return the correct answer.  The infrequent case 
would be slightly slower code that has to do an overflow check, not code that 
returns the wrong answer!

From info-dylan-request Wed Oct 14 22:50:21 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29271; Wed, 14 Oct 92 22:50:23 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29266; Wed, 14 Oct 92 22:50:21 -0400
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19083; Wed, 14 Oct 92 22:58:50 -0400
	for info-dylan@cambridge.apple.com
Received: from fpr.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA22831; Wed, 14 Oct 92 22:35:16 -0400
Message-Id: <9210150235.AA22831@uu.psi.com>
Received: by fpr (Mac/gnuucp v6.01) Wed, 14 Oct 1992 20:31:58 EDT
Date: Wed, 14 Oct 1992 19:52:44 -4
From: jim@fpr.com (James E. O'Dell)
Reply-To: jim@fpr.com
To: cassels@cambridge.apple.com
Subject: Re: small integers
Cc: moon@cambridge.apple.com, Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU,
        info-dylan@cambridge.apple.com
X-Mailer: Mac/gnuucp Mail Reader v6.02
Organization: Fort Pond Research

On Wed, 14 Oct 1992, Robert A. Cassels <cassels@cambridge.apple.com>
wrote:
>>Do you intend that Dylan have arithmetic that is "as good as" FORTRAN
or
>>that
>>it be "almost as good"? I would argue that for general acceptance of
the
>>language
>>for both political and technical reasons only "as good as" will do.
>
>For someone's definition of "good".

Of course what I meant was, "as fast as." I firmly believe that to be
competitive
in your target market that Dylan will have to have a mode that is at least
as
fast as FORTRAN. Not only on isolated FLOPs but on arrays of floats and
fixnums. To do any less will relegate the language to company of basic
and
hypercard.

Jim

From info-dylan-request Wed Oct 14 22:51:54 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29290; Wed, 14 Oct 92 22:51:55 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29286; Wed, 14 Oct 92 22:51:54 -0400
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19105; Wed, 14 Oct 92 23:00:22 -0400
	for info-dylan@cambridge.apple.com
Received: from fpr.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA22895; Wed, 14 Oct 92 22:35:47 -0400
Message-Id: <9210150235.AA22895@uu.psi.com>
Received: by fpr (Mac/gnuucp v6.01) Wed, 14 Oct 1992 20:31:59 EDT
Date: Wed, 14 Oct 1992 20:04:59 -4
From: jim@fpr.com (James E. O'Dell)
Reply-To: jim@fpr.com
To: moon@cambridge.apple.com
Subject: Re: small integers
Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, info-dylan@cambridge.apple.com
X-Mailer: Mac/gnuucp Mail Reader v6.02
Organization: Fort Pond Research

On Wed, 14 Oct 92, moon@cambridge.apple.com (David A. Moon) wrote:
>> Date: Tue, 13 Oct 1992 22:33:27 -4
>> From: jim@fpr.com (James E. O'Dell)
>> 
>> ...garbled line-wrapped message elided...
>
>When I said "often" I meant that the compiler can often optimize the code,
not 
>that the code would often return the correct answer.  The infrequent case

>would be slightly slower code that has to do an overflow check, not code
that 
>returns the wrong answer!

Yeah, thats what I thought you meant. I still think you need a mode that
compiles
arithmetic with complete disregard for correctness. Real numerical types
never trust
a single calculation anyway. There are too many other ways to get
numerical
instabilities in a complicated numerical program. To check a single op for
corrrectness 
in a large code may be seen by many as penny wise and pound foolish.

Many complicated codes are checked for correctness by varying input values

slightly to see if the results are stable. Another method of doing a
sensitivity 
analysis is performing the same calculation in both single and double
precision and 
checking the results for stability.

I don't believe Seymour Cray built his machines the way he did because he
liked
getting incorrect answers.

Jim

From info-dylan-request Thu Oct 15 08:12:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11189; Thu, 15 Oct 92 08:12:20 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11185; Thu, 15 Oct 92 08:12:18 -0400
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19527; Thu, 15 Oct 92 08:20:52 -0400
	for info-dylan@cambridge.apple.com
Received: by world.std.com (5.65c/Spike-2.0)
	id AA22835; Thu, 15 Oct 1992 08:17:13 -0400
Date: Thu, 15 Oct 1992 08:17:13 -0400
From: ferrante@world.std.com (Richard D Ferrante)
Message-Id: <199210151217.AA22835@world.std.com>
To: info-dylan@cambridge.apple.com
Subject: numeric speed

(James E. O'Dell) writes
>Of course what I meant was, "as fast as." I firmly believe that to be
>competitive in your target market that Dylan will have to have a mode
>that is at least as
>fast as FORTRAN. Not only on isolated FLOPs but on arrays of floats and
>fixnums. To do any less will relegate the language to company of basic
>and hypercard.

I don't see any way of doing this without allowing for the
declaration of multidimensional fixed size arrays.  The "convert to
simple vector and compute your own indices" alternative is less than
appealing.


--- 

Richard Ferrante
(617)-739-7055
ferrante@world.std.com
    

From info-dylan-request Thu Oct 15 14:56:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25544; Thu, 15 Oct 92 14:56:17 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25539; Thu, 15 Oct 92 14:56:15 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20366; Thu, 15 Oct 92 15:04:48 -0400
	for moon@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA26033; Thu, 15 Oct 92 15:00:47 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 145956.13568; Thu, 15 Oct 1992 14:59:56 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA02518; Thu, 15 Oct 92 08:57:19 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA02258; Thu, 15 Oct 92 08:57:17 PDT
Date: Thu, 15 Oct 92 08:57:17 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210151557.AA02258@eagle.sharebase.com>
To: jim@fpr.com, moon@cambridge.apple.com
Subject: Re: small integers
Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, info-dylan@cambridge.apple.com

jim@fpr.com (James E. O'Dell), Re: small integers:
/// On Wed, 14 Oct 92, moon@cambridge.apple.com (David A. Moon) wrote:
/// >> Date: Tue, 13 Oct 1992 22:33:27 -4
/// >> From: jim@fpr.com (James E. O'Dell)
/// >>
/// >> ...garbled line-wrapped message elided...
/// >
/// >When I said "often" I meant that the compiler can often optimize the code,
/// not
/// >that the code would often return the correct answer.  The infrequent case
/// >would be slightly slower code that has to do an overflow check, not code
/// that
/// >returns the wrong answer!

Narrowing the concern for notification of corruption of data to numerics may
be creating tunnel-vision, here.  Many different types (classes) can be
verified at run-time, to the great benefit of the developer.

I would like to see some form of contractual programming implemented in Dylan.
This way, when I declare my <SSN> class, I can state that it will contain
ten digits, etc., and at least during prototyping I can compile programs that
automagically check this assertion about what data should be placed in these
structures.

If this were the case, only one additional built-in class would be required
for this numeric problem: <fixnum-only> -- which has a contract specifying it
may never contain a <bignum>...

/// Yeah, thats what I thought you meant. I still think you need a mode
/// that compiles arithmetic with complete disregard for correctness. Real
/// numerical types never trust a single calculation anyway. There are too
/// many other ways to get numerical instabilities in a complicated
/// numerical program. To check a single op for corrrectness in a large
/// code may be seen by many as penny wise and pound foolish.

Having some kind of pragma to toggle run-time value verification is probably
a good idea, at least for production versions of your executable.  This
"contract checking" should be able to be turned off easily, and best if this
is do-able in the invocation of the compiler -- but that might suggest some
need for a notation for conditional compilation, a mechanism which Dylan lacks.

Don't get me wrong on that, though.  Conditional compilation is dangerous to
include in a language.  Not only will it be used to write unreadable (ergo:
unmaintainable) code, but it will permit destandardization of the core
language.

What I'm suggesting is some very limited types of conditional compilation, like
with 'contract checking enabled' and 'contract checking disabled'.

/// Many complicated codes are checked for correctness by varying input
/// values
/// slightly to see if the results are stable. Another method of doing a
/// sensitivity analysis is performing the same calculation in both single
/// and double precision and checking the results for stability.

For a language like FORTRAN, whose compiler writers live to optimize floating
point operations, this is feasible.  For Dylan, it probably isn't.  No
[mainstream] language is as fast as FORTRAN when it comes to number-crunching,
because FORTRAN compilers have always had _very_ good optimizers.  This is
good for a number-crunching language like FORTRAN, but would remove the focus
of Dylan (OOD Programming) from the compiler.

/// I don't believe Seymour Cray built his machines the way he did because
/// he liked getting incorrect answers.

I don't either.  On the other hand, debugging wrong algorithms may not have
been as important in design as getting answers from already working ones.  When
machine-time is more expensive than programmer-time this is an option one has.

/// Jim

	-- Scot

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

P.S.:

	Contract checking suggestions:
	1. Contract method on some class called for class modification.
	   Contract should be included in class (this is great documentation)
	   declaration.  Toggle by class when compiling production images.
	2. Contract clause in methods for result.  Also great documentation.
	3. Explicit in-line contracts are important, too.  Such as
		(must-be <fix-num> (* x y (+ z a)))
		;;; (contract (method (x) (type? x <fix-num>))
		;;;	(* x y (+ z a)))

From info-dylan-request Thu Oct 15 22:58:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04865; Thu, 15 Oct 92 22:58:58 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04861; Thu, 15 Oct 92 22:58:57 -0400
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21329; Thu, 15 Oct 92 23:07:35 -0400
	for info-dylan@cambridge.apple.com
Received: by world.std.com (5.65c/Spike-2.0)
	id AA23882; Thu, 15 Oct 1992 23:03:53 -0400
Date: Thu, 15 Oct 1992 23:03:53 -0400
From: squeegee@world.std.com (Stephen C. Gilardi)
Message-Id: <199210160303.AA23882@world.std.com>
To: info-dylan@cambridge.apple.com
Subject: Default magnitude for <complex> should be 1

Dear info-dylan,

I'm a newcomer to the discussion, so please forgive me if this has 
already been discussed.

On page 148 of the Dylan book, it is specified that:

     (make <complex> :angle a)

is interpreted as:

     (make-polar 0 a)
     
The choice of 0 as the default magnitude seems to me not to be the best 
one.  I think the default magnitude should be 1.

Rationale:

[1] As currently specified, (make <complex> :angle a) is equal to 0
regardless of a.  We don't need another fancy and confusing way to type 0.

[2] It is fairly common when using complex numbers to use a "pure angle"
in the sense of exp(sqrt(-1) * theta).  Defaulting the magnitude to 1
makes (make <complex> :angle theta) accomplish that.

[3] When humans work with complex numbers, rectangular coordinates are easy
to use in additive operations, and polar coordinates are easy to use in
multiplicative operations.  With the mangitude defaulted to 1, the 
following two identities apply and there is a nice symmetry to them:

     (make <complex> magnitude: a angle: b) =
          (* (make <complex> magnitude: a) (make <complex> angle: b))

     (make <complex> x: a y: b) =
          (+ (make <complex> x: a) (make <complex> y: b))

Proposal:

Change the Dylan spec such that

    (make <complex> :angle a)
    
is interpreted as

    (make-polar 1 a)
	
--Steve

Stephen C. Gilardi
SQ Software
squeegee@world.std.com

From info-dylan-request Thu Oct 15 23:44:37 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05059; Thu, 15 Oct 92 23:44:37 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05055; Thu, 15 Oct 92 23:44:37 -0400
Received: from sparc7.cs.uiuc.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21409; Thu, 15 Oct 92 23:53:15 -0400
	for info-dylan@cambridge.apple.com
Received: by sparc7.cs.uiuc.edu id AA10216
  (5.65c/IDA-1.4.4 for info-dylan@cambridge.apple.com); Thu, 15 Oct 1992 22:51:37 -0500
Date: Thu, 15 Oct 1992 22:51:37 -0500
From: Conrad W Taylor <ctaylor@suna0.cs.uiuc.edu>
Message-Id: <199210160351.AA10216@sparc7.cs.uiuc.edu>
To: info-dylan@cambridge.apple.com
Subject: Dylan info/mailing list


         Could you send/e-mail me any info concerning Dylan and also
could I be added to the mailing list?

Thanks in advance,

-Conrad

ps: My e-mail is ctaylor@silver.lcs.mit.edu.


From info-dylan-request Fri Oct 16 04:40:27 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10957; Fri, 16 Oct 92 04:40:30 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10951; Fri, 16 Oct 92 04:40:27 -0400
Received: from ns3.hq.eso.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21626; Fri, 16 Oct 92 04:49:05 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210160843.AA15321@ns3.hq.eso.org>
Received: from localhost.hq.eso.org by ns3.hq.eso.org (4.1/ eso-1.1)
	id AA15321; Fri, 16 Oct 92 09:43:19 +0100
To: ferrante@world.std.com, info-dylan@cambridge.apple.com
Cc: ralbrecht@eso.org, ohnston@stsci.edu, miller@stsci.edu
Subject: Lisp (Dylan?) for Scientific Computing
Date: Fri, 16 Oct 92 09:43:18 +0100
From: hmadorf@eso.org

Dear friends,

I have been following the interesting discussion on floating-point
efficiency in Dylan for a while. I should like to provide a few
comments from the perspective of someone who has been active in the
area of scientific computing for two decades of which one was spent 
within astronomy.

I cannot see how the Dylan language is going to win the scientific 
computing community (or even a discernible fraction of it), if it is 
going to neglect the issue of floating point efficiency.

May be a healthy competition can be instigated between Common Lisp
language developers and implementors vs. Dylan developers and
implementors. I will certainly switch to whatever language comes
first in solving (elegantly of course!!) the needs of scientific 
computing, i.e. combining flexibility with efficiency.

Some of you might be interested in that I am currently in the
process of setting up a restricted (access- and timewise) WAN 
e-mail discussion group on the working title "Scientific computing in the 
1990ies - an astronomical perspective". I expect my host 
organization, the European Sothern Observatory, to have a broad
discussion on a similar topic early next year (which means getting 
prepared now) and that there is interest e.g. in the Italian 
astronomical community by some far-thinking colleagues.

My personal interest is in parallelism, languages (e.g. 
cross-platform portability, longevity of algorithms across language 
modifications or even complete language switches) and software 
environments (for code producers and end-users likewise) in the 
context of scientific computing, which involves almost invariably
a lot of FP-operations. From internal discussions I know that 
(a) data rates from astronomical telescopes will be increasing by 
factors of 10 to 100 in the foreseeable future and that
(b) people realize an increasing discontent with the
FORTRAN/C based interactive (data analysis) systems we have been
using in astronomy for the past 5 to 10 years.

Should any of you like to participate in the discussion, please let 
me know until the end of this month. We can negotiate the form and 
potential benefit for you.

Sincerely

Hans-Martin Adorf
- ST Data Analysis Scientist -
Space Telescope - European Coordinating Facility
European Southern Observatory
Karl-Schwarzschild-Str. 2
D-8046 Garching bei Muenchen
FR Germany
Internet: adorf@eso.org
Bitnet: adorf@dgaeso51.bitnet
Span: ESO::ADORF

From alms Fri Oct 16 10:10:45 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20441; Fri, 16 Oct 92 10:10:49 -0400
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20434; Fri, 16 Oct 92 10:10:45 -0400
Message-Id: <9210161410.AA20434@cambridge.apple.com>
Date: Fri, 16 Oct 1992 10:21:20 -0500
To: ferrante@world.std.com, info-dylan@cambridge.apple.com, hmadorf@eso.org
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Lisp (Dylan?) for Scientific Computing
Cc: ralbrecht@eso.org, ohnston@stsci.edu, miller@stsci.edu

At  9:43 AM 10/16/92 +0100, hmadorf@eso.org wrote:
>
>
>I cannot see how the Dylan language is going to win the scientific 
>computing community (or even a discernible fraction of it), if it is 
>going to neglect the issue of floating point efficiency.

I hope nothing in the Dylan manual or in messages from Apple gave
you the impression that the Dylan language in general and our
implementations in particular are going to neglect the issue of
floating point efficiency.  That most certainly is not the case.

Implementing efficient floating point numbers in a dynamic language
is more difficult than in a static language, but the technology
for doing so is known.

  -Andrew Shalit


From info-dylan-request Fri Oct 16 10:26:41 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21243; Fri, 16 Oct 92 10:26:43 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21237; Fri, 16 Oct 92 10:26:41 -0400
Received: from ns3.hq.eso.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22019; Fri, 16 Oct 92 10:35:20 -0400
	for alms@cambridge.apple.com
Message-Id: <9210161431.AA17464@ns3.hq.eso.org>
Received: from localhost.hq.eso.org by ns3.hq.eso.org (4.1/ eso-1.1)
	id AA17464; Fri, 16 Oct 92 15:31:11 +0100
To: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Lisp (Dylan?) for Scientific Computing 
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Your message of "Fri, 16 Oct 92 10:21:20 EST."
             <9210161410.AA20434@cambridge.apple.com> 
Date: Fri, 16 Oct 92 15:31:11 +0100
From: hmadorf@eso.org

Andrew,

>I hope nothing in the Dylan manual or in messages from Apple gave
>you the impression that the Dylan language in general and our
>implementations in particular are going to neglect the issue of
>floating point efficiency.  That most certainly is not the case.
No. Nothing in the manual, though I was looking for declarations and
found none. (Did I overlook them?)

My comments are mostly triggered by the on-going discussion on
FP-efficiency on info-dylan. Also, as you may be aware I ran
benchmarks comparing Fortran and Lisp FP-efficiency, and, though I
received a number of helpful and interesting comments, so far no-one
has come up with a version of my code that is comparable to Fortran 
w.r. to efficiency. 

I am looking forward to run my benchmarks in Dylan asap.

Cheers
Hans-Martin 

From info-dylan-request Sun Oct 18 11:27:37 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00452; Sun, 18 Oct 92 11:27:39 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00448; Sun, 18 Oct 92 11:27:37 -0400
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00191; Fri, 16 Oct 92 21:51:45 -0400
	for info-dylan@cambridge.apple.com
Received: from fpr.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA08820; Fri, 16 Oct 92 21:30:54 -0400
Message-Id: <9210170130.AA08820@uu.psi.com>
Received: by fpr (Mac/gnuucp v6.01) Fri, 16 Oct 1992 19:39:35 EDT
Date: Thu, 15 Oct 1992 23:50:30 -4
From: jim@fpr.com (James E. O'Dell)
Reply-To: jim@fpr.com
To: dyer@eagle.sharebase.com
Subject: Re: small integers
Cc: moon@cambridge.apple.com, Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU,
        info-dylan@cambridge.apple.com
X-Mailer: Mac/gnuucp Mail Reader v6.02
Organization: Fort Pond Research

...

>/// I don't believe Seymour Cray built his machines the way he did because
>/// he liked getting incorrect answers.
>
>I don't either.  On the other hand, debugging wrong algorithms may not have
>been as important in design as getting answers from already working ones.  When
>machine-time is more expensive than programmer-time this is an option one has.

The already working codes had to be developed at least once though. And most
large numeric programs are constatntly being twiddled. Take some of the large
"Hydrodynamics" codes run at the national laboratories. They are constantly
being upgraded to agree with the latestest experimental data. The codes are
then tested regressively against all previous data for agreement. This is a very
time consuming process.

A modern, efficent development environment would help considerably.

Also, think of all the image processing and full motion video code that will be
developed in the coming years. Most of that code is intensely numerical.
It will be important for that code to execute quickly. We we be forced to write
that code in C or Fortran? I hope not.

Jim

From info-dylan-request Mon Oct 19 13:31:53 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14844; Mon, 19 Oct 92 13:31:55 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14839; Mon, 19 Oct 92 13:31:53 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02143; Mon, 19 Oct 92 13:35:04 -0400
	for moon@cambridge.apple.com
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA12207; Mon, 19 Oct 92 13:31:11 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 132952.15902; Mon, 19 Oct 1992 13:29:52 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA10165; Mon, 19 Oct 92 09:21:54 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA00709; Mon, 19 Oct 92 09:21:52 PDT
Date: Mon, 19 Oct 92 09:21:52 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210191621.AA00709@eagle.sharebase.com>
To: dyer@eagle.sharebase.com, jim@fpr.com
Subject: Re: small integers
Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, info-dylan@cambridge.apple.com,
        moon@cambridge.apple.com

/// The already working codes had to be developed at least once though. And
/// most large numeric programs are constatntly being twiddled. Take some
/// of the large "Hydrodynamics" codes run at the national laboratories.
/// They are constantly being upgraded to agree with the latestest
/// experimental data. The codes are then tested regressively against all
/// previous data for agreement. This is a very time consuming process.
/// 
/// A modern, efficent development environment would help considerably.

Dynamic development may not be the best modern development environment for such
projects, then.  [a gasp escapes the studio audience]  The regression testing
would have to be heavily compiled and optimized (read: static-ized) in order
for such heavy-duty number crunching testing to be viable.

Dylan may be, despite it's name [DYnamic LANguage], a suitable language for
expressing such algorithms at some time in the future, but only if enough
attention is paid to float optimization when writing the compiler.

/// Also, think of all the image processing and full motion video code that
/// will be developed in the coming years. Most of that code is intensely
/// numerical.  It will be important for that code to execute quickly. We
/// we be forced to write that code in C or Fortran? I hope not.

Hopefully, Dylan will come equipped with a foreign function interface that
would allow the development of methods on these objects in a static language.
I agree that this is not the best long-term direction, but languages that try
to be everything for everyone end up like PL/I.

Not that PL/I wasn't a great language.  I just don't need compiler-support for
eight different numeric representations, and more constructs than I can count.
PL/I represents committee language designe, and much like Ada, a complete
compiler was never produced [Ada fans, I may be wrong about the later] because
of the bulk of requirements laid down for it.

Even worse, people who paid [through the nose] for what PL/I compilers
there were seemed to resent having to pay for what everyone else wanted
when they bought them...  Numerics are important, but I think we need a
good implementation of the base language before we can really dig into
more detailed issues...

/// Jim

	-- Scot

From info-dylan-request Mon Oct 19 15:27:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18880; Mon, 19 Oct 92 15:27:45 -0400
Received: from goofy.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18875; Mon, 19 Oct 92 15:27:43 -0400
Received: from apple.com by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef)
	id AA20273; Mon, 19 Oct 92 12:27:06 -0700
	for info-dylan@cambridge.apple.com
Received: from [90.190.20.255] by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA10166; Mon, 19 Oct 92 12:26:55 -0700
	for info-dylan@cambridge.apple.com
Message-Id: <9210191926.AA10166@apple.com>
Date: Mon, 19 Oct 1992 12:27:28 -0800
To: info-dylan@cambridge.apple.com
From: moofie@apple.com (Steve Klingsporn)
Subject: Please remove me from the lists

Could someone at Apple in Cambridge please remove me from the Dylan
lists?  Again, I was interested, but I have 100+ messages today after being
gone for a whole week, and I'm literally spinning trying to read all of them
or at least sort out which is which.

Thanks.
---------------------------------------------------------------------------
Steve Klingsporn                              20525 Mariani Avenue, MS 35-A
Collaborative Systems Development             Cupertino, CA  95014
Apple Computer, Inc.                          (408) 862-6508

"There are moments you can reach with people that are pure bliss, but then
 you have to get it again, and it can turn into a futile exercise that can
 undermine your entire existence.  The quest for the perfect moment."

                                     - Robert Smith


From info-dylan-request Mon Oct 19 18:22:07 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22029; Mon, 19 Oct 92 18:22:09 -0400
Received: from goofy.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22024; Mon, 19 Oct 92 18:22:07 -0400
Received: from apple.com by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef)
	id AA28381; Mon, 19 Oct 92 15:21:33 -0700
	for info-dylan@cambridge.apple.com
Received: from uu2.psi.com by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA01174; Sun, 18 Oct 92 00:31:34 -0700
	for info-dylan@cambridge.apple.com
Received: from rutherford.stsi.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA06014; Sun, 18 Oct 92 03:30:06 -0400
Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1)
	id AA04154; Sun, 18 Oct 92 03:30:02 EDT
Received: from quark.sbi.com by sbi.sbi.com (4.1/SMI-4.1)
	id AA13226; Sun, 18 Oct 92 03:30:00 EDT
Received: from silver.elements_CO by quark.sbi.com (4.1/SMI-4.1)
	id AA21405; Sat, 17 Oct 92 18:02:28 EDT
Date: Sat, 17 Oct 92 18:02:28 EDT
From: rwk@quark.sbi.com (Richard W. Kreutzer Consultant)
Message-Id: <9210172202.AA21405@quark.sbi.com>
Received: by silver.elements_CO (4.1/SMI-4.1)
	id AA00357; Sat, 17 Oct 92 18:03:26 EDT
To: info-dylan@cambridge.apple.com
Subject: MIT and Dylan

Someone posted that they heard that MIT was is some way involved with the
design and/or an implementation of Dylan.  Is this true?

Dick

From info-dylan-request Mon Oct 19 19:43:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23145; Mon, 19 Oct 92 19:43:06 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23140; Mon, 19 Oct 92 19:43:04 -0400
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03379; Mon, 19 Oct 92 19:46:20 -0400
	for info-dylan@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for info-dylan@cambridge.apple.com id AA12731; Mon, 19 Oct 92 16:42:27 -0700
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:info-dylan@cambridge.apple.com id AA27907; Mon, 19 Oct 92 16:42:27 -0700
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:info-dylan@cambridge.apple.com id AA09422; Mon, 19 Oct 92 16:44:46 -0700
Message-Id: <9210192344.AA09422@void.esd.sgi.com>
To: info-dylan@cambridge.apple.com
Subject: object projections and protocol
Date: Mon, 19 Oct 92 16:44:41 PDT
From: thant@void.esd.sgi.com


I'm new to this group and to Dylan, so I apologize if this is old stuff.

If an object B is indistinguishable as a subtype of another object A 
in the sense that for every method applicable to A there is also an
indistinguishable method for B, it would be nice to be able to cast 
a B into an A irregardless of the heterarchy of declared types.  I
am told this is called a 'projection.'

In Dylan projections could be accomplished explicitly using 
the 'as' function.

This would free the implementer from the burden of anticipating the
entire class heterarchy.  It certainly couldn't be expected to be
efficient (which is why it should only be done explicitly via 'as,'
but I have found that I often really want to do this and that there
is no other way around not being able to (independent of surgery on
the type heterarchy).

I suppose the tricky part would be going through all the methods
for which A is an argument and making sure that there is a
corresponding method for B and then building the appropriate
dispatcher.

Anybody wanna shoot this down?

I was told that one alternative to this mess is to move toward a
'protocol-based' system as opposed to an 'object-based' system.
I think I know what that means, but if anybody can point to some
literature, or enlighten me here, I would be much obliged.

thant




From info-dylan-request Mon Oct 19 20:41:19 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24058; Mon, 19 Oct 92 20:41:20 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24054; Mon, 19 Oct 92 20:41:19 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03555; Mon, 19 Oct 92 20:44:34 -0400
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA02887; Mon, 19 Oct 92 20:40:15 -0400
Received: by easynet.crl.dec.com; id AA16610; Mon, 19 Oct 92 20:40:21 -0400
Message-Id: <9210200040.AA14684@taunton.crl.dec.com>
To: rwk@quark.sbi.com (Richard W. Kreutzer Consultant)
Cc: info-dylan@cambridge.apple.com
Subject: Re: MIT and Dylan 
In-Reply-To: Your message of "Sat, 17 Oct 92 18:02:28 EDT."             <9210172202.AA21405@quark.sbi.com> 
Date: Mon, 19 Oct 92 20:40:20 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Sat, 17 Oct 92 18:02:28 EDT
    From: rwk@quark.sbi.com (Richard W. Kreutzer Consultant)
    
    Someone posted that they heard that MIT was is some way involved with the
    design and/or an implementation of Dylan.  Is this true?

Gack!  Another RWK!  Well, we RWK's should stick to gether, so
here's a cut at answering your question.

There are lots of ways that MIT is tied in.  A few of them:

1)  Many of Dylan's designers went to MIT.
2)  The first publicly-available implementation done to the Dylan
    book, is called "Thomas", and is written in MIT-Scheme.  (This
    was done by people here at DEC-CRL; some of the people who
    implemented it used to be at MIT).
3)  Various people at MIT participate in the design discussions.

There are probably other ties as well.

--rwk

From info-dylan-request Mon Oct 19 21:21:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24856; Mon, 19 Oct 92 21:21:08 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24851; Mon, 19 Oct 92 21:21:05 -0400
Received: from ibeam.ht.intel.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03670; Mon, 19 Oct 92 21:24:20 -0400
	for info-dylan@cambridge.apple.com
Received: from ishark.intel.com by ibeam.intel.com with smtp
	(Smail3.1.26.7 #9) id m0mh7b7-00020CC; Mon, 19 Oct 92 17:37 PDT
Received: by ishark.intel.com (Smail3.1.26.7 #9)
	id m0mh7eH-00018fC; Mon, 19 Oct 92 17:40 PDT
Message-Id: <m0mh7eH-00018fC@ishark.intel.com>
Date: Mon, 19 Oct 92 17:40 PDT
From: andyw@ibeam.ht.intel.com (Andy Wilson)
To: info-dylan@cambridge.apple.com
Subject: bounded, infinite ranges?


Excuse me if this question has been asked before ... but since the
Dylan language has IEEE floats and thus contains infinities, couldn't
the "up-to:", "through:" or "size:" parameters for a range be
infinite?  One could thus have an infinite range which is still
bounded.  If this supposition is true, perhaps the language definition
should be changed so that infinite ranges are always treated as
unbounded.

Oh, that reminds me: what is the Dylan syntax for infinities, NaNs,
and other IEEE goodies?  They don't seem to be specified in the April
'92 manual.

atw

From info-dylan-request Mon Oct 19 23:24:09 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29009; Mon, 19 Oct 92 23:24:15 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29004; Mon, 19 Oct 92 23:24:09 -0400
Received: from uu3.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03884; Mon, 19 Oct 92 23:27:26 -0400
	for info-dylan@cambridge.apple.com
Received: from stowe.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AB22799; Mon, 19 Oct 92 23:23:34 -0400
Received:  by stowe.bdsw.com (UUPC/extended 1.11v);
           Mon, 19 Oct 1992 23:20:18 EDT
X-Mailer: Cinetic Mail Manager V2.1
Date: Mon, 19 Oct 1992 23:20:15 EDT
From: duncan@stowe.bdsw.com (Rich Duncan)
Message-Id: <2ae37af3.stowe@stowe.bdsw.com>
To: info-dylan@cambridge.apple.com (Dylan Information Forum)
Subject: Dylan Constants

 From the Dylan reference, there appears to be now way of defining a read
only constant ala the Common Lisp DEFCONSTANT macro. This appears to be an
omission since that *constantness* of a variable is helpful to both
programmers and compilers.

Given a choice, I'd vote for an extension to the syntax of the DEFINE form
rather and the addition of another DEF macro.

Any thoughts?

--
Rich Duncan                                  Internet: duncan@bdsw.com
Black Diamond Software, Inc.               Compuserve: 75540,2532
127 Wilton Road East                            Phone: (203)438-3050
Ridgefield, CT 06877                              Fax: (203)438-1447

From info-dylan-request Tue Oct 20 07:43:26 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13975; Tue, 20 Oct 92 07:43:28 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13970; Tue, 20 Oct 92 07:43:26 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04205; Tue, 20 Oct 92 07:46:46 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210201146.AA04205@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa10734;
          20 Oct 92 7:42:31 EDT
To: Rich Duncan <duncan@stowe.bdsw.com>
Cc: Dylan Information Forum <info-dylan@CAMBRIDGE.APPLE.COM>
Subject: Re: Dylan Constants 
In-Reply-To: Your message of Mon, 19 Oct 92 23:20:15 -0500.
             <2ae37af3.stowe@stowe.bdsw.com> 
Date: Tue, 20 Oct 92 07:42:26 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


     From the Dylan reference, there appears to be now way of defining a read
    only constant ala the Common Lisp DEFCONSTANT macro. 

The Dylan people at Apple have indicated that this will be fixed.  I don't
know if they've yet settled on a choice of syntax, but I believe the
current plan is that *all* the "define" forms will produce constants, and
some new form will be created for defining non-constant variables.

Clearly the ability to create simple constants, as in

(defconstant pixel-depth 8)

is essential if code is to be both efficient and readable.

-- 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
5000 Forbes Avenue
Pittsburgh, PA 15213

From info-dylan-request Tue Oct 20 08:47:32 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17450; Tue, 20 Oct 92 08:47:33 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17446; Tue, 20 Oct 92 08:47:32 -0400
Received: from gmdzi.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04292; Tue, 20 Oct 92 08:50:45 -0400
	for info-dylan@cambridge.apple.com
Received: from localhost by gmdzi.gmd.de with SMTP id AA26839
  (5.65c/IDA-1.4.4 for info-dylan@CAMBRIDGE.APPLE.COM); Tue, 20 Oct 1992 13:45:57 +0100
Message-Id: <199210201245.AA26839@gmdzi.gmd.de>
To: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU
Cc: <duncan@stowe.bdsw.com>, <info-dylan@CAMBRIDGE.APPLE.COM>,
        bretth@gmdzi.gmd.de
Subject: Re: Dylan Constants 
In-Reply-To: Your message of "Tue, 20 Oct 92 07:42:26 -0400."
             <9210201146.AA04205@brazil.cambridge.apple.com> 
Date: Tue, 20 Oct 92 13:45:54 +0100
From: Harry.Bretthauer@gmd.de
X-Mts: smtp


>      From the Dylan reference, there appears to be now way of defining a read
>     only constant ala the Common Lisp DEFCONSTANT macro. 

One thing, I don't like in the CL DEFCONSTANT spec is that it mixes
the concepts of bindings and data structures. 
In an object oriented language like Dylan it should be a property of
the anonymous object if it is read only or not. The question if the
binding is mutable or immutable is an orthogonal one, although the
compiler can make more optimizations if both the binding and the
object are read only.

> The Dylan people at Apple have indicated that this will be fixed.  I don't
> know if they've yet settled on a choice of syntax, but I believe the
> current plan is that *all* the "define" forms will produce constants, and
> some new form will be created for defining non-constant variables.

In EuLisp, we adopted the same approach.

--Harry

Harry Bretthauer
German National Research Center for Computer Science (GMD)
P.O. Box 1316, W-5205 Sankt Augustin 1, Germany
Phone: +49-2241-14-2704   Fax: +49-2241-14-2072 Email: bretthauer@gmd.de

From info-dylan-request Tue Oct 20 09:02:28 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18164; Tue, 20 Oct 92 09:02:30 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18159; Tue, 20 Oct 92 09:02:28 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04343; Tue, 20 Oct 92 09:05:48 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210201305.AA04343@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa10817;
          20 Oct 92 9:01:43 EDT
To: Harry.Bretthauer@gmd.de
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Dylan Constants 
In-Reply-To: Your message of Tue, 20 Oct 92 13:45:54 +0000.
             <199210201245.AA26839@gmdzi.gmd.de> 
Date: Tue, 20 Oct 92 09:01:37 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


    In an object oriented language like Dylan it should be a property of
    the anonymous object if it is read only or not. The question if the
    binding is mutable or immutable is an orthogonal one, although the
    compiler can make more optimizations if both the binding and the
    object are read only.
    
Good point.

-- 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
5000 Forbes Avenue
Pittsburgh, PA 15213

From info-dylan-request Tue Oct 20 09:24:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19166; Tue, 20 Oct 92 09:24:17 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19161; Tue, 20 Oct 92 09:24:15 -0400
Received: from mwunix.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04412; Tue, 20 Oct 92 09:27:36 -0400
	for info-dylan@cambridge.apple.com
Return-Path: <slack@starbase.mitre.org>
Received: from starbase.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
	id AA04083; Tue, 20 Oct 92 09:23:07 -0400
Received: by starbase.mitre.org (4.1/SMI-4.1)
	id AA06122; Tue, 20 Oct 92 09:18:15 EDT
Date: Tue, 20 Oct 92 09:18:15 EDT
From: slack@starbase.MITRE.ORG (M. G. Slack)
Message-Id: <9210201318.AA06122@starbase.mitre.org>
To: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Remove me from the list please!


Too much for me to handle.  Please remove me from the mailing list.

Thanks, and sorry for bugging the rest of you with this.

Marc

From alms Tue Oct 20 10:30:16 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22136; Tue, 20 Oct 92 10:30:23 -0400
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22129; Tue, 20 Oct 92 10:30:16 -0400
Message-Id: <9210201430.AA22129@cambridge.apple.com>
Date: Tue, 20 Oct 1992 10:35:34 -0500
To: Rich Duncan <duncan@stowe.bdsw.com>, Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Dylan Constants
Cc: Dylan Information Forum <info-dylan@CAMBRIDGE.APPLE.COM>

At  7:42 AM 10/20/92 -0400, Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU wrote:
> 
> 
>      From the Dylan reference, there appears to be now way of defining a read
>     only constant ala the Common Lisp DEFCONSTANT macro. 
> 
> The Dylan people at Apple have indicated that this will be fixed.  I don't
> know if they've yet settled on a choice of syntax, but I believe the
> current plan is that *all* the "define" forms will produce constants, and
> some new form will be created for defining non-constant variables.

That's correct.


From alms Tue Oct 20 10:31:38 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22223; Tue, 20 Oct 92 10:31:42 -0400
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22214; Tue, 20 Oct 92 10:31:38 -0400
Message-Id: <9210201431.AA22214@cambridge.apple.com>
Date: Tue, 20 Oct 1992 10:36:55 -0500
To: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, Harry.Bretthauer@gmd.de
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Dylan Constants
Cc: <duncan@stowe.bdsw.com>, <info-dylan@CAMBRIDGE.APPLE.COM>,
        bretth@gmdzi.gmd.de

At  1:45 PM 10/20/92 +0100, Harry.Bretthauer@gmd.de wrote:
> 
> 
> >      From the Dylan reference, there appears to be now way of defining a read
> >     only constant ala the Common Lisp DEFCONSTANT macro. 
> 
> One thing, I don't like in the CL DEFCONSTANT spec is that it mixes
> the concepts of bindings and data structures. 
> In an object oriented language like Dylan it should be a property of
> the anonymous object if it is read only or not. The question if the
> binding is mutable or immutable is an orthogonal one, although the
> compiler can make more optimizations if both the binding and the
> object are read only.

Dylan maintains the separation you want, and will continue to do so.


From info-dylan-request Tue Oct 20 11:58:39 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01338; Tue, 20 Oct 92 11:58:40 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01334; Tue, 20 Oct 92 11:58:39 -0400
Received: from Relay.Prime.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04955; Tue, 20 Oct 92 12:01:57 -0400
	for info-dylan@cambridge.apple.com
Received: from flora.ccs.northeastern.edu by Relay.Prime.COM; 20 Oct 92 12:02:48 EST
Received: from sun4110a.ccs.northeastern.edu by flora.ccs.northeastern.edu (4.0/SMI-4.1)
	id AA13258; Tue, 20 Oct 92 11:57:16 EDT
Received: by sun4110a.ccs.northeastern.edu (4.1/SMI-3.2+CCS-subsidiary-2.2)
	id AA00582; Tue, 20 Oct 92 11:57:13 EDT
Date: Tue, 20 Oct 92 11:57:13 EDT
From: esmith@sun4110a.ccs.northeastern.edu (J. Elliot Smith)
Message-Id: <9210201557.AA00582@sun4110a.ccs.northeastern.edu>
To: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Please remove me from the mailing list.


Echoing another user's recent mail,

    Too much chatter for me to handle.
    Please remove me from the mailing list.
    Thanks, and sorry for bugging the rest of you with this.

Perhaps you could set up a summarizing program, ala the
Scheme Digest (may require running Unix not MacOS).  If
you ever do, let me know.
				-- elliott smith




From info-dylan-request Tue Oct 20 12:00:24 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01388; Tue, 20 Oct 92 12:00:26 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01384; Tue, 20 Oct 92 12:00:24 -0400
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04983; Tue, 20 Oct 92 12:03:46 -0400
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 20 Oct 1992 16:59:09 +0100
Date: Tue, 20 Oct 92 17:00:49 BST
Message-Id: <12071.9210201600@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: contractual programming
To: info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Mon, 19 Oct 92 09:34:27 PDT

  For those of you who just tuned in, contractual programming is the
  attaching of some expression to a class or a method to be used as a
  contract.

This sounds similar to the "class invariants" (is that right?)
in Eiffel.

-- jeff

From alms Tue Oct 20 13:22:58 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03458; Tue, 20 Oct 92 13:23:00 -0400
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03453; Tue, 20 Oct 92 13:22:58 -0400
Message-Id: <9210201722.AA03453@cambridge.apple.com>
Date: Tue, 20 Oct 1992 13:28:17 -0500
To: info-dylan
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Please use the '-request' line

Just a reminder:

  Please don't send administrative mail to the info-dylan mailing list.
Send it to the administrative address: info-dylan-request@cambridge.apple.com.
(AppleLink users can abbreviate this to info-dylan-req@cambridge.apple.com.)

  Requests to be added or removed are considered administrative.

  Thanks in advance for observing this piece of net ettiquette.

  -Andrew Shalit


From info-dylan-request Tue Oct 20 13:24:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03501; Tue, 20 Oct 92 13:24:36 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03497; Tue, 20 Oct 92 13:24:35 -0400
Received: from outmail.microsoft.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05570; Tue, 20 Oct 92 13:27:56 -0400
	for info-dylan@cambridge.apple.com
Received:  by outmail.microsoft.com (5.65/25-eef)
	id AA04642; Tue, 20 Oct 92 10:21:59 -0700
Message-Id: <9210201721.AA04642@outmail.microsoft.com>
X-Msmail-Message-Id:  54CB51C6
X-Msmail-Conversation-Id:  54CB51C6
From: Kevin Purcell (Rho) <a-kevinp@microsoft.com>
To: info-dylan@cambridge.apple.com,
        netmail!info-dylan-request@cambridge.apple.com
Date: Tue, 20 Oct 92 10:15:04 PDT
Subject: RE: Dylan Constants

Do the Program Constants (p20) not suffice for this? $pi, $end-of-file, $etc.

Is the problem in first paragraph of Variable names on p20: "the names 
of variables do not affect the semantics of the program"?

Does Dylan raise an error on (set! $pi 3.0)?

Kevin Purcell
a-kevinp@microsoft.com
My views are often orthogonal to those of Microsoft Corp
----------
From: Rich Duncan  <netmail!duncan@stowe.bdsw.com>
To: Dylan Information Forum  <info-dylan@cambridge.apple.com>
Subject: Dylan Constants
Date: Monday, October 19, 1992 11:20PM

 From the Dylan reference, there appears to be now way of defining a read
only constant ala the Common Lisp DEFCONSTANT macro. This appears to be an
omission since that *constantness* of a variable is helpful to both
programmers and compilers.

Given a choice, I'd vote for an extension to the syntax of the DEFINE form
rather and the addition of another DEF macro.

Any thoughts?

--
Rich Duncan                                  Internet: duncan@bdsw.com
Black Diamond Software, Inc.               Compuserve: 75540,2532
127 Wilton Road East                            Phone: (203)438-3050
Ridgefield, CT 06877                              Fax: (203)438-1447


From info-dylan-request Tue Oct 20 13:35:55 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03802; Tue, 20 Oct 92 13:35:57 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03798; Tue, 20 Oct 92 13:35:55 -0400
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05708; Tue, 20 Oct 92 13:39:18 -0400
	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 AA18023; Tue, 20 Oct 92 13:35:29 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 133430.681; Tue, 20 Oct 1992 13:34:30 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA27504; Tue, 20 Oct 92 08:44:48 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA01330; Tue, 20 Oct 92 08:44:47 PDT
Date: Tue, 20 Oct 92 08:44:47 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210201544.AA01330@eagle.sharebase.com>
To: andyw@ibeam.ht.intel.com, info-dylan@cambridge.apple.com
Subject: Re:  bounded, infinite ranges?

/// Excuse me if this question has been asked before ... but since the
/// Dylan language has IEEE floats and thus contains infinities, couldn't
/// the "up-to:", "through:" or "size:" parameters for a range be
/// infinite?  One could thus have an infinite range which is still
/// bounded.  If this supposition is true, perhaps the language definition
/// should be changed so that infinite ranges are always treated as
/// unbounded.

I'm not entirely sure this would be a good idea for infities, but it should
be for a bottom (NaN) value.  My reason: a range is over floats, yes?
Therefore no enumerative approach would terminate (any range has an infinite
number of elements), even if one was provided.

/// Oh, that reminds me: what is the Dylan syntax for infinities, NaNs, and
/// other IEEE goodies?  They don't seem to be specified in the April '92
/// manual.

Yes.  I was rather disapointed by this myself, tho' it was plenty easy to be
happy with the rest.

These values that sit outside the system, "top" and "bottom" values are usually
very important to a program.  IMHO, it was unfortunate that they were left out
of the Dylan language spec.  Sometimes, one wants to return an integer from a
function, for example, and also be able to return an error value.  One can't
use -1 or 0 or whatever.  This is a classic LISP style problem that was made
even worse in older LISPs by using 'nil' to represent _every_ bottom value
(including class 'cons's bottom value).

In fact, I'm such a big fan of top and bottom values that I might ask that some
more generic solution to the problem of writing Nan and Infinity in a program
be found -- one that will also let me write (error |Empty list has no sum|) as
a _value_ (this is _LISP_ after all, and the value is king :-) so that I can
return it from 'sum' if passed the empty list...

/// atw

	-- Scot

Llamas?  I thought they were CAMLs!

From info-dylan-request Tue Oct 20 13:36:02 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03815; Tue, 20 Oct 92 13:36:04 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03809; Tue, 20 Oct 92 13:36:02 -0400
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05712; Tue, 20 Oct 92 13:39:23 -0400
	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 AA17991; Tue, 20 Oct 92 13:35:24 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 133439.747; Tue, 20 Oct 1992 13:34:39 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA27888; Tue, 20 Oct 92 09:56:39 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA01399; Tue, 20 Oct 92 09:56:38 PDT
Date: Tue, 20 Oct 92 09:56:38 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210201656.AA01399@eagle.sharebase.com>
To: info-dylan@cambridge.apple.com, jeff@aiai.edinburgh.ac.uk
Subject: Re: contractual programming

///   For those of you who just tuned in, contractual programming is the
///   attaching of some expression to a class or a method to be used as a
///   contract.
///
/// This sounds similar to the "class invariants" (is that right?)
/// in Eiffel.

I don't know enough about Eiffel to say, I'm afraid.  The idea is to provide
a conveniant space in class/method definitions for run-time error checking,
since this can be awkward without them, leading programmers to fly by the seat
of their pants during development...  One hopes that by giving them a suitably
painless avenue towards value-checking that they will develop robust
applications with a good amount of error checking.

Is this what "class invariants" buy one in Eiffel?

	-- Scot

From info-dylan-request Tue Oct 20 13:37:34 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03881; Tue, 20 Oct 92 13:37:36 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03877; Tue, 20 Oct 92 13:37:34 -0400
Received: from uu2.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05746; Tue, 20 Oct 92 13:40:52 -0400
	for info-dylan@cambridge.apple.com
Received: from [192.195.121.6] by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA00493; Tue, 20 Oct 92 13:36:34 -0400
Received: from sbi.sbi.com by internet.sbi.com (4.1/SMI-4.1)
	id AA06255; Tue, 20 Oct 92 13:36:20 EDT
Received: from quark.sbi.com by sbi.sbi.com (4.1/SMI-4.1)
	id AA17105; Tue, 20 Oct 92 13:36:19 EDT
Received: from silver.elements_CO by quark.sbi.com (4.1/SMI-4.1)
	id AA03993; Tue, 20 Oct 92 13:35:05 EDT
Date: Tue, 20 Oct 92 13:35:05 EDT
From: rwk@quark.sbi.com (Richard W. Kreutzer Consultant)
Message-Id: <9210201735.AA03993@quark.sbi.com>
Received: by silver.elements_CO (4.1/SMI-4.1)
	id AA06512; Tue, 20 Oct 92 13:36:17 EDT
To: info-dylan@cambridge.apple.com
Subject: macros

Is there any progress on a macro facility for Dylan?

Dick

From info-dylan-request Tue Oct 20 14:08:25 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05006; Tue, 20 Oct 92 14:08:26 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05002; Tue, 20 Oct 92 14:08:25 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06009; Tue, 20 Oct 92 14:11:48 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210201811.AA06009@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa11050;
          20 Oct 92 14:07:20 EDT
To: Scot Dyer <dyer@eagle.sharebase.com>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: contractual programming 
In-Reply-To: Your message of Mon, 19 Oct 92 09:34:27 -0800.
             <9210191634.AA00726@eagle.sharebase.com> 
Date: Tue, 20 Oct 92 14:07:17 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


    For those of you who just tuned in, contractual programming is the attaching
    of some expression to a class or a method to be used as a contract.  If the
    expression ever evaluates to #false, the contract has been violated and an
    error is signalled.
    
Well, something like the Common Lisp ASSERT (test some arbitrary predicate
and signal a value if it is false) would do part of what you want.  It
might want to be part of the base language, just to encourage people to use
it, but it would be trivial to add it as a library.  The only problem is
that you have to sprinkle these around your program in specific places.

The next step would be to build a table associating a "contract" predicate
with each class.  A call to (CHECK-CONTRACT <object>) would retrieve the
contract associated with that class (if any), then proceed as for ASSERT.
Again, this is trivial to write as a portable library.

The final step would be to modify all the setters to run check-contract
after they do their thing.  I'm not sure if this could be written somehow
as a mix-in method on SET! and INITIALIZE -- it's a bit unclear since the
former is a syntax-form and the latter is perhaps being revised.  But I'm
sure there's some way to get this effect.  I certainly wouldn't want this
to be the default, however.  Contracts have their charm, but I don't want
to slow down *all* modifications to check them.

-- 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
5000 Forbes Avenue
Pittsburgh, PA 15213

From info-dylan-request Tue Oct 20 15:00:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06658; Tue, 20 Oct 92 15:00:36 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06654; Tue, 20 Oct 92 15:00:35 -0400
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06216; Tue, 20 Oct 92 15:03:58 -0400
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA00645; Tue, 20 Oct 92 14:59:55 -0400
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA17784; Tue, 20 Oct 1992 14:57:56 -0400
Date: Tue, 20 Oct 1992 14:57:56 -0400
Message-Id: <9210201857.AA17784@lakatos.osf.org>
To: dyer@eagle.sharebase.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Tue, 20 Oct 92 08:44:47 PDT <9210201544.AA01330@eagle.sharebase.com>
Subject:  bounded, infinite ranges?
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

   ...My reason: a range is over floats, yes?  Therefore no
   enumerative approach would terminate (any range has an infinite
   number of elements), even if one was provided.

Huh?  Floats are not reals -- after all, they're represented finitely.

As for the meaning of IEEE infinity, it is not really infinity either:
it stands for all numbers too large to represent in a given floating
type.

   These values that sit outside the system, "top" and "bottom" values
   are usually very important to a program.  IMHO, it was unfortunate
   that they were left out of the Dylan language spec.

I agree.  Dylan appears to use #f as a substitute for a void value in
some cases, e.g. while, until, bind with no forms.  This, and the fact
that ANY non-#f value is true, seem to be residual Lispisms.

Note that adding void to the possible returns of a function increases
function-return overhead, since of course you have to find some place
for the necessary bits....  (If you do it by some control convention,
there is still some overhead somewhere.)

	-s


From info-dylan-request Tue Oct 20 15:08:51 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06854; Tue, 20 Oct 92 15:08:53 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06850; Tue, 20 Oct 92 15:08:51 -0400
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06268; Tue, 20 Oct 92 15:12:13 -0400
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA10348; Tue, 20 Oct 92 15:08:16 EDT
Received: from ireland.gensym by gensym.com (4.0/SMI-3.2)
	id AA03429; Tue, 20 Oct 92 14:47:50 EDT
Received: by ireland.gensym (4.1/SMI-4.1)
	id AA07352; Tue, 20 Oct 92 14:53:38 EDT
Date: Tue, 20 Oct 92 14:53:38 EDT
From: gensym!ireland!jra@harvard.harvard.edu (Jim Allard)
Message-Id: <9210201853.AA07352@ireland.gensym>
To: info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Mon, 19 Oct 92 09:21:52 PDT <9210191621.AA00709@eagle.sharebase.com>
Subject: Re: small integers


   ...Dynamic development may not be the best modern development environment for such
   projects, then.  [a gasp escapes the studio audience]  The regression testing
   would have to be heavily compiled and optimized (read: static-ized) in order
   for such heavy-duty number crunching testing to be viable.

   Dylan may be, despite it's name [DYnamic LANguage], a suitable language for
   expressing such algorithms at some time in the future, but only if enough
   attention is paid to float optimization when writing the compiler...

   ...Hopefully, Dylan will come equipped with a foreign function interface that
   would allow the development of methods on these objects in a static language.
   I agree that this is not the best long-term direction, but languages that try
   to be everything for everyone end up like PL/I.

I must disagree with the content and sentiment of the previous statements.  Our
experiences with fielding a commercial product written in Common Lisp have been
dominated by the performance and portability concerns that are being
characterized as unimportant above.

Typically, it is has been easy for us to get our code to run within different
vendor's Common Lisps.  However, we have had to spend significant amounts of
time tuning it to run fast enough within these different Common Lisp
implementations.  In many cases we have been forced to use implementation
specific optimizations, such as foreign functions, to get the speed we needed.
Every time we have done this we have regretted it, either when it came time to
do the next port, or when previous ports were broken by the changes.

Usually the performance problems arose when implementations chose to ignore
type declarations that we expected would produce certain optimizations.  In our
case, we needed optimizations for the following: fixnum and double-float
arithmetic to get these operations in-line without boxing of intermediate
values; setting and fetching values within arrays of immediate double-floats
and immediate integers 1, 8, 16, and 32 bits in length; indirect dispatches to
functions where we knew the argument lists contained only required arguments;
and some miscellaneous fetching operations like (car (the cons x)) and (length
(the simple-vector y)).

There is always competition around speed in commercial software.  As a user of
a high level language, my strong preference is for clear statements within the
language specification of what optimization statements I can use and what I
should expect from them.  Make-read-only and seal are such optimization
operations, though the manual does not explicitly tell me what optimizations I
can expect given what situations.  Optimized numeric operations are a
requirement for most commercial code, and users of a language must be able to
write code that they can be confident will run very fast in any reasonable
implementation of the language.

There should not be a contradiction between ease of writing correct programs
and ease of writing fast programs.  The first is an advantage, while the second
is a requirement.

Jim

-------------------------------------------------------------------------------
Jim Allard                                        jra@gensym.com
Gensym Corporation                                (617) 547-2500
125 CambridgePark Drive
Cambridge, MA  02140
-------------------------------------------------------------------------------

From info-dylan-request Tue Oct 20 16:18:29 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08694; Tue, 20 Oct 92 16:18:30 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08690; Tue, 20 Oct 92 16:18:29 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06399; Tue, 20 Oct 92 16:21:49 -0400
	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 AA11122; Tue, 20 Oct 92 16:17:56 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 161621.24548; Tue, 20 Oct 1992 16:16:21 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA01477; Tue, 20 Oct 92 12:46:00 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA01551; Tue, 20 Oct 92 12:45:58 PDT
Date: Tue, 20 Oct 92 12:45:58 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210201945.AA01551@eagle.sharebase.com>
To: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, dyer@eagle.sharebase.com
Subject: Re: contractual programming
Cc: info-dylan@CAMBRIDGE.APPLE.COM

If you aren't interested in this, junk it now.  It's longer than I thought it
would end up being...

/// Well, something like the Common Lisp ASSERT (test some arbitrary
/// predicate and signal a value if it is false) would do part of what you
/// want.  It might want to be part of the base language, just to encourage
/// people to use it, but it would be trivial to add it as a library.  The
/// only problem is that you have to sprinkle these around your program in
/// specific places.
/// 
/// The next step would be to build a table associating a "contract"
/// predicate with each class.  A call to (CHECK-CONTRACT <object>) would
/// retrieve the contract associated with that class (if any), then proceed
/// as for ASSERT.  Again, this is trivial to write as a portable library.

Which many programmers really don't want to do.  Not to say that they don't
think it's a good idea, but it can clutter up code and in a value-oriented
language (like a LISP dialect, for example), it can detract from the
readability of the code, especially:

	;; syntax for define-method might be d.-m. name (params) form)
	;; sorry -- don't have manual handy...
	(define-method (do-something x)
		(do-something-else x (method (blah-blah) blah-blah)))

..becomes...

	(define-method (do-something x)
		(begin
			(check-range x)
			(do-something-else x (method ...))...)

Where a 'begin'/'sequence' is needed.  Also, this is one type of contract
that has been neglected in the discussion (partially because I'm writing
this from my work-place and have [unfortunately] other responsibilities) --
The notion of range-checking input to a function is so good for program
resiliance, that I'd argue for a special form to do it with.  This could be
a Dylan parameter 'specializer', or it could be included as an optional
keyed parameter to define-method, ergo:

	(define-method (do-something x)
		domain-check: (and (>= x 0) (<= x 10))
			;; 'domain' because not a check of return value.
			;; range-check: valuable documentation, eh?
		(do-something-else x (method (blah-..........

..or...

	(define-method (do-something (x <some-class> range: (and (>= x 0).....)

Both have advantages and disadvantages since a range check implies that the
method has already been selected, and that next-method should not be used,
while the specializer implies that several ranges could be used.  These would
have to be placed (in the generic functions method list) after singletons,
but before un-ranged class-restricted parameters.

Personally, I'd rather see the first, since it restricts the notation to
actual contract checking, rather than some exotic flow of control mechanism
that may be difficult to read/maintain.

/// The final step would be to modify all the setters to run check-contract
/// after they do their thing.  I'm not sure if this could be written
/// somehow as a mix-in method on SET! and INITIALIZE -- it's a bit unclear
/// since the former is a syntax-form and the latter is perhaps being
/// revised.  But I'm sure there's some way to get this effect.  I
/// certainly wouldn't want this to be the default, however.  Contracts
/// have their charm, but I don't want to slow down *all* modifications to
/// check them.

On the issue of efficiency, I think it's important to be able to disable
*all* contract-checking in a production version of the program.  This helps
discourage people from using contracts as a special flow of control mechanism
since a more efficient production model could not be produced.  For places
where the programmer wished the production version to do run-time error
checking, the ad-hoc 'check-contract' may be best, but in keeping with the
style of the rest of Dylan, I would ask that it be defined to either return
the object itself, or on failure to raise an exception (that may be returned
from after correction...).

I am generally opposed to conditional compilation since this can produce wildly
unreadable code like C's stdio.h which in most implementations is a hairball
deserving of only its author.  But allowing toggling of contract checking for
production code wouldn't cause these problems.

Also, when some kind of 'trace' package is installed, one might want to be
able to toggle contracts off and on on a class-by-class and method-by-method
basis.  Built-in improved debugability.

/// -- Scott

	-- Scot		(Llamas?!)

P.S.  Yes, what about macros?  This is the third (and final for those of you
getting sick of discussing things outside the Dylan spec) thing that
disappointed me in the spec.  I trust that it, if nothing else, will be fixed.

From info-dylan-request Tue Oct 20 16:35:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA09188; Tue, 20 Oct 92 16:35:16 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09184; Tue, 20 Oct 92 16:35:15 -0400
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06491; Tue, 20 Oct 92 16:38:37 -0400
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA05496; Tue, 20 Oct 92 16:34:45 -0400
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA14204; Tue, 20 Oct 1992 16:32:47 -0400
Date: Tue, 20 Oct 1992 16:32:47 -0400
Message-Id: <9210202032.AA14204@lakatos.osf.org>
To: macrakis@osf.org
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Stavros Macrakis's message of Tue, 20 Oct 1992 14:57:56 -0400 <9210201857.AA17784@lakatos.osf.org>
Subject: bounded, infinite ranges?
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

I said:

   Floats are not reals -- after all, they're represented finitely.

Let me just clarify.  I meant that floats are not mathematical real
numbers.  They are of course Dylan "reals".

	-s

From info-dylan-request Tue Oct 20 17:16:56 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10049; Tue, 20 Oct 92 17:16:57 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10043; Tue, 20 Oct 92 17:16:56 -0400
Received: from ibeam.ht.intel.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06640; Tue, 20 Oct 92 17:20:18 -0400
	for info-dylan@cambridge.apple.com
Received: from ishark.intel.com by ibeam.intel.com with smtp
	(Smail3.1.26.7 #9) id m0mhQsp-00020KC; Tue, 20 Oct 92 14:12 PDT
Received: by ishark.intel.com (Smail3.1.26.7 #9)
	id m0mhQvy-00018uC; Tue, 20 Oct 92 14:16 PDT
Message-Id: <m0mhQvy-00018uC@ishark.intel.com>
Date: Tue, 20 Oct 92 14:16 PDT
From: andyw@ibeam.ht.intel.com (Andy Wilson)
To: macrakis@osf.org
Subject: Re:  bounded, infinite ranges?
Cc: info-dylan@cambridge.apple.com

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

   ...My reason: a range is over floats, yes?  Therefore no
   enumerative approach would terminate (any range has an infinite
   number of elements), even if one was provided.

Huh?  Floats are not reals -- after all, they're represented finitely.
---------------------------------------------------------------

Absolutely right -- which is why I originally asked the question
about ranges where one of the bounds is infinity.  Actually, there's
a much more mundane question about ranges with float bounds: what
is the (size) of such a range, which is defined in the April '92
book as an integer.

Naively, one might assume that (size range) could be defined as
(/ (- (top range) (bottom range)) (by range)).  However, since
floats are in fact represented finitely, if the "by:" step size
for range is sufficiently small there might well be too few
allowable bit patterns to represent the theoretical number of
intervals in the range.

You could define away this problem by requiring by:, from:, up-to:
and through: to be rational, thus making the size calculation
exact.

BTW, I'd still like an answer on the other question about Dylan
syntax for infinities and NaN's.  Any takers?

atw

From info-dylan-request Tue Oct 20 17:58:06 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10784; Tue, 20 Oct 92 17:58:08 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10780; Tue, 20 Oct 92 17:58:06 -0400
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06770; Tue, 20 Oct 92 18:01:29 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210202201.AA06770@brazil.cambridge.apple.com>
Via: uk.ac.bath.maths; Tue, 20 Oct 1992 22:54:53 +0100
Received: from watt by haldane.maths.Bath.AC.UK id aa17874; 20 Oct 92 22:53 BST
To: dyer@eagle.sharebase.com
Cc: Scott_Fahlman@sef1.slisp.cs.cmu.edu, info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Tue, 20 Oct 92 12:45:58 PDT <9210201945.AA01551@eagle.sharebase.com>
Subject: contractual programming
Date: Tue, 20 Oct 92 22:53:10 BST
From: jap@maths.bath.ac.uk
Sender: jap@maths.bath.ac.uk
Source-Info: From (or Sender) name not authenticated.

   Date: Tue, 20 Oct 92 12:45:58 PDT
   From: Scot Dyer <dyer@com.sharebase.eagle>
   Sender: info-dylan-request@com.apple.cambridge

   [...]

   P.S.  Yes, what about macros?  This is the third (and final for those of you
   getting sick of discussing things outside the Dylan spec) thing that
   disappointed me in the spec.  I trust that it, if nothing else, will be fixed.

It will be fixed...at least I've heard that hope expressed by people
in Cambridge.  The truth is it is a non-trivial problem to fix
elegantly.

One solution would be to add packages and then it would be simple to
adopt something like Common Lisp's macro model.  I would not be in
favour of this, but it does have the advantage of tying down which
binding you are referring to because it is symbol based.

What I would prefer is a macro model that works harmoniously with the
module mechanism...and that's the difficulty.  Unfortunately the
"macros that work" model doesn't seem to hold up in this context.
Also, I and others that I have talked to don't want to be restricted
to syntax-rules style definitions, but rather want to be able to write
arbitrary expander functions.  The difficulty is in making the use of
the macro transparent to the client...which is why the principle of
the syntactic closure offers promise.  The EuLisp group have been
working on this issue for a couple of years (but only part-time) and
although we hve come near to a reasonable solution, it breaks down
with macro generating macros.

Fortunately, one of the group (Keith Playford) has now got the time to
look at the problem closely for a while and we are hopeful that we
might have a viable solution is a little while.

--Julian.

From info-dylan-request Tue Oct 20 18:29:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11206; Tue, 20 Oct 92 18:29:45 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11202; Tue, 20 Oct 92 18:29:43 -0400
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06841; Tue, 20 Oct 92 18:33:07 -0400
	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 AA16693; Tue, 20 Oct 92 18:29:20 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 182802.6967; Tue, 20 Oct 1992 18:28:02 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA02187; Tue, 20 Oct 92 14:17:04 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA01629; Tue, 20 Oct 92 14:17:02 PDT
Date: Tue, 20 Oct 92 14:17:02 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210202117.AA01629@eagle.sharebase.com>
To: dyer@eagle.sharebase.com, macrakis@osf.org
Subject: Re:  bounded, infinite ranges?
Cc: info-dylan@cambridge.apple.com

///    ...My reason: a range is over floats, yes?  Therefore no
///    enumerative approach would terminate (any range has an infinite
///    number of elements), even if one was provided.
/// 
/// Huh?  Floats are not reals -- after all, they're represented finitely.
/// 
/// As for the meaning of IEEE infinity, it is not really infinity either:
/// it stands for all numbers too large to represent in a given floating
/// type.

Programs I have written using this kind of knowledge are usually cryptic at
best.  Also, generating the elements of the range sequentially may be
non-trivial, and there are usually way too many to be useful.

///    These values that sit outside the system, "top" and "bottom" values
///    are usually very important to a program.  IMHO, it was unfortunate
///    that they were left out of the Dylan language spec.
/// 
/// I agree.  Dylan appears to use #f as a substitute for a void value in
/// some cases, e.g. while, until, bind with no forms.  This, and the fact
/// that ANY non-#f value is true, seem to be residual Lispisms.

Providing a structured "bottom" would present one aesthetically pleasing
solution to this.  Ergo (and 1 #f) --> {bottom: and of non-boolean: 1}.  This
also preserves the focus on values, rather than control mechanisms.

Treating bottom values as not inheritting <object> (since they aren't valid
objects, but rather 'outside the normal system') would make integration of
such values into an exception system a bit easier.  When no method can be
found to apply (no error correcting method), program execution could halt with
a back-trace (the bottom value having accumulated this on the way out...)
Either that or create {bottom: no applicable method}

Something like: {bottom: car {bottom: car ()}} would be the error from
(car (car '())).  Of course, pretty-printing such values would be important.

Arranging these bottom values into a class heterarchy (as Dylan already so
wisely does with exceptions, IMHO) gives programmers good flexibility insofar
as where to catch the error/exception.  Given that exceptions are exceptional,
too, the cost of backing out and collecting the trace seems minimal, especially
since that information should be accessible to the program...

/// Note that adding void to the possible returns of a function increases
/// function-return overhead, since of course you have to find some place
/// for the necessary bits....  (If you do it by some control convention,
/// there is still some overhead somewhere.)

Dylan already pays the full price of type tags.  I say take advantage of them.

///         -s

	-- Scot

P.S.  Perhaps we should be creating a new mailing-list, for Dylan specification
    requests and/or conversations.  I don't want to waste the signal-to-noise
    ratio in this group, but this stuff seems like an important consideration.
    Even though (unless we're all going to implement Dylan supersets -- another
    PL/I disaster! :-) they could be construed as pertaining to implementation.

      I hope someone at Apple hears this.  I should suspect that someone there
    will read all these messages...

From info-dylan-request Tue Oct 20 22:57:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16442; Tue, 20 Oct 92 22:57:45 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16438; Tue, 20 Oct 92 22:57:43 -0400
Received: from uu.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07200; Tue, 20 Oct 92 23:01:06 -0400
	for info-dylan@cambridge.apple.com
Received: from fpr.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
	id AA12505; Tue, 20 Oct 92 22:49:14 -0400
Message-Id: <9210210249.AA12505@uu.psi.com>
Received: by fpr (Mac/gnuucp v6.01) Tue, 20 Oct 1992 22:43:25 EDT
Date: Tue, 20 Oct 1992 22:37:10 -4
From: jim@fpr.com (James E. O'Dell)
Reply-To: jim@fpr.com
To: gensym!ireland!jra@harvard.harvard.edu
Subject: Fast Programs Sell
Cc: info-dylan@cambridge.apple.com
X-Mailer: Mac/gnuucp Mail Reader v6.02
Organization: Fort Pond Research

...

>There should not be a contradiction between ease of writing correct programs
>and ease of writing fast programs.  The first is an advantage, while the second
>is a requirement.

Very elegantly stated.

Jim

From info-dylan-request Wed Oct 21 08:27:26 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03337; Wed, 21 Oct 92 08:27:28 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03332; Wed, 21 Oct 92 08:27:26 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07862; Wed, 21 Oct 92 08:30:54 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210211230.AA07862@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa03477; 21 Oct 92 8:26:15 EDT
To: Jim Allard <gensym!ireland!jra@HARVARD.HARVARD.EDU>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: small integers 
In-Reply-To: Your message of Tue, 20 Oct 92 14:53:38 -0500.
             <9210201853.AA07352@ireland.gensym> 
Date: Wed, 21 Oct 92 08:26:08 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU



    ....  As a user of
    a high level language, my strong preference is for clear statements within the
    language specification of what optimization statements I can use and what I
    should expect from them.  Make-read-only and seal are such optimization
    operations, though the manual does not explicitly tell me what optimizations I
    can expect given what situations.  Optimized numeric operations are a
    requirement for most commercial code, and users of a language must be able to
    write code that they can be confident will run very fast in any reasonable
    implementation of the language.
    
I think it would be a serious mistake for the Dylan language to include a
required list of numeric optimizations at this early point (or any time
very soon).  Until we all get some experience with this, it won't be clear
what is easy, what is straightforward but perhaps too expensive for small
implementations, and what is very hard.  At present, we don't yet have a
complete system of types and declarations, or even full agreement on how to
handle bignums/integer-overflow.

The langauge does require a few optimizations, such as tail-recursion
optimization, but those are special and generally well-understood cases.

What might be useful is for someone like you (perhaps in consultation with
Rob Maclachlan and other compiler wizards) to group the optimizations that
you want to see into a few coherent levels.  Then implementors and
applications designers would have a convenient shorthand: "This code runs
well only a in Dylan implementation with level 2 arithmetic optimizations."
You might even cook up a test suite for each level, though you'd have to
either look at generated code or do some tricky timing stuff to see if
certain operations are handled the way you want.

It wouldn't matter too much whether these levels are blessed officially as
part of the Dylan language or are just a users-group thing, as long as
everyone who wants to play this implementation efficiency game agrees to a
common set of conventions.

-- 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
5000 Forbes Avenue
Pittsburgh, PA 15213

From moon Wed Oct 21 12:16:49 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16392; Wed, 21 Oct 92 12:16:52 -0400
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16386; Wed, 21 Oct 92 12:16:49 -0400
Message-Id: <9210211616.AA16386@cambridge.apple.com>
Date: Wed, 21 Oct 92 12:16:59 EDT
From: moon (David A. Moon)
To: dyer@eagle.sharebase.com (Scot Dyer)
Subject: Re: contractual programming
Cc: info-dylan@CAMBRIDGE.APPLE.COM

So how come you are ignoring the Dylan check-type function?

From info-dylan-request Wed Oct 21 13:39:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21503; Wed, 21 Oct 92 13:39:19 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21499; Wed, 21 Oct 92 13:39:18 -0400
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00172; Wed, 21 Oct 92 13:42:46 -0400
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Wed, 21 Oct 1992 18:38:25 +0100
Date: Wed, 21 Oct 92 18:40:29 BST
Message-Id: <11274.9210211740@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: contractual programming
To: info-dylan@cambridge.apple.com

jap writes:

> What I would prefer is a macro model that works harmoniously with the
> module mechanism...and that's the difficulty.  Unfortunately the
> "macros that work" model doesn't seem to hold up in this context.
> Also, I and others that I have talked to don't want to be restricted
> to syntax-rules style definitions, but rather want to be able to write
> arbitrary expander functions.  The difficulty is in making the use of
> the macro transparent to the client...which is why the principle of
> the syntactic closure offers promise.  The EuLisp group have been
> working on this issue for a couple of years (but only part-time) and
> although we hve come near to a reasonable solution, it breaks down
> with macro generating macros.

Some of the recent Scheme solutions look fairly reasonable, though
I still feel I need more experience with them before I can say whether
they do what I want.  

What is it that's wrong with "macros that work", by the way?
Do they break down in more cases than the Common Lisp approach?

-- jeff


From info-dylan-request Wed Oct 21 13:54:28 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21818; Wed, 21 Oct 92 13:54:30 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21813; Wed, 21 Oct 92 13:54:28 -0400
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00424; Wed, 21 Oct 92 13:57:57 -0400
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Wed, 21 Oct 1992 18:53:35 +0100
Date: Wed, 21 Oct 92 18:55:38 BST
Message-Id: <11287.9210211755@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: contractual programming
To: info-dylan@cambridge.apple.com
Cc: sef+@cs.cmu.edu

Scott Fahlman writes:

> The next step would be to build a table associating a "contract" predicate
> with each class.  A call to (CHECK-CONTRACT <object>) would retrieve the
> contract associated with that class (if any), then proceed as for ASSERT.
> Again, this is trivial to write as a portable library.
> 
> The final step would be to modify all the setters to run check-contract
> after they do their thing. 

The Eiffel approach is to have a condition (and "invariant") that
a method can assume is true when it starts and that it must make
sure is true when it finishes (or invokes another method? -- I'd
have to look up the details).  But it doesn't have to be true after
every modification to the object.  I think there must be a number
of cases where an object has to be in an invalid state temporarily.
For instance, maybe two changes have to be made before it's valid
again.

So I suspect that checking after every change might make life
more difficult than it ought to be.  However, I also suspect that
in Eiffel changing the value of a slot (or are they instance
variables?) does not involve calling a method.  This would make
it easier to have a rule about what methods have to preserve
that doesn't also apply to all modification performed within
a method invocation.  If all modifications are done via methods,
it's harder to draw such a neat distinction.

-- jeff

From info-dylan-request Wed Oct 21 14:57:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23731; Wed, 21 Oct 92 14:57:44 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23726; Wed, 21 Oct 92 14:57:43 -0400
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00748; Wed, 21 Oct 92 15:01:03 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210211901.AA00748@brazil.cambridge.apple.com>
Via: uk.ac.bath.maths; Wed, 21 Oct 1992 19:57:01 +0100
Received: from watt by haldane.maths.Bath.AC.UK id aa26375; 21 Oct 92 19:55 BST
To: jeff@aiai.edinburgh.ac.uk, info-dylan@cambridge.apple.com
In-Reply-To: Jeff Dalton's message of Wed, 21 Oct 92 18:40:29 BST <11274.9210211740@subnode.aiai.ed.ac.uk>
Subject: contractual programming
Date: Wed, 21 Oct 92 19:54:57 BST
From: jap@maths.bath.ac.uk
Sender: jap@maths.bath.ac.uk
Source-Info: From (or Sender) name not authenticated.

   Date: Wed, 21 Oct 92 18:40:29 BST
   From: Jeff Dalton <jeff@uk.ac.ed.aiai>
   Sender: info-dylan-request <info-dylan-request%com.apple.cambridge@com.apple.cambridge.brazil>

   [...]

   Some of the recent Scheme solutions look fairly reasonable, though
   I still feel I need more experience with them before I can say whether
   they do what I want.  

I seem to have heard you say that a few times in the past!

   What is it that's wrong with "macros that work", by the way?

I think the difficulty stems from them working in a single context and
"all at once".

   Do they break down in more cases than the Common Lisp approach?

CL never breaks down, it's just rather messy but at least you how it's
going to screw you.  Macros work in CL because it is symbol based (I
need a phrase here---please don't waste time flaming about the
accuracy of the term) and each symbol is tagged with where it comes
from by virtue of the packages.  Shadowing issues must be dealt with
explicitly by gensym.

In a module based system there is a stronger orientation towards
bindings and the difficulty is distinguishing between identifiers and
symbols---since at the abstract syntax level they seem the same.
Furthermore, because of quote a symbol which is data at one stage of
expansion can become an identifier at the next.  This is why some
special form like syntax-quote seems unavoidable...supporters of the
Wirth school of programming might argue that it is good documentation
to use a special operator.  In addition, there is no information
attached to a symbol/identifier to tell you which module it came from.

That aside, the main feature of the scheme we have been does go back
to Kohlbecker's '86 paper---at least, the way I read it---in that we
paint the identifiers resulting from the expansion of an expression
with the module in which the expander was defined.  This gives us
inter-module hygiene, but not local hygiene.  This model also fails
for macro-defining macros.  A hybrid of the labelling by depth of
expansion with labelling by modules might resolve intr-module hygiene.

Our aim is that an expander should be a black box in the same way as
any other exported function, so that the user need not be aware of the
modules on which the expansion result depends.  Put another way, you
should not have to import a module because it is part of the run-time
of the expanded expression, since that breaks the macro abstraction.
Because an expansion can, quite reasonably, refer to bindings visible
in its expander's defining module and these may either not be visible
or would create a name conflict in the use module we have to
circumvent the language defined module interface in a way similar to
the use of :: in CL packages.

This raises another important issue: what is the class of the result
of macro expansion?  Is it an s-expression or implementation-defined?
Is it re-readable?  If so, then we have an external representation to
break the module abstraction and poke around anywhere.  I do not want
this freedom, since it prevents a compiler taking any advantage of the
existence of modules, so although I want to be able to inspect the
result of an expansion I don't think I want to pay the price of being
able to key it in.

--Julian.


From info-dylan-request Wed Oct 21 15:54:50 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25795; Wed, 21 Oct 92 15:54:52 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25789; Wed, 21 Oct 92 15:54:50 -0400
Received: from SEF1.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01206; Wed, 21 Oct 92 15:58:20 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210211958.AA01206@brazil.cambridge.apple.com>
Received: from sef1.slisp.cs.cmu.edu by SEF1.SLISP.CS.CMU.EDU id aa11711;
          21 Oct 92 15:53:34 EDT
To: Jeff Dalton <jeff@AIAI.EDINBURGH.AC.UK>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: contractual programming 
In-Reply-To: Your message of Wed, 21 Oct 92 18:55:38 +0000.
             <11287.9210211755@subnode.aiai.ed.ac.uk> 
Date: Wed, 21 Oct 92 15:52:40 -0400
From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU


    > The final step would be to modify all the setters to run check-contract
    > after they do their thing. 
    
    The Eiffel approach is to have a condition (and "invariant") that
    a method can assume is true when it starts and that it must make
    sure is true when it finishes (or invokes another method? -- I'd
    have to look up the details).  But it doesn't have to be true after
    every modification to the object.  I think there must be a number
    of cases where an object has to be in an invalid state temporarily.
    For instance, maybe two changes have to be made before it's valid
    again.
    
OK, I can see that checking the object's contract after each modification
could well be the wrong thing.  There are places in the code where you want
to be sure that the contract is valid, and strecthes where it can't be.

Given this, I don't think it's obvious that method exit is always the
right place to check.  One might call several sub-methods that mess up an
object before some surrounding method fixes it again.

All of which brings me back to the view that the user should just insert
ASSERT or CHECK-CONTRACT calls where he thinks they belong.

-- 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
5000 Forbes Avenue
Pittsburgh, PA 15213
 

From info-dylan-request Wed Oct 21 16:06:37 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26234; Wed, 21 Oct 92 16:06:45 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26226; Wed, 21 Oct 92 16:06:37 -0400
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01303; Wed, 21 Oct 92 16:10:06 -0400
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA14431; Wed, 21 Oct 92 16:06:11 -0400
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA18725; Wed, 21 Oct 1992 16:04:12 -0400
Date: Wed, 21 Oct 1992 16:04:12 -0400
Message-Id: <9210212004.AA18725@lakatos.osf.org>
To: andyw@ibeam.ht.intel.com
In-Reply-To: Andy Wilson's message of Tue, 20 Oct 92 14:16 PDT <m0mhQvy-00018uC@ishark.intel.com>
Subject:  bounded, infinite ranges?
Cc: info-dylan@cambridge.apple.com
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

Andyw says:

   ...Naively, one might assume that (size range) could be defined as
   (/ (- (top range) (bottom range)) (by range)).  However, since
   floats are in fact represented finitely, if the "by:" step size for
   range is sufficiently small there might well be too few allowable
   bit patterns to represent the theoretical number of intervals in
   the range.

The elements of the range should be in general calculated as from+I*by
rather than as ((from+by)+by)+by+...  This also guarantees that you
don't get killed by round-off.  On the other hand, it does mean that
more than one element of the range may have the same value.

From info-dylan-request Wed Oct 21 23:12:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04189; Wed, 21 Oct 92 23:12:03 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04184; Wed, 21 Oct 92 23:12:01 -0400
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02405; Wed, 21 Oct 92 23:15:32 -0400
	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 AA21376; Wed, 21 Oct 92 23:11:22 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 231031.21419; Wed, 21 Oct 1992 23:10:31 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA11617; Wed, 21 Oct 92 14:30:33 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA00259; Wed, 21 Oct 92 14:30:31 PDT
Date: Wed, 21 Oct 92 14:30:31 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210212130.AA00259@eagle.sharebase.com>
To: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, jeff@AIAI.EDINBURGH.AC.UK
Subject: Re: contractual programming
Cc: info-dylan@CAMBRIDGE.APPLE.COM

WARNING:

I received a message from Julian asking me why I was neglecting the check-type
function.  I don't have my copy of the Dylan spec on my person right now, but
this could all be moot.

This is another long message, so if you're sick of this thread, junk it now.

/// OK, I can see that checking the object's contract after each modification
/// could well be the wrong thing.  There are places in the code where you want
/// to be sure that the contract is valid, and strecthes where it can't be.

This assumes that only classes will have contracts.  While class contracts are
an enormous help during development and maintenance (read: debugging), they are
not the entire focus of programming with contracts.  Assumptions for methods
about their parameters (like: X will not be NULL, or X will not be zero) can
be checked by hand, but this may disrupt the flow of the code if not given
a seperate 'slot' in the method.

Giving them a single spot allows them to function as documentation, although
they will never replace comments.  It can be extremely useful to know what
assumptions a method makes about its parameters.

/// Given this, I don't think it's obvious that method exit is always the
/// right place to check.  One might call several sub-methods that mess up an
/// object before some surrounding method fixes it again.

The issues are more complex than all this, yes.  Contracts for classes are
difficult to implement correctly without losing the elegance of the idea.
I might suggest checking method parameters when it is entered according to the
contracts of the classes specified for that method, and again for the return
value.  (The return value is a special case, though, and really deserves to
be treated separately -- as a contract of its own)

/// All of which brings me back to the view that the user should just insert
/// ASSERT or CHECK-CONTRACT calls where he thinks they belong.

Is this because of the difficulty in catching _every_ violation of a contract?
It's nice to have the guarantee that every violation will be reported (at
least for debugging -- so one knows the true root of the semantic error).

Perhaps a good compromise would be to turn contract checking off in a block
of code?  Like many LISP nuts, I'm not a big fan of set!/setq, and think that
object interfaces should be as impervious as possible to the deliterious
effects of modifying existing structures, ...but set! has its place, as does
setter in escaping the limitations of functional programming.  Perhaps a
'mute' or 'alter' form would be in order?

	(mute my-object
		slot1: new-slot1
		slot2: new-slot2)

Given this, I could be quite satisfied if contract checking were only done
after calls to make, mute, or when explicitly requested by the programmer.
This would only leave the [god-awful] task of figuring out how to conditionally
compile this code.  It might even (in a static program) be possible to pay
for contract checking only when one uses it.

This approach as the advantage of specifying where a contract check needs to
be done, and also may (I haven't thought about this too extensively) serve to
document code.  It would also encourage use of (setter slot-n), since it should
use it/them.

/// -- Scott

	-- Scot

==============================================================================

BTW, here are the three types of contracts that I consider crucial to a
    contractual programming style.

	1) As a check on the return value of a method or a function.

		(define-method sqrt ((x <something>))
			range-contract: (curry >= 0)
			;; range contracts as methods on the [un-named]
			;; return value
			;; this one has caught more bugs for me than any
			;; other...
			...
			)

	2) As a check on the parameters to a method or a function.

		(define-method sqrt ((x <something>))
			domain-contract: (>= x 0)
			;; domain contracts as s-expressions in the context
			;; of the method
			;; this one catches about as many bugs as a class
			;; contract, in _my_ code, at least...
			...
			)

	3) As a check of the validity of a class.  Note that verifying the
	   class must also include it's superclasses and subclasses.

Of course, it must also be possible to disable these checks without altering
the source code -- rather like C's #ifdef if restricted to DEBUG.

From info-dylan-request Wed Oct 21 23:28:31 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04662; Wed, 21 Oct 92 23:28:32 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04658; Wed, 21 Oct 92 23:28:31 -0400
Received: from ibeam.ht.intel.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02475; Wed, 21 Oct 92 23:32:02 -0400
	for info-dylan@cambridge.apple.com
Received: from ishark.intel.com by ibeam.intel.com with smtp
	(Smail3.1.26.7 #9) id m0mhqRZ-00020LC; Wed, 21 Oct 92 17:30 PDT
Received: by ishark.intel.com (Smail3.1.26.7 #9)
	id m0mhqUi-00018aC; Wed, 21 Oct 92 17:33 PDT
Message-Id: <m0mhqUi-00018aC@ishark.intel.com>
Date: Wed, 21 Oct 92 17:33 PDT
From: andyw@ibeam.ht.intel.com (Andy Wilson)
To: macrakis@osf.org
Subject: Re:  bounded, infinite ranges?
Cc: info-dylan@cambridge.apple.com


Stavros Macrakis writes:

-----------------------------------------------------------
The elements of the range should be in general calculated as from+I*by
rather than as ((from+by)+by)+by+...  This also guarantees that you
don't get killed by round-off.  On the other hand, it does mean that
more than one element of the range may have the same value.
-----------------------------------------------------------

Due to the miracle of floating point arithmetic, there is always
a value for "by:" where even from+I*by == from for at least some
part of the range.  This leads to one of two undesirable states:
1) more than one element of the range has the same value, as Stavros
suggests, or 2) the (size) of the range is not equal to the number
of values one would see iterating over it.

Again, these unpleasant facts of floating point life could be avoided
if from/up-to/by were constrained to be <rational>.

atw

From info-dylan-request Thu Oct 22 06:30:19 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12665; Thu, 22 Oct 92 06:30:21 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12661; Thu, 22 Oct 92 06:30:19 -0400
Received: from uu3.psi.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03035; Thu, 22 Oct 92 06:31:21 -0400
	for info-dylan@cambridge.apple.com
Received: from stowe.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA02871; Thu, 22 Oct 92 06:22:59 -0400
Received:  by stowe.bdsw.com (UUPC/extended 1.11v);
           Wed, 21 Oct 1992 08:57:33 EDT
X-Mailer: Cinetic Mail Manager V2.1
Date: Wed, 21 Oct 1992 08:57:30 EDT
From: duncan@stowe.bdsw.com (Rich Duncan)
Message-Id: <2ae553bf.stowe@stowe.bdsw.com>
To: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Dylan Constants 

>From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU
>
>
>     From the Dylan reference, there appears to be now way of defining a read
>    only constant ala the Common Lisp DEFCONSTANT macro. 
>
>The Dylan people at Apple have indicated that this will be fixed.  I don't
>know if they've yet settled on a choice of syntax, but I believe the
>current plan is that *all* the "define" forms will produce constants, and
>some new form will be created for defining non-constant variables.
>

Probably a good choice since that will make DEFINE semantically closer
to #DEFINE in C and %REPLACE in PL/I.

--
Rich Duncan                                  Internet: duncan@bdsw.com
Black Diamond Software, Inc.               Compuserve: 75540,2532
127 Wilton Road East                            Phone: (203)438-3050
Ridgefield, CT 06877                              Fax: (203)438-1447

From info-dylan-request Thu Oct 22 07:15:00 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13197; Thu, 22 Oct 92 07:15:03 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13191; Thu, 22 Oct 92 07:15:00 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03132; Thu, 22 Oct 92 07:18:32 -0400
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA02786; Thu, 22 Oct 92 07:12:16 -0400
Received: by easynet.crl.dec.com; id AA28435; Thu, 22 Oct 92 07:12:15 -0400
Message-Id: <9210221112.AA11572@taunton.crl.dec.com>
To: duncan@stowe.bdsw.com (Rich Duncan)
Cc: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Dylan Constants 
In-Reply-To: Your message of "Wed, 21 Oct 92 08:57:30 EDT."             <2ae553bf.stowe@stowe.bdsw.com> 
Date: Thu, 22 Oct 92 07:12:13 -0400
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Wed, 21 Oct 1992 08:57:30 EDT
    From: duncan@stowe.bdsw.com (Rich Duncan)
    >The Dylan people at Apple have indicated that this will be fixed.  I don't
    >know if they've yet settled on a choice of syntax, but I believe the
    >current plan is that *all* the "define" forms will produce constants, and
    >some new form will be created for defining non-constant variables.
    
    Probably a good choice since that will make DEFINE semantically closer
    to #DEFINE in C and %REPLACE in PL/I.

Eh?

I'm not sure what you think #define does, or what you think
DEFINE does, or what bit of the semantics you're comparing,
but in my ontology this doesn't compute.

You can re-#define #define's; they're not constant at all.
They perform semi-syntactic argument substitution, preserving
semantics not one whit, and often doing violence to the syntax.

It seems that instead this makes it closer to 'enum'.

I would hope that Dylan never does anything even vaguely resembling
the non-semantics of #define!

From info-dylan-request Thu Oct 22 14:24:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25250; Thu, 22 Oct 92 14:24:17 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25246; Thu, 22 Oct 92 14:24:15 -0400
Received: from argus.arc.nasa.gov by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04216; Thu, 22 Oct 92 14:27:52 -0400
	for info-dylan@cambridge.apple.com
Received: by argus.arc.nasa.gov (911016.SGI/1.34)
	id AA17042; Thu, 22 Oct 92 11:23:32 -0700
Date: Thu, 22 Oct 92 11:23:32 -0700
From: vck@argus.arc.nasa.gov (Vince Kerchner)
Message-Id: <9210221823.AA17042@argus.arc.nasa.gov>
Apparently-To: info-dylan@cambridge.apple.com

Please remove me from this list ASAP.
Thanks very much,
--Vince


From info-dylan-request Thu Oct 22 15:04:44 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25796; Thu, 22 Oct 92 15:04:46 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25792; Thu, 22 Oct 92 15:04:44 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04373; Thu, 22 Oct 92 15:08:22 -0400
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA06844; Thu, 22 Oct 92 15:04:03 -0400
Received: by easynet.crl.dec.com; id AA14108; Thu, 22 Oct 92 15:04:16 -0400
Message-Id: <9210221904.AA13977@peanut.crl.dec.com>
To: thant@void.esd.sgi.com
Cc: info-dylan@cambridge.apple.com
Subject: Re: bug in thomas regarding false 
In-Reply-To: Your message of "Thu, 22 Oct 92 12:02:14 PDT."             <9210221902.AA13600@void.esd.sgi.com> 
Date: Thu, 22 Oct 92 15:04:13 -0400
From: jmiller@crl.dec.com
X-Mts: smtp

> The empty list and #f are the same thing.  This contradicts p. 63.

I suspect you are using MIT Scheme to run Thomas.  This is a "bug" in
the MIT system that they keep promising to fix ... sorry.  You
shouldn't observe this under Gambit or Scheme->C.

--Jim

From info-dylan-request Thu Oct 22 15:16:42 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA25924; Thu, 22 Oct 92 15:16:56 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25919; Thu, 22 Oct 92 15:16:42 -0400
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04430; Thu, 22 Oct 92 15:20:12 -0400
	for info-dylan@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for jmiller@crl.dec.com id AA06519; Thu, 22 Oct 92 11:59:54 -0700
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:info-dylan@cambridge.apple.com id AA00125; Thu, 22 Oct 92 11:59:53 -0700
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:jmiller@crl.dec.com id AA13600; Thu, 22 Oct 92 12:02:15 -0700
Message-Id: <9210221902.AA13600@void.esd.sgi.com>
To: info-dylan@cambridge.apple.com
Cc: jmiller@crl.dec.com
Subject: bug in thomas regarding false
Date: Thu, 22 Oct 92 12:02:14 PDT
From: thant@void.esd.sgi.com


The empty list and #f are the same thing.  This contradicts p. 63.

(unless (list) "bug")
;Value: "bug"

Sorry if this is old news.

thant




From info-dylan-request Thu Oct 22 16:02:09 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26354; Thu, 22 Oct 92 16:02:10 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26350; Thu, 22 Oct 92 16:02:09 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04564; Thu, 22 Oct 92 16:05:45 -0400
	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 AA18474; Thu, 22 Oct 92 16:01:45 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 160030.16934; Thu, 22 Oct 1992 16:00:30 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA24523; Thu, 22 Oct 92 08:58:52 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA00686; Thu, 22 Oct 92 08:58:50 PDT
Date: Thu, 22 Oct 92 08:58:50 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210221558.AA00686@eagle.sharebase.com>
To: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, duncan@stowe.bdsw.com
Subject: Re: Dylan Constants
Cc: info-dylan@CAMBRIDGE.APPLE.COM

/// Probably a good choice since that will make DEFINE semantically closer
/// to #DEFINE in C and %REPLACE in PL/I.

What?!  I don't know about %REPLACE, but #define is at a completely different
level than the rest of C's syntax (the pre-processor), but Dylan's define forms
are just forms...

Also, they bind atoms, not lists of characters like #define.

	-- Scot

From info-dylan-request Thu Oct 22 16:02:25 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26367; Thu, 22 Oct 92 16:02:26 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26363; Thu, 22 Oct 92 16:02:25 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04568; Thu, 22 Oct 92 16:06:01 -0400
	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 AA18485; Thu, 22 Oct 92 16:01:47 -0400
Received: from woodstock.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 160028.16922; Thu, 22 Oct 1992 16:00:28 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA24467; Thu, 22 Oct 92 08:46:43 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA00651; Thu, 22 Oct 92 08:46:40 PDT
Date: Thu, 22 Oct 92 08:46:40 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210221546.AA00651@eagle.sharebase.com>
To: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, dyer@eagle.sharebase.com,
        jeff@AIAI.EDINBURGH.AC.UK
Subject: Re: contractual programming
Cc: info-dylan@CAMBRIDGE.APPLE.COM

I just read this posting, and I'd like to revise what I think doing this
_right_ would require.

/// Perhaps a good compromise would be to turn contract checking off in a
/// block of code?  Like many LISP nuts, I'm not a big fan of set!/setq,
/// and think that object interfaces should be as impervious as possible to
/// the deliterious effects of modifying existing structures, ...but set!
/// has its place, as does setter in escaping the limitations of functional
/// programming.  Perhaps a 'mute' or 'alter' form would be in order?
///
/// 	(mute my-object
/// 		slot1: new-slot1
/// 		slot2: new-slot2)

This form, as given, is not sufficiently general.  If functions return
multiple values, they may be hard to use (without bind).  Perhaps giving
mute more the form of 'bind' where multiple values can be accepted would
fix this.

More generic yet might be to make mute evaluate the forms it contains and
return the object muted...

/// Given this, I could be quite satisfied if contract checking were only
/// done after calls to make, mute, or when explicitly requested by the
/// programmer.  This would only leave the [god-awful] task of figuring out
/// how to conditionally compile this code.  It might even (in a static
/// program) be possible to pay for contract checking only when one uses
/// it.

Actually, even if the compiler/interpretter had only all or nothing as choices
for contract-checking, I don't think I'd mind.  It would force me not to use
contracts in such a way as to have to include any of them in a final product...

It's darn handy to be able to turn tracing/checking on and off on a class by
class or method by method basis, especially if some of the contracts are
expensive -- this way they are still there and can be used when you want them,
but your program won't just _crawl_ along _all_ the time.

Also, adding a 'mute' command won't do for all the stuff I'd want.  I'd also
want domain-contract: and range-contract: to be added as optional keyed
parameters to method, define-method, _and_ define-generic-function (where it
can be _really_ important, since enforcing the protocol of the function to
other programmers may save lots of time later by simply not kludging the code
in the first place)

	-- Scot

From info-dylan-request Thu Oct 22 16:04:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26384; Thu, 22 Oct 92 16:04:02 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26379; Thu, 22 Oct 92 16:04:01 -0400
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04588; Thu, 22 Oct 92 16:07:38 -0400
	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 AA02119; Thu, 22 Oct 92 16:03:37 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 160029.16927; Thu, 22 Oct 1992 16:00:29 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA24500; Thu, 22 Oct 92 08:56:18 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA00680; Thu, 22 Oct 92 08:56:15 PDT
Date: Thu, 22 Oct 92 08:56:15 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210221556.AA00680@eagle.sharebase.com>
To: andyw@ibeam.ht.intel.com, macrakis@osf.org
Subject: Re:  bounded, infinite ranges?
Cc: info-dylan@cambridge.apple.com

andyw@ibeam.ht.intel.com (Andy Wilson) writes:
/// Stavros Macrakis writes:
/// 
/// -----------------------------------------------------------
/// The elements of the range should be in general calculated as from+I*by
/// rather than as ((from+by)+by)+by+...  This also guarantees that you
/// don't get killed by round-off.  On the other hand, it does mean that
/// more than one element of the range may have the same value.
/// -----------------------------------------------------------
/// 
/// Due to the miracle of floating point arithmetic, there is always
/// a value for "by:" where even from+I*by == from for at least some
/// part of the range.  This leads to one of two undesirable states:
/// 1) more than one element of the range has the same value, as Stavros
/// suggests, or 2) the (size) of the range is not equal to the number
/// of values one would see iterating over it.

Really the only way to get around this is to work with the underlying exponent
and mantissa.  A good floating point representation will not permit the same
number two representations, and most will guarantee that the highest mantissa
with some exponent will be just less than the lowest mantissa with the next
possible exponent.  This means that the items in the list will not be evenly
spaced, but rather, logarithmically.

/// Again, these unpleasant facts of floating point life could be avoided
/// if from/up-to/by were constrained to be <rational>.

I think even <rational> might have it's problems...

This kind of confusion about floats is exactly why I don't like the idea of
enumerating a range of <real> -- Dylan programmers (mostly) don't have enough
experience in systems programming (read: C and assembly language) to really
have much a clue how this would work.  Most likely it will be an error, and if
it isn't, it should be written differently (at least in Dylan -- this style is
practical in 'C').

I also don't think one should be able to test for exact equality of floats.
(Ergo, id? should be valid, but = invalid).  At least not in a _high_level_
language.

/// atw
	-- Scot

From info-dylan-request Thu Oct 22 16:04:42 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26397; Thu, 22 Oct 92 16:04:44 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26393; Thu, 22 Oct 92 16:04:42 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04608; Thu, 22 Oct 92 16:08:18 -0400
	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 AA18443; Thu, 22 Oct 92 16:01:41 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 160031.16940; Thu, 22 Oct 1992 16:00:31 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA24539; Thu, 22 Oct 92 09:03:00 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA00692; Thu, 22 Oct 92 09:02:58 PDT
Date: Thu, 22 Oct 92 09:02:58 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210221602.AA00692@eagle.sharebase.com>
To: duncan@stowe.bdsw.com, rwk@crl.dec.com
Subject: Re: Dylan Constants
Cc: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, info-dylan@CAMBRIDGE.APPLE.COM

/// I would hope that Dylan never does anything even vaguely resembling
/// the non-semantics of #define!

C's two-level syntax may be great for pseudo-assembly coding, but it is a 
mistake I don't want to see in Dylan.

Even worse than #define though, is #ifdef -- most mature maintenance of C
programs is a constant battle with conditional compilations.  They're just too
easy to add.  "Oh?  It broke on VAX?  I'll just put in some VAX specific code.
Oh?  It broke on MVS?  I'll just..."  Sooner or later, there's nothing left
but the patches, and no matter how well they're commented, sooner or later one
finds oneself reading a function definition and saying "What?!" only to later
discover that a #ifdef on the previous page of code excluded that particular
definition from compilation.  Ug!

	-- Scot

From info-dylan-request Thu Oct 22 16:19:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26534; Thu, 22 Oct 92 16:19:44 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26530; Thu, 22 Oct 92 16:19:43 -0400
Received: from ibeam.ht.intel.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04814; Thu, 22 Oct 92 16:23:05 -0400
	for info-dylan@cambridge.apple.com
Received: from ishark.intel.com by ibeam.intel.com with smtp
	(Smail3.1.26.7 #9) id m0mi8wS-000203C; Thu, 22 Oct 92 13:15 PDT
Received: by ishark.intel.com (Smail3.1.26.7 #9)
	id m0mi8z9-00018fC; Thu, 22 Oct 92 13:18 PDT
Message-Id: <m0mi8z9-00018fC@ishark.intel.com>
Date: Thu, 22 Oct 92 13:18 PDT
From: andyw@ibeam.ht.intel.com (Andy Wilson)
To: dyer@eagle.sharebase.com
Subject: Re:  bounded, infinite ranges?
Cc: info-dylan@cambridge.apple.com

Scot Dyer writes:
---------------------------------------------------------------------
/// Again, these unpleasant facts of floating point life could be avoided
/// if from/up-to/by were constrained to be <rational>.

I think even <rational> might have it's problems...
---------------------------------------------------------------------

Rational arithmetic is always exact; maybe not fast, but exact.

atw

From info-dylan-request Thu Oct 22 16:20:33 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26557; Thu, 22 Oct 92 16:20:34 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26553; Thu, 22 Oct 92 16:20:33 -0400
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04826; Thu, 22 Oct 92 16:24:06 -0400
	for info-dylan@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for info-dylan@cambridge.apple.com id AA16456; Thu, 22 Oct 92 13:15:02 -0700
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:jmiller@crl.dec.com id AA03774; Thu, 22 Oct 92 13:14:57 -0700
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:info-dylan@cambridge.apple.com id AA13683; Thu, 22 Oct 92 13:17:25 -0700
Message-Id: <9210222017.AA13683@void.esd.sgi.com>
To: jmiller@crl.dec.com
Cc: info-dylan@cambridge.apple.com
Subject: Re: bug in thomas regarding false 
In-Reply-To: Your message of Thu, 22 Oct 92 15:04:13 -0400.
             <9210221904.AA13977@peanut.crl.dec.com> 
Date: Thu, 22 Oct 92 13:17:24 PDT
From: thant@void.esd.sgi.com



> > The empty list and #f are the same thing.  This contradicts p. 63.
> 
> I suspect you are using MIT Scheme to run Thomas.  This is a "bug" in
> the MIT system that they keep promising to fix ... sorry.  You
> shouldn't observe this under Gambit or Scheme->C.
> 
> --Jim
> 

I am indeed using MIT scheme.  Thank you for the information.

BTW, is it me, or are Thomas error messages a tad on the obscure
side?  Is there something I'm missing?

thant




From info-dylan-request Thu Oct 22 16:29:52 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26628; Thu, 22 Oct 92 16:29:53 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26622; Thu, 22 Oct 92 16:29:52 -0400
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04947; Thu, 22 Oct 92 16:33:28 -0400
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA16096; Thu, 22 Oct 92 16:27:31 EDT
Message-Id: <9210222027.AA16096@MIT.EDU>
Date: Thu, 22 Oct 92 15:50:20 EST
From: cfry@MIT.EDU (Christopher Fry)
To: jim@fpr.com
Subject: Re: Fast Programs Sell
Cc: gensym!ireland!jra@harvard.harvard.edu, info-dylan@cambridge.apple.com


> >There should not be a contradiction between ease of writing correct programs
> >and ease of writing fast programs.  The first is an advantage, while the second
> >is a requirement.

I agree that there is no contradiction here. In fact there's even a strong 
relationship between the two in that there's nothing slower than a broken program.

From info-dylan-request Thu Oct 22 17:07:24 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27075; Thu, 22 Oct 92 17:07:25 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27071; Thu, 22 Oct 92 17:07:24 -0400
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05128; Thu, 22 Oct 92 17:11:01 -0400
	for info-dylan@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for info-dylan@cambridge.apple.com id AA22978; Thu, 22 Oct 92 14:06:59 -0700
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:info-dylan@cambridge.apple.com id AA06060; Thu, 22 Oct 92 14:06:57 -0700
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:info-dylan@cambridge.apple.com id AA13758; Thu, 22 Oct 92 14:09:24 -0700
Message-Id: <9210222109.AA13758@void.esd.sgi.com>
To: info-dylan@cambridge.apple.com
Subject: false and types 
Date: Thu, 22 Oct 92 14:09:23 PDT
From: thant@void.esd.sgi.com



(define-class <foo> (<object>)
  
  (a type: <integer>
     init-value: #f))		    ;;  Why can you do this...
;Value: <foo>

(define foo (make <foo>))
;Value: foo

(a foo)
;Value: ()

((setter a) foo 3)
;Value: 3

((setter a) foo #f)		    ;; ...if you can't do this?


I figured out that I could do (singleton #f) to create a type for 
a method that dispatched specifically on false, but that isn't
a solution for the above.  In C and C++ NILL is kind of an exception
to the type system, and I thougth #f might play the same role.

What is the *right* thing to do?

thant





From info-dylan-request Thu Oct 22 17:23:33 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27222; Thu, 22 Oct 92 17:23:35 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27218; Thu, 22 Oct 92 17:23:33 -0400
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05203; Thu, 22 Oct 92 17:27:10 -0400
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA18386; Thu, 22 Oct 92 17:22:47 -0400
Received: by easynet.crl.dec.com; id AA19842; Thu, 22 Oct 92 17:22:45 -0400
Message-Id: <9210222122.AA14986@peanut.crl.dec.com>
To: thant@void.esd.sgi.com
Cc: info-dylan@cambridge.apple.com
Subject: Re: bug in thomas regarding false 
In-Reply-To: Your message of "Thu, 22 Oct 92 13:17:24 PDT."             <9210222017.AA13683@void.esd.sgi.com> 
Date: Thu, 22 Oct 92 17:22:43 -0400
From: jmiller@crl.dec.com
X-Mts: smtp

> BTW, is it me, or are Thomas error messages a tad on the obscure
> side?  Is there something I'm missing?

Probably our fault, not yours.  If you have particular ones you don't
like, feel free to let me know (probably send to info-thomas, not
info-dylan) and I'll see what we can do about fixing them.  We really
would like some feedback on thomas -- we haven't used it much yet,
we've just built it ...

--Jim

From alms Thu Oct 22 18:29:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27726; Thu, 22 Oct 92 18:29:38 -0400
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27722; Thu, 22 Oct 92 18:29:35 -0400
Message-Id: <9210222229.AA27722@cambridge.apple.com>
Date: Thu, 22 Oct 1992 18:35:12 -0500
To: info-dylan@cambridge.apple.com, thant@void.esd.sgi.com
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: false and types

At  2:09 PM 10/22/92 -0700, thant@void.esd.sgi.com wrote:
> (define-class <foo> (<object>)
>   
>   (a type: <integer>
>      init-value: #f))               ;;  Why can you do this...
> ;Value: <foo>

This is an error.  Thomas should not let you do this.

> (define foo (make <foo>))
> ;Value: foo
> 
> (a foo)
> ;Value: ()
> 
> ((setter a) foo 3)
> ;Value: 3
> 
> ((setter a) foo #f)                 ;; ...if you can't do this?
> 
> 
> I figured out that I could do (singleton #f) to create a type for 
> a method that dispatched specifically on false, but that isn't
> a solution for the above.  In C and C++ NILL is kind of an exception
> to the type system, and I thougth #f might play the same role.
> 
> What is the *right* thing to do?

In this case, the right thing to do in Dylan is to not supply an
init-value.  If the slot is accessed before a value is stored in
it, you will get an error.

If you want to supply an init value, it must be of the type specified
for the slot.

I thought the Dylan manual was clear about this, but a quick glance
shows that it doesn't spell out the restriction on init-value specifically.


From info-dylan-request Thu Oct 22 21:36:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29386; Thu, 22 Oct 92 21:36:15 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29382; Thu, 22 Oct 92 21:36:14 -0400
Received: from unet.Net.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05916; Thu, 22 Oct 92 21:39:48 -0400
	for info-dylan@cambridge.apple.com
Received: from zeus.net.com by unet (4.1/UNET-1.1)
	id AA02626; Thu, 22 Oct 92 18:37:51 PDT
Received: from bach.net.com by zeus.net.com (4.1/SMI-4.1)
	id AA25768; Thu, 22 Oct 92 18:35:02 PDT
Date: Thu, 22 Oct 92 18:35:02 PDT
From: bobt@zeus.net.com (Bob Tykulsker)
Message-Id: <9210230135.AA25768@zeus.net.com>
To: info-dylan@cambridge.apple.com
Subject: please subscribe

Please subscribe.

Robert Tykulsker,
Principal Engineer
Network Equipment Technologies, Inc.
800 Saginaw Drive, MS 23.2.3
Redwood City, CA 94063

phone:	+1 415 780 5149
fax:	+1 415 780 5001
email:	bobt@net.com

From info-dylan-request Fri Oct 23 05:33:10 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12591; Fri, 23 Oct 92 05:33:18 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12579; Fri, 23 Oct 92 05:33:10 -0400
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06532; Fri, 23 Oct 92 05:36:46 -0400
	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 AA03628; Fri, 23 Oct 92 05:32:47 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 053117.12863; Fri, 23 Oct 1992 05:31:17 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA27891; Thu, 22 Oct 92 14:29:12 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA01117; Thu, 22 Oct 92 14:29:10 PDT
Date: Thu, 22 Oct 92 14:29:10 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210222129.AA01117@eagle.sharebase.com>
To: andyw@ibeam.ht.intel.com, dyer@eagle.sharebase.com
Subject: Re:  bounded, infinite ranges?
Cc: info-dylan@cambridge.apple.com

Andy Wilson writes:
/// Scot Dyer writes:
/// ---------------------------------------------------------------------
/// /// Again, these unpleasant facts of floating point life could be avoided
/// /// if from/up-to/by were constrained to be <rational>.
/// 
/// I think even <rational> might have it's problems...
/// ---------------------------------------------------------------------
/// 
/// Rational arithmetic is always exact; maybe not fast, but exact.

Yes, but enumerating a finite rational range would be quite time-intensive, and
would require some special form, since it wouldn't (in all probability) fit in
memory on most machines.  Also, generating the members of a rational range in
sequential order (each new one greater or lesser for the whole range) is more
of a trick than for floats (in my eyes -- but my experience w/ rationals is
limitted)

I do agree that = should be defined for rationals, tho'.  And for indexed
loops (ala 'for') a rational restriction is probably best.  Either that, or
something like C's for, which would really be a 'while' extension.  Since the
iteration methods are defined for collections, a special version of 'for' could
be provided, like '(over <collection> <form>)' (for-each w/ <collection>?)

	-- Scot

From POOLE.GREG@AppleLink.Apple.COM Fri Oct 23 11:01:07 1992
Received: from alink-gw.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27416; Fri, 23 Oct 92 11:01:07 -0400
Received: by alink-gw.apple.com (5.65/27-Sep-1991-eef)
	id AA07989; Fri, 23 Oct 92 07:56:51 -0700
	for 
Date: 23 Oct 92 14:53 GMT
From: POOLE.GREG@AppleLink.Apple.COM (Portfolio Sys, Greg Poole,PRT)
Subject: oo announce-dylan request
To: ANNOUNCE-DYLAN@CAMBRIDGE.APPLE.COM
Message-Id: <719852224.9758896@AppleLink.Apple.COM>

 
announce-dylan-req@cambridge.apple.com@internet#
I am finding that the info-dylan-req INTERNET address is providing more
detailed information than I have the time to keep up with at present.
 
Could you please cancel me for the info-dylan discussions and instead add me to
the announce-dylan-req address? Thanks very much.
 
I am mainly interested in getting my hands on the "real" Dylan from Apple
whenever they see fit to let us developers play with it.
 
Greg Poole
Portfolio Software, Inc.
1200 South 4th Street
Fairfield, IA 52556
 
AppleLink: Poole.Greg
 
( announce-dylan-req@cambridge.apple.com@internet# )
 

From info-dylan-request Fri Oct 23 18:01:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08423; Fri, 23 Oct 92 18:01:48 -0400
Received: from goofy.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08419; Fri, 23 Oct 92 18:01:43 -0400
Received: from apple.com by goofy.apple.com with SMTP (5.61/27-Sep-1991-eef)
	id AA15563; Fri, 23 Oct 92 15:01:23 -0700
	for info-dylan@CAMBRIDGE.apple.com
Received: from uu3.psi.com by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA14566; Fri, 23 Oct 92 15:01:12 -0700
	for info-dylan@CAMBRIDGE.apple.com
Received: from stowe.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet)
	id AA19191; Fri, 23 Oct 92 17:56:53 -0400
Received:  by stowe.bdsw.com (UUPC/extended 1.11v);
           Fri, 23 Oct 1992 13:31:57 EDT
X-Mailer: Cinetic Mail Manager V2.1
Date: Fri, 23 Oct 1992 13:31:53 EDT
From: duncan@stowe.bdsw.com (Rich Duncan)
Message-Id: <2ae8370e.stowe@stowe.bdsw.com>
To: rwk@crl.dec.com
Cc: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Dylan Constants 

>From: Bob Kerns <rwk@crl.dec.com>
>
>I'm not sure what you think #define does, or what you think
>DEFINE does, or what bit of the semantics you're comparing,
>but in my ontology this doesn't compute...
>

>From: dyer@eagle.sharebase.com (Scot Dyer)
>
>What?!  I don't know about %REPLACE, but #define is at a completely 
different
>level than the rest of C's syntax (the pre-processor), but Dylan's define 
forms
>are just forms...

Thank you both for the clarification. My comment was SIMPLY an 
observation that if the designers change Dylan's DEFINE to mean "define 
read-only constant", it will be closer to one of the two primary uses of the 
C preprocessor's #define directive.

I am aware of the differences between DEFINE and #define, would never
advocate a Dylan version of cpp and think #define is a completely terrible
way of defining constants compared to DEFINE or DEFCONSTANT in CL. So did
the ANSI C committee, since the "const" directive in ANSI C can be used to
define a  typed, lexically scoped constant. So my response is "yes I
completely agree," and "you are preaching to the choir."

However, there is still a point that I feel is worth making. I believe the 
following statement (page 15) is crucial to Dylan's success:

	Dylan is not intended primarily for the Lisp community. The real 
	target audience of Dylan is application developers now using 
	languages such as C, C++ and Pascal...

If this is truly the target audience, then I can assure you that many of
these individuals are not concerned with "ontology". They define constants
with #define (for the most part), and while they may not appreciate the vast 
difference between #define and DEFINE (yet), they will appreciate the fact
that the only difference is to "drop the '#' and put parens around it."

This is just one microstep in the direction of achieving Dylan's goal
(mine too).

-Rich

--
Rich Duncan                                  Internet: duncan@bdsw.com
Black Diamond Software, Inc.               Compuserve: 75540,2532
127 Wilton Road East                            Phone: (203)438-3050
Ridgefield, CT 06877                              Fax: (203)438-1447

From info-dylan-request Fri Oct 23 20:26:50 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13698; Fri, 23 Oct 92 20:26:51 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13693; Fri, 23 Oct 92 20:26:50 -0400
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09021; Fri, 23 Oct 92 20:30:36 -0400
	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 AA10754; Fri, 23 Oct 92 20:26:31 -0400
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 202531.12134; Fri, 23 Oct 1992 20:25:31 EDT
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA11175; Fri, 23 Oct 92 16:04:33 PDT
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA01143; Fri, 23 Oct 92 16:04:30 PDT
Date: Fri, 23 Oct 92 16:04:30 PDT
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9210232304.AA01143@eagle.sharebase.com>
To: duncan@stowe.bdsw.com, rwk@crl.dec.com
Subject: Re: Dylan Constants
Cc: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU, info-dylan@CAMBRIDGE.APPLE.COM

On the topic of #define vs. DEFINE...

I don't want to be antagonistic about this, but the point of my message was
that they are so dissimilar as to create _confusion_ in the C community if
compared.  I speak as one of the rare members of both the C and LISP com-
munities.  For example, Dylan's DEFINE can be used recursively, and cannot
be used to 'splice' into a list, etc.  It exists as part of the language
semantics, not syntax.

Perhaps most C programmers don't make this distinction.  One I work with,
here at a company where LISP is not used (or respected), did however feel
that C function definitions were at quite a different level than #defines.

C functions, BTW, are one case where the C compiler (actually the linker),
does correctly implement symbolic constants.

	-- Scot

P.S.  I didn't want to post this to the net for fear of being offencive, but
I really think I should since most of the people there don't think C is a
decent language, and this might give them a little more respect for the
language.  It's not that I think it's a good application programming language
[since it's not], but rather that no portable assembly language exists yet,
so 'C' for systems programming cannot be supplanted.  Unless assembly language
or machine language comes into vogue in a big way, that is.

Also, I thought it might be important if there were 'C' programmers reading
this list...

From info-dylan-request Fri Oct 23 21:29:24 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15906; Fri, 23 Oct 92 21:29:32 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15896; Fri, 23 Oct 92 21:29:24 -0400
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09121; Fri, 23 Oct 92 21:33:12 -0400
	for info-dylan@cambridge.apple.com
Received: by world.std.com (5.65c/Spike-2.0)
	id AA16651; Fri, 23 Oct 1992 21:28:40 -0400
Date: Fri, 23 Oct 1992 21:28:08 -0400 (EDT)
From: Sam Hunting <shunting@world.std.com>
Subject: Re: dylan availability
To: kent@Camex.COM
Cc: rwk@crl.dec.com, uunet!cs.brown.edu!twl@uunet.UU.NET,
        alms@cambridge.apple.com, dylan-builders@cambridge.apple.com,
        info-dylan@cambridge.apple.com, kent@Camex.COM, kevin@scic.intel.com,
        twl@cs.brown.edu
In-Reply-To: <9209292325.AA08893@relay1.UU.NET>
Message-Id: <Pine.3.05.9210232108.A15849-9100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

No, please don't restrict!! I feel like an astronomer privileged to
witness the birth of a new star!

On Tue, 29 Sep 1992 kent@Camex.COM wrote:

> >If this discussion continues, perhaps we should restrict it to
> >dylan-builders or email...
> 
> Please don't, this is interesting stuff!  If I get a vote, I say keep going.
> 
> -kb




From info-dylan-request Sat Oct 24 02:39:55 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24927; Sat, 24 Oct 92 02:40:00 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24921; Sat, 24 Oct 92 02:39:55 -0400
Received: from inet-gw-1.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09605; Sat, 24 Oct 92 02:41:42 -0400
	for info-dylan@cambridge.apple.com
Received: by inet-gw-1.pa.dec.com; id AA13304; Fri, 23 Oct 92 23:35:09 -0700
Received: by myrtle.pa.dec.com; id AA20226; Fri, 23 Oct 92 23:33:40 -0700
Message-Id: <9210240633.AA20226@myrtle.pa.dec.com>
To: info-dylan@cambridge.apple.com
Subject: Multiple values in Dylan
Date: Fri, 23 Oct 92 23:33:40 -0700
From: meehan@src.dec.com
X-Mts: smtp


[I first sent these suggestions to Andrew Shalit at Apple back in 
June, long before there was a mailing list.] 

I like multiple values, but I'm sorry that Dylan has made them as 
sloppy as they are in Common Lisp.  I think they should be defined 
to be, in effect, the arguments to the current continuation: no more, 
no less. 

If we did this, then we wouldn't have to make all those hack-y exceptions 
about supplying extra #f's and ignoring extra values.   Forms where 
(VALUES) occurred in a position that required a value could be flagged 
as errors, just as any function call would if it had the wrong number 
of arguments.  If the continuation wants to ignore values, it can 
do so, just as functions can. 

This would also allow us to avoid having to say that there are actually 
two false values, #f and "no values".  Ugh. 

All the forms that don't produce "real" values, like FOR-loops 
whose end-tests are true but which have no result-forms, should be 
defined as returning no values.  If I want such a form to return #f, 
I can write #f. 

We should generalize COMPOSE so that it uses multiple values: if 
one function returns N values, then all N should be passed to the 
"next" function.  This would allow us to define (COMPOSE) [i.e., 
with no arguments] in a consistent fashion. This is what I used in 
Common Lisp: 

(defun compose (&rest fns)
  (if (null fns)
      #'values
      #'(lambda (&rest arglist)
          (labels ((z (fns)
                      (if (null (cdr fns))
                          (apply (car fns) arglist)
                          (multiple-value-call (car fns) (z (cdr fns))))))
            (z fns)))))


By the way, is there a way to write the Dylan equivalent of
    (multiple-value-call f exp)
other than
    (bind ((#rest args exp)) (apply f args)) ?
In Common Lisp, multiple-value-call was the primitive from which 
you could build multiple-value-bind, multiple-value-setq, etc. Of 
course, Dylan doesn't specify what type of sequence is produced by 
#rest (it needn't be a list, for example), so perhaps compilers are 
expected to provide an internal, efficient values->sequence function.


--Jim Meehan

From info-dylan-request Sat Oct 24 06:14:40 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27606; Sat, 24 Oct 92 06:14:42 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27602; Sat, 24 Oct 92 06:14:40 -0400
Received: from brahma.imag.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09779; Sat, 24 Oct 92 06:18:29 -0400
	for info-dylan@cambridge.apple.com
Received: from imag.imag.fr by brahma.imag.fr with SMTP id AA14032
  (5.65c8/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Sat, 24 Oct 1992 11:14:12 +0100
Received: by imag.imag.fr (5.54/5.17)
	id AA14027; Sat, 24 Oct 92 11:13:28 +0100
Message-Id: <9210241013.AA14027@imag.imag.fr>
Date: Fri, 23 Oct 1992 11:19:29 +0100
To: info-dylan@cambridge.apple.com
From: lafourca@imag.fr (mathieu Lafourcade)
Subject: Subscribe

I really want to subscribe.

Thank You

---
Lafourcade Mathieu
GETA (Groupe d'Etude pour la Traduction Automatique)
BP 53X, 38041 GRENOBLE CEDEX, FRANCE

Lafourca@imag.fr


From info-dylan-request Sat Oct 24 11:35:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03176; Sat, 24 Oct 92 11:35:03 -0400
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03167; Sat, 24 Oct 92 11:35:01 -0400
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10031; Sat, 24 Oct 92 11:38:53 -0400
	for info-dylan@cambridge.apple.com
Message-Id: <9210241538.AA10031@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa06979; 24 Oct 92 11:34:46 EDT
To: meehan@SRC.DEC.COM
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Multiple values in Dylan 
In-Reply-To: Your message of Fri, 23 Oct 92 23:33:40 -0800.
             <9210240633.AA20226@myrtle.pa.dec.com> 
Date: Sat, 24 Oct 92 11:34:35 -0400
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU

    
    I like multiple values, but I'm sorry that Dylan has made them as 
    sloppy as they are in Common Lisp.  I think they should be defined 
    to be, in effect, the arguments to the current continuation: no more, 
    no less. 
    
Jim,

Could you expand on your above suggestion a bit, perhaps with soem examples
of what common cases would look like?  Not being a Schemer, I'm not sure I
understand quite what you mean by "arguments to the current continuation"
and what this would imply in practice.

-- 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 Sun Oct 25 11:35:10 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05803; Sun, 25 Oct 92 11:35:11 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05799; Sun, 25 Oct 92 11:35:10 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11249; Sun, 25 Oct 92 11:39:00 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Sun, 25 Oct 1992 17:34:18 +0100
Received: by miles.ircam.fr, Sun, 25 Oct 1992 17:34:16 +0100
Date: Sun, 25 Oct 1992 17:34:16 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210251634.AA11719@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: new-value argument setter functions

I would very much prefer to have the new-value argument to setter
functions be the first argument instead of the last.  The problem is
felt when there are #rest args.  This results in ugly arglists (e.g.,
indices-and-new-value for `aref') and it gets ugly to strip off that
last arg and it costs in time and sometimes in space (for consing a
new list).  Maybe this wouldn't cost for builtin functions like `aref'
that have special compiler support, but it will for user-defined
functions.  The new-value argument really doesn't belong there: it's
not part of the #rest args.  One might want to dispatch on its type as
well (or at least be able to declare its type) and currently that is
impossible.  

-- jonathan bachrach

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


From info-dylan-request Sun Oct 25 12:25:24 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07047; Sun, 25 Oct 92 12:25:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07043; Sun, 25 Oct 92 12:25:24 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11317; Sun, 25 Oct 92 12:29:18 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Sun, 25 Oct 1992 18:24:39 +0100
Received: by miles.ircam.fr, Sun, 25 Oct 1992 18:24:37 +0100
Date: Sun, 25 Oct 1992 18:24:37 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199210251724.AA11745@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: declaration symmetry

The `for' and `for-each' iteration macros should permit the
declaration of the types of the iteration variables.  The `for' syntax
could be:

	for (({var-1 | (var-1 type-1)} init-1 step-1)
    	     ({var-2 | (var-2 type-2)} init-2 step-2) ...)
	    (end-test result-1 result-2 ...)
	    body-form1 body-form-2 ...

and similarly `for-each''s syntax could be:

	for-each (({var-1 | (var-1 type-1)} collection-1)
    	          ({var-2 | (var-2 type-2)} collection-2) ...)
	         (end-test result-1 result-2 ...)
	         body-form1 body-form-2 ...

-- jonathan bachrach

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


From info-dylan-request Sun Oct 25 18:23:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14512; Sun, 25 Oct 92 18:23:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14508; Sun, 25 Oct 92 18:23:30 -0500
Received: from inet-gw-1.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11787; Sun, 25 Oct 92 18:23:26 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-1.pa.dec.com; id AA00141; Sun, 25 Oct 92 15:16:08 -0800
Received: by myrtle.pa.dec.com; id AA21827; Sun, 25 Oct 92 15:14:42 -0800
Message-Id: <9210252314.AA21827@myrtle.pa.dec.com>
To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu
Cc: info-dylan@cambridge.apple.com
Subject: Re: Multiple values in Dylan 
In-Reply-To: Message of Sat, 24 Oct 92 11:34:35 -0400    from Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU    <9210241537.AA25226@inet-gw-1.pa.dec.com>
Date: Sun, 25 Oct 92 15:14:41 -0800
From: meehan@src.dec.com
X-Mts: smtp


I said:
    
    I think [multiple values] should be defined to be, in effect, 
    the arguments to the current continuation: no more, no less. 
        
You asked:
    
    Could you expand on your above suggestion a bit, perhaps with some examples
    of what common cases would look like?  Not being a Schemer, I'm not sure I
    understand quite what you mean by "arguments to the current continuation"
    and what this would imply in practice.

I'm sure there's nothing new in this explanation for you and most 
other readers of this mailing list, but I'll elaborate anyway.

Informally, the current continuation is "what happens next", or more
commonly, "what happens when we return from this function call".  I
said "in effect" because Dylan has no explicit representation of the
current continuation, although Lisp compilers have used
continuation-passing style at least since RABBIT (1978).  Scheme lets
you get at it directly, as a first-class object.  Common Lisp has
multiple-value-call, which lets you specify the continuation function.

When a function returns a single value, it has the effect of calling 
the current continuation with that value.  So when we're evaluating 
(+ (- a b) c), we can say that after we've computed the difference 
of a and b, we could pass that value to the current continuation, 
which is something like (lambda (x) (+ x c)).

My point is that (values x y) is simply a notation for calling 
the current continuation with two values instead of one. For example,
in (bind ((quotient remainder (floor a))) ...), once we're inside 
the call to floor, the current continuation is 
(lambda (quotient remainder) ...).  Clearly, that's a function of 
two arguments; they can have types, and we should be able to use #rest
and #key and all the other lambda-binding machinery.

So in this view, there's no such thing as "returning some values".
There's only "calling the continuation with some values", and whatever
rules Dylan uses for passing arguments to functions (e.g., it doesn't
automatically ignore extra parameters or supply #f for missing
parameters) it should use for multiple values: "no more, no less".

My general belief is that Lisp has suffered both internally and
externally because of such sloppiness: "floor returns two values, but
you can ignore the second one if you want, and if you ask for more
than two values, you'll get some #f's thrown in for free." Internally,
it leads to error-prone code, and it prevents the compiler from
catching a certain class of errors.  Externally, people from "tighter"
languages (pick your favorite) see this, and it merely reaffirms their
belief that Lisp is, was, and forever shall be inefficient, not
commercially viable, no competition for "real" languages like C, etc.,
etc., etc.

I don't think the language need be completely inflexible, of course.
It's very handy to be able, for instance, to add reals and integers
without explicitly having to coerce the integer into a real, and I
think most people would agree that it's worth the price we pay for
that.  But I've never heard a convincing argument in favor of the
sloppy binding for multiple values, or, for that matter, for NOT
declaring types of variables.  [In a recent comment on the Lisp FAQ, I
took exception to the recommendation that we shouldn't "add
declarations to code until it is fully debugged".  That's the sort of
attitude, in my opinion, that's gets us into a lot of trouble.]

Of course, there's a cost to being hard-nosed.  If we follow my
suggestion, you won't be able to write (bind ((q (floor a))) ...), or
even (+ (floor a) b), since the wrong number of values are being
"returned".  Of course, this one is easy to fix, by defining a
function ("floor1") that returns only the first value, just as MODULO
returns only the second value.

To do this "right", I'd also want to allow BIND to use #key (and maybe
even #next), thus getting rid of the distinction between the
variable-binding protocols of BIND and METHOD.  Indeed, I believe BIND
is the only way in Dylan to get effect of multiple-value-call; if BIND
can't use #key, then the only way to use BIND call a method that takes
keywords is to use #rest and APPLY; what a waste!

--Jim

From info-dylan-request Sun Oct 25 18:35:23 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14568; Sun, 25 Oct 92 18:35:24 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14564; Sun, 25 Oct 92 18:35:23 -0500
Received: from inet-gw-1.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11847; Sun, 25 Oct 92 18:37:25 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-1.pa.dec.com; id AA00705; Sun, 25 Oct 92 15:30:47 -0800
Received: by myrtle.pa.dec.com; id AA21849; Sun, 25 Oct 92 15:29:20 -0800
Message-Id: <9210252329.AA21849@myrtle.pa.dec.com>
To: info-dylan@cambridge.apple.com
Subject: Result-forms
Date: Sun, 25 Oct 92 15:29:19 -0800
From: meehan@src.dec.com
X-Mts: smtp


The manual doesn't say whether the iteration variables in FOR, FOR-EACH, 
and DOTIMES are bound when the result-forms are evaluated.  It should 
should say that they're bound (and if so, to what), or that they're 
not bound (i.e., they revert to previous bindings, if any); I think 
it will be awkward for programmers if you say that the variables 
may or may not be bound, depending on the implementation. 

Personally, I'd vote that the variables be bound to the values they 
had when the end-test "became" true, but that may present type-problems 
if we adopt Jonathan Bachrach's suggestion ("declaration symmetry", 
which I support.

Minor, predictable peeve: if there aren't any result-forms, the iteration 
constructs should return no values rather than #f.

From info-dylan-request Sun Oct 25 23:49:49 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19397; Sun, 25 Oct 92 23:49:50 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19393; Sun, 25 Oct 92 23:49:49 -0500
Received: from inet-gw-1.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12114; Sun, 25 Oct 92 23:51:52 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-1.pa.dec.com; id AA11022; Sun, 25 Oct 92 20:45:14 -0800
Received: by myrtle.pa.dec.com; id AA22105; Sun, 25 Oct 92 20:43:46 -0800
Message-Id: <9210260443.AA22105@myrtle.pa.dec.com>
To: info-dylan@cambridge.apple.com
Subject: Question about MAKE
Date: Sun, 25 Oct 92 20:43:46 -0800
From: meehan@src.dec.com
X-Mts: smtp


The book says, "Dylan does not specify whether the value returned 
must be a newly allocated instance, or whether MAKE is permitted 
to return a previously created instance.  If a new instance is allocated, 
MAKE will call INITIALIZE on the instance before returning it." [page 
51]

1. If MAKE returns a previously created instance, this has got to 
be something that's no longer visible to the program, right? E.g., 
something that the garbage collector has tossed back into a weak-pointer 
pool.  As stated, it sounds as though MAKE could return the same 
object every time!

2. I expect that INITIALIZE will typically be used to assign non-constant 
values to slots, to attach pointers to the new object, etc.  If so, 
then it would seem to make sense for MAKE to call INITIALIZE even 
when it's returning some "recycled" object, no?


From info-dylan-request Mon Oct 26 03:06:50 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22804; Mon, 26 Oct 92 03:06:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22800; Mon, 26 Oct 92 03:06:50 -0500
Received: from ns3.hq.eso.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12345; Mon, 26 Oct 92 03:10:45 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9210260806.AA15580@ns3.hq.eso.org>
Received: from localhost.hq.eso.org by ns3.hq.eso.org (4.1/ eso-1.1)
	id AA15580; Mon, 26 Oct 92 09:06:09 +0100
To: info-dylan@cambridge.apple.com
Subject: Vectorizing Dylan?
Date: Mon, 26 Oct 92 09:06:08 +0100
From: hmadorf@eso.org

Dear Dylan-enthusiasts,

I recently vectorized MacintoshCL via a set of macros. Now I
can say e.g. (+ a b) where a and b may be numbers OR vectors, or 
lists, or arrays of numbers and the code does the obvious thing. 
Or I can say (sin a) and if a is a vector the Sine function of all 
elements will be computed and a vector returned.

Since you are working on a language for the 1990ies, where I expect
to see more vector processors than today, I wonder whether it would 
not be appropriate to include vectorizing constructs into Dylan from
the beginning. It would certainly facilitate the high-level
implementation of many numerical algorithms that can be expressed on
the abstraction level of mathematical vectors or arrays.

I can provide further information on VectorCL if needed.

Cheers
Hans-Martin Adorf
ST-ECF/ESO
Garching b Muenchen
FRG

From info-dylan-request Mon Oct 26 09:35:07 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01116; Mon, 26 Oct 92 09:35:09 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01111; Mon, 26 Oct 92 09:35:07 -0500
Received: from RIVERSIDE.SCRC.Symbolics.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12777; Mon, 26 Oct 92 09:39:12 -0500
	for Info-dylan@cambridge.apple.com
Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 936267; 26 Oct 1992 09:36:19-0500
Date: Mon, 26 Oct 1992 09:37-0500
From: Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
Subject: Question about MAKE
To: meehan@src.dec.com
Cc: Info-dylan@CAMBRIDGE.APPLE.COM
In-Reply-To: <9210260443.AA22105@myrtle.pa.dec.com>
Message-Id: <19921026143704.2.NAHA@LILIKOI.SCRC.Symbolics.COM>

    Date: Sun, 25 Oct 1992 23:43 EST
    From: meehan@src.dec.com


    The book says, "Dylan does not specify whether the value returned 
    must be a newly allocated instance, or whether MAKE is permitted 
    to return a previously created instance.  If a new instance is allocated, 
    MAKE will call INITIALIZE on the instance before returning it." [page 
    51]

    1. If MAKE returns a previously created instance, this has got to 
    be something that's no longer visible to the program, right? 

Wrong.

Consider that I have some collection of named objects and I want to
insure that no two objects will be created with the same name.  My
application could use MAKE in the same way that the Lisp reader uses
INTERN to insure that if will get a preexisting symbol of a given name
rather than creating another one.

The authors of Dylan had the forseight to not add a gratuitous
restriction to MAKE which would constrain it to return a new object each
time.

								 E.g., 
    something that the garbage collector has tossed back into a weak-pointer 
    pool.  As stated, it sounds as though MAKE could return the same 
    object every time!

If the garbage collector has reclaimed something, it is gone.  The
storage may, and most likely will get reallocated, but the object
occupying that recycled storage is a new object, not some resurrected
zombie undead object.

    2. I expect that INITIALIZE will typically be used to assign non-constant 
    values to slots, to attach pointers to the new object, etc.  If so, 
    then it would seem to make sense for MAKE to call INITIALIZE even 
    when it's returning some "recycled" object, no?

No.  This could well be the wrong behavior for the case I outlined
above.  I can't imagine any circumstance inwhich it would be the right
behavior.

From info-dylan-request Mon Oct 26 09:35:41 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01149; Mon, 26 Oct 92 09:35:43 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01145; Mon, 26 Oct 92 09:35:41 -0500
Received: from RIVERSIDE.SCRC.Symbolics.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12787; Mon, 26 Oct 92 09:39:46 -0500
	for Info-dylan@cambridge.apple.com
Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 936268; 26 Oct 1992 09:36:54-0500
Date: Mon, 26 Oct 1992 09:37-0500
From: Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
Subject: Question about MAKE
To: meehan@src.dec.com
Cc: Info-dylan@CAMBRIDGE.APPLE.COM
In-Reply-To: <9210260443.AA22105@myrtle.pa.dec.com>
Supersedes: <19921026143704.2.NAHA@LILIKOI.SCRC.Symbolics.COM>
Message-Id: <19921026143740.3.NAHA@LILIKOI.SCRC.Symbolics.COM>

    Date: Sun, 25 Oct 1992 23:43 EST
    From: meehan@src.dec.com


    The book says, "Dylan does not specify whether the value returned 
    must be a newly allocated instance, or whether MAKE is permitted 
    to return a previously created instance.  If a new instance is allocated, 
    MAKE will call INITIALIZE on the instance before returning it." [page 
    51]

    1. If MAKE returns a previously created instance, this has got to 
    be something that's no longer visible to the program, right? 

Wrong.

Consider that I have some collection of named objects and I want to
insure that no two objects will be created with the same name.  My
application could use MAKE in the same way that the Lisp reader uses
INTERN to insure that if will get a preexisting symbol of a given name
rather than creating another one.

The authors of Dylan had the forseight to not add a gratuitous
restriction to MAKE which would constrain it to return a new object each
time.

								 E.g., 
    something that the garbage collector has tossed back into a weak-pointer 
    pool.  As stated, it sounds as though MAKE could return the same 
    object every time!

If the garbage collector has reclaimed something, it is gone.  The
storage may, and most likely will get reallocated, but the object
occupying that recycled storage is a new object, not some resurrected
zombie undead object.

    2. I expect that INITIALIZE will typically be used to assign non-constant 
    values to slots, to attach pointers to the new object, etc.  If so, 
    then it would seem to make sense for MAKE to call INITIALIZE even 
    when it's returning some "recycled" object, no?

No.  This could well be the wrong behavior for the case I outlined
above.  I can't imagine any circumstance inwhich it would be the right
behavior.

From info-dylan-request Mon Oct 26 10:23:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02158; Mon, 26 Oct 92 10:23:37 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02151; Mon, 26 Oct 92 10:23:35 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13054; Mon, 26 Oct 92 10:27:41 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9210261527.AA13054@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa08876; 26 Oct 92 10:23:28 EST
To: hmadorf@eso.org
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Vectorizing Dylan? 
In-Reply-To: Your message of Mon, 26 Oct 92 09:06:08 +0100.
             <9210260806.AA15580@ns3.hq.eso.org> 
Date: Mon, 26 Oct 92 10:23:16 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    Since you are working on a language for the 1990ies, where I expect
    to see more vector processors than today, I wonder whether it would 
    not be appropriate to include vectorizing constructs into Dylan from
    the beginning.

This sounds like a good job for a library.  The nice thing about the way
Dylan is being organized is that there's no sharp division between what's
"in" the language and what is available as a well-known and widely used
library.  The trick will be to get this package out early and in solid
shape.

The only tricky thing will be to make sure that the rules for sealing and
inlining are such that a compiler can take advantage of any primitive
high-speed vector operations that a machine might support.  But this same
requirement comes up all over the place (for example, in a machine whose
ALU supports SIN or MULTIPLY/ACCUMULATE or operations on primitive ASCII
strings), and I'm sure it's being worked on by the Dylan designers.

-- Scott

From moon Mon Oct 26 13:46:19 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05381; Mon, 26 Oct 92 13:46:22 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05377; Mon, 26 Oct 92 13:46:19 -0500
Message-Id: <9210261846.AA05377@cambridge.apple.com>
Date: Mon, 26 Oct 92 13:46:59 EDT
From: moon (David A. Moon)
To: meehan@src.dec.com
Subject: Re: Multiple values in Dylan 
Cc: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu, info-dylan@cambridge.apple.com

> Date: Sun, 25 Oct 92 15:14:41 -0800
> From: meehan@src.dec.com

Scott Fahlman asked for examples, and you didn't really provide
any.  I think it's incumbent on anyone proposing significant language
changes to give examples of how common usages would change under
the proposal. Let me ask you how you propose the following expression
should be written:

  (* y (ceiling/ x y))

You touched on that in this paragraph:

> Of course, there's a cost to being hard-nosed.  If we follow my
> suggestion, you won't be able to write (bind ((q (floor a))) ...), or
> even (+ (floor a) b), since the wrong number of values are being
> "returned".  Of course, this one is easy to fix, by defining a
> function ("floor1") that returns only the first value, just as MODULO
> returns only the second value.

but I'm not sure that adding a bunch more functions to the language is
the direction we want to go.  Maybe you should propose the exact set of
functions to be added and then we can see whether it seems like too much
for a language that is trying to be small in both implementation and
cost of learning.

I'd also like to know whether you propose to keep the function values
a function or change it to a special form.  That has an important effect
on your proposal, too, doesn't it?

I don't think we are necessarily inflexible about keeping Dylan multiple 
values the way they are, but on the other hand we don't want to keep 
redesigning this language forever, so to be effective a proposed change has to 
be argued in a really convincing way.  I don't think you've done that yet for 
this change.  However, I don't want to prejudge this issue; this part of the 
current language definition is certainly ugly and if you can make a convincing 
case for something better, that would be great.

--Dave

PS: I'd like to see more proposals to remove things from the language rather 
than adding things.

From info-dylan-request Mon Oct 26 14:33:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05904; Mon, 26 Oct 92 14:33:14 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05900; Mon, 26 Oct 92 14:33:14 -0500
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00435; Mon, 26 Oct 92 14:37:17 -0500
	for info-dylan@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for info-dylan@cambridge.apple.com id AA02628; Mon, 26 Oct 92 11:33:05 -0800
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:info-dylan@cambridge.apple.com id AA12109; Mon, 26 Oct 92 11:33:00 -0800
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:info-dylan@cambridge.apple.com id AA19151; Mon, 26 Oct 92 11:35:31 -0800
Message-Id: <9210261935.AA19151@void.esd.sgi.com>
To: info-dylan@cambridge.apple.com
Cc: thant@void.esd.sgi.com
Subject: setter problem
Date: Mon, 26 Oct 92 11:35:30 PST
From: thant@void.esd.sgi.com


Why doesn't this work?


(define-class <foo> (<object>)
  (a)
  (b))
;Value: <foo>

(define foo (make <foo>))
;Value: foo

((setter a) foo "apple")
;Value: "apple"

((setter b) foo "ball")
;Value: "ball"

(define-method see-foo (m (f <foo>))
  (m f))
;Value: see-foo

(see-foo a foo)
;Value: "apple"

(see-foo b foo)
;Value: "ball"


(define-method set-foo (m (f <foo>) i)
  ((setter m) f i))
;Value: set-foo

(set-foo a foo "aardvark")
;Error: unbound variable dylan:setter/m/




From info-dylan-request Mon Oct 26 14:54:41 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06110; Mon, 26 Oct 92 14:54:42 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06106; Mon, 26 Oct 92 14:54:41 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00546; Mon, 26 Oct 92 14:58:50 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA06103; Mon, 26 Oct 92 14:54:39 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA17931; Mon, 26 Oct 1992 14:52:37 -0500
Date: Mon, 26 Oct 1992 14:52:37 -0500
Message-Id: <9210261952.AA17931@lakatos.osf.org>
To: dyer@eagle.sharebase.com
Cc: andyw@ibeam.ht.intel.com, dyer@eagle.sharebase.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Scot Dyer's message of Thu, 22 Oct 92 14:29:10 PDT <9210222129.AA01117@eagle.sharebase.com>
Subject:  bounded, infinite ranges?
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

Dyer writes:

   ... enumerating a finite rational range would be quite time-intensive, and
   would require some special form, since it wouldn't (in all probability) fit in
   memory on most machines.  Also, generating the members of a rational range in
   sequential order (each new one greater or lesser for the whole range) is more
   of a trick than for floats...

I don't see any problem here.  Although any non-trivial _interval_
contains an infinity of rationals, a Dylan _range_ has an explicit
step.  A range from A/B by C/D consists simply of A/B + i*C/D (call
that R[i]).

Presumably, you calculate R[i] by first expressing A/B and C/D over a
common denominator:

	G = GCD(B,D)
	N[0] = A*D/G
	D = B*D/G
	Del = C*B/G

Then,

	N[i+1] = N[i] + Del

	R[i] = (N[i] / GCD(N[i],D) ) / (D / GCD(N[i],D))

   -s




From alms Mon Oct 26 16:10:01 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06929; Mon, 26 Oct 92 16:10:05 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06925; Mon, 26 Oct 92 16:10:01 -0500
Message-Id: <9210262110.AA06925@cambridge.apple.com>
Date: Mon, 26 Oct 1992 16:16:09 -0500
To: info-dylan@cambridge.apple.com, thant@void.esd.sgi.com
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: setter problem
Cc: thant@void.esd.sgi.com

At 11:35 AM 10/26/92 -0800, thant@void.esd.sgi.com wrote:
> Why doesn't this work?
> 
> 
> (define-class <foo> (<object>)
>   (a)
>   (b))
> ;Value: <foo>
> 
> (define foo (make <foo>))
> ;Value: foo
> 
> ((setter a) foo "apple")
> ;Value: "apple"
> 
> ((setter b) foo "ball")
> ;Value: "ball"
> 
> (define-method see-foo (m (f <foo>))
>   (m f))
> ;Value: see-foo
> 
> (see-foo a foo)
> ;Value: "apple"
> 
> (see-foo b foo)
> ;Value: "ball"
> 
> 
> (define-method set-foo (m (f <foo>) i)
>   ((setter m) f i))
> ;Value: set-foo
> 
> (set-foo a foo "aardvark")
> ;Error: unbound variable dylan:setter/m/

This doesn't work because setter isn't a function.  The definition
of set-foo uses a variable

   (setter m)

Of course, there is no such variable.  Your program acts as if setter
is a function which takes one function and returns another, which is
not the case.  Setter is syntax.

We're considering changing setter syntax so that it doesn't look so
much like an operation.  Your mistake probably wouldn't have come up
if (setter a) were spelled set-a.

  -Andrew


From info-dylan-request Mon Oct 26 16:39:46 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07267; Mon, 26 Oct 92 16:39:47 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07263; Mon, 26 Oct 92 16:39:46 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00985; Mon, 26 Oct 92 16:43:55 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Mon, 26 Oct 1992 21:39:30 +0000
Date: Mon, 26 Oct 92 21:41:47 GMT
Message-Id: <22596.9210262141@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: setter problem
To: info-dylan@cambridge.apple.com

> This doesn't work because setter isn't a function.  The definition
> of set-foo uses a variable
> 
>    (setter m)
> 
> Of course, there is no such variable.  Your program acts as if setter
> is a function which takes one function and returns another, which is
> not the case.  Setter is syntax.

But it is a function of exactly that sort in T (and EuLisp),
which may explain why someone might expect it to be a function.

And, for what it's worth, I prefer the T approach.

Common Lisp needs somethign more general and macro-like, rather
than a function->function function, for only a few cases such as
LDB.

-- jeff

From alms Mon Oct 26 16:41:56 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07303; Mon, 26 Oct 92 16:41:59 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07299; Mon, 26 Oct 92 16:41:56 -0500
Message-Id: <9210262141.AA07299@cambridge.apple.com>
Date: Mon, 26 Oct 1992 16:48:02 -0500
To: info-dylan@cambridge.apple.com, Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: setter problem

At  9:41 PM 10/26/92 +0000, Jeff Dalton wrote:
> > This doesn't work because setter isn't a function.  The definition
> > of set-foo uses a variable
> > 
> >    (setter m)
> > 
> > Of course, there is no such variable.  Your program acts as if setter
> > is a function which takes one function and returns another, which is
> > not the case.  Setter is syntax.
> 
> But it is a function of exactly that sort in T (and EuLisp),
> which may explain why someone might expect it to be a function.
> 
> And, for what it's worth, I prefer the T approach.
> 
> Common Lisp needs somethign more general and macro-like, rather
> than a function->function function, for only a few cases such as
> LDB.

Both the Common Lisp and T approaches have the problem that you cannot
export a getter without also exporting the setter.  Dylan does not
have this problem.

  -Andrew


From alms Mon Oct 26 16:58:39 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07533; Mon, 26 Oct 92 16:58:43 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07529; Mon, 26 Oct 92 16:58:39 -0500
Message-Id: <9210262158.AA07529@cambridge.apple.com>
Date: Mon, 26 Oct 1992 17:04:45 -0500
To: hmadorf@eso.org, Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Vectorizing Dylan?
Cc: info-dylan@CAMBRIDGE.APPLE.COM

At 10:23 AM 10/26/92 -0500, Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU wrote:
>     Since you are working on a language for the 1990ies, where I expect
>     to see more vector processors than today, I wonder whether it would 
>     not be appropriate to include vectorizing constructs into Dylan from
>     the beginning.
> 
> This sounds like a good job for a library.  The nice thing about the way
> Dylan is being organized is that there's no sharp division between what's
> "in" the language and what is available as a well-known and widely used
> library.  The trick will be to get this package out early and in solid
> shape.
> 
> The only tricky thing will be to make sure that the rules for sealing and
> inlining are such that a compiler can take advantage of any primitive
> high-speed vector operations that a machine might support.  But this same
> requirement comes up all over the place (for example, in a machine whose
> ALU supports SIN or MULTIPLY/ACCUMULATE or operations on primitive ASCII
> strings), and I'm sure it's being worked on by the Dylan designers.

Yes, it is.  The purpose of sealing is to allow this kind of efficient
compilation.

  -Andrew


From info-dylan-request Mon Oct 26 17:34:17 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07967; Mon, 26 Oct 92 17:34:18 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07961; Mon, 26 Oct 92 17:34:17 -0500
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01312; Mon, 26 Oct 92 17:38:21 -0500
	for alms@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for info-dylan@cambridge.apple.com id AA26816; Mon, 26 Oct 92 14:34:06 -0800
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:alms@cambridge.apple.com id AA16587; Mon, 26 Oct 92 14:20:06 -0800
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:jeff@aiai.edinburgh.ac.uk id AA19470; Mon, 26 Oct 92 14:22:37 -0800
Message-Id: <9210262222.AA19470@void.esd.sgi.com>
To: alms@cambridge.apple.com (Andrew LM Shalit)
Cc: info-dylan@cambridge.apple.com, Jeff Dalton <jeff@aiai.edinburgh.ac.uk>,
        thant@void.esd.sgi.com
Subject: Re: setter problem 
In-Reply-To: Your message of Mon, 26 Oct 92 16:48:02 -0500.
             <9210262141.AA07299@cambridge.apple.com> 
Date: Mon, 26 Oct 92 14:22:36 PST
From: thant@void.esd.sgi.com



Okay, so (setter m) is actually a variable in and of itself.  But that
doesn't make sense with (set! (m foo) item).  Is there similar macro
magic going on here? Is this syntax also under redesign consideration?

According to Andrew LM Shalit, Dylan does things this way so that 
the getter and the setter can be exported (or not) separately.
I could also see that there might be performance hits in building
'setter' into a dispatcher.  

But all of a sudden, Dylan doesn't seem as elegant as I originally 
thought it was.  Isn't there a way of turning setter into a dispatcher
that at compile-time can be, but may not be optimized out of existence?
(-Since I assume some fancy optimizations happen with the general
method dispatcher anyway?)  Assuming this can be done, can't the
export information that can't be compiled out be assimilated into 
the dispatcher?

thant

P.S.  Although, I've never used T, I had heard of T's setter 
function and I did originally think that Dylan's was the same 
thing.





From info-dylan-request Mon Oct 26 17:39:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08015; Mon, 26 Oct 92 17:39:58 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08011; Mon, 26 Oct 92 17:39:57 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01380; Mon, 26 Oct 92 17:44:04 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA03774@relay.tek.com>; Mon, 26 Oct 92 14:32:25 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA25896; Mon, 26 Oct 92 14:36:45 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA13841; Mon, 26 Oct 92 14:22:43 PST
Date: Mon, 26 Oct 92 14:22:43 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9210262222.AA13841@goldfish.MITRON.TEK.COM>
To: info-dylan@cambridge.apple.com
Subject: "A Dylan Culture" plus "Questions from a new member of the list"

One of the benefits of a dynamic language is of course that anyone can
add to the system. This can be true even of products delivered using
that system. One of the barriers to creating such a product with
commercial dynamic languages is the cost and/or licensing issue. With
systems developed in academia, cost may or may not be an issue, but
support becomes an issue.

* A truly effective Dylan "culture" must cross these barriers. How will
that be done? How will the costs be covered?

* Is there a list of implementations that are underway or being
considered?

* Is there an archive of this mail list?

Thanks
--
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 Mon Oct 26 17:47:44 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08104; Mon, 26 Oct 92 17:47:45 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08100; Mon, 26 Oct 92 17:47:44 -0500
Received: from phage.cshl.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01491; Mon, 26 Oct 92 17:51:51 -0500
	for info-dylan@cambridge.apple.com
Received: from isis.cshl.org by phage.cshl.org (4.1/2.1-Cold Spring Harbor Laboratory - phage)
	id AA20235; Mon, 26 Oct 92 17:38:44 EST
Received: by isis.cshl.org (4.1/SMI-4.1)
	id AA28217; Mon, 26 Oct 92 17:45:39 EST
Date: Mon, 26 Oct 92 17:45:39 EST
From: boutell@isis.cshl.org (Tom Boutell)
Message-Id: <9210262245.AA28217@isis.cshl.org>
To: alms@cambridge.apple.com, info-dylan@cambridge.apple.com,
        jeff@aiai.edinburgh.ac.uk
Subject: Re: setter problem

Can you elaborate on why, exactly, exporting a setter function is a problem?

-T

From info-dylan-request Mon Oct 26 17:57:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08216; Mon, 26 Oct 92 17:57:06 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08212; Mon, 26 Oct 92 17:57:05 -0500
Received: from inet-gw-1.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01561; Mon, 26 Oct 92 17:57:44 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-1.pa.dec.com; id AA26185; Mon, 26 Oct 92 14:50:45 -0800
Received: by myrtle.pa.dec.com; id AA01176; Mon, 26 Oct 92 14:49:17 -0800
Message-Id: <9210262249.AA01176@myrtle.pa.dec.com>
To: moon@cambridge.apple.com (David A. Moon)
Cc: info-dylan@cambridge.apple.com
Subject: Re: Multiple values in Dylan 
In-Reply-To: Message of Mon, 26 Oct 92 13:46:59 EDT    from moon@cambridge.apple.com (David A. Moon)    <9210261846.AA05377@cambridge.apple.com>
Date: Mon, 26 Oct 92 14:49:16 -0800
From: meehan@src.dec.com
X-Mts: smtp


    From: moon@cambridge.apple.com (David A. Moon)
    Date: Mon, 26 Oct 92 13:46:59 EDT

    ... I think it's incumbent on anyone proposing significant language
    changes to give examples of how common usages would change under
    the proposal ...

OK.  My basic point was that we could make the language simpler, 
more elegant, and compiler-friendlier by cleaning up multiple values.  
Specifics: 

1. Ditch the part of BIND that allows extra values and fills in missing 
values with #f.  Allow BIND to take #key and #next.  Specify that 
VALUES must produce exactly the number and types of values that BIND 
is prepared to receive; VALUES and BIND must agree, just as APPLY 
and METHOD do.  Then there's only one protocol in the language for 
passing arguments. 

2. For the cases where you want to ignore extra values, we would 
add a macro or special form, e.g., (VAL1 expression), that takes 
an expression that produces at least one value, and returns the first 
value.  Something with this sort of effect (but done more efficiently): 

    (define-macro val1 (expression)
      (bind ((vals (gensym)))
        `(bind ((#rest ,vals ,expression))
           (first ,vals))))

Then you can write (* y (val1 (ceiling/ x y))), and you don't need 
to add "floor1", "ceiling1", "init-value1", etc. 

3. I don't think that VALUES would need to be a special form.  The 
compiler could be at least as smart about VALUES as it is about APPLY, 
which isn't a special form, either.  If, as the book suggests, 
DEFINE-GENERIC-FUNCTION had a standard option for specifying the 
number and types of return-values, the compiler could do a really 
good job of checking for errors, avoiding the allocation of #REST-sequences, 
etc. 


Comment: Careful readers of the manual may have noticed that the 
only built-in functions that return multiple values, besides VALUES 
itself, are INIT-VALUE, FLOOR, FLOOR/, CEILING, CEILING/, ROUND, 
ROUND/, TRUNCATE, and TRUNCATE/ (did I miss any?), so they might 
argue that this is a lot of fuss over an obscure feature of the language.  
But I've found them to be quite useful; they make the language more 
"functional", and they are certainly to be preferred over passing 
"VAR OUT" parameters. I've seen a lot of bad Lisp code where people 
cheated by adding extra return-values to encode obscure state-information, 
often not even documenting them in the "white pages", so that "normal 
users" would think there was only one value; this led to errors.  
Cleaning up multiple values would prevent that sort of problem. 

I've also programmed in languages where, in order to get the effect 
of multiple values, you defined a record-type that held exactly the 
right number and types of slots.  This is clean and works well, but 
it requires more verbose code, and it can waste storage allocation: 
in the typical case, the values are extracted from the record, immediately 
upon return, and bound to other variables.  Multiple values could 
simplify this usage as well. 

--Jim

From info-dylan-request Mon Oct 26 18:33:37 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08550; Mon, 26 Oct 92 18:33:38 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08546; Mon, 26 Oct 92 18:33:37 -0500
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01762; Mon, 26 Oct 92 18:37:43 -0500
	for info-dylan@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for info-dylan@cambridge.apple.com id AA05225; Mon, 26 Oct 92 15:33:19 -0800
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:boutell@isis.cshl.org id AA19297; Mon, 26 Oct 92 15:33:13 -0800
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:info-dylan@cambridge.apple.com id AA19682; Mon, 26 Oct 92 15:35:44 -0800
Message-Id: <9210262335.AA19682@void.esd.sgi.com>
To: boutell@isis.cshl.org (Tom Boutell)
Cc: info-dylan@cambridge.apple.com
Subject: Re: setter problem 
In-Reply-To: Your message of Mon, 26 Oct 92 17:45:39 -0500.
             <9210262245.AA28217@isis.cshl.org> 
Date: Mon, 26 Oct 92 15:35:43 PST
From: thant@void.esd.sgi.com



> Can you elaborate on why, exactly, exporting a setter function is a problem?
> 
> -T


Modules have two purposes: The first is to prevent namespace pollution.
The second is to guarantee that clients only use the advertised 
interfaces to libraries so that the libraries can be changed without
breaking client code.

Coming from the C++ world, I feel weird without the ability to make
methods private at the class level, let alone the module level.

I understand that getter and setter are really two different things.
I just don't like the price Dylan is making me pay.  I would think
the right thing to do is dispatch 'set!' the same way all the methods
are dispatched and use whatever mechanism it uses to only export 
the appropriate methods.  This would make things simpler in terms
of syntax because 'set!' would look like any other method.  This 
also wouldn't prevent Dylan from automatically creating the set! for 
you when you created the slot.

Is there a reason why 'set!' isn't treated like a regular method?
Does it have to do with the fact that normally set! is a special 
case because it doesn't evaluate the variable being set?

thant






From info-dylan-request Mon Oct 26 21:14:47 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA09632; Mon, 26 Oct 92 21:14:49 -0500
Received: from jumbo.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09628; Mon, 26 Oct 92 21:14:47 -0500
Received: from apple.com by jumbo.apple.com with SMTP (5.64/26-Oct-1992-eef)
	id AA04987; Mon, 26 Oct 92 12:18:11 PST
	for info-dylan@cambridge.apple.com
Received: from sol.UVic.CA by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA23693; Mon, 26 Oct 92 09:50:00 -0800
	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.37TMX)
	id AA07412; Mon, 26 Oct 92 09:48:25 PST
Date: Mon, 26 Oct 92 09:48:21 PST
Message-Id: <9210261748.AA07412@sol.UVic.CA>
To: info-dylan@cambridge.apple.com
From: marykuca@sol.UVic.CA (Brent Marykuca)
Subject: Is Thomas Appropriate for a Small Project?

Hi there,

Well, I've read the book, played a little with Thomas and have decided that
I like Dylan.  I'm considering using Thomas to implement a small game as a
term project for my Object Programming course this fall.  Before I start,
though, I'd appreciate opinions about whether or not the Thomas
implementation is complete enough to handle a moderately-complex program.

Thanks,

Brent

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


From info-dylan-request Mon Oct 26 22:58:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11453; Mon, 26 Oct 92 22:58:44 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11448; Mon, 26 Oct 92 22:58:43 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02432; Mon, 26 Oct 92 23:02:54 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9210270402.AA02432@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa09467; 26 Oct 92 22:57:47 EST
To: Andrew LM Shalit <alms@CAMBRIDGE.APPLE.COM>
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: setter problem 
In-Reply-To: Your message of Mon, 26 Oct 92 16:16:09 -0500.
             <9210262110.AA06925@cambridge.apple.com> 
Date: Mon, 26 Oct 92 22:57:28 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    We're considering changing setter syntax so that it doesn't look so
    much like an operation.  Your mistake probably wouldn't have come up
    if (setter a) were spelled set-a.
    
I think some such change really must be made, even at the cost of
taking away a chunk of the space of possible symbols.  The current setter
syntax is by far the ugliest wart in the language.

If we must reserve part of the name space for setter functions, it should
be some part that people won't stumble over accidentally.  I'd prefer that
(setter a) turn into a-setter or setter-a, since "set" would naturally be
used as a variable name for some mathematical set.  If we must choose, it's
probably better to trip up the dog lovers than the mathematicians.

-- 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 Oct 26 23:48:31 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12466; Mon, 26 Oct 92 23:48:34 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12462; Mon, 26 Oct 92 23:48:31 -0500
Received: from amway.ch.apollo.hp.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02596; Mon, 26 Oct 92 23:52:41 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9210270452.AA02596@brazil.cambridge.apple.com>
Received: from daphne.ch.apollo.hp.com by amway.ch.apollo.hp.com id <AA21938@amway.ch.apollo.hp.com> Mon, 26 Oct 92 23:47:25 EST    
Received: from kanangra.ch.apollo.hp.com by daphne.ch.apollo.hp.com id AA05759; Mon, 26 Oct 1992 23:45:07 -0500    
Received: by kanangra.ch.apollo.hp.com id <AA15810@kanangra.ch.apollo.hp.com>; Mon, 26 Oct 92 23:39:55 -0500    
Date: Mon, 26 Oct 92 23:39:55 -0500
From: esler@apollo.hp.com
To: info-dylan@cambridge.apple.com
Subject: How to get Thomas ?
Reply-To: esler@apollo.hp.com

May I obtain a copy of Thomas from somewhere ?
--  
Kevin Esler //hewlett-packard/cso/nsg/std/clo/mll (MA Language Lab)
esler@apollo.hp.com   (508) 436-5979

From info-dylan-request Tue Oct 27 00:21:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13327; Tue, 27 Oct 92 00:21:33 -0500
Received: from jumbo.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13322; Tue, 27 Oct 92 00:21:30 -0500
Received: from apple.com by jumbo.apple.com with SMTP (5.64/26-Oct-1992-eef)
	id AA24844; Mon, 26 Oct 92 21:20:59 PST
	for Info-dylan@CAMBRIDGE.apple.com
Received: from linus.mitre.org by apple.com with SMTP (5.61/7-Aug-1992-eef)
	id AA24686; Mon, 26 Oct 92 09:53:17 -0800
	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 AA23633; Mon, 26 Oct 92 12:50:30 -0500
Posted-Date: Mon, 26 Oct 92 12:50:26 EST
Received: by celebes.mitre.org (5.61/RCF-4C)
	id AA09461; Mon, 26 Oct 92 12:50:27 -0500
Message-Id: <9210261750.AA09461@celebes.mitre.org>
To: Info-dylan@CAMBRIDGE.APPLE.COM
Cc: ramsdell@linus.mitre.org
Subject: Duel Name Spaces Within Modules
Date: Mon, 26 Oct 92 12:50:26 EST
From: John D. Ramsdell <ramsdell@linus.mitre.org>

Dylan appears to be a great advance in the design of object oriented
dynamic languages.  With that said, I would like to ask about some
design details.

In an other forum, I argued against the idea of having two name spaces
within a module.  I am refering, of course, to the fact that FOO is
a different variable from #'FOO, which is (SETTER FOO) in the old
syntax.  The reply in the Dylan FAQ stated that:

	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.

It seems quite simple to export a getter without its setter by
encapsilating the getter in an object that intercepts only setter
operations, and delegates all other operations.  In fact, it seems so
simple, I feel I must be missing something.  Why is it difficult to
have a value based implementation of SETTER notation be able to
selectively export a getter without a setter?

John

P. S.  I agree with Jim Meehan suggestion on multiple values in that
calling a continuation should be like calling an ordinary procedure.


From info-dylan-request Tue Oct 27 04:44:39 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19735; Tue, 27 Oct 92 04:44:42 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19730; Tue, 27 Oct 92 04:44:39 -0500
Received: from hplb.hpl.hp.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02977; Tue, 27 Oct 92 04:48:50 -0500
	for info-dylan@cambridge.apple.com
Received: from cdollin.hpl.hp.com by hplb.hpl.hp.com; Tue, 27 Oct 92 09:43:51 GMT
Received: by wol.hpl.hp.com
	(16.6/15.6+ISC) id AA22256; Tue, 27 Oct 92 09:47:48 GMT
Date: Tue, 27 Oct 92 09:47:48 GMT
From: Chris Dollin <kers@hplb.hpl.hp.com>
Message-Id: <9210270947.AA22256@wol.hpl.hp.com>
To: info-dylan@cambridge.apple.com
Subject: Re: setter problem

Andrew says:

| We're considering changing setter syntax so that it doesn't look so
| much like an operation.  Your mistake probably wouldn't have come up
| if (setter a) were spelled set-a.

Why not do it the way T and Pop do, and make setter be a function?

(The only argument I've heard against this is that you'd like to be able to
export the accessor and not the setter of a function, which is easy if they're
symbols. But it seems to me that (a) you can get that effect by introducing an
auxilliary function, and (b) if it's that common, you can introduce export
syntax to have the system do it for you. Compared to the simplicty and
elegance of procedures-with-setters, this seems a feeble case. IMAO.)

Regards,    | "C gains much of its vaunted efficiency by employing a very
Kers.       | powerful pre-processor, usually called a ``programmer''."

From info-dylan-request Tue Oct 27 09:52:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28871; Tue, 27 Oct 92 09:52:20 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28866; Tue, 27 Oct 92 09:52:18 -0500
Received: from gmdzi.gmd.de by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03507; Tue, 27 Oct 92 09:56:30 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by gmdzi.gmd.de with SMTP id AA26646
  (5.65c/IDA-1.4.4 for info-dylan@cambridge.apple.com); Tue, 27 Oct 1992 15:51:23 +0100
Message-Id: <199210271451.AA26646@gmdzi.gmd.de>
To: Chris Dollin <kers@hplb.hpl.hp.com>
Cc: info-dylan@cambridge.apple.com
Subject: Re: setter problem 
In-Reply-To: Your message of "Tue, 27 Oct 92 09:47:48 GMT."
             <9210270947.AA22256@wol.hpl.hp.com> 
Date: Tue, 27 Oct 92 15:51:22 +0100
From: Harry.Bretthauer@gmd.de
X-Mts: smtp

 
> Why not do it the way T and Pop do, and make setter be a function?
> 
> (The only argument I've heard against this is that you'd like to be able to
> export the accessor and not the setter of a function, which is easy if they're
> symbols. But it seems to me that (a) you can get that effect by introducing an
> auxilliary function, and (b) if it's that common, you can introduce export
> syntax to have the system do it for you. Compared to the simplicty and
> elegance of procedures-with-setters, this seems a feeble case. IMAO.)

There are some more aspects, where, I think the setter should have
similar behavior as the reader. For example:
1. if the reader binding is constant, the setter "binding or table
   entry" should also. 
2. if a reader reference can be analyzed statically (detecting errors,
etc.), the setter reference should also.

This can be better achieved and explained by special forms, one for
defining setters and one for refering them, rather than by a function.

This could be generalized to structure the lexical module bindings
with respect to some criteria which are orthogonal to the module
structure. It might be also usefull to allow language extenders to define new
binding spaces with lexical or other semantics.

Harry Bretthauer
German National Research Center for Computer Science (GMD)
P.O. Box 1316, W-5205 Sankt Augustin 1, Germany
Phone: +49-2241-14-2704   Fax: +49-2241-14-2072 Email: bretthauer@gmd.de

From info-dylan-request Tue Oct 27 11:23:26 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03368; Tue, 27 Oct 92 11:23:30 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03362; Tue, 27 Oct 92 11:23:26 -0500
Received: from hplb.hpl.hp.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03846; Tue, 27 Oct 92 11:27:36 -0500
	for info-dylan@cambridge.apple.com
Received: from cdollin.hpl.hp.com by hplb.hpl.hp.com; Tue, 27 Oct 92 16:22:36 GMT
Received: by wol.hpl.hp.com
	(16.6/15.6+ISC) id AA23914; Tue, 27 Oct 92 16:26:35 GMT
Date: Tue, 27 Oct 92 16:26:35 GMT
From: Chris Dollin <kers@hplb.hpl.hp.com>
Message-Id: <9210271626.AA23914@wol.hpl.hp.com>
To: info-dylan@cambridge.apple.com
Subject: Re: setter problem

Harry Bretthauer (|) replies to me (| >):

| > Why not do it the way T and Pop do, and make setter be a function?
| >
| > (The only argument I've heard against this is that you'd like to be able to
| > export the accessor and not the setter of a function, which is easy if they're
| > symbols. But it seems to me that (a) you can get that effect by introducing an
| > auxilliary function, and (b) if it's that common, you can introduce export
| > syntax to have the system do it for you. Compared to the simplicty and
| > elegance of procedures-with-setters, this seems a feeble case. IMAO.)
|
| There are some more aspects, where, I think the setter should have
| similar behavior as the reader. For example:
| 1. if the reader binding is constant, the setter "binding or table
|    entry" should also.
| 2. if a reader reference can be analyzed statically (detecting errors,
| etc.), the setter reference should also.

These can be done if there is a way to assert that (setter x) is an invariant
for some particular x. Since this is a useful thing to be able to assert for
*any* function-value combination (eg, (sin x), (car x)), there seems to be no
compelling reason to have special forms for setter rather than making it a
procedure.

| This can be better achieved and explained by special forms, one for
| defining setters and one for refering them, rather than by a function.

I don't agree (except I'd expect a special form or macro for *defining* them,
for the sake of common use).

| This could be generalized to structure the lexical module bindings
| with respect to some criteria which are orthogonal to the module
| structure. It might be also usefull to allow language extenders to define new
| binding spaces with lexical or other semantics.

But if we do that (for example, by attaching suitable predicates to bindings)
then we can attach eg information about the immutability of the setter slot of
procedures, once again dispensing with the need for an extra name space in
favour of the setter-as-function solution.

I've *used* setters-as-functions. Not being able to pass a function as a
parameter and get at its setter would be a *pain* -- I'd no more want to do
without them than I'd want to do without lexical binding, partial
application, or properties (hash tables). I think the getter-and-setter
procedures are a natural pair; associating them only by name is surely an
easily-fixable mistake.

Kers.       | "A foolish hobgoblin has the consistency of little minds".

From alms Tue Oct 27 11:59:29 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05046; Tue, 27 Oct 92 11:59:40 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05036; Tue, 27 Oct 92 11:59:29 -0500
Message-Id: <9210271659.AA05036@cambridge.apple.com>
Date: Tue, 27 Oct 1992 12:05:43 -0500
To: info-dylan
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Dylan FAQ October 27, 1992

[A number of new people have joined the list, and a couple of FAQs have
been asked recently, so I'm accelerating our monthly FAQ posting. -Andrew]


Dylan(tm) FAQ October 27, 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 in the latest 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 products based on Dylan.

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

* 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#.)

* 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 a C or Algol-like 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 btlewis@arkesden.Eng.Sun.COM Tue Oct 27 16:06:47 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13758; Tue, 27 Oct 92 16:06:47 -0500
Received: from Sun.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05180; Tue, 27 Oct 92 16:11:02 -0500
	for announce-dylan@cambridge.apple.com
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA10465; Tue, 27 Oct 92 13:03:47 PST
Received: from arkesden.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
	id AA18975; Tue, 27 Oct 92 13:03:29 PST
Received: from salishan.Eng.Sun.COM by arkesden.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08296; Tue, 27 Oct 92 13:03:58 PST
Date: Tue, 27 Oct 92 13:03:58 PST
From: btlewis@arkesden.Eng.Sun.COM (Brian Lewis)
Message-Id: <9210272103.AA08296@arkesden.Eng.Sun.COM>
To: announce-dylan@cambridge.apple.com
Subject: Addition to Dylan announcement meiling list
Cc: btlewis@arkesden.Eng.Sun.COM

Please add me to the announce-dylan@cambridge.apple.com list. Thanks.

  Brian

From preece@urbana.mcd.mot.com Wed Oct 28 09:50:09 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10974; Wed, 28 Oct 92 09:50:09 -0500
Received: from urbana.mcd.mot.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06934; Wed, 28 Oct 92 09:54:30 -0500
	for announce-dylan@cambridge.apple.com
Received: from etude.urbana.mcd.mot.com by urbana.mcd.mot.com (5.61/1.34)
	id AA08195; Wed, 28 Oct 92 08:49:32 -0600
Received: by etude.urbana.mcd.mot.com (5.61/MCDMAIL IR04 [05/15/91 07:50]/1.34)
	id AA06081; Wed, 28 Oct 92 08:49:02 -0600
Date: Wed, 28 Oct 92 08:49:02 -0600
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Message-Id: <9210281449.AA06081@etude.urbana.mcd.mot.com>
To: announce-dylan@cambridge.apple.com
Subject: subscribe request

Please add me to the mailing list for Dylan information/updates.

thanks,
scott

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550

From info-dylan-request Wed Oct 28 12:14:57 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18632; Wed, 28 Oct 92 12:15:01 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18626; Wed, 28 Oct 92 12:14:57 -0500
Received: from mailrus.cc.umich.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07710; Wed, 28 Oct 92 12:19:19 -0500
	for info-dylan@cambridge.apple.com
Received: from um.cc.umich.edu by mailrus.cc.umich.edu (5.65/1123-1.0)
	id AA27739; Wed, 28 Oct 92 12:15:01 -0500
Date: Wed, 28 Oct 92 12:10:22 EST
From: Gordon.Leacock@um.cc.umich.edu
To: info-dylan@cambridge.apple.com
Message-Id: <16934104@um.cc.umich.edu>
X-Mts-Userid: W02B
Subject: Please add me to info-dylan list

Please add me to the info-dylan mailing list. 
 
I received the Dylan book today, thanks. 
 
  -- Gordon

From info-dylan-request Thu Oct 29 11:01:13 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24991; Thu, 29 Oct 92 11:01:14 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24987; Thu, 29 Oct 92 11:01:13 -0500
Received: from harvard.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10814; Thu, 29 Oct 92 11:05:37 -0500
	for info-dylan@cambridge.apple.com
Received: by harvard.harvard.edu (5.54/a0.25)
	(for info-dylan@cambridge.apple.com) id AA01464; Thu, 29 Oct 92 11:00:59 EST
Received: from ireland.gensym by gensym.com (4.0/SMI-3.2)
	id AA06331; Thu, 29 Oct 92 10:50:24 EST
Received: by ireland.gensym (4.1/SMI-4.1)
	id AA19111; Thu, 29 Oct 92 10:57:07 EST
Date: Thu, 29 Oct 92 10:57:07 EST
From: gensym!ireland!jra@harvard.harvard.edu (Jim Allard)
Message-Id: <9210291557.AA19111@ireland.gensym>
To: info-dylan@cambridge.apple.com
In-Reply-To: harvard!SEF-PMAX.SLISP.CS.CMU.EDU!Scott_Fahlman's message of Wed, 21 Oct 92 08:26:08 -0400 <9210211230.AA07862@brazil.cambridge.apple.com>
Subject: Re: small integers 


Scott Fahlman writes:
    
  I think it would be a serious mistake for the Dylan language to include a
  required list of numeric optimizations at this early point (or any time
  very soon).  Until we all get some experience with this, it won't be clear
  what is easy, what is straightforward but perhaps too expensive for small
  implementations, and what is very hard.  At present, we don't yet have a
  complete system of types and declarations, or even full agreement on how to
  handle bignums/integer-overflow.

I agree that it is not easy to get optimized numerics done right within the
Common Lisp numerics system, either as a language designer or as a
programmer.  I have a group of experienced Common Lisp programmers here, and
many of them are still not confident in their ability to write numeric
operations that will be deemed acceptable for optimization by the compilers
we use.  This was such a problem that we had to write macros for fixnum and
double-float numeric operations that we knew would work, and so our
programmers now use those macros to get optimized arithmetic.

In view of this experience, I was very surprised to see the Common Lisp
numeric system adopted within Dylan wholesale.  I feel that if the Dylan
designers really intend to lure C and C++ programmers into Dylan, they should
either provide the means to write optimized numeric methods, or they should
fall back to a numeric system that is simple enough to be able to get
optimizations.  I still believe the C community will view Dylan as largely
irrelevant without fast arithmetic.  For these reasons I can't agree with
Scott that this work should be postponed.

Scott continues:

  What might be useful is for someone ... to group the optimizations that
  you want to see into a few coherent levels.  Then implementors and
  applications designers would have a convenient shorthand: "This code runs
  well only a in Dylan implementation with level 2 arithmetic
  optimizations."...

  It wouldn't matter too much whether these levels are blessed officially as
  part of the Dylan language or are just a users-group thing, as long as
  everyone who wants to play this implementation efficiency game agrees to a
  common set of conventions.

I agree that once sufficient type declaration means are provided within Dylan
to allow numeric optimizations, it could be left up to implementors to choose
whether or not to provide optimizations within their implementation.  I also
strongly agree that conventions are needed within the Dylan community to
describe classes of optimizations.  I would hope that these conventions are
blessed by the language designers to ensure widespread understanding of their
meaning.  To use the example of Common Lisp again, I feel that strong enough
definitions of numeric optimizations did not evolve.  Yet, while some
compilers (for example CMU Lisp) do amazing things with types, there are
still commercial implementations that do not support all of the following
optimizations in their numerics.  I still find myself in long-winded
discussions with Lisp vendors about what they mean by "in-line arithmetic."
It would be a shame for that to happen to Dylan.

The following lists some sets of optimizations I would be interested in
seeing.

1) Compile-time method selection.

Given adequate calls to seal, calls to make-read-only, and type declarations
at a method call site, then a specific method is chosen and the call to it is
staticly compiled in, or even in-lined for simple methods such as slot value
access.  This optimizes away run-time type dispatching.  (This is what I
think Dylan designers are attempting around seal and make-read-only, though I
couldn't find it spelled out in detail within the Dylan manual.)

2) Unboxed intermediate arithmetic values.

Given that compile-time method selection succeeded, intermediate results of
nested fixnum and double-float operations are passed from one operation to
the next without boxing.  This optimizes away possibly expensive consing
operations, makes the expression itself faster and also reduces the load the
garbage collector imposes on an application.

Determining numeric type of intermediate values of double-float expressions
can be done without intermediate declaration since contagion between double-
floats always produces double-floats.  (Would any experts please verify this?
I'm fairly certain this always holds.)  For fixnums, it can be determined (by
a *sufficiently smart* compiler) that intermediate values don't exceed the
range of fixnums given tighter range restrictions on arguments to an
expression.  These tighter bounds can be inferred when using Dylan's
iteration over ranges, though an extention to the type system to declare
ranges on integer types would provide this through a broader means.  Even
given fixnum range-restricted type declarations, a means is needed to assert
types of intermediate values.  Without it, Dylan users will be stuffing
intermediate values back into fixnum type declared lexical variables to get
an implicit type declaration of the expression's return value.

3) Unboxed lexical variable contents.

Given local variables that are type declared as fixnum or double-float, the
memory for that location is allocated to hold the value in its unboxed form.
Uses of the variable value for compile-time method selected expressions with
unboxed intermediate values would use the unboxed value from this variable
directly.  Uses of the variable value for other purposes would cause a boxing
of the value before use.  Like #2, this optimizes away consing operations.

4) Unboxed method arguments and return values.

Given a user-defined (i.e.  not built-in) method that takes fixnum or
double-float arguments, and returns values that can be determined at compile
time to be fixnum or double-float, and given a compile-time selected call to
the method, then the fixnum arguments and return values for this call are
passed in their unboxed form.  Like #2 and #3, this optimizes away consing
operations.

Chris Fry writes:

  I agree that there is no contradiction here [between correct programs and
  fast programs]. In fact there's even a strong relationship between the two
  in that there's nothing slower than a broken program.

I don`t mean to jump all over you, Chris, but the sad fact is that there is a
flippant dismissal of performance issues among many high level language
proponents.  In my view, more than anything else, the reputation of Common
Lisp as fat and slow prevented its commercial success and fueled the flight
of expert systems products from Lisp to C, and numeric performance was the
example I heard most often from people arguing against Lisp.

It doesn't matter that Common Lisp implementations have now mainly got those
issues under control.  A bad reputation has become firmly entrenched in the
marketplace.  And it is still true that smart, well-meaning users of that
language have a hard time using it correctly.

If the Dylan designers mean what was said in the introduction to the manual
about targeting C, C++, and Pascal users, that compatibility with Lisps is
not a primary goal, and that they would "leave out anything that we do not
know how to implement efficiently in both space and time", then I think this
numerics issue qualifies as a problem area deserving of attention.

Well, I've blathered on more than I planned here.  I don't mean to tell the
Dylan designers how to do their jobs, and I don't diminish in any way the
difficulty of the task set before them.  I've just gone through a lot with
Common Lisp numerics and so have some strong opinions in this area.

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 Thu Oct 29 11:24:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26330; Thu, 29 Oct 92 11:24:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26325; Thu, 29 Oct 92 11:24:11 -0500
Received: from gatech.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11009; Thu, 29 Oct 92 11:28:42 -0500
	for info-dylan@cambridge.apple.com
Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1)
	id AA10216 for info-dylan@cambridge.apple.com; Thu, 29 Oct 92 11:24:22 EST
Received: from lennon.cc.gatech.edu (odie.cc.gatech.edu) by burdell.cc.gatech.edu (4.1/SMI-4.1)
	id AA10841; for info-dylan@cambridge.apple.com; Thu, 29 Oct 92 11:24:20 EST
Received: from denver.cc.gatech.edu by lennon.cc.gatech.edu (4.1/SMI-4.1)
	id AA02770; Thu, 29 Oct 92 11:24:24 EST
Date: Thu, 29 Oct 92 11:24:24 EST
From: erica@cc.gatech.edu (Erica Liebman)
Message-Id: <9210291624.AA02770@lennon.cc.gatech.edu>
To: info-dylan@cambridge.apple.com
Subject: please sign me up for the news group. tx


From moon Thu Oct 29 11:35:45 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27082; Thu, 29 Oct 92 11:35:54 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27069; Thu, 29 Oct 92 11:35:45 -0500
Message-Id: <9210291635.AA27069@cambridge.apple.com>
Date: Thu, 29 Oct 92 11:36:42 EST
From: moon (David A. Moon)
To: gensym!ireland!jra@harvard.harvard.edu (Jim Allard)
Subject: Re: small integers 
Cc: info-dylan@cambridge.apple.com

> Date: Thu, 29 Oct 92 10:57:07 EST
> From: gensym!ireland!jra@harvard.harvard.edu (Jim Allard)

Thanks.  It's refreshing to read such a carefully written piece of email!  I 
think you've given an excellent summary of some important problems.

From info-dylan-request Thu Oct 29 12:22:52 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00180; Thu, 29 Oct 92 12:22:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00174; Thu, 29 Oct 92 12:22:52 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11342; Thu, 29 Oct 92 12:27:23 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA14723; Thu, 29 Oct 92 12:22:31 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA15600; Thu, 29 Oct 1992 12:20:30 -0500
Date: Thu, 29 Oct 1992 12:20:30 -0500
Message-Id: <9210291720.AA15600@lakatos.osf.org>
To: info-dylan@cambridge.apple.com
Subject: Arithmetic comments
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

p. 148 says that

	(make <complex> angle: a) == (make-polar 0 a) 

This is presumably equivalent to (make-rectangular 0 0), since the
only kind of non-real <complex> is <rectangular-complex>.

What use is it?  Is it just for symmetry?  A default magnitude of 1
would be far more useful.

Note that the smoothness argument does not apply, since it is
statically manifest that there is no specified magnitude.

	-s

From info-dylan-request Thu Oct 29 14:11:00 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06386; Thu, 29 Oct 92 14:11:02 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06381; Thu, 29 Oct 92 14:11:00 -0500
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11797; Thu, 29 Oct 92 14:15:31 -0500
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA16679; Thu, 29 Oct 92 14:10:54 EST
Message-Id: <9210291910.AA16679@MIT.EDU>
Date: Thu, 29 Oct 92 15:12:03 EST
From: cfry@MIT.EDU (Christopher Fry)
To: jra@gensym.com
Subject: Re: small integers 
Cc: info-dylan@cambridge.apple.com

>Chris Fry writes:

>>  I agree that there is no contradiction here [between correct programs and
>>  fast programs]. In fact there's even a strong relationship between the two
>>  in that there's nothing slower than a broken program.

> I don`t mean to jump all over you, Chris, but the sad fact is that there is a
> flippant dismissal of performance issues among many high level language
> proponents.  In my view, more than anything else, the reputation of Common
> Lisp as fat and slow prevented its commercial success and fueled the flight
> of expert systems products from Lisp to C, and numeric performance was the
> example I heard most often from people arguing against Lisp.

> It doesn't matter that Common Lisp implementations have now mainly got those
> issues under control.  A bad reputation has become firmly entrenched in the
> marketplace.  And it is still true that smart, well-meaning users of that
> language have a hard time using it correctly.

Hi, Jim. I actually wrote a couple of side messages to others interested
in this issue. Somehow I didn't think it was that big a deal but
I got one person supporting my statement and the other rejecting it.

I though about it a little and realized both were right.
Here's how I'll summarize my thoughts:
There are certain applications where if the answer doesn't come back within
a millisecond of when you want it to, then the program is worthless.
[I gave an example about a patriot missle imaging system that took a whole day to
compute when it was supposed to blow up.]
Even in less extreme situations such as a user interface that takes 3 seconds
instead of one, it can drive users [including me!] nuts.

Gensym's tightness has provided a valuable service to the community by clarifying
the issues with speed and garbage collection [I wish your list of fns that
aren't suppose to cons would make it into the CL2 spec.]

One guy argued that you'll never get all the bugs out of a big program, so
just make it fast. On the surface that sounds pretty stupid, but if
we reword it to say "Its more important to get the stuff that you
use a lot to be fast than to get every last little bug out of the
esoteric features that you rarely, if ever, use." then I think many of
us would agree.

I'll just bring up one additiohnal point for the other side.
If you've got a program that is correct in all ways except that
its too slow, then you may be able to fix that  problem simply by buying
faster hardware. I say "simply" because sometimes in a big system
its CHEAPER to buy faster hardware than to recode. And it may even be faster.
Say it takes a year to rewrite the code, but a machine twice as fast comes out
every year anyway.

But there's some synergy between fast and correct too. The same declarations
that help a compiler be fast can be used for better error checking and reporting.
ie rather than seeing "Sorry your system crashed" I'd like to see
"You just called foo with 3 as the first arg. But foo requires a symbol as
the first arg and 3 is a number."

You're right, I'm guilty of being flippant. And I hope you'll keep bashing away at CL vendors
for speed and correctness. You're also right that CL has a bad rep and it should be fixed.
Size-wise, you might notice that the full blown X is huge, but somehow it rode in
on C's coat-tails.

If we had to design programming langs all over again, we might still find it fastest 
to have one group concentrate on speed, and one on high-level-semanitcs.
Then at various points along the way some 3rd group would come along and try to
get the best of both worlds. I guess the problem has been that everybody ended up in
one or the other camps and the 3rd group was too slow in comming.
Keep up the pressure!
Fry



From info-dylan-request Thu Oct 29 14:37:29 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07986; Thu, 29 Oct 92 14:37:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07980; Thu, 29 Oct 92 14:37:29 -0500
Received: from research.nj.nec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11945; Thu, 29 Oct 92 14:41:59 -0500
	for info-dylan@cambridge.apple.com
Received: by research.nj.nec.com (4.0/YDL1.8-920115.13)
	id AA06977(research.nj.nec.com); Thu, 29 Oct 92 14:37:33 EST
Received: by overdrive.ccrl.NJ.NEC.COM (4.1/EMS1.6-920330.08)
	id AA29546(overdrive.ccrl.NJ.NEC.COM); Thu, 29 Oct 92 14:37:35 EST
From: zilla@ccrl.nj.nec.com	(John Lewis)
Received: by babelfish (4.1/CNC-Client)
	id AA09860; Thu, 29 Oct 92 14:37:25 EST
Date: Thu, 29 Oct 92 14:37:25 EST
Message-Id: <9210291937.AA09860@babelfish>
To: info-dylan@cambridge.apple.com
Subject: Re: small integers, numerical efficiency

I agree with the recent message by Jim Allard r.e. numerics in Lisp.

Lisp is wonderful, but both its design and its implementations 
usually have a strong bias which hinders the use of the language 
for numerical algorithms.
  Bignums and rational numbers are (IMHO) useful for a relatively
specialized type of application- things like Macsyma.
These features are not generally used in what is probably
a much larger class of numerical algorithms.

David Moon (i recall) commented that he would rather see
floating point removed from Dylan than have a half-baked numeric
system like that in C.  Although I agree that the C (also fortran,...) 
numeric system is poorly designed, nevertheless in fact I would much 
rather see Dylan have a "normal" but efficient numeric system 
than Bignums!!!  The numeric system in Scheme, which may be
considered to be well designed, drives me nuts!

For the current discussion I would like to try to label myself 
as a 'non-AI' user of Lisp, the sort of programmer who will use Dylan.
In ~8 years of Lisp programming, I have
- used Lisp for languages and interactive code with excellent results
- used rational numbers only a couple of times
- never required bignums
- tried many wierd schemes to do efficient numeric work in a Lisp context
- still write most numerical code in C

Dylan is a rare opportunity; i also hope it does not inherit CL's numerical
inefficiencly and problems as described Jim Allard's message.  
Acceptable efficiency is matter of opinion; I would find Dylan 
acceptable for most uses if it were within 1/2-1/3 of the 
speed of C/etc. implementations.  

I am still looking forward to Dylan even if numerical efficiency is not 
practical (the issues are way over my head certainly), 
but I hope that at least an efficient and standard foreign function interface
can be provided.




From moon Thu Oct 29 15:55:49 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10323; Thu, 29 Oct 92 15:55:52 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10318; Thu, 29 Oct 92 15:55:49 -0500
Message-Id: <9210292055.AA10318@cambridge.apple.com>
Date: Thu, 29 Oct 92 15:56:46 EST
From: moon (David A. Moon)
To: zilla@ccrl.nj.nec.com     (John Lewis)
Subject: Re: small integers, numerical efficiency
Cc: info-dylan@cambridge.apple.com

> From: zilla@ccrl.nj.nec.com     (John Lewis)
> Date: Thu, 29 Oct 92 14:37:25 EST
> ....
> David Moon (i recall) commented that he would rather see
> floating point removed from Dylan than have a half-baked numeric
> system like that in C.  ....

I did not say those last four words.

What I said was that I think a Dylan implementation would be better off 
leaving out floating point entirely than putting in floating point but not 
doing it efficiently.

Then from a language point of view, we could decide that few implementations 
will want to bother doing floating point efficiently, and therefore remove it 
from the language, or we could make it optional in the language, or we could 
leave the language the way it is and some implementations could announce that 
they only support a subset.  Personally I prefer making it optional over 
either extreme.  Floating point is not the only thing in the Dylan book that 
ought to be optional.

Also, C's integer numeric system is half-baked, but its floating-point numeric 
system is not particularly bad.  I say enough bad things about C that you 
don't need to misquote me disparaging a part of C that doesn't bother me!

From info-dylan-request Thu Oct 29 16:21:45 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11008; Thu, 29 Oct 92 16:21:46 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11004; Thu, 29 Oct 92 16:21:45 -0500
Received: from research.nj.nec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12582; Thu, 29 Oct 92 16:26:16 -0500
	for info-dylan@cambridge.apple.com
Received: by research.nj.nec.com (4.0/YDL1.8-920115.13)
	id AA09258(research.nj.nec.com); Thu, 29 Oct 92 16:21:48 EST
Received: by overdrive.ccrl.NJ.NEC.COM (4.1/EMS1.6-920330.08)
	id AA29963(overdrive.ccrl.NJ.NEC.COM); Thu, 29 Oct 92 16:21:49 EST
From: zilla@ccrl.nj.nec.com	(John Lewis)
Received: by babelfish (4.1/CNC-Client)
	id AA09948; Thu, 29 Oct 92 16:21:40 EST
Date: Thu, 29 Oct 92 16:21:40 EST
Message-Id: <9210292121.AA09948@babelfish>
To: moon@cambridge.apple.com
Subject: Re: small integers, numerical efficiency
Cc: info-dylan@cambridge.apple.com

Sorry about inaccurately paraphrasing you.  Here's what i should have
quoted:

> in agreement there; my reasoning is that if one isn't going to do a serious 
> implementation of floating-point, one shouldn't do a half-baked job, instead 
> one should not even claim to try.

> That's just my own opinion, not Apple's.  But I wonder how other people on 
> this list feel.  I know most people who implement Unix C numerics libraries 
> don't agree with me at all: from what I've heard they evidently think a 
> half-baked job is fine.


From info-dylan-request Fri Oct 30 01:13:09 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21939; Fri, 30 Oct 92 01:13:15 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21933; Fri, 30 Oct 92 01:13:09 -0500
Received: from iha.compuserve.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13884; Fri, 30 Oct 92 01:17:40 -0500
	for info-dylan@cambridge.apple.com
Received: by iha.compuserve.com (5.65/5.910516)
	id AA03372; Fri, 30 Oct 92 01:13:19 -0500
Date: 29 Oct 92 23:16:30 EST
From: Joe Terry |Manhattan| <72130.2100@CompuServe.COM>
To: <info-dylan@cambridge.apple.com>
Subject: REMOVE ME!!
Message-Id: <921030041629_72130.2100_CHL25-1@CompuServe.COM>

I'm Sorry but the weight is too great, Please remove me
from "info-dylan", and no other mail list.

I don't have the administration address handy.

Ladies and Gentlemen, Pardon the noise.

______________________________________________________________________
Joe Terry                                  Manhattan Software, Inc.
Software Engineer                          865 Manhattan Beach Blvd.
INTERNET:   72130.2100@@Compuserve.com      Suite 204
APPLELINK:  LAWYER                         Manhattan Beach, CA 90266
TELEPHONE:  (310) 545 6462                 USA
FACIMILE:   (310) 545 1730
______________________________________________________________________



From info-dylan-request Fri Oct 30 10:01:21 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08903; Fri, 30 Oct 92 10:01:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08895; Fri, 30 Oct 92 10:01:21 -0500
Received: from KARIBA.BBN.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14866; Fri, 30 Oct 92 10:05:59 -0500
	for moon@cambridge.apple.com
Message-Id: <9210301505.AA14866@brazil.cambridge.apple.com>
To: "David A. Moon" <moon@cambridge.apple.com>
Cc: John Lewis <zilla@ccrl.nj.nec.com>, info-dylan@cambridge.apple.com
Subject: Re: small integers, numerical efficiency 
In-Reply-To: Your message of Thu, 29 Oct 92 15:56:46 -0500.
             <9210292055.AA10318@cambridge.apple.com> 
Date: Fri, 30 Oct 92 09:45:36 -0500
From: kanderso@BBN.COM

  Date: Thu, 29 Oct 92 15:56:46 EST
  From: "David A. Moon" <moon@cambridge.apple.com>
  To: John Lewis <zilla@ccrl.nj.nec.com>
  Subject: Re: small integers, numerical efficiency
  Cc: info-dylan@cambridge.apple.com
  
  ...

  What I said was that I think a Dylan implementation would be better off 
  leaving out floating point entirely than putting in floating point but not 
  doing it efficiently.
  
  Then from a language point of view, we could decide that few implementations 
  will want to bother doing floating point efficiently, and therefore remove it 
  from the language, or we could make it optional in the language, or we could 
  leave the language the way it is and some implementations could announce that 
  they only support a subset.  Personally I prefer making it optional over 
  either extreme.  Floating point is not the only thing in the Dylan book that 
  ought to be optional.
  
Does "optional" mean one would not be able to use floats in a portable way? 

  Also, C's integer numeric system is half-baked, but its floating-point numeric 
  system is not particularly bad.  I say enough bad things about C that you 
  don't need to misquote me disparaging a part of C that doesn't bother me!

Perhaps we should order the numerical classes on page 147 by frequency of use.
Then we could use this to focus our attention on performance, or which
classes to prune from the language.

From my experience (which includes graphical and numerical programming) it
would be something like:

Class                 % of programs needing
<integer>             95.0
<single-float>        75.0
<double-float>        10.0
<ratio>                5.0
<rectangular-complex>  2.0
<extended-float>       0.1

In fact, i'd be quite happy if Dylan only had <integer> and <single-float>,
even if some would consider this a "half-baked" numerical system.

k

From moon Fri Oct 30 11:53:07 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15176; Fri, 30 Oct 92 11:53:10 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15170; Fri, 30 Oct 92 11:53:07 -0500
Message-Id: <9210301653.AA15170@cambridge.apple.com>
Date: Fri, 30 Oct 92 11:54:10 EST
From: moon (David A. Moon)
To: kanderso@BBN.COM
Subject: Re: small integers, numerical efficiency 
Cc: John Lewis <zilla@ccrl.nj.nec.com>, info-dylan@cambridge.apple.com

> Date: Fri, 30 Oct 92 09:45:36 -0500
> From: kanderso@BBN.COM
> 
>   Date: Thu, 29 Oct 92 15:56:46 EST
>   From: "David A. Moon" <moon@cambridge.apple.com>
>   
>   Then from a language point of view, we could decide that few implementations 
>   will want to bother doing floating point efficiently, and therefore remove it 
>   from the language, or we could make it optional in the language, or we could 
>   leave the language the way it is and some implementations could announce that 
>   they only support a subset.  Personally I prefer making it optional over 
>   either extreme.  Floating point is not the only thing in the Dylan book that 
>   ought to be optional.
>   
> Does "optional" mean one would not be able to use floats in a portable way? 

Optional means optional.  That is, each implementation could choose whether to 
include it or not.  Obviously if your program uses floating point it would only be 
portable to implementations that include floating point.

From smithn@orvb.saic.com Fri Oct 30 13:18:41 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20832; Fri, 30 Oct 92 13:18:41 -0500
Received: from orvb.SAIC.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15636; Fri, 30 Oct 92 13:23:17 -0500
	for announce-dylan@cambridge.apple.com
Received: from [139.121.81.63] by ORVB.SAIC.COM with SMTP; 
          Fri, 30 Oct 1992 13:18:54 EST
X-Popmail-Charset: English
Date: Fri, 30 Oct 92 14:27:12 EST
From: (Norman E. Smith, CDP) <smithn@orvb.saic.com>
Message-Id: <52034.smithn@orvb.saic.com>
To: announce-dylan@cambridge.apple.com
Subject: Dylan manual...

Please send me a copy of the Dylan manual along with information on
becoming a Newton developer. We are considering a SGML product
here at SAIC that I believe would be appropriate to the Newton.

      Norman Smith
      Science Applications International Corp.
      P.O. Box 2501
      301 Laboratory Road
      Oak Ridge, Tenn. 37716
Norman E. Smith, CDP          Science Applications International Corp
smithn@orvb.saic.com          PO Box 2501
                              301 Laboratory Road
615-481-2186                  Oak Ridge, Tenn.  37831-2501 

From smithn@orvb.saic.com Fri Oct 30 13:22:57 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21211; Fri, 30 Oct 92 13:22:57 -0500
Received: from orvb.SAIC.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15705; Fri, 30 Oct 92 13:27:35 -0500
	for announce-dylan@cambridge.apple.com
Received: from [139.121.81.63] by ORVB.SAIC.COM with SMTP; 
          Fri, 30 Oct 1992 13:23:05 EST
X-Popmail-Charset: English
Date: Fri, 30 Oct 92 14:31:23 EST
From: (Norman E. Smith, CDP) <smithn@orvb.saic.com>
Message-Id: <52285.smithn@orvb.saic.com>
To: announce-dylan@cambridge.apple.com
Subject: Please add me to the announce-dylan list

Please add  smithn@orvb.saic.com to the announce-dylan list.

Thanks,
Norm
==
Norman E. Smith, CDP          Science Applications International Corp
smithn@orvb.saic.com          PO Box 2501
                              301 Laboratory Road
615-481-2186                  Oak Ridge, Tenn.  37831-2501 

From cassels Fri Oct 30 16:42:34 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05029; Fri, 30 Oct 92 16:42:41 -0500
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05014; Fri, 30 Oct 92 16:42:34 -0500
Message-Id: <9210302142.AA05014@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Fri, 30 Oct 1992 16:43:03 -0400
To: info-dylan@cambridge.apple.com,
        gensym!ireland!jra@harvard.harvard.edu (Jim Allard)
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: small integers

>Scott Fahlman writes:
>    
>  I think it would be a serious mistake for the Dylan language to include a
>  required list of numeric optimizations at this early point (or any time
>  very soon).  Until we all get some experience with this, it won't be clear
>  what is easy, what is straightforward but perhaps too expensive for small
>  implementations, and what is very hard.  At present, we don't yet have a
>  complete system of types and declarations, or even full agreement on how to
>  handle bignums/integer-overflow.

Based on the technology available today, I expect there will be a
significant performance difference between "small implementations" and more
aggressive implementations.  I hope that groups like CMU will come up with
new technologies that will enable smaller high-performance implementations.
 But I believe that using currently-available technology, we'll be able to
get excellent performance from (larger) Dylan systems.

I agree that we're not ready for a "required list of ... optimizations." 
But it's probably not too early to have some terminology to distinguish
between "aggressive, professional-quality" implementations and "small,
clean" implementations.  My first thought was "Professional Dylan" vs.
"Academic Dylan", but Scott and his group could rightly take exception. 
Any better ideas?

>Jim Allard replies:
>I agree that it is not easy to get optimized numerics done right within the
>Common Lisp numerics system, either as a language designer or as a
>programmer.  I have a group of experienced Common Lisp programmers here, and
>many of them are still not confident in their ability to write numeric
>operations that will be deemed acceptable for optimization by the compilers
>we use.  This was such a problem that we had to write macros for fixnum and
>double-float numeric operations that we knew would work, and so our
>programmers now use those macros to get optimized arithmetic.

I agree that the Common Lisp numerics experience overall has been less than
satisfactory.  Certainly there have been notable successes with particular
implementations (Lisp machines, Python, etc.) but portable high efficiency
is awkward to impossible.  [Once upon a time I was a Fortran hacker, so I'd
like to do numerics well in Dylan.]  Numerics is one of many Common Lisp
areas whose deficiencies we are trying to address with Dylan.

>[some discussion elided]
>Jim continues:
>The following lists some sets of optimizations I would be interested in
>seeing.
>
>1) Compile-time method selection.
>
>Given adequate calls to seal, calls to make-read-only, and type declarations
>at a method call site, then a specific method is chosen and the call to it is
>staticly compiled in, or even in-lined for simple methods such as slot value
>access.  This optimizes away run-time type dispatching.  (This is what I
>think Dylan designers are attempting around seal and make-read-only, though I
>couldn't find it spelled out in detail within the Dylan manual.)

Indeed that's the intent, and our implementations do a lot of compile-time
method selection.  I don't know whether the language manual is the place to
spell out such things -- we'd like to keep the language definition as short
as possible.  But of course we should make it clear somehow.  Any ideas?

>2) Unboxed intermediate arithmetic values.
>
>Given that compile-time method selection succeeded, intermediate results of
>nested fixnum and double-float operations are passed from one operation to
>the next without boxing.  This optimizes away possibly expensive consing
>operations, makes the expression itself faster and also reduces the load the
>garbage collector imposes on an application.

Our implementations do this in many cases, and we expect to extend it
further.

>Determining numeric type of intermediate values of double-float expressions
>can be done without intermediate declaration since contagion between double-
>floats always produces double-floats.  (Would any experts please verify this?
>I'm fairly certain this always holds.)  For fixnums, it can be determined (by
>a *sufficiently smart* compiler) that intermediate values don't exceed the
>range of fixnums given tighter range restrictions on arguments to an
>expression.  These tighter bounds can be inferred when using Dylan's
>iteration over ranges, though an extention to the type system to declare
>ranges on integer types would provide this through a broader means.  Even
>given fixnum range-restricted type declarations, a means is needed to assert
>types of intermediate values.  Without it, Dylan users will be stuffing
>intermediate values back into fixnum type declared lexical variables to get
>an implicit type declaration of the expression's return value.

For floats of concrete type (<double-float>, etc.) arithmetic operations
(+, -, *, /) are closed.  Currently, functions such as SQRT can return
complex numbers given <real> inputs, so <double-float> isn't closed under
SQRT.  We expect to address this in some way -- maybe by redefining SQRT,
or by some other means.

For integers, you note the obvious problems and some solutions. 
Limited-range types are currently under consideration.

>3) Unboxed lexical variable contents.
>
>Given local variables that are type declared as fixnum or double-float, the
>memory for that location is allocated to hold the value in its unboxed form.
>Uses of the variable value for compile-time method selected expressions with
>unboxed intermediate values would use the unboxed value from this variable
>directly.  Uses of the variable value for other purposes would cause a boxing
>of the value before use.  Like #2, this optimizes away consing operations.

We have plans to support this, and partial support already in our
implementations.  Also under consideration are support for unboxed slots,
sequence and array elements, and module variables.

>4) Unboxed method arguments and return values.
>
>Given a user-defined (i.e.  not built-in) method that takes fixnum or
>double-float arguments, and returns values that can be determined at compile
>time to be fixnum or double-float, and given a compile-time selected call to
>the method, then the fixnum arguments and return values for this call are
>passed in their unboxed form.  Like #2 and #3, this optimizes away consing
>operations.

Already under consideration.

>Chris Fry writes:
>
>  I agree that there is no contradiction here [between correct programs and
>  fast programs]. In fact there's even a strong relationship between the two
>  in that there's nothing slower than a broken program.
>
>I don`t mean to jump all over you, Chris, but the sad fact is that there is a
>flippant dismissal of performance issues among many high level language
>proponents.  In my view, more than anything else, the reputation of Common
>Lisp as fat and slow prevented its commercial success and fueled the flight
>of expert systems products from Lisp to C, and numeric performance was the
>example I heard most often from people arguing against Lisp.
>
>It doesn't matter that Common Lisp implementations have now mainly got those
>issues under control.  A bad reputation has become firmly entrenched in the
>marketplace.  And it is still true that smart, well-meaning users of that
>language have a hard time using it correctly.
>
>If the Dylan designers mean what was said in the introduction to the manual
>about targeting C, C++, and Pascal users, that compatibility with Lisps is
>not a primary goal, and that they would "leave out anything that we do not
>know how to implement efficiently in both space and time", then I think this
>numerics issue qualifies as a problem area deserving of attention.

Indeed we are paying attention, and we agree that these are important
issues.

>Well, I've blathered on more than I planned here.  I don't mean to tell the
>Dylan designers how to do their jobs, and I don't diminish in any way the
>difficulty of the task set before them.  I've just gone through a lot with
>Common Lisp numerics and so have some strong opinions in this area.

We certainly appreciate your thoughtful concern, and your taking the time
to express your opinions.


From shunting@world.std.com Sun Nov  1 15:30:58 1992
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14031; Sun, 1 Nov 92 15:30:58 -0500
Received: from world.std.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19712; Sun, 1 Nov 92 15:35:52 -0500
	for announce-dylan@cambridge.apple.com
Received: by world.std.com (5.65c/Spike-2.0)
	id AA06360; Sun, 1 Nov 1992 15:30:00 -0500
Date: Sun, 1 Nov 1992 15:26:11 -0500 (EST)
From: Sam Hunting <shunting@world.std.com>
Subject: Re: Dylan manual...
To: smithn@orvb.saic.com
Cc: announce-dylan@cambridge.apple.com
In-Reply-To: <52034.smithn@orvb.saic.com>
Message-Id: <Pine.3.05.9211011509.A29797-a100000@world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Greetings!
 
We sat together on the podium at SGML '92 last week in Danvers. I had no
idea you were interested in Newton! We at BCS are *EXTREMELY* interested
in both Dylan and Newton; I would be fascinated to hear about your project.
 
Sam Hunting
Editor, BCS Magazine
The Boston Computer Society
One Kendall Square, Building 1400
Cambridge, MA 02139-1562

On Fri, 30 Oct 1992 smithn@orvb.saic.com wrote:

> Please send me a copy of the Dylan manual along with information on
> becoming a Newton developer. We are considering a SGML product
> here at SAIC that I believe would be appropriate to the Newton.
> 
>       Norman Smith
>       Science Applications International Corp.
>       P.O. Box 2501
>       301 Laboratory Road
>       Oak Ridge, Tenn. 37716
> Norman E. Smith, CDP          Science Applications International Corp
> smithn@orvb.saic.com          PO Box 2501
>                               301 Laboratory Road
> 615-481-2186                  Oak Ridge, Tenn.  37831-2501 




From info-dylan-request Mon Nov  2 02:32:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23560; Mon, 2 Nov 92 02:32:32 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23556; Mon, 2 Nov 92 02:32:30 -0500
Received: from sophia.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20743; Mon, 2 Nov 92 02:37:28 -0500
	for info-dylan@cambridge.apple.com
Received: from kwai.inria.fr by sophia.inria.fr with SMTP
	(5.65c/IDA-1.2.8) id AA20504; Mon, 2 Nov 1992 08:34:39 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 02 Nov 92 08:34:42+0100
X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
	Relayed; 02 Nov 92 08:34:00 GMT
Date: 02 Nov 92 08:34:00 GMT
From: Ranson <ranson@LANNION.cnet.fr>
Message-Id: <m0mlwIe-00000FC(a)lamd01>
To: kanderso@BBN.COM, moon@cambridge.apple.com
Subject: Re: small integers, numerical efficiency
Cc: info-dylan@cambridge.apple.com

While I could live with bignums/ratios/floats being in external libs in Dylan,
I'm worried about people deciding that this type is more useful than that type
based on their experience. We have heard a lot here from numerical analysis
people, but let's not forget there are more to Lisp programming than that. I
have written a large CL program that has industrial applications (production
optimization and such), and it relies on bignums and ratios and their efficient
implementation. No floats at all. MCL2.0 is fine for that, but I look forward
to a small and fast version written in Dylan!
     Daniel.


From info-dylan-request Mon Nov  2 15:53:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05116; Mon, 2 Nov 92 15:53:16 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05112; Mon, 2 Nov 92 15:53:14 -0500
Received: from alpha.Xerox.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22950; Mon, 2 Nov 92 15:58:17 -0500
	for info-dylan@cambridge.apple.com
Received: from fliff.wrc.xerox.com ([13.0.33.96]) by alpha.xerox.com with SMTP id <11825>; Mon, 2 Nov 1992 12:53:25 PST
Received: by fliff.wrc.xerox.com (4.1/SMI-4.1-wrc)
	id AA02373; Mon, 2 Nov 92 15:53:22 EST
Message-Id: <9211022053.AA02373@fliff.wrc.xerox.com>
To: info-dylan@cambridge.apple.com
Subject: Comments on Dylan
Date: 	Mon, 2 Nov 1992 12:53:19 PST
From: Jim Mayer <mayer@wrc.xerox.com>

I just finished reading the Dylan book, and thought I would share some
thoughts I had about the language.

In general, I was very happy with what I saw.  Most of the programming I do
can be broadly categorized as "systems" programming in Common Lisp.  I
enjoy using Common Lisp and CLOS, but have been frustrated by the
resource requirements of the implementations available to me.  I
would love to be able to write small, "unix" like, tools in Lisp
(currently I drop into "C" to do this sort of thing).

Here are some comments and some changes I would like to see in Dylan:

(1) Comment: I couldn't figure out how different comparison operations
were to be associated with hash tables.

(2) Unimportant comment: how about using #!fu instead of (setter fu).
If (setter fu) is just syntax, they why not use a syntaxy (?!?) form?

(2) Change: Add support for tables indexed by more than one key.  One
could call these "multi-dimensional" tables by analogy with vectors
and arrays.  Ideally, each "dimension" could be associated with a
different hash function.

Multi-dimensional hash tables are extremely useful for modeling
relations and for "memoizing" functions.  The alternative of providing
a sequence of keys requires a structure walking "=" table to be used
(which is very slow compared to "id" tables), and requires a sequence
to be allocated for each query.

(3) Addition: Consider allowing hash tables to take arbitrary comparison
and hash generation functions.  Also, consider whether or not the
"id-hash" could be exposed without overly limiting the range of
possible implementations.  For example, one could put the following
restrictions on the use of hash values:

	(a) The result of id-hash may change at any time, so hash
	    functions are not free to cache the results of calling
	    id-hash.

	(b) A table may "rehash" itself at any time, and user defined
	    hash functions may be called arbitrarily.

	(c) The results of a hash function may only be combined by
	    means of the "combine-hash" function.

(4) Addition: Add support for weak pointers and collections
(particularly deques And tables).  Weak data structures are very
useful for implementing caching schemes.

(5) Addition: Add support for finalization, while stressing that its
"proper" role is for supporting automatic collection of objects
outside the scope of normal storage management (such as file
descriptors).

(6) Comment: YES vote for a threads package as an optional library.

(7) Addition: add a denotation for classes and generic functions.
Classes and generic functions would then be at the same "level" as
numbers and methods (both of which have denotations).

(8) Addition: Currently the only way to create a read-only variable is
to use "define-class" or "define-generic-function".  There ought to be
a "define-readonly" that creates a read-only variable with an
arbitrary value.

(9) Addition: support the ability to declare that a given condition
evaluates to a TRUE value at all points within a lexical scope.  For
example:

    (bind (((x integer) 0))
	  (proclaim-function (method () (<= 0 x 5)))
	  ...
	  )

or (for a nicer syntax)

    (bind (((x integer) 0))
	  (proclaim (<= 0 x 5))
	  ...
	  )

This asserts that "x" lies within the range [0..5] at all points
within its scope.  This information can be checked, assumed, or
ignored by a compiler (just like type declarations in common lisp).

I prefer this approach to introducing a large type system because the
"proclaim" construct does not introduce a new sublanguage (such as the
common lisp type system).  It also avoids the complexity of talking
about "abstract" and "representation" types that common lisp gets
into.

Enjoy!

-- 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 Mon Nov  2 16:18:27 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05566; Mon, 2 Nov 92 16:18:28 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05562; Mon, 2 Nov 92 16:18:27 -0500
Received: from alpha.Xerox.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23038; Mon, 2 Nov 92 16:23:30 -0500
	for info-dylan@cambridge.apple.com
Received: from fliff.wrc.xerox.com ([13.0.33.96]) by alpha.xerox.com with SMTP id <11822>; Mon, 2 Nov 1992 13:18:47 PST
Received: by fliff.wrc.xerox.com (4.1/SMI-4.1-wrc)
	id AA02433; Mon, 2 Nov 92 16:18:45 EST
Message-Id: <9211022118.AA02433@fliff.wrc.xerox.com>
To: info-dylan@cambridge.apple.com
Subject: Re: Comments on Dylan 
In-Reply-To: Your message of "Mon, 02 Nov 92 12:53:19 PST."
             <9211022053.AA02373@fliff.wrc.xerox.com> 
Date: 	Mon, 2 Nov 1992 13:18:42 PST
From: Jim Mayer <mayer@wrc.xerox.com>

Oops... I left one out.

(10) Change: Make the reader case sensitive, but continue to use case
insensitive comparisons for variable names (since the Dylan designers
seem to like that style).  Introduce a new predicate "variable-id?" to
handle case insensitive comparisons of symbols.  The following code
shows how this would work:

    (bind ((fuBar 3)
	   (FuBar 4))
	  (print (list 'fuBar 'FuBar fuBar FuBar
                       (id? 'fuBar 'FuBar)
                       (variable-id? 'fuBar 'FuBar))))
    =>
    (fuBar FuBar 4 4 #f #t)

The "variable-id?" function can be implemented as a constant time
operation by having each symbol contain a pointer to a cannonical
representation.

The justification for this change is to let symbols as DATA be case
sensitive, while retaining case insensitive comparisons for variable
names.

Disclaimer #1: symbol case is a fundamentally religious issue.

Disclaimer #2: my way is the only way.

-- 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  5 12:17:38 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA21865; Thu, 5 Nov 92 12:17:40 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21861; Thu, 5 Nov 92 12:17:38 -0500
Received: from SGI.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01261; Thu, 5 Nov 92 12:22:55 -0500
	for info-dylan@cambridge.apple.com
Received: from relay.esd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for info-dylan@cambridge.apple.com id AA23957; Thu, 5 Nov 92 09:18:13 -0800
Received: from void.esd.sgi.com by mars.esd.sgi.com via SMTP (920330.SGI/911001.SGI)
	for @sgi.sgi.com:info-dylan@cambridge.apple.com id AA09876; Thu, 5 Nov 92 09:18:11 -0800
Received: from localhost.esd.sgi.com by void.esd.sgi.com via SMTP (920330.SGI/900721.SGI)
	for @mars.esd.sgi.com:info-dylan@cambridge.apple.com id AA12271; Thu, 5 Nov 92 09:20:50 -0800
Message-Id: <9211051720.AA12271@void.esd.sgi.com>
To: info-dylan@cambridge.apple.com
Cc: thant@void.esd.sgi.com
Subject: setter again
Date: Thu, 05 Nov 92 09:20:49 PST
From: thant@void.esd.sgi.com


I am anxious to see this setter thing resolved and I've been thinking
about it.

I have decided that the desire to hide the difference between setting
a slot and calling a method is fundamentally at odds with setter
syntax.  In other words, if one really wants the former, it must be
impossible to use the setter syntax on a slot from anywhere except
within the lexical scope of the class to which the slot belongs.

In other words, this should not be legal:

(set! (slot object) new-value)


This should be legal within the lexical scope of the object:

(set! slot new-value)


This is not as bad as it sounds because, the same name could be 
used for both a method and a value:

(method object) ; to get the value of 'method'

(method object new-value) ; to send a value to object via method.
			  ; The body of 'method' in this case may 
			  ; default to merely setting a slot.



This would also solve this problem:

(define-class <foo> (<object>)
  (a)
  (b))
;Value: <foo>

(define foo (make <foo>))
;Value: foo

(define-method set-foo (m (f <foo>) i)
  ((setter m) f i))	; currently this is literally translated as
			; (set! (m f) i) and method 'm' doesn't exist
;Value: set-foo

'set-foo' would be replaced with:

(define-method set-foo (m (f <foo>) i)
  (m f i))

I think in general, this simplifies the language and at the same time,
makes it more powerful.  It would be best if this was formalized in
the language itself, but I tried to achieve something similar within
the current language.  I ran into a problem.

Experiments in Thomas seem to show that a parameter list with a 
different number of arguments is considered illegal, although
I can't find anyplace in the Dylan manual that this is explicitly
stated.  For example:


(define-class <bar> (<object>)
  (item-slot))

(define-method item ((o <bar>))
  (item-slot o))

(define-method item ((o <bar>) new-value)	; pukes here
  (set! (item-slot o) new-value))

(define bar (make <bar>))

(item bar "hello")  ; should set item to "hello"

(item bar)	    ; should evaluate to the value of bar's item


Any input would be greatly appreciated.

thant







From info-dylan-request Thu Nov  5 13:31:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA23969; Thu, 5 Nov 92 13:31:36 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23965; Thu, 5 Nov 92 13:31:35 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01593; Thu, 5 Nov 92 13:37:00 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA29345; Thu, 5 Nov 92 13:32:20 -0500
Received: by easynet.crl.dec.com; id AA23654; Thu, 5 Nov 92 13:32:18 -0500
Date: Thu, 5 Nov 92 13:32:17 -0500
From: birkholz@crl.dec.com
Message-Id: <9211051832.AA08831@mingus.crl.dec.com>
To: info-dylan@cambridge.apple.com
Cc: thant@void.esd.sgi.com
In-Reply-To: Msg of Thu, 05 Nov 92 09:20:49 PST from thant@void.esd.sgi.com
Subject: setter again
X-Scheme-Mailer: Edwin 3.74

   Date: Thu, 05 Nov 92 09:20:49 PST
   From: thant@void.esd.sgi.com

   [...]

   Experiments in Thomas seem to show that a parameter list with a 
   different number of arguments is considered illegal, although
   I can't find anyplace in the Dylan manual that this is explicitly
   stated.  For example:

How about the top of page 47:  "All methods in and the
define-generic-function of a given generic function must have
congruent parameter lists.  Two parameter lists are congruent if they
have the same number of require parameters,..."

If you really what this dubious behavior, try:

(define-method item ((o <bar>) #rest new-value)	; no pukes
  (if new-value
      (set! (item-slot o) new-value))
  (item-slot o))

Matt Birkholz						Cambridge Research Lab
birkholz@crl.dec.com		<DARWIN><		Digital Equipment Corp.

From info-dylan-request Fri Nov  6 00:13:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06367; Fri, 6 Nov 92 00:13:32 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06363; Fri, 6 Nov 92 00:13:30 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03208; Fri, 6 Nov 92 00:18:56 -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 AA24802; Fri, 6 Nov 92 00:14:25 -0500
Received: from sh8810.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 001132.11369; Fri, 6 Nov 1992 00:11:32 EST
Received: by sh8810.telcom.oki.co.jp (5.57/6.4J.6-oki-921023)
	id AA22820; Fri, 6 Nov 92 11:18:39 +0900
Received: by okilab.okilab.oki.co.jp (4.0/6.4J.6)
	id AA21759; Fri, 6 Nov 92 11:19:10 JST
Received: from tomato.otsl.oki.co.jp by otsl2.otsl.oki.co.jp (4.0/6.4J.6)
	id AA12188; Fri, 6 Nov 92 11:10:05 JST
Received: by tomato.otsl.oki.co.jp (4.0/6.4J.6)
	id AA02434; Fri, 6 Nov 92 11:09:52 JST
Date: Fri, 6 Nov 92 11:09:52 JST
From: gomi@tomato.otsl.oki.co.jp (Hiroshi Gomi)
Return-Path: <gomi@tomato.otsl.oki.co.jp>
Message-Id: <9211060209.AA02434@tomato.otsl.oki.co.jp>
To: info-dylan@cambridge.apple.com
Subject: lambda-list congruence (Re: setter again)
Reply-To: gomi@otsl.oki.co.jp
In-Reply-To: Msg of Thu, 05 Nov 92 09:20:49 PST from thant@void.esd.sgi.com

I am Gomi.

I don't like a lambda-list congruence in parameter-list of method.
(CLOS, too)

I want to use a different number of arguments in method. Their 
methods have different classes or same classes.

Then if no ambiguousness, Dylan performs different number of arguments
in method definition. (--> I am glad and use Dylan.)

Exp.
(define-method foo ((x <number>) (y <number>)) (+ x y))
(define-method foo ((x <number>)) (+ 1 x))
;;; O.K.

(define-method foo ((x <number>) (y <number>)) (+ x y))
(define-method foo ((x <number>) #rest r) ...)
;;; N.G.

# But the costs of implementation and running are big .... uuun.

                                     From Go. (Nagoya.Japan)
				              gomi@otsl.oki.co.jp

From info-dylan-request Fri Nov  6 02:28:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA09619; Fri, 6 Nov 92 02:28:20 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09615; Fri, 6 Nov 92 02:28:18 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03440; Fri, 6 Nov 92 02:33:47 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9211060733.AA03440@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa21771; 6 Nov 92 2:28:25 EST
To: meehan@SRC.DEC.COM
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Multiple values in Dylan 
In-Reply-To: Your message of Sun, 25 Oct 92 15:14:41 -0800.
             <9210252314.AA21827@myrtle.pa.dec.com> 
Date: Fri, 06 Nov 92 02:28:10 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


Jim,

After thinking about your multiple-value proposal for a while, I've decided
that I really don't like it.  (This is the proposal that multiple values be
passed as arguments to the current continuation.)  To me the model
currently proposed for Dylan seems exactly right: not sloppy, not
inefficient, and much less likely to result in programmer errors than your
model.

I like the idea that, under normal circumstances, every function returns
exactly one value.  This is clear, simple, and intuitive.  It reduces the
cognitive load on the programmer.

A few functions -- a small minority -- produce several values that are
worth returning.  Often there is a single primary value and some other
values that are only of interest to a few callers.  If the called function
is prepared to return these extra values, and if the caller is interested
in receiving them, I think it's fine to have a mechanism that does this
without consing.  But I like the idea that this is a special return
protocol that you have to explicitly request, in Dylan's case by using the
multiple-value syntax of BIND.  If you don't do that, you can count on
getting back exactly one value.  You don't have to worry about any extra
return values that might pop up, and you don't have to clutter up your code
with special operations that get rid of any excess values.

Your scheme has a certain elegant symmetry to it.  Multiple return values
are the rule, not the exception.  The caller must know exactly what values
the callee will return, just as it must know how many arguments the callee
accepts.  If a #key protocol is used for the return values, the caller must
know exactly what keywords the callee is allowed to return.  I think that
this puts a significant extra load on the programmer, for very little gain.

Finally, I don't share your dislike of #f as the "I've got nothing interesting
to return" value.  I think that functions of zero values are very
confusing in a scheme like yours.

-- 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 Fri Nov  6 08:47:33 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19081; Fri, 6 Nov 92 08:47:35 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19076; Fri, 6 Nov 92 08:47:33 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03962; Fri, 6 Nov 92 08:52:34 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 6 Nov 1992 14:47:07 +0100
Received: by miles.ircam.fr, Fri, 6 Nov 1992 14:47:03 +0100
Date: Fri, 6 Nov 1992 14:47:03 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199211061347.AA06606@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: direct-instance declarations

Sealed-classes provide a mechanism for reducing dispatching, but
unfortunately the current mechanism is limited in annoying ways.
First, dispatching is performed at compile-time for only
sealed-classes at the leaves of the class heterarchy.  This prevents
creating efficient instantiable classes with subclasses.  Secondly,
after sealing a class it is forbidden to create a new subclass for
that class.  This means, for example, that none of the code for the
classes in the sealed collection classes can be leverage -- for
example it is impossible to create a new <table> subclass with a
slight variation.

I have a proposal that I think would keep all the advantages of the
sealed-class mechanism while overcoming these limitations.  I propose
a new object declaration, which I call an ``direct'' declaration.  It
is a means for specifying that an object is a direct-instance of a
declared class, instead of a general-instance of a declared class.
This would allow a programmer to precisely specify a sealed-class with
subclasses and would permit the compiler to perform the dispatching.
Also it would permit a programmer to subclass an already sealed-class,
because the original sealed-class could be specified in a precise
manner.

The default declaration would be general-instance and thus the change
would be backward-compatible with the current design.  In order
to achieve the best performance, though, the programmer must employ a
new syntax for specifying the type of a variable or parameter.  A
proposed syntax would be `(direct <table>)' (as opposed to just
`<table>') and perhaps there would be a read macro to shorten the
syntax.  A similar design has been employed in the Sather language and
has been shown to dramatically reduce the amount of dispatching
(without overly restricting the programmer).

-- jonathan

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


From info-dylan-request Fri Nov  6 09:26:50 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20795; Fri, 6 Nov 92 09:26:51 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20790; Fri, 6 Nov 92 09:26:50 -0500
Received: from RIVERSIDE.SCRC.Symbolics.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04156; Fri, 6 Nov 92 09:32:22 -0500
	for info-dylan@cambridge.apple.com
Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 945469; 6 Nov 1992 09:28:53-0500
Date: Fri, 6 Nov 1992 09:25-0500
From: Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
Subject: direct-instance declarations
To: Jonathan.Bachrach@ircam.fr
Cc: info-dylan@cambridge.apple.com
In-Reply-To: <199211061347.AA06606@miles.ircam.fr>
Message-Id: <19921106142512.1.NAHA@LILIKOI.SCRC.Symbolics.COM>

    Date: Fri, 6 Nov 1992 08:47 EST
    From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>

    Sealed-classes provide a mechanism for reducing dispatching, but
    unfortunately the current mechanism is limited in annoying ways.
    First, dispatching is performed at compile-time for only
    sealed-classes at the leaves of the class heterarchy.  This prevents
    creating efficient instantiable classes with subclasses.  Secondly,
    after sealing a class it is forbidden to create a new subclass for
    that class.  

I don't see this as a significant restriction.  I would see myself not
sealing a class untill I was ready to build a "shipable" executable of
my application.  At that point there is no longer a development
environment and there is no possibility of adding subclasses anyway.  I
don't think it's a big disadvantage to not seal a class until the
development cycle is over.

		 This means, for example, that none of the code for the
    classes in the sealed collection classes can be leverage -- for
    example it is impossible to create a new <table> subclass with a
    slight variation.

    [...]

From info-dylan-request Fri Nov  6 10:52:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24797; Fri, 6 Nov 92 10:52:16 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24792; Fri, 6 Nov 92 10:52:14 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04420; Fri, 6 Nov 92 10:57:47 -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 AA13000; Fri, 6 Nov 92 10:53:03 -0500
Posted-Date: Fri, 06 Nov 92 10:53:00 EST
Received: by thelonius.mitre.org (5.61/RCF-4C)
	id AA05480; Fri, 6 Nov 92 10:53:01 -0500
Message-Id: <9211061553.AA05480@thelonius.mitre.org>
To: info-dylan@cambridge.apple.com
Subject: Re: Sealing and direct-instance declarations
Date: Fri, 06 Nov 92 10:53:00 EST
From: john@linus.mitre.org

Jonathan Bachrach (Jonathan.Bachrach@ircam.fr) feels that the current
class sealing mechanism is too limiting.

Mark Nahabedian (naha@RIVERSIDE.SCRC.Symbolics.COM) replies:

  I don't see this as a significant restriction.  I would see myself
  not sealing a class untill I was ready to build a "shipable"
  executable of my application.  At that point there is no longer a
  development environment and there is no possibility of adding
  subclasses anyway.  I don't think it's a big disadvantage to not
  seal a class until the development cycle is over.

But you may want to ship not an application, but a library module
for others to use.  If you seal too much, the library may not be
extensible by another user, who will most likely wish to specialize
the leaves of your class hierarchy.  Conversely, you may not want the
user to know about the upper reaches of your class hierarchy, and so
the user does not know what classes to seal when HE is ready to ship
his application.

Now, he could just seal the "exported" leaves of your library module,
as those are the only classes his code references, but YOUR libarary
code probably references non-exported classes, and thus cannot be
optimized.  I think this is a real problem with the current sealing
approach, as I understand it.  I have to think about it some more, but
I think the "direct instance" declaration described by Bachrach would
not suffer from the same problems.

John Burger
john@mitre.org

From info-dylan-request Fri Nov  6 11:33:50 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA26705; Fri, 6 Nov 92 11:33:51 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA26700; Fri, 6 Nov 92 11:33:50 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04570; Fri, 6 Nov 92 11:39:06 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA05192@relay.tek.com>; Fri, 6 Nov 92 08:25:48 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA12258; Fri, 6 Nov 92 08:26:24 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA00819; Fri, 6 Nov 92 08:19:54 PST
Date: Fri, 6 Nov 92 08:19:54 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9211061619.AA00819@goldfish.MITRON.TEK.COM>
To: naha@riverside.scrc.symbolics.com
Cc: Jonathan.Bachrach@ircam.fr, info-dylan@cambridge.apple.com
In-Reply-To: Mark Nahabedian's message of Fri, 6 Nov 1992 09:25-0500 <19921106142512.1.NAHA@LILIKOI.SCRC.Symbolics.COM>
Subject: direct-instance declarations

   From: Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
       From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>

       Sealed-classes provide a mechanism for reducing dispatching, but
       unfortunately the current mechanism is limited in annoying ways.
       First, dispatching is performed at compile-time for only
       sealed-classes at the leaves of the class heterarchy.  This prevents
       creating efficient instantiable classes with subclasses.  Secondly,
       after sealing a class it is forbidden to create a new subclass for
       that class.  

   I don't see this as a significant restriction.  I would see myself not
   sealing a class untill I was ready to build a "shipable" executable of
   my application.  At that point there is no longer a development
   environment and there is no possibility of adding subclasses anyway.  I
   don't think it's a big disadvantage to not seal a class until the
   development cycle is over.

		    This means, for example, that none of the code for the
       classes in the sealed collection classes can be leverage -- for
       example it is impossible to create a new <table> subclass with a
       slight variation.


What about a scenario like the following: a class is given one
subclass that adds no new functionality but is sealed. Other
subclasses can be made that add functionality, but instances can be
made of the sealed class for the benefits that sealing provide.

			    Super Classes
                              \  |  /
			       \ | /
				\|/
		     Class-that-can-be-subclassed
                             /           \
			    /             \
			   /               \
Sealed-subclass-with-no-new-functionality   \			     
				            Other subclasses

--
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 Nov  6 11:57:52 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA27876; Fri, 6 Nov 92 11:57:54 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA27872; Fri, 6 Nov 92 11:57:52 -0500
Received: from talcott.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04773; Fri, 6 Nov 92 12:03:25 -0500
	for info-dylan@cambridge.apple.com
Received: by kurz-ai.com (MC 2.0/SMI-4.0)
	id AA21750; Fri, 6 Nov 92 11:18:51 EST
Received: by taiyo.kurz-ai.com (4.1/SMI-4.0)
	id AA11846; Fri, 6 Nov 92 11:17:51 EST
Date: Fri, 6 Nov 92 11:17:51 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9211061617.AA11846@taiyo.kurz-ai.com>
To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu, meehan@src.dec.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Scott_Fahlman's message of Fri, 06 Nov 92 02:28:10 EST
Subject: Multiple values in Dylan 

I hope there is more discussion of Jim's multiple-value proposal -- that
multiple values be passed as arguments to the current continuation --
because I think it is a good one.

I would like to reply to parts of Scott's message, in which he says:

   I like the idea that, under normal circumstances, every function returns
   exactly one value.  This is clear, simple, and intuitive.  It reduces the
   cognitive load on the programmer.

   A few functions -- a small minority -- produce several values that are
   worth returning.  Often there is a single primary value and some other
   values that are only of interest to a few callers.

   ...

   [In the current Dylan proposal,] You don't have to worry about any extra
   return values that might pop up, and you don't have to clutter up your code
   with special operations that get rid of any excess values.

   ...

   I think that functions of zero values are very
   confusing in a scheme like [Jim's].

If in fact a small minority of functions produce several values, then
ALMOST every function returns exactly one value.  That's intuitive enough
for me and my cognitive load -- I can handle the few that don't.

As for worrying about extra return values, I agree that the caller should
not need special operations to get rid of excess values IF the callee
agrees that the extra values are safely able to be considered optional.
In other words, just as a callee may specify that a tail end of given
arguments are optional, it might also specify that a tail end of its
returned values are optional to receive.  I don't know if this technically
improves or detracts from the overall symmetry of Jim's proposal, but it
does put the decision about constraints on argument passing in the hands of
the one function returning the values, rather than in each caller of it.

As for functions of zero values being very confusing in Jim's scheme:
Scott, could you give some examples?

From info-dylan-request Fri Nov  6 12:47:08 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29550; Fri, 6 Nov 92 12:47:09 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29546; Fri, 6 Nov 92 12:47:08 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04918; Fri, 6 Nov 92 12:52:39 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9211061752.AA04918@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa22509; 6 Nov 92 12:47:41 EST
To: Sam Pilato <samp@KURZ-AI.COM>
Cc: meehan@SRC.DEC.COM, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Multiple values in Dylan 
In-Reply-To: Your message of Fri, 06 Nov 92 11:17:51 -0500.
             <9211061617.AA11846@taiyo.kurz-ai.com> 
Date: Fri, 06 Nov 92 12:47:35 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    If in fact a small minority of functions produce several values, then
    ALMOST every function returns exactly one value.  That's intuitive enough
    for me and my cognitive load -- I can handle the few that don't.
    
Sure, a good programmer can handle most anything.  But the very existence
of multiple values that might pop up unbidden means that you've got one
more thing to worry about.  It would be a pain to have to remember that
certain built-in arithmetic functions return a second value that you
usually don't want and that you explicitly have to flush.  It would be an
even bigger pain, when dealing with someone else's library package, to
remember how many probably-unwanted-but-maybe-useful-to-someone values the
author decided to pass back.

If Meehan's proposal were adopted, rule 1 in our local style guidelines
would be that NO function should ever return other than one value unless
its name is MULTIPLE-VALUE-*, because now those additional return values
are more trouble than they are worth.

    As for worrying about extra return values, I agree that the caller should
    not need special operations to get rid of excess values IF the callee
    agrees that the extra values are safely able to be considered optional.

    In other words, just as a callee may specify that a tail end of given
    arguments are optional, it might also specify that a tail end of its
    returned values are optional to receive.  I don't know if this technically
    improves or detracts from the overall symmetry of Jim's proposal, but it
    does put the decision about constraints on argument passing in the hands of
    the one function returning the values, rather than in each caller of it.
    
First, I don't think you can come up with a good syntax or efficient
machinery for this.  The thought of values returning a bunch of keyword
value pairs so that the caller can treat some of these things as optional
is pretty ghastly.  Second, I don't think that "optionalness" of return
values is any business of the called function.  It is the caller that knows
which of these things are useful.

    As for functions of zero values being very confusing in Jim's scheme:
    Scott, could you give some examples?

Sure:

(cons (foo a) (bar b) (bletch c))

It kind of looks like too many arguments are being passed there, and my
sophisticated syntax-checking editor just complained.  But in this case
it's OK, since bar really does some side-effect and returns zero values, so
it acts sort of like a comment -- drop it in code anywhere.  BAR isn't
written yet, so none of the programming tools know that it's going to be
zero-valued.

(+ (foo a) (bar b) (bletch c))

How many numbers are we adding here?  The correct answer in this case is
27, but you sure can't tell that by looking at the code.  Turns out that
bar is not a cosntant, so it can be changed at runtime and none of this can
be open coded.

I'll take the occasional arbitrary #f any day over this sort of nonsense.

I repeat: the scheme presented in the book looks right to me.  I might go
one step farther and use a separate MULTIPLE-BIND call instead of
decorating the more commonly used BIND with extra fields.  And it would be
nice for a called function to have some way of detecting how many returns
its caller actually wants, so VALUES can avoid wasting effort calculating
and pushing extra values when they are just going to be discarded.  But
perhaps the SSC ("sufficiently smart compiler") can do that sort of thing
for you.

-- 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 Fri Nov  6 13:14:40 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00268; Fri, 6 Nov 92 13:14:42 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00264; Fri, 6 Nov 92 13:14:40 -0500
Received: from inet-gw-2.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05061; Fri, 6 Nov 92 13:20:13 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-2.pa.dec.com; id AA28451; Fri, 6 Nov 92 10:15:25 -0800
Received: by myrtle.pa.dec.com; id AA14261; Fri, 6 Nov 92 10:15:17 -0800
Message-Id: <9211061815.AA14261@myrtle.pa.dec.com>
To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu
Cc: Sam Pilato <samp@kurz-ai.com>, info-dylan@cambridge.apple.com
Subject: Re: Multiple values in Dylan 
In-Reply-To: Message of Fri, 06 Nov 92 12:47:35 EST    from Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU    <9211061752.AA10356@inet-gw-1.pa.dec.com>
Date: Fri, 06 Nov 92 10:15:16 -0800
From: meehan@src.dec.com
X-Mts: smtp


    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    Date: Fri, 06 Nov 92 12:47:35 EST
    To: Sam Pilato <samp@KURZ-AI.COM>
    
        As for functions of zero values being very confusing in Jim's scheme:
        Scott, could you give some examples?
    
    Sure:
    
    (cons (foo a) (bar b) (bletch c))
    
    It kind of looks like too many arguments are being passed there, and my
    sophisticated syntax-checking editor just complained.  But in this case
    it's OK, since bar really does some side-effect and returns zero values, so
    it acts sort of like a comment -- drop it in code anywhere.  BAR isn't
    written yet, so none of the programming tools know that it's going to be
    zero-valued.

Gack. You've given multiple-value-call semantics to ALL procedure 
calls.  I certainly never intended to propose anything like that! 
According to what I was suggesting, the form 
    (cons (foo a) (bar b) (bletch c)) 
is DEFINITELY erroneous, because an expression that is 
a procedure-argument must produce exactly one value. That's why I 
said that
    (+ (floor a) b)
was also wrong, because FLOOR didn't produce one value.

--Jim

From info-dylan-request Fri Nov  6 13:44:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00853; Fri, 6 Nov 92 13:44:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00848; Fri, 6 Nov 92 13:44:11 -0500
Received: from linus.mitre.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05241; Fri, 6 Nov 92 13:49:44 -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 AA20708; Fri, 6 Nov 92 13:44:59 -0500
Posted-Date: Fri, 06 Nov 92 13:44:54 EST
Received: by celebes.mitre.org (5.61/RCF-4C)
	id AA18491; Fri, 6 Nov 92 13:44:57 -0500
Message-Id: <9211061844.AA18491@celebes.mitre.org>
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Cc: ramsdell@linus.mitre.org, info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Multiple values in Dylan 
In-Reply-To: Your message of "Fri, 06 Nov 92 12:47:35 EST."
             <9211061752.AA04918@brazil.cambridge.apple.com> 
Date: Fri, 06 Nov 92 13:44:54 EST
From: John D. Ramsdell <ramsdell@linus.mitre.org>

>     Scott, could you give some examples?
> 
> Sure:
> 
> (cons (foo a) (bar b) (bletch c))
> 
> It kind of looks like too many arguments are being passed there, and my
> sophisticated syntax-checking editor just complained.  But in this case
> it's OK, since bar really does some side-effect and returns zero values, so
> it acts sort of like a comment -- drop it in code anywhere.  BAR isn't
> written yet, so none of the programming tools know that it's going to be
> zero-valued.
> 

As I understand it, this example would not be okay in Jim's version of
multiple values in Dylan.  Bar is being called in a position that
expects one value, but the bar you describe is returning no values.  A
continuation passing version of the expression follows.  Clearly, cons
is being called with too many arguments.

(foo
 a
 (lambda (foo-a)		; Foo's continuation
   (bar
    b
    (lambda (bar-b)		: Bar's contination
      (bletch
       c
       (lambda (bletch-c)	; Bletch's continuation
	 (cons
	  foo-a
	  bar-b
	  bletch-c
	  initial-continuation)))))))

You must call bar from an expression that expects exactly zero
values or from an expression that accepts any number of return values.
Try begin as in:

(begin (bar b) #t)

> (+ (foo a) (bar b) (bletch c))

This example is also in error for the same reason as the previous one.

John

From info-dylan-request Fri Nov  6 14:00:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01215; Fri, 6 Nov 92 14:00:16 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01211; Fri, 6 Nov 92 14:00:15 -0500
Received: from SEF-PMAX.SLISP.CS.CMU.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05385; Fri, 6 Nov 92 14:05:47 -0500
	for info-dylan@cambridge.apple.com
Message-Id: <9211061905.AA05385@brazil.cambridge.apple.com>
Received: from sef-pmax.slisp.cs.cmu.edu by SEF-PMAX.SLISP.CS.CMU.EDU
          id aa22679; 6 Nov 92 14:00:31 EST
To: meehan@SRC.DEC.COM
Cc: info-dylan@CAMBRIDGE.APPLE.COM
Subject: Re: Multiple values in Dylan 
In-Reply-To: Your message of Fri, 06 Nov 92 10:15:16 -0800.
             <9211061815.AA14261@myrtle.pa.dec.com> 
Date: Fri, 06 Nov 92 14:00:22 EST
From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    Gack. You've given multiple-value-call semantics to ALL procedure 
    calls.  I certainly never intended to propose anything like that! 
    According to what I was suggesting, the form 
        (cons (foo a) (bar b) (bletch c)) 
    is DEFINITELY erroneous, because an expression that is 
    a procedure-argument must produce exactly one value. That's why I 
    said that
        (+ (floor a) b)
    was also wrong, because FLOOR didn't produce one value.
    
Hmm...  I guess I did misunderstand your proposal then.  It seemed to me
that when you said "all the returned values are passed as arguments to the
current continuation, no more, no less" you meant that this works like
multiple-value-call.  Now we see that only single-return-value functions
are allowed in procedure arguments. and that multiple values are allowed
only in certain special forms.  Functions of 0 values would presumably be
allowed within things like BEGIN blocks, where the values are discarded
anyway.  Would functions of one value be allowed there as well?  That's
sloppy...

What this does is break the Dylan world down into two or three distinct
kinds of functions: one-valued, multi-valued, and (perhaps a separate
class) zero-valued.  For those functions, built-in and user defined, where
there is a primary return value and several less-useful ones, you would
have to define two versions of each.  I would argue that, for built-in
functions, the good names should go to the more commonly used single-value
versions.

So it seems to me, if I now understand the proposal, that what you've done
is to ghettoize the MV versions.  They can only be used if both the caller
and the callee specifically use the MV machinery, and it's an error if they
don't agree.  I much prefer the model in which the caller decides how many
values it wants, and the callee just returns everything that might be
useful.  This makes the called function more generic: you can call it for
one value or for many.

-- 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 Fri Nov  6 14:28:12 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01816; Fri, 6 Nov 92 14:28:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01812; Fri, 6 Nov 92 14:28:12 -0500
Received: from RIVERSIDE.SCRC.Symbolics.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05529; Fri, 6 Nov 92 14:33:42 -0500
	for Info-Dylan@cambridge.apple.com
Received: from PALLANDO.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 945827; 6 Nov 1992 14:30:12-0500
Date: Fri, 6 Nov 1992 14:30-0500
From: Allan C. Wechsler <ACW@RIVERSIDE.SCRC.Symbolics.COM>
Subject: Re: Multiple values in Dylan 
To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
Cc: Info-Dylan@cambridge.apple.com, samp@KURZ-AI.COM, meehan@SRC.DEC.COM
In-Reply-To: <9211061752.AA04918@brazil.cambridge.apple.com>
Message-Id: <19921106193003.6.ACW@PALLANDO.SCRC.Symbolics.COM>

    Date: Fri, 6 Nov 1992 12:47 EST
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


	If in fact a small minority of functions produce several values, then
	ALMOST every function returns exactly one value.  That's intuitive enough
	for me and my cognitive load -- I can handle the few that don't.
    
    Sure, a good programmer can handle most anything.  But the very existence
    of multiple values that might pop up unbidden means that you've got one
    more thing to worry about.  It would be a pain to have to remember that
    certain built-in arithmetic functions return a second value that you
    usually don't want and that you explicitly have to flush.  

I think the names of functions that return multiple values should adhere
to naming conventions that don't let you forget, for example,
FLOOR-AND-REMAINDER, or READ-CHAR-AND-EOF.  Not that I'm advocating that
exact convention, but some such convention could surely answer this
particular objection.
							       
							       It would be an
    even bigger pain, when dealing with someone else's library package, to
    remember how many probably-unwanted-but-maybe-useful-to-someone values the
    author decided to pass back.

The author of a library package can certainly shaft you with unexpected
interfaces.  No set of language design decisions is going to protect you
against this.  A naming convention would help here, too.

    If Meehan's proposal were adopted, rule 1 in our local style guidelines
    would be that NO function should ever return other than one value unless
    its name is MULTIPLE-VALUE-*, because now those additional return values
    are more trouble than they are worth.

The naming convention need not be that obtrusive -- this is a straw man.
A natural result would be that most multi-valued functions would have
single-valued interfaces that you would call when you only wanted the
first value.
    
[...]

			Second, I don't think that "optionalness" of return
    values is any business of the called function.  It is the caller that knows
    which of these things are useful.

I agree with this.

[...]

    (cons (foo a) (bar b) (bletch c))

    It kind of looks like too many arguments are being passed there, and my
    sophisticated syntax-checking editor just complained.  But in this case
    it's OK, since bar really does some side-effect and returns zero values, so
    it acts sort of like a comment -- drop it in code anywhere.  BAR isn't
    written yet, so none of the programming tools know that it's going to be
    zero-valued.

No, you must have misunderstood Meehan's proposal.  If BAR returned zero
values, it would be calling the current continuation with zero
arguments.  The current continuation would signal too-few-arguments.
The compiler and your editor have not lost their license to complain
about the above expression.  

    (+ (foo a) (bar b) (bletch c))

    How many numbers are we adding here?  The correct answer in this case is
    27, but you sure can't tell that by looking at the code.  Turns out that
    bar is not a cosntant, so it can be changed at runtime and none of this can
    be open coded.

I'm worried that everyone is going to have this misimpression.  Unless I
am mistaken, Meehan was not proposing that Dylan have MARVEL syntax,
where all the returned values are passed to the calling function.
Rather, the proposal states that all the returned values be passed to
the current continuation, which is quite different.  In ordinary
function-argument position, the current continuation takes exactly one
argument, and it is simply an error to call it with any other number of
arguments.  Thus, an expression in argument position would be
constrained to be single-valued.

    I'll take the occasional arbitrary #f any day over this sort of nonsense.

I would too, but that sort of nonsense has not been proposed.

    I repeat: the scheme presented in the book looks right to me.  I might go
    one step farther and use a separate MULTIPLE-BIND call instead of
    decorating the more commonly used BIND with extra fields.  

I sort of liked the expanded BIND.  I even think that it should be
extended to allow #key.  Thus, the "butlast" of a BIND-clause would
exactly be the parameter-list of the current continuation.

From info-dylan-request Fri Nov  6 14:40:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02070; Fri, 6 Nov 92 14:40:07 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02065; Fri, 6 Nov 92 14:40:04 -0500
Received: from inet-gw-2.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05598; Fri, 6 Nov 92 14:45:36 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-2.pa.dec.com; id AA02975; Fri, 6 Nov 92 11:40:52 -0800
Received: by myrtle.pa.dec.com; id AA14436; Fri, 6 Nov 92 11:40:51 -0800
Message-Id: <9211061940.AA14436@myrtle.pa.dec.com>
To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu
Cc: info-dylan@cambridge.apple.com
Subject: Multiple values, revised proposal
Date: Fri, 06 Nov 92 11:40:50 -0800
From: meehan@src.dec.com
X-Mts: smtp


After reviewing the discussion on multiple values, I would like to 
propose a simpler, less stringent rule that I think more people would 
find acceptable.  In describing BIND, the book says on page 34: 

    If the _init_ produces more values than there are _variable-names_, 
    the extra values are ignored.  If the _init_ produces fewer values 
    than there are _variable-names_, then the extra variables are 
    bound to #f.

Proposal (part 1 of 2): Delete the second sentence.

1. Ignoring extra values corresponds to a function's ignoring some 
of its parameters, which is common in all languages.  *Supplying* 
extra values, on the other hand, seems to me to be a bad idea.

    At best, it's Dylan's way of providing &AUX, which was unnecessary 
    in Common Lisp; it was yet another syntax for binding variables, 
    and it offered no additional semantics. 

    At worst, the programmer was *expecting* some "actual" values, 
    and really deserves to get an error about "too few values". 

2. This eliminates the need for VAL1 (a hypothetical syntax form 
for discarding all values but the first), and we can once again write 

        (+ (floor a) b)

since the second value is now ignored, and

        (begin ... last-form)

where ALL the values prior to _last-form_ are ignored.

Proposal (part 2 of 2): Add multiple-value-call.

My earlier suggestion that BIND should allow #key and #next is really 
just a way of providing an alternate syntax for anonymous methods.  
That is, I could write the continuation as 

    (method (a b #key ...) ...)

and I would, except that since Dylan lacks multiple-value-call, there's 
no way for me to call this method, other than the kludgey

    (bind ((#rest args mv-exp))
      (apply (method (a b #key ...) ...) args)

So let's add a multiple-value-call to Dylan.  It should NOT, however, 
be like Common Lisp's, which allowed an arbitrary number of multiple-valued 
expressions, and "appended" all the results together. (Did anyone 
ever use that feature?) Dylan's should be much simpler.  Add to page 73: 

    (multiple-value-call _function_ _form_) => values      [Special form]

    This is like APPLY.  The values produced by _form_ are spread 
    out and taken as individual arguments to _function_.

--Jim

From info-dylan-request Fri Nov  6 16:45:09 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04536; Fri, 6 Nov 92 16:45:14 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04527; Fri, 6 Nov 92 16:45:09 -0500
Received: from RIVERSIDE.SCRC.Symbolics.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05951; Fri, 6 Nov 92 16:50:30 -0500
	for Info-Dylan@cambridge.apple.com
Received: from PALLANDO.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 945946; 6 Nov 1992 16:46:58-0500
Date: Fri, 6 Nov 1992 16:46-0500
From: Allan C. Wechsler <ACW@RIVERSIDE.SCRC.Symbolics.COM>
Subject: Multiple values, revised proposal
To: Info-Dylan@cambridge.apple.com
In-Reply-To: <9211061940.AA14436@myrtle.pa.dec.com>
Supersedes: <19921106214536.9.ACW@PALLANDO.SCRC.Symbolics.COM>
Comments: Corrected recipient-list
Message-Id: <19921106214650.0.ACW@PALLANDO.SCRC.Symbolics.COM>

    Date: Fri, 6 Nov 1992 14:40 EST
    From: meehan@src.dec.com

[From the book:]

	If the _init_ produces more values than there are _variable-names_, 
	the extra values are ignored.  If the _init_ produces fewer values 
	than there are _variable-names_, then the extra variables are 
	bound to #f.

    Proposal (part 1 of 2): Delete the second sentence.

    1. Ignoring extra values corresponds to a function's ignoring some 
    of its parameters, which is common in all languages.  

Just because everyone else does is wrong doesn't mean we can't get it
right.  If it were good for functions to ignore extra arguments, we
would define them all to do so.  But we don't -- instead, we have
too-many-args errors.

Ignoring extra values in BIND might be OK -- I don't happen to think so
-- but it can't be for the reason cited, that it's like functions
ignoring extra arguments.
							  
							  *Supplying* 
    extra values, on the other hand, seems to me to be a bad idea.

Agreed.

    2. This eliminates the need for VAL1 (a hypothetical syntax form 
    for discarding all values but the first), and we can once again write 

	    (+ (floor a) b)

I say, the current floor should be renamed, say (I don't care) to
FLOOR-AND-REMAINDER, and then define FLOOR to return one value.  Then
you can write (+ (floor a) b) also.

    since the second value is now ignored, and

	    (begin ... last-form)

    where ALL the values prior to _last-form_ are ignored.

BEGIN and kin could easily be defined to be tolerant of multi-valued
forms in its body.

(The following is not a very strong opinion.

I vaguely feel that the nonlast operands of BEGIN should be required to
return zero values.  An operator named something like FOR-EFFECT could
be introduced to help.

This is based on an intuition that we would learn something important --
I'm not sure what -- by being forced to say what to do with each value.
The tacit disposal of extra values just feels mildly pernicious to me.)

    Proposal (part 2 of 2): Add multiple-value-call.

Agreed.

    My earlier suggestion that BIND should allow #key and #next is really 
    just a way of providing an alternate syntax for anonymous methods.  

I still think, for consistency and symmetry, that the BUTLAST of a
BIND-clause should be, exactly, a parameter list.

    So let's add a multiple-value-call to Dylan.  It should NOT, however, 
    be like Common Lisp's, which allowed an arbitrary number of multiple-valued 
    expressions [...]

Agreed.



From moon Fri Nov  6 17:11:55 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA05034; Fri, 6 Nov 92 17:12:02 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA05028; Fri, 6 Nov 92 17:11:55 -0500
Message-Id: <9211062211.AA05028@cambridge.apple.com>
Date: Fri, 06 Nov 92 17:13:40 EST
From: moon (David A. Moon)
To: meehan@src.dec.com
Subject: Re: Multiple values, revised proposal
Cc: info-dylan@cambridge.apple.com

> Date: Fri, 06 Nov 92 11:40:50 -0800
> From: meehan@src.dec.com
> 
> ....In describing BIND, the book says on page 34: 
> 
>     If the _init_ produces more values than there are _variable-names_, 
>     the extra values are ignored.  If the _init_ produces fewer values 
>     than there are _variable-names_, then the extra variables are 
>     bound to #f.
> 
> Proposal (part 1 of 2): Delete the second sentence.
> 
> 1. Ignoring extra values corresponds to a function's ignoring some 
> of its parameters, which is common in all languages.  *Supplying* 
> extra values, on the other hand, seems to me to be a bad idea.
> 
>     At best, it's Dylan's way of providing &AUX, which was unnecessary 
>     in Common Lisp; it was yet another syntax for binding variables, 
>     and it offered no additional semantics. 

The defaulting of missing values in BIND is to support programming styles such 
as the following:

  (bind ((frobby 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 two values:
  ;;  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 (foo fah)))))))))

In your proposal find-frobby would have to be written as

  (define find-frobby (method (name)
    (bind ((x ..la de dah..))
      (if (and (umpty ump...)
               (something something something...))
          (bind ((frobby (do dah ...)))
            (if (no-good? frobby)
              (values frobby (foo fah))
              (values #f #f)))
          (values #f #f)))))

or maybe as some horror show involving bind-exit.  If it's okay to rely on the 
"failure" path of when, unless, and cond to default to #f when one value is 
being returned, then it should be okay to rely on it to default to #f #f when 
two values are being returned.

I hope this clarifies for you the motivation that led to the current 
definition of the semantics of multiple values in Dylan and in Common Lisp.

>     At worst, the programmer was *expecting* some "actual" values, 
>     and really deserves to get an error about "too few values". 

It's not clear to me why you think it's okay to let bind accept values of the 
wrong type if the programmer doesn't put a specializer in the bind, but it's 
not okay to let bind accept missing values if the programmer doesn't put a 
specializer in the bind.  In other words, I think missing values that the 
caller was expecting are a type error and we already have a way to detect and 
report type errors in bind, so we don't really need to put in another 
mechanism.  That's just my personal opinion.

From info-dylan-request Fri Nov  6 18:15:51 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06192; Fri, 6 Nov 92 18:15:52 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06188; Fri, 6 Nov 92 18:15:51 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06335; Fri, 6 Nov 92 18:21:25 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA28294; Fri, 6 Nov 92 18:16:36 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA18847; Fri, 6 Nov 1992 18:14:32 -0500
Date: Fri, 6 Nov 1992 18:14:32 -0500
Message-Id: <9211062314.AA18847@lakatos.osf.org>
To: ACW@RIVERSIDE.SCRC.Symbolics.COM
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Allan C. Wechsler's message of Fri, 6 Nov 1992 14:30-0500 <19921106193003.6.ACW@PALLANDO.SCRC.Symbolics.COM>
Subject: Multiple values in Dylan 
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

From the point of view of readability, ignored extra value returns
don't seem so bad.

Named returns could improve readability a lot.

Using #f to mean both boolean False and no-value seems error-prone; so
does letting anything that's not #f mean #t.  I know, it's a
long-standing Lisp tradition, but then so is () == #f, which Dylan
does fix.

This comes up when some of the additional value returns are booleans
which are only sometimes valid.  If you test them before checking
whether they're valid, you get misleading results.  For that matter,
you can't even use type checking if you believe that they're always
valid, since all values are legitimate booleans.  If in some
unexpected case they turn out not to be valid, an error won't be
signaled.

So why not make #f and #t the only valid booleans, and reserve #none
for "invalid"?

	-s

From info-dylan-request Fri Nov  6 18:24:46 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06379; Fri, 6 Nov 92 18:24:47 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06375; Fri, 6 Nov 92 18:24:46 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06414; Fri, 6 Nov 92 18:30:21 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA28443; Fri, 6 Nov 92 18:25:37 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA18853; Fri, 6 Nov 1992 18:23:33 -0500
Date: Fri, 6 Nov 1992 18:23:33 -0500
Message-Id: <9211062323.AA18853@lakatos.osf.org>
To: macrakis@osf.org
Cc: ACW@RIVERSIDE.SCRC.Symbolics.COM, info-dylan@cambridge.apple.com
In-Reply-To: Stavros Macrakis's message of Fri, 6 Nov 1992 18:14:32 -0500 <9211062314.AA18847@lakatos.osf.org>
Subject: Multiple values in Dylan 
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

Oops, my note is incomplete.  Instead of:

   Named returns could improve readability a lot.

Please read:

   Keyword names on multiple-value returns (on both ends, of course)
   could improve readability a lot, and catch stupid errors.  Some
   syntax would need to be invented for this.

	-s


From info-dylan-request Fri Nov  6 21:48:35 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA10334; Fri, 6 Nov 92 21:48:37 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA10330; Fri, 6 Nov 92 21:48:35 -0500
Received: from inet-gw-2.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06786; Fri, 6 Nov 92 21:54:08 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-2.pa.dec.com; id AA18061; Fri, 6 Nov 92 18:49:25 -0800
Received: by myrtle.pa.dec.com; id AA15166; Fri, 6 Nov 92 18:49:22 -0800
Message-Id: <9211070249.AA15166@myrtle.pa.dec.com>
To: info-dylan@cambridge.apple.com
Subject: CFV: comp.lang.dylan
Date: Fri, 06 Nov 92 18:49:21 -0800
From: meehan@src.dec.com
X-Mts: smtp


As promised, here's the Call For Votes on comp.lang.dylan, as posted 
to a zillion newsgroups.  Vote early (if not often :-).

------- Forwarded Message

From: meehan@src.dec.com (Jim Meehan)
Date: Sat, 7 Nov 92 02:37:23 GMT
Subject: CFV: comp.lang.dylan
Newsgroups: news.announce.newgroups,comp.object,comp.lang.scheme,comp.lang.lisp.mcl,comp.lang.c++,comp.lang.misc,comp.lang.smalltalk,comp.lang.functional,comp.lang.clos,comp.lang.lisp
Sender: news@src.dec.com (News)
Message-ID: <1992Nov7.023723.15686@src.dec.com>

CALL FOR VOTES
--------------

NAME:
	comp.lang.dylan

STATUS:
	unmoderated

CHARTER:
	For discussion of the Dylan language. The newsgroup would be
	gatewayed with the mailing list info-dylan@cambridge.apple.com.

COMMENTS:
Dylan(TM) is a new object-oriented language, described in a book
published by Apple Computer in April 1992.  Many people have expressed
interest in the language since then, and prototype implementations are
now appearing.

In September, Apple created four public mailing lists for discussions
of Dylan; the one called info-dylan is used for discussing any and all
aspects of the language.  In just over a month, the volume of mail on
info-dylan has reached the point where a newsgroup would be more
useful than a mailing list; indeed, some subscribers have already
removed their names from the list because of the high volume.  Apple
will maintain a gateway with the mailing list so that current
subcribers to info-dylan who lack newsgroup access will still be able
to participate in the discussions.

HOW TO VOTE:
	All votes should be mailed to meehan@src.dec.com.

	To vote in favor, use "comp.lang.dylan YES" as the Subject.
	To vote against, use "comp.lang.dylan NO" as the Subject.
	
	(These are only suggestions. I'll actually read the messages.)


SCHEDULE:
	The voting period will end November 30, 1992.

------- End of Forwarded Message

From info-dylan-request Fri Nov  6 22:25:43 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11132; Fri, 6 Nov 92 22:25:46 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11128; Fri, 6 Nov 92 22:25:43 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06889; Fri, 6 Nov 92 22:31:11 -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 AA18698; Fri, 6 Nov 92 22:26:23 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 222542.23975; Fri, 6 Nov 1992 22:25:42 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA21316; Fri, 6 Nov 92 15:59:46 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA02983; Fri, 6 Nov 92 15:59:44 PST
Date: Fri, 6 Nov 92 15:59:44 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211062359.AA02983@eagle.sharebase.com>
To: ACW@RIVERSIDE.SCRC.Symbolics.COM, macrakis@osf.org
Subject: Re:  Multiple values in Dylan
Cc: info-dylan@cambridge.apple.com

/// >From the point of view of readability, ignored extra value returns
/// >don't seem so bad.

I agree thoroughly.

/// Named returns could improve readability a lot.
/// 
/// Using #f to mean both boolean False and no-value seems error-prone; so
/// does letting anything that's not #f mean #t.  I know, it's a
/// long-standing Lisp tradition, but then so is () == #f, which Dylan
/// does fix.
///
/// This comes up when some of the additional value returns are booleans
/// which are only sometimes valid.  If you test them before checking
/// whether they're valid, you get misleading results.  For that matter,
/// you can't even use type checking if you believe that they're always
/// valid, since all values are legitimate booleans.  If in some
/// unexpected case they turn out not to be valid, an error won't be
/// signaled.

The same design-flaw exists in 'C' -- when a function returns a pointer, NULL
can be returned to signal an error.  Functions returning integers though have
no value that can be returned as 'not an integer.'

Having true error values can be (provided that method dispatch is modified
accordingly) a real benefit for readability's sake.  Errors are logically
checked by checking the return value of a function.  This way, all exceptional
cases are reported to the caller in the same way, rather than some as #f, some
as 0, some as -1, and some as requiring an exception handler to have been set
before calling the function in question.  Besides removing the idea of a non-
local GOTO from common (in my opinion _recoverable_) exception handling, it
can really get us out of some of the tight places we find ourselves when
discussing the correct behaviour of special forms... like bind.

/// So why not make #f and #t the only valid booleans, and reserve #none
/// for "invalid"?

I like this idea, but I'd want to extend it.  See the following proposal on
giving Dylan a value-oriented exception system.  (Yes, I know this is a little
tangental, but it really fits well in this context)  One of the things that
greatly impressed me about Dylan was that it was Object Oriented without
losing LISPs origional Value Orientation (as contrasted to FORTRAN [etc.]'s
Procedural Orientation).  The exception system currently in the Dylan spec,
though, seems to be inspired by procedure oriented programming languages.  It
was the one part of the language I was least impressed by.

///         -s
/// 

	-- Scot

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

Proposal:

	Add a built-in class <undefined> with two subclasses: <bottom> and
<top>.  All exception classes would belong to <undefined>.  #bottom would be
the only object that is a direct instance of <bottom>.  <bottom> should be
sealed, and <top> left open for user-defined exceptions.  <undefined> should
not inherit from <object> for reasons listed below:

As <top> is subclassed, additional slots may be added to carry information,
of course.  Like (define-class <file-not-found> (<top>)
			(file-name <string>)  ;; syntax may be wrong
			)
..for example.

Modifications to Method-Dispatch:
				(Why <undefined> should NOT inherit <object>)

When method dispatch is given an <undefined> parameter, it should consult
the methods within the generic function for methods working _without_ certain
values (e.g., methods whose corresponding parameter's class restriction(s)
inherit from <undefined> or are <undefined> themselves).  If no method can
be found, then the system should stop.  For this reason, methods should not
be considered part of <object>.  Otherwise, errors will cascade in
unpredictable, and unreasonable ways.

An alternate method dispatch scheme is to provide a <top> value from the
dispatcher, that would contain a slot for the <undefined> value for which
method-dispatch was unable to find an appropriate method.  This way, an
un-caught exception would fall through the initial function invocation of the
program, containing a detailed back-trace.  Since exceptions are, well,
exceptional, this performance hit really wouldn't be noticeable.  It also
provides a clear way to orderly exit from a program.  Note also that allowing
errors to 'cascade' thus provides a much more sane approach than if <undefined>
inheritted <object>, which would cause an _entire_ stack dump (mostly
irrelevant and confusing)

Also, an implementation of display/print (used in the read-eval-print loop)
should be provided allowing the developer to brouse through errors, so that
a back-trace doesn't simply fill the screen, scroll off, force the offending
code out of the text-buffer being worked with, etc.

It would probably be best for implementations to provide both of these
features as options.  Also, NB that <undefined>, renamed to <error> could
continue to function as in the Dylan spec.  This would give language users the
choice of how to handle exceptions... With 'values' or with non-local flow of
control.

From info-dylan-request Mon Nov  9 11:57:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA22039; Mon, 9 Nov 92 11:57:24 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22034; Mon, 9 Nov 92 11:57:22 -0500
Received: from talcott.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01705; Mon, 9 Nov 92 12:03:19 -0500
	for info-dylan@cambridge.apple.com
Received: by kurz-ai.com (MC 2.0/SMI-4.0)
	id AA25963; Mon, 9 Nov 92 11:11:12 EST
Received: by taiyo.kurz-ai.com (4.1/SMI-4.0)
	id AA13015; Mon, 9 Nov 92 11:10:17 EST
Date: Mon, 9 Nov 92 11:10:17 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9211091610.AA13015@taiyo.kurz-ai.com>
To: moon@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: David A. Moon's message of Fri, 06 Nov 92 17:13:40 EST
Subject: Multiple values, revised proposal

>The defaulting of missing values in BIND is to support programming styles such 
>as the following:
>
>  (bind ((frobby 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 two values:
>  ;;  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 (foo fah)))))))))
>
>In your [Meehan's] proposal find-frobby would have to be written as
>
>  (define find-frobby (method (name)
>    (bind ((x ..la de dah..))
>      (if (and (umpty ump...)
>		(something something something...))
>	   (bind ((frobby (do dah ...)))
>	     (if (no-good? frobby)
>	       (values frobby (foo fah))
>	       (values #f #f)))
>	   (values #f #f)))))

What's wrong with the following version?  Perhaps some will find the
use of set! objectionable, but I don't understand why.  This version
avoids the need for defaulting missing values in BIND, and also makes
clear to compiler and programmer that it offers to return exactly two
values.  Perhaps you don't find anything particularly wrong with this
version, but would nevertheless like to support the no-setting style?

  (define find-frobby (method (name)
    (bind ((x ..la de dah..)
	   (frobby #f)
	   (path-to-frobby #f))
      (when (umpty ump...)
	 (when (something something something...)
	   (set! frobby (do dah ...))
	   (unless (no-good? frobby)
	     (set! path-to-frobby (foo fah)))))
      (values frobby path-to-frobby))))

From info-dylan-request Wed Nov 11 02:32:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11896; Wed, 11 Nov 92 02:32:19 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11890; Wed, 11 Nov 92 02:32:15 -0500
Received: from holonet.holonet.net by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06629; Wed, 11 Nov 92 02:38:17 -0500
	for info-dylan@cambridge.apple.com
Received: by holonet.net (5.57/Ultrix3.0-C)
	id AA19199; Tue, 10 Nov 92 23:33:17 -0800
Received: from Planet BMUG (FirstClass[14888]) by PostalUnion Lite 1.0.4
   id AA14888.101487; at Tue, 10 Nov 1992 23:12:57 PST
Message-Id: <1992Nov10.210215.101487@bmug.org>
To: info-dylan@cambridge.apple.com
From: alex_D._holub@bmug.org
Organization: BMUG, Inc.
Date: Tue, 10 Nov 1992 21:02:15 PST
Subject: mailing list

I heard of your new Dylan Language and would like to be put on your mailing
list.

Thank you.
***************************************************************************
             From Planet BMUG, the FirstClass BBS of BMUG, Inc.
              The above message was gatewayed via PostalUnion
***************************************************************************
The message contained in this posting is entirely the poster's personal
opinion.  Any possible, real or perceived, (dis)similarities with the
views held by BMUG, are purely coincidental.
***************************************************************************

From info-dylan-request Wed Nov 11 15:29:00 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00639; Wed, 11 Nov 92 15:29:01 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00635; Wed, 11 Nov 92 15:29:00 -0500
Received: from inet-gw-2.pa.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08055; Wed, 11 Nov 92 15:35:09 -0500
	for info-dylan@cambridge.apple.com
Received: by inet-gw-2.pa.dec.com; id AA23900; Wed, 11 Nov 92 12:30:04 -0800
Received: by myrtle.pa.dec.com; id AA22681; Wed, 11 Nov 92 12:30:01 -0800
Message-Id: <9211112030.AA22681@myrtle.pa.dec.com>
To: info-dylan@cambridge.apple.com
Subject: comp.lang.dylan: starting over
Date: Wed, 11 Nov 92 12:30:00 -0800
From: meehan@src.dec.com
X-Mts: smtp


The process of creating the comp.lang.dylan newsgroup to replace 
the info-dylan mailing list had been moving right along -- lots of 
votes came in over the weekend -- but alas, we have to start over 
from the beginning.

The Usenet guidelines for creating newsgroups specify that the Request 
For Discussion (RFD) and the Call For Votes (CFV) be posted to 
news.announce.newgroups.  I did that (in addition to sending copies 
to info-dylan, comp.lang.lisp, etc.), but it seems that on our local 
system, news.announce.newgroups was not installed as a "moderated" 
group.  The effect of this single incorrect bit (!) was that my messages 
got into the local copy of the newsgroup without going through the 
moderator, David Lawrence (tale@uunet.uu.net). The RFD and CFV were 
therefore never approved, and the whole discussion and vote is invalid. 

The problem is not simply that the proposal lacked someone's approval. 
The real issue is that because it wasn't approved, it didn't go 
out over the net to all the usenet sites, so the only people who 
ever participated in the discussion and vote were the folks who saw 
the message via info-dylan, comp.lang.lisp, etc.

In other words, we were arguably preaching to the converted, and 
it was not a fair election. 

My apologies to all who sent in comments and votes.  At least it 
makes for a good story about the importance of a single bit.

Now we start over.  I've *mailed* a new copy of the RFD to David 
Lawrence and asked him to post it to news.announce.newgroups and 
cross-post it to comp.lang.lisp, etc.  If all goes will, it should 
show up soon, and you'll have 3 weeks in which to *discuss* the proposal, 
which you do by posting messages to news.groups. Then, in 3 weeks, 
I'll issue a new Call For Votes, and then you can vote (again).  
With luck, we'll be done by New Year's. 

--Jim Meehan

From info-dylan-request Wed Nov 11 23:41:48 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13632; Wed, 11 Nov 92 23:41:50 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13627; Wed, 11 Nov 92 23:41:48 -0500
Received: from [192.47.241.1] by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA09071; Wed, 11 Nov 92 23:48:00 -0500
	for info-dylan@cambridge.apple.com
Received: by shpwide.sharp.co.jp (5.65+1.6W/2.8Wb-sharp/1.2) with SMTP
	id AA23209; Thu, 12 Nov 92 13:43:00 JST
Received: by shpcsl.shpcsl.sharp.co.jp (4.1/6.4J.6-csl/m2.5)
	id AA16026; Thu, 12 Nov 92 13:43:27 JST
Received: by trane.shpcsl.sharp.co.jp (4.1/6.4J.6-csl/s1.1)
	id AA18898; Thu, 12 Nov 92 13:43:09 JST
Return-Path: <funato@shpcsl.sharp.co.jp>
Message-Id: <9211120443.AA18898@trane.shpcsl.sharp.co.jp>
To: info-dylan@cambridge.apple.com
Subject: Question (difference between [Function] and [Method])
Return-Receipt-To: funato@shpcsl.sharp.co.jp
Date: Thu, 12 Nov 92 13:43:09 JST
From: Nobuhiko Funato <funato@shpcsl.sharp.co.jp>


Dylan book anonotates one of some categories for each function symbol
description. E.g. [Function], [Method], [Generic Function], [G.F. Method]...

I hope those categories will be introduced in p.16 (Manual Notation),
or in p.19 (Language Overview),

In fact, it is still not clear for me the distinction between [Function]
and [Method]. My understanding is:

  [Generic Function] The specified generic function is bound to that symbol

  [G.F. Method]      A generic function according to the specified method
		     is bound to that symbol

  [Method]           The specified method, so-called lambda closure of which
                     parameters' types are specialized, is bound to that symbol
	             (Method dispatch won't be occured, when the symbol is
                      evaluated)

  [Function]         (How different from [Method] ? How is it defined ?)

Please teach me the difference, though it may be an elementary question.
Thanks.

Nobuhiko FUNATO
SHARP Corporation
2613-1 Ichinomoto, Tenri, Nara 632, JAPAN
funato@shpcsl.sharp.co.jp


P.S.

I vote yes for:

(1) optional thread package i/f standard/recommendation
(2) foreign language i/f standard/recommendation, first of all for C

Although aboves are related to implementation issues, they are the
first step to construct flexible distributed application framework on
Dylan. And it is expected for small computers. (exceeding requirement ?)

From alms Thu Nov 12 16:27:44 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16700; Thu, 12 Nov 92 16:27:48 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16696; Thu, 12 Nov 92 16:27:44 -0500
Message-Id: <9211122127.AA16696@cambridge.apple.com>
Date: Thu, 12 Nov 1992 16:36:18 -0500
To: info-dylan@cambridge.apple.com, funato@shpcsl.sharp.co.jp
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: Question (difference between [Function] and [Method])

At  1:43 PM 11/12/92 +0000, Nobuhiko Funato wrote:
> Dylan book anonotates one of some categories for each function symbol
> description. E.g. [Function], [Method], [Generic Function], [G.F. Method]...
> 
> I hope those categories will be introduced in p.16 (Manual Notation),
> or in p.19 (Language Overview),
> 
> In fact, it is still not clear for me the distinction between [Function]
> and [Method]. My understanding is:
> 
>   [Generic Function] The specified generic function is bound to that symbol
> 
>   [G.F. Method]      A generic function according to the specified method
>                      is bound to that symbol
> 
>   [Method]           The specified method, so-called lambda closure of which
>                      parameters' types are specialized, is bound to that symbol
>                      (Method dispatch won't be occured, when the symbol is
>                       evaluated)
> 
>   [Function]         (How different from [Method] ? How is it defined ?)
> 
> Please teach me the difference, though it may be an elementary question.
> Thanks.

The classifications in the current manual are inconsistent.  They're
scheduled to be cleaned up in the next version of the language design.

That said, here are the categories:

Generic Function       The variable contains a generic function.  The
                       attached description describes the protocol of
                       the generic function as a whole.

GF Method              The variable contains a generic function.  The
                       attached description describes the behavior of
                       a particular method in the generic function (i.e.,
                       the behavior of the generic function when called
                       with a particular set of arguments)

Method                 The variable contains a method.  No generic function
                       dispatch involved.

Function               It is unspecified whether the variable contains a
                       generic function or a method.


As I said, the current manual does not use these consistently.


From info-dylan-request Fri Nov 13 03:04:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA28904; Fri, 13 Nov 92 03:04:07 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA28900; Fri, 13 Nov 92 03:04:04 -0500
Received: from brahma.imag.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11706; Fri, 13 Nov 92 03:10:29 -0500
	for info-dylan@cambridge.apple.com
Received: from imag.imag.fr by brahma.imag.fr with SMTP id AA15382
  (5.65c8/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Fri, 13 Nov 1992 09:05:19 +0100
Received: by imag.imag.fr (5.54/5.17)
	id AA15816; Fri, 13 Nov 92 09:10:49 +0100
Message-Id: <9211130810.AA15816@imag.imag.fr>
Date: Thu, 12 Nov 1992 09:11:56 +0100
To: info-dylan@cambridge.apple.com
From: lafourca@imag.fr (mathieu Lafourcade)
Subject: dylan interpreter

It seems it exists a Dylan interpreter in Scheme on Mac (which one ?,)
where is it possible to get it ?

Is there something similar but in MCL ? (I only use MCL, for now :-)

---
Lafourcade Mathieu
GETA (Groupe d'Etude pour la Traduction Automatique)
BP 53X, 38041 GRENOBLE CEDEX, FRANCE

Lafourca@imag.fr


From info-dylan-request Fri Nov 13 09:59:25 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA11850; Fri, 13 Nov 92 09:59:27 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA11845; Fri, 13 Nov 92 09:59:25 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12231; Fri, 13 Nov 92 10:05:40 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 13 Nov 1992 15:59:50 +0100
Received: by miles.ircam.fr, Fri, 13 Nov 1992 15:59:48 +0100
Date: Fri, 13 Nov 1992 15:59:48 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199211131459.AA00220@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: dispatching on keywords

I would like to see specializers on keywords in Dylan.  Although it
might be hazardous to implement Scott Fahlman's proposal, it seems
that adding specializers to keywords is feasible.

David Moon replied to Scott with a reason why specializing on keywords
might be difficult:

> The problem with specializing on missing arguments is that if different 
> methods have different defaults, it may not be possible to sort the applicable 
> methods into a consistent order.  Certainly that is true in CLOS.  Suppose 
> method m1 specifies type <x> and defaults to an instance of <w>, while method 
> m2 specifies type <y> and defaults to an instance of <v>.  Now suppose the CPL 
> of <v> is (<v> <y> <x> <object>) and the CPL of <w> is (<w> <x> <y> <object>).
> Is m1 or m2 more specific?  This is why CLOS doesn't allow specializing 
> optional and keyword arguments.  Dylan doesn't actually specify the full set 
> of rules for finding the most specific method yet (see p.82 of the Dylan 
> book), so perhaps we could jigger the rules to make your proposal work.  But 
> there are obvious dangers in that.

I don't understand how <x> can inherit from <y> while <y> inherits
from <x>.  This is not a proper class heterarchy.  What am I missing?

David Moon goes on to state why it would be hazardous to adopt Scott's
proposal, but he does not state a reason which would preclude adding
specializers to the current keyword system.  On the contrary, he says
`perhaps we could jigger the rules'.  Well then, here is my attempt to
`jigger the rules'.

When all keyword values are specified, the most specific method is
chosen just like with required parameters.  When a particular keyword
value is not specified, the keyword's specializers (from the list of
applicable methods) are sorted according to specificity and then
lexicographical order.  

In the following quote, David Moon gives another example of why it's
difficult to specialize #key parameters:
      
> The problem is the unclear semantics of allowing specialization of parameters 
> that are optional, i.e. that are defaulted if the caller does not supply a 
> corresponding argument.  Consider this example (using an invented syntax for 
> specializing keyword parameters that is probably not right):
> 
> (define-method f (#key (a: 100 <integer>)) "method 1")
> 
> (define-method f (#key (a: 'foo <symbol>)) "method 2")
> 
> (f a: 15) => "method 1"
> (f a: 'x) => "method 2"
> (f) => what??

My answer is:

(f) => "method 1"

because (class-name <integer>) < (class-name <symbol>) in
lexicographical order.

I must say that I think that this is a rather contrived example and
that user's shouldn't design and use code such as this.  But
nonetheless, there is a formal rule that describes the
most-specific-method. 

I would think that the required parameters should specify the
most-specific-method and that the specializers on the keywords are
useful for type declarations.

I think it is indispensible to allow specializers (type declarations)
on keyword parameters and if people don't like my proposal, I strongly
encourage them to try their hand at jiggering the rules.

-- jonathan bachrach

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

From info-dylan-request Fri Nov 13 10:06:08 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12205; Fri, 13 Nov 92 10:06:09 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12200; Fri, 13 Nov 92 10:06:08 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12296; Fri, 13 Nov 92 10:11:17 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 13 Nov 1992 16:04:40 +0100
Received: by miles.ircam.fr, Fri, 13 Nov 1992 16:04:39 +0100
Date: Fri, 13 Nov 1992 16:04:39 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199211131504.AA00232@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: DYLIM

The FAQ states:

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

Why wouldn't a strategy like CLIM also work for Dylan.  CLIM runs on
all the CL platforms.  Has there been any discussion of DYLANizing CLIM?

-- jonathan bachrach

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


From moon Fri Nov 13 10:58:05 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14483; Fri, 13 Nov 92 10:58:08 -0500
Received: from [90.223.0.23] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14478; Fri, 13 Nov 92 10:58:05 -0500
Message-Id: <9211131558.AA14478@cambridge.apple.com>
Date: Fri, 13 Nov 92 11:00:32 EST
From: moon (David A. Moon)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: dispatching on keywords
Cc: info-dylan@cambridge.apple.com

> Date: Fri, 13 Nov 1992 15:59:48 +0100
> From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
> 
> > .... Now suppose the CPL 
> > of <v> is (<v> <y> <x> <object>) and the CPL of <w> is (<w> <x> <y> <object>).
> > Is m1 or m2 more specific?  This is why CLOS doesn't allow specializing 
> > optional and keyword arguments.  Dylan doesn't actually specify the full set 
> > of rules for finding the most specific method yet (see p.82 of the Dylan 
> > book), so perhaps we could jigger the rules to make your proposal work.  But 
> > there are obvious dangers in that.
> 
> I don't understand how <x> can inherit from <y> while <y> inherits
> from <x>.

I didn't say that <x> inherited from <y> nor vice versa.  Suppose in CLOS we
have

  (defclass <x> (<object>) ())
  (defclass <y> (<object>) ())
  (defclass <v> (<y> <x>) ())
  (defclass <w> (<x> <y>) ())

This gives the CPL's mentioned above.

> When all keyword values are specified, the most specific method is
> chosen just like with required parameters.  When a particular keyword
> value is not specified, the keyword's specializers (from the list of
> applicable methods) are sorted according to specificity and then
> lexicographical order.  

In CLOS, specializers cannot be sorted according to specificity in the absence
of an argument, because specificity is only defined with respect to a particular
object.  See page 794 of Common Lisp: the Language second edition.

The Dylan book does not specify whether Dylan uses the same rules as CLOS or uses
different rules.

> In the following quote, David Moon gives another example of why it's
> difficult to specialize #key parameters:
>       
> > The problem is the unclear semantics of allowing specialization of parameters 
> > that are optional, i.e. that are defaulted if the caller does not supply a 
> > corresponding argument.  Consider this example (using an invented syntax for 
> > specializing keyword parameters that is probably not right):
> > 
> > (define-method f (#key (a: 100 <integer>)) "method 1")
> > 
> > (define-method f (#key (a: 'foo <symbol>)) "method 2")
> > 
> > (f a: 15) => "method 1"
> > (f a: 'x) => "method 2"
> > (f) => what??
> 
> My answer is:
> 
> (f) => "method 1"
> 
> because (class-name <integer>) < (class-name <symbol>) in
> lexicographical order.

There is no class-name function in Dylan, although there is one in CLOS.

By lexicographical order are you saying that the semantics depends on the spelling 
of the variable that is bound to the class?!?  What if there is more than one 
variable bound a given class, for instance in your example suppose someone did

  (define <identifier> <symbol>)

because they like the word "identifier" better.  This is valid Dylan.  Would this 
change which method is applicable?

From kab Fri Nov 13 11:03:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA14642; Fri, 13 Nov 92 11:03:25 -0500
Received: from [90.223.0.20] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA14638; Fri, 13 Nov 92 11:03:22 -0500
Message-Id: <9211131603.AA14638@cambridge.apple.com>
Date: Fri, 13 Nov 92 11:03:17
From: kab (Kim Barrett)
To: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: Re: dispatching on keywords
Cc: info-dylan@cambridge.apple.com

> David Moon replied to Scott with a reason why specializing on keywords
> might be difficult:
> 
> > The problem with specializing on missing arguments is that if different 
> > methods have different defaults, it may not be possible to sort the applicable 
> > methods into a consistent order.  Certainly that is true in CLOS.  Suppose 
> > method m1 specifies type <x> and defaults to an instance of <w>, while method 
> > m2 specifies type <y> and defaults to an instance of <v>.  Now suppose the CPL 
> > of <v> is (<v> <y> <x> <object>) and the CPL of <w> is (<w> <x> <y> <object>).
> > Is m1 or m2 more specific?  This is why CLOS doesn't allow specializing 
> > optional and keyword arguments.  Dylan doesn't actually specify the full set 
> > of rules for finding the most specific method yet (see p.82 of the Dylan 
> > book), so perhaps we could jigger the rules to make your proposal work.  But 
> > there are obvious dangers in that.
> 
> I don't understand how <x> can inherit from <y> while <y> inherits
> from <x>.  This is not a proper class heterarchy.  What am I missing?

There is nothing in Moon's example that says <x> and <y> have any direct 
inheritance relationship at all.  The CPL's he gives could come about from the 
following class definitions (assuming something like CLOS cpl computation rules):

  (define-class <x> (<object>))
  (define-class <y> (<object>))
  (define-class <v> (<y> <x>))
  (define-class <w> (<x> <y>))

> In the following quote, David Moon gives another example of why it's
> difficult to specialize #key parameters:
>       
> > The problem is the unclear semantics of allowing specialization of parameters 
> > that are optional, i.e. that are defaulted if the caller does not supply a 
> > corresponding argument.  Consider this example (using an invented syntax for 
> > specializing keyword parameters that is probably not right):
> > 
> > (define-method f (#key (a: 100 <integer>)) "method 1")
> > 
> > (define-method f (#key (a: 'foo <symbol>)) "method 2")
> > 
> > (f a: 15) => "method 1"
> > (f a: 'x) => "method 2"
> > (f) => what??
> 
> My answer is:
> 
> (f) => "method 1"
> 
> because (class-name <integer>) < (class-name <symbol>) in
> lexicographical order.

I see no class-name in Dylan.  Classes are anonymous objects.  The fact that some 
namable variable is bound to the class has no effect on the class itself.  (Also 
note that the module system allows one to "rename" variables, rendering such an 
ordering to be completely arbitrary anyway).  I can think of other objections, but 
I don't think its worth the time to write them down just now.

From cassels Fri Nov 13 11:37:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15298; Fri, 13 Nov 92 11:37:16 -0500
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15287; Fri, 13 Nov 92 11:37:11 -0500
Message-Id: <9211131637.AA15287@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Fri, 13 Nov 1992 11:39:24 -0400
To: info-dylan@cambridge.apple.com,
        Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: DYLIM

>The FAQ states:
>
>> * 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.
>
>Why wouldn't a strategy like CLIM also work for Dylan.  CLIM runs on
>all the CL platforms.  Has there been any discussion of DYLANizing CLIM?

CLIM is a reasonable solution for the kinds of platforms CL runs on today. 
 That is, workstations with keyboards, mice, and screens, and where the
interface paradigm is a user issuing commands via mouse (2d position) and
keyboard (character) gestures and the machine responding by drawing stuff
on the screen.  We hope that Dylan will be used in a more diverse set of
environments.


From info-dylan-request Fri Nov 13 11:37:28 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15317; Fri, 13 Nov 92 11:37:30 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15312; Fri, 13 Nov 92 11:37:28 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12819; Fri, 13 Nov 92 11:43:56 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA04482; Fri, 13 Nov 92 11:38:11 -0500
Received: by easynet.crl.dec.com; id AA26214; Fri, 13 Nov 92 11:38:09 -0500
Date: Fri, 13 Nov 92 11:38:08 -0500
From: birkholz@crl.dec.com
Message-Id: <9211131638.AA15701@mingus.crl.dec.com>
To: Jonathan.Bachrach@ircam.fr
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Msg of Fri, 13 Nov 1992 15:59:48 +0100 from Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Subject: dispatching on keywords
X-Scheme-Mailer: Edwin 3.75

   Date: Fri, 13 Nov 1992 15:59:48 +0100
   From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>

   I would like to see specializers on keywords in Dylan.  Although it
   might be hazardous to implement Scott Fahlman's proposal, it seems
   that adding specializers to keywords is feasible.

   [...]

   When all keyword values are specified, the most specific method is
   chosen just like with required parameters.  When a particular keyword
   value is not specified, the keyword's specializers (from the list of
   applicable methods) are sorted according to specificity and then
   lexicographical order.  

That doesn't fix the problem.  The problem is really in the assumption
that keyword arguments that aren't provided by the user must be
assigned a default value.  I suggest that: "If it hurts, don't do
that."  It is possible to leave such arguments "unassigned" and leave
it to the programmer to detect and assign a default, if desired,
_after_ method dispatch.  (BTW, this simplifies detecting optional,
including keyword, arguments that were not provided -- not that it was
particularly difficult in Common Lisp.)  Without defaults, keyword
arguments won't change class depending on which method you're
considering.

   In the following quote, David Moon gives another example of why it's
   difficult to specialize #key parameters:

   > The problem is the unclear semantics of allowing specialization
   > of parameters that are optional, i.e. that are defaulted if the
   > caller does not supply a corresponding argument.  Consider this
   > example (using an invented syntax for specializing keyword
   > parameters that is probably not right):
   > 
   > (define-method f (#key (a: 100 <integer>)) "method 1")
   > 
   > (define-method f (#key (a: 'foo <symbol>)) "method 2")
   > 
   > (f a: 15) => "method 1"
   > (f a: 'x) => "method 2"
   > (f) => what??

   My answer is:

   (f) => "method 1"

   because (class-name <integer>) < (class-name <symbol>) in
   lexicographical order.

The manual says that _lists_ of specializers are compared
lexicographically, not individual specializers.  Or are you
introducing an arbitrary disambiguating rule?  I'll presume not, since
the ambiguity hasn't been mentioned in your message, and doesn't fix the
problem that was the subject of your message.

In the more familiar lexicographic sort, you compare the first letters
of two words using a predicate like `char<?'.  If these first two
letters don't tell you which word should come first, i.e. if they're
equal, you loop to compare the next letters.  A lexicographic sort of
lists of specializers would compare two lists by starting with the
first specalizers in the lists, comparing them with a predicate
perhaps called `specializer<?'.

   [...]

Matt Birkholz						Cambridge Research Lab
birkholz@crl.dec.com		<DARWIN><		Digital Equipment Corp.

From info-dylan-request Fri Nov 13 12:15:51 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16002; Fri, 13 Nov 92 12:15:52 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15998; Fri, 13 Nov 92 12:15:51 -0500
Received: from nadia.ircam.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13115; Fri, 13 Nov 92 12:19:39 -0500
	for info-dylan@cambridge.apple.com
Received: from miles.ircam.fr by nadia.ircam.fr, Fri, 13 Nov 1992 18:13:26 +0100
Received: by miles.ircam.fr, Fri, 13 Nov 1992 18:13:25 +0100
Date: Fri, 13 Nov 1992 18:13:25 +0100
From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
Message-Id: <199211131713.AA00346@miles.ircam.fr>
To: info-dylan@cambridge.apple.com
Subject: Re: Re: dispatching on keywords

Thank you all for the clarifications.  I can see that there are some
problems with my proposal.  Unfortunately, I still think it is very
important to allow type declarations for keyword parameters.

Here are some other ideas:

1. Disallow the aforementioned ambiguities in method dispatching.
Make it an error to leave off keyword values (i.e., rely on the
defaults) when it would make the selection of methods impossible.

2. Have different semantics for keyword types.  The type specified
for the keyword would not be a specializer but would be a type
declaration (like in bind).


-- jonathan bachrach

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


From info-dylan-request Fri Nov 13 13:18:59 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17212; Fri, 13 Nov 92 13:19:00 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17208; Fri, 13 Nov 92 13:18:59 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13307; Fri, 13 Nov 92 13:25:27 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA04656; Fri, 13 Nov 92 13:19:56 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA14929; Fri, 13 Nov 1992 13:17:50 -0500
Date: Fri, 13 Nov 1992 13:17:50 -0500
Message-Id: <9211131817.AA14929@lakatos.osf.org>
To: birkholz@crl.dec.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: birkholz@crl.dec.com's message of Fri, 13 Nov 92 11:38:08 -0500 <9211131638.AA15701@mingus.crl.dec.com>
Subject: dispatching on keywords
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

   The problem is really in the assumption that keyword arguments that
   aren't provided by the user must be assigned a default value.  I
   suggest that: "If it hurts, don't do that."  It is possible to
   leave such arguments "unassigned" and leave it to the programmer to
   detect and assign a default, if desired, _after_ method dispatch.

Agreed.  Yet another role for #none (or #nothing).  For that matter,
this gives the programmer a way of explicitly saying "I know that
there is a keyword K, but I do not want to provide a value for it",
not to be confused with "...and I give it the value #f":

		K: #none

	-s

From info-dylan-request Fri Nov 13 13:27:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17308; Fri, 13 Nov 92 13:27:15 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17304; Fri, 13 Nov 92 13:27:14 -0500
Received: from corton.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13381; Fri, 13 Nov 92 13:33:08 -0500
	for info-dylan@cambridge.apple.com
Received: from ilog.UUCP by corton.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA08774; Fri, 13 Nov 1992 17:52:19 +0100 (MET)
Date: Fri, 13 Nov 92 17:45:03 +0100
Received: from passy.ilog by ilog.ilog.fr, Fri, 13 Nov 92 17:45:03 +0100
From: davis@ilog.ilog.fr (Harley Davis)
Message-Id: <9211131645.AA25253@ilog.ilog.fr>
Received: by passy.ilog (4.1/SMI-4.1)
	id AA13582; Fri, 13 Nov 92 17:45:02 +0100
To: Jonathan.Bachrach@ircam.fr
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Jonathan Bachrach's message of Fri, 13 Nov 1992 15:59:48 +0100 <199211131459.AA00220@miles.ircam.fr>
Subject: dispatching on keywords

I think the idea of lexicographical ordering of class names for
computing method specificity is silly --- especially in a system where
class names are optional and documentary.

However, I think there is something which can be saved from the idea
of dispatching on keywords and optional arguments.  I think it should
be allowed only if the default value is specified in the generic
function definition rather than in the method definition.  This would
not create the sort of ambiguities which Moon and Fahlman mentioned.

My proposal would be that if a default value is specified in a generic
function, it cannot also be specified in one of the gf's methods.  If
any method specifies a default value, the generic function cannot.

Example:

(defgeneric foo (x #optional (y 1))

(defmethod foo (x #optional (y <integer>)) 
  ;; default method
  )

(defmethod foo (x #optional (y <string>)) 
  ;; could be called if y were supplied by the caller
  )

Obviously there are major syntactic problems to be solved.

Also, for the question on ambiguous CPL's:

(defclass <w> (<x> <y>) ...)
(defclass <v> (<y> <x>) ...)

The CPL's for <w> and <v> have <y> and <x> in opposite orders.  It is
not necessary that <y> and <x> be related to each other by
inheritance.

-- Harley Davis

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France


From info-dylan-request Fri Nov 13 13:59:41 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17709; Fri, 13 Nov 92 13:59:42 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17705; Fri, 13 Nov 92 13:59:41 -0500
Received: from helen.oit.itd.umich.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13501; Fri, 13 Nov 92 14:05:58 -0500
	for info-dylan@cambridge.apple.com
Received: from localhost by oit.itd.umich.edu (4.1/1123-1.0(us))
	id AA11427; Fri, 13 Nov 92 13:58:50 EST
Message-Id: <9211131858.AA11427@oit.itd.umich.edu>
To: lafourca@imag.fr (mathieu Lafourcade)
Cc: info-dylan@cambridge.apple.com
Subject: Re: dylan interpreter 
In-Reply-To: Your message of "Thu, 12 Nov 92 09:11:56 +0100."
             <9211130810.AA15816@imag.imag.fr> 
Date: Fri, 13 Nov 92 13:58:49 -0500
From: Kenneth Knight <krk@oit.itd.umich.edu>

Mathieu,
  The closest we can get right now, that I know at least, is Thomas. This
is an implementation, though not a complete one, of Dylan done by DEC. You
will need Scheme to run it, but that is not a problem sinctheir is a Gambit
Scheme for the Mac which you can find at any of the big ftp sites. Thomas
itself can be found at cambridge.apple.com's ftp site I believe.

  ** Ken **
>It seems it exists a Dylan interpreter in Scheme on Mac (which one ?,)
>where is it possible to get it ?
>
>Is there something similar but in MCL ? (I only use MCL, for now :-)
>
>---
>Lafourcade Mathieu
>GETA (Groupe d'Etude pour la Traduction Automatique)
>BP 53X, 38041 GRENOBLE CEDEX, FRANCE
>
>Lafourca@imag.fr
>

From info-dylan-request Fri Nov 13 14:10:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17929; Fri, 13 Nov 92 14:10:23 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17925; Fri, 13 Nov 92 14:10:22 -0500
Received: from relay.tek.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13586; Fri, 13 Nov 92 14:16:42 -0500
	for info-dylan@cambridge.apple.com
Received: by relay.tek.com id <AA29967@relay.tek.com>; Fri, 13 Nov 92 10:43:10 -0800
Received: from goldfish.MITRON.TEK.COM by tektronix.TEK.COM (4.1/8.0)
	id AA11812; Fri, 13 Nov 92 10:43:46 PST
Received: by goldfish.MITRON.TEK.COM (4.1/7.1)
	id AA11013; Fri, 13 Nov 92 10:36:25 PST
Date: Fri, 13 Nov 92 10:36:25 PST
From: patl@goldfish.mitron.tek.com (Patrick Logan)
Message-Id: <9211131836.AA11013@goldfish.MITRON.TEK.COM>
To: macrakis@osf.org
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Stavros Macrakis's message of Fri, 13 Nov 1992 13:17:50 -0500 <9211131817.AA14929@lakatos.osf.org>
Subject: dispatching on keywords

   Date: Fri, 13 Nov 1992 13:17:50 -0500
   Agreed.  Yet another role for #none (or #nothing).  For that matter,
   this gives the programmer a way of explicitly saying "I know that
   there is a keyword K, but I do not want to provide a value for it",
   not to be confused with "...and I give it the value #f":

Doesn't this lead to meta-circular madness? I mean, once there is an
object that is #nothing, then that object is something and will be
used for something, e.g., er, nothing.

The only way to ultimately step out of the problem is to have two
separate values: the data and the meta-data. The data is the value
desired and the meta-data is the separate indicator that indicates the
data is good, bad, missing, etc. It is trouble when one variable's
value is being used for both purposes.
--
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 Nov 13 15:11:29 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19448; Fri, 13 Nov 92 15:11:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19444; Fri, 13 Nov 92 15:11:29 -0500
Received: from RIVERSIDE.SCRC.Symbolics.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13750; Fri, 13 Nov 92 15:17:52 -0500
	for info-dylan@brazil.cambridge.apple.com
Received: from LILIKOI.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via INTERNET with SMTP id 950651; 13 Nov 1992 15:13:09-0500
Date: Fri, 13 Nov 1992 15:09 -0500
From: Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
Subject: dispatching on keywords
To: info-dylan@brazil.cambridge.apple.com, Jonathan.Bachrach@ircam.fr,
        davis@ilog.ilog.fr
In-Reply-To: <9211131645.AA25253@ilog.ilog.fr>
Message-Id: <19921113200945.3.NAHA@LILIKOI.SCRC.Symbolics.COM>

    Date: Fri, 13 Nov 1992 11:45 EST
    From: davis@ilog.ilog.fr (Harley Davis)

    I think the idea of lexicographical ordering of class names for
    computing method specificity is silly --- especially in a system where
    class names are optional and documentary.

    However, I think there is something which can be saved from the idea
    of dispatching on keywords and optional arguments.  I think it should
    be allowed only if the default value is specified in the generic
    function definition rather than in the method definition.  This would
    not create the sort of ambiguities which Moon and Fahlman mentioned.

    My proposal would be that if a default value is specified in a generic
    function, it cannot also be specified in one of the gf's methods.  If
    any method specifies a default value, the generic function cannot.

I think you also need the restriction that if any method specifies a
default for an argument then no method can specialize that argument.
You can't change the arguments after the applicable methods have been
determined.

    Example:

    (defgeneric foo (x #optional (y 1))

    (defmethod foo (x #optional (y <integer>)) 
      ;; default method
      )

    (defmethod foo (x #optional (y <string>)) 
      ;; could be called if y were supplied by the caller
      )

    Obviously there are major syntactic problems to be solved.

... because the syntax for specializing required arguments conflicts
with the syntax for defaulting optional arguments.

I don't understand the motivation for this discussion.  I have not yet
needed such a feature.  I have always been able to employ a trivial
workaround on the rare occasions when what you're arguing for ha scome
up.  (Sorry to be using Lisp syntax here, I don't have a Dylan spec
handy).

(defun foo (x &optional (y integer))
  (foo-1 x y))

(defgeneric foo-1 (x y))

(defmethod foo-1 (x (y integer))
  ...)

(defmethod foo-1 (x (y string))
  ...)

From cassels Fri Nov 13 15:41:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20008; Fri, 13 Nov 92 15:41:33 -0500
Received: from [90.223.0.24] by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20004; Fri, 13 Nov 92 15:41:30 -0500
Message-Id: <9211132041.AA20004@cambridge.apple.com>
Sender: cassels@ministry.cambridge.apple.com
Date: Fri, 13 Nov 1992 15:43:44 -0400
To: info-dylan@brazil.cambridge.apple.com, Jonathan.Bachrach@ircam.fr,
        davis@ilog.ilog.fr,
        Mark Nahabedian <naha@RIVERSIDE.SCRC.Symbolics.COM>
From: Robert A. Cassels <cassels@cambridge.apple.com>
Subject: Re: dispatching on keywords

>... because the syntax for specializing required arguments conflicts
>with the syntax for defaulting optional arguments.

Dylan has no #optional arguments.  Only required and keyword arguments.


From info-dylan-request Sat Nov 14 09:11:24 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA15049; Sat, 14 Nov 92 09:11:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15045; Sat, 14 Nov 92 09:11:24 -0500
Received: from corton.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA15166; Sat, 14 Nov 92 09:17:53 -0500
	for info-dylan@brazil.cambridge.apple.com
Received: from ilog.UUCP by corton.inria.fr (5.65c8d/92.02.29)
	via Fnet-EUnet id AA15766; Sat, 14 Nov 1992 14:36:24 +0100 (MET)
Date: Sat, 14 Nov 92 14:16:42 +0100
Received: from passy.ilog by ilog.ilog.fr, Sat, 14 Nov 92 14:16:43 +0100
From: davis@ilog.ilog.fr (Harley Davis)
Message-Id: <9211141316.AA01059@ilog.ilog.fr>
Received: by passy.ilog (4.1/SMI-4.1)
	id AA14256; Sat, 14 Nov 92 14:16:42 +0100
To: naha@RIVERSIDE.SCRC.Symbolics.COM
Cc: Jonathan.Bachrach@ircam.fr, info-dylan@brazil.cambridge.apple.com
In-Reply-To: Mark Nahabedian's message of Fri, 13 Nov 1992 15:09 -0500 <19921113200945.3.NAHA@LILIKOI.SCRC.Symbolics.COM>
Subject: dispatching on keywords

   I don't understand the motivation for this discussion.  I have not yet
   needed such a feature.  I have always been able to employ a trivial
   workaround on the rare occasions when what you're arguing for ha scome
   up.  (Sorry to be using Lisp syntax here, I don't have a Dylan spec
   handy).

I agree that this feature is not strictly necessary.  However, several
of our users have asked for it, so I've given the question a little
bit of thought.  One advantage of the feature is that you don't have
to document two different interfaces to the same functionality -- one
for calling, and one for extension.  (This hasn't stopped EuLisp from
using your idea for the few functions in the definition which take
optional arguments.)

-- Harley

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France


From info-dylan-request Mon Nov 16 05:19:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08157; Mon, 16 Nov 92 05:19:17 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08153; Mon, 16 Nov 92 05:19:14 -0500
Received: from rascals.Stanford.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17328; Mon, 16 Nov 92 05:26:03 -0500
	for info-dylan@cambridge.apple.com
Received: by rascals.stanford.edu (5.65/inc-1.0)
	id AA03502; Mon, 16 Nov 92 02:20:52 -0800
Date: Mon, 16 Nov 92 02:20:52 -0800
From: mcgrant@rascals.stanford.edu (Michael C. Grant)
Message-Id: <9211161020.AA03502@rascals.stanford.edu>
To: info-dylan@cambridge.apple.com
Subject: halp


Well, I received the manual, I joined the mailing list, I READ
the manual, I downloaded Thomas-1.1,...

...but for the life of me I can't seem to put together a complete class,
because 1) the book does not provide enough examples/explanation, and does
not answer all of my questions; and 2) despite my searching there's not
much example code out there...

So, considering that this is the only place to turn for questions/
comments and such, I shall ask a few:

1) Is there ANY significant example code out there I can look
   at? I don't learn any better than from example...
2) Can the types of variables supplied in #key arguments be
   specialized? If so, what's the syntax? I'd also like to
   see an example with specialization AND a default value.
3) I don't fully understand the communicaton between make and
   initialize... given the class <numeric-vector>, I'd like to
   be able to define a <polynomial> class which accepts the
   following make combinations:

   make <polynomail> var: nvar
   make <polynomial> gain: ngain var: nvar
   make <polynomial> roots: nroots gain: ngain var: nvar
   make <polynomial> coeffs: ncoeffs var: nvar

   where nroots, ncoeffs are of type <numeric-vector>, ngain
   is of type <number>, and var is of type <string> and is always
   optional... and, I'd like to reject all other 
   combinations as errors . What combination of initialize and
   make definitions must I have? Obviously some of these could
   be init-keywords in the class (especially var), and several
   of these different syntaxes could be combined with defaults,
   but again I just need to see something legal.
4) Has anyone addressed the issue of interfacing to other languages?
   I was specifically wondering if I was ever going to be able
   to define some sealed, optimized numeric classes for interfacing
   with LAPACK. This is indeed a BIG issue since I would actually
   depend on some sealed subclass of <vector>, say 
   <homogeneous-c-style-data-vector>, which supported only certain
   data types (like the various <numeric> types), etc.

More on #4: I realize just how tall an order #4 is. I also don't
expect any solutions in the near future. But from what I can tell
Dylan is as close to an ideal object-oriented numerics prototyping
(if not programming) language as anyone could get, ASSUMING

1) This interface to standard C/FORTRAN numerical code exists, and
2) Compilation efficiency can be assured, with compile-time
method resolution and inlining, for example.

and, would be absolutely AMAZING if

3) A C/Algol-like syntax were defined,
4) The C/FORTRAN interface could be preserved in a run-time,
   interpreted environment as well as the compiled environment.

I'm really impressed with how 'complete' Dylan feels from where I 
stand. Of course, without a standalone implementation, none of
us can be sure how successful it can be.

I think it's unnecessary to say that I like Dylan from head to toe,
although perhaps as I continue writing code I'll find things I wish
were different. I'd appreciate any answers to my Four Questions so
that I CAN continue to explore the language.

Thanks a lot,
Michael C. Grant
mcgrant@isl.stanford.edu

From info-dylan-request Mon Nov 16 15:58:36 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA00193; Mon, 16 Nov 92 15:58:39 -0500
Received: from alink-gw.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00189; Mon, 16 Nov 92 15:58:36 -0500
Received: by alink-gw.apple.com (5.65/27-Sep-1991-eef)
	id AA16428; Mon, 16 Nov 92 11:31:56 -0800
	for 
Date: 15 Nov 92 19:17 GMT
From: CONDON.TOM@AppleLink.Apple.COM (Condon, Thomas,PAS)
Subject: I don't get enough mail, ha ha
To: INFO-DYLAN@CAMBRIDGE.APPLE.COM
Message-Id: <721942329.9728667@AppleLink.Apple.COM>

Could you add me to info-dylan?  Thanks.
 
Tom Condon
 

From info-dylan-request Mon Nov 16 16:58:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA01479; Mon, 16 Nov 92 16:58:23 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01475; Mon, 16 Nov 92 16:58:22 -0500
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19068; Mon, 16 Nov 92 17:05:16 -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 AA29940; Mon, 16 Nov 92 16:58:38 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 165647.26258; Mon, 16 Nov 1992 16:56:47 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA19486; Mon, 16 Nov 92 08:59:33 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA05978; Mon, 16 Nov 92 08:59:32 PST
Date: Mon, 16 Nov 92 08:59:32 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211161659.AA05978@eagle.sharebase.com>
To: macrakis@osf.org, patl@goldfish.mitron.tek.com
Subject: Re:  dispatching on keywords
Cc: info-dylan@cambridge.apple.com

From: patl@goldfish.mitron.tek.com (Patrick Logan)
/// Subject: dispatching on keywords
/// 
///    Date: Fri, 13 Nov 1992 13:17:50 -0500
///    Agreed.  Yet another role for #none (or #nothing).  For that matter,
///    this gives the programmer a way of explicitly saying "I know that
///    there is a keyword K, but I do not want to provide a value for it",
///    not to be confused with "...and I give it the value #f":
/// 
/// Doesn't this lead to meta-circular madness? I mean, once there is an
/// object that is #nothing, then that object is something and will be
/// used for something, e.g., er, nothing.

This can be a problem, but I think it can be minimized by leaving "nothing"
values outside the class heterarchy, or at least ensure that <nothing> doesn't
inherit from <object>.

As heretical as that seems, I think it would discourage improper use of
"nothing" values.

/// The only way to ultimately step out of the problem is to have two
/// separate values: the data and the meta-data. The data is the value
/// desired and the meta-data is the separate indicator that indicates the
/// data is good, bad, missing, etc. It is trouble when one variable's
/// value is being used for both purposes.

If we provided _two_ types of "nothing" values, this wouldn't be such a
problem.  One can be used to signal an error and can have slots attached to it
for an error message, irritants, an os error code/etc.  Ergo:

	(open-file "my file")
	==> {some stream that I can't print}

	(open-file "this file should not be open-able (not found)")
	==> {error: file not found ... }

The other can be used for absent arguments, etc.  This gives us one value (a
'top' value) for cases where there is no value because of over-specification,
and another (a 'bottom' value) for cases where there is no value because of
under-specification (as in an uninitialized variable/slot/etc.)

Both of these values (or just the 'bottom' #nothing, if that's all that will be
provided) must exist OUTSIDE the class system to prevent them from being
abused.  Or perhaps create their own little class heterarchy, but don't let
them be considered as inheriting <object> behavior... Or we'll keep doint this
forever.

Nil didn't work for LISP as a bottom value, #f doesn't work for scheme, and
I think Dylan needs to fix this if it's going to bring dynamic programming back
in style.  "If I'm already paying the overhead of type-tags, let me use them
for significant other uses, like error flags...."

	-- Scot

P.S.  Just to try to make this germain to the discussion: not allowing
    specialization on key'ed arguments places severe limits on code
    reusability and maintainability to programmers who use keyword arguments
    _at_all_, since if they _ever_ need to be specialized, _all_ of the
    interfacing code must be changed (ick.)  This is the kind of problem I'd
    like an O-O environment to solve, not to create.

From info-dylan-request Mon Nov 16 18:39:51 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03389; Mon, 16 Nov 92 18:39:53 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03385; Mon, 16 Nov 92 18:39:51 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19335; Mon, 16 Nov 92 18:46:46 -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 AA26773; Mon, 16 Nov 92 17:44:05 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA15343; Mon, 16 Nov 1992 17:41:18 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA25043; Mon, 16 Nov 92 17:41:28 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA02533; Mon, 16 Nov 92 17:41:28 CST
Date: Mon, 16 Nov 92 17:41:28 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211162341.AA02533@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject:  Bravo DYLAN !!



The first thing I noticed about DYLAN was that you were able to clean
up the baggage that Common Lisp and Scheme have been carrying for so
many years.  I am greatful that Apple has taken up the mission of
trying to settle the Lisp vs C++ arguments.  At TI we have been
resigned to the painful process of learning C++ due to the demands of
management.  There is a great deal of misconception by those who "pay
the bills" that substituting C++ for Lisp is like the exchanging of
equivalent hardware.

Especially in the research quarter at TI, many good Lispers have been
forced to "tie one hand behind their backs" and move to C++.   Those
who wouldn't have left for greener pastures.  I am certian that a
language with the goals of DYLAN could put some power back into
programming for those of us who remain.

I would like to offer my help in promoting the language at TI.  I am
sure it could gather many advocates here.  I have a lot of contact
with people working on CAD and OODB prototypes.  If you would like, I
could attempt to establish a beta site for DYLAN.  Unfortuately, we
have only a few Macs.  Most of the software types have SPARC 2's.  It
was suggested that you would do a Unix port.  When you do, please let
me know.


Rob Farrow
Integrated Systems Laboratory
Texas Instruments
P.O. Box 655474, MS 446
Dallas, TX  75265

EMAIL: farrow@hc.ti.com
FACS: (214) 995-6194
PH:   (214) 995-7399



From info-dylan-request Tue Nov 17 02:14:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13964; Tue, 17 Nov 92 02:14:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13960; Tue, 17 Nov 92 02:14:22 -0500
Received: from pamir.inria.fr by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20009; Tue, 17 Nov 92 02:21:17 -0500
	for info-dylan@cambridge.apple.com
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/;
	Relayed; 17 Nov 92 08:14:39+0100
X400-Received: by /PRMD=CNET/ADMD=ATLAS/C=FR/;
	Relayed; 17 Nov 92 08:16:00 GMT
Date: 17 Nov 92 08:16:00 GMT
From: Ranson <ranson@LANNION.cnet.fr>
Message-Id: <m0mrNAK-000011C(a)lamd01>
To: dyer@eagle.sharebase.com, macrakis@osf.org, patl@goldfish.mitron.tek.com
Subject: Re:  dispatching on keywords
Cc: info-dylan@cambridge.apple.com

I'm not sure error values are such a good idea, even in a functional language.
Expanding on your example, consider:

   (read (open-file ...

With error values, read can get a stream argument or an error value, and so
must check at run time.
With non-local exits and conditions, you can assert that open-file returns a
stream, and the compiler will optimize type checking. Or alternatively, you
can write your own open-file-or-return-error-value, which makes conditions more
powerful than error values.

Another common argument against error values is that usually, you don't know
locally what to do about the error. You miss the larger picture, and it's
better to exit to a higher-level function that will have a better idea about
what to do.

I'll spare you the argument about all modern computer languages using except-
ions/conditions :-)

     Daniel.




From info-dylan-request Tue Nov 17 09:13:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24315; Tue, 17 Nov 92 09:13:18 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24310; Tue, 17 Nov 92 09:13:15 -0500
Received: from alpha.Xerox.COM by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20558; Tue, 17 Nov 92 09:20:15 -0500
	for info-dylan@cambridge.apple.com
Received: from fliff.wrc.xerox.com ([13.0.33.96]) by alpha.xerox.com with SMTP id <12099>; Tue, 17 Nov 1992 06:14:46 PST
Received: by fliff.wrc.xerox.com (4.1/SMI-4.1-wrc)
	id AA29098; Tue, 17 Nov 92 09:14:45 EST
Message-Id: <9211171414.AA29098@fliff.wrc.xerox.com>
To: dyer@eagle.sharebase.com (Scot Dyer)
Cc: info-dylan@cambridge.apple.com
Subject: Re: dispatching on keywords 
In-Reply-To: Your message of "Mon, 16 Nov 92 08:59:32 PST."
             <9211161659.AA05978@eagle.sharebase.com> 
Date: 	Tue, 17 Nov 1992 06:14:41 PST
From: Jim Mayer <mayer@wrc.xerox.com>

There is an interesting Ph.D. dissertation that is relevant to the
discussion of error values.  It is by Andrew Black, out of Oxford, and
is titled "Exception Handling: the Case Against."  I don't have it
with me, but it came out sometime in the early 1980s.

The paper looks at, and classifies, a number of different proposed
exception handling mechanisms.  It makes a distinction between
exception handling (anticipated problems) and fault recovery
(unanticipated problems) (my terminology is probably off...), and goes
on to argue that the combination of first class procedures and "oneof"
(tagged union) values covers all of the interesting cases.  It also
attacks the argument that explicit exception handling constructs make
code clearer by showing that the idea of an "exceptional" case is
often ill-defined.

I can't really summarize the paper since it has been quite a few years
since I read it, but it struck me as being well written and well reasoned.

-- 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 Tue Nov 17 10:58:45 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA29679; Tue, 17 Nov 92 10:58:46 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA29675; Tue, 17 Nov 92 10:58:45 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20823; Tue, 17 Nov 92 11:05:11 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA07187; Tue, 17 Nov 92 10:59:16 -0500
Received: by easynet.crl.dec.com; id AA19880; Tue, 17 Nov 92 10:59:07 -0500
Date: 17 Nov 1992 10:48 EST
From: Andrew P. Black  <black@crl.dec.com>
Subject: error values and handling alternative results
To: info-dylan@cambridge.apple.com
Fcc: +Dylan
Message-Id: <722015319/black@isis.crl.dec.com>

 > 
 > There is an interesting Ph.D. dissertation that is relevant to the
 > discussion of error values.  It is by Andrew Black, out of Oxford, and
 > is titled "Exception Handling: the Case Against."  I don't have it
 > with me, but it came out sometime in the early 1980s.
 > 
 > The paper looks at, and classifies, a number of different proposed
 > exception handling mechanisms.  It makes a distinction between
 > exception handling (anticipated problems) and fault recovery
 > (unanticipated problems) (my terminology is probably off...), and goes
 > on to argue that the combination of first class procedures and "oneof"
 > (tagged union) values covers all of the interesting cases. 

A good summary.  I would add that the best proposal I have seen for
integrating "oneof"s with objects and invocation results is the work by
the ANSA project in Cambridge, England.  Basically, in ANSA each
operation on an object can result in one or more named terminations.
So "tail" (of a list) might have two terminations: an anonymous one with
an associated result object of type list, and one named "empty" with no
associated result object.  Dispatching on multiple named results turns
out to be quite analogous to dispatching on multiple named operations.

Reference:

%A Architecture Projects Management Ltd
%T ANSA: An Application Programmer's Introduction to the Architecture
%R TR.017
%I APM Ltd
%D NOV 1991

    Andrew Black
    
P.S.  I don't subscribe to this list, so if you want to respond to me,
please do so directly.

    APB

From info-dylan-request Tue Nov 17 12:17:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA03339; Tue, 17 Nov 92 12:17:17 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA03335; Tue, 17 Nov 92 12:17:15 -0500
Received: from ghost.mimuw.edu.pl by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21112; Tue, 17 Nov 92 12:24:05 -0500
	for info-dylan@cambridge.apple.com
Received: by ghost.mimuw.edu.pl (5.57/Ultrix3.0-C)
	id AA00629; Tue, 17 Nov 92 18:17:19 -0100
Message-Id: <9211171917.AA00629@ghost.mimuw.edu.pl>
To: info-dylan@cambridge.apple.com
Subject: new subscriber
Date: Tue, 17 Nov 92 18:17:17 -0100
From: gregsg@mimuw.edu.pl
X-Mts: smtp

Please add me to the Dylan mailing list.
			Yours sincerely
			Grzegorz Grudzinski
			(gregsg@mimuw.edu.pl)

From info-dylan-request Tue Nov 17 13:20:36 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06212; Tue, 17 Nov 92 13:20:37 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06208; Tue, 17 Nov 92 13:20:36 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21320; Tue, 17 Nov 92 13:27:36 -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 AA29343; Tue, 17 Nov 92 12:24:57 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA21018; Tue, 17 Nov 1992 12:22:03 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA26933; Tue, 17 Nov 92 12:22:16 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA02637; Tue, 17 Nov 92 12:22:15 CST
Date: Tue, 17 Nov 92 12:22:15 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211171822.AA02637@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: Responses to Bravo DYLAN
Cc: farrow@stephanie.hc.ti.com


Fellas,

It was interesting to see all the responses I got to my last message.
But, the comments were not very diverse.  I fear there aren't enough
C++ folks in the audience.  I didn't even get called on my "one and
tied behind their backs" crack (which I expected).

I'm not happy with yet another obscure research dialect.  It is not
too much of a generalization to say that only research hackers even
consider using ML.  There are lots of interesting new software
technology research type languages coming out of DARPA (see DARPA
Software Technology Conference '92) but these aren't REAL options.  

Languages require lots of people, time, and money to be an alternative
to Common Lisp, ADA, Smalltalk, let alone C++.  C++ has a special
place because it proliferated like the gold rush.  The reason it did
was because there were people with money willing to support good
developers to build great compilers and improved support features like
development environments and OODBs (best example: Lucid/SUN/Object
Design).

My greatest elation about DYLAN was that it was being done by Apple.
With these guys teamed with IBM, they may have the clout to get DYLAN
accepted by the C++ advocates who lord over software popular opinion
(ie. those who came from C and mainstream comercial programming).  If
they can get OODL to be considered as valuable to those guys as OOP --
then we can get somewhere in convincing management.  

I expect Lisp people to take to DYLAN like fish to water.  I hope that
eventually the C++ advocates will see that their syntax is overly
complex.  If they can be convinced that building abstractions with
macros is useful and necessary then maybe they will understand the
need to go with the uniformly simpler paren-based style.  In the mean
time, I hope Apple doesn't cripple the language by becoming C syntax
oriented just to appease the unknowing.

Now to respond directly to some questions/comments:

----------------------------------------------------------------------
Sorry, Charlie, as of September, TI Hillcreast is no more.  I know
because I had worked there for the last four years.  Yes it is true
that our group has more Macs than most.  But don't be misled.  Macs
are mostly used by managers and secretaries.  Engineers have either
Apollos or Suns.  In fact, the latest corporate mandate is that we
will not by any more Macs.  Instead we will purchase PCs for the
managers (the equivalent hardware issue again).

It is my strongest hope that the new Apple/IBM RISCs will compete with
SUNs speed so I can get one.

------------------------------------------------------------------
To everyone. Thank you, yes I know about THOMAS.  I have it.  But I
have been burned before by using prototype software.  I think the
three week effort they made is useful and promising.  However, I am
not going to get into a deadline jam because I have an unsupported
language bug.  I will continue to experiment with THOMAS.  It is a
great way to grow knowledge of the language -- which is what it was
intended for.

------------------------------------------------------------------
Dak.  Scheme contains obsolete forms which are maintained for backward
compatability.  Also, Scheme implementations contain Flavor-type
object systems.  Flavors is an obsolete (thank goodness)
object-oriented methodology.

------------------------------------------------------------------
Several people asked about SmallTalk.  It is true that TI has had some
interest in this language of late.  However, convincing management to
use it was painful.  Doug Johnson wrote and interesting report
comparing SmallTalk to Lisp to C++ and finally won the war.  The
report entitiled "On Holy Wars and a Plea for Peace: MMST Lanugage
Selection."  The bottom line was that the project would require ten
times the developers ten times as long to complete the work.

For myself, I have used SmallTalk.  I find it great that they are so
primally object-oriented.  However, they don't support the building of
language abstractions (like macros).  This results in a lot of typing
and less readability. Both of which equate directly to code
maintainability.  Plus, sometimes their brand of OOP doesn't suit the
problem.  I prefer a more flexable methodology. SELF looks
interesting, but I have never tried it.

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


I hope I get mail from C++ folks this time.



Rob Farrow
Integrated Systems Laboratory
Texas Instruments
P.O. Box 655474, MS 446
Dallas, TX  75265

EMAIL: farrow@hc.ti.com
FACS: (214) 995-6194



From info-dylan-request Tue Nov 17 13:49:08 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06865; Tue, 17 Nov 92 13:49:09 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06861; Tue, 17 Nov 92 13:49:08 -0500
Received: from sun2.nsfnet-relay.ac.uk by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21443; Tue, 17 Nov 92 13:56:07 -0500
	for info-dylan@cambridge.apple.com
Via: uk.ac.edinburgh.aiai; Tue, 17 Nov 1992 18:10:23 +0000
Date: Tue, 17 Nov 92 13:31:37 GMT
Message-Id: <18168.9211171331@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>
Subject: Re: Bravo DYLAN !!
To: Rob Farrow <farrow@stephanie.hc.ti.com>, info-dylan@cambridge.apple.com
In-Reply-To: Rob Farrow's message of Mon, 16 Nov 92 17:41:28 CST

> The first thing I noticed about DYLAN was that you were able to clean
> up the baggage that Common Lisp and Scheme have been carrying for so
> many years.

Just what is this baggage that has been cleaned up?

Seriously, it's common for people to have completely different ideas
of what's wrong with CL or Scheme.  So I can't tell just what you're
talking about; and I'd like to know if, for example, the problems
have also been fixed in EuLisp.

-- jeff

From info-dylan-request Tue Nov 17 14:59:30 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07343; Tue, 17 Nov 92 14:59:31 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07339; Tue, 17 Nov 92 14:59:30 -0500
Received: from everest.den.mmc.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21618; Tue, 17 Nov 92 15:06:30 -0500
	for info-dylan@cambridge.apple.com
Received: from orion.den.mmc.com by everest.den.mmc.com (4.1/1.34.a)
	id AA24678; Tue, 17 Nov 92 13:01:11 MST
Received: by orion.den.mmc.com (orion# aliases for this host.mmc.generic.062090)
Date: Tue, 17 Nov 92 12:57:37 MST
From: Robin Kladke (303) 977-9760 <robin@orion.den.mmc.com>
Message-Id: <9211171957.AA09032@orion>
To: farrow@stephanie.hc.ti.com
Subject: Re:  Responses to Bravo DYLAN
Cc: info-dylan@cambridge.apple.com


This isn't from a C++er (yet); sorry!  

I completely agree with what you said regarding Dylan's "real" market in the programming world.  I too am a Lisper being forced by the powers-that-be (usually the government) to move over to C++.  I have found it a near impossible task to convince the people with the bucks that Lisp is an infinitely more productive and expressive environment than C for the AI software development i am involved in.  I really hope that Dylan can win over hard-core C/C++ enthusiasts; if that happens, we Lispers will reap the benefits.  The challenge, however, will be to overcome the prejudice of C people regarding dynamic languages in general and a Lisp-like language in particular.  To do this, it must be proven to them that they will not lose efficiency (though i am not always sure that these claims of efficiency apply to the symbolic computing that we Lispers tend to do...).  This is a very big order, maybe one that will eventually be obviated by faster and bigger computers.  Granted, the IDE!
AL target audience of Dylan is th

Robin Rouch Kladke
Martin Marietta
Denver, CO

From info-dylan-request Tue Nov 17 15:09:11 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07436; Tue, 17 Nov 92 15:09:13 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07432; Tue, 17 Nov 92 15:09:11 -0500
Received: from relay1.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21680; Tue, 17 Nov 92 15:16:11 -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 AA05430; Tue, 17 Nov 92 15:09:58 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 150741.8640; Tue, 17 Nov 1992 15:07:41 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA26058; Tue, 17 Nov 92 09:17:51 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA06525; Tue, 17 Nov 92 09:17:47 PST
Date: Tue, 17 Nov 92 09:17:47 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211171717.AA06525@eagle.sharebase.com>
To: dyer@eagle.sharebase.com, macrakis@osf.org, patl@goldfish.mitron.tek.com,
        ranson@LANNION.cnet.fr
Subject: Re:  dispatching on keywords
Cc: info-dylan@cambridge.apple.com

/// I'm not sure error values are such a good idea, even in a functional
/// language.  Expanding on your example, consider:
/// 
///    (read (open-file ...
/// 
/// With error values, read can get a stream argument or an error value,
/// and so must check at run time.  With non-local exits and conditions,
/// you can assert that open-file returns a stream, and the compiler will
/// optimize type checking. Or alternatively, you can write your own
/// open-file-or-return-error-value, which makes conditions more powerful
/// than error values.

It is correct that un-anticipated exception values will 'cascade' in this kind
of a scheme.  This is handy in that it produces a back-trace which it is
simple to build a browser to view.  For efficiency concerns, I think you're
right.  Some function would be required that would guarantee the type of it's
return value, ergo:

	(read (ensure <stream> (open-file ...

Of course, (curry ensure <stream>) would have to know some way of correcting a
stream error, given only the error value.  This would allow more global error
handling via dispatch on ensure.

It might be more reasonable to have open-file call (ensure <stream> ...)
itself, and provide a lower level hook for people who want to avoid losing
that control.  I would prefer it, though, if open-file did not call ensure,
since this

   (a) leaves me more control.  If I want a version of open-file that calls
       ensure I can code it trivially.
   (b) effectively halves the number of functions that need to be provided in
       the base language.

/// Another common argument against error values is that usually, you don't
/// know locally what to do about the error. You miss the larger picture,
/// and it's better to exit to a higher-level function that will have a
/// better idea about what to do.

This is a good argument.  Sometimes one wants errors handled transparently,
I'll admit to that, but having that be the _only_ way can make life harder
when you just want to define a simple function like

	(define-method file-exists? (file-name)
		(not (error? (open-file file-name))))

PROPOSAL:  If error values are to be included in Dylan, they should be required
to inherit from a special class heterarchy, so that method-dispatch can catch
most cascades, and 'signal' for appropriate correction.  If programmers provide
methods that work with particular errors, then no signal would need to be
made by method-dispatch.  It's probably sheer heresy to suggest that errors
not inherit from <object>, so I would also propose the existance of some base
class like <class-heterarchy-root> from which both <object> and <error> would
inherit.  The name could change, but I think the default class specialization
on a parameter needs to be left at <object> for this scheme to work.

/// I'll spare you the argument about all modern computer languages using
/// except-ions/conditions :-)

Thanks.  I don't want Dylan to turn out like COBOL, FORTRAN (on error),
PL/I or Ada either.  :-)

///      Daniel.

	-- Scot

From info-dylan-request Tue Nov 17 16:57:14 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA08347; Tue, 17 Nov 92 16:57:16 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA08343; Tue, 17 Nov 92 16:57:14 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA21936; Tue, 17 Nov 92 17:04:13 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA01335; Tue, 17 Nov 92 16:56:39 -0500
Received: by easynet.crl.dec.com; id AA28642; Tue, 17 Nov 92 16:56:34 -0500
Date: Tue, 17 Nov 92 16:56:32 -0500
From: birkholz@crl.dec.com
Message-Id: <9211172156.AA19091@mingus.crl.dec.com>
To: dyer@eagle.sharebase.com
Cc: macrakis@osf.org, patl@goldfish.mitron.tek.com, ranson@LANNION.cnet.fr
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Msg of Tue, 17 Nov 92 09:17:47 PST from dyer@eagle.sharebase.com (Scot Dyer)
Subject:  dispatching on keywords
X-Scheme-Mailer: Edwin 3.75

   Date: Tue, 17 Nov 92 09:17:47 PST
   From: dyer@eagle.sharebase.com (Scot Dyer)

   /// I'm not sure error values are such a good idea, even in a functional
   /// language.  Expanding on your example, consider:
   /// 
   ///    (read (open-file ...
   /// 
   /// With error values, read can get a stream argument or an error value,
   /// and so must check at run time.  With non-local exits and conditions,
   /// you can assert that open-file returns a stream, and the compiler will
   /// optimize type checking. Or alternatively, you can write your own
   /// open-file-or-return-error-value, which makes conditions more powerful
   /// than error values.

   It is correct that un-anticipated exception values will 'cascade'
   in this kind of a scheme.  This is handy in that it produces a
   back-trace which it is simple to build a browser to view.

It is _not_ handy in that it produces something that could be _mistaken_
for a backtrace.  Why throw away the stack in order to generate something
that looks like the stack but from which you can't continue?

   /// Another common argument against error values is that usually, you don't
   /// know locally what to do about the error. You miss the larger picture,
   /// and it's better to exit to a higher-level function that will have a
   /// better idea about what to do.

   This is a good argument.  Sometimes one wants errors handled transparently,
   I'll admit to that, but having that be the _only_ way can make life harder
   when you just want to define a simple function like

	   (define-method file-exists? (file-name)
		   (not (error? (open-file file-name))))

This is a situation where the context of an error happens to be
unimportant.  I don't think it justifies throwing away potentially relevant
information (i.e. pop the stack) by default, for errors you weren't
expecting -- errors for which any relevant information may be crucial.  It
_should_ take a few more keystrokes to abandon the error context in this
situation.

Matt Birkholz						Cambridge Research Lab
birkholz@crl.dec.com		<DARWIN><		Digital Equipment Corp.

From info-dylan-request Tue Nov 17 21:08:42 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA13162; Tue, 17 Nov 92 21:08:43 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA13158; Tue, 17 Nov 92 21:08:42 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA22314; Tue, 17 Nov 92 21:15:45 -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 AA00757; Tue, 17 Nov 92 21:10:15 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 210946.21663; Tue, 17 Nov 1992 21:09:46 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA01991; Tue, 17 Nov 92 15:51:18 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA06749; Tue, 17 Nov 92 15:51:16 PST
Date: Tue, 17 Nov 92 15:51:16 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211172351.AA06749@eagle.sharebase.com>
To: birkholz@crl.dec.com, dyer@eagle.sharebase.com
Subject: Re:  dispatching on keywords
Cc: info-dylan@cambridge.apple.com, macrakis@osf.org,
        patl@goldfish.mitron.tek.com, ranson@LANNION.cnet.fr

From: birkholz@crl.dec.com
///    It is correct that un-anticipated exception values will 'cascade' in
///    this kind of a scheme.  This is handy in that it produces a
///    back-trace which it is simple to build a browser to view.
/// 
/// It is _not_ handy in that it produces something that could be
/// _mistaken_ for a backtrace.  Why throw away the stack in order to
/// generate something that looks like the stack but from which you can't
/// continue?

Well, if the stack weren't actually destroyed on exit from a function with an
error value (this is easy enough for a compiler to do)*, the stack can still
exist when and if method-dispatch can find no appropriate method to continue
with.

In my own personal code, I would re-call the function with parameters that
don't create an error, but I don't want to force my style on other people.
This was actually an unexpected issue, but if you read on, I think it can be
resolved with little loss of elegance (and only 1 function and 1 class)

///    This is a good argument.  Sometimes one wants errors handled
///    transparently, I'll admit to that, but having that be the _only_ way
///    can make life harder when you just want to define a simple function
///    like
/// 
/// 	   (define-method file-exists? (file-name)
/// 		   (not (error? (open-file file-name))))
/// 
/// This is a situation where the context of an error happens to be
/// unimportant.  I don't think it justifies throwing away potentially
/// relevant information (i.e. pop the stack) by default, for errors you
/// weren't expecting -- errors for which any relevant information may be
/// crucial.  It _should_ take a few more keystrokes to abandon the error
/// context in this situation.

Yes, and I would assert that this is a goodly number of the cases where one
wants to be able to detect an exceptional condition.  Insisting that non-local
control be used forces programmers to obfuscate such simple constructs in
their code.

Perhaps if a re-start mechanism were availible you would be more ammenable to
this scheme?  I think it would be easy enough to provide one.  Something like
(restart <restartable-error>).  Restartable conditions could inherit from
the abstract class <restartable-error> which provides a slot 'continuation'
that can be called.

	-- Scot

--
* Leaving the stack un-touched if an error occurs is actually _trivial_
  compared to trying to determine what functions have stable return types.

From info-dylan-request Wed Nov 18 10:23:03 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA04931; Wed, 18 Nov 92 10:23:05 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA04925; Wed, 18 Nov 92 10:23:03 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23277; Wed, 18 Nov 92 10:30:07 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA26152; Wed, 18 Nov 92 10:24:40 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA15212; Wed, 18 Nov 1992 10:22:25 -0500
Date: Wed, 18 Nov 1992 10:22:25 -0500
Message-Id: <9211181522.AA15212@lakatos.osf.org>
To: mayer@wrc.xerox.com
Cc: dyer@eagle.sharebase.com, info-dylan@cambridge.apple.com
In-Reply-To: Jim Mayer's message of Tue, 17 Nov 1992 06:14:41 PST <9211171414.AA29098@fliff.wrc.xerox.com>
Subject: dispatching on keywords 
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

    ... an interesting Ph.D. dissertation...by Andrew Black, out of
    Oxford, and is titled "Exception Handling: the Case Against." ...

It appeared as U. of Washington CS Dept. tech report 82-01-02
(although it is an Oxford thesis).  I don't know if it was published
elsewhere.

    The paper looks at, and classifies, a number of different proposed
    exception handling mechanisms.  It...argue[s] that the combination
    of first class procedures and "oneof" (tagged union) values covers
    all of the interesting cases....

Yes.  In the language framework he uses, unboxing the union requires a
case statement which must cover all cases, thus allowing static
checking.  But the language framework is different in many ways from
Dylan's, in particular being as static as possible.

I think it is worthwhile also to quote his criticism of the use of
zero as an error return:

    Assigning 'v' to zero and continuing with the computation is sensible
    in two kinds of situation.  The first occurs when zero is not valid as
    a value.....  This implies that the ... abstraction should have been
    instantiated with some other 'v', say "Natural" [instead of Integer].
    Thus 'v' is really of a union type: it is either a 'v' or it is zero.
    The program fragment represented by '<use v>' will presumably test 'v'
    to see if it is zero before deciding to proceed.  There is nothing new
    or surprising about this use of zero as an "impossible" value: it has
    a history going back to the days of assembly language and Fortran.
    However, the advantages of languages like Pascal and Alphard is that
    one can construct types containing just the values one needs and thus
    obtain clearer code and more checking at compile time.  Using union
    types preserves these benefits at the cost of having to make explicit
    checks and type conversion.  Adding "impossible values" to existing
    types allows those conversions to be avoided, but negates many of the
    benefits of strong typing.  ...

    The second kind of situation in which it is sensible for 'v' to be
    assigned to zero occurs when zero is some sort of default
    value,...

The second case is simply not an error return at all.  But the first
case I think applies equally well to using #f as a non-return or
non-argument.

	-s

From info-dylan-request Wed Nov 18 10:57:59 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA06712; Wed, 18 Nov 92 10:58:00 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA06708; Wed, 18 Nov 92 10:57:59 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA23523; Wed, 18 Nov 92 11:05:07 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA27665; Wed, 18 Nov 92 10:59:50 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA18573; Wed, 18 Nov 1992 10:57:42 -0500
Date: Wed, 18 Nov 1992 10:57:42 -0500
Message-Id: <9211181557.AA18573@lakatos.osf.org>
To: info-dylan@cambridge.apple.com
Subject: #f = #none ?
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

Imagine a function which takes an optional argument which is to be
True, False, or Dont-care.  Presumably if the argument is omitted, the
value should be Dont-care.  How will we encode these values?  We can't
use #f for False, because it also means that the argument isn't there.
We could use #t for true, but we'll have to be careful, because all
boolean functions in Dylan allow any non-#f value to represent
True....

So perhaps we'll need to define a new type which takes values
(singletons) True, False, and #f...  Seems silly, and error-prone.

	-s


From alms Wed Nov 18 11:07:06 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07205; Wed, 18 Nov 92 11:07:09 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07200; Wed, 18 Nov 92 11:07:06 -0500
Message-Id: <9211181607.AA07200@cambridge.apple.com>
Date: Wed, 18 Nov 1992 11:16:31 -0500
To: info-dylan@cambridge.apple.com, Stavros Macrakis <macrakis@osf.org>
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: #f = #none ?

At 10:57 AM 11/18/92 -0500, Stavros Macrakis wrote:
> Imagine a function which takes an optional argument which is to be
> True, False, or Dont-care.  Presumably if the argument is omitted, the
> value should be Dont-care.  How will we encode these values?  We can't
> use #f for False, because it also means that the argument isn't there.
> We could use #t for true, but we'll have to be careful, because all
> boolean functions in Dylan allow any non-#f value to represent
> True....
> 
> So perhaps we'll need to define a new type which takes values
> (singletons) True, False, and #f...  Seems silly, and error-prone.
> 
>         -s

(bind ((no-value (cons #f #f)))
  (define-method true-false-dontcare (#key (arg no-value))
    (select arg id?
      ((#t) "sharp-t was passed")
      ((#f) "sharp-f wass passed")
      ((no-value) "no argument was passed")
      ;otherwise error
      )))


From alms Wed Nov 18 11:13:42 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA07568; Wed, 18 Nov 92 11:14:06 -0500
Received: from alms.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA07547; Wed, 18 Nov 92 11:13:42 -0500
Message-Id: <9211181613.AA07547@cambridge.apple.com>
Date: Wed, 18 Nov 1992 11:23:07 -0500
To: alms@cambridge.apple.com, Stavros Macrakis <macrakis@osf.org>
From: alms@cambridge.apple.com (Andrew LM Shalit)
Subject: Re: #f = #none ?
Cc: info-dylan

At 11:10 AM 11/18/92 -0500, Stavros Macrakis wrote:
>    (bind ((no-value (cons #f #f)))
>      (define-method true-false-dontcare (#key (arg no-value))
>        (select arg id?
>          ((#t) "sharp-t was passed")
>          ((#f) "sharp-f wass passed")
>          ((no-value) "no argument was passed")
>          ;otherwise error
>          )))
> 
> Small problem here: there is no way to explicitly specify a don't care
> value.  Correction: make no-value visible....  Do you like that
> solution?  I don't.

I don't see how you can have it both ways.  Either the don't care value
is an explicit published part of the protocol, or it's not.


From info-dylan-request Wed Nov 18 12:39:12 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA12178; Wed, 18 Nov 92 12:39:14 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA12173; Wed, 18 Nov 92 12:39:12 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24236; Wed, 18 Nov 92 12:46: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 AA11143; Wed, 18 Nov 92 11:43:44 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA09445; Wed, 18 Nov 1992 11:40:42 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA29345; Wed, 18 Nov 92 11:40:59 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA02905; Wed, 18 Nov 92 11:40:58 CST
Date: Wed, 18 Nov 92 11:40:58 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211181740.AA02905@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: clarification



>> ------------------------------------------------------------------
>> Several people asked about SmallTalk.  It is true that TI has had some
>> interest in this language of late.  However, convincing management to
>> use it was painful.  Doug Johnson wrote and interesting report
>> comparing SmallTalk to Lisp to C++ and finally won the war.  The
>> report entitiled "On Holy Wars and a Plea for Peace: MMST Lanugage
>> Selection."  The bottom line was that the project would require ten
>> times the developers ten times as long to complete the work.
>> 

I have gotten several requests for this paper.  But before I send it I
should clarify the the report by Doug Johnson does not make the case
for the 100x productivity loss.  That conclusion was the result of
long (months) decision process.  There was a lot of TI internal data
that went into that claim.  The conclusion also had some situation
dependent criteria.  Most notibly that the team was primarily
engineers (ie not software folks).

Doug's paper was an attempt to levelize the playing field for each of
the potential languages.  It tries to go through the justifications,
both bussiness and technical, for each language without bias.

All I was trying to point out, with my statements above, is the kind
of painful process that was required to NOT use C++.  The conclusion,
whether case dependent or not, was the kind of radical justification
required.  The title of the paper shows the kind of prejudice that
enters into these kinds of decisions.  From some of the responses I
have gotten, I can see that this is the prevalent tone in many
companies.

-- Rob.

From info-dylan-request Wed Nov 18 14:58:20 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA16430; Wed, 18 Nov 92 14:58:22 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA16425; Wed, 18 Nov 92 14:58:20 -0500
Received: from relay2.UU.NET by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24616; Wed, 18 Nov 92 15:05:17 -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 AA10690; Wed, 18 Nov 92 14:59:16 -0500
Received: from blia.UUCP by uunet.uu.net with UUCP/RMAIL
	(queueing-rmail) id 145541.20605; Wed, 18 Nov 1992 14:55:41 EST
Received: from eagle.sharebase.com by sharebase.com (4.1/SMI-4.1)
	id AA15948; Wed, 18 Nov 92 10:14:53 PST
Received: by eagle.sharebase.com (4.1/SMI-4.1)
	id AA07048; Wed, 18 Nov 92 10:14:51 PST
Date: Wed, 18 Nov 92 10:14:51 PST
From: dyer@eagle.sharebase.com (Scot Dyer)
Message-Id: <9211181814.AA07048@eagle.sharebase.com>
To: alms@cambridge.apple.com, macrakis@osf.org
Subject: Re: #f = #none ?
Cc: info-dylan@cambridge.apple.com

Perhaps we should simply use signals to denote when no keyword has been passed?
This is consistant with the rest of Dylan's treatment of 'undefined' values,
slots, etc.  It should be an error to access them, and that error should be
catchable by a defined handler?

Of course, we could also define a proper bottom to avoid the following
nonsense:

From: alms@cambridge.apple.com (Andrew LM Shalit)
/// At 11:10 AM 11/18/92 -0500, Stavros Macrakis wrote:
/// >    (bind ((no-value (cons #f #f)))
/// >      (define-method true-false-dontcare (#key (arg no-value))
/// >        (select arg id?
/// >          ((#t) "sharp-t was passed")
/// >          ((#f) "sharp-f wass passed")
/// >          ((no-value) "no argument was passed")
/// >          ;otherwise error
/// >          )))
/// >
/// > Small problem here: there is no way to explicitly specify a don't care
/// > value.  Correction: make no-value visible....  Do you like that
/// > solution?  I don't.
/// 
/// I don't see how you can have it both ways.  Either the don't care value
/// is an explicit published part of the protocol, or it's not.

I think Mr. Macrakis means that the "don't care" behavior should occur when
no key value is supplied in the function call.  To make the problem plainer:
Let's say I have a keyword argument that I expect booleans on; under the
current specification of Dylan, I have no way of telling whether the function
was called with key: #f or without a key value.

Now if I could set a handler for <unbound-atom> and try to read 'arg,' this
would solve the problem.  Perhaps a special predicate, like argument-supplied?
or maybe the same predicate could be merged with slot-initialized? ?  Of
course, I think this would be simplest if a true bottom value (like #none)
was introduced to the language.  Having to set a handler here would probably
be over-kill.

Of course, as usual, I will state my opinion that if #none is supplied, it
should not be considered an <object>.

	-- Scot

From info-dylan-request Wed Nov 18 15:20:36 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17095; Wed, 18 Nov 92 15:20:37 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17091; Wed, 18 Nov 92 15:20:36 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24807; Wed, 18 Nov 92 15:27:45 -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 AA17438; Wed, 18 Nov 92 14:25:09 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA16876; Wed, 18 Nov 1992 14:22:03 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA29747; Wed, 18 Nov 92 14:22:20 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA02958; Wed, 18 Nov 92 14:22:20 CST
Date: Wed, 18 Nov 92 14:22:20 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211182022.AA02958@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: Doug Johnson "On holy wars ...



> ------------------------------------------------------------------
> Several people asked about SmallTalk.  It is true that TI has had some
> interest in this language of late.  However, convincing management to
> use it was painful.  Doug Johnson wrote and interesting report
> comparing SmallTalk to Lisp to C++ and finally won the war.  The
> report entitiled "On Holy Wars and a Plea for Peace: MMST Lanugage
> Selection." 


I am working on placing the postscript version of this paper in TI
anon. FTP space.  

Stay Tuned.

-- Rob.

From info-dylan-request Wed Nov 18 15:40:07 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17767; Wed, 18 Nov 92 15:40:21 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17754; Wed, 18 Nov 92 15:40:07 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25007; Wed, 18 Nov 92 15:46:49 -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 AA18309; Wed, 18 Nov 92 14:44:09 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA18064; Wed, 18 Nov 1992 14:40:55 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA29864; Wed, 18 Nov 92 14:41:09 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA02975; Wed, 18 Nov 92 14:41:08 CST
Date: Wed, 18 Nov 92 14:41:08 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211182041.AA02975@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: Here it is.


A veritable stampeeeeed of interest.  So here goes.
Doug Johnson's Paper in postscript follows.

-- Rob.

=============================================================================
%!PS-Adobe-2.0
%%Creator: dvips 5.47 Copyright 1986-91 Radical Eye Software
%%Title: language.dvi
%%Pages: 13 1
%%BoundingBox: 0 0 612 792
%%EndComments
%%BeginProcSet: tex.pro
/TeXDict 200 dict def TeXDict begin /N /def load def /B{bind def}N /S /exch
load def /X{S N}B /TR /translate load N /isls false N /vsize 10 N /@rigin{
isls{[0 1 -1 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale
Resolution VResolution vsize neg mul TR matrix currentmatrix dup dup 4 get
round 4 exch put dup dup 5 get round 5 exch put setmatrix}N /@letter{/vsize 10
N}B /@landscape{/isls true N /vsize -1 N}B /@a4{/vsize 10.6929133858 N}B /@a3{
/vsize 15.5531 N}B /@ledger{/vsize 16 N}B /@legal{/vsize 13 N}B /@manualfeed{
statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0 0]N
/FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn begin
/FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X array
/BitMaps X /BuildChar{CharBuilder}N /Encoding IE N end dup{/foo setfont}2
array copy cvx N load 0 nn put /ctr 0 N[}B /df{/sf 1 N /fntrx FMat N df-tail}
B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]N df-tail}B /E{pop nn dup definefont
setfont}B /ch-width{ch-data dup length 5 sub get}B /ch-height{ch-data dup
length 4 sub get}B /ch-xoff{128 ch-data dup length 3 sub get sub}B /ch-yoff{
ch-data dup length 2 sub get 127 sub}B /ch-dx{ch-data dup length 1 sub get}B
/ch-image{ch-data dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0
N /rw 0 N /rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S
dup /base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0
ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice
ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 add]{ch-image}
imagemask restore}B /D{/cc X dup type /stringtype ne{]}if nn /base get cc ctr
put nn /BitMaps get S ctr S sf 1 ne{dup dup length 1 sub dup 2 index S get sf
div put}if put /ctr ctr 1 add N}B /I{cc 1 add D}B /bop{userdict /bop-hook
known{bop-hook}if /SI save N @rigin 0 0 moveto}N /eop{clear SI restore
showpage userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook
known{start-hook}if /VResolution X /Resolution X 1000 div /DVImag X /IE 256
array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for}N /p /show load N
/RMat[1 0 0 -1 0 0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X
/rulex X V}B /V statusdict begin /product where{pop product dup length 7 ge{0
7 getinterval(Display)eq}{pop false}ifelse}{false}ifelse end{{gsave TR -.1 -.1
TR 1 1 scale rulex ruley false RMat{BDot}imagemask grestore}}{{gsave TR -.1
-.1 TR rulex ruley scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /a{
moveto}B /delta 0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{
S p tail}B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B
/j{3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w
}B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p
a}B /bos{/SS save N}B /eos{clear SS restore}B end
%%EndProcSet
TeXDict begin 1000 300 300 @start /Fa 37 125 df<0001C0000001800000018000000180
000003800000030000000300000003000000070000000600000006000000060000FFFFFFC0FFFF
FFC0000C0000000C0000001C000000180000001800000018000000380000003000000030000000
30000000700000006000001A1A7B9620>43 D<1C3C3C3C3C0C1C18387070E0C0060D7D840D>I<
FFC0FFC0FFC00A037D890F>I<70F8F8F0F005057B840D>I<007C00FE0387030306030E030C031C
031C031807380738073807700E700E700E700E601CE01CE018E038E030E070606071C03F801E00
101B7B9A15>48 D<0006000E001C003C007C07FC07B80038007800780070007000F000F000E000
E001E001E001C001C003C003C0038003800780FFF8FFF80F1B7C9A15>I<007C01FE03C707070E
030E031C031C031C073C073807380F380F381E1C3E1FFE0FFE021C001C00387038F070F0E0F1C0
E780FF007C00101B7B9A15>57 D<01FFFF0001FFFF80003E03C0003C01E0003C01E0003C00E000
7C00E0007801E0007801E0007803C000F8078000F00F0000FFFE0000FFFC0001F03E0001E00F00
01E0078001E0078003E0078003C0078003C0078003C0078007C00F0007801E0007803E000F807C
00FFFFF000FFFFC0001B1C7E9B1D>66 D<0007F060003FFCE0007E1FE001F007C003E007C00780
03C00F0003C01F0003801E0001803C0003803C000380780000007800000078000000F8000000F0
000000F0000000F0000000F0000C00F0000C00F0001C0070001800780038007C0070003E00E000
1F83C0000FFF000003FC00001B1C7A9B1E>I<01FFFFF001FFFFF0003E01F0003C00F0003C0060
003C0060007C006000781860007818600078386000F8300000F0700000FFF00000FFF00001F0E0
0001E0600001E0600001E0E1C003E0C18003C0038003C0030003C0070007C0070007800E000780
1E000F807C00FFFFFC00FFFFF8001C1C7E9B1C>69 D<01FFFE0001FFFF80003E03C0003C01E000
3C01E0007C01E0007C01E0007801E0007801E000F801C000F803C000F0038000F0070001F01E00
01FFFC0001FFF00001E0000003E0000003E0000003C0000003C0000007C0000007C00000078000
00078000000F800000FFF00000FFF000001B1C7E9B1C>80 D<001F8C007FFC00F0FC01C07803C0
3803803807803807003007000007800007C00007F80007FF0003FF8001FFC0003FC00007C00003
C00001C00001C03001C03003C0700380700780780F007E1E00FFFC00C7F000161C7D9B17>83
D<1FFFFFC03FFFFFC03E0F87C0380F01C0700F0180600F0180601F0180E01E0180C01E0180C01E
0180003E0000003C0000003C0000003C0000007C000000780000007800000078000000F8000000
F0000000F0000000F0000001F0000001E0000001E0000003E000007FFF00007FFF00001A1C799B
1E>I<FFE3FF8FF8FFE3FF0FF81F007803E01E007801801E007803001F00F803000F00F806000F
01F806000F01F80C000F03780C000F037818000F067838000F067830000F0C7860000F0C786000
0F1878C0000F3878C0000F307980000F607980000F607B00000FC07B00000FC07E00000F807E00
000F807C00000F003C00000F003800000E003800000E00300000251C789B29>87
D<03DC000FFC001E7C001C3C00383C00783800703800707800F07800E07000E07000E0F380E0F3
80E1E300E1E300F7E6007FFE003C7C0011127B9115>97 D<3F007F000F000F000E000E000E001E
001C001C001C003FE03FF03E703C307838703870387078F070E070E070E0F0E0E0E1E0E1C0F780
7F003E000D1D7B9C13>I<01F007F80F3C1C3C387C783870007000F000E000E000E000E000E018
E03870F07FE01F800E127B9113>I<001F80003F80000780000780000700000700000F00000F00
000E00000E00001E0003DE000FFC001E7C001C3C00383C00783800703800707800F07800E07000
E07000E0F380E0F380E1E300E1E300F7E6007FFE003C7C00111D7B9C15>I<03F007F81F383C18
3818781870787FF0FF80E000E000E000E000E018E03870F03FE01F800D127B9113>I<0003E000
0FE0000FF0001DF0001CE0001C00003C0000380000380000380000380003FF8007FF8000700000
700000700000F00000E00000E00000E00000E00001E00001C00001C00001C00001C00003C00003
8000038000038000038000070000F70000F70000FE0000FC00007800001425819C0D>I<007B80
01FF8003CF800387800707800F07000E07000E0F001E0F001C0E001C0E001C1E001C1E001C3C00
1C3C001EFC000FFC0007B800003800007800007800F07000F0F000F1E000FFC0007F0000111A7E
9113>I<0FC0001FC00003C00003C0000380000380000780000780000700000700000F00000FFC
000FFE000FCE001F0E001E0E001E0E001C0E003C1E003C1C00381C00383C007838E07838E07078
C07071C0F07B80F03F00E03E00131D7D9C15>I<01C001E001E001C00000000000000000000000
001F003F0077806380E780C7000F000E000E001E001C001CE03CE038C039C03B803F801E000B1C
7D9B0D>I<000E001E001E001E00000000000000000000000001F003F8073806380E380C380038
007800780070007000F000F000E000E001E001E001C001C003C003C0F380F780FF00FE00F8000F
24819B0D>I<1F803F8007800780070007000F000F000E000E001E001E001C001C003C003C0038
0038007800780070007000F700F700E600E600EE00FC007C00091D7C9C0B>108
D<1E1F87E03F7FDFF077F1FC7067C1F070E7C1F070C781E0700701C0700F03C0F00F03C0E00E03
80E00E0381E01E0781C71E0781C71C0703C61C07038E3C0F03DC3C0F01F8380E01F020127D9122
>I<1E3F003F7F8077F38067C380E78380C783800703800F07800F07000E07000E0F001E0E381E
0E381C1E301C1C703C1EE03C0FC0380F8015127D9117>I<01F007F80F3C1C1C380C780E700E70
1EF01CE01CE01CE03CE038E070E0F071E07FC01F000F127B9115>I<078F800FDFC01DF9C019F0
C039E0E031C0E001C0E003C1E003C1C00381C00381C00783C00783800787800787000FDE000FFC
000EF8000E00001E00001E00001C00001C00003C0000FF8000FF8000131A7F9115>I<1E3E3F7F
77E767C7E78FC78F070F0F000F000E000E001E001E001C001C003C003C00380010127D9112>
114 D<03F007F80F3C0E3C1E7C1E381F001FE00FF00FF000F82078F070F070F0F0E1E07FC03F80
0E127D9111>I<01C001C001C003C003C0038003800780FFE0FFE007000F000F000E000E001E00
1E001C001C003C703C70386038E039C03F801F000C1A7D990E>I<1F03803F8380738380638780
E38780C78700070700070F000F0F000E0E000E0E000E1E701E1E701C1C601E3C600E7CC00FFFC0
07CF8014127D9116>I<1F073F8773876383E383C783070307070F060E060E060E0E1E0C1E1C0E
180E380FF007E010127D9113>I<1F01C3803F81C3807381C3806383C180E3838180C783818007
038180070783800F0703000E0703000E0703000E0707000E0F06000E0F0E000E1F0C000F3F1C00
07FFF80003F3F00019127D911C>I<1F03803F8380738380638780E38700C78700070700070F00
0F0E000E0E000E0E000E1E001E1C001C1C001E3C000E7C000FF80007F800003800007800387000
78F00079E00073C0007F80003E0000111A7D9114>121 D<FFFFFFFFF8FFFFFFFFF825027B8B2A>
124 D E /Fb 39 122 df<7CFEFEFEFEFE7C07077D860D>46 D<00600001E0000FE000FFE000F3
E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003E00003
E00003E00003E00003E00003E00003E00003E00003E0007FFF807FFF80111B7D9A18>49
D<07F8003FFF00787F80F81FC0FC0FC0FC0FE0FC0FE0FC07E07807E0000FE0000FE0000FC0001F
80003F00003E00007C0000F00001E00003C0600780600F00601C00E03FFFC07FFFC0FFFFC0FFFF
C0FFFFC0131B7E9A18>I<07F8001FFF003C3F807C1FC07C0FC07E0FC07C0FC03C1FC0001F8000
3F80007F0003FC0003F800003F00001F80000FC0000FE0000FE0780FE0FC0FE0FC0FE0FC0FE0FC
0FC0F81FC0783F803FFF000FF800131B7E9A18>I<000380000780000F80001F80001F80003F80
007F8000EF8001CF80038F80070F80060F800C0F801C0F80380F80700F80E00F80FFFFF8FFFFF8
000F80000F80000F80000F80000F80000F8001FFF801FFF8151B7F9A18>I<1C03801FFF801FFF
801FFF001FFC001FF8001FC0001800001800001800001BFC001FFF001E1F801C0FC01807C00007
E00007E00007E07807E0F807E0F807E0F807E0F80FC0700FC07C3F803FFE0007F800131B7E9A18
>I<00038000000380000007C0000007C0000007C000000FE000000FE000001FF000001BF00000
1BF0000031F8000031F8000061FC000060FC0000E0FE0000C07E0000C07E0001803F0001FFFF00
03FFFF8003001F8003001F8006000FC006000FC00E000FE00C0007E0FFC07FFEFFC07FFE1F1C7E
9B24>65 D<FFFFF800FFFFFF000FC01F800FC00FC00FC00FC00FC00FE00FC00FE00FC00FE00FC0
0FE00FC00FE00FC00FC00FC01F800FFFFF000FFFFE000FC03F800FC00FC00FC007E00FC007E00F
C007F00FC007F00FC007F00FC007F00FC007F00FC007E00FC00FE00FC01FC0FFFFFF80FFFFFC00
1C1C7E9B22>I<001FF06000FFFCE003FC1FE00FE007E01FC003E01F8001E03F0000E07F0000E0
7F0000E07E000060FE000060FE000000FE000000FE000000FE000000FE000000FE000000FE0000
007E0000607F0000607F0000603F0000E01F8000C01FC001C00FE0078003FC1F0000FFFC00001F
F0001B1C7D9B22>I<FFFFF800FFFFFF000FC01FC00FC007E00FC003F00FC001F80FC001F80FC0
00FC0FC000FC0FC000FC0FC000FE0FC000FE0FC000FE0FC000FE0FC000FE0FC000FE0FC000FE0F
C000FE0FC000FC0FC000FC0FC000FC0FC001F80FC001F80FC003F00FC007E00FC01FC0FFFFFF00
FFFFF8001F1C7E9B25>I<FFFFFF00FFFFFF000FC01F000FC007000FC003000FC003800FC00380
0FC181800FC181800FC181800FC180000FC380000FFF80000FFF80000FC380000FC180000FC180
000FC180600FC180600FC000E00FC000C00FC000C00FC001C00FC001C00FC003C00FC00F80FFFF
FF80FFFFFF801B1C7E9B1F>I<FFFFFFFF07E007E007E007E007E007E007E007E007E007E007E0
07E007E007E007E007E007E007E007E007E007E007E007E007E0FFFFFFFF101C7F9B12>73
D<FFFF00FFFF000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0
000FC0000FC0000FC0000FC0000FC0030FC0030FC0030FC0070FC0070FC0060FC00E0FC01E0FC0
7EFFFFFEFFFFFE181C7E9B1D>76 D<FFFFF800FFFFFE000FC03F800FC01F800FC00FC00FC00FE0
0FC00FE00FC00FE00FC00FE00FC00FE00FC00FE00FC00FC00FC01F800FC03F800FFFFE000FFFF8
000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC000000FC0
0000FFFC0000FFFC00001B1C7E9B21>80 D<003FE00001FFFC0003F07E000FC01F801F800FC01F
800FC03F0007E07F0007F07E0003F07E0003F0FE0003F8FE0003F8FE0003F8FE0003F8FE0003F8
FE0003F8FE0003F8FE0003F87E0003F07E0003F07F0007F03F0F87E03FBFCFE01FB8EFC00FF07F
8003F87E0001FFFC00003FFC0800003E1800003FF800003FF800001FF800001FF000000FF00000
0FE0000007C01D247D9B24>I<07F8601FFFE03E0FE07803E07001E0F000E0F00060F80060F800
00FE0000FFF0007FFE007FFF803FFFC01FFFE007FFE0007FF00007F00001F00001F0C000F0C000
F0E000F0E001E0F001E0FE07C0FFFF80C3FE00141C7D9B1B>83 D<7FFFFFE07FFFFFE0781F81E0
701F80E0601F8060E01F8070C01F8030C01F8030C01F8030C01F8030001F8000001F8000001F80
00001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F
8000001F8000001F8000001F800007FFFE0007FFFE001C1C7E9B21>I<FFFC03FFFFFC03FF0FC0
00300FC000300FC000300FC000300FC000300FC000300FC000300FC000300FC000300FC000300F
C000300FC000300FC000300FC000300FC000300FC000300FC000300FC000300FC000300FC00070
07E0006007E000E003F001C001FC0F80007FFF00000FF800201C7E9B25>I<0FFC003FFF003E1F
803E0FC03E07C01C07C00007C003FFC01FFFC07F87C07F07C0FE07C0FC07C0FC07C0FE0FC07E3F
E03FFBF80FE1F815127F9117>97 D<FF0000FF00001F00001F00001F00001F00001F00001F0000
1F00001F00001F00001F3FC01FFFF01FE1F81F80FC1F007C1F007E1F007E1F007E1F007E1F007E
1F007E1F007E1F007E1F00FC1F80FC1FE1F81CFFF0183FC0171D7F9C1B>I<03FC001FFF003F1F
007E1F007E1F00FC0E00FC0000FC0000FC0000FC0000FC0000FC0000FC00007E01807F03803F87
001FFE0003F80011127E9115>I<000FF0000FF00001F00001F00001F00001F00001F00001F000
01F00001F00001F007F9F01FFFF03F0FF07E03F07E01F0FC01F0FC01F0FC01F0FC01F0FC01F0FC
01F0FC01F0FC01F07C01F07E03F03F0FF01FFFFE07F1FE171D7E9C1B>I<03FC000FFF003F0F80
3E07C07E03C07C03E0FC03E0FFFFE0FFFFE0FC0000FC0000FC00007C00007E00603F00E01FC3C0
0FFF8003FE0013127F9116>I<007F0001FFC003E7C007C7C00FC7C00F83800F80000F80000F80
000F80000F8000FFF800FFF8000F80000F80000F80000F80000F80000F80000F80000F80000F80
000F80000F80000F80000F80000F80007FF8007FF800121D809C0F>I<07F9F01FFFF83E1F787C
0FB87C0F807C0F807C0F807C0F807C0F803E1F003FFE0037F8007000007000007800003FFF803F
FFE01FFFF07FFFF0F801F8F000F8F00078F00078F800F87E03F03FFFE007FF00151B7F9118>I<
FF0000FF00001F00001F00001F00001F00001F00001F00001F00001F00001F00001F1FE01F7FF0
1FF1F81FC0F81F80F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F00F8
1F00F8FFE7FFFFE7FF181D7F9C1B>I<3E007F007F007F007F007F003E00000000000000000000
00FF00FF001F001F001F001F001F001F001F001F001F001F001F001F001F001F00FFE0FFE00B1E
7F9D0E>I<FF0000FF00001F00001F00001F00001F00001F00001F00001F00001F00001F00001F
0FF81F0FF81F03801F0F001F1E001F3C001F78001FF8001FFC001FFE001F3E001F1F001F1F801F
0F801F07C01F03E0FFC7FCFFC7FC161D7F9C19>107 D<FF00FF001F001F001F001F001F001F00
1F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F001F00FF
E0FFE00B1D7F9C0E>I<FF1FE0FF00FF7FF3FF801FF1FF8FC01FC0FE07C01F80FC07C01F00F807
C01F00F807C01F00F807C01F00F807C01F00F807C01F00F807C01F00F807C01F00F807C01F00F8
07C01F00F807C01F00F807C0FFE7FF3FF8FFE7FF3FF825127F9128>I<FF1FE0FF7FF01FF1F81F
C0F81F80F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F00F8FF
E7FFFFE7FF18127F911B>I<01FC000FFF801F07C03E03E07C01F07C01F0FC01F8FC01F8FC01F8
FC01F8FC01F8FC01F87C01F07C01F03E03E01F07C00FFF8001FC0015127F9118>I<FF3FC0FFFF
F01FE3F81F80FC1F00FC1F00FE1F007E1F007E1F007E1F007E1F007E1F007E1F00FE1F00FC1F81
FC1FE3F81FFFF01F3FC01F00001F00001F00001F00001F00001F0000FFE000FFE000171A7F911B
>I<FE3E00FEFF801EEF801FCF801F8F801F87001F00001F00001F00001F00001F00001F00001F
00001F00001F00001F0000FFF000FFF00011127F9114>114 D<1FF87FF87078E018E018F000FF
80FFF07FF83FF80FFC007CC03CE01CE01CF878FFF8CFE00E127E9113>I<030003000300070007
000F000F003F00FFFCFFFC1F001F001F001F001F001F001F001F001F001F0C1F0C1F0C1F0C1F9C
0FF803F00E1A7F9913>I<FF07F8FF07F81F00F81F00F81F00F81F00F81F00F81F00F81F00F81F
00F81F00F81F00F81F00F81F01F81F01F81F87F80FFFFF03FCFF18127F911B>I<FFC1FCFFC1FC
1F00601F80E00F80C00FC0C007C18007C18003E30003E30001F60001F60001FE0000FC0000FC00
00780000780000300016127F9119>I<FFC1FCFFC1FC1F00601F80E00F80C00FC0C007C18007C1
8003E30003E30001F60001F60001FE0000FC0000FC000078000078000030000030000060007060
00F8E000C0C000E380007F00003E0000161A7F9119>121 D E /Fc 1 16
df<07E01FF83FFC7FFE7FFEFFFFFFFFFFFFFFFFFFFFFFFF7FFE7FFE3FFC1FF807E010107E9115>
15 D E /Fd 1 59 df<70F8F8F87005057D840C>58 D E /Fe 33 118 df<0000700000000070
000000007000000000700000000070000000007000000000700000000070000000007000000000
7000000000700000000070000000007000000000700000000070000000007000000000700000FF
FFFFFFF8FFFFFFFFF8FFFFFFFFF800007000000000700000000070000000007000000000700000
000070000000007000000000700000000070000000007000000000700000000070000000007000
00000070000000007000000000700000000070000025257D9E2C>43 D<7CFEFEFEFEFE7C07077C
8610>46 D<00180000780001F800FFF800FFF80001F80001F80001F80001F80001F80001F80001
F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001
F80001F80001F80001F80001F80001F8007FFFE07FFFE013207C9F1C>49
D<03FC001FFF803C1FC0700FE0FC07F0FE03F0FE03F8FE03F8FE01F87C01F83803F80003F80003
F00007F00007E0000FC0000F80001F00003E00007C0000F80001F01801C0180380180700180E00
381FFFF03FFFF07FFFF0FFFFF0FFFFF0FFFFF015207D9F1C>I<01FF0007FFC01F07E01E03F03F
03F83F01F83F81F83F01F83F03F80E03F80003F00007F0000FE0001F8001FF0001FF000007E000
03F80001FC0000FC0000FE0000FE7C00FEFE00FEFE00FEFE00FEFE00FCFE01FC7803F83E07F01F
FFE003FF0017207E9F1C>I<000070000000007000000000F800000000F800000000F800000001
FC00000001FC00000003FE00000003FE00000003FE00000006FF000000067F0000000E7F800000
0C3F8000000C3F800000183FC00000181FC00000381FE00000300FE00000300FE00000600FF000
006007F00000E007F80000FFFFF80000FFFFF800018001FC00018001FC00038001FE00030000FE
00030000FE000600007F000600007F00FFE00FFFF8FFE00FFFF825227EA12A>65
D<FFFFFF8000FFFFFFE00007F001F80007F000FC0007F0007E0007F0007E0007F0007F0007F000
7F0007F0007F0007F0007F0007F0007F0007F0007E0007F000FE0007F000FC0007F003F80007FF
FFF00007FFFFF00007F001FC0007F0007E0007F0003F0007F0003F8007F0001F8007F0001FC007
F0001FC007F0001FC007F0001FC007F0001FC007F0001FC007F0003F8007F0003F8007F0007F00
07F001FE00FFFFFFF800FFFFFFC00022227EA128>I<0007FE0180003FFFC38000FF01E78003FC
007F8007F0001F800FE0000F801FC0000F801F800007803F800003807F000003807F000003807F
00000180FE00000180FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000
FE00000000FE00000000FE000000007F000001807F000001807F000001803F800003801F800003
001FC00007000FE0000E0007F0001C0003FC00380000FF01F000003FFFC0000007FF000021227D
A128>I<FFFFE0FFFFE003F80003F80003F80003F80003F80003F80003F80003F80003F80003F8
0003F80003F80003F80003F80003F80003F80003F80003F80003F80003F80003F80003F80003F8
0003F80003F80003F80003F80003F80003F80003F800FFFFE0FFFFE013227FA115>73
D<FFFFE000FFFFE00007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0
000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007F0000007
F0000007F0000007F0001807F0001807F0001807F0001807F0003807F0003807F0007007F00070
07F000F007F001F007F007F0FFFFFFF0FFFFFFF01D227EA122>76 D<0007FC0000003FFF800000
FC07E00003F001F80007E000FC000FC0007E001F80003F001F80003F003F00001F803F00001F80
7F00001FC07E00000FC07E00000FC0FE00000FE0FE00000FE0FE00000FE0FE00000FE0FE00000F
E0FE00000FE0FE00000FE0FE00000FE0FE00000FE07E00000FC07F00001FC07F00001FC03F0000
1F803F80003F801F80003F000FC0007E0007E000FC0003F001F80000FC07E000003FFF80000007
FC000023227DA12A>79 D<03FE0C0FFF9C1F03FC3E00FC7C007C78003CF8001CF8001CF8000CFC
000CFE0000FF0000FFF0007FFF007FFFE03FFFF01FFFF80FFFFC03FFFE007FFE0003FF0000FF00
007F00003FC0001FC0001FC0001FE0001FE0001EF0003EFC007CFF80F8E7FFF0C0FFC018227DA1
1F>83 D<7FFFFFFF807FFFFFFF807E03F80F807803F807807003F803806003F80180E003F801C0
E003F801C0C003F800C0C003F800C0C003F800C0C003F800C00003F800000003F800000003F800
000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F8
00000003F800000003F800000003F800000003F800000003F800000003F800000003F800000003
F800000003F8000003FFFFF80003FFFFF80022227EA127>I<07FE001FFF803F0FC03F07E03F07
F03F03F01E03F00003F00003F001FFF00FFFF03FE3F07F03F07E03F0FE03F0FC03F0FC03F0FC07
F0FE0FF07F1FF83FFDFF0FF0FF18167E951B>97 D<FF800000FF8000001F8000001F8000001F80
00001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8FE0001F
BFFC001FF07E001FC03F001F801F801F801F801F800F801F800FC01F800FC01F800FC01F800FC0
1F800FC01F800FC01F800FC01F800FC01F800F801F801F801F801F001FC03F001FF0FE001E7FF8
001C1FE0001A237EA21F>I<01FF8007FFE01FC3F03F03F03E03F07E03F07C01E0FC0000FC0000
FC0000FC0000FC0000FC0000FC0000FC00007E00007E00003F00303F80701FE1E007FFC001FF00
14167E9519>I<0003FE000003FE0000007E0000007E0000007E0000007E0000007E0000007E00
00007E0000007E0000007E0000007E0000007E0001FE7E0007FFFE001FC3FE003F00FE003E007E
007E007E007C007E00FC007E00FC007E00FC007E00FC007E00FC007E00FC007E00FC007E00FC00
7E007C007E007E007E003E00FE003F01FE001F83FE000FFF7FC001FC7FC01A237EA21F>I<01FE
0007FF801F87E03F03E03E01F07E00F07C00F8FC00F8FC00F8FFFFF8FFFFF8FC0000FC0000FC00
00FC00007E00007E00003F00181F80380FE0F007FFE000FF8015167E951A>I<003F8001FFC003
F7E007E7E007E7E00FC7E00FC3C00FC0000FC0000FC0000FC0000FC0000FC000FFFC00FFFC000F
C0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC0000F
C0000FC0000FC0000FC0000FC0007FFC007FFC0013237FA211>I<01FE1F0007FFFF800F87F780
1F03E7803E01F3003E01F0003E01F0003E01F0003E01F0003E01F0003E01F0001F03E0000F87C0
001FFF80001DFE0000180000001C0000001E0000001FFFE0001FFFFC001FFFFE000FFFFF003FFF
FF007E007F80FC001F80F8000F80F8000F80F8000F80FC001F807E003F003F80FE000FFFF80001
FFC00019217F951C>I<FF800000FF8000001F8000001F8000001F8000001F8000001F8000001F
8000001F8000001F8000001F8000001F8000001F8000001F87F0001F9FFC001FF8FC001FF07E00
1FE07E001FC07E001FC07E001F807E001F807E001F807E001F807E001F807E001F807E001F807E
001F807E001F807E001F807E001F807E001F807E001F807E00FFF1FFC0FFF1FFC01A237EA21F>
I<1F003F803F803F803F803F801F000000000000000000000000000000FF80FF801F801F801F80
1F801F801F801F801F801F801F801F801F801F801F801F801F801F801F80FFF0FFF00C247FA30F
>I<003E007F007F007F007F007F003E000000000000000000000000000003FF03FF003F003F00
3F003F003F003F003F003F003F003F003F003F003F003F003F003F003F003F003F003F003F003F
003F783FFC3FFC7FFC7EFCFC7FF81FC0102E83A311>I<FF800000FF8000001F8000001F800000
1F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F8000001F80FF
801F80FF801F8078001F80F0001F81E0001F83C0001F8700001F8E00001FBE00001FFF00001FFF
00001FFF80001F9FC0001F8FE0001F87E0001F87F0001F83F8001F81F8001F80FC001F80FE00FF
F1FFC0FFF1FFC01A237EA21E>I<FF80FF801F801F801F801F801F801F801F801F801F801F801F
801F801F801F801F801F801F801F801F801F801F801F801F801F801F801F801F801F801F801F80
1F80FFF0FFF00C237FA20F>I<FF87F80FF000FF9FFC3FF8001FBC7E78FC001FF07FE0FE001FE0
3FC07E001FC03F807E001FC03F807E001F803F007E001F803F007E001F803F007E001F803F007E
001F803F007E001F803F007E001F803F007E001F803F007E001F803F007E001F803F007E001F80
3F007E001F803F007E001F803F007E00FFF1FFE3FFC0FFF1FFE3FFC02A167E952F>I<FF87F000
FF9FFC001FF8FC001FF07E001FE07E001FC07E001FC07E001F807E001F807E001F807E001F807E
001F807E001F807E001F807E001F807E001F807E001F807E001F807E001F807E001F807E00FFF1
FFC0FFF1FFC01A167E951F>I<00FE0007FFC00F83E01E00F03E00F87C007C7C007C7C007CFC00
7EFC007EFC007EFC007EFC007EFC007EFC007E7C007C7C007C3E00F81F01F00F83E007FFC000FE
0017167E951C>I<FF8FE000FFBFFC001FF0FE001FC03F001F803F801F801F801F801F801F800F
C01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F800FC01F801F801F801F801F80
3F001FC07F001FF0FE001FFFF8001F9FE0001F8000001F8000001F8000001F8000001F8000001F
8000001F8000001F800000FFF00000FFF000001A207E951F>I<FF1F80FF7FC01F77E01FE7E01F
C7E01FC7E01F83C01F80001F80001F80001F80001F80001F80001F80001F80001F80001F80001F
80001F80001F8000FFF800FFF80013167E9517>114 D<0FFB003FFF007C1F00780700F00300F0
0300F80000FF0000FFF8007FFC007FFE001FFF000FFF80007F80C00F80C00F80E00780F00780F8
0F00FC1F00FFFE00C7F80011167E9516>I<00C00000C00000C00000C00001C00001C00003C000
07C0000FC0001FC000FFFF00FFFF000FC0000FC0000FC0000FC0000FC0000FC0000FC0000FC000
0FC0000FC0000FC0000FC1800FC1800FC1800FC1800FC1800FE38007E70003FF0000FC0011207F
9F16>I<FF83FE00FF83FE001F807E001F807E001F807E001F807E001F807E001F807E001F807E
001F807E001F807E001F807E001F807E001F807E001F807E001F807E001F80FE001F80FE001F81
FE000FC3FE000FFF7FC003FC7FC01A167E951F>I E /Ff 1 14 df<000FF80000007FFF000001
F80FC00003C001E00007000070000E000038001C00001C003800000E0030000006007000000700
60000003006000000300E000000380C000000180C000000180C000000180C000000180C0000001
80C000000180C000000180E0000003806000000300600000030070000007003000000600380000
0E001C00001C000E00003800070000700003C001E00001F80FC000007FFF0000000FF800002121
7E9926>13 D E /Fg 20 122 df<07801FE03870303070386018E01CE01CE01CE01CE01CE01CE0
1CE01CE01CE01CE01CE01C60187038703838701FE007800E187E9713>48
D<03000700FF00FF00070007000700070007000700070007000700070007000700070007000700
070007000700FFF0FFF00C187D9713>I<0FC01FE038707038F038E018E01CE01CE01CE01CE03C
703C707C3FFC1FDC061C001C00387838787078F079E03FC01F000E187E9713>57
D<007F0601FFE607E0FE0F803E1E001E3C001E3C000E78000E780006F00006F00000F00000F000
00F00000F00000F00000F000067800067800063C000E3C000C1E001C0F803807E0F001FFE0007F
80171A7E991C>67 D<FFFF8000FFFFE0000F00F0000F0038000F001C000F000E000F000E000F00
0F000F0007000F0007800F0007800F0007800F0007800F0007800F0007800F0007800F0007800F
0007000F0007000F000F000F000E000F001C000F003C000F00F800FFFFE000FFFF8000191A7F99
1D>I<0FFF0FFF0078007800780078007800780078007800780078007800780078007800780078
00787078F878F878F8F8F9F07FE01F80101A7F9914>74 D<7F80FFE0F1F0F0F0607000F01FF03F
F07870F070E070E073E0F3F1F37FFE3F3C10107E8F13>97 D<07F81FFC3C3C783C7018E000E000
E000E000E000F0007000780C3E1C1FF807E00E107F8F11>99 D<0FDF1FFF387770387038703870
38703838703FE07FC0700070007FF83FFC7FFEF01FE00FE007E007F00F7C3E3FFC0FF010187F8F
13>103 D<FC0000FC00001C00001C00001C00001C00001C00001C00001C00001C00001CF8001F
FC001F1E001E0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E001C0E00FF
9FC0FF9FC0121A7F9915>I<3C003C003C003C00000000000000000000000000FC00FC001C001C
001C001C001C001C001C001C001C001C001C001C00FF80FF80091A80990A>I<FC00FC001C001C
001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C00
1C00FF80FF80091A80990A>108 D<FCF800FFFC001F1E001E0E001C0E001C0E001C0E001C0E00
1C0E001C0E001C0E001C0E001C0E001C0E00FF9FC0FF9FC012107F8F15>110
D<07E01FF8381C700E6006E007E007E007E007E007E007700E700E3C3C1FF807E010107F8F13>
I<FCFC00FFFE001F0F001E07801C03801C03C01C01C01C01C01C01C01C01C01C03C01C03801E07
801F1F001FFE001DF8001C00001C00001C00001C00001C0000FF8000FF800012177F8F15>I<FD
E0FFF01F701E701E001C001C001C001C001C001C001C001C001C00FFC0FFC00C107F8F0F>114
D<3FE07FE0F0E0E060E060F000FF807FC01FE001F0C0F0E070E070F0F0FFE0DF800C107F8F0F>
I<0C000C000C000C001C001C003C00FFC0FFC01C001C001C001C001C001C001C001C601C601C60
1C601EE00FC007800B177F960F>I<FC7E00FC7E001C0E001C0E001C0E001C0E001C0E001C0E00
1C0E001C0E001C0E001C0E001C1E001E3E000FFFC007EFC012107F8F15>I<FF3F80FF3F803C0E
001C0C001C0C000E18000E18000E380007300007300007F00003E00003E00001C00001C00001C0
00018000018000618000F30000C70000FE000078000011177F8F14>121
D E /Fh 59 123 df<00FEF803FFFC0F87DC1E079C1C07001C07001C07001C07001C0700FFFFE0
FFFFE01C07001C07001C07001C07001C07001C07001C07001C07001C07001C0700FF1FE0FF1FE0
1617809615>11 D<00FE0003FF000F87001E07001C07001C00001C00001C00001C0000FFFF00FF
FF001C07001C07001C07001C07001C07001C07001C07001C07001C07001C0700FF1FE0FF1FE013
17809614>I<E1C0F1E0F1E0F1E03060306070E060C0E1C0C1800B0A7F9612>34
D<E0F0F0F030307060E0C0040A7D960A>39 D<038007000F000E001C0038003800380070007000
7000E000E000E000E000E000E000E000E000E000E000E000E0007000700070003800380038001C
000E000F000700038009227E980E>I<E0007000780038001C000E000E000E0007000700070003
80038003800380038003800380038003800380038003800700070007000E000E000E001C003800
78007000E00009227E980E>I<0030000030000030000030000030000030000030000030000030
00003000003000FFFFFCFFFFFC0030000030000030000030000030000030000030000030000030
0000300000300016187E931B>43 D<E0F0F0F030307060E0C0040A7D830A>I<FF80FF80FF8009
0380870C>I<F0F0F0F004047D830A>I<07C01FF03838701C600C600CE00EE00EE00EE00EE00EE0
0EE00EE00EE00E600C701C701C38381FF007C00F157F9412>48 D<03000F00FF00F70007000700
07000700070007000700070007000700070007000700070007007FF07FF00C157E9412>I<0070
00F000F001F003F0077006700E701C70187030707070E070FFFEFFFE007000700070007003FE03
FE0F157F9412>52 D<70307FF07FE07FC060006000600060006FC07FE078F06070003800380038
E038E038E070F0F07FE01F800D157E9412>I<0FE03FF83C7C783C701C701C783C3E783FF00FE0
1FF03DFC787CF01EE01EE00EE00EF01E7C3C3FF80FE00F157F9412>56 D<003800003800003800
007C00007C00007C0000CE0000CE0000CE0001870001870001870003038003038003FF8007FFC0
0601C00601C00C00E00C00E01C00E0FF03FEFF03FE17177F961A>65 D<FFFE00FFFF801C03E01C
01E01C00F01C00F01C00F01C00F01C01E01C03C01FFF801FFFC01C01E01C00F01C00781C00781C
00781C00781C00781C00F01C01E0FFFFC0FFFF0015177F9619>I<00FE3007FF700FC3F01F01F0
3C00F07C0070780070780030F00030F00000F00000F00000F00000F00000F00030780030780030
7C00703C00601F00E00FC3C007FF8000FE0014177E9619>I<FFFF00FFFFC01C03E01C00F01C00
781C00381C003C1C001C1C001E1C001E1C001E1C001E1C001E1C001E1C001E1C001C1C001C1C00
3C1C00781C00F01C01E0FFFFC0FFFF0017177F961B>I<FFFFE0FFFFE01C01E01C00601C00701C
00301C0C301C0C301C0C001C1C001FFC001FFC001C1C001C0C001C0C001C0C001C00001C00001C
00001C00001C0000FFC000FFC00014177F9617>70 D<FF83FEFF83FE1C00701C00701C00701C00
701C00701C00701C00701C00701FFFF01FFFF01C00701C00701C00701C00701C00701C00701C00
701C00701C0070FF83FEFF83FE17177F961A>72 D<FFE0FFE00E000E000E000E000E000E000E00
0E000E000E000E000E000E000E000E000E000E000E000E00FFE0FFE00B177F960D>I<FFC000FF
C0001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00001C00601C
00601C00601C00601C00E01C00C01C01C01C07C0FFFFC0FFFFC013177F9616>76
D<FE0003F8FF0007F81F0007C01F0007C01B800DC01B800DC019C019C019C019C019C019C018E0
31C018E031C018F061C0187061C0187061C01838C1C01838C1C01838C1C0181D81C0181D81C018
0F01C0180F01C0FF0F0FF8FF060FF81D177F9620>I<FC01FEFE01FE1F00301F00301F80301BC0
3019C03019E03018F030187030187830183C30181E30180E30180F301807B01803B01803F01801
F01800F01800F0FF0070FF003017177F961A>I<00FC0003FF000F03C01E01E03C00F038007078
0078700038F0003CF0003CF0003CF0003CF0003CF0003CF0003C7800787800783800703C00F01E
01E00F87C003FF0000FC0016177E961B>I<FFFE00FFFF801C03C01C01E01C00F01C00F01C00F0
1C00F01C00F01C01E01C03C01FFF801FFE001C00001C00001C00001C00001C00001C00001C0000
1C0000FF8000FF800014177F9618>I<0FCC3FFC787CF03CE01CE00CE00CF000F8007F003FF01F
F801FC003C001E000EC00EC00EE00EF01CF83CFFF8CFE00F177E9614>83
D<7FFFF87FFFF8703838603818E0381CC0380CC0380CC0380C0038000038000038000038000038
0000380000380000380000380000380000380000380000380007FFC007FFC016177F9619>I<FF
81FEFF81FE1C00301C00301C00301C00301C00301C00301C00301C00301C00301C00301C00301C
00301C00301C00301C00301C00700E00600F00E00783C003FF8000FE0017177F961A>I<FF07FC
7F80FF07FC7F801C01E00E001C01E00C001C03E00C000E037018000E037018000E037018000E06
38380007063830000706383000070C1C3000038C1C6000038C1C6000039C1E600001D80EC00001
D80EC00001D80EC00001F007C00000F007800000F007800000E0038000006003000021177F9624
>87 D<FF87FCFF87FC0E01C007018007830003870001C60001EE0000EC00007800007800003800
007C0000FE0000CE000187000387800303800601C00E01E01E00E0FF03FEFF03FE17177F961A>
I<306070E060C0E1C0C180C180F1E0F1E0F1E070E00B0A7B9612>92 D<1FC03FF038F810380078
1FF87FF8F838F038E03BE03BF8FB7FFE3F9C100E7F8D12>97 D<FC0000FC00001C00001C00001C
00001C00001C00001C00001C00001DFE001FFF001F0F801C03801C03C01C01C01C01C01C01C01C
01C01C03C01E03801F0F801BFF0018FC001217809614>I<0FF01FF87C387010F000E000E000E0
00E000F00078187C381FF00FE00D0E7F8D10>I<007E00007E00000E00000E00000E00000E0000
0E00000E00000E000FEE003FFE007C3E00700E00F00E00E00E00E00E00E00E00E00E00F00E0070
1E007C3E003FFFC00FCFC012177F9614>I<0FC03FF078707038FFF8FFF8E000E000E000F00070
187C381FF00FE00D0E7F8D10>I<03E007F00F701E701C001C001C001C001C00FF80FF801C001C
001C001C001C001C001C001C001C001C00FF80FF800C1780960B>I<0FBF3FFF38E37070707070
70707038E03FE07F8070007FF03FFC7FFCF03EE00EE00EF01E783C3FF80FE010157F8D12>I<FC
0000FC00001C00001C00001C00001C00001C00001C00001C00001CFC001FFE001F0F001E07001C
07001C07001C07001C07001C07001C07001C07001C0700FF9FE0FF9FE01317809614>I<3C3C3C
3C00000000007C7C1C1C1C1C1C1C1C1C1C1CFFFF081780960A>I<078007800780078000000000
0000000000001F801F8003800380038003800380038003800380038003800380038003800380E3
80E780FF007C00091D82960B>I<FC0000FC00001C00001C00001C00001C00001C00001C00001C
00001C7F801C7F801C7C001CF0001DE0001FC0001FE0001EF0001CF8001C78001C3C001C1E00FF
3FC0FF3FC01217809613>I<FC00FC001C001C001C001C001C001C001C001C001C001C001C001C
001C001C001C001C001C001C001C00FF80FF80091780960A>I<FCFC3F00FFFEFF801F0FC3C01E
0781C01C0701C01C0701C01C0701C01C0701C01C0701C01C0701C01C0701C01C0701C0FF9FE7F8
FF9FE7F81D0E808D1E>I<FCFC00FFFE001F0F001E07001C07001C07001C07001C07001C07001C
07001C07001C0700FF9FE0FF9FE0130E808D14>I<07C01FF03838701C600CE00EE00EE00EE00E
E00E701C38381FF007C00F0E7F8D12>I<FDFE00FFFF001F0F801C07801C03C01C01C01C01C01C
01C01C01C01C03C01E07801F0F801FFF001CFC001C00001C00001C00001C0000FF8000FF800012
14808D14>I<0FC6003FF6007C3E00781E00F00E00E00E00E00E00E00E00E00E00F00E00781E00
7C7E003FFE000FCE00000E00000E00000E00000E00007FC0007FC012147F8D13>I<FDF0FFF81F
381E101E001C001C001C001C001C001C001C00FF80FF800D0E808D0E>I<3FC07FC0F1C0E0C0F0
00FF007FC03FE003E0C0E0E0E0F1E0FFC0DF800B0E7F8D0E>I<180018001800180038007800FF
80FF8038003800380038003800380038C038C038C03DC03F801F000A147F930E>I<FC3F00FC3F
001C07001C07001C07001C07001C07001C07001C07001C07001C0F001E1F001FFFE007E7E0130E
808D14>I<FE3FFE3F381C1C181C180E300E300E700760076003C003C003C00180100E7F8D13>I<
FCFCFCFCFCFC3878703878701C7C601CFC601CCC600ECEC00ECEC00F86C0078780078780070380
030300160E7F8D19>I<FE7FFE7F1C780E7007E007C0038003C007E006F00C703C38FC7FFC7F10
0E7F8D13>I<FE3FFE3F381C1C181C180E300E300E700760076003C003C003C0018001800300E3
00E600FE00780010147F8D13>I<FFF0FFF0E1E0C1E0C3C0C780CF000F181E183C1878307870FF
F0FFF00D0E7F8D10>I E /Fi 10 58 df<1F003F8060C04040C060C060C060C060C060C060C060
C06060C060C03F801F000B107F8F0F>48 D<18007800F800980018001800180018001800180018
00180018001800FF80FF8009107E8F0F>I<3F00FFC0F3E0F0E0F0E000E000E001E001C007800F
001C0038607060FFC0FFC00B107F8F0F>I<1F007F8071C079C071C003C00F800F8001C000E060
E0F0E0F0E0F1C07FC03F000B107F8F0F>I<070007000F001F001B003B0033006300E300FFE0FF
E00300030003001FE01FE00B107F8F0F>I<61807F807F007C00600060006F807FC079E070E000
E0E0E0E0E0E1C0FFC03F000B107F8F0F>I<0F801FC039C071C06000C200FFC0FFC0E0E0C060C0
60C06060E071C03FC01F000B107F8F0F>I<60007FE07FE0C0E0C1C00380070006000E000E000C
001C001C001C001C001C001C000B117E900F>I<1F003F8071C060C070C07DC03F803F807FC0E3
E0C0E0C060C060F1E07FC01F000B107F8F0F>I<1F007F8071C0E0C0C060C060C060E0E07FE07F
E0086000C071C073807F803E000B107F8F0F>I E /Fj 10 58 df<0FC01FE0387070386018E01C
E01CE01CE01CE01CE01CE01CE01CE01C6018703838701FE00FC00E137F9211>48
D<06001E00FE00EE000E000E000E000E000E000E000E000E000E000E000E000E000E00FFE0FFE0
0B137D9211>I<1F807FC0E1E0E0F0E070E0700070007000E001E003C007800F001E303C307870
FFE0FFE0FFE00C137E9211>I<1FC07FF07078703870380038007800F00FE00FE00078003C001C
E01CE01CE03CF0787FF01FC00E137F9211>I<00E001E001E003E007E00EE01CE018E030E070E0
E0E0FFFCFFFC00E000E000E000E007FC07FC0E137F9211>I<60607FE07FC07E00600060006000
7F807FC071E060F000700070E070E070E0F0F1E07FC03F000C137E9211>I<03F00FF81E383838
70007000E080EFF0FFF8F838F01CE01CE01CE01C701C703C38783FF00FC00E137F9211>I<6000
7FFC7FFC7FFCE038C070C0E001C00180038003000700070006000E000E000E000E000E000E000E
147E9311>I<0FC03FF078F87038703878387E783FF01FC03FF07DF8F0FCF03CE01CE01CF03C78
783FF01FC00E137F9211>I<0FC03FF07870F038E038E01CE01CE01CE03C707C7FFC3FDC041C00
380038707070F07FC03F800E137F9211>I E /Fk 84 125 df<003F1F8001FFFFC003C3F3C007
83E3C00F03E3C00E01C0000E01C0000E01C0000E01C0000E01C0000E01C000FFFFFC00FFFFFC00
0E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0000E01C0
000E01C0000E01C0000E01C0000E01C0007F87FC007F87FC001A1D809C18>11
D<003F0001FF8003C3C00783C00F03C00E03C00E00000E00000E00000E00000E0000FFFFC0FFFF
C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01
C00E01C07F87F87F87F8151D809C17>I<003FC001FFC003C3C00783C00F03C00E01C00E01C00E
01C00E01C00E01C00E01C0FFFFC0FFFFC00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E
01C00E01C00E01C00E01C00E01C00E01C00E01C07FCFF87FCFF8151D809C17>I<003F83F00001
FFDFF80003E1FC3C000781F83C000F01F03C000E01E03C000E00E000000E00E000000E00E00000
0E00E000000E00E00000FFFFFFFC00FFFFFFFC000E00E01C000E00E01C000E00E01C000E00E01C
000E00E01C000E00E01C000E00E01C000E00E01C000E00E01C000E00E01C000E00E01C000E00E0
1C000E00E01C000E00E01C007FC7FCFF807FC7FCFF80211D809C23>I<7070F8F8FCFCFCFC7C7C
0C0C0C0C1C1C181838387070F0F060600E0D7F9C15>34 D<0F8000C03FC001C039E0038070F80F
80707FFF00E07FFE00E0300E00E0301C00E0301800E0303800E0303000E07070007060E00070E0
C00039E1C0003FC380000F8303E000070FF0000E0E78000C1C38001C1C180038381C0030380C00
70380C0060380C00E0380C01C0380C0180381C03801C1807001C3806000E780E000FF00C0003E0
1E217E9E23>37 D<70F8FCFC7C0C0C1C183870F060060D7D9C0C>39 D<01C00380038007000E00
0C001C001800380038007000700070007000E000E000E000E000E000E000E000E000E000E000E0
00E000E000E00070007000700070003800380018001C000C000E0007000380038001C00A2A7D9E
10>I<E0007000700038001C000C000E00060007000700038003800380038001C001C001C001C0
01C001C001C001C001C001C001C001C001C001C003800380038003800700070006000E000C001C
00380070007000E0000A2A7E9E10>I<0006000000060000000600000006000000060000000600
0000060000000600000006000000060000000600000006000000060000FFFFFFE0FFFFFFE00006
000000060000000600000006000000060000000600000006000000060000000600000006000000
06000000060000000600001B1C7E9720>43 D<70F8F8F878181818383070E060050D7D840C>I<
FFE0FFE0FFE00B0380890E>I<70F8F8F87005057D840C>I<00030003000700060006000E000C00
1C0018001800380030003000700060006000E000C000C001C00180038003000300070006000600
0E000C000C001C001800180038003000700060006000E000C000C00010297E9E15>I<07E00FF0
1C38381C781E700E700EF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00FF00F700E70
0E781E381C1C380FF007E0101B7E9A15>I<030007003F00FF00C7000700070007000700070007
0007000700070007000700070007000700070007000700070007000700FFF8FFF80D1B7C9A15>
I<0FE03FF878FC603EF01EF81FF80FF80F700F000F001F001E003E003C007800F001E001C00380
07000E031C0338037006FFFEFFFEFFFE101B7E9A15>I<0FE03FF8387C783E7C1E781E781E001E
003C003C00F807F007E00078003C001E000F000F000F700FF80FF80FF81EF01E787C3FF80FE010
1B7E9A15>I<001C00001C00003C00007C00007C0000DC0001DC00039C00031C00071C000E1C00
0C1C00181C00381C00301C00601C00E01C00FFFFC0FFFFC0001C00001C00001C00001C00001C00
001C0001FFC001FFC0121B7F9A15>I<301C3FFC3FF83FE030003000300030003000300037E03F
F83C3C381E301E000F000F000F000FF00FF00FF00FF01E703E787C3FF80FE0101B7E9A15>I<01
F807FC0F8E1E1E3C1E381E781E78007000F080F7F8FFFCFC1CF81EF80FF00FF00FF00FF00FF00F
700F700F781E381E1E3C0FF807E0101B7E9A15>I<6000007FFF807FFF807FFF80600700C00600
C00E00C01C0000380000300000700000600000E00000C00001C00001C00003C000038000038000
038000078000078000078000078000078000078000078000078000111C7E9B15>I<07E01FF83C
3C381E701E700E700E780E7C1E7F3C3FF81FF00FF01FFC3DFC787E703FF00FE00FE007E007E007
F00E781E3C3C1FF807E0101B7E9A15>I<07E01FF83C38781C781EF00EF00EF00FF00FF00FF00F
F00FF01F781F383F3FFF1FEF010F000E001E781E781C783C787878F03FE01F80101B7E9A15>I<
70F8F8F870000000000000000070F8F8F87005127D910C>I<70F8F8F870000000000000000070
F8F8F878181818383070E060051A7D910C>I<1FE03FF8787CE01EF01EF01EF01E603E007C00F8
01F001E003C00380030003000300030003000300000000000000000007000F800F800F8007000F
1D7E9C14>63 D<00060000000F0000000F0000000F0000001F8000001F8000001F8000003FC000
0033C0000033C0000073E0000061E0000061E00000E1F00000C0F00000C0F00001C0F800018078
0001FFF80003FFFC0003003C0003003C0007003E0006001E0006001E001F001F00FFC0FFF0FFC0
FFF01C1C7F9B1F>65 D<FFFFC0FFFFF00F00F80F003C0F001C0F001E0F001E0F001E0F001E0F00
1C0F003C0F00780FFFF00FFFE00F00F80F003C0F001E0F001E0F000F0F000F0F000F0F000F0F00
0F0F001E0F003E0F007CFFFFF8FFFFC0181C7E9B1D>I<003FC18001FFF18003F07B800FC01F80
1F000F801E0007803C0003807C0003807800038078000180F0000180F0000000F0000000F00000
00F0000000F0000000F0000000F000000078000180780001807C0001803C0003801E0003001F00
07000FC00E0003F03C0001FFF000003FC000191C7E9B1E>I<FFFFC000FFFFF0000F007C000F00
1E000F000F000F0007000F0003800F0003C00F0003C00F0001C00F0001E00F0001E00F0001E00F
0001E00F0001E00F0001E00F0001E00F0001E00F0001C00F0001C00F0003C00F0003800F000780
0F000F000F001E000F007C00FFFFF000FFFFC0001B1C7E9B20>I<FFFFFCFFFFFC0F007C0F001C
0F000C0F000E0F00060F03060F03060F03060F03000F07000FFF000FFF000F07000F03000F0300
0F03030F03030F00030F00060F00060F00060F000E0F001E0F007CFFFFFCFFFFFC181C7E9B1C>
I<FFFFF8FFFFF80F00780F00380F00180F001C0F000C0F000C0F030C0F030C0F03000F03000F07
000FFF000FFF000F07000F03000F03000F03000F03000F00000F00000F00000F00000F00000F00
00FFF800FFF800161C7E9B1B>I<003FC18001FFF18003F07B800FC01F801F000F801E0007803C
0003807C0003807800038078000180F0000180F0000000F0000000F0000000F0000000F0000000
F000FFF0F000FFF078000780780007807C0007803C0007801E0007801F0007800FC00F8003F03F
8001FFFB80003FE1801C1C7E9B21>I<FFF3FFC0FFF3FFC00F003C000F003C000F003C000F003C
000F003C000F003C000F003C000F003C000F003C000F003C000FFFFC000FFFFC000F003C000F00
3C000F003C000F003C000F003C000F003C000F003C000F003C000F003C000F003C000F003C000F
003C00FFF3FFC0FFF3FFC01A1C7E9B1F>I<FFF0FFF00F000F000F000F000F000F000F000F000F
000F000F000F000F000F000F000F000F000F000F000F000F000F000F000F00FFF0FFF00C1C7F9B
0F>I<1FFF1FFF0078007800780078007800780078007800780078007800780078007800780078
007800780078F878F878F878F8F8F1F07FE01F80101C7F9B15>I<FFF07FE0FFF07FE00F003E00
0F003C000F0078000F0070000F00E0000F01C0000F0380000F0700000F0E00000F1E00000F3F00
000F7F80000FFF80000FE7C0000FC3C0000F83E0000F01F0000F00F0000F00F8000F007C000F00
7C000F003E000F001E000F001F00FFF07FF0FFF07FF01C1C7E9B20>I<FFF800FFF8000F00000F
00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F
00000F00180F00180F00180F00180F00380F00300F00700F00F00F01F0FFFFF0FFFFF0151C7E9B
1A>I<FF8000FF80FFC001FF800FC001F8000FC001F8000DE00378000DE00378000DE00378000C
F00678000CF00678000CF00678000C780C78000C780C78000C780C78000C3C1878000C3C187800
0C3C1878000C1E3078000C1E3078000C1E3078000C0F6078000C0F6078000C0F6078000C07C078
000C07C078000C07C078001E03807800FFC387FF80FFC387FF80211C7E9B26>I<FF00FFC0FF80
FFC00FC01E000FC00C000FE00C000DE00C000DF00C000CF80C000CF80C000C7C0C000C3C0C000C
3E0C000C1E0C000C1F0C000C0F8C000C078C000C07CC000C03CC000C03EC000C01FC000C00FC00
0C00FC000C007C000C007C000C003C001E001C00FFC01C00FFC00C001A1C7E9B1F>I<003F8000
01FFF00003E0F80007001C000E000E001C0007003C00078038000380780003C0700001C0F00001
E0F00001E0F00001E0F00001E0F00001E0F00001E0F00001E0F00001E0780003C0780003C03800
03803C0007801E000F000E000E0007803C0003E0F80001FFF000003F80001B1C7E9B20>I<FFFF
80FFFFE00F00F00F00380F003C0F001E0F001E0F001E0F001E0F001E0F001E0F003C0F00380F00
F00FFFE00FFF800F00000F00000F00000F00000F00000F00000F00000F00000F00000F0000FFF0
00FFF000171C7E9B1C>I<003F800001FFF00003E0F80007803C000E000E001C0007003C000780
38000380780003C0780003C0F00001E0F00001E0F00001E0F00001E0F00001E0F00001E0F00001
E0F00001E0780003C0780003C0380003803C1F07801C3F87000E39CE0007B0FC0003F8F80001FF
F000003FE0200000E0200000702000007060000078E000007FC000003FC000001FC000000F001B
247E9B20>I<FFFF0000FFFFE0000F00F0000F0038000F003C000F001E000F001E000F001E000F
001E000F001E000F003C000F0038000F00F0000FFFE0000FFFC0000F03F0000F00F0000F00F800
0F0078000F0078000F0078000F0078000F0078000F0078000F007C300F007E70FFF03FE0FFF00F
C01C1C7E9B1F>I<07F1801FFD803C1F80700780700380E00380E00180E00180F00000F80000FE
00007FE0003FFC001FFE000FFF0000FF80000F800007C00003C00001C0C001C0C001C0E001C0E0
0380F00780FE0F00DFFE00C7F800121C7E9B17>I<7FFFFFC07FFFFFC0780F03C0700F01C0600F
00C0E00F00E0C00F0060C00F0060C00F0060C00F0060000F0000000F0000000F0000000F000000
0F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000
000F0000000F000003FFFC0003FFFC001B1C7F9B1E>I<FFF0FFC0FFF0FFC00F001E000F000C00
0F000C000F000C000F000C000F000C000F000C000F000C000F000C000F000C000F000C000F000C
000F000C000F000C000F000C000F000C000F000C000F000C000F000C000F001C00078018000780
380003C0700001F0F00000FFC000003F80001A1C7E9B1F>I<FFE01FF0FFE01FF01F0007800F00
03000F800700078006000780060007C00E0003C00C0003C00C0001E0180001E0180001E0180000
F0300000F0300000F870000078600000786000007CE000003CC000003CC000001F8000001F8000
001F8000000F0000000F0000000F0000000600001C1C7F9B1F>I<FFE0FFE1FFFFE0FFE1FF1F00
1E007C0F001E00380F003F00300F003F003007803F00600780678060078067806007C06780E003
C0C3C0C003C0C3C0C003C0C3C0C001E1C3E18001E181E18001E181E18000F181E30000F300F300
00F300F30000FB00F700007E007E00007E007E00007E007E00003E007C00003C003C00003C003C
00001C0038000018001800281C7F9B2B>I<7FF0FFC07FF0FFC007C07E0003C0380003E0300001
E0700001F0600000F0C0000079C000007D8000003F0000001F0000001F0000000F0000000F8000
001F8000003BC0000033E0000071E0000061F00000C0F80001C0780001807C0003003C0007001E
000F801F00FFE0FFF0FFE0FFF01C1C7F9B1F>I<FFF00FFCFFF00FFC0FC003C007C0038003C003
0003E0060001F0060000F00C0000F81C0000781800007C3800003C3000001E6000001F6000000F
C000000FC000000780000007800000078000000780000007800000078000000780000007800000
07800000078000007FF800007FF8001E1C809B1F>I<7FFFF07FFFF07E01F07803E07007C07007
C0600F80600F00601F00603E00003E00007C0000F80000F80001F00001F00003E03007C03007C0
300F80300F00701F00703E00603E00E07C01E0F807E0FFFFE0FFFFE0141C7E9B19>I<FEFEC0C0
C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0C0FEFE0729
7C9E0C>I<18183C3C383870706060E0E0C0C0C0C0F8F8FCFCFCFC7C7C38380E0D7B9C15>I<FEFE
06060606060606060606060606060606060606060606060606060606060606060606060606FEFE
0729809E0C>I<183C387060E0C0C0F8FCFC7C38060D7E9C0C>96 D<1FE0003FF8003C3C003C1E
00180E00000E00001E0007FE003FFE007E0E00F80E00F80E00F00E60F00E60F81E607C7E607FFF
C01FC78013127F9115>I<FC0000FC00001C00001C00001C00001C00001C00001C00001C00001C
00001C00001CFE001FFF801F87C01E03E01C01E01C00F01C00F01C00F01C00F01C00F01C00F01C
00F01C01E01E01E01E03C01F87C01BFF8018FE00141D7F9C17>I<07F80FFC3E3C3C3C78187800
F000F000F000F000F000F000780078063C0E3F1C0FF807F00F127F9112>I<001F80001F800003
8000038000038000038000038000038000038000038000038007F3801FFF803E1F807C07807803
80F80380F00380F00380F00380F00380F00380F00380F003807807807C0F803E1F801FFBF007E3
F0141D7F9C17>I<07E01FF83E7C781C781EF01EFFFEFFFEF000F000F000F000780078063C0E3F
1C0FF807F00F127F9112>I<00FC03FE079E071E0F1E0E000E000E000E000E000E00FFE0FFE00E
000E000E000E000E000E000E000E000E000E000E000E000E000E007FE07FE00F1D809C0D>I<07
E7C01FFFC03C3DC0781E00781E00781E00781E00781E00781E003C3C003FF80037E00070000070
00007800003FFC003FFF007FFF807807C0F003C0E001C0E001C0F003C0F807C07C0F801FFE0007
F800121B7F9115>I<FC0000FC00001C00001C00001C00001C00001C00001C00001C00001C0000
1C00001CFE001DFF001F8F801F07801E03801C03801C03801C03801C03801C03801C03801C0380
1C03801C03801C03801C0380FF9FF0FF9FF0141D7F9C17>I<38007C007C007C00380000000000
0000000000000000FC00FC001C001C001C001C001C001C001C001C001C001C001C001C001C001C
00FF80FF80091D7F9C0C>I<01C003E003E003E001C00000000000000000000000000FE00FE000
E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E0F0E0
F1E0F3C0FF807E000B25839C0D>I<FC0000FC00001C00001C00001C00001C00001C00001C0000
1C00001C00001C00001C7FC01C7FC01C3E001C3C001C78001CF0001DE0001FE0001FF0001FF000
1E78001C7C001C3C001C1E001C1E001C0F00FF9FE0FF9FE0131D7F9C16>I<FC00FC001C001C00
1C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C001C
001C001C001C00FF80FF80091D7F9C0C>I<FC7F07F000FDFF9FF8001F87F87C001F03F03C001E
01E01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C001C01C01C00
1C01C01C001C01C01C001C01C01C001C01C01C00FF8FF8FF80FF8FF8FF8021127F9124>I<FCFE
00FDFF001F8F801F07801E03801C03801C03801C03801C03801C03801C03801C03801C03801C03
801C03801C0380FF9FF0FF9FF014127F9117>I<03F0000FFC001E1E00380700780780700380F0
03C0F003C0F003C0F003C0F003C0F003C07003807807803807001E1E000FFC0003F00012127F91
15>I<FCFE00FFFF801F87C01E03E01C01E01C01F01C00F01C00F01C00F01C00F01C00F01C00F0
1C01E01E01E01E03C01F8FC01FFF801CFE001C00001C00001C00001C00001C00001C0000FF8000
FF8000141A7F9117>I<07F1801FF9803F1F803C0F80780780780380F00380F00380F00380F003
80F00380F00380F803807807807C0F803E1F801FFB8007E3800003800003800003800003800003
80000380001FF0001FF0141A7F9116>I<FDF0FFF81F781E781E301C001C001C001C001C001C00
1C001C001C001C001C00FFC0FFC00D127F9110>I<1FB07FF0F0F0E070E030F030F8007FC07FE0
1FF000F8C078C038E038F078F8F0FFF0CFC00D127F9110>I<0C000C000C000C000C001C001C00
3C00FFE0FFE01C001C001C001C001C001C001C001C001C301C301C301C301C301E700FE007C00C
1A7F9910>I<FC1F80FC1F801C03801C03801C03801C03801C03801C03801C03801C03801C0380
1C03801C03801C07801C0F801E1F800FFFF007F3F014127F9117>I<FF0FE0FF0FE01C07801C07
000E06000E06000E0600070C00070C00071C0003980003980003F80001F00001F00000E00000E0
0000E00013127F9116>I<FF3FCFE0FF3FCFE03C0F07801C0F03001C1F03000E1B06000E1B8600
0E1B86000E318E000731CC000731CC000760CC0003E0F80003E0F80003E0F80001C0700001C070
0001C070001B127F911E>I<7F8FF07F8FF00F0F80070F00038E0001DC0001D80000F000007000
00780000F80001DC00038E00030E000707001F0780FF8FF8FF8FF81512809116>I<FF0FE0FF0F
E01C07801C07000E06000E06000E0600070C00070C00071C0003980003980003F80001F00001F0
0000E00000E00000E00000C00000C00000C000F18000F18000C700007E00003C0000131A7F9116
>I<7FFC7FFC783C707860F061E061E063C00780078C0F0C1E0C1E1C3C187818F078FFF8FFF80E
127F9112>I<FFFFFFFFFF80FFFFFFFFFF802902808B2A>124 D E /Fl 33
122 df<000700000F00007F0007FF00FFFF00FFFF00F8FF0000FF0000FF0000FF0000FF0000FF
0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF
0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF0000FF007FFFFE7FFF
FE7FFFFE17277BA622>49 D<00FFC00007FFF8001FFFFE003F03FF007E00FF807F007FC0FF807F
C0FF803FE0FF803FE0FF803FE0FF801FE07F001FE03E003FE000003FE000003FC000003FC00000
7F8000007F800000FF000001FE000001FC000003F8000007E000000FC000001F8000003E00E000
7C00E0007800E000F001C001E001C0038001C007FFFFC00FFFFFC01FFFFFC03FFFFFC07FFFFF80
FFFFFF80FFFFFF80FFFFFF801B277DA622>I<007FC00003FFF00007FFFC000FC1FE001F80FF00
3FC0FF003FE07F803FE07F803FE07F803FE07F803FE07F801FC0FF800F80FF000000FF000001FE
000003FC000007F00000FFC00000FFF8000001FE000000FF0000007F8000007FC000003FC00000
3FE01E003FE07F803FE07F803FE0FFC03FE0FFC03FE0FFC03FE0FFC03FC0FFC07FC07F807F807F
00FF803F81FF001FFFFC0007FFF80000FFC0001B277DA622>I<0000070000000F0000001F0000
003F0000007F000000FF000000FF000001FF000003FF0000077F00000F7F00000E7F00001C7F00
00387F0000707F0000F07F0000E07F0001C07F0003807F0007007F000F007F000E007F001C007F
0038007F0070007F00E0007F00FFFFFFF8FFFFFFF8FFFFFFF80000FF000000FF000000FF000000
FF000000FF000000FF000000FF00007FFFF8007FFFF8007FFFF81D277EA622>I<000003800000
000007C00000000007C0000000000FE0000000000FE0000000000FE0000000001FF0000000001F
F0000000003FF8000000003FF8000000003FF8000000007FFC0000000077FC00000000F7FE0000
0000E3FE00000000E3FE00000001C1FF00000001C1FF00000003C1FF8000000380FF8000000780
FFC0000007007FC0000007007FC000000E007FE000000E003FE000001E003FF000001C001FF000
001FFFFFF000003FFFFFF800003FFFFFF8000078000FFC0000700007FC0000700007FC0000E000
07FE0000E00003FE0001E00003FF0001C00001FF0001C00001FF00FFFE003FFFFEFFFE003FFFFE
FFFE003FFFFE2F297EA834>65 D<FFFFFFFC0000FFFFFFFF8000FFFFFFFFE00003FC001FF00003
FC0007F80003FC0007FC0003FC0003FC0003FC0003FC0003FC0003FE0003FC0001FE0003FC0001
FE0003FC0001FE0003FC0003FE0003FC0003FC0003FC0003FC0003FC0007F80003FC000FF00003
FC001FE00003FC007FC00003FFFFFF000003FFFFFFE00003FC0007F00003FC0003FC0003FC0001
FE0003FC0001FE0003FC0000FF0003FC0000FF0003FC0000FF8003FC0000FF8003FC0000FF8003
FC0000FF8003FC0000FF8003FC0000FF8003FC0000FF0003FC0001FF0003FC0003FE0003FC0007
FE0003FC000FFC00FFFFFFFFF000FFFFFFFFC000FFFFFFFE000029297DA831>I<00007FF80180
0007FFFE0780001FFFFF8F80007FF80FFF8000FF8001FF8003FE00007F8007FC00003F8007F800
001F800FF000000F801FE000000F803FE0000007803FC0000007807FC0000003807FC000000380
7FC000000380FF8000000000FF8000000000FF8000000000FF8000000000FF8000000000FF8000
000000FF8000000000FF8000000000FF8000000000FF8000000000FF80000000007FC000000000
7FC0000003807FC0000003803FC0000003803FE0000003801FE0000007800FF00000070007F800
000F0007FC00001E0003FE00003C0000FF8000F800007FF807F000001FFFFFC0000007FFFF0000
00007FF8000029297CA832>I<FFFFFFF80000FFFFFFFF8000FFFFFFFFE00003FE001FF80003FE
0007FC0003FE0001FE0003FE0000FF0003FE00007F8003FE00003FC003FE00001FC003FE00001F
E003FE00001FE003FE00000FF003FE00000FF003FE00000FF003FE00000FF003FE00000FF803FE
00000FF803FE00000FF803FE00000FF803FE00000FF803FE00000FF803FE00000FF803FE00000F
F803FE00000FF803FE00000FF803FE00000FF003FE00000FF003FE00000FF003FE00001FE003FE
00001FE003FE00001FC003FE00003FC003FE00007F8003FE00007F0003FE0001FE0003FE0003FC
0003FE001FF800FFFFFFFFE000FFFFFFFF8000FFFFFFFC00002D297DA835>I<FFFFFEFFFFFEFF
FFFE01FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001
FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001
FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF0001FF00FFFFFEFFFFFEFFFFFE17
297FA81A>73 D<FFFFFE0000FFFFFE0000FFFFFE000003FE00000003FE00000003FE00000003FE
00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003
FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE00000003FE000000
03FE00000003FE00000003FE0001C003FE0001C003FE0001C003FE0001C003FE0003C003FE0003
8003FE00038003FE00078003FE00078003FE000F8003FE000F8003FE001F8003FE007F8003FE01
FF00FFFFFFFF00FFFFFFFF00FFFFFFFF0022297DA829>76 D<0000FFE000000007FFFC0000003F
C07F8000007F001FC00001FC0007F00003F80003F80007F00001FC000FF00001FE001FE00000FF
001FE00000FF003FC000007F803FC000007F807FC000007FC07F8000003FC07F8000003FC07F80
00003FC0FF8000003FE0FF8000003FE0FF8000003FE0FF8000003FE0FF8000003FE0FF8000003F
E0FF8000003FE0FF8000003FE0FF8000003FE0FF8000003FE07F8000003FC07FC000007FC07FC0
00007FC03FC000007F803FC000007F801FE00000FF001FE00000FF000FF00001FE0007F00001FC
0003F80003F80001FC0007F00000FF001FE000003FC07F8000000FFFFE00000000FFE000002B29
7CA834>79 D<FFFFFFE00000FFFFFFFE0000FFFFFFFF800003FE007FE00003FE000FF00003FE00
07F80003FE0007FC0003FE0003FC0003FE0003FE0003FE0003FE0003FE0003FE0003FE0003FE00
03FE0003FE0003FE0003FE0003FE0003FC0003FE0007F80003FE0007F80003FE001FE00003FE00
7FC00003FFFFFE000003FFFFFC000003FE01FF000003FE007FC00003FE007FE00003FE003FE000
03FE003FF00003FE001FF00003FE001FF00003FE001FF00003FE001FF00003FE001FF00003FE00
1FF00003FE001FF00003FE001FF00003FE001FF00703FE001FF00703FE000FF80703FE000FF80F
FFFFF807FE1EFFFFF801FFFCFFFFF8003FF030297DA834>82 D<00FF806003FFF0E00FFFFFE01F
C0FFE03F001FE03E0007E07E0003E07C0003E0FC0001E0FC0001E0FC0000E0FE0000E0FF0000E0
FF800000FFF80000FFFFC0007FFFF8007FFFFE003FFFFF801FFFFFC00FFFFFC007FFFFE001FFFF
F0003FFFF00003FFF800001FF800000FF8000007F8E00003F8E00001F8E00001F8E00001F8F000
01F8F00001F0F80003F0FC0003E0FF0007E0FFE01FC0FFFFFF80E1FFFE00C03FF8001D297CA826
>I<FFFFF87FFFF807FFF0FFFFF87FFFF807FFF0FFFFF87FFFF807FFF003FE0001FF00001C0003

000000001F00000F80000000000E00000700000044297FA847>87 D<03FFC0000FFFF0001F81FC
003FC0FE003FC07F003FC07F003FC03F803FC03F801F803F8000003F8000003F80001FFF8001FF
FF8007FE3F801FE03F803FC03F807F803F807F003F80FE003F80FE003F80FE003F80FE007F80FF
007F807F00FFC03FC3DFFC1FFF8FFC03FE07FC1E1B7E9A21>97 D<FFE0000000FFE0000000FFE0
0000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000FE00000000F
E00000000FE00000000FE00000000FE00000000FE00000000FE3FE00000FEFFFC0000FFF07F000
0FFC03F8000FF001FC000FE000FE000FE000FE000FE0007F000FE0007F000FE0007F800FE0007F
800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE000
7F000FE000FF000FE000FE000FF000FE000FF001FC000FF803F8000F9E0FE0000F0FFFC0000E03
FE0000212A7EA926>I<003FF80001FFFE0007F83F000FE07F801FC07F803F807F803F807F807F
807F807F003F00FF000000FF000000FF000000FF000000FF000000FF000000FF000000FF000000
FF0000007F0000007F8000003F8001C03FC001C01FC003C00FE0078007F83F0001FFFC00003FF0
001A1B7E9A1F>I<00003FF80000003FF80000003FF800000003F800000003F800000003F80000
0003F800000003F800000003F800000003F800000003F800000003F800000003F800000003F800
000003F800003FE3F80001FFFBF80003F83FF8000FE00FF8001FC007F8003F8003F8003F8003F8
007F8003F8007F0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003
F800FF0003F800FF0003F800FF0003F8007F0003F8007F0003F8003F8003F8003F8007F8001FC0
0FF8000FE01FF80007F07FFF8001FFFBFF80003FC3FF80212A7EA926>I<003FE00001FFFC0007
F07E000FE03F001FC01F803F800FC03F800FC07F000FC07F0007E0FF0007E0FF0007E0FF0007E0
FFFFFFE0FFFFFFE0FF000000FF000000FF000000FF0000007F0000007F8000003F8000E03F8001
E01FC001C00FE007C003F81F8001FFFE00003FF8001B1B7E9A20>I<00FF81F007FFF7FC0FE3FF
7C1F80FCFC3F80FE7C3F007E787F007F007F007F007F007F007F007F007F007F007F007F003F00
7E003F80FE001F80FC000FE3F8001FFFF00018FF8000380000003C0000003C0000003E0000003F
FFFC003FFFFF001FFFFFC00FFFFFE007FFFFF03FFFFFF07E000FF87C0001F8F80001F8F80000F8
F80000F8F80000F8FC0001F87E0003F03F0007E01FE03FC007FFFF0000FFF8001E287E9A22>
103 D<0F801FC03FE03FE03FE03FE03FE01FC00F800000000000000000000000000000FFE0FFE0
FFE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00F
E00FE00FE0FFFEFFFEFFFE0F2B7DAA14>105 D<0007C0000FE0001FF0001FF0001FF0001FF000
1FF0000FE00007C000000000000000000000000000000000000000000000FFF000FFF000FFF000
07F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F000
07F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F000
07F07E07F0FF07F0FF07F0FF0FE0FF0FE0FF1FC07E3F803FFE000FF800143785AA15>I<FFE0FF
E0FFE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE0
0FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE0FFFEFF
FEFFFE0F2A7DA914>108 D<FFC07F800FF000FFC1FFE03FFC00FFC7C3F0F87E000FCF03F9E07F
000FDC01FB803F000FF801FF003F800FF001FE003F800FF001FE003F800FF001FE003F800FE001
FC003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC003F80
0FE001FC003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC003F800FE001FC
003F800FE001FC003F800FE001FC003F800FE001FC003F80FFFE1FFFC3FFF8FFFE1FFFC3FFF8FF
FE1FFFC3FFF8351B7D9A3A>I<FFC0FF0000FFC3FFC000FFC787E0000FCE07F0000FDC03F8000F
F803F8000FF003F8000FF003F8000FF003F8000FE003F8000FE003F8000FE003F8000FE003F800
0FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8
000FE003F8000FE003F8000FE003F800FFFE3FFF80FFFE3FFF80FFFE3FFF80211B7D9A26>I<00
3FE00001FFFC0003F07E000FC01F801F800FC03F800FE03F0007E07F0007F07F0007F07F0007F0
FF0007F8FF0007F8FF0007F8FF0007F8FF0007F8FF0007F8FF0007F8FF0007F87F0007F07F0007
F03F800FE03F800FE01F800FC00FC01F8007F07F0001FFFC00003FE0001D1B7E9A22>I<FFE3FE
0000FFEFFFC000FFFF0FF0000FFC03F8000FF001FC000FE001FE000FE000FE000FE000FF000FE0
00FF000FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800FE0007F800F
E0007F800FE0007F800FE000FF000FE000FF000FE000FE000FF001FE000FF003FC000FF807F800
0FFE0FE0000FEFFFC0000FE3FE00000FE00000000FE00000000FE00000000FE00000000FE00000
000FE00000000FE00000000FE00000000FE0000000FFFE000000FFFE000000FFFE00000021277E
9A26>I<003FE0380001FFF8780003F87CF8000FF01FF8001FE00FF8003FC007F8003F8007F800
7F8003F8007F8003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F800FF0003F8
00FF0003F800FF0003F800FF0003F8007F8003F8007F8003F8003F8003F8003FC007F8001FC00F
F8000FE01FF80007F87FF80001FFF3F800003FC3F800000003F800000003F800000003F8000000
03F800000003F800000003F800000003F800000003F800000003F80000003FFF8000003FFF8000
003FFF8021277E9A24>I<FFC7F0FFCFFCFFDC7E0FD8FF0FF8FF0FF0FF0FF0FF0FF0FF0FE07E0F
E0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000F
E0000FE000FFFF00FFFF00FFFF00181B7E9A1C>I<03FE701FFFF03E03F07801F07000F0F00070
F00070F80070FE0000FFF000FFFF007FFFC03FFFE01FFFF007FFF800FFFC0007FC0000FCE0007C
E0003CF0003CF0003CF80078FC0078FF01F0FFFFC0E1FF00161B7E9A1B>I<0070000070000070
0000700000F00000F00000F00001F00003F00003F00007F0001FFFF0FFFFF0FFFFF007F00007F0
0007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F03807F0
3807F03807F03807F03807F03807F03803F87001FCF000FFE0003FC015267FA51B>I<FFE03FF8
00FFE03FF800FFE03FF8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003
F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE003F8000FE0
03F8000FE003F8000FE003F8000FE003F8000FE007F8000FE007F8000FE00FF80007E01FF80003
F83BFF8001FFF3FF80007FE3FF80211B7D9A26>I<FFFE03FF80FFFE03FF80FFFE03FF8007F000
700007F000700007F800F00003F800E00003FC01E00001FC01C00001FC01C00000FE03800000FE
038000007F070000007F070000007F8F0000003F8E0000003FDE0000001FDC0000001FDC000000
0FF80000000FF80000000FF800000007F000000007F000000003E000000003E000000001C00000
0001C000000003800000000380000038078000007C07000000FE0F000000FE0E000000FE1E0000
00FE3C0000007C780000003FE00000000FC000000021277F9A24>121 D
E /Fm 15 122 df<70F8FCFC7C0C0C0C1C18183870E0E0060F7C840E>44
D<01F00007FC000E0E001C07003803803803807803C07001C07001C07001C0F001E0F001E0F001
E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E07001C07001
C07001C07803C03803803803801C07000E0E0007FC0001F00013227EA018>48
D<018003800F80FF80F38003800380038003800380038003800380038003800380038003800380
038003800380038003800380038003800380038003800380FFFEFFFE0F217CA018>I<007E0001
FF8003C3C00703C00E03C01E03C03C03C0380000780000780000780000702000F3FC00F7FF00FE
0F80FC0780F803C0F803C0F801E0F001E0F001E0F001E0F001E0F001E07001E07001E07801E078
01C03803C03C03801E07800F1F0007FE0003F80013227EA018>54 D<03F8000FFC001F1E003C07
003807807803807003C0F003C0F001C0F001C0F001E0F001E0F001E0F001E0F001E0F003E07803
E07803E03C07E03E0FE01FFDE007F9E00081E00001C00003C00003C0000380780780780700780F
00781E00787C003FF8000FE00013227EA018>57 D<FFFFF000FFFFFE0007801F00078007C00780
03C0078001E0078000F0078000F8078000780780007C0780003C0780003C0780003C0780003E07
80003E0780003E0780003E0780003E0780003E0780003E0780003E0780003E0780003C0780003C
0780007C0780007807800078078000F0078001E0078003E0078007C007801F00FFFFFE00FFFFF8
001F227EA125>68 D<03FFF003FFF0000F00000F00000F00000F00000F00000F00000F00000F00
000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00000F00
000F00000F00000F00F80F00F80F00F80F00F81F00F01E00703E00787C003FF8000FE00014237E
A119>74 D<0000F003FBF807FFB80F1F381E0F003C07803C07803C07803C07803C07803C07803C
07801E0F001F1E001FFC001BF8001800001800001C00001FFF000FFFC03FFFF07C01F0700078F0
0078E00038E00038E00038F000787800F03F07E01FFFC003FE0015217F9518>103
D<0E0000FE0000FE00001E00000E00000E00000E00000E00000E00000E00000E00000E00000E00
000E00000E3F800EFFE00FE1E00F80F00F00700F00700E00700E00700E00700E00700E00700E00
700E00700E00700E00700E00700E00700E00700E0070FFE7FFFFE7FF18237FA21B>I<0E00FE00
FE001E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E
000E000E000E000E000E000E000E000E000E000E000E00FFE0FFE00B237FA20E>108
D<0E3F80FEFFE0FFE1E01F80F00F00700F00700E00700E00700E00700E00700E00700E00700E00
700E00700E00700E00700E00700E00700E0070FFE7FFFFE7FF18157F941B>110
D<01FC0007FF000F07801C01C03800E07800F0700070F00078F00078F00078F00078F00078F000
78F000787000707800F03800E01C01C00F078007FF0001FC0015157F9418>I<1FD83FF87878F0
38E018E018F018F8007F807FE01FF003F8007CC03CC01CE01CE01CF03CF878FFF0CFE00E157E94
13>115 D<0E0070FE07F0FE07F01E00F00E00700E00700E00700E00700E00700E00700E00700E
00700E00700E00700E00700E00F00E00F00E01F00787F807FF7F01FC7F18157F941B>117
D<FFC3FEFFC3FE1E00F80E00700E00E00700C00700C00700C003818003818003C38001C30001C3
0000E60000E60000E600007C00007C00007C000038000038000030000030000070000060000060
00F0C000F1C000F380007F00003E0000171F7F941A>121 D E /Fn 23 122
df<FFFF807FFFC0FFFF807FFFC007F00003F80003E00001F00003E00001F00003E00001F00003
E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001
F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003
E00001F00003E00001F00003E00001F00003E00001F00003FFFFFFF00003FFFFFFF00003E00001
F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003
E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001
F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003E00001F00003
E00001F00007F00003F800FFFF807FFFC0FFFF807FFFC02A317CB032>72
D<FFFFC00000FFFFC0000007F000000003E000000003E000000003E000000003E000000003E000
000003E000000003E000000003E000000003E000000003E000000003E000000003E000000003E0
00000003E000000003E000000003E000000003E000000003E000000003E000000003E000000003
E000000003E000000003E000000003E000000003E000000003E000000003E000000003E0000000
03E00000C003E00000C003E00000C003E00000C003E000018003E000018003E000018003E00001
8003E000038003E000038003E000038003E000078003E0000F8003E0001F0003E0003F0007E001
FF00FFFFFFFF00FFFFFFFF0022317CB029>76 D<FFF00000007FF8FFF8000000FFF807F8000000

01E00FFFF8FFFC00C00FFFF835317CB03D>I<00003FC000000001FFF800000007C03E0000001F

000001FFF8000000003FC000002C337CB134>79 D<FFFFFFC000FFFFFFF80007E000FE0003E000
1F0003E0000F8003E00007C003E00003E003E00003F003E00001F003E00001F003E00001F803E0
0001F803E00001F803E00001F803E00001F803E00001F803E00001F003E00001F003E00003F003
E00003E003E00007C003E0000F8003E0001F0003E000FE0003FFFFF80003FFFFC00003E0000000
03E000000003E000000003E000000003E000000003E000000003E000000003E000000003E00000
0003E000000003E000000003E000000003E000000003E000000003E000000003E000000003E000
000003E000000003E000000003E000000007F0000000FFFF800000FFFF80000025317CB02D>I<
007F806003FFF06007C0F8E00F003CE01E000FE03C0007E03C0003E0780003E0780001E0F00001
E0F00000E0F00000E0F00000E0F0000060F8000060F8000060F80000007C0000007E0000007F00
00003FC000001FFC00001FFFC0000FFFF80003FFFE0000FFFF00001FFF800001FFC000001FE000
0007E0000003F0000001F0000001F8000000F8000000F8C0000078C0000078C0000078C0000078
E0000078E0000078E0000070F00000F0F00000F0F80001E0FC0001E0FF0003C0E7800F80E3F01F
00C0FFFC00C01FF0001D337CB125>83 D<7FFFFFFFFFE07FFFFFFFFFE07F000F800FE07C000F80

317EB030>I<FFFE003FFF8007FFC0FFFE003FFF8007FFC00FE00003F80000FE0007E00001F800

00003C00000F00000000001C00000E00000000001800000600000042327FB044>87
D<03FF00000FFFC0001E03F0003E00F8003E007C003E003C003E003E001C001E0000001E000000
1E0000001E0000001E000003FE00007FFE0003FF1E0007F01E001FC01E003F001E007E001E007C
001E00FC001E00F8001E0CF8001E0CF8001E0CF8003E0CFC007E0C7C007E0C7E01FF1C3F87CFB8
1FFF07F003FC03C01E1F7D9E21>97 D<003FE001FFF803E03C07C03E0F003E1F003E3E003E3C00
1C7C00007C0000780000F80000F80000F80000F80000F80000F80000F80000F80000F800007C00
007C00007C00003E00033E00071F00060F800E07C01C03F07801FFF0003F80181F7D9E1D>99
D<000001E000003FE000003FE0000003E0000001E0000001E0000001E0000001E0000001E00000
01E0000001E0000001E0000001E0000001E0000001E0000001E0000001E0000001E0000001E000
3F81E001FFF1E003F079E007C01FE00F800FE01F0007E03E0003E03C0001E07C0001E07C0001E0
780001E0F80001E0F80001E0F80001E0F80001E0F80001E0F80001E0F80001E0F80001E0F80001
E0780001E07C0001E07C0001E03C0003E03E0003E01E0007E01F000FE00FC03DE007E0F9F001FF
E1FF007F81FF20327DB125>I<003F800001FFF00003E1F80007807C000F003E001E001E003E00
1F003C000F007C000F807C000F8078000F80F8000780FFFFFF80FFFFFF80F8000000F8000000F8
000000F8000000F8000000F80000007C0000007C0000007C0000003E0001803E0003801F000300
0F80070007E00E0003F83C0000FFF800003FC000191F7E9E1D>I<0007F0001FF8007C3C00F87C
00F07C01E07C01E03803E00003C00003C00003C00003C00003C00003C00003C00003C00003C000
03C00003C000FFFFC0FFFFC003C00003C00003C00003C00003C00003C00003C00003C00003C000
03C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C000
03C00003C00003C00003C00007E0007FFF007FFF0016327FB114>I<000001F8007F07FC01FFCF
1C07E3FC3C0F80F81C0F0078001F007C001E003C003E003E003E003E003E003E003E003E003E00
3E003E003E003E003E001E003C001F007C000F0078000F80F8000FE3F0000DFFC0001C7F00001C
0000001C0000001C0000001E0000001F0000000FFFF8000FFFFF0007FFFFC00FFFFFE03E000FF0
7C0001F0780000F0F0000078E0000038E0000038E0000038E0000038F000007870000070780000
F03C0001E01F0007C00FE03F8003FFFE00007FF0001E2F7E9F21>I<0F001F801F801F801F800F
00000000000000000000000000000000000000000000000780FF80FF800F800780078007800780
078007800780078007800780078007800780078007800780078007800780078007800780078007
800FC0FFF8FFF80D307EAF12>105 D<0780FF80FF800F80078007800780078007800780078007
800780078007800780078007800780078007800780078007800780078007800780078007800780
07800780078007800780078007800780078007800780078007800780078007800FC0FFFCFFFC0E
327EB112>108 D<0781FE0000FF87FF8000FF9E0FC0000FB803E00007F001E00007E001F00007
E000F00007C000F00007C000F000078000F000078000F000078000F000078000F000078000F000
078000F000078000F000078000F000078000F000078000F000078000F000078000F000078000F0
00078000F000078000F000078000F000078000F000078000F000078000F0000FC001F800FFFC1F
FF80FFFC1FFF80211F7E9E25>110 D<001FC00000FFF80001E03C0007800F000F0007801E0003
C01E0003C03C0001E03C0001E0780000F0780000F0780000F0F80000F8F80000F8F80000F8F800
00F8F80000F8F80000F8F80000F8F80000F8780000F07C0001F03C0001E03C0001E01E0003C01E
0003C00F00078007C01F0001F07C0000FFF800001FC0001D1F7E9E21>I<0787F0FF8FF8FFBC7C
0FB87C07F07C07E07C07E00007C00007C00007C000078000078000078000078000078000078000
0780000780000780000780000780000780000780000780000780000780000780000780000FC000
FFFE00FFFE00161F7E9E19>114 D<03FE300FFFF03E07F07801F07000F0E00070E00070E00030
E00030F00030F800007F00007FF0003FFF000FFFC003FFE0003FF00003F80000F8C0007CC0003C
E0001CE0001CE0001CF0001CF80038F80038FC00F0EF03F0C7FFC0C1FF00161F7E9E1A>I<00C0
0000C00000C00000C00000C00001C00001C00001C00003C00003C00007C0000FC0001FC000FFFF
E0FFFFE003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C0
0003C00003C00003C00003C00003C03003C03003C03003C03003C03003C03003C03003C07001E0
6001E0E000F9C000FFC0003F00142C7FAB19>I<078000F000FF801FF000FF801FF0000F8001F0
00078000F000078000F000078000F000078000F000078000F000078000F000078000F000078000
F000078000F000078000F000078000F000078000F000078000F000078000F000078000F0000780
00F000078000F000078000F000078001F000078001F000078001F000078003F00003C007F00003
C00EF00001F03CF80000FFF8FF80003FC0FF80211F7E9E25>I<FFF803FF80FFF803FF800FC000
FC000780007800078000700003C000700003C000600003E000E00001E000C00001E000C00000F0
01800000F001800000F801800000780300000078030000007C070000003C060000003C06000000
1E0C0000001E0C0000001F1C0000000F180000000F1800000007B000000007B000000007B00000
0003E000000003E000000003E000000001C000000001C000000001800000000180000000038000
000003000000000300000000060000000006000000700E000000F80C000000F81C000000F83800
000070700000003FE00000001F80000000212D7F9E23>121 D E end
%%EndProlog
%%BeginSetup
%%Feature: *Resolution 300
TeXDict begin 
%%EndSetup
%%Page: 1 1
bop 462 440 a Fn(On)21 b(Holy)g(W)-6 b(ars)22 b(and)f(a)g(Plea)h(for)g(P)n
(eace)586 531 y(MMST)f(Language)g(Selection)824 652 y Fm(Doug)c(Johnson)834
749 y(July)e(16,)i(1990)125 904 y Fl(Abstract)125 996 y Fk(The)i(purp)q(ose)h
(of)e(this)h(do)q(cumen)o(t)g(is)g(to)f(start)i(to)125 1046
y(rationalize)315 1031 y Fj(1)346 1046 y Fk(the)15 b(c)o(hoice)f(of)g
(language)f(for)h(MMST)125 1096 y(dev)o(elopmen)o(t.)j(It)d(will)f(discuss)i
(selection)g(criteria,)125 1146 y(issues)j(related)g(to)f(those)h(criteria,)g
(and)f(ho)o(w)f(w)o(ell)125 1195 y(the)e(v)n(arious)f(languages)h(meet)f
(them.)166 1246 y(The)18 b(issues)h(and)f(languages)f(are)h(discussed)i(on)
125 1296 y(a)d(qualitativ)o(e,)g(rather)i(quan)o(titativ)o(e)e(basis.)30
b(Key)125 1345 y(quan)o(titativ)o(e)19 b(issues)j(will)e(b)q(e)h(addressed)i
(b)o(y)d(the)125 1395 y(system)27 b(design)i(team)e(o)o(v)o(er)h(the)h(next)f
(sev)o(eral)125 1445 y(mon)o(ths.)k(The)20 b(in)o(ten)o(t)f(of)g(this)g(do)q
(cumen)o(ts)g(is)g(to)125 1495 y(pro)o(vide)11 b(a)g(concrete)j(basis)e(for)f
(further)i(discussion,)125 1545 y(leading)e(to)i(general)g(agreemen)o(t)g(on)
f(just)h(what)g(the)125 1594 y(k)o(ey)g(issues)i(are.)125 1734
y Fl(1)69 b(In)n(tro)r(duction)125 1826 y Fk(The)15 b(discussion)h(of)e(the)i
(MMST)f(implemen)o(tation)125 1876 y(language)9 b(has)i(b)q(een)h(one)f(of)f
(the)h(most)f(emotionally)125 1926 y(c)o(harged)j(issues)h(I)f(ha)o(v)o(e)f
(ev)o(er)i(b)q(een)g(in)o(v)o(olv)o(ed)d(in.)18 b(It)125 1976
y(is)d(an)g(imp)q(ortan)o(t)f(decision)i(and)f(should)h(b)q(e)g(made)125
2025 y(in)e(a)h(rational)f(manner,)g(but)i(the)g(participan)o(ts)f(all)125
2075 y(seem)j(to)h(b)q(e)g(op)q(erating)g(with)f(di\013eren)o(t)i(assump-)125
2125 y(tions)10 b(and)h(priorities.)17 b(A)11 b(summary)e(to)h(date)i(migh)o
(t)125 2175 y(consist)j(of:)k(\\C++,)14 b(of)g(course.")22
b(and)14 b(\\I)g(lo)o(v)o(e)g(m)o(y)125 2225 y(Smalltal)o(k/Lisp".)j(I)e
(think)f(it's)h(imp)q(ortan)o(t)e(to)h(es-)125 2274 y(tablish)k(a)h(set)g(of)
g(selection)g(criteria)h(that)f(w)o(e)g(all)125 2324 y(can)f(agree)g(on)g
(and)f(then)i(apply)e(them)g(as)h(ob)r(jec-)125 2374 y(tiv)o(ely)d(as)g(p)q
(ossible.)24 b(As)16 b(a)g(starting)g(p)q(oin)o(ting,)e(I'll)p
125 2411 333 2 v 171 2437 a Fi(1)188 2449 y Fh(In)d(the)g(sense)f(of)i
(taking)d(the)i(emotion)e(out.)996 904 y Fk(outline)k(the)h(criteria)g(that)f
(are)h(b)q(eing)f(used)i(b)o(y)e(the)996 954 y(CIP)20 b(system)f(design)h
(team.)34 b(W)m(e)20 b(are)g(op)q(erating)996 1004 y(on)g(the)g(assumption)e
(that)i(a)f(single)h(language)f(is)996 1054 y(preferred)d(to)d(m)o(ultiple)e
(languages.)17 b(Ho)o(w)o(ev)o(er,)d(the)996 1104 y(CIP)19
b(system)e(requiremen)o(ts)i(are)f(div)o(erse)h(enough)996
1153 y(that)13 b(w)o(e)g(ma)o(y)e(ha)o(v)o(e)i(to)g(use)h(more)d(than)i(one)g
(in)g(it's)996 1203 y(dev)o(elopmen)o(t.)1038 1378 y(The)23
b(selection)g(criteria)g(ha)o(v)o(e)f(few)g(absolutes,)996
1428 y(they)15 b(are)f(mostly)e(shades)i(of)g(grey)m(.)j(Must)e(w)o(e)f(ha)o
(v)o(e)996 1478 y(the)g(most)f(p)q(opular)g(language?)k(Of)d(course)g(not,)f
(or)996 1527 y(w)o(e)f(w)o(ould)e(use)i(COBOL.)f(Must)h(w)o(e)f(ha)o(v)o(e)g
(the)h(most)996 1577 y(e\016cien)o(t?)35 b(No,)19 b(or)h(w)o(e)f(w)o(ould)f
(b)q(e)i(co)q(ding)f(in)g(as-)996 1627 y(sem)o(bly)13 b(language.)19
b(I)c(b)q(eliev)o(e)g(there)g(are)g(only)f(t)o(w)o(o)996 1677
y(absolute)i(requiremen)o(ts:)23 b(it)15 b(m)o(ust)g(b)q(e)h(ob)r(ject)h
(ori-)996 1727 y(en)o(ted)11 b(and)e(it)g(m)o(ust)f(ha)o(v)o(e)h(an)h(exp)q
(ected)h(lifetime)c(ex-)996 1776 y(ceeding)13 b(that)f(of)g(the)h(CIP)f
(system)g(\(15)g(y)o(ear)g(goal\).)1038 1951 y(There)k(is)f(a)g(wide)g(range)
g(of)f(desirable)i(features,)996 2001 y(b)q(oth)25 b(tec)o(hnical)g(and)g
(business,)j(that)d(m)o(ust)f(b)q(e)996 2051 y(traded)e(o\013)e(against)g
(eac)o(h)h(other.)39 b(No)20 b(language)996 2100 y(optimizes)f(all)h(of)f
(them.)37 b(I)20 b(b)q(eliev)o(e)h(the)g(discus-)996 2150 y(sion)14
b(m)o(ust)g(fo)q(cus)h(on)f(the)h(problem)e(w)o(e)i(are)g(trying)996
2200 y(to)e(solv)o(e|dev)o(elopmen)o(t)e(of)h(the)h(MMST)f(CIP)h(sys-)996
2250 y(tem.)k(It)11 b(is)g(p)q(oin)o(tless)g(to)g(talk)f(ab)q(out)h(the)h
(virtues)g(of)996 2300 y(a)i(language)e(outside)i(some)f(problem)f(con)o
(text.)19 b(In-)996 2350 y(dividual)11 b(features)j(of)d(a)h(language)g(can)g
(b)q(e)h(either)h(a)996 2399 y(strength)e(or)f(a)f(w)o(eakness)i(dep)q
(ending)f(on)f(the)i(prob-)996 2449 y(lem.)135 2573 y Fg(c)125
2574 y Ff(\015)h Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h(Johnson)1077
b Fk(1)p eop
%%Page: 2 2
bop 125 307 a Fl(2)69 b(Absolute)22 b(Requiremen)n(ts)125 402
y Fk(As)g(men)o(tioned,)g(I)g(b)q(eliev)o(e)g(there)i(are)e(only)f(t)o(w)o(o)
125 452 y(\\drop)13 b(dead")h(requiremen)o(ts)h(for)e(a)h(language:)j(ob-)125
502 y(ject)f(orien)o(ted)g(and)g(an)g(exp)q(ected)i(life)d(of)g(15)g(y)o
(ears)125 552 y(or)g(more.)22 b(I)16 b(don't)f(exp)q(ect)i(m)o(uc)o(h)e(con)o
(tro)o(v)o(ersy)h(on)125 602 y(these,)22 b(so)f(w)o(on't)f(defend)h(them)e
(in)h(detail.)37 b(But)125 652 y(they)14 b(do)g(narro)o(w)f(the)i(\014eld)f
(tremendously)m(.)125 780 y Fe(2.1)55 b(Ob)s(ject)19 b(Orien)n(ted)125
861 y Fk(F)m(or)k(man)o(y)f(sound)i(reasons,)i(\\ob)r(ject)e(orien)o(ted")125
911 y(has)c(b)q(een)i(selected)g(as)e(the)h(unifying)e(theme)h(for)125
961 y(the)15 b(CIP)f(dev)o(elopmen)o(t.)19 b(W)m(e`v)o(e)14
b(done)h(ob)r(ject)g(ori-)125 1011 y(en)o(ted)20 b(analysis,)g(w)o(e)f(are)h
(doing)f(ob)r(ject)h(orien)o(ted)125 1060 y(design,)29 b(w)o(e)d(will)f(do)i
(an)f(ob)r(ject)h(orien)o(ted)g(im-)125 1110 y(plemen)o(tation.)41
b(It)22 b(just)h(mak)o(es)e(go)q(o)q(d)h(sense)i(to)125 1160
y(c)o(ho)q(ose)12 b(an)g(ob)r(ject)g(orien)o(ted)h(language)e(to)g(aid)h
(that)125 1210 y(implem)o(en)o(tation)410 1195 y Fj(2)426 1210
y Fk(.)166 1262 y(No)o(w,)32 b(if)c(y)o(ou)h(start)h(lo)q(oking)d(at)i
(languages)125 1312 y(to)22 b(see)i(if)d(they)i(are)g(ob)r(ject)g(orien)o
(ted,)i(y)o(ou)d(dis-)125 1362 y(co)o(v)o(er)g(a)g(gra)o(y)g(scale)g(here,)j
(to)q(o.)43 b(Some)21 b(clearly)125 1412 y(are)g(\(e.g.)g(Smalltalk,)f
(E\016el,)j(Actor,)g(CLU,)p Fd(:)7 b(:)g(:)e Fk(\).)125 1461
y(Some)19 b(clearly)h(aren't)g(\(e.g.)g(COBOL)755 1446 y Fj(3)775
1461 y Fk(,)f(F)m(ortran,)125 1511 y(BASIC)p Fd(:)7 b(:)g(:)e
Fk(\).)29 b(In)17 b(the)h(middle)e(is)h(a)g(range)h(of)f(lan-)125
1561 y(guages)10 b(that)g(mix)e(ob)r(ject)i(orien)o(ted)h(and)f(functional)
125 1611 y(concepts.)21 b(Ada)15 b(lies)f(at)g(the)h(\\mostly)e(functional")
125 1661 y(end)j(of)f(the)i(sp)q(ectrum)f(with)f(a)h(few)g(features)h(that)
125 1710 y(p)q(ermit)h(a)i(v)o(ersion)g(of)f(OO.)h(C++)g(and)g(Lisp)f(are)125
1760 y(near)9 b(the)h(other)h(end)e(with)h(strong)f(supp)q(ort)i(for)e(OO,)
125 1810 y(but)14 b(still)f(preserving)i(their)f(functional)f(heritage.)125
1939 y Fe(2.2)55 b(Long)19 b(Life)125 2020 y Fk(It)12 b(w)o(ould)f(b)q(e)i
(an)f(exp)q(ensiv)o(e)h(tragedy)f(for)g(us)h(to)f(im-)125 2070
y(plemen)o(t)19 b(the)i(CIP)f(system)g(in)g(a)f(language)h(that)125
2119 y(will)14 b(b)q(e)i(an)f(orphan)h(in)f(ten)h(y)o(ears.)24
b(W)m(e)15 b(w)o(ould)g(b)q(e)125 2169 y(faced)d(with)g(either)h(supp)q
(orting)g(the)g(language)e(and)p 125 2213 333 2 v 171 2240
a Fi(2)188 2252 y Fh(It)i(is)f(p)q(ossible)g(to)g(use)g(ob)r(ject)g(orien)o
(ted)e(tec)o(hniques)g(in)125 2291 y(an)o(y)i(language.)17
b(In)c(fact,)f(once)g(man)o(y)g(go)q(o)q(d)g(programm)o(ers)125
2331 y(understand)i(OO,)k(they)e(sa)o(y)h(\\I'v)o(e)f(b)q(een)g(doing)f(that)
i(for)125 2370 y(y)o(ears.")c(Ho)o(w)o(ev)o(er,)e(OO)i(languages)c(mak)o(e)h
(it)h(m)o(uc)o(h)f(easier.)171 2398 y Fi(3)188 2410 y Fh(Although)j(there)g
(is)h(a)g(committee)d(forming)i(to)h(de\014ne)125 2449 y(an)d(ob)r(ject)e
(orien)o(ted)h(COBOL.)996 307 y Fk(to)q(ols)j(ourselv)o(es)i(or)e(totally)f
(rewriting)i(the)g(system)996 357 y(in)g(some)f(new)h(language.)1038
407 y(While)f(it)g(is)g(imp)q(ossible)f(to)i(predict)g(the)g(future,)996
457 y(there)e(are)g(man)o(y)d(things)h(that)h(can)g(giv)o(e)g(con\014dence)
996 506 y(that)17 b(the)f(language)g(will)e(p)q(ersist.)27
b(These)17 b(are)g(the)996 556 y(ones)e(w)o(e'v)o(e)f(used)g(to)g(narro)o(w)g
(the)g(\014eld:)1038 639 y Fc(\017)20 b Fk(Curren)o(t)e(Age.)28
b(A)17 b(language)f(that)h(has)g(b)q(een)1079 688 y(around)f(for)f(a)h(n)o
(um)o(b)q(er)f(of)g(y)o(ears)h(is)g(lik)o(ely)f(to)1079 738
y(sta)o(y)m(.)1038 821 y Fc(\017)20 b Fk(An)14 b(activ)o(e)g(formal)e
(standards)i(b)q(o)q(dy)m(.)1038 904 y Fc(\017)20 b Fk(Supp)q(ort)28
b(from)e(m)o(ultiple)f(viable)i(v)o(endors,)1079 954 y(including)c
(compilers,)h(dev)o(elopmen)o(t)f(to)q(ols,)1079 1003 y(user)15
b(in)o(terface)g(builders,)e(databases,)i(etc.)1038 1086 y
Fc(\017)20 b Fk(A)d(large,)e(div)o(erse)i(user)h(comm)o(unit)o(y)13
b(in)i(b)q(oth)1079 1136 y(industry)g(and)e(academia)1495 1121
y Fj(4)1512 1136 y Fk(.)1038 1218 y(Bey)o(ond)20 b(the)g(absolute)f(criteria)
h(of)f(just)g(b)q(eing)996 1268 y(viable)e(for)g(15)f(y)o(ears,)i(is)f(a)g
(desireable)h(criteria)g(of)996 1318 y(ha)o(ving)g(a)h(broad)f(use)i(and)f
(acceptance)i(o)o(v)o(er)e(the)996 1368 y(pro)r(ject)c(life.)j(This)c(is)g
(mostly)e(what)i(p)q(eople)h(mean)996 1418 y(when)k(they)g(talk)e(ab)q(out)h
(\\standard")h(and)f(is)g(ad-)996 1467 y(dressed)e(in)e(section)g(3.1.1.)996
1583 y Fe(2.3)56 b(Candidates)996 1660 y Fk(When)12 b(y)o(ou)f(\014lter)h
(the)g(w)o(orld's)e(languages)h(through)996 1710 y(the)31 b(absolute)g
(criteria,)j(only)c(three)h(are)g(left.)996 1760 y(Most)23
b(existing)f(languages)g(are)h(not)f(ob)r(ject)h(ori-)996 1809
y(en)o(ted)13 b(enough.)18 b(Most)12 b(ob)r(ject)h(orien)o(ted)g(languages)
996 1859 y(are)20 b(to)q(o)f(new)h(to)f(ha)o(v)o(e)g(an)o(y)g(con\014dence)i
(in)e(their)996 1909 y(longevit)o(y)m(.)38 b(The)21 b(three)i(candidates)e
(are)h(CLOS,)996 1959 y(C++,)17 b(and)e(Smalltalk.)21 b(The)16
b(only)f(marginal)e(call)996 2009 y(is)f(Ada,)g(whic)o(h)g(w)o(as)g(omitted)f
(b)q(ecause)j(of)d(its)i(w)o(eak)996 2059 y(OO)i(supp)q(ort.)1038
2108 y(In)23 b(terms)g(of)f(longevit)o(y)m(,)h(the)h(star)f(candidate)996
2158 y(is)c(Lisp.)32 b(It)19 b(meets)g(all)e(four)i(criteria)g(men)o(tioned)
996 2208 y(ab)q(o)o(v)o(e,)i(it's)f(o)o(v)o(er)g(thirt)o(y)f(y)o(ears)i(old,)
f(has)g(a)g(v)o(ery)996 2258 y(activ)o(e)d(standards)g(committee)1502
2243 y Fj(5)1518 2258 y Fk(,)g(four)f(ma)r(jor)f(and)p 996
2292 V 1042 2319 a Fi(4)1060 2331 y Fh(I)j(view)g(this)f(a)h(threshold)d
(requiremen)o(t.)32 b(Once)17 b(the)996 2370 y(user)f(comm)o(unit)o(y)e(reac)
o(hes)h(a)i(certain)e(critical)g(mass,)i(the)996 2410 y(language)9
b(will)j(b)q(e)f(viable)f(for)h(some)f(time)h(to)g(come.)1042
2437 y Fi(5)1060 2449 y Fh(With)g(sev)o(eral)f(TI)i(participan)o(t)o(s.)135
2573 y Fg(c)125 2574 y Ff(\015)h Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h
(Johnson)1077 b Fk(2)p eop
%%Page: 3 3
bop 125 307 a Fk(man)o(y)15 b(minor)g(v)o(endors,)k(and)e(a)g(broad)g(user)h
(com-)125 357 y(m)o(unit)o(y)m(.)166 408 y(C++)g(is)f(somewhat)g(w)o(eak)o
(er.)29 b(It's)17 b(only)g(a)g(few)125 458 y(y)o(ears)23 b(old)296
443 y Fj(6)314 458 y Fk(,)h(the)f(X3J16)f(standards)i(committee)125
508 y(has)d(just)g(formed,)g(v)o(endors)h(are)f(still)f(emerging,)125
557 y(and)14 b(there)h(is)f(a)g(v)o(ery)h(rapidly)e(gro)o(wing)g(user)i(com-)
125 607 y(m)o(unit)o(y)m(.)44 b(Ho)o(w)o(ev)o(er,)26 b(there)f(seems)f(to)f
(b)q(e)h(little)125 657 y(doubt)13 b(of)h(its)g(longevit)o(y)m(.)166
708 y(Smalltalk)c(is)j(the)h(w)o(eak)o(est)g(of)f(the)h(three)h(in)e(this)125
758 y(area.)33 b(It's)19 b(ab)q(out)g(15)f(y)o(ears)i(old,)f(has)g(no)g
(activ)o(e)125 808 y(standards)j(b)q(o)q(dy)m(,)g(is)f(supp)q(orted)i(b)o(y)e
(t)o(w)o(o)g(ma)r(jor)125 857 y(v)o(endors)10 b(and)g(man)o(y)f(smaller)f
(ones,)j(and)f(has)h(a)e(sub-)125 907 y(stan)o(tial)k(\(and)g(gro)o(wing\))g
(user)i(comm)o(unit)o(y)m(.)125 1050 y Fl(3)69 b(Desirable)21
b(Criteria)125 1143 y Fk(No)o(w)12 b(w)o(e)h(get)g(to)g(the)g(hard)g(issues.)
19 b(Eac)o(h)13 b(language)125 1193 y(is)j(b)q(est)i(at)e(something.)25
b(No)17 b(language)f(is)g(b)q(est)i(at)125 1243 y(ev)o(erything.)f(W)m(e)9
b(m)o(ust)g(w)o(eigh)h(these)h(desirable)g(cri-)125 1293 y(teria)g(against)g
(eac)o(h)h(other)h(to)e(ac)o(hiev)o(e)h(the)g(b)q(est)h(so-)125
1343 y(lution)g(for)h(our)h(problem.)k(Sev)o(eral)14 b(of)g(these)i(areas)125
1392 y(ha)o(v)o(e)9 b(a)g(sharp)h(threshold.)17 b(It)10 b(is)f(a)g(ma)r(jor)f
(limitation)125 1442 y(if)g(there)k(are)e(no)f(go)q(o)q(d)h(dev)o(elopmen)o
(t)e(en)o(vironmen)o(ts)125 1492 y(for)13 b(a)g(language,)g(but)h(only)e
(minor)g(adv)n(an)o(tage)h(if)g(it)125 1542 y(has)h(t)o(w)o(en)o(t)o(y)m(.)
166 1593 y(The)20 b(criteria)f(are)h(divided)e(in)o(to)h(business)h(and)125
1643 y(tec)o(hnical)g(categories.)36 b(The)20 b(tec)o(hnical)g(category)125
1692 y(fo)q(cuses)12 b(on)g(the)g(issues)h(in)o(v)o(olv)o(ed)d(in)h(the)h
(actual)f(de-)125 1742 y(sign)k(and)g(writing)g(of)g(the)h(system.)23
b(The)15 b(business)125 1792 y(category)d(deals)g(with)f(the)h(broader)h
(issues)f(of)g(man-)125 1842 y(agemen)o(t)g(and)i(mark)o(eting)e(the)j
(system.)125 1964 y Fe(3.1)55 b(Business)19 b(Criteria)125
2043 y Fb(3.1.1)47 b(Standards)125 2121 y Fk(The)20 b(b)q(ene\014ts)h(of)e(a)
g(standard)h(language)f(include)125 2171 y(long)8 b(life,)i(con)o(trolled)f
(ev)o(olution,)h(wide)f(a)o(v)n(ailabilit)o(y)125 2221 y(of)16
b(supp)q(ort)j(pac)o(k)n(ages)e(of)g(all)g(kinds,)g(and)h(ease)g(of)125
2271 y(hiring)13 b(and)g(training)g(sta\013.)166 2322 y(The)g(term)f
(\\standards")h(is)f(used)i(in)e(sev)o(eral)h(dif-)125 2371
y(feren)o(t)h(w)o(a)o(ys.)k(In)c(the)h(strictest)h(sense,)f(a)f(language)p
125 2411 333 2 v 171 2437 a Fi(6)188 2449 y Fh(15)d(y)o(ears)f(if)i(y)o(ou)e
(grandfather)f(C)996 307 y Fk(is)24 b(standard)g(if)f(a)g(recognized)i
(standards)f(b)q(o)q(dy)996 357 y(\(usually)14 b(ANSI)g(in)g(this)g(coun)o
(try\),)g(has)g(published)996 407 y(sp)q(eci\014cations)21
b(for)e(the)h(language.)34 b(While)19 b(there)996 457 y(are)13
b(a)f(n)o(um)o(b)q(er)f(of)g(b)q(ene\014ts)j(of)e(ha)o(ving)f(a)g(published)
996 506 y(standard,)g(I)e(don't)g(think)g(this)h(is)f(an)g(o)o(v)o
(erwhelming)996 556 y(consideration)18 b(for)f(us.)30 b(Of)18
b(our)f(candidate)h(lan)o(u-)996 606 y(gages,)i(only)e(Lisp)h(is)g(a)g
(standard)h(in)e(this)h(sense.)996 656 y(The)13 b(ANSI)f(X3J16)g(committee)e
(for)i(standardizing)996 706 y(C++)20 b(has)g(just)g(formed)f(and)g(it)g
(will)g(b)q(e)h(sev)o(eral)996 756 y(y)o(ears)15 b(b)q(efore)f(they)h
(publish)e(a)h(standard.)1038 807 y(When)23 b(most)f(p)q(eople)h(talk)f(ab)q
(out)h(standards,)996 857 y(they)c(are)f(usually)f(meaning)e(\\widely)i
(accepted",)996 907 y(\\the)c(leader)g(in)f(the)h(\014eld.")18
b(This)12 b(is)h(a)f(more)f(useful)996 956 y(meaning,)f(but)j(no)o(w)e(y)o
(ou)h(ha)o(v)o(e)g(to)g(de\014ne)h(the)g(\014eld.)996 1006
y(In)d(business)h(programming,)c(COBOL)k(is)f(king,)f(but)996
1056 y(RPG,)g(PL/1,)h(and)g(ev)o(en)g(C)g(ha)o(v)o(e)g(wide)g(acceptance.)996
1106 y(In)21 b(scien)o(ti\014c)g(computing,)g(F)m(ortran)f(is)h(the)g(clear)
996 1156 y(leader,)c(with)f(some)f(C)h(and)g(other)h(languages.)24
b(In)996 1205 y(the)14 b(ob)r(ject)g(orien)o(ted)g(comm)o(uni)o(t)o(y)m(,)c
(Smalltalk)g(and)996 1255 y(C++)18 b(are)f(the)g(leaders,)h(with)e(Lisp)h
(and)f(E\016el)h(in)996 1305 y(the)f(second)g(tier.)21 b(In)15
b(the)h(CIM)f(mark)o(et,)f(COBOL)996 1355 y(is)e(the)g(leader)g(for)f(pro)q
(duction)h(systems,)g(nearly)g(all)996 1405 y(the)18 b(academic)e(systems)h
(are)g(in)g(Lisp.)27 b(In)17 b(the)g(AI)996 1454 y(\014eld,)22
b(Lisp)f(is)f(the)h(clear)g(leader)h(with)e(Prolog)g(a)996
1504 y(p)q(opular)c(nic)o(he.)24 b(In)16 b(the)h(hard)f(realtime)e(\014eld,)j
(as-)996 1554 y(sem)o(bly)e(language)g(is)h(still)f(the)i(premier)e(language)
996 1604 y(with)i(some)e(C)i(and)f(P)o(ascal)h(in)f(use.)27
b(The)17 b(MMST)996 1654 y(CIP)e(is)f(a)h(ob)r(ject)g(orien)o(ted)g(CIM)g
(system)f(with)g(AI)996 1704 y(and)d(realtime)e(comp)q(onen)o(ts.)16
b(Whic)o(h)10 b(\014eld's)h(leader)996 1753 y(should)j(w)o(e)g(pic)o(k?)1038
1805 y(What)h(is)h(absolutely)f(critical)h(is)g(that)g(there)h(b)q(e)996
1855 y(enough)11 b(of)g(a)g(user)h(comm)o(unit)o(y)c(\(in)i(some)h(\014eld\))
g(for)996 1904 y(language)16 b(to)h(b)q(e)h(viable.)26 b(Bey)o(ond)17
b(that,)g(there)i(is)996 1954 y(considerable)h(b)q(ene\014t)f(in)g(tec)o
(hnology)f(transfer)h(if)996 2004 y(y)o(ou)14 b(are)g(using)f(the)i(same)d
(language)h(as)h(the)g(\014eld's)996 2054 y(researc)o(hers)j(and)d(ma)r(jor)e
(dev)o(elop)q(ers.)996 2170 y Fb(3.1.2)48 b(Ev)o(olution)996
2250 y Fk(The)16 b(CIP)f(system)h(is)f(going)f(to)h(ha)o(v)o(e)g(b)q(oth)g(a)
g(long)996 2300 y(dev)o(elopmen)o(t)i(cycle)h(and)f(a)g(long)g(life.)28
b(In)17 b(select-)996 2350 y(ing)d(a)g(language,)g(w)o(e)h(m)o(ust)e
(understand)j(b)q(oth)f(the)996 2399 y(curren)o(t)d(state)f(and)e(the)i(exp)q
(ected)h(ev)o(olution.)k(Ev)o(o-)996 2449 y(lution)d(can)h(b)q(oth)g(help)g
(and)g(h)o(urt.)135 2573 y Fg(c)125 2574 y Ff(\015)f Fg(Cop)o(yrigh)o(t)h
(1990)g(Douglas)h(Johnson)1077 b Fk(3)p eop
%%Page: 4 4
bop 166 307 a Fk(It)16 b(helps)g(when)g(the)g(ev)o(olution)f(is)g(timely)m(,)
e(com-)125 357 y(patible,)27 b(or)e(\\addable".)52 b(An)26
b(example)e(of)h(an)125 407 y(addable)10 b(ev)o(olution)g(migh)o(t)f(b)q(e)j
(a)e(new)i(pro)q(cess)g(sim-)125 457 y(ulator)e(or)i(h)o(yp)q(ertext)g(pac)o
(k)n(age)f(that)h(can)f(b)q(e)h(added)125 506 y(on)j(top)g(of)g(CIP)g(to)h
(giv)o(e)f(new)g(capabilit)o(y)m(.)21 b(An)16 b(ex-)125 556
y(ample)h(of)h(a)h(compatible)e(ev)o(olution)h(w)o(ould)g(b)q(e)i(a)125
606 y(p)q(erformance)e(impro)o(v)o(emen)o(t)d(or)k(a)f(more)f(reliable)125
656 y(release)k(of)e(a)g(database.)36 b(Other)21 b(forms)e(of)g(help-)125
706 y(ful)e(ev)o(olution)f(include)i(ric)o(her)h(and)f(more)f(p)q(o)o(w)o
(er-)125 756 y(ful)e(to)q(ols,)h(b)q(etter)h(supp)q(ort)g(pac)o(k)n(ages,)f
(and)g(ric)o(her)125 805 y(class)c(libraries.)18 b(In)12 b(all)f(cases,)j
(the)f(ev)o(olution)f(m)o(ust)125 855 y(b)q(e)i(there)h(when)g(w)o(e)f(need)h
(it.)166 905 y(Ev)o(olution)20 b(can)i(h)o(urt)g(when)g(it)g(is)f(incompati-)
125 955 y(ble)e(ev)o(olution)f(\(esp)q(ecially)h(of)g(things)g(em)o(b)q
(edded)125 1005 y(deeply)13 b(in)f(the)h(system\))f(or)h(ev)o(olution)f(that)
g(o)q(ccurs)125 1054 y(to)q(o)h(late.)166 1104 y(F)m(or)g(example,)f(the)i
(ANSI)g(Common)d(Lisp)i(com-)125 1154 y(mittee)j(rede\014ned)i(c)o(haracter)h
(handling)c(in)i(a)f(w)o(a)o(y)125 1204 y(that)d(w)o(as)g(b)q(oth)h(fundamen)
o(tal)d(and)i(incompatible.)125 1254 y(The)d(ANSI)g(C)f(committee)f(did)h
(similar)e(things)j(with)125 1303 y(argumen)o(t)f(passing.)17
b(Multiple)10 b(inheritance)i(w)o(as)e(in)125 1353 y(Smalltal)o(k)f(release)k
(2.3)d(and)i(remo)o(v)o(ed)f(from)e(2.5.)17 b(It)125 1403 y(is)j(to)q(o)g(m)o
(uc)o(h)f(to)i(exp)q(ect)h(that)e(the)h(ANSI)g(C++)125 1453
y(commi)o(ttee)g(will)g(refrain.)44 b(In)23 b(all)e(fairness,)k(the)125
1503 y(ANSI)d(c)o(hanges)h(are)f(long)f(term)h(impro)o(v)o(em)o(en)o(ts.)125
1553 y(Both)9 b(ANSI)h(C)f(and)g(ANSI)h(Common)c(Lisp)j(are)h(b)q(et-)125
1602 y(ter)h(languages)g(than)g(the)h(de)f(facto)g(standards)h(they)125
1652 y(started)j(with.)166 1702 y(In)e(some)g(cases,)h(where)g(the)g(ev)o
(olving)e(feature)i(is)125 1752 y(not)h(engineered)j(in)o(to)d(the)h(CIP)m(,)
f(w)o(e)h(can)g(tak)o(e)g(ad-)125 1802 y(v)n(an)o(tage)f(of)h(c)o(hanges)h
(as)f(so)q(on)h(as)f(they)h(are)g(a)o(v)n(ail-)125 1851 y(able.)g(W)m(e)11
b(can)h(shift)g(to)g(a)g(new)g(dev)o(elopmen)o(t)f(en)o(vi-)125
1901 y(ronmen)o(t)16 b(whenev)o(er)k(the)e(pro)q(ductivit)o(y)g(impro)o(v)o
(e-)125 1951 y(men)o(ts)13 b(justify)g(the)i(training)d(costs.)166
2001 y(The)18 b(timing)e(is)h(v)o(ery)h(imp)q(ortan)o(t)e(to)i(us.)30
b(Con-)125 2051 y(sider)18 b(execption)h(handling.)29 b(W)m(e)18
b(need)h(to)f(de\014ne)125 2100 y(an)h(exception)g(handling)f(sc)o(heme)i(b)q
(efore)g(w)o(e)f(b)q(e-)125 2150 y(gin)12 b(co)q(ding)h(CIP)h(and)f(that)g
(sc)o(heme)h(will)e(get)h(built)125 2200 y(in)o(to)f(CIP)h(p)q(erv)n(asiv)o
(ely)m(.)k(If)12 b(the)h(language)f(do)q(es)i(not)125 2250
y(pro)o(vide)h(exception)i(handling,)e(w)o(e)i(need)g(to)f(build)125
2300 y(it.)23 b(Later)16 b(ev)o(olution)f(do)q(es)h(us)g(no)g(go)q(o)q(d)f
(and)h(ma)o(y)125 2350 y(h)o(urt)e(if)f(our)h(sc)o(heme)g(is)g(non-standard.)
k(All)13 b(of)g(the)125 2399 y(k)o(ey)i(primitiv)o(es)e(m)o(ust)i(b)q(e)h
(stable)f(b)q(efore)h(w)o(e)g(start)125 2449 y(co)q(ding)d(in)h(Jan)o(uary)f
(of)h('91.)1038 307 y(In)i(one)g(area)g(w)o(e)g(are)h(coun)o(ting)e(on)h
(compatible)996 357 y(ev)o(olution,)10 b(i.e.)g(impro)o(v)o(emen)o(ts)f(b)o
(y)i(a)g(selected)h(v)o(en-)996 407 y(dor.)17 b(This)11 b(will)e(b)q(e)j(v)o
(ery)f(imp)q(ortan)o(t)e(to)i(us)g(if)f(w)o(e)h(se-)996 457
y(lect)j(an)f(ob)r(ject)h(orien)o(ted)g(database)f(b)q(ecause)i(their)996
506 y(curren)o(t)h(bac)o(k)o(end)f(database)f(services)i(are)f(not)f(y)o(et)
996 556 y(robust)h(enough.)1038 606 y(The)g(rate)h(of)e(ev)o(olution)g(is)h
(driv)o(en)g(b)o(y)g(b)q(oth)g(the)996 656 y(size)i(of)e(the)h(mark)o(et)e
(and)i(the)g(di\016cult)o(y)e(of)h(dev)o(el-)996 706 y(opmen)o(t.)40
b(The)22 b(larger)f(the)i(mark)o(et,)e(the)h(larger)996 756
y(the)13 b(incen)o(tiv)o(e)f(to)g(dev)o(elop)g(an)f(impro)o(v)o(emen)o(t.)k
(The)996 805 y(harder)j(it)f(is)g(to)h(dev)o(elop)f(the)h(impro)o(v)o(emen)o
(t,)d(the)996 855 y(more)e(the)i(cost)f(\(see)h(section)g(3.1.4\).)1038
905 y(While)h(this)h(can)h(b)q(e)g(view)o(ed)f(as)g(a)g(simple)f(R)o(OI)996
955 y(problem,)k(the)g(dynamics)e(of)h(ev)o(olution)g(seem)h(to)996
1005 y(b)q(e)c(more)e(complex)g(than)h(that.)22 b(If)15 b(the)h(ev)o
(olution-)996 1054 y(ary)k(pro)q(cess)i(w)o(ere)f(dominated)d(b)o(y)i(mark)o
(et)f(size,)996 1104 y(then)10 b(the)h(COBOL/IBM)f(en)o(vironmen)o(ts)f(w)o
(ould)g(b)q(e)996 1154 y(ev)o(olving)k(ten)h(times)f(faster)h(than)g(an)o(y)f
(other)i(en)o(vi-)996 1204 y(ronmen)o(t.)i(That's)d(not)g(what's)g(going)e
(on.)1038 1254 y(F)m(or)g(eac)o(h)h(of)f(the)h(tec)o(hnical)f(criteria,)h
(I'll)e(b)q(e)i(dis-)996 1303 y(cussing)i(the)f(exp)q(ected)i(ev)o(olution)d
(and)g(its)h(impact)996 1353 y(on)g(us.)996 1460 y Fb(3.1.3)48
b(Customer)15 b(Demand)996 1537 y Fk(This)k(is)g(an)g(imp)q(ortan)o(t)e
(issue.)35 b(If)19 b(the)g(customer)996 1586 y(needs)g(a)e(particular)g
(language,)g(w)o(e)g(m)o(ust)f(do)h(our)996 1636 y(b)q(est)g(to)f(meet)f
(that)h(need.)25 b(Ho)o(w)o(ev)o(er,)16 b(that)g(raises)996
1686 y(the)22 b(issue)f(of)f(what)h(w)o(e)g(are)g(building,)g(who)f(our)996
1736 y(customer)d(is,)g(and)g(what)g(that)g(customer's)g(needs)996
1786 y(are.)g(Our)10 b(o\016cial)e(customer)h(do)q(esn't)h(seem)f(to)h(ha)o
(v)o(e)996 1836 y(strong)17 b(preferences.)28 b(The)17 b(only)f(languages)g
(men-)996 1885 y(tioned)10 b(in)f(the)i(con)o(tract)f(are)g(C)g(and)g(Lisp.)
16 b(W)m(e)9 b(need)996 1935 y(to)k(tak)o(e)f(a)g(broader)h(view)g(of)f
(\\customer")g(for)g(help.)1038 1985 y(I)h(susp)q(ect)j(this)e(is)g(one)g
(area)f(where)i(ev)o(ery)o(one)g(in)996 2035 y(the)c(language)f(debate)h(is)g
(op)q(erating)f(with)g(di\013eren)o(t)996 2085 y(assumptions.)24
b(Let's)16 b(try)g(out)g(the)h(v)n(arious)e(p)q(ossi-)996 2134
y(bilities:)1026 2219 y(1.)20 b(If)d(w)o(e)g(are)h(building)d(turn)j(k)o(ey)f
(systems,)h(the)1079 2269 y(customer)24 b(cares)g(ab)q(out)f(what)h(the)g
(system)1079 2319 y(do)q(es,)14 b(language)f(is)h(secondary)m(.)1026
2399 y(2.)20 b(If)g(w)o(e)h(are)g(building)e(an)h(exp)q(erimen)o(tal)g(sys-)
1079 2449 y(tem)f(to)g(test)i(concepts)g(and)e(ideas,)i(it's)e(the)135
2573 y Fg(c)125 2574 y Ff(\015)13 b Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h
(Johnson)1077 b Fk(4)p eop
%%Page: 5 5
bop 208 307 a Fk(ideas)15 b(and)g(exp)q(erience)i(that)e(are)h(imp)q(ortan)o
(t.)208 357 y(The)h(system)f(will)f(probably)h(need)i(to)e(b)q(e)h(re-)208
407 y(engineered)e(for)e(pro)q(duction)i(an)o(yw)o(a)o(y)m(.)155
499 y(3.)20 b(If)15 b(w)o(e)h(are)h(building)d(a)i(collection)g(of)f(comp)q
(o-)208 548 y(nen)o(ts)20 b(to)g(b)q(e)h(used)f(in)g(other)g(systems,)i(lan-)
208 598 y(guage)c(is)g(crucial)g(when)h(those)g(comp)q(onen)o(ts)208
648 y(are)i(to)g(b)q(e)h(compiled)d(and)i(link)o(ed)g(in)o(to)f(the)208
698 y(existing)f(system)g(or)h(when)g(they)g(are)h(to)e(b)q(e)208
748 y(main)o(tained)11 b(as)j(part)g(of)f(that)h(system)825
733 y Fj(7)155 840 y Fk(4.)20 b(If)d(w)o(e)h(are)h(building)d(a)i(framew)o
(ork)e(for)i(CIM)208 889 y(that)25 b(is)h(to)g(in)o(tegrate)g(a)g(v)n(ariet)o
(y)f(of)g(com-)208 939 y(p)q(onen)o(ts)20 b(from)e(man)o(y)g(sources,)23
b(it's)c(the)h(in-)208 989 y(terfaces)f(\(particularly)f(the)h(database\))g
(that)208 1039 y(matters.)43 b(The)23 b(framew)o(ork)e(m)o(ust)g(b)q(e)j
(lan-)208 1089 y(guage)13 b(indep)q(enden)o(t.)166 1189 y(As)i(part)g(of)e
(this)i(discussion,)f(w)o(e)h(need)h(to)e(iden-)125 1239 y(tify)f(whic)o(h)g
(of)h(these)h(w)o(e)f(are)h(doing.)i(My)d(assump-)125 1288
y(tion)c(is)i(that)f(w)o(e)h(are)g(primarily)d(doing)i(item)f(2)h(with)125
1338 y(hop)q(es)j(that)g(w)o(e)g(will)f(accomplish)f(items)h(4)h(and)f(1.)166
1390 y(If)f(this)h(isn't)f(correct,)i(w)o(e'll)e(need)h(to)f(adjust)h(pri-)
125 1440 y(orities)g(in)g(sev)o(eral)h(areas.)k(While)13 b(all)f(of)h(the)h
(ab)q(o)o(v)o(e)125 1490 y(w)o(ould)8 b(b)q(e)j(desirable)f(outcomes,)f(w)o
(e)h(can't)f(attempt)125 1540 y(to)j(do)h(them)f(all)g(without)h(a)g(risk)g
(that,)f(in)h(the)h(end,)125 1590 y(w)o(e)g(will)e(ha)o(v)o(e)i(done)g(none)g
(of)f(them.)125 1709 y Fb(3.1.4)47 b(Pro)q(ductivit)o(y)125
1790 y Fk(I)13 b(w)o(asn't)g(sure)i(whether)f(this)g(should)f(b)q(e)h(a)f
(tec)o(hni-)125 1840 y(cal)c(issue)i(or)f(a)f(business)i(issue.)18
b(Pro)q(ductivit)o(y)10 b(is)f(of-)125 1890 y(ten)i(cited)g(as)f(a)g(reason)h
(for)f(selecting)i(a)e(language.)16 b(I)125 1939 y(think)11
b(ev)o(ery)o(one)h(agrees)h(that)f(some)e(languages)h(are)125
1989 y(more)16 b(pro)q(ductiv)o(e)h(than)g(others.)29 b(Unfortunately)m(,)125
2039 y(no)15 b(one)h(can)f(agree)i(on)e(ho)o(w)g(m)o(uc)o(h)g(more)f(pro)q
(duc-)125 2089 y(tiv)o(e,)f(th)o(us)i(no)e(one)i(can)f(agree)h(on)f(ho)o(w)f
(imp)q(ortan)o(t)125 2139 y(that)g(is.)p 125 2174 333 2 v 171
2201 a Fi(7)188 2213 y Fh(\\Language")5 b(in)j(this)g(case)f(means)g(more)g
(than)g(just)g(Lisp)125 2252 y(or)13 b(C++.)25 b(Unless)14
b(the)f(class)h(libraries)e(are)h(also)g(compati-)125 2291
y(ble,)k(the)f(comp)q(onen)o(t)e(ma)o(y)i(b)q(e)g(as)h(hard)e(to)i(in)o
(tegrate)d(or)125 2331 y(main)o(tain)9 b(as)j(if)f(it)h(w)o(as)g(written)f
(in)h(Sw)o(ahilli.)j(I)d(can't)e(o)o(v)o(er-)125 2370 y(emphasize)k(this.)31
b(Prop)q(erly)15 b(designed)g(OO)j(applications)125 2410 y(are)8
b(primarily)f(written)i(in)g(the)f(class)h(libraries,)f(not)g(the)h(lan-)125
2449 y(guage)h(primitiv)o(es.)1038 307 y Fk(F)m(or)19 b(one)i(example,)e
(consider)i(t)o(w)o(o)f(debuggers.)996 357 y(The)14 b(GDB)f(debugger)i(is)e
(written)h(in)f(C)h(for)f(C)g(run-)996 407 y(ning)21 b(on)h(Unix.)41
b(It)22 b(is)g(p)q(o)o(w)o(erful,)h(widely)e(used,)996 457
y(and)14 b(written)h(in)f(36,953)f(lines)h(for)g(the)h(curren)o(t)h(re-)996
506 y(lease.)j(The)14 b(equiv)n(alen)o(t)f(functionalit)o(y)g(in)g(Lisp)h
(for)996 556 y(Lisp)j(running)g(on)g(the)g(Explorer)h(is)f(10,396)e(lines.)
996 606 y(Neither)d(system)f(is)g(particularly)f(ob)r(ject)i(orien)o(ted)1807
591 y Fj(8)996 656 y Fk(Since)i(lines-p)q(er-man-da)o(y)e(are)i(roughly)e
(constan)o(t,)996 706 y(it's)j(reasonable)h(to)g(think)f(the)h(Lisp)g(implem)
o(en)o(ta-)996 756 y(tion)j(w)o(ould)f(b)q(e)i(ab)q(out)f(a)g(third)g(the)h
(cost)g(of)f(the)996 805 y(C.)1038 858 y(W)m(e)h(can)h(build)f(CIP)g(in)h(an)
o(y)f(language.)37 b(The)996 908 y(pressure)17 b(p)q(oin)o(t)d(will)f(b)q(e)j
(the)f(functionalit)o(y)e(of)h(the)996 958 y(system.)j(As)11
b(part)g(of)f(the)h(detailed)g(ev)n(alutions)e(o)o(v)o(er)996
1008 y(the)19 b(next)g(sev)o(eral)g(mon)o(ths,)e(w)o(e)i(will)e(try)h(to)g
(esti-)996 1057 y(mate)d(the)i(tradeo\013)g(of)e(language)h(vs.)25
b(functional-)996 1107 y(it)o(y)m(.)996 1231 y Fb(3.1.5)48
b(T)l(raining)996 1314 y Fk(T)m(raining)10 b(considerations)i(m)o(ust)f
(include)h(b)q(oth)g(ini-)996 1363 y(tial)i(dev)o(elopmen)o(t)h(and)g(long)f
(term)h(main)o(tenance.)996 1413 y(No)o(w,)i(and)g(for)g(at)g(least)g(the)h
(next)g(sev)o(eral)f(y)o(ears,)996 1463 y(the)e(ma)r(jor)d(issue)i(will)f(b)q
(e)h(\014nding)f(or)h(training)f(ob-)996 1513 y(ject)i(orien)o(ted)f
(programmers.)i(The)e(language)f(will)996 1563 y(b)q(e)20 b(secondary)m(.)35
b(Y)m(ou)19 b(can't)g(just)h(tak)o(e)f(a)g(C)h(pro-)996 1612
y(grammer)13 b(and)i(hand)g(him)e(a)i(C++)h(en)o(vironmen)o(t.)996
1662 y(What)e(y)o(ou)f(get)h(will)f(b)q(e)h(C.)1038 1715 y(When)f(a)g
(skilled)g(OO)h(programmer)d(is)i(found)f(or)996 1765 y(trained,)g(the)h
(next)g(ma)r(jor)d(training)h(issue)i(is)f(learn-)996 1815
y(ing)17 b(the)i(ob)r(jects)g(used)f(in)g(the)g(en)o(vironmen)o(t)f(and)996
1865 y(application.)f(The)d(syn)o(tax)f(of)g(the)h(language)f(is)g(the)996
1914 y(least)i(of)g(the)g(problems)1377 1899 y Fj(9)1395 1914
y Fk(.)1038 1967 y(This)32 b(is)h(considerably)f(di\013eren)o(t)i(from)d(the)
996 2017 y(\\go)q(o)q(d)16 b(old)g(da)o(ys")g(when)h(programmers)d(built)i
(di-)996 2067 y(rectly)f(using)e(the)h(lo)o(w)o(est)g(lev)o(els)f(on)h(the)g
(language.)996 2117 y(Then)20 b(learning)f(the)g(language)g(w)o(as)g(a)g
(dominan)o(t)996 2166 y(part)h(of)f(the)h(training)e(problem.)34
b(With)19 b(the)h(ad-)p 996 2213 V 1042 2240 a Fi(8)1060 2252
y Fh(I)12 b(c)o(hose)f(this)g(example)f(largely)g(b)q(ecause)g(it)i(w)o(as)h
(a)f(rea-)996 2291 y(sonably)j(comparable,)g(\\real")g(and)h(complex)f(one)h
(that)g(I)996 2331 y(could)7 b(get)h(line)g(coun)o(ts)f(on.)14
b(I'll)7 b(b)q(e)i(happ)o(y)d(to)j(collect)d(others.)1042 2359
y Fi(9)1060 2370 y Fh(Lisp)20 b(and)f(Smalltalk)f(b)q(oth)h(ha)o(v)o(e)g
(trivial)g(syn)o(taxes.)996 2410 y(C++'s)c(is)f(more)f(complex,)f(but)h(can)g
(b)q(e)g(understo)q(o)q(d)e(in)j(a)996 2449 y(w)o(eek)e(or)f(so.)135
2573 y Fg(c)125 2574 y Ff(\015)i Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h
(Johnson)1077 b Fk(5)p eop
%%Page: 6 6
bop 125 307 a Fk(v)o(en)o(t)18 b(of)g(ob)r(ject)i(orien)o(ted)f(tec)o
(hniques,)h(program-)125 357 y(mers)25 b(build)g(with)g(m)o(uc)o(h)f(more)h
(abstract)i(\(and)125 407 y(more)12 b(p)q(o)o(w)o(erful\))i(lev)o(els.)166
457 y(F)m(or)j(the)h(initial)e(dev)o(elopmen)o(t,)g(a)i(surv)o(ey)g(indi-)125
507 y(cates)j(that)g(Smalltalk)d(is)i(the)h(b)q(est)h(kno)o(wn)f(lan-)125
557 y(guage)e(in)g(the)h(CIP)g(team)563 542 y Fj(10)597 557
y Fk(.)36 b(Lisp)19 b(is)h(next)g(and)125 606 y(there)f(is)e(v)o(ery)h
(little)f(exp)q(erience)j(with)e(C++,)h(al-)125 656 y(though)13
b(a)h(lot)f(with)h(C.)166 706 y(Long)h(term,)f(let's)h(assume)g(the)h
(program)e(has)h(a)125 756 y(20\045)e(ann)o(ual)h(turno)o(v)o(er)h(rate)g
(and)g(a)f(\\bad")g(c)o(hoice)125 806 y(of)e(language)g(adds)i(three)g(mon)o
(ths)e(to)h(the)h(training)125 856 y(time.)h(That)10 b(will)e(increase)k(the)
e(main)o(tenance)g(costs)125 906 y(b)o(y)j(5\045.)18 b(This)13
b(do)q(es)i(not)f(app)q(ear)g(signi\014can)o(t.)125 1024 y
Fe(3.2)55 b(T)-5 b(ec)n(hnical)21 b(Issues)125 1101 y Fb(3.2.1)47
b(Supp)q(ort)14 b(P)o(ac)o(k)m(ages)125 1179 y Fk(One)c(of)g(the)h(primary)d
(issues)j(in)f(language)f(selection)125 1228 y(is)h(the)i(supp)q(ort)f(pac)o
(k)n(ages)g(a)o(v)n(ailable)e(for)h(it.)17 b(This)11 b(is)125
1278 y(\\o\013)g(the)i(shelf)s(")g(soft)o(w)o(are)f(that)g(w)o(e)h(will)d
(include)j(as)125 1328 y(part)18 b(of)f(the)i(application)e(p)q(erforming)g
(some)g(ser-)125 1378 y(vice)f(for)g(the)h(application.)24
b(Basically)m(,)15 b(they)i(let)f(a)125 1428 y(programmer)d(fo)q(cus)j(on)g
(the)g(p)q(ositiv)o(e)g(di\013eren)o(tia-)125 1477 y(tors)h(in)g(the)h
(application)e(while)h(letting)g(the)h(sup-)125 1527 y(p)q(ort)i(pac)o(k)n
(ages)g(handle)g(the)g(necessary)m(,)j(but)d(p)q(e-)125 1577
y(ripheral)13 b(issues.)125 1687 y Fb(Databases)40 b Fk(In)52
b(most)f(applications,)60 b(the)125 1737 y(database)18 b(w)o(ould)e(not)i(b)q
(e)g(as)g(closely)g(tied)g(to)f(the)125 1787 y(language)f(as)i(it)f(is)g(for)
g(us.)29 b(Our)19 b(ob)r(ject-orien)o(ted)125 1836 y(approac)o(h)j(means)g
(that)h(w)o(e)g(m)o(ust)f(ha)o(v)o(e)h(a)f(v)o(ery)125 1886
y(close)17 b(tie)h(b)q(et)o(w)o(een)h(the)f(in-memory)c(ob)r(jects)19
b(and)125 1936 y(the)c(underlying)f(data)g(store.)21 b(F)m(or)14
b(example,)f(Zeit-)125 1986 y(geist)k(only)g(w)o(orks)h(with)f(C++)i(and)e
(Lisp.)29 b(Gem-)125 2036 y(stone)13 b(only)f(w)o(orks)h(w)o(ell)f(with)h
(Smalltalk,)c(Itasca)919 2021 y Fj(11)125 2085 y Fk(with)15
b(Lisp.)23 b(F)m(urthermore,)16 b(eac)o(h)g(database)g(has)g(a)125
2135 y(di\013eren)o(t)i(set)g(of)f(features)i(and)e(none)h(has)g(all)e(the)
125 2185 y(features)f(w)o(e)f(require.)166 2235 y(Getting)h(the)g(righ)o(t)g
(database)g(and)g(data)f(mo)q(del)125 2285 y(is)j(crucial)g(to)g(success)j
(of)d(the)h(program.)26 b(W)m(e)17 b(are)125 2335 y(activ)o(ely)e(in)o(v)o
(estigating)g(it)h(and)h(the)g(issues)g(are)g(at)p 125 2371
333 2 v 156 2398 a Fi(10)188 2410 y Fh(This)12 b(is)f(a)g(result)g(of)g(the)g
(protot)o(ypin)o(g)e(e\013ort.)156 2437 y Fi(11)188 2449 y
Fh(The)j(commercia)o(l)d(v)o(ersion)h(of)h(Orion)g(from)f(MCC.)996
307 y Fk(least)17 b(as)g(complex)e(as)h(the)h(language)f(issues.)27
b(But)996 357 y(for)12 b(no)o(w,)f(I)h(b)q(eliev)o(e)g(database)h
(considerations)f(w)o(ell)996 407 y(migh)o(t)e(driv)o(e)i(the)g(language)f
(selection)h(rather)g(than)996 457 y(the)j(other)f(w)o(a)o(y)f(around.)1038
569 y Fb(Ev)o(olution)38 b Fk(The)28 b(ev)o(olution)f(here)h(is)g(fairly)996
618 y(clear.)37 b(The)20 b(relational)f(databases)h(will)f(b)q(ecome)996
668 y(more)d(ob)r(ject)h(orien)o(ted)g(and)f(the)i(ob)r(ject)f(orien)o(ted)
996 718 y(databases)22 b(will)e(mature)h(in)o(to)g(usable)h(pro)q(ducts.)996
768 y(The)d(rate)g(of)f(ev)o(olution)f(is)h(an)g(in)o(teresting)h(issue.)996
818 y(It)d(to)q(ok)g(ten)h(y)o(ears)f(for)g(the)h(relations)f(to)g(mature,)
996 867 y(it)c(will)e(probably)h(tak)o(e)g(the)i(same)d(for)i(the)g(OODBs.)
996 917 y(In)h(the)h(mean)e(time,)f(there)k(will)c(b)q(e)j(a)f(lot)f(of)g
(uncer-)996 967 y(tain)o(t)o(y)17 b(in)g(the)g(mark)o(et)g(as)g(companies)f
(come)h(and)996 1017 y(go.)29 b(If)18 b(w)o(e)g(c)o(ho)q(ose)g(an)g(OODB,)g
(w)o(e)g(will)e(need)j(to)996 1067 y(protect)c(ourselv)o(es)g(against)d
(this.)18 b(Approac)o(hes)d(in-)996 1116 y(clude)k(qualifying)e(m)o(ultiple)f
(v)o(endors)j(and)g(a)o(v)o(oid-)996 1166 y(ance)c(of)e(v)o(endor)h(sp)q
(eci\014c)i(features.)996 1278 y Fb(User)22 b(In)o(terface)f(Builders)38
b Fk(These)22 b(are)e(to)q(ols)996 1328 y(that)c(sp)q(eed)i(the)e(dev)o
(elopmen)o(t)f(of)g(graphical)g(user)996 1378 y(in)o(terfaces.)27
b(This)16 b(will)f(b)q(e)i(v)o(ery)f(imp)q(ortan)o(t)f(to)h(us)996
1428 y(b)q(ecause)j(of)d(the)h(h)o(uge)f(n)o(um)o(b)q(er)g(of)g(in)o
(terfaces)i(the)996 1477 y(CIP)c(will)f(require.)1038 1589
y Fb(Ev)o(olution)38 b Fk(This)15 b(is)g(an)g(area)h(where)g(there)h(is)996
1639 y(a)g(great)g(deal)g(of)f(activit)o(y)h(in)f(b)q(oth)h(industry)h(and)
996 1689 y(univ)o(ersities.)25 b(While)15 b(there)i(are)g(wider)f(v)n(ariet)o
(y)f(of)996 1739 y(to)q(ols)c(for)f(C++,)h(the)h(ones)f(for)g(Lisp)f(and)h
(Smalltalk)996 1789 y(are)k(m)o(uc)o(h)d(more)h(adv)n(anced.)996
1900 y Fb(Class)24 b(Libraries)38 b Fk(Class)21 b(libraries)f(are)h(collec-)
996 1950 y(tions)e(of)f(prede\014ned)j(ob)r(jects)f(that)f(can)g(b)q(e)h
(used)996 2000 y(either)c(to)f(build)f(application)g(ob)r(jects)i(or)f(just)h
(\\as)996 2050 y(is".)39 b(They)21 b(range)g(from)f(simple,)g(lo)o(w)g(lev)o
(el)h(ob-)996 2100 y(jects)d(suc)o(h)f(as)g(hash)g(tables,)g(lists,)g(or)g
(time)e(k)o(eep-)996 2150 y(ing)10 b(services,)i(through)e(graphics)g(pac)o
(k)n(ages)g(lik)o(e)g(In-)996 2199 y(terviews)18 b(or)e(CLX/CLUE/CLIO,)h(to)f
(full)f(blo)o(wn)996 2249 y(spreadsheets,)32 b(h)o(yp)q(ertext,)f(or)26
b(exp)q(ert)i(systems)996 2299 y(shells.)j(The)18 b(ric)o(her)h(class)f
(libraries)g(often)g(repre-)996 2349 y(sen)o(t)d(man)o(y)d(man-y)o(ears)h(of)
g(w)o(ork.)1038 2399 y(This)h(is)h(one)g(area)g(where)h(more)e(is)h(b)q
(etter.)22 b(The)996 2449 y(ric)o(her)11 b(the)h(class)e(library)g(a)o(v)n
(ailable,)e(the)k(less)f(\\scaf-)135 2573 y Fg(c)125 2574 y
Ff(\015)i Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h(Johnson)1077
b Fk(6)p eop
%%Page: 7 7
bop 125 307 a Fk(folding")11 b(w)o(e)i(will)f(ha)o(v)o(e)h(to)g(build)f(to)h
(supp)q(ort)h(CIP)m(.)125 357 y(Ma)o(yb)q(e)19 b(a)h(b)q(etter)h(analogy)d
(is)i(hardw)o(are)g(design.)125 407 y(The)12 b(more)e(standard)j(parts)f(a)o
(v)n(ailable)d(in)j(the)g(TTL)125 457 y(datab)q(o)q(ok,)j(the)i(b)q(etter)h
(the)f(c)o(hance)g(the)g(designer)125 506 y(will)9 b(b)q(e)i(able)f(to)g
(\014nd)h(exactly)g(the)g(part)f(to)h(meet)f(his)125 556 y(needs.)29
b(F)m(urthermore,)18 b(a)f(designer)h(with)f(a)g(VLSI)125 606
y(parts)12 b(catalog)g(will)f(b)q(e)i(far)e(more)h(pro)q(ductiv)o(e)h(than)
125 656 y(one)e(with)g(only)f(SSI.)h(I)g(view)g(this)g(as)g(a)g(ma)r(jor)e
(issue.)166 706 y(In)k(this)h(one)g(area,)f(Smalltalk)d(stands)k(head)g(and)
125 756 y(shoulders)i(ab)q(o)o(v)o(e)g(the)h(other)g(t)o(w)o(o)e(candidate)i
(lan-)125 805 y(guages.)29 b(Ov)o(er)18 b(its)g(\014fteen)g(y)o(ear)g
(existance,)h(class)125 855 y(libraries)25 b(ha)o(v)o(e)g(b)q(een)i(written)f
(for)f(almost)e(an)o(y)125 905 y(imaginabl)o(e)17 b(purp)q(ose.)34
b(These)20 b(include)f(ric)o(h)g(sets)125 955 y(of)i(basic)g(data)h(t)o(yp)q
(es)g(and)f(structures,)26 b(extensi-)125 1005 y(ble)c(user)h(in)o(terface)g
(to)q(ols)f(suc)o(h)h(as)f(editors)h(and)125 1054 y(bro)o(wsers,)d(database)f
(in)o(terfaces,)h(and)e(high)g(lev)o(el)125 1104 y(pac)o(k)n(ages)12
b(suc)o(h)i(as)f(h)o(yp)q(ertext,)h(spreadsheets,)h(and)125
1154 y(h)o(yp)q(ertext.)29 b(F)m(urthermore,)17 b(b)q(ecause)i(of)e(the)h
(con-)125 1204 y(sisten)o(t)j(nature)h(of)e(Smalltalk')o(s)f(ob)r(ject)i
(orien)o(ted)125 1254 y(paradigm,)12 b(the)k(pac)o(k)n(ages)f(tend)h(to)g(w)o
(ork)e(w)o(ell)h(to-)125 1303 y(gether.)166 1353 y(Lisp)h(also)g(has)h(a)f
(broad)g(set)h(of)f(libraries)g(a)o(v)n(ail-)125 1403 y(able.)23
b(The)17 b(basic)f(datat)o(yp)q(es)g(and)g(structures)i(are)125
1453 y(somewhat)g(b)q(etter)j(than)f(Smalltalk.)32 b(Commeri-)125
1503 y(cal)15 b(Lisp)h(en)o(vironmen)o(ts)f(include)h(extensible)h(user)125
1553 y(in)o(terface)j(to)q(ols,)g(Harlequin)f(Common)d(Lisp)k(has)125
1602 y(database)i(in)o(terfaces)h(and)g(h)o(yp)q(ertext)g(pac)o(k)n(ages.)125
1652 y(The)18 b(only)f(problem)g(is)g(that)h(the)h(di\013eren)o(t)g(pac)o(k-)
125 1702 y(ages)14 b(don't)g(tend)i(to)e(b)q(e)h(as)g(easy)g(to)f(in)o
(tegrate)h(b)q(e-)125 1752 y(cause)e(of)e(the)i(broader)f(range)g(of)g
(implemen)o(tatio)o(ns)125 1802 y(p)q(ossible.)166 1851 y(Libraries)20
b(for)f(C++)h(are)f(just)h(no)o(w)f(b)q(ecoming)125 1901 y(a)o(v)n(ailable.)
37 b(The)22 b(National)d(Institute)j(of)f(Health)125 1951 y(has)12
b(a)h(pac)o(k)n(age)f(that)h(duplicates)g(m)o(uc)o(h)e(of)h(the)i(lo)o(w)125
2001 y(lev)o(el)c(Smalltalk)d(data)j(structures)j(and)d(t)o(yp)q(es.)18
b(TI's)125 2051 y(COOL)k(library)f(tends)i(to)f(duplicate)g(the)h(Com-)125
2100 y(mon)17 b(Lisp)i(basic)g(t)o(yp)q(es)h(and)f(structures)j(as)d(w)o(ell)
125 2150 y(as)9 b(adding)g(exception)i(handling)d(and)i(macros.)15
b(The)125 2200 y(In)o(terviews)c(library)f(pro)o(vides)h(basic)g(user)h(in)o
(terface)125 2250 y(features,)18 b(but)f(nothing)g(as)g(high)f(lev)o(el)h(as)
g(editors)125 2300 y(and)22 b(bro)o(wsers.)44 b(Most)23 b(of)e(the)i(ob)r
(ject)g(orien)o(ted)125 2350 y(databases)d(ha)o(v)o(e)g(C++)g(in)o(terfaces)h
(and)f(most)e(of)125 2399 y(the)12 b(relational)f(databases)i(ha)o(v)o(e)f(C)
g(or)g(C++)h(in)o(ter-)125 2449 y(faces.)21 b(I)15 b(don't)f(kno)o(w)h(of)f
(an)o(y)g(high)g(lev)o(el)h(libraries)996 307 y(pro)o(viding)e(things)h(lik)o
(e)f(h)o(yp)q(ertext.)1038 358 y(Unfortunately)m(,)d(the)i(C++)g(libraries)f
(tend)h(to)f(b)q(e)996 407 y(incompatible)19 b(and)j(hard)f(to)g(in)o
(tegrate.)41 b(As)22 b(an)996 457 y(example,)14 b(COOL)h(and)g(Zeitgeist)g(w)
o(on't)f(w)o(ork)h(to-)996 507 y(gether)j(and)f(they)h(w)o(ere)f(dev)o(elop)q
(ed)h(b)o(y)f(the)g(same)996 557 y(compan)o(y)m(.)1038 668
y Fb(Ev)o(olution)38 b Fk(This)14 b(is)f(an)g(area)g(where)i(the)f(ev)o(o-)
996 717 y(lution)c(is)g(less)g(clear.)18 b(F)m(or)9 b(all)g(the)i(in)o
(terest)h(in)d(C++,)996 767 y(there)16 b(are)e(surprisingly)g(few)g(class)g
(libraries)g(a)o(v)n(ail-)996 817 y(able)d(for)g(it)g(and)h(those)g(are)f
(still)g(w)o(orking)f(on)h(dupli-)996 867 y(cating)17 b(functionalit)o(y)e
(already)i(in)f(the)i(other)f(lan-)996 917 y(guages,)k(while)d(there)j(are)f
(v)o(ery)f(high)g(lev)o(el)g(class)996 966 y(libraries)k(\(h)o(yp)q(ertext,)k
(inference)d(engines,)i(etc.\))996 1016 y(a)o(v)n(ailable)12
b(for)h(Lisp)h(and)g(Smalltalk)1577 1001 y Fj(1)o(2)1623 1016
y Fk(.)996 1127 y Fb(Distribu)o(ted)44 b(Pro)q(cessing)39 b
Fk(Since)j(w)o(e)f(are)996 1177 y(building)23 b(an)h(application)e(that)i
(runs)h(on)f(a)g(set)996 1227 y(of)17 b(distributed)h(w)o(orkstations,)g(w)o
(e)f(need)i(supp)q(ort)996 1277 y(for)k(building)f(the)h(application)f(and)h
(con)o(trolling)996 1326 y(its)i(execution)g(on)f(those)i(distributed)f(w)o
(orksta-)996 1376 y(tions.)30 b(There)19 b(seems)f(to)g(b)q(e)g(v)o(ery)g
(little)f(\\o\013)h(the)996 1426 y(shelf)s(")11 b(supp)q(ort)g(a)o(v)n
(ailable)d(to)j(date.)17 b(Most)11 b(existing)996 1476 y(commercial)18
b(soft)o(w)o(are)i(\(e.g.)g(Sun's)h(remote)f(pro-)996 1526
y(cedure)h(call)e(and)g(y)o(ello)o(w)f(pages)i(naming\))d(is)j(to)q(o)996
1575 y(lo)o(w)13 b(lev)o(el)g(for)h(our)f(problem.)k(While)c(it)g(pro)o
(vides)h(a)996 1625 y(base)i(to)f(build)g(on,)g(it)g(lea)o(v)o(es)g(t)o(w)o
(o)g(hard)g(problems)996 1675 y(unsolv)o(ed|replication)d(for)g(reliablit)o
(y)f(and)i(ob)r(ject)996 1725 y(orien)o(ted)i(in)o(terfaces)f(to)g(remote)g
(services.)1038 1775 y(W)m(e)j(ha)o(v)o(e)h(iden)o(ti\014ed)g(only)f(t)o(w)o
(o)g(pac)o(k)n(ages)h(that)996 1825 y(address)29 b(these)g(issues:)46
b(MetaCourier)28 b(from)e(a)996 1875 y(small)16 b(Cam)o(bridge)g(startup,)j
(and)f(ISIS,)f(whic)o(h)h(is)996 1925 y(a)f(surprisingly)g(stable)h(and)f
(mature)f(researc)o(h)k(ef-)996 1974 y(fort)14 b(from)e(Cornell.)18
b(ISIS)c(supp)q(orts)h(C++,)f(C)g(and)996 2024 y(Lisp.)j(MetaCourier)11
b(supp)q(orts)h(C)f(and)f(Lisp.)17 b(They)996 2074 y(can)f(b)q(e)h(adapted)f
(to)f(supp)q(ort)i(Smalltalk,)12 b(but)k(w)o(e)996 2124 y(w)o(ould)d(need)i
(to)f(do)g(it.)1038 2235 y Fb(Ev)o(olution)38 b Fk(Ov)o(er)21
b(the)f(next)f(few)h(y)o(ears,)h(the)996 2285 y(kind)d(of)g(distributed)g
(application)f(w)o(e)i(are)f(build-)996 2334 y(ing)10 b(will)e(b)q(ecome)i
(routine)h(and)f(broadly)f(supp)q(orted)p 996 2371 333 2 v
1027 2398 a Fi(12)1060 2410 y Fh(Bjarne)f(Stroustrup)e(claims)i(it)g(is)i
(harder)d(to)i(write)g(class)996 2449 y(libraries)e(for)i(static)f(languages)
f(lik)o(e)h(C++,)j(see)e(app)q(endix)e(B)135 2573 y Fg(c)125
2574 y Ff(\015)13 b Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h(Johnson)1077
b Fk(7)p eop
%%Page: 8 8
bop 125 307 a Fk(with)17 b(standard)h(soft)o(w)o(are.)29 b(The)18
b(recen)o(t)h(OSF)f(se-)125 357 y(lection)c(of)f(DEcorum)h(pro)o(vides)g(a)g
(solid)g(core)h(that)125 407 y(will)e(allo)o(w)h(construction)i(of)e(the)i
(higher)f(lev)o(el)g(ab-)125 457 y(stractions)20 b(w)o(e)g(require.)36
b(OSF)20 b(in)o(tends)g(to)g(issue)125 506 y(a)14 b(Request)h(F)m(or)g(T)m
(ec)o(hnology)e(\(RFT\))i(in)f(this)h(area)125 556 y(so)q(on.)24
b(If)15 b(previous)h(OSF)h(selections)f(are)h(a)e(guide,)125
606 y(it)i(should)h(b)q(e)g(commercially)d(a)o(v)n(ailable)g(in)j(ab)q(out)
125 656 y(t)o(w)o(o)13 b(y)o(ears.)125 763 y Fb(3.2.2)47 b(Dev)o(elopmen)o(t)
13 b(En)o(vironmen)o(t)o(s)125 840 y Fk(I'm)25 b(using)i(the)g(term)g(\\dev)o
(elopmen)o(t)f(en)o(viron-)125 890 y(men)o(ts")14 b(to)i(mean)e(all)g(the)i
(to)q(ols)g(that)f(are)h(needed)125 939 y(for)9 b(actual)g(dev)o(elopmen)o(t)
g(and)g(main)o(tenance)g(of)g(the)125 989 y(system.)43 b(Unlik)o(e)22
b(the)h(supp)q(ort)g(pac)o(k)n(ages)g(men-)125 1039 y(tioned)13
b(ab)q(o)o(v)o(e,)g(these)i(are)f(not)g(normally)d(included)125
1089 y(as)i(part)i(of)e(the)h(deliv)o(ered)h(soft)o(w)o(are.)125
1196 y Fb(Dev)o(elopmen)n(t)26 b(T)l(o)q(ols)41 b Fk(These)26
b(are)g(the)g(clas-)125 1246 y(sic)13 b(editors,)g(compilers,)f(debuggers,)i
(bro)o(wsers)p Fd(:)7 b(:)g(:)f Fk(.)125 1296 y(The)k(k)o(ey)h(issues)g(here)
g(are)g(that)f(to)q(ols)g(should)g(b)q(e)h(in-)125 1346 y(tegrated,)16
b(in)o(teractiv)o(e,)g(and)f(incremen)o(tal.)22 b(When)125
1395 y(programmers)j(are)i(actually)f(dev)o(eloping)g(co)q(de,)125
1445 y(their)11 b(pro)q(ductivit)o(y)g(is)g(largely)g(determined)g(b)o(y)g
(the)125 1495 y(\\inner)i(lo)q(op")g(of)h(edit-compile-test.)166
1545 y(The)21 b(to)q(ols)f(should)g(b)q(e)h(in)o(tegrated)g(with)f(b)q(oth)
125 1595 y(the)c(application)f(b)q(eing)i(dev)o(elop)q(ed)g(\(so)f(the)h(to)q
(ols)125 1644 y(ha)o(v)o(e)j(go)q(o)q(d)h(visibilit)o(y)e(and)i(con)o(trol)g
(of)f(the)i(pro-)125 1694 y(gram)c(b)q(eing)i(tested\))i(and)e(with)f(eac)o
(h)i(other)f(\(so)125 1744 y(a)f(programmer)f(do)q(es)i(not)g(ha)o(v)o(e)g
(to)f(switc)o(h)i(con-)125 1794 y(texts)e(among)e(the)j(to)q(ols)e(and)h(the)
g(to)q(ols)g(pro)o(vide)125 1844 y(a)e(uniform)e(in)o(terface\).)30
b(Incremen)o(tal)17 b(to)q(ols)g(let)h(a)125 1894 y(programmer)7
b(mak)o(e)i(small)f(c)o(hanges)j(without)f(large)125 1943 y(time)g(costs)j
(\(e.g.)f(without)f(recompiling)f(the)j(en)o(tire)125 1993
y(application\).)i(They)c(m)o(ust)e(b)q(e)i(in)o(teractiv)o(e)g(to)f(k)o(eep)
125 2043 y(the)k(inner)g(lo)q(op)f(as)h(short)h(a)e(p)q(ossible.)166
2093 y(Curren)o(tly)m(,)27 b(Lisp)e(and)g(Smalltalk)d(ha)o(v)o(e)j(suc)o(h)
125 2143 y(to)q(ols)c(as)g(a)h(natural)f(part)g(of)g(the)h(en)o(vironmen)o
(t.)125 2192 y(The)c(C++)g(equiv)n(alen)o(ts)g(are)g(still)f(in)h(the)g(exp)q
(eri-)125 2242 y(men)o(tal)f(stage.)35 b(None)20 b(that)f(w)o(e)h(ha)o(v)o(e)
f(lo)q(ok)o(ed)g(at)125 2292 y(are)14 b(mature)f(enough)h(for)f(daily)g(use.)
166 2399 y Fb(Ev)o(olution)39 b Fk(There)23 b(is)f(no)g(doubt)g(that)g(ade-)
125 2449 y(quate)9 b(C++)i(dev)o(elopmen)o(t)d(to)q(ols)i(will)e(b)q(e)i(a)o
(v)n(ailable)996 307 y(within)18 b(the)i(next)f(y)o(ear)g(to)g(18)f(mon)o
(ths,)h(p)q(ossibly)996 357 y(so)q(oner.)996 472 y Fb(T)l(o)q(ols)30
b(for)f(Programming)f(in)h(the)g(Large)996 522 y Fk(Once)11
b(a)e(pro)r(ject)h(gro)o(ws)f(past)h(a)f(couple)h(of)e(program-)996
572 y(mers,)13 b(to)q(ols)g(for)g(managing)d(and)k(con)o(trolling)e(m)o(ul-)
996 622 y(tiple)18 b(dev)o(elopmen)o(t)f(start)h(b)q(ecoming)f(imp)q(ortan)o
(t.)996 672 y(The)f(curren)o(t)h(state-of-the-art)f(in)f(these)i(to)q(ols)e
(in-)996 721 y(clude)h(con\014guration)f(managemen)o(t,)e(source)k(co)q(de)
996 771 y(con)o(trol,)k(c)o(hange)e(histories,)i(problem)e(rep)q(orting,)996
821 y(etc.)57 b(T)m(raditionally)m(,)26 b(this)g(has)h(b)q(een)g(an)f(area)
996 871 y(that)11 b(has)g(lagged)f(b)q(ehind)h(programming)c(language)996
921 y(tec)o(hnology)m(.)22 b(Ob)r(ject)16 b(orien)o(ted)g(languages)f(are)h
(no)996 970 y(exception.)1038 1022 y(The)11 b(existing)f(to)q(ols)g(are)h
(largely)e(text)i(based)h(and)996 1071 y(language)23 b(indep)q(enden)o(t.)49
b(F)m(or)23 b(ob)r(ject)i(orien)o(ted)996 1121 y(programming,)8
b(y)o(ou'd)i(lik)o(e)h(the)h(to)q(ols)f(to)g(b)q(e)h(ob)r(ject)996
1171 y(based)h(and)e(tigh)o(tly)g(coupled)h(to)g(the)h(language)e(and)996
1221 y(en)o(vironmen)o(t.)37 b(A)20 b(particularly)g(imp)q(ortan)o(t)e(to)q
(ol)996 1271 y(w)o(ould)13 b(b)q(e)i(an)f(ob)r(ject)g(library)m(.)j(Since)e
(a)f(large)f(part)996 1321 y(of)18 b(ob)r(ject)h(orien)o(ted)g(programming)c
(is)j(sp)q(ecialliz-)996 1370 y(ing)d(existing)h(ob)r(jects,)h(the)f(dev)o
(elop)q(er)h(m)o(ust)e(ha)o(v)o(e)996 1420 y(an)c(easy)g(w)o(a)o(y)f(of)g
(\014nding)h(suitable)f(ob)r(jects.)19 b(That's)996 1470 y(the)c(purp)q(ose)g
(of)e(the)i(ob)r(ject)f(library)m(.)1038 1585 y Fb(Ev)o(olution)38
b Fk(I)19 b(presume)g(suc)o(h)g(to)q(ols)g(will)e(b)q(e-)996
1635 y(come)e(a)o(v)n(ailable)f(ev)o(en)o(tually)m(.)23 b(In)16
b(the)h(mean)d(time,)996 1685 y(w)o(e)20 b(can)h(use)f(the)h(existing)f(to)q
(ols)f(on)h(an)o(y)f(of)h(the)996 1735 y(candidate)14 b(languages.)996
1850 y Fb(T)l(esting)j(and)g(SQA)41 b Fk(SQA)17 b(and)f(testing)g(is)g(an-)
996 1900 y(other)k(area)g(that)f(lags)g(the)g(rest)i(of)d(the)i(tec)o(hnol-)
996 1950 y(ogy)m(.)d(There)c(is)f(a)g(debate)h(raging)f(on)g(the)h(to)q(ols)f
(and)996 1999 y(tec)o(hniques)j(needed)g(to)e(test)h(ob)r(ject)h(orien)o(ted)
f(pro-)996 2049 y(grams.)19 b(Man)o(y)c(of)f(the)h(existing)f(metho)q(ds)g
(of)h(test-)996 2099 y(ing)f(functional)g(programs)f(do)i(not)f(seem)g(to)h
(mak)o(e)996 2149 y(m)o(uc)o(h)e(sense)j(in)d(an)h(ob)r(ject)g(orien)o(ted)h
(w)o(orld.)1038 2200 y(F)m(or)i(example,)h(to)q(ols)g(for)f(functional)h
(test)h(co)o(v-)996 2250 y(erage)c(mak)o(e)e(sure)i(that)f(the)h(test)g(co)o
(v)o(ers)g(all)e(paths)996 2300 y(through)k(a)f(function.)26
b(P)o(erhaps)18 b(the)f(OO)g(equiv)n(a-)996 2350 y(len)o(t)c(migh)o(t)f(b)q
(e)h(to)q(ols)g(that)h(ensure)g(co)o(v)o(erage)g(of)f(all)996
2399 y(metho)q(ds.)k(But)12 b(do)q(es)g(that)f(include)g(metho)q(ds)g(from)
996 2449 y(sup)q(erclasses?)20 b(If)12 b(this)g(class)h(is)f(a)f(sp)q
(ecialization)h(of)135 2573 y Fg(c)125 2574 y Ff(\015)h Fg(Cop)o(yrigh)o(t)h
(1990)g(Douglas)h(Johnson)1077 b Fk(8)p eop
%%Page: 9 9
bop 125 307 a Fk(a)17 b(w)o(ell)g(tested)i(class,)f(do)f(just)h(the)g(new)g
(metho)q(ds)125 357 y(need)c(testing?)166 524 y Fb(Ev)o(olution)39
b Fk(Ob)r(ject)18 b(orien)o(ted)f(programming)125 574 y(is)9
b(just)g(no)o(w)g(mo)o(ving)e(in)o(to)i(mainstream)d(computing)125
624 y(where)11 b(issues)g(suc)o(h)h(as)e(formal)e(testing)j(metho)q(dolo-)125
674 y(gies)16 b(are)g(a)g(concern)453 659 y Fj(13)490 674 y
Fk(.)25 b(I)16 b(susp)q(ect)i(it)e(will)e(b)q(e)j(t)o(w)o(o)125
724 y(or)d(three)i(y)o(ears)f(b)q(efore)g(to)q(ols)f(and)g(metho)q(dologies)
125 774 y(are)20 b(a)o(v)n(ailable)e(for)i(an)o(y)g(language.)36
b(F)m(or)20 b(no)o(w,)h(it)125 823 y(do)q(es)14 b(not)f(app)q(ear)h(that)g
(one)g(language)e(has)i(an)f(ad-)125 873 y(v)n(an)o(tage)g(o)o(v)o(er)h(an)o
(y)f(other.)125 1041 y Fb(3.2.3)47 b(P)o(erformance)125 1138
y Fk(P)o(erformance)13 b(is)g(often)h(discussed)h(as)f(a)f(reason)h(for)125
1188 y(c)o(ho)q(osing)g(a)g(language,)g(partly)g(b)q(ecause)i(it)e(can)h(b)q
(e)125 1238 y(easy)k(to)g(measure)g(and)g(partly)f(b)q(ecause)j(it)e(often)
125 1288 y(is)j(crucial.)45 b(Ho)o(w)o(ev)o(er,)25 b(in)e(the)g(particular)g
(case)125 1337 y(of)16 b(CIP)m(,)h(I)g(b)q(eliev)o(e)h(that)g(ra)o(w)f(CPU)h
(p)q(erformance)125 1387 y(\(the)f(primary)e(p)q(erformance)i(e\013ect)h(of)e
(language\))125 1437 y(is)k(the)g(least)h(of)e(our)h(w)o(orries.)37
b(The)21 b(distributed)125 1487 y(nature)f(of)f(CIP)h(and)f(rapid)h(decline)g
(of)f(the)h(cost)125 1537 y(of)d(MIPS)g(tend)i(to)e(con\014rm)g(this.)29
b(I'm)16 b(curren)o(tly)125 1587 y(assuming)g(\(this)i(will)f(b)q(e)h(v)o
(eri\014ed)h(as)f(system)f(de-)125 1636 y(sign)h(progresses\))i(that)f(our)f
(ma)r(jor)f(p)q(erformance)125 1686 y(limitati)o(on)10 b(will)h(b)q(e)i
(database)g(access,)h(follo)o(w)o(ed)d(b)o(y)125 1736 y(net)o(w)o(ork)k
(latency)m(,)f(memory)e(use,)j(then)h(CPU)f(p)q(er-)125 1786
y(formance.)h(One)e(area)e(where)i(this)f(ma)o(y)e(not)h(apply)125
1836 y(is)18 b(an)o(y)g(soft)o(w)o(are)g(w)o(e)h(write)g(for)f(the)h(MPS)g
(whic)o(h)125 1885 y(ma)o(y)11 b(b)q(e)k(more)e(memory)e(and)j(CPU)g
(limited.)166 2053 y Fb(Ev)o(olution)39 b Fk(Ab)q(out)17 b(the)h(only)f(area)
h(I)f(exp)q(ect)125 2103 y(m)o(uc)o(h)12 b(p)q(erformance)h(ev)o(olution)g
(is)h(in)f(Lisp.)18 b(There)125 2153 y(will)d(incremen)o(tal)h(impro)o(v)o
(emen)o(ts)e(in)j(CLOS)g(p)q(er-)125 2202 y(formance)c(as)i(the)g(required)h
(compiler)d(tec)o(hnology)125 2252 y(matures.)k(I)d(don't)f(think)h(it)f
(will)g(b)q(e)h(signi\014can)o(t.)p 125 2332 333 2 v 156 2359
a Fi(13)188 2370 y Fh(A)h(session)e(on)g(OO)i(testing)e(at)g(a)h(recen)o(t)f
(testing)f(con-)125 2410 y(ference)f(had)i(8)h(p)q(eople)e(attending)f
(\(including)g(t)o(w)o(o)i(TIers\))125 2449 y(out)d(of)h(450)g(at)g(the)g
(conference.)996 307 y Fl(4)69 b(Summary)996 398 y Fk(It)12
b(is)g(m)o(y)e(hop)q(e)i(this)f(will)g(form)f(the)i(basis)g(for)f(a)g(lan-)
996 448 y(guage)j(selection)g(that)g(is)g(righ)o(t)f(for)g(all)g(concerned.)
996 498 y(As)j(de\014ned,)g(the)f(absolute)g(requiremen)o(ts)h(narro)o(w)996
548 y(the)g(selection)h(do)o(wn)e(to)h(three)g(languages:)21
b(C++,)996 597 y(Lisp,)14 b(and)f(Smalltalk.)1038 647 y(No)o(w)g(w)o(e)h
(need)g(to)f(apply)g(the)h(desirable)g(criteria)996 697 y(to)j(narro)o(w)g
(the)g(selection)h(to)f(the)g(\014nal)g(c)o(hoice.)27 b(I)996
747 y(curren)o(tly)12 b(b)q(eliev)o(e)f(that)f(the)h(\014rst)h(order)f(terms)
f(are:)1038 823 y Fc(\017)20 b Fk(The)15 b(data)e(mo)q(del)g(and)g(database)h
(in)o(terfaces.)1038 901 y Fc(\017)20 b Fk(The)15 b(a)o(v)n(ailabili)o(t)o(y)
c(and)j(useabilit)o(y)f(of)g(class)i(li-)1079 950 y(braries.)1038
1028 y Fc(\017)20 b Fk(Customer)26 b(requiremen)o(ts)h(\(as)g(I)g(curren)o
(tly)1079 1077 y(understand)12 b(them,)e(they)h(pro)o(vide)g(little)e(basis)
1079 1127 y(to)14 b(select)h(one)f(candidate)g(o)o(v)o(er)g(another\).)1038
1204 y(While)f(still)h(imp)q(ortan)o(t,)e(the)j(follo)o(wing)d(criteria)996
1254 y(seem)e(to)g(b)q(e)h(less)g(signi\014can)o(t)f(than)g(the)h(ones)g(ab)q
(o)o(v)o(e:)1038 1330 y Fc(\017)20 b Fk(Standards.)1038 1408
y Fc(\017)g Fk(Dev)o(elopmen)o(t)13 b(to)q(ols.)1038 1485 y
Fc(\017)20 b Fk(Distributed)14 b(Pro)q(cessing.)1038 1562 y
Fc(\017)20 b Fk(Programmer)h(pro)q(ductivit)o(y)h(\(P)o(erhaps)i(this)1079
1612 y(should)16 b(b)q(e)h(a)f(\014rst)i(order)f(term,)f(but)g(it)g(is)g(so)
1079 1661 y(hard)e(to)g(quan)o(tify\).)1038 1738 y(Finally)m(,)e(these)k
(criteria)f(seem)f(to)h(pro)o(vide)f(little)996 1788 y(basis)g(for)g
(selecting)g(one)g(language)f(o)o(v)o(er)h(another:)1038 1865
y Fc(\017)20 b Fk(User)15 b(In)o(terface)g(Builders)1038 1942
y Fc(\017)20 b Fk(T)m(raining)1038 2019 y Fc(\017)g Fk(SQA)15
b(and)e(testing)i(to)q(ols)1038 2096 y Fc(\017)20 b Fk(T)m(o)q(ols)13
b(for)h(programmi)o(ng)d(in)i(the)i(large.)1038 2173 y Fc(\017)20
b Fk(P)o(erformance)1038 2250 y(There)11 b(is)f(a)f(broad)h(sp)q(ectrum)g(of)
g(issues)h(in)e(select-)996 2300 y(ing)i(a)g(language)g(for)g(MMST.)g(I'v)o
(e)h(tried)g(to)f(outline)996 2350 y(them)j(here.)20 b(If)14
b(there)i(is)e(something)f(y)o(ou'd)g(lik)o(e)h(to)996 2399
y(add)i(or)g(y)o(ou)g(ha)o(v)o(e)f(an)o(y)h(questions,)h(please)f(let)g(me)
996 2449 y(kno)o(w.)135 2573 y Fg(c)125 2574 y Ff(\015)d Fg(Cop)o(yrigh)o(t)h
(1990)g(Douglas)h(Johnson)1077 b Fk(9)p eop
%%Page: 10 10
bop 125 307 a Fl(A)68 b(Language)25 b(Discussion)125 398 y
Fk(In)18 b(this)h(section,)h(I'm)d(going)g(to)i(do)f(something)g(I)125
448 y(said)12 b(w)o(e)h(shouldn't:)k(discuss)c(the)h(three)f(candidate)125
498 y(languages)19 b(in)g(abstract.)36 b(F)m(or)19 b(eac)o(h)h(language,)g(I)
125 548 y(w)o(ould)12 b(lik)o(e)g(to)h(presen)o(t)i(something)d(of)g(the)i
(history)125 598 y(and)e(philosophies)g(b)q(ehind)h(them.)k(Eac)o(h)c
(language)125 647 y(is)i(unique)h(and)g(is)f(what)h(it)f(is)h(for)f(sound)h
(reasons.)125 697 y(P)o(erhaps)g(this)f(will)e(giv)o(e)i(some)f(insigh)o(t)h
(in)o(to)f(those)125 747 y(reasons.)125 864 y Fe(A.1)55 b(C++)125
941 y Fk(C++)17 b(is)h(a)f(reasonable)h(and)f(recen)o(t)i(ev)o(olution)d(of)
125 991 y(C.)11 b(F)m(or)h(that)h(reason,)f(it's)g(probably)g(b)q(est)i(to)e
(b)q(egin)125 1041 y(with)f(a)h(discussion)g(of)f(C.)h(C)f(w)o(as)h(dev)o
(elop)q(ed)h(in)e(the)125 1090 y(early)e('70's)f(at)i(Bell)f(Lab)q
(oratories.)17 b(It's)9 b(prime)g(pur-)125 1140 y(p)q(ose)16
b(w)o(as)g(to)f(replace)i(assem)o(bly)d(language)h(in)g(de-)125
1190 y(v)o(eloping)10 b(op)q(erating)h(systems,)h(particularly)f(Unix.)125
1240 y(Because)k(of)f(this,)f(p)q(erformance)h(w)o(as)g(paramoun)o(t.)166
1290 y(Unix)k(itself)g(w)o(as)h(dev)o(elop)q(ed)g(as)g(a)f(reaction)h(to)125
1340 y(Dennis)g(Ric)o(hie's)g(p)q(erception)i(that)f(Multics)g(suf-)125
1389 y(fered)j(from)f(\\soft)o(w)o(are)g(bloat".)45 b(Unix)22
b(w)o(as)h(in-)125 1439 y(tended)13 b(to)e(b)q(e)i(a)e(lean)h(and)g(mean)657
1424 y Fj(14)703 1439 y Fk(op)q(erating)f(sys-)125 1489 y(tem.)25
b(Key)18 b(researc)o(h)g(concepts)h(included)d(writing)125
1539 y(the)f(OS)g(in)g(a)f(high)g(lev)o(el)h(language)f(and)h(p)q(ortabil-)
125 1589 y(it)o(y)m(.)32 b(Up)20 b(to)f(then,)h(op)q(erating)f(systems)h(w)o
(ere)g(al-)125 1638 y(w)o(a)o(ys)c(proprietary)h(and)f(v)o(ery)h(tigh)o(tly)f
(coupled)h(to)125 1688 y(the)d(hardw)o(are.)166 1738 y(C)i(re\015ects)i
(those)f(goals.)24 b(C)17 b(features)g(are)f(ideal)125 1788
y(for)21 b(op)q(erating)h(system)g(dev)o(elopmen)o(t,)h(There)g(is)125
1838 y(outstanding)11 b(supp)q(ort)h(for)f(p)q(oin)o(ter)g(manipulation.)125
1888 y(The)21 b(data)f(t)o(yp)q(es)h(and)g(structures)i(are)e(similarly)125
1937 y(w)o(ell)10 b(suited.)17 b(The)12 b(syn)o(tax)f(of)f(the)i(language)e
(is)g(v)o(ery)125 1987 y(terse,)k(using)e(one)h(or)g(t)o(w)o(o)g(c)o
(haracters)h(where)g(other)125 2037 y(languages)h(used)h(w)o(ords)g(or)f
(phrases.)25 b(Ev)o(erything)125 2087 y(that)14 b(can)g(done)h(at)f(compile)f
(time)f(is.)19 b(There)d(is)e(no)125 2137 y(run)9 b(time)f(t)o(yp)q(e)i(or)f
(error)i(c)o(hec)o(king.)16 b(Ev)o(en)10 b(the)g(com-)125 2187
y(piler)16 b(do)q(es)i(little)f(error)h(c)o(hec)o(king,)f(relying)g(on)g(an)
125 2236 y(auxiliary)11 b(program)g(called)i(LINT)g(to)g(c)o(hec)o(k)i(man)o
(y)125 2286 y(classes)k(of)f(errors.)33 b(The)19 b(dev)o(elop)q(ers)h(of)e
(the)h(lan-)125 2336 y(guage)13 b(to)q(ok)h(justi\014able)f(pride)h(in)g(the)
g(fact)g(that)g(C)p 125 2371 333 2 v 156 2398 a Fi(14)188 2410
y Fh(Ov)o(er)c(the)g(y)o(ears,)f(Unix)i(has)e(bloated)g(far)h(b)q(ey)o(ond)e
(what)125 2449 y(Multics)i(ev)o(er)h(managed.)996 307 y Fk(co)q(de)21
b(w)o(as)f(only)f(20\045)h(slo)o(w)o(er)g(than)g(hand)g(co)q(ded)996
357 y(assem)o(bly)13 b(language.)1038 411 y(The)g(p)q(opularit)o(y)f(of)h(C)g
(spread)h(with)f(Unix.)k(The)996 461 y(language)g(has)h(c)o(hanged)g(remark)n
(ably)e(little)h(since)996 511 y(the)22 b(original)c(b)q(o)q(ok)j(b)o(y)f
(Kernighan)h(and)g(Ric)o(hie.)996 560 y(The)12 b(ANSI)f(C)h(commi)o(ttee)e
(dev)o(elop)q(ed)i(a)f(more)f(pre-)996 610 y(cise)16 b(sp)q(eci\014cation,)g
(cleaned)g(up)f(some)f(lo)q(ose)i(ends)996 660 y(and)e(revised)h(argumen)o(t)
e(passing.)1038 714 y(C++)d(can)g(b)q(e)h(view)o(ed)f(as)g(the)g(second)h
(signi\014can)o(t)996 764 y(revison.)17 b(It)11 b(remains)e(v)o(ery)i
(faithful)d(to)i(the)h(original)996 814 y(goals.)22 b(P)o(erformance)15
b(is)g(still)g(paramoun)o(t.)20 b(There)996 864 y(is)14 b(no)f(run)o(time)f
(t)o(yp)q(e)i(or)g(error)g(c)o(hec)o(king,)f(all)g(t)o(yp)q(es)996
913 y(are)k(declared)g(b)o(y)f(the)g(programmer)e(and)i(c)o(hec)o(k)o(ed)996
963 y(b)o(y)c(the)g(compiler)1277 948 y Fj(15)1310 963 y Fk(.)18
b(C++)12 b(\(or)f(C\))h(are)g(an)f(ob)o(vious)996 1013 y(c)o(hoice)17
b(for)e(an)h(application)f(with)g(tigh)o(t)h(time)f(and)996
1063 y(space)g(constrain)o(ts.)996 1201 y Fe(A.2)56 b(Smalltalk)996
1286 y Fk(While)25 b(C)g(w)o(as)g(b)q(eing)h(dev)o(elop)q(ed)g(on)f(the)h
(east)996 1336 y(coast,)11 b(a)f(group)g(of)f(researc)o(hers)14
b(on)9 b(the)i(other)g(coast)996 1385 y(at)23 b(Xero)o(x)g(P)m(AR)o(C)f(w)o
(ere)i(dev)o(eloping)e(Smalltalk.)996 1435 y(It)32 b(w)o(as)g(b)q(eing)g(dev)
o(elop)q(ed)h(as)f(part)h(of)e(their)996 1485 y(wide-ranging)19
b(researc)o(h)j(in)o(to)d(p)q(ersonal)h(comput-)996 1535 y(ers.)47
b(Nearly)22 b(ev)o(erything)i(in)e(to)q(da)o(y's)h(w)o(orksta-)996
1585 y(tions)11 b(had)g(it's)f(origins)g(in)h(that)g(researc)o(h)h(including)
996 1634 y(bit)i(mapp)q(ed)f(graphics,)h(lo)q(cal)f(area)h(net)o(w)o(orks,)g
(the)996 1684 y(mouse,)d(and)f(the)i(\(then)g(radical\))e(idea)h(of)g(one)g
(com-)996 1734 y(puter)k(p)q(er)g(p)q(erson.)1038 1788 y(The)d(researc)o(h)h
(goals)e(of)f(Smalltalk)f(included)i(ex-)996 1838 y(ploration)k(of)h(ob)r
(ject)h(orien)o(ted)g(concepts)h(and)e(de-)996 1888 y(v)o(elopmen)o(t)e(of)h
(a)g(fully)f(in)o(tegrated,)i(highly)e(coher-)996 1938 y(en)o(t,)g(en)o
(vironmen)o(t)f(for)g(soft)o(w)o(are)h(dev)o(elopmen)o(t.)1038
1992 y(Again,)h(the)h(language)f(is)g(a)h(re\015ection)h(of)e(those)996
2041 y(goals.)j(Smalltal)o(k)11 b(is)j(a)g(deligh)o(t)f(to)h(the)g(ob)r(ject)
h(ori-)996 2091 y(en)o(ted)21 b(purist.)37 b Fa(Everything)24
b Fk(in)c(the)g(language)g(is)996 2141 y(an)15 b(ob)r(ject.)21
b Fa(Every)d Fk(op)q(eration)c(is)h(a)f(message)h(send)996
2191 y(to)g(an)f(ob)r(ject)1217 2176 y Fj(16)1253 2191 y Fk(.)20
b(Because)c(the)f(language)f(has)g(one)996 2241 y(and)h(only)f(one)h(w)o(a)o
(y)g(to)f(do)h(something,)f(Smalltalk)p 996 2292 V 1027 2319
a Fi(15)1060 2331 y Fh(This)d(is)h(what)f(they)f(mean)h(b)o(y)g(static)f(t)o
(yping.)1027 2359 y Fi(16)1060 2370 y Fh(In)o(ternal)k(implemen)o(ta)o(tio)o
(ns)g(\\c)o(heat")g(on)i(this)f(for)h(ef-)996 2410 y(\014ciency's)f(sak)o(e,)
i(but)f(it's)h(true)f(from)f(the)h(programmer's)996 2449 y(p)q(oin)o(t)10
b(of)i(view.)135 2573 y Fg(c)125 2574 y Ff(\015)h Fg(Cop)o(yrigh)o(t)h(1990)g
(Douglas)h(Johnson)1056 b Fk(10)p eop
%%Page: 11 11
bop 125 307 a Fk(soft)o(w)o(are)16 b(tends)i(to)e(b)q(e)h(easy)g(to)f(in)o
(tegrate.)26 b(Inde-)125 357 y(p)q(enden)o(tly)12 b(written)g(pac)o(k)n(ages)
g(can)g(come)f(together)125 407 y(with)i(minim)o(al)e(problems.)166
459 y(This)34 b(same)g(conceptual)h(simplicit)o(y)d(mak)o(es)125
509 y(learning)22 b(the)h(basic)h(language)e(trivial,)h(b)q(ecause)125
559 y(there)18 b(is)g(only)e(one)i(op)q(eration|the)f(ob)r(ject)i(mes-)125
608 y(sage)g(send.)33 b(The)19 b(learning)g(e\013ort)g(comes)f(in)h(un-)125
658 y(derstanding)d(general)g(ob)r(ject)h(orien)o(ted)f(program-)125
708 y(ming)h(and)i(learning)g(to)g(use)h(the)h(ob)r(jects)f(in)f(the)125
758 y(Smalltal)o(k)11 b(en)o(vironmen)o(t.)166 810 y(Graphical)e(user)i(in)o
(terfaces)g(ha)o(v)o(e)f(b)q(een)h(a)e(part)h(of)125 860 y(Smalltal)o(k)h
(righ)o(t)i(from)f(the)i(start.)19 b(In)13 b(fact,)h(all)e(the)125
910 y(windo)o(wing)18 b(en)o(vironmen)o(ts)g(in)h(broad)h(use)g(to)q(da)o(y)
125 959 y(ha)o(v)o(e)9 b(at)h(least)g(philosophic)f(ro)q(ots)i(in)e(the)i
(Smalltalk)125 1009 y(researc)o(h)270 994 y Fj(17)307 1009
y Fk(.)125 1138 y Fe(A.3)55 b(Lisp)125 1218 y Fk(Lisp)16 b(is)h(the)g(second)
h(oldest)f(computer)f(language,)125 1268 y(only)f(F)m(ortran)h(is)g(older.)24
b(Lisp)16 b(w)o(as)g(dev)o(elop)q(ed)h(b)o(y)125 1318 y(John)12
b(McCarth)o(y)g(at)g(MIT)f(in)h(1959.)k(The)d(k)o(ey)f(pur-)125
1368 y(p)q(ose)22 b(w)o(as)g(to)g(dev)o(elop)f(a)h(language)f(for)g(writing)
125 1418 y(non-mathm)o(atical)9 b(programs)j(\(i.e.)g(sym)o(b)q(olic)f(pro-)
125 1467 y(cessing\).)20 b(As)15 b(suc)o(h,)g(the)g(primary)d(data)j
(structure)125 1517 y(w)o(as)e(a)h(list,)f(hence)i(the)g(name)d
Fb(LIS)p Fk(t)i Fb(P)p Fk(ro)q(cessing.)166 1569 y(There)24
b(has)f(b)q(een)h(a)e(tremendous)h(amoun)o(t)e(of)125 1619
y(ev)o(olution)g(o)o(v)o(er)i(the)h(y)o(ears.)46 b(An)23 b(original)e(Lisp)
125 1669 y(programmer)d(w)o(ould)h(hardly)h(recognize)h(mo)q(dern)125
1719 y(Comm)o(on)13 b(Lisp.)23 b(The)16 b(list)g(is)f(no)h(longer)f(the)h
(only)125 1769 y(data)10 b(structure,)j(it)e(is)f(just)h(one)g(of)f(man)o(y)f
(a)o(v)n(ailable.)125 1818 y(One)14 b(of)f(the)h(most)e(recen)o(t)j(ev)o
(olutions)e(is)g(the)i(addi-)125 1868 y(tion)g(of)h(a)f(standard)i(ob)r(ject)
g(system,)f(CLOS)g(\(the)125 1918 y(Comm)o(on)11 b(Lisp)i(Ob)r(ject)i
(System\).)j(While)13 b(ob)r(jects)125 1968 y(are)18 b(not)h(new)g(to)f(Lisp)
499 1953 y Fj(18)534 1968 y Fk(,)h(CLOS)g(w)o(as)f(a)g(distilla-)125
2018 y(tion)d(of)g(earlier)i(systems)f(and)g(is)f(the)i(\014rst)g(that)f(is)
125 2068 y(completely)c(in)o(tegrated)j(in)o(to)e(the)h(language.)166
2120 y(In)j(con)o(trast)h(to)f(Smalltalk,)d(whic)o(h)j(has)h(only)e(a)125
2169 y(single)22 b(w)o(a)o(y)f(of)h(doing)g(things,)i(Lisp)e(has)h(man)o(y)m
(.)p 125 2213 333 2 v 156 2240 a Fi(17)188 2252 y Fh(W)m(e)9
b(are)g(all)f(a)o(w)o(are)h(of)g(Apple's)f("lo)q(ok)g(and)g(feel")g(la)o
(wsuit)125 2291 y(alleging)d(Microsoft)i(stole)f(the)i(Mac's)f(user)g(in)o
(terface.)12 b(Xero)o(x)125 2331 y(has)g(recen)o(tly)f(sued)h(Apple)h
(accusing)e(Apple)h(of)h(stealing)e(it)125 2370 y(from)f(them.)156
2398 y Fi(18)188 2410 y Fh(Fla)o(v)o(ors)g(w)o(as)i(an)f(early)f(OO)i(system)
e(in)h(Lisp)g(and)g(used)125 2449 y(extensiv)o(ely)d(in)j(Lisp)g(mac)o(hines)
996 307 y Fk(F)m(or)16 b(this)h(reason,)g(Lisp)g(is)f(most)f(commonly)f(used)
996 357 y(for)j(applications)f(that)h(require)g(a)g(language)f(with)996
407 y(great)21 b(expressiv)o(e)g(p)q(o)o(w)o(er,)h(complex)c(data)i(repre-)
996 457 y(sen)o(tations,)30 b(and)c(\015exible)g(op)q(erations)g(on)g(that)
996 506 y(data.)33 b(This)19 b(is)g(exactly)g(what)f(AI)h(requires,)i(but)996
556 y(is)13 b(also)f(true)i(of)e(man)o(y)f(other)j(problems,)d(including)996
606 y(CAD)1089 591 y Fj(19)1124 606 y Fk(,)j(CASE,)f(sc)o(heduling,)h(etc.)
1038 658 y(The)h(culture)i(of)d(Lisp)h(dev)o(elopmen)o(t)f(sa)o(ys)i(that,)
996 708 y(when)g(a)f(Lisp)g(dev)o(elop)q(er)h(tac)o(kles)f(a)g(problem,)f
(the)996 758 y(\014rst)e(thing)f(done)g(is)g(to)g(build)f(an)o(y)h(necessary)
i(to)q(ols.)996 808 y(This)h(means)e(that)i(Lisp)f(also)g(has)g(a)g(v)o(ery)h
(ric)o(h)g(and)996 857 y(p)q(o)o(w)o(erful)e(set)g(of)g(supp)q(ort)g(to)q
(ols)g(and)f(dev)o(elopmen)o(t)996 907 y(en)o(vironmen)o(ts.)36
b(These)22 b(to)q(ols)e(ha)o(v)o(e)g(gro)o(wn)f(o)o(v)o(er)996
957 y(the)c(y)o(ears)g(and)g(k)o(ept)f(pace)h(with)f(the)h(ev)o(olution)f(in)
996 1007 y(computer)h(hardw)o(are.)22 b(Lisp)15 b(w)o(as)g(one)g(of)g(the)h
(\014rst)996 1057 y(languages)c(to)g(b)q(e)g(run)h(in)o(teractiv)o(ely)e(and)
h(graphics)996 1107 y(in)o(terfaces)i(w)o(ere)f(added)g(as)g(so)q(on)f(as)h
(the)g(hardw)o(are)996 1156 y(b)q(ecame)h(a)o(v)n(ailable.)1038
1208 y(Go)q(o)q(d)21 b(Lisp)h(en)o(vironmen)o(ts)f(for)g(Unix)h(are)g(of-)996
1258 y(fered)16 b(b)o(y)f(four)g(ma)r(jor)e(v)o(endors)j(and)f(a)g(n)o(um)o
(b)q(er)f(of)996 1308 y(smaller)k(pla)o(y)o(ers.)34 b(There)20
b(are)g(a)e(couple)i(of)e(pub-)996 1358 y(lic)13 b(domain)e(v)o(ersions)i
(that)g(lac)o(k)g(the)h(stabilit)o(y)e(and)996 1408 y(rapid)19
b(ev)o(olution)f(of)h(the)h(ma)r(jor)e(pac)o(k)n(ages.)34 b(The)996
1458 y(ev)o(olution)11 b(is)h(c)o(hie\015y)h(in)e(the)i(area)f(of)g(impro)o
(v)o(ed)e(de-)996 1507 y(v)o(elopmen)o(t)g(to)q(ols)i(and)f(supp)q(ort)h(pac)
o(k)n(ages.)18 b(A)11 b(cou-)996 1557 y(ple)i(of)f(v)o(endors)h(still)e(ha)o
(v)o(en't)i(caugh)o(t)f(up)h(with)f(the)996 1607 y(\014nal)f(ANSI)h
(de\014nition,)f(although)g(they)h(should)g(b)q(e)996 1657
y(there)j(this)f(summer.)996 1806 y Fl(B)69 b(On)92 b(Language)h(W)-6
b(ars)1114 1881 y(Bjarne)23 b(Stroustrup)996 1976 y Fk([)p
Fa(The)15 b(fol)r(lowing)f(c)n(omments)h(fr)n(om)f(Bjarne)h(Str)n(ous-)996
2026 y(trup)j(original)r(ly)g(app)n(e)n(ar)n(e)n(d)h(on)g(the)f(net)h(and)g
(wer)n(e)996 2076 y(r)n(eprinte)n(d)12 b(in)g(the)g(Par)n(cPlac)n(e)g
(Systems)h(newsletter,)996 2126 y Fk(P)o(arcNotices)p Fa(,)19
b(Winter)f(1990.)27 b(Bjarne)18 b(is)f(the)g(de-)996 2176 y(velop)n(er)j(of)h
(C++.)35 b(They)21 b(may)g(help)f(she)n(d)h(some)996 2225 y(light)15
b(on)g(the)g(issues.)k(|)c(daj)6 b Fk(])1038 2277 y(There)25
b(seems)g(to)f(b)q(e)h(a)f(misconception)f(that)996 2327 y(C++)j(is)g(supp)q
(osed)g(to)g(b)q(e)g(Smalltalk)c(or)j(that)p 996 2371 V 1027
2398 a Fi(19)1060 2410 y Fh(Not)15 b(only)e(is)i(Droid)f(in)g(Lisp,)h(but)f
(so)h(is)g(the)f(p)q(opular)996 2449 y(PC)f(CAD)f(program,)d(AutoCAD.)135
2573 y Fg(c)125 2574 y Ff(\015)k Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h
(Johnson)1056 b Fk(11)p eop
%%Page: 12 12
bop 125 307 a Fk(Smalltal)o(k)9 b(and)i(C++)i(are)f(in)f(some)f(w)o(a)o(y)h
(supp)q(osed)125 357 y(to)17 b(b)q(e)i(the)f(same.)30 b(Some)16
b(migh)o(t)g(summarize)g(the)125 407 y(misconception)d(in)g(a)h(\\sillygism)o
(":)191 454 y(C++)g(is)g(Ob)r(ject-Orien)o(ted)191 504 y(Smalltalk)d(is)i(Ob)
r(ject-Orien)o(ted)p 166 520 573 2 v 191 555 a(C++)h(is)g(Smalltalk)166
603 y(It)e(follo)o(ws)e(from)f(that)j(view)f(that)h(y)o(ou)f(should)g(b)q(e)
125 653 y(able)g(to)h(w)o(ork)g(in)g(exactly)g(the)h(same)e(w)o(a)o(y)h(with)
g(im-)125 703 y(plemen)o(tations)i(of)h(the)h(t)o(w)o(o)f(languages,)g(that)h
(y)o(ou)125 753 y(should)h(b)q(e)h(able)f(to)g(accomplish)f(the)i(same)e
(tasks)125 802 y(with)e(b)q(oth)g(languages,)f(and)i(that)f(when)h(y)o(ou)f
(can-)125 852 y(not,)f(someone)g(has)h(go)q(ofed.)166 902 y(I)g(disagree)g
(with)g(this)g(premise.)166 952 y(P)o(eople)29 b(who)f(naiv)o(ely)f(approac)o
(h)h(C++)h(and)125 1002 y(Smalltal)o(k)17 b(with)j(this)g(premise)g(are)g
(going)f(to)h(b)q(e)125 1051 y(disapp)q(oin)o(ted.)166 1101
y(C++)28 b(w)o(as)f Fa(not)32 b Fk(designed)c(as)g(an)f(imitation)125
1151 y(Smalltal)o(k.)43 b(Had)23 b(I)h(tried)f(that,)i(I)f(w)o(ould)e(nat-)
125 1201 y(urally)k(pro)q(duced)j(something)d(m)o(uc)o(h)h(closer)h(to)125
1251 y(Smalltal)o(k.)g(Actually)m(,)18 b(I)g(do)g(not)g(see)h(a)f(need)h(for)
125 1300 y(imitation-)o(Sm)o(al)o(ltal)o(ks.)49 b(Smalltalk)21
b(is)k(still)f(the)125 1350 y(b)q(est)18 b(Smalltalk)c(around.)27
b(It)17 b(is)g(a)g(v)o(ery)g(nice)h(lan-)125 1400 y(guage/system)d(and)h(its)
g(ev)o(olution)f(is)h(in)f(v)o(ery)i(ca-)125 1450 y(pable)c(hands.)166
1500 y(So,)19 b(C++)h(is)f(not)f(a)h(v)o(ery)g(go)q(o)q(d)f(Smalltalk;)g(it)
125 1550 y(w)o(as)f(not)f(mean)o(t)g(to)h(b)q(e.)28 b(Similarly)m(,)14
b(Smalltalk)g(is)125 1599 y(not)e(a)g(v)o(ery)g(go)q(o)q(d)g(C++;)h(it)e(w)o
(as)h(not)h(mean)o(t)e(to)h(b)q(e.)166 1649 y(There)20 b(are)e(t)o(w)o(o)g
(fundamen)o(tal)f(di\013erences)j(b)q(e-)125 1699 y(t)o(w)o(een)j(C++)f(and)h
(Smalltalk)o(:)32 b(C++)23 b(is)g(a)f(lan-)125 1749 y(guage;)d(Smalltalk)c
(is)j(a)g(system.)30 b(C++)19 b(is)f(stati-)125 1799 y(cally)13
b(t)o(yp)q(ed;)h(Smalltal)o(k)d(is)j(dynamically)d(t)o(yp)q(ed.)166
1848 y(These)24 b(\014rst)f(order)g(di\013erences)i(follo)o(w)20
b(partly)125 1898 y(from)12 b(needs)k(and)e(application)f(areas,)h(partly)g
(they)125 1948 y(represen)o(t)22 b(alternativ)o(e)f(strategies)g(for)f(attac)
o(king)125 1998 y(problems.)62 b(Man)o(y)28 b(di\013ernences)j(follo)o(w)c
(from)125 2048 y(them.)17 b(F)m(or)c(example,)f(in)i(general)166
2123 y Fc(\017)21 b Fk(it)9 b(is)g(harder)i(to)e(build)g(a)g(high-qualit)o(y)
m(,)e(\(\\mo)q(d-)208 2173 y(ern,")18 b(\\Smalltalk-l)o(ik)n(e"\))d
(programming)f(en-)208 2223 y(vironmen)o(t)9 b(for)h(a)h(statically)f(t)o(yp)
q(ed)h(language.)166 2300 y Fc(\017)21 b Fk(it)27 b(is)g(harder)h(to)f(pro)o
(vide)h(a)f(high-qualit)o(y)208 2350 y(programmi)o(ng)10 b(en)o(vironmen)o(t)
h(for)h(a)h(language)208 2399 y(used)e(on)g(a)g(div)o(erse)h(range)f(of)f
(systems)i(\(rather)208 2449 y(than)h(b)q(eing)h(a)g(system)g(in)f(itself)s
(\).)1038 307 y Fc(\017)20 b Fk(it)15 b(is)h(easier)g(to)g(design)f
(\\standard)h(libraries")1079 357 y(in)e(a)f(dynamically)e(t)o(yp)q(ed)k
(language.)1038 432 y Fc(\017)20 b Fk(it)13 b(is)g(harder)h(to)f(pro)q(duce)i
(e\016cien)o(tly)e(running)1079 482 y(co)q(de)i(for)f(a)f(dynamically)e(t)o
(yp)q(ed)k(langauge.)1038 558 y Fc(\017)20 b Fk(it)26 b(is)h(harder)g(to)f
(co)q(op)q(erate)i(with)e(\\tradi-)1079 608 y(tional")10 b(systems)h(from)f
(a)h(dynamically)d(t)o(yp)q(ed)1079 657 y(language)19 b(em)o(b)q(edded)h(in)f
(a)g(non-traditional)1079 707 y(standard)c(en)o(vironmen)o(t.)1038
783 y Fc(\017)20 b Fk(it)27 b(is)f(easier)h(to)g(manage)e(the)i(in)o
(tegration)1079 832 y(of)c(large)f(systems)h(written)h(b)o(y)f(man)o(y)e
(pro-)1079 882 y(grammers)8 b(if)i(statically)f(t)o(yp)q(ed)i(in)o(terfaces)g
(are)1079 932 y(used.)1038 1005 y(The)j(list)e(could)i(b)q(e)g(made)e(m)o(uc)
o(h)g(longer,)h(but)g(as)996 1054 y(it)g(b)q(ecomes)h(more)e(sp)q(eci\014c,)i
(the)g(sp)q(eci\014cs)i(b)q(ecome)996 1104 y(hard)c(to)g(understand)g(in)g
(isolation,)e(data)h(is)h(harder)996 1154 y(to)e(come)f(b)o(y)m(,)g(and)h
(the)g(issues)h(get)f(more)e(sensitiv)o(e)j(to)996 1204 y(matters)16
b(of)f(system)g(maturit)o(y)m(,)e(application)i(area,)996 1254
y(ecomonics,)e(and)h(the)g(bac)o(kground)g(of)f(the)i(users.)1038
1303 y(It)37 b(is)h(clear)g(that)g(b)q(oth)f(classes)i(of)e(lan-)996
1353 y(guages/systems)11 b(ev)o(olv)o(e)g(to)g(comp)q(ensate)g(for)g(their)
996 1403 y(w)o(eaknesses,)i(and)e(that)g(the)h(a)o(v)o(erage)f(prop)q(onen)o
(t)g(of)996 1453 y(one)17 b(language/system)e(kno)o(ws)h(his/her)h(o)o(wn)f
(lan-)996 1503 y(guage)22 b Fa(much)j Fk(b)q(etter)e(than)e(the)i(alternativ)
o(es)e(so)996 1553 y(that)d(m)o(uc)o(h)f(criticism)g(is)h(based)h(up)q(on)f
(ignorance)996 1602 y(ab)q(out)12 b(the)h(strengths)h(of)e(the)h(alternativ)o
(es)f(and)g(of-)996 1652 y(ten)j(lev)o(eled)f(against)f(obsolete)h(systems.)
1038 1702 y(The)e(st)o(yle)f(of)g(programming)d(and)j(the)h(approac)o(h)996
1752 y(to)h(design)g(is)f(\(and)h(I)f(think)h(ough)o(t)f(to)g(b)q(e\))i
(strongly)996 1802 y(in\015uenced)21 b(b)o(y)e(the)h(language/system)e(used.)
35 b(In)996 1851 y(particular,)15 b(C++)h(design)g(t)o(ypically)e(has)h(a)g
(larger)996 1901 y(\\up)e(fron)o(t")g(design)g(e\013ort)h(than)e(Smalltalk)e
(design)996 1951 y(and)17 b(the)h(sp)q(eci\014cation)g(of)e(strongly)h(t)o
(yp)q(ed)g(in)o(ter-)996 2001 y(faces)g(is)f(usually)f(the)h(k)o(ey)g(elemen)
o(t)g(of)f(C++)i(pro-)996 2051 y(gramming.)29 b(Ignoring)18
b(fundamen)o(tal)f(di\013erences)996 2100 y(in)g(one's)h(basic)f(to)q(ols)g
(leads)g(to)h(p)q(o)q(or)f(design)h(and)996 2150 y(to)c(insu\016cien)o(t)g
(and)g(p)q(o)q(orly)f(structured)j(co)q(de.)1038 2200 y(The)21
b(c)o(hoice)g(of)e(language/system)g(c)o(hosen)j(for)996 2250
y(a)g(particular)f(job)g(should)g(b)q(e)i(done)f(with)f(a)g(de-)996
2300 y(gree)h(of)d(understanding)i(of)f(b)q(oth)h(the)g(strengths)996
2350 y(and)26 b(the)g(w)o(eaknesses)h(of)e(the)h(alternativ)o(e)f(lan-)996
2399 y(guages/systems.)h(In)16 b(the)i(few)e(cases)i(where)f(gen-)996
2449 y(uine)f(data)f(can)h(b)q(e)g(obtained)g(it)f(should)g(b)q(e)h(tak)o(en)
135 2573 y Fg(c)125 2574 y Ff(\015)d Fg(Cop)o(yrigh)o(t)h(1990)g(Douglas)h
(Johnson)1056 b Fk(12)p eop
%%Page: 13 13
bop 125 307 a Fk(seriously)21 b(and)g(not)h(just)f(dismissed)g(in)g(fa)o(v)o
(or)f(of)125 357 y(philosophical)12 b(arguemen)o(ts.)166 407
y(There)23 b(is)e(no)h(reason)g(to)g(b)q(eliev)o(e)g(that)g(a)f(sin-)125
457 y(gle)f(language/system)g(will)g(b)q(e)h(the)h(b)q(est)g(c)o(hoice)125
506 y(for)16 b(all)g(applications|ev)o(en)g(if)g(a)g(particular)h(user)125
556 y(ma)o(y)9 b(ha)o(v)o(e)j(the)h(luxury)e(of)g(w)o(orking)g(exclusiv)o
(ely)h(on)125 606 y(pro)r(jects)h(where)g(a)f(single)g(language/system)f(has)
h(a)125 656 y(fairly)g(constan)o(t)i(o)o(v)o(erall)f(adv)n(an)o(tage.)393
697 y(.)393 714 y(.)393 731 y(.)166 781 y(There)23 b(is)f(no)g
(language/system)e(in)i(existence)125 831 y(that)12 b(can)h(serv)o(e)g(the)g
(range)g(of)f(applications/needs)125 880 y(that)27 b(is)g(curren)o(tly)h
(serv)o(ed)h(b)o(y)e(v)n(arious)f(\\OOP)125 930 y(languages"|let)12
b(alone)h(the)i(range)f(of)f(needs)i(they)125 980 y(could)e(serv)o(e.)19
b(C++)13 b(and)g(Smalltalk)d(w)o(ere)15 b Fa(delib)n(er-)125
1030 y(ately)k Fk(placed)e(at)f(the)g(extremes)h(of)e(the)i(sp)q(ectrum)125
1080 y(of)d(reasonable)i(design)g(c)o(hoices)g(for)f(practical)h(lan-)125
1130 y(guages)10 b(at)f(the)i(times)e(they)i(w)o(ere)f(dev)o(elop)q(ed.)18
b(That)125 1179 y(mak)o(es)d(comparisons)h(b)q(et)o(w)o(een)j(them)d(in)o
(teresting)125 1229 y(\(but)j(tric)o(ky\))g(and)g(they)h(supp)q(ort)f(eac)o
(h)h(other)g(as)125 1279 y(m)o(uc)o(h)d(as)j(they)f(comp)q(ete)h(for)e
(resources.)37 b(I)19 b(con-)125 1329 y(jecture)i(that)g(there)g(are)g(man)o
(y)e(more)g(Smalltalk)125 1379 y(programmers)9 b(no)o(w)j(than)g(there)h(w)o
(ould)e(ha)o(v)o(e)h(b)q(een)125 1428 y(had)h(C++)i(not)e(existed|and)i(vice)
f(v)o(ersa.)135 2573 y Fg(c)125 2574 y Ff(\015)f Fg(Cop)o(yrigh)o(t)h(1990)g
(Douglas)h(Johnson)1056 b Fk(13)p eop
%%Trailer
end
userdict /end-hook known{end-hook}if
%%EOF

From info-dylan-request Wed Nov 18 15:42:31 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA17829; Wed, 18 Nov 92 15:42:32 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA17822; Wed, 18 Nov 92 15:42:31 -0500
Received: from postman.osf.org by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25030; Wed, 18 Nov 92 15:49:38 -0500
	for info-dylan@cambridge.apple.com
Received: from lakatos.osf.org by postman.osf.org (5.64+/OSF 1.0)
	id AA09915; Wed, 18 Nov 92 15:44:17 -0500
Received: by lakatos.osf.org (AIX 3.2/UCB 5.64/4.03)
          id AA15580; Wed, 18 Nov 1992 15:42:09 -0500
Date: Wed, 18 Nov 1992 15:42:09 -0500
Message-Id: <9211182042.AA15580@lakatos.osf.org>
To: alms@cambridge.apple.com
Cc: info-dylan@cambridge.apple.com
In-Reply-To: Andrew LM Shalit's message of Wed, 18 Nov 1992 11:23:07 -0500 <9211181613.AA07547@cambridge.apple.com>
Subject: #f = #none ?
From: Stavros Macrakis <macrakis@osf.org>
Sender: macrakis@osf.org

alms suggested:
   >    (bind ((no-value (cons #f #f)))
   >      (define-method true-false-dontcare (#key (arg no-value))
I replied:
   > 
   > Small problem here: there is no way to explicitly specify a don't care
   > value.  Correction: make no-value visible....  Do you like that
   > solution?  I don't.
alms continued:
   I don't see how you can have it both ways.  Either the don't care value
   is an explicit published part of the protocol, or it's not.

OK, so you export no-value as the no-value indicator.  But it does not
respect Dylan semantics ("in Dylan, all objects besides #f count as
true", p. 63).  I'd prefer to see #t represent True, #f represent
False, and anything else not be a boolean value at all.  Similarly,
#nothing should mean nothing, and #f should mean something, namely
boolean false.

From info-dylan-request Wed Nov 18 16:25:55 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19323; Wed, 18 Nov 92 16:25:56 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19319; Wed, 18 Nov 92 16:25:55 -0500
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25379; Wed, 18 Nov 92 16:32:53 -0500
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA16639; Wed, 18 Nov 92 16:27:25 EST
Message-Id: <9211182127.AA16639@MIT.EDU>
Date: Wed, 18 Nov 92 16:20:17 EST
From: cfry@MIT.EDU (Christopher Fry)
To: Stavros Macrakis <macrakis@osf.org>
Subject: Re: #f = #none ?
Cc: info-dylan@cambridge.apple.com

> Date: Wed, 18 Nov 1992 10:57:42 -0500
> To: info-dylan@cambridge.apple.com
> Subject: #f = #none ?
> From: Stavros Macrakis <macrakis@osf.org>
> Sender: macrakis@osf.org
> 
> Imagine a function which takes an optional argument which is to be
> True, False, or Dont-care.  Presumably if the argument is omitted, the
> value should be Dont-care.  How will we encode these values?  We can't
> use #f for False, because it also means that the argument isn't there.
> We could use #t for true, but we'll have to be careful, because all
> boolean functions in Dylan allow any non-#f value to represent
> True....
> 
> So perhaps we'll need to define a new type which takes values
> (singletons) True, False, and #f...  Seems silly, and error-prone.

This reminds me of a problem with CL. If Dylan doesn't address it, it 
should. For an argument in a function call, I would like to explicitly 
say  "use-the-default-value". 

From info-dylan-request Wed Nov 18 16:38:18 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19323; Wed, 18 Nov 92 16:25:56 -0500
Full-Name: 
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19319; Wed, 18 Nov 92 16:25:55 -0500
Received: from MIT.MIT.EDU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA25379; Wed, 18 Nov 92 16:32:53 -0500
	for info-dylan@cambridge.apple.com
Received: from KORUNA.MIT.EDU by MIT.EDU with SMTP
	id AA16639; Wed, 18 Nov 92 16:27:25 EST
Message-Id: <9211182127.AA16639@MIT.EDU>
Date: Wed, 18 Nov 92 16:20:17 EST
From: cfry@MIT.EDU (Christopher Fry)
To: Stavros Macrakis <macrakis@osf.org>
Subject: Re: #f = #none ?
Cc: info-dylan@cambridge.apple.com

> Date: Wed, 18 Nov 1992 10:57:42 -0500
> To: info-dylan@cambridge.apple.com
> Subject: #f = #none ?
> From: Stavros Macrakis <macrakis@osf.org>
> Sender: macrakis@osf.org
> 
> Imagine a function which takes an optional argument which is to be
> True, False, or Dont-care.  Presumably if the argument is omitted, the
> value should be Dont-care.  How will we encode these values?  We can't
> use #f for False, because it also means that the argument isn't there.
> We could use #t for true, but we'll have to be careful, because all
> boolean functions in Dylan allow any non-#f value to represent
> True....
> 
> So perhaps we'll need to define a new type which takes values
> (singletons) True, False, and #f...  Seems silly, and error-prone.

This reminds me of a problem with CL. If Dylan doesn't address it, it 
should. For an argument in a function call, I would like to explicitly 
say  "use-the-default-value". 

From info-dylan-request Wed Nov 18 18:14:27 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA24870; Wed, 18 Nov 92 18:14:28 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA24865; Wed, 18 Nov 92 18:14:27 -0500
Received: from goanna.cs.rmit.OZ.AU by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA00428; Wed, 18 Nov 92 18:21:32 -0500
	for info-dylan@cambridge.apple.com
Received: from [131.170.64.21] (thylacine.cs.rmit.OZ.AU) by goanna.cs.rmit.OZ.AU with SMTP id AA20591
  (5.65c/IDA-1.4.4 for <info-dylan@cambridge.apple.com>); Thu, 19 Nov 1992 10:15:55 +1100
Message-Id: <199211182315.AA20591@goanna.cs.rmit.OZ.AU>
Date: Thu, 19 Nov 1992 10:16:05 +1000
To: info-dylan@cambridge.apple.com, farrow@stephanie.hc.ti.com (Rob Farrow)
From: pnm@goanna.cs.rmit.oz.au
Subject: Re: Doug Johnson "On holy wars ...
Cc: pnm@goanna.cs.rmit.OZ.AU

Rob,

Thankyou so much for providing Doug Johnson's Paper.  In case I'm not the
only one, could someone please provide expansions on the following
acronyms?  I can make a (hazy) guess at two, but I'd rather not show my
total ignorance :-)

MMST ?
CIP?
CIM?


Thankyou,

Paul Menon
pnm@goanna.cs.rmit.oz.au
Computer Science, Royal Melbourne Institute of Technology,
124 La Trobe Street, Melbourne, Victoria 3001, Australia
Ph: +61 3 660 - 3209/2348	Fx: +61 3 662 1617


From info-dylan-request Wed Nov 18 23:39:04 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA02129; Wed, 18 Nov 92 23:39:08 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02125; Wed, 18 Nov 92 23:39:04 -0500
Received: from crl.dec.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA01001; Wed, 18 Nov 92 23:46:16 -0500
	for info-dylan@cambridge.apple.com
Received: by crl.dec.com; id AA02557; Wed, 18 Nov 92 23:40:53 -0500
Received: by easynet.crl.dec.com; id AA12443; Wed, 18 Nov 92 23:40:51 -0500
Message-Id: <9211190440.AA00758@taunton.crl.dec.com>
To: cfry@MIT.EDU (Christopher Fry)
Cc: Stavros Macrakis <macrakis@osf.org>, info-dylan@cambridge.apple.com
Subject: Re: #f = #none ? 
In-Reply-To: Your message of "Wed, 18 Nov 92 16:20:17 EST."             <9211182127.AA16639@MIT.EDU> 
Date: Wed, 18 Nov 92 23:40:50 -0500
From: Bob Kerns <rwk@crl.dec.com>
X-Mts: smtp

    Date: Wed, 18 Nov 92 16:20:17 EST
    From: cfry@MIT.EDU (Christopher Fry)
    
    This reminds me of a problem with CL. If Dylan doesn't address it, it 
    should. For an argument in a function call, I would like to explicitly 
    say  "use-the-default-value". 


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


From info-dylan-request Thu Nov 19 10:55:40 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18257; Thu, 19 Nov 92 10:55:43 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18253; Thu, 19 Nov 92 10:55:40 -0500
Received: from talcott.harvard.edu by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02048; Thu, 19 Nov 92 11:02:54 -0500
	for info-dylan@cambridge.apple.com
Received: by kurz-ai.com (MC 2.0/SMI-4.0)
	id AA13310; Thu, 19 Nov 92 10:19:54 EST
Received: by taiyo.kurz-ai.com (4.1/SMI-4.0)
	id AA16847; Thu, 19 Nov 92 10:18:44 EST
Date: Thu, 19 Nov 92 10:18:44 EST
From: samp@kurz-ai.com (Sam Pilato)
Message-Id: <9211191518.AA16847@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 Wed, 18 Nov 92 23:40:50 -0500
Subject: #f = #none ? 

   Date: Wed, 18 Nov 92 23:40:50 -0500
   From: Bob Kerns <rwk@crl.dec.com>
   X-Mts: smtp

       Date: Wed, 18 Nov 92 16:20:17 EST
       From: cfry@MIT.EDU (Christopher Fry)

       This reminds me of a problem with CL. If Dylan doesn't address it, it 
       should. For an argument in a function call, I would like to explicitly 
       say  "use-the-default-value". 


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

From info-dylan-request Thu Nov 19 10:59:15 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA18345; Thu, 19 Nov 92 10:59:20 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA18339; Thu, 19 Nov 92 10:59:15 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02052; Thu, 19 Nov 92 11:06:31 -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 AA23321; Thu, 19 Nov 92 10:03:56 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA25172; Thu, 19 Nov 1992 10:00:44 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA02846; Thu, 19 Nov 92 10:01:05 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA03125; Thu, 19 Nov 92 10:01:04 CST
Date: Thu, 19 Nov 92 10:01:04 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211191601.AA03125@stephanie.hc.ti.com>
To: pnm@goanna.cs.rmit.oz.au
Cc: info-dylan@cambridge.apple.com
In-Reply-To: pnm@goanna.cs.rmit.oz.au's message of Thu, 19 Nov 1992 10:16:05 +1000 <199211182315.AA20591@goanna.cs.rmit.OZ.AU>
Subject: Acronyms for Doug Johnson "On holy wars ...



>Thankyou so much for providing Doug Johnson's Paper.  In case I'm not the
>only one, could someone please provide expansions on the following
>acronyms?  I can make a (hazy) guess at two, but I'd rather not show my
>total ignorance :-)

>MMST ?
>CIP?
>CIM?


MMST = Microelectronics Manufacturing Science and Technology
CIP = Computer Integregrated Processing
CIM = Computer Integregrated Manufacturing

-- Rob

From info-dylan-request Thu Nov 19 11:35:45 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA19357; Thu, 19 Nov 92 11:35:49 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA19351; Thu, 19 Nov 92 11:35:45 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02326; Thu, 19 Nov 92 11:42: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 AA25046; Thu, 19 Nov 92 10:40:24 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA27278; Thu, 19 Nov 1992 10:37:12 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA03097; Thu, 19 Nov 92 10:37:33 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA03132; Thu, 19 Nov 92 10:37:32 CST
Date: Thu, 19 Nov 92 10:37:32 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211191637.AA03132@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: Capacity Alert.


I had ONE, poorly explained, complaint that the 146k postscript file I
mailed is TOO BIG for some.  I quess I have a 90's impression of big
and anything under 150k isn't it.  If this caused some of you grief
I'm sincerely sorry.

If someone, who understands where these problems arise (or has them),
would like to explain this to me I would be interested to hear it.  I
am by no means a Internet expert and this seems like an issue I should
have a feel for.  So what is NOT too big.  100k? 50k? 5k?

In the years I have used Internet I have never heard or had this
complaint.  Granted, I have always used it in places with plenty of
resources.  What are the guidelines for Internet use? Are there any?


-- Rob.

From info-dylan-request Thu Nov 19 11:57:22 1992
Received: by cambridge.apple.com (5.64/25-eef)
	id AA20495; Thu, 19 Nov 92 11:57:25 -0500
Received: from brazil.cambridge.apple.com by cambridge.apple.com with SMTP (5.64/25-eef)
	id AA20488; Thu, 19 Nov 92 11:57:22 -0500
Received: from ti.com by brazil.cambridge.apple.com with SMTP (5.64/25-eef)
	id AA02500; Thu, 19 Nov 92 12:04:38 -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 AA25800; Thu, 19 Nov 92 11:02:04 CST
Received: from hc.ti.com (sunspot.hc.ti.com) by tilde.csc.ti.com id AA28434; Thu, 19 Nov 1992 10:58:53 -0600
Received: from stephanie.hc.ti.com by hc.ti.com (4.1/SMI-4.1)
	id AA03189; Thu, 19 Nov 92 10:59:14 CST
Received: by stephanie.hc.ti.com (4.1/SMI-4.1)
	id AA03143; Thu, 19 Nov 92 10:59:14 CST
Date: Thu, 19 Nov 92 10:59:14 CST
From: farrow@stephanie.hc.ti.com (Rob Farrow)
Message-Id: <9211191659.AA03143@stephanie.hc.ti.com>
To: info-dylan@cambridge.apple.com
Subject: Re: Capacity Alert.




>You've probably got a bunch of replies already (if not, you will soon). Some
>mailers, either older ones or on systems that are old or (shudder) that
>gateway to networks like FIDOnet or other such systems (America Online,
>CompuServe, probably AppleLink) choke on messages after a certain size
>limit. Usually, that limit is around 32k. Most systems today do not have
>any such problem and unless someone complains it is hard to tell which
>systems will (unless you already know). The easiest way to split up a
>file is to use the split (UNIX) command. When I've had to do this I tend to
>make my splits at around 30k chunks to play it safe.

Thanks Ken,

You were the first.  Ok 32k.  Does everyone agree with that?
If I don't hear from anyone else I'll assume that is ok.  Sorry for
taking time on this mailing list to bring this up.

-- Rob



