Dylan Interim Reference Manual now available 
Author Message
 Dylan Interim Reference Manual now available

Quote:

>I suspect that people will (like me) want clarification as follows:

>Does "It combines the original Dylan book, ..." mean that a large fraction
>of the file is an unedited replica of the original book?

No.  I updated the Dylan 1992 book throughout, integrating the design
changes as of May 1994 into the original text.  I don't think there was a
page of the original book left untouched.

Quote:
>How many printed pages is the interim manual?

214 pages including title page and front matter.

Quote:
>How many megabytes to download?

The .ps file is around 1055K.
The .rtf file is around 525K.

Quote:
>Are the fonts included in the .ps file; if not, what fonts are used?

The fonts are not included in the .ps file.
The fonts used are Palatino and Courier.

Finally, those of you who have color printers may want to print the title
page in color!

    Orca Starbuck



Sat, 23 Nov 1996 00:20:47 GMT  
 Dylan Interim Reference Manual now available

Quote:

> When the first Dylan manual was published in 1992, it was met with an
> enthusiastic response.  People agreed with our goals for the language,

The first manual said Dylan was a dialect of Lisp.

Quote:
> The language has become simpler and more efficient.

The syntax has become far more complex.  

Quote:
>            Apple is working closely with other Dylan
> implementors to ensure that the new book will not be Apple-specific, but
> will apply equally to all Dylan implementations.

Apple is working closely with "Dylan Partners".  It would be unfortunate
if those were the only implementations.


Sat, 23 Nov 1996 00:04:58 GMT  
 Dylan Interim Reference Manual now available

Quote:

>> When the first Dylan manual was published in 1992, it was met with an
>> enthusiastic response.  People agreed with our goals for the language,

>The first manual said Dylan was a dialect of Lisp.

Let's examine that statement in context.  In David Moon's Introduction, he said:

"Dylan is a simple dialect of Lisp with a thoroughly integrated object model.
... To those familiar with the Lisp family of languages, Dylan looks like
Scheme augmented with CLOS.  However, 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."

In my Foreword, which preceded Moon's Introduction, I said (among other
things) that Dylan would:

- combine the best aspects of Lisp and Smalltalk
- provide static language users an attractive dynamic alternative
- be more like Lisp than Smalltalk, except it would be "objects all the way
down"

Yes, Dylan is in some sense a dialect of LISP.  Its primary syntax is more
like McCarthy's m-expressions than his s-expressions (see the seminal
paper, which I think was called "Recursive Functions of Symbolic
Expressions")..

Quote:
>> The language has become simpler and more efficient.

>The syntax has become far more complex.

In my Foreword, I also said:

"By providing alternate syntaxes atop the extremely neutral base of Lisp,
we believed we could present a familiar face not only to Lisp programmers,
but also to those accustomed to other syntaxes, including Smalltalk's."

That is truly what we believed when the project started in 1987.  But by
1993, we encountered practical problems in supporting multiple syntaxes
with equal stature.  After extensive consultation with many people,
including those in this newsgroup, we saw that there was no broad consensus
as to what to do.  Recalling the goals stated in the front of the book, we
decided to emphasize the syntactic style that we believed would appeal to
the largest fraction of the target audience.

Other people are welcome to provide alternate syntaxes.  For certain
alternate syntaxes, the macro facility may be useful in accomplishing this
end.  For others, the mechanisms underlying implementations of that
facility may be useful.

Many people feel that fully parenthesized prefix S-expressions are a
simpler syntax than precedence-based Algol-like infix expressions.  To
their perception, Lisp-like syntax is simpler, and it may be surprising
that other people might not find it so.  Our surveys show that the
overwhelming majority of our target audience strongly prefers the
Algol-like style.  I hope that those who prefer the Lisp-like style will
build tools to make it available to like-minded souls.

Quote:
>>            Apple is working closely with other Dylan
>> implementors to ensure that the new book will not be Apple-specific, but
>> will apply equally to all Dylan implementations.

