dylan, Info Dylan Digest V1 #177

Cory Kem
#1 / 34

Info Dylan Digest V1 #177

Quote:

>Date: Sun, 5 Dec 1993 23:53:49 GMT

>Subject: Algol and dylan

>I feel that an Algol-based syntax would cause the following changes
>that could take some of the 'punch' of Dylan:

>1) an Algol syntax would downplay the dynamic enviroment that Dylan is
>(ie, don't use a procedural paradigm for a non-procedural language)

I could come back with "A Lisp syntax downplays the idea that Dylan is
supposed to be a production language for writing real-world applications,
not an academic experiment", but that wouldn't prove anything beyond the
fact that I don't like to type Lots of Insignificant Silly Parentheses.

Quote:

>2) Why use not use Algol if you want that syntax?

Alternatively, "Why not use Lisp if you want that syntax?"

I don't want to use Algol. I want a dynamic object oriented language.

I fail to see how typing:

(define-class <point> (<object>)
(horizontal
type: <integer>
init-value: 0
init-keyword: horizontal:
)
(vertical
type: <integer>
init-value: 0
init-keyword: vertical:
)
)

(define my-point (make <point> horizontal: 123 vertical: 456))

((setter horizontal) my-point 789)

is somehow superior to typing something like:

class Point : object {
integer horizontal;
integer vertical;
Point(void) {
horizontal = 0;
vertical = 0;
}
Point(h, v) {
horizontal = h;
vertical = v;
}
};

Point MyPoint(123,456);

MyPoint->horizontal = 789;

I can see that the second requires less typing, and to me is significantly
clearer as to the meaning. I am sure to a Lisp fan, the first would be
clearer.

Can anyone provide a concrete example (that will not get shot down in 10
seconds) of why one syntax is supposedly better than the other? Or can we
all agree that a debate on the subject is silly, that some people prefer
one style over the other, and that the same things can be said in both
styles?

At which point, I can re-ask my original question: what is the status of
the Algol-style sytnax that was mentioned in the Dylan manual? Where can I
get information on it?

+C

What's a libertarian? That's an American who realizes this isn't
America anymore.
-------------------------------------------------------------
Cory Kempf

Sat, 25 May 1996 23:13:37 GMT

Franklyn Turb
#2 / 34

Info Dylan Digest V1 #177

Quote:

> Date: Tue, 7 Dec 1993 10:13:37 -0500

> Subject: Re: Info Dylan Digest V1 #177

> Can anyone provide a concrete example (that will not get shot down in 10
> seconds) of why one syntax is supposedly better than the other? Or can we
> all agree that a debate on the subject is silly, that some people prefer
> one style over the other, and that the same things can be said in both
> styles?

Though I agree that most of the debate about syntax is silly, I think
there are two important advantages of the s-expression syntax:

(1) S-expressions facilitate the writing of programs that manipulate
other programs -- interpreters, compilers, source-to-source
transformers, etc. These programs are messier in the Algol syntax
because of the need to parse code to and unparse code from some
abstract syntax tree data structure.

(2) S-expressions facilitate the expression of macros, an important
special case of a source-to-source transform. For example,
the Scheme LET construct, (let ((<name> <val>)*) <body>*), can
be defined in most versions of Scheme by a simple macro:

