lgm@cbnewsc.att.com (lawrence.g.mayka) (08/27/90)
In article <1990Aug24.154118.22011@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: >My point is that there is nothing special that makes *Lisp* a great >extension language. Some might argue that it is the "simple syntax," >but that same simple syntax is hated by many (myself *not* included). Simplicity is nice, but extensibility is the much more important virtue of Lisp syntax. (The two are of course related to some degree.) Lisp's other main advantage as an extension language is its dynamic typing, which greatly reduces the effort required to make small changes to a program's behavior. I have found that those who "hate" Lisp syntax almost invariably have never used a powerful Lisp development environment such as Symbolics Genera, or even Harlequin's LispWorks. Indeed, the "haters" usually have never used any Lisp system beyond the 1962-vintage Lisp 1.5 that most of us oldsters were introduced to in undergraduate school. Opinions formed in ignorance carry little weight with me. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
sfk@otter.hpl.hp.com (Steve Knight) (08/27/90)
With trepidation, I'd like to try to make a couple of points about Lisp syntax. The basic point is that the virtues claimed for Lisp syntax are not exclusive to Lisp. Lawrence writes: > Simplicity is nice, but extensibility is the much more important > virtue of Lisp syntax. I agree with this. However, there's no reason to think that extensible languages are obliged to adopt the approach of Lisp and Prolog in which the programmatic syntax is identical to that of some concrete data types. The main advantage with the Lisp/Prology approach, as I see it, is that the learning curve for extension-programming is shortend. However, here's an alternative look. It is quite easy to imagine a programming language with (say) an Algol-like syntax in which the parse tree is available as a standard data-structure. Extending the language has several solutions. The elegant solution might be to create new grammar rules with associated rewrite actions. A more brute-force approach, used in Pop11 (a Lisp derivative), is to supply the compiler's parsing & tokenising procedures. The advantage I see in this approach is two-fold. Firstly, the programmer gets to deal with a more familiar kind of syntax. Secondly, the parse tree can be made more regular, making extension programming easier. Speaking personally, I am no fan of the Lisp or Prolog style of syntax. It seems to me to be an unfortunate conflation of issues -- external syntax is there to make programs readable etc -- internal structure is there to make manipulation of programs convenient. I think that Prolog makes the better job of it, having the advantage of being relational so that quoting rules aren't required, and providing a good infix/prefix/ postfix operator system. I should point out that I've happily programmed in both of these languages for quite a few years and am very comfortable programming with them. But I don't think that they are beyond improvement. Lawrence continues: > I have found that those who "hate" Lisp syntax almost invariably have > never used a powerful Lisp development environment such as Symbolics > Genera, or even Harlequin's LispWorks. Cause and effect -- but which way round do you think it operates? We have a Symbolics with Genera sitting around turned off. We used it for a couple of projects but the incremental benefits were too small. I agree with Lawrence in thinking that many folks pre-judge on the basis of ignorance, it would be odd if it wasn't true! However, the issue of Lisp's syntax is largely independent of programming environment -- you don't need Lisp's syntax to do sensible things with programs. I am inclined to think that the best interpretation of Lawrence's observation is that expensive Lisp equipment is of much more interest to folks who are prepared to tolerate the problems with Lisp. And I would count the syntax as, overall, a problem because the benefits could be achieved without the cost. > Indeed, the "haters" usually > have never used any Lisp system beyond the 1962-vintage Lisp 1.5 that > most of us oldsters were introduced to in undergraduate school. That doesn't ring a bell with me. My (UK based) experience is that people's exposure is to Lisp's such as Lucid. This doesn't really sweeten the experience, to be fair, since so many commercial lisp systems have intense memory requirements -- which ends up spoiling the experience. Another factor in the development of attitudes hostile to Lisp, in my view, is the bias of university teaching. (I'm only talking about the UK here.) I've had a great deal of trouble getting UK graduates to accept Lisp as a viable language -- even for prototyping. The presentation of Prolog is much fairer, although I encounter very set attitudes about what can be done with Prolog. Steve "Just the opinions, ma'am" Knight
lgm@cbnewsc.att.com (lawrence.g.mayka) (08/29/90)
In article <1350028@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes: >odd if it wasn't true! However, the issue of Lisp's syntax is largely >independent of programming environment -- you don't need Lisp's syntax >to do sensible things with programs. I was referring more than anything to the fear some people have that they "would never be able to keep track of all those parentheses." If they use a reasonable editor (i.e., one that keeps track of parentheses, at the very least!), they shouldn't have any difficulty. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (08/29/90)
lgm@cbnewsc.att.com (lawrence.g.mayka) writes: >In article <1990Aug24.154118.22011@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: >>My point is that there is nothing special that makes *Lisp* a great >>extension language. Some might argue that it is the "simple syntax," >>but that same simple syntax is hated by many (myself *not* included). >Simplicity is nice, but extensibility is the much more important >virtue of Lisp syntax. (The two are of course related to some >degree.) Lisp's other main advantage as an extension language is its >dynamic typing, which greatly reduces the effort required to make >small changes to a program's behavior. But other languages can be as extensible. In fact, ARexx (Rexx for the Amiga) is likely the most extensible "extension language" I have heard of. If a program has a Rexx-port, it can be used as an extension to ARexx. In the Amiga community, it is very common to hear of people custom-making editor/compiler/hot-key setups with random editors, compilers, and ARexx. Languages like shell languages (including ARexx) are incredibly extensible, because you can use other programs as language "operators". Yes, lisp is naturally extensible, but so are *many* other languages. I will agree that lisp's dynamic typing are an important point of its usefulness. >I have found that those who "hate" Lisp syntax almost invariably have >never used a powerful Lisp development environment such as Symbolics >Genera, or even Harlequin's LispWorks. Indeed, the "haters" usually >have never used any Lisp system beyond the 1962-vintage Lisp 1.5 that >most of us oldsters were introduced to in undergraduate school. Many of the lisp-haters that I am thinking of used the Xerox InterLisp workstation environment. What got many people were the structured editors. (I didn't mind these workstations much, aside from the slowness.) Many people I have spoken to hate lisp because they are used to Pascal-like languages. Some of these people had programmed in lisp for several months (i.e. a few AI courses in school). >Opinions formed in ignorance carry little weight with me. I agree, but many of the lisp-haters I have met have gien lisp a chance, and found they just didn't like it. Be careful of assuming that lisp-haters have formed their opinions out of ignorance. .oO Chris Oo. -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson
tomf@key.COM (Tom Faulhaber) (08/30/90)
In article <1350028@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes: >It is quite easy to imagine a programming language with (say) an Algol-like >syntax in which the parse tree is available as a standard data-structure. >Extending the language has several solutions. The elegant solution might >be to create new grammar rules with associated rewrite actions. Actually a language that I think meets your criteria was developed at Harvard in the early 70s. It was called EL1 (Extensible Language 1) and it was like Algol on the outside and like Lisp on the inside. A system called PDS (Program Development System) was built around it which supplied the capabilty to write rewrite rules. These rules were very similar to macros in modern Lisps, but with an Algol-like syntax. The approach commonly used could be described as somewhat object-oriented in that programmers would develop interfaces to their datatypes at a high level without concern for the underlying impelmentation and then specify the rewrite rules to translate the high-level primtives into actual code. Interfaces included not only functions but operators (any symbol could be an operator) and iterators (and any syntactic sugar you could think of to make the job easier). EL1 had many of the shortcomings of the Lisps of its day, including totally dynamic scoping, but it fostered an interesting approach to programming. EL1 was taught to upper-level undergraduates in a course called AM113 throughout the seventies and into the early eighties. Some ex-students still haven't fully recovered :-). I don't have the references on EL1 handy, but the primary source was Ben Wegbreit's Ph.D. thesis at Harvard (around 1974, I think). Others who wrote about aspects of the system were Tom Cheatham (the Prof behind it all), Judy Townley, and Glenn Holloway. Send me mail if you want more info and I'll try to dig it out. Tom -- ------------------------------------------------------------------------- Thomas A. Faulhaber, Jr. tom@marble.com Marble Associates (408) 295-5099 Pacific Region/San Jose, CA
rar@kronos.ads.com (Bob Riemenschneider) (08/30/90)
To save some digging, Allen's _Anatomy of Lisp_ discusses EL1 -- not in much greater detail than in the posting, though -- and refers you to B. Wegbreit "ECL Programmer's Manual" Harvard Center for Research in Computing Technology TR23-74 December, 1974 -- rar
barnes@cadence.com (Tim Barnes) (09/01/90)
In article <1990Aug28.235240.19605@cbnewsc.att.com> lgm@cbnewsc.att.com (lawrence.g.mayka) writes:
...> I was referring more than anything to the fear some people have that
...> they "would never be able to keep track of all those parentheses." If
...> they use a reasonable editor (i.e., one that keeps track of
...> parentheses, at the very least!), they shouldn't have any difficulty.
It's also the case that there are a variety of "syntax packages"
available for Lisp: for example Cadence's Skill(tm) allows the following
semantically equivalent syntaxes:
x = 3*sin( y->z )
(setq x (times 3 (sin (getq y z))))
Mentor Graphics' (used to be from Silicon Compiler Systems) GENIE(tm)
extension language allows either lisp-like, C-shell-like (I think) or
C-like syntax, though I believe they use separate parsers for each
syntax, where Skill lets you mix the two syntaxes in the same
expression.
There are some public domain syntax processors available too: for
example CGOL.
I find I'm happy with either syntactic style, but I like the mixture
best of all. And of course I use emacs to help me format whatever I
write.
--
/ / Manager, Framework Technology - Cadence Design Systems
-/- o /__ ___ __ ___ ___ ___ 2455 Augustine Drive
/ / /\ /\ / / ___/ / / / /__/ /__ Santa Clara, CA 95054-3082
/__ / / \/ \ /__/ /__/ / / / /__ ___/ barnes@cadence.com (408) 987 5417lgm@cbnewsc.att.com (lawrence.g.mayka) (09/01/90)
In article <1990Aug29.153243.7567@uwslh.slh.wisc.edu>, lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: > editors, compilers, and ARexx. Languages like shell languages > (including ARexx) are incredibly extensible, because you can use other > programs as language "operators". Yes, lisp is naturally extensible, > but so are *many* other languages. Extensible shell languages often use *prefix* notation, don't they? Hmmm... > Many of the lisp-haters that I am thinking of used the Xerox InterLisp > workstation environment. What got many people were the structured > editors. (I didn't mind these workstations much, aside from the I have read of the '70s debate between syntax-sensitive text editing (a la MIT) and true structure editing (a la Xerox). I am very pleased with the former; the latter seems to be dying out, so I may never even have a chance to sample it. > slowness.) Many people I have spoken to hate lisp because they are > used to Pascal-like languages. Some of these people had programmed in > lisp for several months (i.e. a few AI courses in school). Several months may or may not be a fair test, depending on the intensity of Lisp usage, the brand of Lisp used, the degree of emotional investment in other languages and environments, the degree of resistance to change (of any kind), etc. > chance, and found they just didn't like it. Be careful of assuming > that lisp-haters have formed their opinions out of ignorance. No, not all, of course. But enough to bother me, I guess. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
john@mintaka.mlb.semi.harris.com (John M. Blasik) (09/10/90)
In article <BARNES.90Aug31185555@cds839.cadence.com> barnes@cadence.com (Tim Barnes) writes: > >It's also the case that there are a variety of "syntax packages" >available for Lisp: for example Cadence's Skill(tm) allows the following >semantically equivalent syntaxes: > x = 3*sin( y->z ) > (setq x (times 3 (sin (getq y z)))) > Too bad the designers brewed Skill(tm) with an overabunance of syntatic sugar at the expense of the time honored hops and malt of lisp: (cons 1 2) *Error* cons: argument #2 should be a list (type template = "gl") - 2 -- john