>Apple is working closely with "Dylan Partners".  It would be unfortunate
>if those were the only implementations.

There are too many people around who love to implement languages for me to
be concerned about that outcome.

Larry

Quote:
>************************************************************
>Larry Tesler, Chief Scientist, Apple Computer, Inc.
>USMail: 1 Infinite Loop, MS: 301-4I, Cupertino, CA, 95014

>Phone: (408) 974-2219, Fax: (408) 974-1794
>************************************************************



Mon, 25 Nov 1996 01:54:54 GMT  
 Dylan Interim Reference Manual now available

Quote:
Larry Tesler writes:


> >> When the first Dylan manual was published in 1992, it was met with an
> >> enthusiastic response.  People agreed with our goals for the language,

> >The first manual said Dylan was a dialect of Lisp.

> Let's examine that statement in context.
> [...]
> Yes, Dylan is in some sense a dialect of LISP.  Its primary syntax is more
> like McCarthy's m-expressions than his s-expressions (see the seminal
> paper, which I think was called "Recursive Functions of Symbolic
> Expressions")..

I'm not saying that New Dylan is a dialect of Lisp (regardless of
what I actually think, which I haven't said), only that Dylan Classic
was fairly uncontroversially a dialect of Lisp.  The old book did
not disagree with this.  It even said Dylan was a dialect of Lisp.
I see nothing in the context you quoted that indicates otherwise.

Now look again at the statement I was replying to.  

If we're going to have some history of Dylan, it should be the true
history, including the discontinuities and conflicts.

My point is simply that the enthusiastic response in 1992 and
agreement with goals was response to a different language and
agreement with different goals.  (For one thing, the goals were
goals for a dialect of Lisp.)

A number of people who were enthusiastic in 1992 are less enthusiastic
now.  Likewise, some people who were unimpressed in 1992 may be more
enthusiastic now.  There's nothing wrong with that.  Reasonable people
can reasonably prefer different things.

Quote:
> >>            Apple is working closely with other Dylan
> >> implementors to ensure that the new book will not be Apple-specific, but
> >> will apply equally to all Dylan implementations.

> >Apple is working closely with "Dylan Partners".  It would be unfortunate
> >if those were the only implementations.

> There are too many people around who love to implement languages for me to
> be concerned about that outcome.

If Apple is working closely only with some implementors, how does
that ensure the new book will apply equally to all implementations?
This is not a rhetorical question.

-- jd



Mon, 25 Nov 1996 03:44:44 GMT  
 Dylan Interim Reference Manual now available
Unless someone other than Jeff shares the opinions he expresses here, this
is my last message on this subject that I will cc to info-dylan.


Quote:
>Larry Tesler writes:



>> >> When the first Dylan manual was published in 1992, it was met with an
>> >> enthusiastic response.  People agreed with our goals for the language,

>> >The first manual said Dylan was a dialect of Lisp.

>> Let's examine that statement in context.

>> [...]

>> Yes, Dylan is in some sense a dialect of LISP.  Its primary syntax is more
>> like McCarthy's m-expressions than his s-expressions (see the seminal
>> paper, which I think was called "Recursive Functions of Symbolic
>> Expressions")..

>I'm not saying that New Dylan is a dialect of Lisp (regardless of
>what I actually think, which I haven't said), only that Dylan Classic
>was fairly uncontroversially a dialect of Lisp.  The old book did
>not disagree with this.  It even said Dylan was a dialect of Lisp.
>I see nothing in the context you quoted that indicates otherwise.

Now you have quoted us TWICE out of context.  The part that you elided
above using [...] said:

Quote:
>>In David Moon's Introduction, he said:

>>"Dylan is a simple dialect of Lisp with a thoroughly integrated object model.
>>... To those familiar with the Lisp family of languages, Dylan looks like
>>Scheme augmented with CLOS.  However, 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."