(define-macro (let bindings . body-exps)

The backquotes and commas are Scheme features make it easy
to fill in the holes of a template s-expression with the results of
arbitrary computations. Macros are harder to handle in an Algol syntax
because they have to interface with the parser.
(In my book, C's string-based preprocessing macros aren't a reasonable
option because they're not guaranteed to preserve the tree structure of
the program.)

Whether these advantages are important to the average Dylan programmer
is a separate question.

- lyn -

Sun, 26 May 1996 03:06:42 GMT

Patrick Log
#3 / 34

Info Dylan Digest V1 #177

Date: Tue, 7 Dec 1993 10:13:37 -0500

> I fail to see how typing:
>
> (define-class <point> (<object>)
> (horizontal
> type: <integer>
> init-value: 0
> init-keyword: horizontal:
> )
> (vertical
> type: <integer>
> init-value: 0
> init-keyword: vertical:
> )
> )
>
> (define my-point (make <point> horizontal: 123 vertical: 456))
>
> ((setter horizontal) my-point 789)
>
> is somehow superior to typing something like:
>
> class Point : object {
> integer horizontal;
> integer vertical;
> Point(void) {
> horizontal = 0;
> vertical = 0;
> }
> Point(h, v) {
> horizontal = h;
> vertical = v;
> }
> };
>
> Point MyPoint(123,456);
>
> MyPoint->horizontal = 789;
>
> I can see that the second requires less typing, and to me is significantly
> clearer as to the meaning. I am sure to a Lisp fan, the first would be
> clearer.

Besides human readability, there is the fact that the Lisp syntax can
be read into Lisp and manipulated. Also it can be more easily
manipulated (parsed) by text editors, e.g. Emacs.

That is not to say the same cannot be done for other syntaxes. But we
(the general Dylan population) know almost nothing about Dylan's new
syntax.

> Can anyone provide a concrete example (that will not get shot down in 10
> seconds) of why one syntax is supposedly better than the other? Or can we
> all agree that a debate on the subject is silly, that some people prefer
> one style over the other, and that the same things can be said in both
> styles?

No, it is not silly. Yes, some prefer one over the other. Yes, two
syntaxes can be defined such that the same thing can be said in both.
Can't say anything specific about Dylan's two syntaxes though, because
only one is widely known.

Sat, 25 May 1996 18:41:18 GMT

William M. Yo
#4 / 34

Info Dylan Digest V1 #177

I fail to see how typing:

(define-class <point> (<object>)
(horizontal
type: <integer>
init-value: 0
init-keyword: horizontal:
)
(vertical
type: <integer>
init-value: 0
init-keyword: vertical:
)
)

(define my-point (make <point> horizontal: 123 vertical: 456))

((setter horizontal) my-point 789)

is somehow superior to typing something like:

class Point : object {
integer horizontal;
integer vertical;
Point(void) {
horizontal = 0;
vertical = 0;
}
Point(h, v) {
horizontal = h;
vertical = v;
}
};

Can anyone provide a concrete example (that will not get shot down in 10
seconds) of why one syntax is supposedly better than the other? Or can we
all agree that a debate on the subject is silly, that some people prefer
one style over the other, and that the same things can be said in both
styles?

Here is my argument (my apologies for the Lisp-rather-than-Dylan-ness):

(defmacro define-integer-slots-class (name slots)
`(define-class ,name ()

`(,slot :type 'integer :init-value 0 :init-keyword ':horizontal))
slots)))

(define-integer-slots-class point (horizontal vertical))
(define-integer-slots-class frob (length width depth weight))

The value isn't in the exact defmacro form I wrote, it is in the
ability of the language to manipulate itself, which is enabled by the
uniform syntax. Adding the define-integer-slots-class form to the
language is an admittedly contrived example that I hope you can
generalize from.

Sun, 26 May 1996 06:27:58 GMT

Jeff Dalt
#5 / 34

Info Dylan Digest V1 #177

Quote:

> I fail to see how typing:
> [some Lisp syntax, indented as if it were C]
> is somehow superior to typing something like:
> [some C-like syntax, indented as if it were C]

Of course, if you deliberately make them look as much alike ad
you can, there's not much difference, but that cuts both ways.

Quote:

> I can see that the second requires less typing, and to me is significantly
> clearer as to the meaning. I am sure to a Lisp fan, the first would be
> clearer.

I don't find that Lisp requires more typing. I have used many
different languages, and I find the Lisp syhtax more readable
than the others. This is not just opinion, but neither is it
something about which everyone must agree on pain of being
irrational (or something like that).

Quote:

> Can anyone provide a concrete example (that will not get shot down in 10
> seconds) of why one syntax is supposedly better than the other?

Not to anyone with a closed mind. I don't know whether you have
a closed mind or not, bu tyou don't seem interesting in learning
why people who prefer Lisp syntax prefer it.

