Info Dylan Digest V1 #177
Author |
Message |
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 |
|
|
Page 1 of 3
|
[ 34 post ] |
|
Go to page:
[1]
[2] [3] |
|