>>In my Foreword, which preceded Moon's Introduction, I said (among other
>>things) that Dylan would:

>>- combine the best aspects of Lisp and Smalltalk
>>- provide static language users an attractive dynamic alternative
>>- be more like Lisp than Smalltalk, except it would be "objects all the way
>>down"

You are welcome to take the phrase "Dylan is a simple dialect of Lisp" out
of context as you have, to propose an interpretation for that phrase, and
to hypothesize implications of your interpretation.  But when those
implications turn out to contradict other statements in the same book--even
statements in the same paragraph, then instead of ignoring those other
statements, you might instead reexamine your interpretation.

In response to Orca's assertion:

Quote:
>> When the first Dylan manual was published in 1992, it was met with an
>> enthusiastic response.  People agreed with our goals for the language,

you responded:

Quote:
>The first manual said Dylan was a dialect of Lisp.

By this, did you mean, "A goal of Dylan, according to the original manual,
was to be a dialect of LISP."  I thought you meant that, and that was what
I was responding to.

Moon did not say that being a dialect of LISP was a __goal__ of Dylan.  He
just said that Dylan __happened to be__ a simple dialect of LISP, with
stated qualifications.

Moon did not say that it was a goal to make the __syntax__ of Dylan like
that of Common LISP or SCHEME.  Other dialects of LISP have syntaxes that
are not parenthesis-prefix, e.g., MLISP and other LISPs inspired by the
m-expressions of McCarthy's original paper.

What Moon said, as quoted above, was (emphasis added here):

Quote:
>>      However [ i.e., despite looking like SCHEME, a dialect of LISP ],
>>      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.

This statement, appearing right after the "simple dialect" statement, was
intended to ensure that nobody misinterpreted the resemblances to SCHEME as
implying that one _goal__ of Dylan was to be a dialect of LISP.  There were
other things in the front matter that were clearly identified as the goals
of Dylan.

Quote:
>Now look again at the statement I was replying to.

>If we're going to have some history of Dylan, it should be the true
>history, including the discontinuities and conflicts.

Orca did not claim unanimous agreement with every goal by every
constituency.  That never happens in human society.

Quote:
>My point is simply that the enthusiastic response in 1992 and
>agreement with goals was response to a different language and
>agreement with different goals.  (For one thing, the goals were
>goals for a dialect of Lisp.)

The goals of Dylan were not goals __for__ a dialect of Lisp.  They were
goals met __by__ dialect of LISP (a simple dialect, more like SCHEME than
like LISP, and with features of Smalltalk) that was __always__ intended to
have a syntax friendly to the target audience: "developers now using
languages such as C, C++, and Pascal."

Quote:
>A number of people who were enthusiastic in 1992 are less enthusiastic
>now.  Likewise, some people who were unimpressed in 1992 may be more
>enthusiastic now.  There's nothing wrong with that.  Reasonable people
>can reasonably prefer different things.

I can agree with that.  What really matters is how enthusiastic people
become when they see a Dylan implementation in action (as they did at WWDC,
to enthusiastic response), when they undertake implementations (which is
happening now), and when they actually use a mature implementation to get
work done (which is some time off).

Quote:
>> >>            Apple is working closely with other Dylan
>> >> implementors to ensure that the new book will not be Apple-specific, but
>> >> will apply equally to all Dylan implementations.

>> >Apple is working closely with "Dylan Partners".  It would be unfortunate
>> >if those were the only implementations.

>> There are too many people around who love to implement languages for me to
>> be concerned about that outcome.

>If Apple is working closely only with some implementors, how does
>that ensure the new book will apply equally to all implementations?
>This is not a rhetorical question.

It is impossible logistically for Apple to work closely with all potential
implementors.  No designers of a successful language has ever worked
closely with all potential implementors.

Language implementors love to implement cool new languages, even in the
hypothetical situation that the language spec does not apply equally to all
of them (cf. K&R C implemented on non-Unix platforms).

Larry

- Show quoted text -