In any case, since we don't know what the non-Lisp syntax for
Dylan is, there's not point in such comparisons.

Quote:

> Or can we
> all agree that a debate on the subject is silly, that some people prefer
> one style over the other, and that the same things can be said in both
> styles?

Sure. And it's also true that Lisp syntax doesn't rely on operator
precedence, doesn't overload special syntax such as -> so that it
can mean anything (cf C++), etc. Other people can still reasonably
prefer a different syntax.

-- jd

Sun, 26 May 1996 02:00:18 GMT

Jonathan Sobe
#6 / 34

Info Dylan Digest V1 #177

Quote:

>(2) S-expressions facilitate the expression of macros....

I've seen this argument often enough that I think it's finally time to
respond to it.

This past spring, I had to write some programs in Scheme using TRULY
heavy-duty macros for the first time. One thing I had to come to
terms with was the fact that the stuff that comes in to the
interpreter/compiler from the user is NOT lists. Oh, sure, it looks
just like the lists that you use for data, but it's not the same
thing! (Lisp syntax actually contributes to the confusion on this
issue, IMHO, but that part is arguable.)

What you are manipulating when you write macros is not lists, but
SYNTAX. The fact that some macro systems might use the same
operators for the two should not lead you to believe they are the
same. If you want really powerful and very secure macros, you have to
use a system that makes the distinction. (See several papers by Dybvig,
et al.) Furthermore, once you've made this distinction, you realize
that the way you manipulate the syntax is independent of the way it
looked when the user originally entered it.

Even in Lisp-family languages, the program text has already been
scanned and parsed by the system reader by the time it reaches your
macros. At that point, you DO have an abstract syntax tree. If the
writer of the interpreter/compiler decided to use lists for his/her
syntax tree representation, that's an implementation detail. The
tools you use to manipulate the tree should not depend on the
implementation of the particular compiler you happen to be using.

So, since the things you transform using macros are abstract syntax
trees anyway, how could you tell what the original syntax was? I can
(and have) written scanners/parsers for several external, concrete
syntaxes which generate exactly the same abstract syntax trees. Using
the right macro systems, you can write a single set of macros which
work for all the concrete syntaxes.

All this is to say that Dylan can (and will) have perfectly reasonable
and extremely powerful macros EVEN IN AN INFIX SYNTAX!

Jonathan Sobel

P.S. I didn't mean for this note to sound inflammatory. There's no a
priori reason anyone should already know all this stuff. It's not
intuitive.

Mon, 27 May 1996 00:17:14 GMT

Nicholas C. Weav
#7 / 34

Info Dylan Digest V1 #177

Pardon me if this is inappropriate, but a few observations on the
differing syntax.

A Lisp like (prefix) syntax does several things more elegantly then
the infix/function syntax. These are:

The handling of multiple return values, and multiple arguments to
basic arithmetic operations. EG, a function which can return multiple
numbers (using values) in a Dylan (old syntax) can be summed up
quite painlessly, by (+ (function)).