Quote:
>************************************************************
>Larry Tesler, Chief Scientist, Apple Computer, Inc.
>USMail: 1 Infinite Loop, MS: 301-4I, Cupertino, CA, 95014

>Phone: (408) 974-2219, Fax: (408) 974-1794
>************************************************************



Sat, 30 Nov 1996 10:43:28 GMT  
 Dylan Interim Reference Manual now available
Just a note of support. Recently there seems to have been a
significant amount of negative and hair-splitting comments here.

My understanding is that the primary goal of Dylan is to create a
dynamic language which will allow most of the benefits of a Dynamic
development environment with the code quality of C++. I was
enthusiastic about this goal in 1992 and I am even more enthusiastic
about it now.

If Dylan needs to make some compromises in either its syntax or macro
facility or any other feature to make it accepable, then so be it.
Dylan will fail unless it is able to address the same group of
developers and managers that C++ has won over.  While we may be in
love with certain features from our favorite languages, like Lisp,
thats too bad -  because the reality is that every dynamic language
to date has failed to reach the mainstream and dynamic languages will
continue to fail until one is "smart" enough to make the tough and
often unpopular compromises that the Dylan group has struggled with.

I eagerly look forward to the early releases of Dylan, to be a part
of helping Dynamic languages become accepted, and to do my share of
helping to fine-tune Dylan and to make it the success it deserves.

Thanks Dylan Group,

Jeffrey W. Stulin



Sat, 30 Nov 1996 23:08:02 GMT  
 Dylan Interim Reference Manual now available

Quote:
> Unless someone other than Jeff shares the opinions he expresses here, this
> is my last message on this subject that I will cc to info-dylan.

So far as I can tell from the rest of your message, *you* agree
with most of what I said (though not with what you thought I said).

Quote:
> >> Yes, Dylan is in some sense a dialect of LISP.  Its primary syntax is more
> >> like McCarthy's m-expressions than his s-expressions (see the seminal
> >> paper, which I think was called "Recursive Functions of Symbolic
> >> Expressions")..

> >I'm not saying that New Dylan is a dialect of Lisp (regardless of
> >what I actually think, which I haven't said), only that Dylan Classic
> >was fairly uncontroversially a dialect of Lisp.  The old book did
> >not disagree with this.  It even said Dylan was a dialect of Lisp.
> >I see nothing in the context you quoted that indicates otherwise.

> Now you have quoted us TWICE out of context.  The part that you elided
> above using [...] said:

I'm sorry, but I have not done anything intellectually dishonest.
So far as I can tell, the context does not show anything wrong with
my interpretation of "Dylan is a simple dialect of Lisp with a
thoroughly integrated object model" as including that Dylan is a
dialect of Lisp.

Now what is it about the context that you think shows my interpretation
is wrong?  I honestly cannot tell what you are talking about.  Indeed,
so far as I can tell from what you say later on, you don't even disagree
with my interpretation.

  In David Moon's Introduction, he said: [...]

  In my Foreword, which preceded Moon's Introduction, I said [...]