It also allows easy treatment of functions as data. If it`s the
first thing in the list, it's the function, if not, data for the function.

It works well in editors. It doesn't take much (or hardly any)
brains to make a good interactive LISP editor, which handles all your
indenting, formatting, etc, in a quick and painless manner. It's much
harder to fancy-format a language like C, which uses brackets to delimit
blocks, or even worse, languages which use kewords (such as end) to delimit
blocks.

It's consistant. Prefix or postfix (RPN) notation lacks any
ambiguities about order of operation.

In any case, I realize that other people prefer an algol like
syntax. (I guess it might be like using RPN calculators. Making the
transistion is difficult, but if you do, you refuse to go back). The simple
solution is keep both syntaxs standard. A programmer should choose which
form he/she wants to use. The Lisp heads (like me) can use a nice,
consistant, elegant, lisp-like syntax. Those who prefer C/C++ syntax can
use their own syntax. The Marketing gurus can sell the Algol-like syntax.
Both syntaxes should be official, although Apple can market the Algol syntax
into the grould, as long as the Lisp-like syntax is also official.

--

I would sit, and draw things that could never be.
If I could write like the poet,
I would sit, and write of things that never were.

Mon, 27 May 1996 03:57:55 GMT

Daniel LaLiber
#8 / 34

Info Dylan Digest V1 #177

I fail to see how typing:

(define-class <point> (<object>)
(horizontal
[ ... ]

is somehow superior to typing something like:

class Point : object {
integer horizontal;
[ ... ]

Can anyone provide a concrete example (that will not get shot down in 10
seconds) of why one syntax is supposedly better than the other?

Here is my argument (my apologies for the Lisp-rather-than-Dylan-ness):

(defmacro define-integer-slots-class (name slots)
`(define-class ,name ()

`(,slot :type 'integer :init-value 0 :init-keyword ':horizontal))
slots)))

(define-integer-slots-class point (horizontal vertical))
(define-integer-slots-class frob (length width depth weight))

The value isn't in the exact defmacro form I wrote, it is in the
ability of the language to manipulate itself, which is enabled by the
uniform syntax.

I can shoot it down in 10 seconds: Read syntax is not the same
thing as internal representation.

People are repeatedly making the mistake of confusing read syntax and
internal representation. The print representation is yet another
thing that happens to look like the read syntax in most cases.

Both lisp-like and algol-like read syntax can be read into the same
internal representation. Thus a macro like the above can still be
defined no matter what the read syntax.

The value of a lisp-like syntax is mostly for editors that would have
trouble parsing algol-like text for commands that deal with expressions.

Dan LaLiberte

(Fight interface copyrights and software patents.

Alert!! Compton's Encyclopedia has been granted a patent on
virtually all applications of multi-media, including *any*
searching on a CD-ROM. They want up to 3 percent of total
corporate revenue!

Mon, 27 May 1996 01:08:05 GMT

Patrick Log
#9 / 34

Info Dylan Digest V1 #177

Date: Wed, 8 Dec 1993 11:17:14 -0500

All this is to say that Dylan can (and will) have perfectly reasonable
and extremely powerful macros EVEN IN AN INFIX SYNTAX!
...
P.S. I didn't mean for this note to sound inflammatory. There's no a
priori reason anyone should already know all this stuff. It's not
intuitive.

That's a little condescending.

Although macros can be written for non-Lisp syntaxes, the ease of
doing so may vary widely. It is difficult to imagine it being much
easier than using Lisp lists. If it is more difficult, will Apple or
CMU or someone be providing the source that other potential
implementors can use?

--

Mitron Corporation (503) 690-8350 FAX: (503) 690-9292
15256 NW Greenbrier Pkwy, Beaverton, OR 97006

Sun, 26 May 1996 17:21:06 GMT

Franklyn Turb
#10 / 34

Info Dylan Digest V1 #177

Quote:

> What you are manipulating when you write macros is not lists, but
> SYNTAX. The fact that some macro systems might use the same
> operators for the two should not lead you to believe they are the
> same. If you want really powerful and very secure macros, you have to
> use a system that makes the distinction. (See several papers by Dybvig,
> et al.) Furthermore, once you've made this distinction, you realize
> that the way you manipulate the syntax is independent of the way it
> looked when the user originally entered it.

> Even in Lisp-family languages, the program text has already been
> scanned and parsed by the system reader by the time it reaches your
> macros. At that point, you DO have an abstract syntax tree. If the
> writer of the interpreter/compiler decided to use lists for his/her
> syntax tree representation, that's an implementation detail. The
> tools you use to manipulate the tree should not depend on the
> implementation of the particular compiler you happen to be using.

> So, since the things you transform using macros are abstract syntax
> trees anyway, how could you tell what the original syntax was?

I am confused by this argument. I understand "abstract syntax trees"
as an abstract datatype for representing the parse tree of a program.
For example, an abstract syntax for Scheme would include the following
kinds of functions in its interface:

(application? <exp>) : Is <exp> an application?
(operator <exp>) : Return the operator subexpression of
an application expression.
(operands <exp>) : Return a list of operands of an
an application expression.
(make-application <exp> (listof <exp>)) : Construct a new application
expression
(if? <exp>) : Is <exp> a conditional?
; Similarly for variables, abstractions, assignments, etc.

It is clear that such functions can easily be used to write
interpreters, compilers, and other program analysis tools in a manner
independent of concrete syntax.

It is less clear how to use abstract syntax in writing Lisp-like macro
expanders (i.e., macros that are allowed to take apart their syntactic
inputs and rearrange them). Since a macro effectively extends the
syntax of a language, it determines how its subparts are supposed to
be interpreted as abstract syntax. This means that, in general, the
*inputs* to the macro expander can't already have been parsed into
abstract syntax. Rather, they need to be members of some free
(uninterpreted) expression type that the macro expander can easily
manipulate. S-expressions are the canonical free tree-shaped
expression type.

As a concrete example, consider Scheme's LET macro (again). For the
expression

(let ((a (+ 1 2))
(b (* 3 4)))
(cons a b))

the syntaxing phase must transmit to the LET macro expander syntactic
entities corresponding to ((A (+ 1 2)) (B (* 3 4))) and (CONS A B).
What is the status of the syntactic entity corresponding to
((A (+ 1 2)) (B (* 3 4))) in an abstract syntax approach? I don't know of
any operations from the abstract syntax for Scheme that would allow the
LET expander to effectively manipulate this fragment; after all, it's not
an application, abstraction, variable, conditional, assignment, etc.
But it's very easy to manipulate this fragment as an s-expression!

In order for a macro expander to manipulate something other than
unsyntaxed expression trees, it somehow needs to communicate with the
parser about the kinds of inputs it expects. Presumably it would be
possible to design a template-based macro system (along the lines of
Scheme's high-level SYNTAX-RULES macros) that includes information
about how the inputs to the macros are supposed to be parsed. Though
they help with naming issues ("hygiene"), template-based macros aren't
always as expressive as the traditional Lisp macro expanders.

For those of you who say that "S-expressions don't matter because it's
all abstract syntax anyway", will you please describe how you plan to
write your macro expanders?

- lyn -

Mon, 27 May 1996 05:00:21 GMT

David Gadbo
#11 / 34

Info Dylan Digest V1 #177

Quote:

>>(2) S-expressions facilitate the expression of macros....

> [...] One thing I had to come to terms with was the fact that the
>stuff that comes in to the interpreter/compiler from the user is NOT
>lists. Oh, sure, it looks just like the lists that you use for data,
>but it's not the same thing! (Lisp syntax actually contributes to
>the confusion on this issue, IMHO, but that part is arguable.)

>What you are manipulating when you write macros is not lists, but
>SYNTAX. The fact that some macro systems might use the same
>operators for the two should not lead you to believe they are the
>same.

But that is the whole point of Lisp macros being the way they are.
Explicitly and purposefully defining the programmer-visible syntactic
representation in terms of existing language-defined data structures
means there does not need to be a big bag on the side of the language
to handle the special program representation. Implementations will
take the sexp representation and turn it in to something else
internally; the sexp rep provides the interface and barrier between
them.

Quote:

>If you want really powerful and very secure macros, you have to
>use a system that makes the distinction.

I do not see how having a special representation makes a difference in
expressiveness. It does allow enforcement of hygiene and referential
transparency, but most programmers I know of Common Lisp and its
ancestral languages think that having linguistic support for dealing
with these issues is just not that important and certainly not worth
muddying a fairly simple model of program transformation. Maybe such
support will be popular for the programmers (and their managers) that
Dylan is to be targeted at, but I think that it will be a turn-off for
the same reasons that Pascal is not their favorite language.

--David Gadbois

Mon, 27 May 1996 05:57:45 GMT

Jeff Dalt
#12 / 34

Info Dylan Digest V1 #177

Quote:

> >(2) S-expressions facilitate the expression of macros....

This happens to be true. That doesn't mean there aren't cases where
a different approach is better.

Quote:

> I've seen this argument often enough that I think it's finally time to
> respond to it.

> This past spring, I had to write some programs in Scheme using TRULY
> heavy-duty macros for the first time. One thing I had to come to
> terms with was the fact that the stuff that comes in to the
> interpreter/compiler from the user is NOT lists. Oh, sure, it looks
> just like the lists that you use for data, but it's not the same
> thing! (Lisp syntax actually contributes to the confusion on this
> issue, IMHO, but that part is arguable.)

I don't know about all versions of Scheme, especially with the new
macro system, but ordinarily what you get *is* lists. You can treat
it abstractly as something else if you want (this is standard in
Lisp), but it's still lists nonetheless and you can treat it as
lists (eg, by printing it out) when that's helpful.

Quote:

> What you are manipulating when you write macros is not lists, but
> SYNTAX. The fact that some macro systems might use the same
> operators for the two should not lead you to believe they are the
> same. If you want really powerful and very secure macros, you have to
> use a system that makes the distinction. (See several papers by Dybvig,
> et al.)

If you want hygenic macros, you have to do various things; but they
don't necessarily involve abandoning lists.

Quote:

> Furthermore, once you've made this distinction, you realize
> that the way you manipulate the syntax is independent of the way it
> looked when the user originally entered it.

This is true anyway. For instance, lists could be input as
pictures of trees.

Quote:

> Even in Lisp-family languages, the program text has already been
> scanned and parsed by the system reader by the time it reaches your
> macros. At that point, you DO have an abstract syntax tree.

You also have lists, symbols, etc.

Quote:

> If the
> writer of the interpreter/compiler decided to use lists for his/her
> syntax tree representation, that's an implementation detail. The
> tools you use to manipulate the tree should not depend on the
> implementation of the particular compiler you happen to be using.

You have to know about the data structures that are given to macro
expanders (unless you stick with something like the Scheme rule
language). The compiler can use other structures for other things,
of course.

Quote:

> So, since the things you transform using macros are abstract syntax
> trees anyway, how could you tell what the original syntax was?

No one ever thought the program could tell. But you, the user, may
well know what it was.

Quote:

> I can
> (and have) written scanners/parsers for several external, concrete
> syntaxes which generate exactly the same abstract syntax trees. Using
> the right macro systems, you can write a single set of macros which
> work for all the concrete syntaxes.

but of course.

Quote:

> All this is to say that Dylan can (and will) have perfectly reasonable
> and extremely powerful macros EVEN IN AN INFIX SYNTAX!

That doesn't follow. For instance, it may be difficult for the
macro-writer to specify an infix syntax for macro calls.

Languages that have an extensible infix syntax have been less
successful than Lisp at getting programmers to take full advantage
of their ability to extend the language. An exception may be Prolog
which, like Lisp, uses a simple and uniform internal representation.

This is not to say you can't do as well with infix syntax, of course;
but it remains to be seen whether it actually turns out that way.

(BTW, I'm using "infix" to mean more or less "like in ordinary
Algol-style programming langauges".)

-- jd

Mon, 27 May 1996 05:39:02 GMT

Paul Stodghi
#13 / 34

Info Dylan Digest V1 #177

Quote:

>> (2) S-expressions facilitate the expression of macros....

Jonathan>
Jonathan>
Jonathan> I've seen this argument often enough that I think it's finally
Jonathan> time to respond to it.

[ Macros work on syntax structures, not necessarily data structures. ]

Jonathan> All this is to say that Dylan can (and will) have perfectly
Jonathan> reasonable and extremely powerful macros EVEN IN AN INFIX SYNTAX!

This is true, but how do _parse_ user extensions in an infix syntax? With
the lists-as-program syntax paradigm, this isn't difficult: the beginning,
'(', and end, ')', of expressions are easily determined. Can this be done
in an infix syntax?

To be concrete: Starting with a base syntax, say Pascal, add a LET
construct. I'll grant you that the macro expander is easy to write, but how
does the parser know how to parse this extension?

If anyone has some references on this, I'll love to see them.

Thanks all.
--

US mail: Department of Computer Science, Upson Hall
Cornell University, Ithaca, NY 14853
Phone: (607) 254-8833

Mon, 27 May 1996 05:55:55 GMT