I happen to think it's reasonable to quote an Introduction without
supplying context from the Foreward, BTW.  (This it not to say
context from the Foreward cannot be significant, but omitting it
is not what's usually meant by "quoting out of context".)

Quote:
> You are welcome to take the phrase "Dylan is a simple dialect of Lisp" out
> of context as you have, to propose an interpretation for that phrase, and
> to hypothesize implications of your interpretation.

So far as I can tell my interpretation is a perfectly natural one in
context or out.  "Dylan is a simple dialect of Lisp" means that Dylan
is a simple dialect of Lisp.  That my interpretation is natural is
shown by the fact that I can state it simply by removing the quotes.

I'm not sure what you have in mind by "implications".  Sure, in my

  The first manual said Dylan was a dialect of Lisp.

Since this was rather short and cryptic, I've explained several times
now, to various people, what I had in mind, namely that original 1992
enthusiasms did not always carry over.  My evidence for _that_ has
nothing to do with the manual apart from it's role as a description
of Dylan, and it would be true even if the manual had said in flashing
pink letters three feet high that Dylan was _not_ a dialect of Lisp,
for saying doesn't make it so.

Quote:
> But when those
> implications turn out to contradict other statements in the same book--even
> statements in the same paragraph, then instead of ignoring those other
> statements, you might instead reexamine your interpretation.

Which other statements?

I have read, reread, and reread again all of the context you supplied.
I have not ignored it.  I cannot tell what you think contradicts my
interpretation.  So far as I can tell, everything is completely
consistent with my interpretation and indeed makes the contrary
interpretation seem forced at best.

Quote:
> In response to Orca's assertion:

> >> When the first Dylan manual was published in 1992, it was met with an
> >> enthusiastic response.  People agreed with our goals for the language,

> you responded:

> >The first manual said Dylan was a dialect of Lisp.

> By this, did you mean, "A goal of Dylan, according to the original manual,
> was to be a dialect of LISP."  I thought you meant that, and that was what
> I was responding to.

I though it was a description, not a goal.

Moreover, I explained what I meant w.r.t. "goals": they were goals _for_
a dialect of Lisp.  (Hence not that "being a dialect of Lisp" was a goal.)

  Dylan is a simple dialect of Lisp with a thoroughly integrated
  object model.

That looked like a description to me.  When I looked at the rest of
the manual and the language it described, I found it to be a true
description as well.

Quote:
> Moon did not say that being a dialect of LISP was a __goal__ of Dylan.  He
> just said that Dylan __happened to be__ a simple dialect of LISP, with
> stated qualifications.

Is that what this is all about?  A trivial misunderstanding?
Well, if so, I'm glad to hear it.

Anyway, in the end it looks like you actually agree with me that Dylan
Classic was a dialect of Lisp (or at least that the manual said it was).

Quote:
> Moon did not say that it was a goal to make the __syntax__ of Dylan like
> that of Common LISP or SCHEME.  Other dialects of LISP have syntaxes that
> are not parenthesis-prefix, e.g., MLISP and other LISPs inspired by the
> m-expressions of McCarthy's original paper.

Sure, and I made the same point myself (a while back) when saying that
merely having a non-paren syntax did not disqualify something from being
a Lisp.

Quote:
> What Moon said, as quoted above, was (emphasis added here):

> >>      However [ i.e., despite looking like SCHEME, a dialect of LISP ],
> >>      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.

> This statement, appearing right after the "simple dialect" statement, was
> intended to ensure that nobody misinterpreted the resemblances to SCHEME as
> implying that one _goal__ of Dylan was to be a dialect of LISP.  There were
> other things in the front matter that were clearly identified as the goals
> of Dylan.

Of course, and I have never said otherwise!

Quote:
> >Now look again at the statement I was replying to.

> >If we're going to have some history of Dylan, it should be the true
> >history, including the discontinuities and conflicts.

> Orca did not claim unanimous agreement with every goal by every
> constituency.  That never happens in human society.

It's clear what impression Orca was trying to convey.  I'm sugesting
a different impression, sure, but not because we lacked _unanimous_
agreement.

Quote:
> >My point is simply that the enthusiastic response in 1992 and
> >agreement with goals was response to a different language and
> >agreement with different goals.  (For one thing, the goals were
> >goals for a dialect of Lisp.)

> The goals of Dylan were not goals __for__ a dialect of Lisp.

Yes they were, because they were goals for Dylan and Dylan was
a dialect of Lisp.

I guess it's the phrase "goals for X" that's causing the problem.
I meant it as if short for "goals for X to achieve".

Quote:
> They were goals met __by__ dialect of LISP

So, in the end, you agree with me.

Quote:
> (a simple dialect, more like SCHEME than
> like LISP, and with features of Smalltalk) that was __always__ intended to
> have a syntax friendly to the target audience: "developers now using
> languages such as C, C++, and Pascal."

Was it always intended to have _only_ that syntax?  That's not how
it's looked to me.

Quote:
> >A number of people who were enthusiastic in 1992 are less enthusiastic
> >now.  Likewise, some people who were unimpressed in 1992 may be more
> >enthusiastic now.  There's nothing wrong with that.  Reasonable people
> >can reasonably prefer different things.

> I can agree with that.  What really matters is how enthusiastic people
> become when they see a Dylan implementation in action (as they did at WWDC,
> to enthusiastic response), when they undertake implementations (which is
> happening now), and when they actually use a mature implementation to get
> work done (which is some time off).

Fair enough.

-- jeff



Sun, 01 Dec 1996 00:48:41 GMT  
 Dylan Interim Reference Manual now available

Quote:

> Date: 14 Jun 1994 11:08:02 -0400
> Just a note of support. Recently there seems to have been a
> significant amount of negative and hair-splitting comments here.

You are entitled to your views, of course, and as I said before

  A number of people who were enthusiastic in 1992 are less enthusiastic
  now.  Likewise, some people who were unimpressed in 1992 may be more
  enthusiastic now.  [And surely some could be enthusiastic then and
  now.]  There's nothing wrong with that.  Reasonable people
  can reasonably prefer different things.

But the idea that people who would prefer a different Dylan should
just keep this to themselves and not tell anyone seems rather odd to
me.

Quote:
> My understanding is that the primary goal of Dylan is to create a
> dynamic language which will allow most of the benefits of a Dynamic
> development environment with the code quality of C++. I was
> enthusiastic about this goal in 1992 and I am even more enthusiastic
> about it now.

But that goal -- code quality -- does not require any particular
syntax or a weak macro system.

Quote:
> If Dylan needs to make some compromises in either its syntax or macro
> facility or any other feature to make it accepable, then so be it.

Who said anything about compromises in the macro system to make
Dylan more acceptable?

How come you're using this "acceptable" line specifically against
macros but not against garbage collection or dynamic typing or even
multi-arg method dispatch?  All of those things have been strongly
criticized by a number of people in the C++ camp.

Quote:
> Dylan will fail unless it is able to address the same group of
> developers and managers that C++ has won over.  While we may be in
> love with certain features from our favorite languages, like Lisp,
> thats too bad -  because the reality is that every dynamic language
> to date has failed to reach the mainstream and dynamic languages will
> continue to fail until one is "smart" enough to make the tough and
> often unpopular compromises that the Dylan group has struggled with.

Tough but unpopular compromises like having "end X" instead of "}"?
How is that supposed to win over C++ folk?

Compromises like tossing out the Classic syntax?  Why is that a
_compromise_?  Why is it even unpopular?  I thought the idea was
to appeal to a larger group, and hence be more popular.

Let's not let rhetoric carry us away.

Quote:
> I eagerly look forward to the early releases of Dylan [...]

To my mind, this is by far the biggest problem with Dylan.  It
takes a very long time for things like the new syntax -- and now
macros -- to arrive.  Indeed, so far as I know, no new-syntax
implementations are available.

The second biggest problme in my view is that implementors seem
to be aiming for Big Environment implementations.

I say this not wearing my Lisp hat but by C hat, which I still
wear from time to time.

-- jd



Sun, 01 Dec 1996 02:39:59 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Dylan Interim Reference Manual now available

2. Dylan Interim Manual available via WWW

3. Book FS: Dylan Reference Manual, by Andrew Shalit.

4. How update of Dylan reference manual?

5. How update of Dylan reference manual?

6. Dylan Reference Manual questions

7. Dylan Reference Manual and MacWorld

8. Dylan Reference Manual online now

9. Dylan Reference Manual

10. Interim release of manuals? comments please

11. Interim Manual: a few notes

12. C/C++ Warm Fuzzy Feelings.... Dylan-Interim

 

 
Powered by phpBB® Forum Software