What does an anti-perl look like
Richard Harter
the original article that sparked the exchanges. Byron, I gather, dislikes
the style of Perl and would like, so to speak, an anti-Perl, even if he has
to write it himself. This is really a lang.misc topic, so I've added that
as a group.
Byron, you don't want to do it. It's more work to develop a language than
one might imagine, particularly if it is to be a good one. If you don't
like Perl there are a number of perfectly reasonable alternatives, among
them TCL, Python, and Icon. There is also Lakota, which I am a principal
developer. [Apologies to all who fuss about people talking about their
own work duly made. My justification is that I want to talk about the
language design issues, which are of general interest to those who are
interested in language design issues.]
Briefly, Lakota occupies the same general linguistic niche as Perl, but
it is about as far as one can get from the style of Perl. When I say the
same niche, what I am getting at is this: The power of UNIX shell programming
rests not in the shell language itself, but in the collection of tool
programs that are standardly available, e.g. sed, awk, find, uniq, sort,
and their interconnection with pipes and redirection. There are a number
of problems with this bag of tools approach, however. These include
(a) the execution of the resulting scripts is slow because each tool is
a separate process, (b) most of the tools (and the shell itself) have
various size limitations, (c) the standard tools do not complement each
other completely, (d) the implementations of the tools vary from OS to
OS, and (e) there are numerous conflicts between command line usage
in the shell and the principal tools. And that's only the beginning of
the list :-).
The Perl solution (and the Lakota solution) is to provide a single language
which has the functionality of the shell and the principle tools. Now
the approach that Larry has taken with Perl is to, in effect, fuse the
major tools of UNIX into a single language with a common syntax and
the annoying limitations removed. This approach has a number of merits;
it fits in with the UNIX/C style, which offers both familiarity and
the use of a proven intellectual technology.
The approach taken in Lakota is much more radical for those who are
accustomed to doing everything "the UNIX way" although not particularly
radical in terms of languages in general. The essence of the matter is
to accept the shell tools functionality as a requirement but scrap the
entire shell syntax and style. In a sense this is a dangerous step
because one has to resolve a lot of issues anew. However there is a lot
to gain. Conventional shell programming has many faults than the ones
I have listed above. What they amount to is that shell programming
involves scripts that are hard to read, hard to maintain, and programming
structures that do not scale up well to large programs.
Some of the features that make Lakota an 'anti-Perl' are:
(A) Brutally stripped syntax. The only special characters are (){} and
the white space characters. There are no quote characters, no meta
characters and no escape character, and no need for them.
(B) English language commands. Call it COBOL if you like. The upshot
is that someone who has a modest command of the language can read it
and maintain it without being a language lawyer.
(C) A hierarchical procedure/module structure with variable isolation
between procedures and modules. Variables are, by default, local to the
procedure they used in; they can be made global to a particular modules.
All inter-module coupling must be done via explcitly shared procedures.
(D) Variable substitution is done via enclosure in parentheses and may
be nested, e.g. (a-(b)) means replace (b) by the contents of b and then
result the resulting string (concatenation of a- and contents of b) by
its contents.
(E) A minimal number of special variables; functional operators are
used instead. [Braces {} are used to delimit functions.] Thus
{all-arguments} for the list of all arguments and {argument 15} for the
15'th argument.
And so on and so forth.
The main point I would like to make is that it is not such a simple thing
to design and implement a language, particularly one which is to have
strong string manipulation capabilities.
Also this article is longer than it should be.
--
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb. This sentence short. This signature done.
Ozan Yigit
by...@donald.tamu.edu (Byron Rakitzis) writes:
3) I want the syntax of the language to be elegant. This sounds like a tall
order, but what I'm doing is ruling out languages like Scheme; I just cannot
deal with the Lots of Irrelevant and Stupid Parentheses.
Your loss. Scheme is a lot more than just Cambridge polish notation
with lots of parens. I include a reasonably complete biblography for
you or anybody else who may wish to have a more detailed view of this
language and some of the concepts embodied within. I am also certain
that these references would be helpful in designing and implementing
other languages worth remembering.
oz
---
%A John Reynolds
%T Definitional Interpreters for Higher Order Programming Languages
%J ACM Conference Proceedings
%P 717-740
%I ACM
%D 1972
%A Gerald Jay Sussman
%A Guy Lewis Steele Jr.
%T Scheme: an Interpreter for Extended Lambda Calculus
%R MIT AI Memo 349
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D December 1975
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T Lambda, the Ultimate Imperative
%R MIT AI Memo 353
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D March 1976
%K imperative
%A Guy Lewis Steele Jr.
%T Lambda, the Ultimate Declarative
%R MIT AI Memo 379
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D November 1976
%K declarative
%A Guy Lewis Steele Jr.
%T Debunking the ``Expensive Procedure Call'' Myth, or Procedure Call
Implementations Considered Harmful, or LAMBDA, the Ultimate GOTO
%J ACM Conference Proceedings
%P 153-162
%I ACM
%D 1977
%K ultimate
%A Guy Lewis Steele Jr.
%T Macaroni is Better than Spaghetti
%J Proceedings of the Symposium on Artificial Intelligence and
Programming Languages
%P 60-66
%O Special joint issue of SIGPLAN Notices 12(8) and SIGART Newsletter 64
%D August 1977
%K macaroni
%A Mitchell Wand
%T Continuation-Based Program Transformation Strategies
%J Journal of the ACM
%V 27
%N 1
%P 174-180
%D 1978
%A Mitchell Wand
%A Daniel P. Friedman
%T Compiling lambda expressions using continuations and
factorizations
%J Journal of Computer Languages
%V 3
%P 241-263
%D 1978
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Revised Report on Scheme, a Dialect of Lisp
%R MIT AI Memo 452
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D January 1978
%K r-report
%A Guy Lewis Steele Jr.
%T Rabbit: a Compiler for Scheme
%R MIT AI Memo 474
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D May 1978
%K rabbit
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Art of the Interpreter, or the Modularity Complex
(parts zero, one, and two)
%R MIT AI Memo 453
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D May 1978
%K modularity
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T Design of LISP-Based Processors
or, SCHEME: A Dielectric LISP
or, Finite Memories Considered Harmful
or, LAMBDA: The Ultimate Opcode
%R MIT-AI Memo 514
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D 1979
%A Uwe F. Pleban
%T The Standard Semantics of a Subset of SCHEME, a Dialect of LISP
%R Computer Science Technical Report TR-79-3
%I University of Kansas
%C Lawrence, Kansas
%D July 1979
%A Guy Lewis Steele Jr.
%T Compiler Optimization Based on Viewing LAMBDA as RENAME + GOTO
%B AI: An MIT Perspective
%E Patrick Henry Winston
%E Richard Henry Brown
%I MIT Press
%C Cambridge, Mass.
%D 1980
%K rename+goto
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T The Dream of a Lifetime: a Lazy Variable Extent Mechanism
%J Conference Record of the 1980 Lisp Conference
%P 163-172
%I The Lisp Conference
%D 1980
%K lazy
%A Drew McDermott
%T An Efficient Environment Allocation Scheme in an Interpreter
for a Lexically-Scoped Lisp
%J Conference Record of the 1980 Lisp Conference
%P 154-162
%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
%D 1980
%O Proceedings reprinted by ACM
%A Steven S. Muchnick
%A Uwe F. Pleban
%T A Semantic Comparison of Lisp and Scheme
%J Conference Record of the 1980 Lisp Conference
%P 56-65
%I The Lisp Conference, P.O. Box 487, Redwood Estates CA.
%D 1980
%A Uwe F. Pleban
%T A Denotational Approach to Flow Analysis and Optimization of
SCHEME, A Dialect of LISP
%R Ph.D. Dissertation
%I University of Kansas
%C Lawrence, Kansas
%D 1980
%A Mitchell Wand
%T Continuation-Based Multiprocessing
%J Conference Record of the 1980 Lisp Conference
%P 19-28
%I The Lisp Conference
%D 1980
%A Mitchell Wand
%T SCHEME Version 3.1 Reference Manual
%R Computer Science Technical Report 93
%I Indiana University
%C Bloomington, Indiana
%D June 1980
%K scheme3.1
%A Guy Lewis Steele Jr.
%A Gerald Jay Sussman
%T Design of a Lisp-based Processor
%J CACM
%V 23
%N 11
%P 628-645
%D November 1980
%A Rex A. Dwyer
%A R. Kent Dybvig
%T A SCHEME for Distributed Processes
%R Computer Science Department Technical Report #107
%I Indiana University
%C Bloomington, Indiana
%D April 1981
%A Gerald Jay Sussman
%A Jack Holloway
%A Guy Lewis Steele Jr.
%A Alan Bell
%T Scheme-79 - Lisp on a Chip
%J IEEE Computer
%V 14
%N 7
%P 10-21
%D July 1981
%I IEEE
%K scheme79
%A John Batali
%A Edmund Goodhue
%A Chris Hanson
%A Howie Shrobe
%A Richard M. Stallman
%A Gerald Jay Sussman
%T The Scheme-81 Architecture - System and Chip
%J Proceedings, Conference on Advanced Research in VLSI
%P 69-77
%E Paul Penfield, Jr.
%C Artech House, Dedham MA.
%D 1982
%K scheme81
%A Jonathan A. Rees
%A Norman I. Adams
%T T: A Dialect of Lisp or, LAMBDA: The Ultimate Software Tool
%J Conference Record of the 1982 ACM Symposium on Lisp and
Functional Programming
%P 114-122
%D 1982
%K T
%A Gerald Jay Sussman
%T LISP, Programming and Implementation
%B Functional Programming and its Applications
%E Darlington, Henderson, Turner
%I Cambridge University Press
%C London
%D 1982
%A R. Kent Dybvig
%T C-Scheme
%R Computer Science Department Technical Report #149 (MS Thesis)
%I Indiana University
%C Bloomington, Indiana
%D 1983
%A Pee Hong Chen
%A W.Y. Chi
%A E.M. Ost
%A L.D. Sabbagh
%A G. Springer
%T Scheme Graphics Reference Manual
%R Computer Science Technical Report No. 145
%I Indiana University
%C Bloomington, Indiana
%D August 1983
%A Pee Hong Chen
%A Daniel P. Friedman
%T Prototyping data flow by translation into Scheme
%R Computer Science Technical Report #147
%I Indiana University
%C Bloomington, Indiana
%D August 1983
%A Carol Fessenden
%A William Clinger
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Scheme 311 version 4 Reference Manual
%R Computer Science Technical Report 137
%I Indiana University
%C Bloomington, Indiana
%D February 1983
%O Superseded by Computer Science Technical Report 153, 1985
%K scheme311
%A William Clinger
%T The Scheme 311 compiler: An Exercise in Denotational Semantics
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%P 356-364
%D 1984
%K compile311
%A Daniel P. Friedman
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%T Programming with Continuations
%B Program Transformation and Programming Environments
%P 263-274
%E P. Pepper
%I Springer-Verlag
%D 1984
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Engines Build Process Abstractions
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%C Austin, TX.
%P 18-24
%D 1984
%A Christopher T. Haynes
%A Daniel P. Friedman
%A Mitchell Wand
%T Continuations and Coroutines
%J Conference Record of the 1984 ACM Symposium on Lisp and
Functional Programming
%C Austin, TX.
%P 293-298
%D 1984
%A Daniel P. Friedman
%A Mitchell Wand
%T Reification: reflection without metaphysics
%J Conference Record of the 1984 ACM Symposium on LISP and Functional
Programming
%C Austin, TX.
%P 348-355
%D August 1984
%A Jonathan A. Rees
%A Norman I. Adams
%A James R. Meehan
%T The T manual, fourth edition
%I Yale University Computer Science Department
%D January 1984
%A Guillermo J. Rozas
%T Liar, an Algol-like Compiler for Scheme
%R S. B. Thesis
%I Department of Electrical Engineering and Computer Science,
Massachusetts Institute of Technology
%D January 1984
%K liar
%A Richard Schooler
%A James W. Stamos
%T Proposal For a Small Scheme Implementation
%R MIT LCS Memo TM-267
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D October 1984
%T MIT Scheme Manual, Seventh Edition
%I Department of Electrical Engineering and Computer Science,
Massachusetts Institute of Technology
%C Cambridge, Mass.
%D September 1984
%K mitscheme
%T MacScheme Reference Manual
%I Semantic Microsystems
%C Sausalito, California
%D 1985
%K macscheme
%A Harold Abelson
%A Gerald Jay Sussman
%A Julie Sussman
%T Structure and Interpretation of Computer Programs
%I MIT Press
%C Cambridge, Mass.
%D 1985
%K siocp
%A William Clinger
%A Daniel P. Friedman
%A Mitchell Wand
%T A Scheme for a Higher-Level Semantic Algebra
%B Algebraic Methods in Semantics
%E J. Reynolds, M. Nivat
%P 237-250
%I Cambridge University Press
%C London
%D 1985
%A Amitabh Srivastava
%A Don Oxley
%A Aditya Srivastava
%T An (other) Integration of Logic and Functional Programming
%J Proceedings of the Symposium on Logic Programming
%P 254-260
%I IEEE
%D 1985
%E William Clinger
%T The Revised Revised Report on Scheme, or An Uncommon Lisp
%R MIT AI Memo 848
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%O Also published as Computer Science Department Technical Report 174,
Indiana University, June 1985
%D August 1985
%K rrrs
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Constraining Control
%J Proceedings of the Twelfth Annual Symposium on Principles of
Programming Languages
%C New Orleans, LA.
%P 245-254
%I ACM
%D January 1985
%A Daniel P. Friedman
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%A Mitchell Wand
%T Scheme 84 Interim Reference Manual
%R Computer Science Technical Report 153
%I Indiana University
%C Bloomington, Indiana
%D January 1985
%K scheme84
%A Pee Hong Chen
%A David Sabbagh
%T Scheme as an Interactive Graphics Programming Environment
%R Computer Science Technical Report No. 166
%I Indiana University
%C Bloomington, Indiana
%D March 1985
%A R. Kent Dybvig
%A Bruce T. Smith
%T Chez Scheme Reference Manual Version 1.0
%I Cadence Research Systems
%C Bloomington, Indiana
%D May 1985
%T TI Scheme Language Reference Manual
%I Texas Instruments, Inc.
%O Preliminary version 1.0
%D November 1985
%A Michael A. Eisenberg
%T Bochser: An Integrated Scheme Programming System
%R MIT Computer Science Technical Report 349
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D October 1985
%K bochser
%T Transliterating Prolog into Scheme
%A Matthias Felleisen
%R Computer Science Technical Report #182
%I Indiana University
%C Bloomington, Indiana
%D October 1985
%A David H. Bartley
%A John C. Jensen
%T The Implementation of PC Scheme
%J Proceedings of the 1986 ACM Conference on Lisp
and Functional Programming
%P 86-93
%D 1986
%K pcscheme
%A R. Kent Dybvig
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Expansion-Passing style: Beyond Conventional Macros
%J Conference Record of the 1986 ACM Conference on Lisp and
Functional Programming
%P 143-150
%D 1986
%A Marc Feeley
%A Guy LaPalme
%T Closure Generation based on viewing LAMBDA as EPSILON plus COMPILE
%O Submitted for Publication
%D 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Closer Look At Export and Import Statements
%J Journal of Computer Languages
%V 11
%N 1
%P 29-37
%I Pergamon Press
%D 1986
%A Daniel P. Friedman
%A Matthias Felleisen
%T The Little LISPer: Second Edition
%I Science Research Associates, Inc.
%C Palo Alto, California
%D 1986
%A Christopher T. Haynes
%A Daniel P. Friedman
%A Mitchell Wand
%T Obtaining Coroutines With Continuations
%J Journal of Computer Languages
%V 11
%N 3/4
%P 143-153
%I Pergamon Press
%D 1986
%A Mitchell Wand
%T Finding the Source of Type Errors
%J Conference Record of the Thirteenth Annual Symposium on
Principles of Programming Languages
%P 38-43
%I ACM
%C St. Peterburg, Fla.
%D 1986
%A Mitchell Wand
%T From Interpreter to Compiler: A Representational Derivation
%B Programs as Data Objects
%I Springer-Verlag Lecture Notes
%D 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%T Control operators, the SECD-machine, and the lambda-calculus
%J 3rd Working Conference on the Formal Description of
Programming Concepts
%C Ebberup, Denmark
%P 193-219
%D August 1986
%A Eugene E. Kohlbecker
%T Syntactic Extensions in the Programming Language Lisp
%R Computer Science Technical Report #199 (Ph.D. Dissertation)
%I Indiana University
%C Bloomington, Indiana
%D August 1986
%A Eugene E. Kohlbecker
%A Daniel P. Friedman
%A Matthias Felleisen
%A Bruce Duba
%T Hygienic macro expansion
%J Symposium on LISP and Functional Programming
%P 151-161
%D August 1986
%O To appear in Lisp and Symbolic Computation
%K hygienic
%A Mitchell Wand
%T The mystery of the tower revealed: a non-reflective
description of the reflective tower
%J Proceedings of the 1986 ACM Symposium on LISP and Functional Programming
%P 298-307
%D August 1986
%K tower
%E Jonathan A. Rees
%E William Clinger
%T Revised^3 Report on the Algorithmic Language Scheme
%J ACM Sigplan Notices
%V 21
%N 12
%D December 1986
%K rrrrs
%A Christopher T. Haynes
%T Logic Continuations
%J Proceedings of the Third International Conference on
Logic Programming
%P 671-685
%I Springer-Verlag
%D July 1986
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
%T Reasoning with Continuations
%J Proceedings of the Symposium on Logic in Computer Science
%P 131-141
%I IEEE Computer Society Press
%C Washington DC
%D June 1986
%A David Kranz
%A Richard Kelsey
%A Jonathan A. Rees
%A Paul Hudak
%A James Philbin
%A Norman I. Adams
%T Orbit: An Optimizing Compiler for Scheme
%J Proceedings of the SIGPLAN '86 Symposium on Compiler
Construction
%P 219-233
%I ACM
%O Published as SIGPLAN Notices 21(7), July 1986
%D June 1986
%K orbit
%A Marc Feeley
%T Deux Approches a' L'implantation du Language Scheme
%I M.Sc. Thesis, De'partement d'Informatique et de Recherche
Ope'rationelle, University of Montreal
%D May 1986
%A Kevin J. Lang
%A Barak A. Pearlmutter
%T Oaklisp: an Object-Oriented Scheme with First Class Types
%J ACM Conference on Object-Oriented Systems, Programming,
Languages and Applications
%P 30-37
%D September 1986
%A William Clinger
%T The Scheme of things: Streams versus Generators
%R Technical Report
%I Tektronix, Inc.
%D 1987
%A R. Kent Dybvig
%T The Scheme Programming Language
%I Prentice-Hall, Inc.
%C Englewood Cliffs, New Jersey
%D 1987
%K splang
%A Marc Feeley
%A Guy LaPalme
%T Using Closures for Code Generation
%J Journal of Computer Languages
%V 12
%N 1
%P 47-66
%I Pergamon Press
%D 1987
%A Matthias Felleisen
%T Reflections on Landin's J-Operator: A Partly Historical Note
%J Journal of Computer Languages
%V 12
%N 3/4
%P 197-207
%I Pergamon Press
%D 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Reduction Semantics for Imperative Higher-Order Languages
%J Parallel Architectures and Languages Europe
%E De Bakker, Nijman and Treleaven
%B Lecture Notes in Computer Science
%V 259
%I Springer-Verlag
%C Berlin
%P 206-223
%D 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%A Eugene E. Kohlbecker
%A Bruce Duba
%T A syntactic theory of sequential control
%J Theoretical Computer Science
%V 52
%P 205-237
%D 1987
%A Daniel P. Friedman
%A Matthias Felleisen
%T The Little LISPer
%I MIT Press
%D 1987
%O Trade Edition
%K littlelisper
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Abstracting Timed Preemption with Engines
%J Journal of Computer Languages
%V 12
%N 2
%P 109-121
%I Pergamon Press
%D 1987
%K engines
%A Stephen Slade
%B The T programming Language
%I Prentice-Hall Inc.
%C Englewood Cliffs, N.J.
%D 1987
%A R. Kent Dybvig
%T Three Implementation Models for Scheme
%R Department of Computer Science Technical Report #87-011 (Ph.D. Dissertation)
%I University of North Carolina at Chapel Hill
%C Chapel Hill, North Carolina
%D April 1987
%A Matthias Felleisen
%T The Calculi of lambda-v-cs conversion: a syntactic
theory of control and state in imperative higher-order programming
languages
%R Computer Science Technical Report #226. (Ph.D. Dissertation)
%I Indiana University
%C Bloomington, Indiana
%D August 1987
%A James S. Miller
%T A Parallel Processing System Based on MIT Scheme
%R MIT LCS Technical Report 402 (Ph.D. Dissertation)
%I Massachusetts Institute of Technology
%C Cambridge, Mass.
%D August 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%A Bruce Duba
%A John Merrill
%T Beyond Continuations
%R Computer Science Dept. Technical Report #216
%I Indiana University
%C Bloomington, Indiana
%D February, 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A calculus for assignments in higher-order languages
%J Conference Record of the 14th Annual ACM Symposium on Principles of
Programming Languages
%C Munich, West Germany
%P 314-345
%D January 1987
%A Matthias Felleisen
%A Daniel P. Friedman
%T A Syntactic Theory of Sequential State
%R Computer Science Dept. Technical Report #230
%I Indiana University
%C Bloomington, Indiana
%D October 1987
%A Christopher T. Haynes
%A Daniel P. Friedman
%T Embedding continuations in procedural objects
%J ACM Transactions on Programming Languages and Systems
%V 9
%N 4
%P 582-598
%D October 1987
%A Michael Eisenberg
%T Programming In Scheme
%E Harold Abelson
%I The Scientific Press
%C Redwood City, CA
%D 1988
%A David Kranz
%T Orbit: An optimizing compiler for Scheme
%R Computer Science Technical report #632 (Ph.D. Dissertation)
%I Yale University
%D 1988
%K orbit-thesis
%A Mitchell Wand
%A Daniel P. Friedman
%T The Mystery of the Tower Revealed: A Non-Reflective
Description of the Reflective Tower
%B Meta-Level Architectures and Reflection
%E P. Maes and D. Nardi
%I Elsevier Sci. Publishers B.V. (North Holland)
%P 111-134
%D 1988
%O Also to appear in Lisp and Symbolic Computation
%A Daniel P. Friedman
%A Mitchell Wand
%A Christopher T. Haynes
%A Eugene E. Kohlbecker
%B Programming Languages: Their Abstractions, Representations,
and Implementations
%I MIT Press and McGraw-Hill
%D 1988-1989
%O in progress
%A Norman Adams
%A Jonathan Rees
%T Object-Oriented Programming in Scheme
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 277-288
%D August 1988
%K oopinscheme
%A William D. Clinger
%A Anne H. Hartheimer
%A Eric M. Ost
%T Implementation Strategies for Continuations
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 124 131
%D August 1988
%K contimpl
%A Matthias Felleisen
%T \(*l-vs-CS: An Extended \(*l-Calculus for Scheme
%J Conference Record of the 1988 ACM Conference on Lisp
and Functional Programming
%P 72-85
%D August 1988
%K calculus
%A Harold Abelson
%A Gerald Jay Sussman
%T Lisp: A Language for Stratified Design
%J BYTE
%D February 1988
%P 207-218
%A William Clinger
%T Semantics of Scheme
%J BYTE
%D February 1988
%P 221-227
%A Alan Bawden
%A Jonathan Rees
%T Syntactic Closures
%J Proceedings of the 1988 ACM Symposium on LISP
and Functional Programming
%C Salt Lake City, Utah.
%D July 1988
%K macrology
%A R. Kent Dybvig
%A Robert Hieb
%T A Variable-Arity Procedural Interface
%J Proceedings of the 1988 ACM Symposium on LISP and Functional Programming
%C Salt Lake City, Utah
%D July 1988
%P 106-115
%O Also Indiana University Computer Science Department Technical Report #247
%A Matthias Felleisen
%A Mitchell Wand
%A Daniel P. Friedman
%A Bruce Duba
%T Abstract Continuations: A Mathematical Semantics for
Handling Functional Jumps
%J Proceedings of the 1988 ACM Symposium on LISP
and Functional Programming
%C Salt Lake City, Utah.
%D July 1988
%A R. Kent Dybvig
%A Daniel P. Friedman
%A Christopher T. Haynes
%T Expansion-Passing Style: A General Macro Mechanism
%J Lisp and Symbolic Computation: An International Journal
%V 1
%N 1
%I Kluwer Academic Publishers
%P 53-76
%D June 1988
%A Olin Shivers
%T Control Flow Analysis in Scheme
%J Proceedings of the Sigplan 1988 Conference on Programming Language
Design and Implementation
%P 164-174
%C Atlanta, Georgia
%D June 1988
%K schflow
%A John Franco
%A Daniel P. Friedman
%T Creating Efficient Programs by Exchanging Data for Procedures
%R Computer Science Technical Report #245
%I Indiana University
%C Bloomington, Indiana
%D March 1988
%A Kevin J. Lang
%A Barak A. Pearlmutter
%T Oaklisp: an Object-Oriented Dialect of Scheme
%J Lisp and Symbolic Computation: An International Journal
%V 1
%N 1
%I Kluwer Academic Publishers
%P 39-51
%D May 1988
%K oaklisp
%A Olin Shivers
%T The Semantics of Scheme Control Flow Analysis (Preliminary).
%R Technical Report ERGO-90-090
%I CMU School of Computer Science
%C Pittsburgh, Penn.
%D November 1988
%A R. Kent Dybvig
%A Robert Hieb
%T Engines from Continuations
%J Journal of Computer Languages
%V 14
%N 2
%P 109-123
%D 1989
%O Also Indiana University Computer Science Department Technical Report #254
%A George Springer
%A Daniel P. Friedman
%B Scheme and the Art of Programming
%I MIT Press and McGraw-Hill
%D 1989
%K scheme-art
%A Matthias Felleisen
%A Robert Hieb
%T The Revised Report on the Syntactic Theories of Sequential Control
and State.
%R Computer Science Technical Report No. 100
%I Rice University
%D June 1989.
%A Steven R. Vegdahl
%A Uwe F. Pleban
%T The Runtime Environment for Screme, a Scheme Implementation
on the 88000
%J Proceedings of the Third International Conference on Architectural
Support for Programming Languages and Operating Systems
%C Boston, Mass.
%D April 1989
%P 172-182
%A Joel F. Bartlett
%T SCHEME->C a Portable Scheme-to-C Compiler
%R Research Report 89/1
%I DEC Western Research Laboratory
%C Palo Alto, California
%D January 1989
%A J. Michael Ashley
%A Richard M. Salter
%T A Revised State Space Model for a Logic Programming Embedding in Scheme
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Olivier Danvy
%T Programming with Tighter Control
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Olivier Danvy
%T Combiner Logiquement en Scheme
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Vincent Delacour
%T Picolo Expresso
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Alain Deutsch
%A Renaud Dumeur
%A Charles Consel
%A Jean-Daniel Fekete
%T CSKIM: An Extended Dialect of Scheme
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Simon M. Kaplan
%A Joseph P. Loyall
%T GARP/Scheme: Implementing a Concurrent, Object-Based Language
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Tan Gon Kim
%A Bernard P. Zeigler
%T The DEVS-Scheme Modelling and Simulation Environment
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Guy Lapalme
%A Marc Feeley
%T Micro-Scheme
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Julia L. Lawall
%A Daniel P. Friedman
%T Embedding the Self Language in Scheme
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Andr\o'e\(aa' Pic
%A Michel Briand
%T Visual Programming with Generators
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Christian Queinnec
%T Validation Suite Generation
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A J. C. Royer
%A J. P. Braquelaire
%A P. Casteran
%A M. Desainte-Catherine
%A J. G. Penaud
%T Le mod\o'e\(ga'le OBJScheme: principes et applications
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Robert Strandh
%T OOOZ, A multi-User Programming Environment Based on Scheme
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Nitsan S\o'e\(aa'niak
%T Compilation de Scheme par sp\o'e\(aa'cialisation explicite
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A John Wade Ulrich
%T Enumeration Algorithms and Non-deterministic Programming in Scheme
%B BIGRE Bulletin
%O Putting Scheme to Work
%E Andr\o'e\(aa' Pic, Michel Briand, Jean B\o'e\(aa'zivin
%N 65
%D July 1989
%A Jonathan Rees
%T Modular Macros
%R Master's thesis
%I Department of Electrical Engineering and Computer Science,
Massachusetts Institute of Technology
%D May 1989
%K modmac
%A Williams Ludwell Harrison III
%T The Interprocedural Analysis and Automatic Parallellization
of Scheme Programs
%J Lisp and Symbolic Computation: An International Journal
%V 2
%N 3/4
%I Kluwer Academic Publishers
%D October 1989
%A Michael Eisenberg
%A William Clinger
%A Anne Hartheimer
%T Programming In MacScheme
%E Harold Abelson
%I The Scientific Press
%C Redwood City, CA
%D 1990
%A John Franco
%A Daniel P. Friedman
%T Towards A Facility for Lexically Scoped, Dynamic Mutual Recursion
in Scheme
%J Journal of Computer Languages
%V 15
%N 1
%P 55-64
%I Pergamon Press
%D 1990
%A John Franco
%A Daniel Friedman
%A Steven Johnson
%T Multi-way Streams in Scheme
%J Journal of Computer Languages
%V 15
%N 2
%P 109-125
%D 1990
%A Samuel Kamin
%B Programming Languages: An Interpreter-based Approach
%I Addison-Wesley
%C Reading, Mass.
%D 1990
%A Guillermo Rozas
%A James Miller
%T Free Variables and First-Class Environments
%J Lisp and Symbolic Computation: An International Journal
%V 3
%N 4
%I Kluwer Academic Publishers
%D December 1990
%A Kurt Normark
%T Simulation of Object-Oriented Concepts and Mechanisms in Scheme
%R Institute for Electronic Systems Technical Report 90-01
%I Aalborg University
%C Aalborg, Denmark
%D January 1990
%K oopmech
%A Dorai Sitaram
%A Matthias Felleisen
%T Control Delimiters and Their Hierarchies
%J Lisp and Symbolic Computation: An International Journal
%V 3
%N 1
%I Kluwer Academic Publishers
%P 67-99
%D January 1990
%K ctrldelim
%A Pavel Curtis
%A James Rauen
%T A Module System for Scheme
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%K module
%A Marc Feeley
%A James S. Miller
%T A Parallel Virtual Machine for Efficient Scheme Compilation
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%A Chris Hanson
%T Efficient Stack Allocation for Tail-Recursive Languages
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%A Morry Katz
%A Daniel Weise
%T Continuing Into the Future:
On the Interaction of Futures and First-Class Continuations
%J Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming
%C Nice, France
%D June 1990
%A Pierre Bonzon
%T A Matacircular Evaluator for a Logical Extension of Scheme
%J Lisp and Symbolic Computation: An International Journal
%I Kluwer Academic Publishers
%V 3
%N 2
%P 113-133
%D March 1990
%A R. Kent Dybvig
%A Robert Hieb
%T Continuations and Concurrency
%J Proceedings of the Second ACM SIGPLAN Symposium on
Principles and Practice of Parallel Programming
%C Seattle, Washington
%D March 1990
%P 128-136
%O Also Indiana University Computer Science Department Technical Report #256
%A Olin Shivers
%T Data-Flow Analysis and Type Recovery in Scheme.
%R Technical Report CMU-CS-90-115
%I CMU School of Computer Science
%C Pittsburgh, Penn.
%D March 1990
%O Also to appear in Topics in Advanced Language Implementation,
Ed. Peter Lee, MIT Press.
%A R. Kent Dybvig
%A Robert Hieb
%T A New Approach to Procedures with Variable Arity
%J Lisp and Symbolic Computation: An International Journal
%V 3
%N 3
%I Kluwer Academic Publishers
%D September 1990
%P 229-244
%A Robert Hieb
%A R. Kent Dybvig
%A Carl Bruggeman
%T Representing Control in the Presence of First-Class Continuations
%J Proceedings of the SIGPLAN '90 Conference on
Programming Language Design and Implementation
%C White Plains, New York
%D June 1990 (to appear)
%A IEEE Std 1178-1990
%T IEEE Standard for the Scheme Programming Language
%I Institute of Electrical and Electronic Engineers, Inc.
%C New York, NY
%D 1991
%A Dorai Sitaram
%A Matthias felleisen
%T Modeling continuations without continuations
%J Proceedings of the Eighteenth ACM Symposium on
Principles of Programming Languages
%D 1991
%P 185-196
Joe Wells
(A) Brutally stripped syntax. The only special characters are (){} and
the white space characters. There are no quote characters, no meta
characters and no escape character, and no need for them.
Does this mean that the NUL character (0) is treated like a letter?
--
Joe Wells <j...@uswest.com>
Byron Rakitzis
>the original article that sparked the exchanges.
>Byron, you don't want to do it. It's more work to develop a language than
>one might imagine, particularly if it is to be a good one. If you don't
>like Perl there are a number of perfectly reasonable alternatives, among
>them TCL, Python, and Icon.
Your comment is perfectly valid. So far, I have received numerous messages
with suggestions for (already existing) alternatives to perl. Most people
named TCL, Python, Icon (as above) but I have also heard that people use
Scheme. This is the first I've heard of Lakota. Is it available for anonymous
ftp?
What it boils down to is this: whether or not ap is a lot of work, I fear it
is going to get written sometime in the near future. When I re-implemented
rc, I thought I came close to what I wanted as my command interpreter, but
now that I am aware of its shortcomings, I want to try to improve on the
rc model. I have at least several goals in mind:
1) I want the core command interpreter to be independent of any particular
application.
2) I want it to be easy to add modules so that the core command interpreter
may be grown into, say, an ap.
3) I want the syntax of the language to be elegant. This sounds like a tall
order, but what I'm doing is ruling out languages like Scheme; I just cannot
deal with the Lots of Irrelevant and Stupid Parentheses. Also, I'm afraid that
Python does not quite fit the bill either. Syntax that is whitespace dependent
just feels "wrong". I know, I tried using Python for a while.
4) This follows from (3): I've recently checked out the Oberon system, and I
am really excited and intrigued by the ideas they bring forth in this environment.
I think they did certain things completely wrong: the interclicking mouse language,
the tiled windows, but the fact that anything on the screen may be instantly
interpreted as a command at the push of a button is a big win, in my view.
There is a window system somewhere in my fingers, and one day it is going to come
out. I'm going to need a command interpreter for this task.
Let me state here that I have not ruled out any of the other interpreters yet.
I still want to see if, say, TCL cannot satisfy my needs. Also, let me state
right away that (1)-(4) contain strong doses of religion; please don't take my
comments as flames. However, if you disagree, I'm always willing to argue. :-)
--
Byron Rakitzis
by...@archone.tamu.edu
Richard Harter
> In article <5...@smds.UUCP> r...@smds.UUCP (Richard Harter) writes:
> Your comment is perfectly valid. So far, I have received numerous messages
> with suggestions for (already existing) alternatives to perl. Most people
> named TCL, Python, Icon (as above) but I have also heard that people use
> Scheme. This is the first I've heard of Lakota. Is it available for anonymous
> ftp?
Sorry, no, you'll need to sign a license. However write me at the address
below or give me an address to send it to, and I'll get a copy to you.
> What it boils down to is this: whether or not ap is a lot of work, I fear it
> is going to get written sometime in the near future. When I re-implemented
> rc, I thought I came close to what I wanted as my command interpreter, but
> now that I am aware of its shortcomings, I want to try to improve on the
> rc model. I have at least several goals in mind:
Also look at Scheme and Rexx as others have noted. Elsewhere David Gudeman
has deprecated Perl and Python as reinventing an unneeded wheel (see his
article in comp.unix.shell). I think David is wrong, but that is a matter
for another article. He argues that refinement of existing languages is
the right way to go. There is something to this; the problem, however, is
that this approach doesn't lead to fundamental improvements in language
design. Taking an existing language and hacking at it (which is what most
people do when they tackle creating a language) is unprofitable -- a
language is more than a sum of pieces. Moreover the "improved" language
is more than likely to be a dead end.
> 1) I want the core command interpreter to be independent of any particular
> application.
By this I gather you mean application area.
> 2) I want it to be easy to add modules so that the core command interpreter
> may be grown into, say, an ap.
This is an interesting topic. The approach in Lakota is to have a core
library (the interpreter and the basic commands) and an extension facility
to add new commands and functions. I believe TCL does the same thing.
And, of course, one can provide libraries of predefined scripts. It
occurs to me that this is a somewhat parochial approach -- that there
may be a more powerful and general way to deal with language extension.
I would be interested in seeing comments on this topic.
> 3) I want the syntax of the language to be elegant. This sounds like a tall
> order, but what I'm doing is ruling out languages like Scheme; I just cannot
> deal with the Lots of Irrelevant and Stupid Parentheses. Also, I'm afraid that
> Python does not quite fit the bill either. Syntax that is whitespace dependent
> just feels "wrong". I know, I tried using Python for a while.
I haven't used Python, so I don't know what the whitespace dependencies are.
I'm not sure what "elegance" is -- I would take it as a combination of
conciseness, coherence, simplicity, and power. I would rate Scheme as
elegant. I would also rate Lakota as elegant, but I'm prejudiced. It
does use indentation for grouping.
> Let me state here that I have not ruled out any of the other interpreters yet.
> I still want to see if, say, TCL cannot satisfy my needs. Also, let me state
> right away that (1)-(4) contain strong doses of religion; please don't take my
> comments as flames. However, if you disagree, I'm always willing to argue. :-)
Understood. One way to approach languages is in terms of the needs that
they fulfill. This, in no particular order, is a list of needs that Lakota
was designed to meet.
(a) The general objective was to provide a language in which it was
convenient and feasible to write moderately large-scale administrative
scripts.
(b) It should be possible to embed the interpreter in programs written
in other languages and have it available as a service utility.
(c) It should be possible to write programs which which are a mixture
of 3GL compiled code and interpreted routines.
(d) The code should be readable and maintainable by someone with a
modest exposure to the language.
(e) As much as possible, scripts should be portable across OS's.
(f) OS commands (or commands in any other underlying target language)
should be directly executable.
(g) Standard structured programming concepts should be natural.
(h) It should be able to handle string and list manipulation.
(i) The language should have the functionality of standard UNIX
tools such as sed, awk, and find.
(j) There should not be any arbitrary size restrictions.
Ken Dickey
>> 3) I want the syntax of the language to be elegant. This sounds like a tall
>> order, but what I'm doing is ruling out languages like Scheme; I just cannot
>> deal with the Lots of Irrelevant and Stupid Parentheses.
You probably don't use C's ugly curly braces, parenthesis, or square
brackets (why so many types of parenthesis?). Aside from being
elegant--which it is--, Scheme's syntax is trivial. I *never* have to
look at a language manual to use Scheme. I *always* have to look at
manuals for non-lisp-family languages. Syntax should be trivial!
-Ken Dickey ke...@data.uucp
Richard Harter
No - but it's an interesting thought. The character set is all printable
characters. Special characters, in this context, are punctuation characters,
characters used as operators, etc. For example, +-=,.[](){}!~&|$\ etc in
the UNIX shell. It is a design spec that OS commands be legal Lakota commands,
in so far as possible, i.e. a Lakota script can have a mixture of Lakota
and UNIX shell commands under UNIX or Lakota and DCL under VMS. The
stripped syntax is a consequence. For this purpose, Lakota is an extension
language over the underlying OS command language; to avoid syntax conflicts
one avoids attaching special meaning to any character that has special meaning
in the underlying OS languages of interest.
Alan Wright
> Most of the articles on the ap thread have expired here; in particular I missed
> the original article that sparked the exchanges. Byron, I gather, dislikes
> the style of Perl and would like, so to speak, an anti-Perl, even if he has
> to write it himself. This is really a lang.misc topic, so I've added that
> as a group.
I also missed the beginning of this thread, but I would like to know what
Byron (or anyone else) has in mind for an anti-Perl.
> Byron, you don't want to do it. It's more work to develop a language than
> one might imagine, particularly if it is to be a good one. If you don't
I have to disagree. I think more people should be experimenting with more
languages of this general flavor. These very high-level interpreted
languages become more usable and more practical as hardware gets faster
and faster. Of course, it would be helpful if one has a source of funding
or some guaranteed revenue from the result....
> like Perl there are a number of perfectly reasonable alternatives, among
> them TCL, Python, and Icon. There is also Lakota, which I am a principal
... and we sell one called Accent. (Actually, it comes bundled with another
product.)
> developer. [Apologies to all who fuss about people talking about their
> own work duly made. My justification is that I want to talk about the
> language design issues, which are of general interest to those who are
> interested in language design issues.]
ditto.
Our background is as follows:
Some three years ago, we used Perl to prototype a product. When we shifted
to developing the production verson, we decided we still wanted to use
a very-high-level interpreted language with dynamic strings, arrays, tables,
etc.... We did not want to use Perl, because we didn't want the compile
phase at runtime, nor could we deliver source code. So we designed and
implemented Accent, which has the following substantial differences from
Perl:
- declarations and strong type checking
- functions, modules, and classes
- remote function calls (as easy as local calls)
- high-level (i.e. dynamic) first class data structures:
(strings, arrays, tables, composites
- table keys can be any data type (just as values can)
- more palatable syntax (derived from C, Pascal, and others)
- portable source and object code
In short, we added what we thought were good software engingeering
features, so that we could write production code (and in large quantity).
> The main point I would like to make is that it is not such a simple thing
> to design and implement a language, particularly one which is to have
> strong string manipulation capabilities.
Could you elaborate on this (especially on why you think string
manipulation is a significant problem). Initial development of such a
language can be done in only a few months. If there is much interest in
the result, then the additional work to polish and distribute the language
is justified.
The key issue here is how to generate interest. We would probably give away
Accent if people wanted it, but new languages seem to be responded to with
nothing but negativity and criticism. I think there is plenty of room for
many more very-high-level languages, which do not require substantial
learning to use effectively. Languages like Perl, Accent, and perhaps
Lakota only take hours or days to learn thoroughly, and thus pay for this
effort very quickly.
To sum up, I would like to see more variations on the Perl theme. More
languages to test various combinations of features. (Yes, I am aware of
Icon, Python, Rexx, and others, but I don't like any of them).
This technology is still far from providing the final solution, so we
need to keep trying!
P.S. Richard, I would like to hear more about Lakota. In case you are not
going to sell it for profit, I see nothing worng with discussing it at
length in this forum.
Robert Marti
>I *never* have to look at a language manual to use Scheme.
is the preferred style, anyway ... )
>I *always* have to look at manuals for non-lisp-family languages.
having a table of operator precedence pasted to my workstation,
though.
>Syntax should be trivial!
Syntax should make for (human-) readable code. If you find that Lots
of Irrelevant Stupid Parenthesis make for readable code, fine. I don't!
(I guess that makes me a wimp, huh? But Real Programmers (TM) program
in FORTRAN, anyway ;-)
Note: IMHO, Scheme has many strong points: It's a small and orthogonal
language (first-class procedures, continuations). However, its syntax
is definitely not one of them.
Robert Marti | Phone: +41 1 254 72 60
Institut fur Informationssysteme | FAX: +41 1 262 39 73
ETH-Zentrum | E-Mail: ma...@inf.ethz.ch
CH-8092 Zurich, Switzerland |
Doug Philips
ke...@data.UUCP (Ken Dickey) writes:
+>by...@donald.tamu.edu (Byron Rakitzis) writes:
+>> 3) I want the syntax of the language to be elegant. This sounds like a tall
+>> order, but what I'm doing is ruling out languages like Scheme; I just cannot
+>> deal with the Lots of Irrelevant and Stupid Parentheses.
+You probably don't use C's ugly curly braces, parenthesis, or square
+brackets (why so many types of parenthesis?). Aside from being
+elegant--which it is--, Scheme's syntax is trivial. I *never* have to
+look at a language manual to use Scheme. I *always* have to look at
+manuals for non-lisp-family languages. Syntax should be trivial!
And then there are Forth and PostScript with even less syntax!
-Doug
---
Preferred: d...@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
Adrian J Ho
>Scheme may very well be The Future, but this arrogant attitude does nothing
>to promote the language.
Well, I guess Ozan might have gotten a _little_ over-enthusiastic, but
do cut him some slack -- he is, after all, the Scheme Repository
maintainer. 8-)
> Scheme seems to share much of its syntax with
>Lisp, which tends to be a "write only" language.
IMHO, no more "write-only" than C. If your Scheme/Lisp code is neatly
indented and you take care to use descriptive names _and_ comments,
it's very readable. It's probably a matter of getting used to a
particular language. Having a powerful editor like Emacs helps, too 8-).
> Languages in which it
>is often easier to scrap a function and write it from scratch than to
>debug it don't earn high marks among those who have to maintain code for
>a living.
Hardly true of Scheme/Lisp. The only language that might be truly
said to possess this characteristic is APL, and only because of its
infernal character set. (Because of this, APL is the one language
I've encountered in my life that I've never _wanted_ to master.)
Substituting each APL operator with a descriptive name would certainly
go a long way towards making it less of a "write-only" language.
>Scheme may be wonderful, but you shouldn't dismiss people who complain
>about its syntax. Their complaints may be valid.
Perhaps, but the _environment_ under which the complainants use a
particular language often goes a _very_ long way towards shaping their
opinions about language features. For instance, I found (like the
original Scheme complainant) the innumerable parens of Scheme programs
to be a royal pain in the butt -- until I discovered Emacs. With its
paren-matching and "intelligent" indentation capabilities, all was
well again in SchemeLand. 8-)
Another example: Does anyone program in Smalltalk on a regular basis
without a class browser? Would anyone _like_ to? 8-)
Summary: Syntax is only one aspect of a language's appeal.
Development tools, although they have absolutely nothing to do with
the language per se, also play an important role. With the right
tools, even APL can be a joy to program. 8-)
[NOTE: This article should not be construed as a APL-bashing post. I
picked the language as an (extreme) example of a "write-only" language
(to the general programming populace).]
Rich Skrenta
> Your loss. Scheme is a lot more than just Cambridge polish notation
> with lots of parens. I include a reasonably complete biblography for
> you or anybody else who may wish to have a more detailed view of this
> language and some of the concepts embodied within. I am also certain
> that these references would be helpful in designing and implementing
> other languages worth remembering.
Scheme may very well be The Future, but this arrogant attitude does nothing
to promote the language. Scheme seems to share much of its syntax with
Lisp, which tends to be a "write only" language. Languages in which it
is often easier to scrap a function and write it from scratch than to
debug it don't earn high marks among those who have to maintain code for
a living.
Scheme may be wonderful, but you shouldn't dismiss people who complain
about its syntax. Their complaints may be valid.
Richard Harter
I am going to address the following PS first:
> P.S. Richard, I would like to hear more about Lakota. In case you are not
> going to sell it for profit, I see nothing wrong with discussing it at
> length in this forum.
Well, we are sort of on the gray edge here -- Lakota is proprietary to SMDS.
I am a principal in SMDS. We are using it internally; at some point it
may be marketed at a nominal price consistent with financial reality. At
present anyone reading this who wants a beta site copy can get it for the
asking. In view of this, the usual Usenet caveats are relevant. My view
is that it is permissable and valid to discuss Lakota in the context of
language design issues, e.g. "I took this path and made these decisions
for these reasons". That seems to me be fair and legitimate; my interest
is in discussing what should and shouldn't be in languages and what
they are good for. If people disagree, I'll hold my peace.
> In article <5...@smds.UUCP>, r...@smds.UUCP (Richard Harter) writes:
....
> I also missed the beginning of this thread, but I would like to know what
> Byron (or anyone else) has in mind for an anti-Perl.
By the by, I'm not knocking Perl; that was Byron.
> > Byron, you don't want to do it. It's more work to develop a language than
> > one might imagine, particularly if it is to be a good one. If you don't
> I have to disagree. I think more people should be experimenting with more
> languages of this general flavor. These very high-level interpreted
> languages become more usable and more practical as hardware gets faster
> and faster. Of course, it would be helpful if one has a source of funding
> or some guaranteed revenue from the result....
There is much to what you say. Actually, even without the hardware speedup
factor it makes sense. In most applications most of the execution time is
spent in a small percentage of the code. Write that 5-10% in C or whatever.
It is my contention that a good high-level interpreted language is several
times more expressive than a traditional 3GL. Grant me a factor of 5, i.e.
it takes 5 times as much 3GL code to do what you can do in the interpreter.
A good high level interpreter should run about 2-3 times slower than the
equivalent 3GL code. For example: suppose you have an application that
has 100,000 lines of 3GL code. 10,000 lines accounts for 90% of the CPU
usage; 90,000 accounts for 10%. Replace the 90,000 by 18,000 lines of
interpreted code. The result is a program that has 28,000 lines of code
and runs 10-20% slower. The development time drops sharply. These are
reasonable tradeoffs.
However my point was really that it is not so simple to develop a general
language that is a signifigant improvement on what is already available.
There is a psychological trap involved, a tendency to say "I use and
like X, but it could be a lot better so I am going to create my own
language Y." The result is X with a bunch of extra miscellaneous features.
....
> ... and we sell one called Accent. (Actually, it comes bundled with another
> product.)
> Our background is as follows:
> Some three years ago, we used Perl to prototype a product. When we shifted
> to developing the production verson, we decided we still wanted to use
> a very-high-level interpreted language with dynamic strings, arrays, tables,
> etc.... We did not want to use Perl, because we didn't want the compile
> phase at runtime, nor could we deliver source code. So we designed and
> implemented Accent, which has the following substantial differences from
> Perl:
> - declarations and strong type checking
> - functions, modules, and classes
> - remote function calls (as easy as local calls)
> - high-level (i.e. dynamic) first class data structures:
> (strings, arrays, tables, composites
> - table keys can be any data type (just as values can)
> - more palatable syntax (derived from C, Pascal, and others)
> - portable source and object code
> In short, we added what we thought were good software engingeering
> features, so that we could write production code (and in large quantity).
That's a fairly impressive collection of features. It reads like a full
blown modern OOL. I gather from your comments about a compile-phase for
Perl at runtime that you can parse an accent program in advance and execute
off of a representation of the parsed program. Is this correct?
> > The main point I would like to make is that it is not such a simple thing
> > to design and implement a language, particularly one which is to have
> > strong string manipulation capabilities.
> Could you elaborate on this (especially on why you think string
> manipulation is a significant problem).
That was somewhat of an overstatement on part that was conditioned by
the particular issues that I was trying to address. If you are in a
typed language with string variables you can do quite nicely with the
usual collection of string manipulation utilities and operators if you
are only concerned with strings as the content of variables. However
if you permit the dynamic creation of variable (and procedure) names
things get interesting. If one is going to allow multiple levels of
substitution and the inclusion of arbitrary characters one has to be
fairly careful.
> To sum up, I would like to see more variations on the Perl theme. More
> languages to test various combinations of features. (Yes, I am aware of
> Icon, Python, Rexx, and others, but I don't like any of them).
> This technology is still far from providing the final solution, so we
> need to keep trying!
I am curious. Why don't you like them?
Ozan Yigit
skr...@amix.commodore.com (Rich Skrenta) writes:
Scheme may very well be The Future, but this arrogant attitude does
nothing to promote the language.
I don't see anything particularly arrogant about a strong suggestion that
there is more to some languages than their syntax might alone suggest, and
that they should perhaps be studied before their dismissal. I also happen to
like scheme a lot, and I can go to some lengths to help people learn more
about the language, hence the posting of a near-complete bibliography.
Scheme may be wonderful, but you shouldn't dismiss people who complain
about its syntax. Their complaints may be valid.
If I were to dismiss people because they complain about the syntax, I would
not try to help them see beneath it by posting real information. Surprizing
as it may seem, I have no strong feelings about lisp syntax, and in the past
I have challenged other people who made unsubstentiated or irrational claims
on the usefullness of such syntax.
Btw: there is at least one book near completion about the representation and
implementation of programming languages that shows the implementation [using
scheme] of scheme-like languages without a lot of brackets. It should be out
before the summer is over.
oz
---
Often it is means that justify ends: Goals | email: o...@nexus.yorku.ca
advance technique and technique survives even | phone: 416-736-5257 x 33976
when goal structures crumble. -- A. J. Perlis | other: o...@ursa.ccs.yorku.ca
Raul Rockwell
Scheme seems to share much of its syntax with Lisp, which tends to
be a "write only" language. Languages in which it is often easier
to scrap a function and write it from scratch than to debug it
don't earn high marks among those who have to maintain code for a
living.
"Write only" languages tend to be ones you don't understand.
Programmers who can't debug programs don't earn high marks in
anybody's book (except, perhaps, their own). [And an inability to
debug in an interactive environment suggests a severe lack of
discipline.]
--
Raul <rock...@socrates.umd.edu>
Alan Wright
>
> Well, we are sort of on the gray edge here -- Lakota is proprietary to SMDS.
> I am a principal in SMDS. We are using it internally; at some point it
> may be marketed at a nominal price consistent with financial reality. At
You may find that the best you can do prior to some large following
developing is to literally give your language away. Further, the
prevailing attitude is that it must be available in source form.
> There is much to what you say. Actually, even without the hardware speedup
> factor it makes sense.
I agree, I just think some of the traditional performance-related objections
to interpretive languages are now less relevant.
> In most applications most of the execution time is
> spent in a small percentage of the code. Write that 5-10% in C or whatever.
> It is my contention that a good high-level interpreted language is several
> times more expressive than a traditional 3GL. Grant me a factor of 5, i.e.
> it takes 5 times as much 3GL code to do what you can do in the interpreter.
> A good high level interpreter should run about 2-3 times slower than the
> equivalent 3GL code. For example: suppose you have an application that
> has 100,000 lines of 3GL code. 10,000 lines accounts for 90% of the CPU
> usage; 90,000 accounts for 10%. Replace the 90,000 by 18,000 lines of
> interpreted code. The result is a program that has 28,000 lines of code
> and runs 10-20% slower. The development time drops sharply. These are
> reasonable tradeoffs.
I agree with your reasoning here, but my experience shows that not only
do you achieve higher productivity via such languages, that you also
tend to implement more generality, flexibility, and other such
qualities with the more expressive language. I suspect that a general
rule here is that the more code a programmer has to write, the more
corners (s)he will tend to cut.
> However my point was really that it is not so simple to develop a general
> language that is a signifigant improvement on what is already available.
It is not simple to successfully popularize one, but it is NOT difficult
for many of us to try. I suppose it may be a lot like writing a hit song.
It is difficult to predict what features will have strong appeal.
> There is a psychological trap involved, a tendency to say "I use and
> like X, but it could be a lot better so I am going to create my own
> language Y." The result is X with a bunch of extra miscellaneous features.
Not necessarily. For example, there is really no resemblance between
Perl and Accent. The reason for this is that Perl was designed for
one niche (system administration?), while our needs were somewhat
different (production CASE software prototyping and development).
> > - declarations and strong type checking
> > - functions, modules, and classes
> > - remote function calls (as easy as local calls)
> > - high-level (i.e. dynamic) first class data structures:
> > (strings, arrays, tables, composites
> > - table keys can be any data type (just as values can)
> > - more palatable syntax (derived from C, Pascal, and others)
> > - portable source and object code
I forgot one:
- simple API for graphical user interfaces (for X, Sunview, ...)
> > In short, we added what we thought were good software engingeering
> > features, so that we could write production code (and in large quantity).
>
> That's a fairly impressive collection of features. It reads like a full
> blown modern OOL.
Our notion of classes is not well enough developed to qualify as a
real OO language. This is actually more a matter of how we limited
our present implementation than a syntactic issue.
> I gather from your comments about a compile-phase for
> Perl at runtime that you can parse an accent program in advance and execute
> off of a representation of the parsed program. Is this correct?
Yes. Parse once, execute multiple.... Also, we can deliver one object code
for all of our platforms.
> > languages to test various combinations of features. (Yes, I am aware of
> > Icon, Python, Rexx, and others, but I don't like any of them).
> > This technology is still far from providing the final solution, so we
> > need to keep trying!
>
> I am curious. Why don't you like them?
I should rephrase: I don't feel they are well suited for my
applications. I could provide an analysis of each, but instead let me
just say that the set of features we ultimately put into Accent were
some of the features I wanted. I think you'll find that each of these
other languages (let me add Scheme, Smalltalk, ABC, TCL) really was
designed with a different use in mind, or is missing some key feature,
or has some critical misfeature. (No vendor support is a critical
misfeature.)
Now, back to the topic of Lakota. I remember seeing something you posted
in the past which suggested to me that Lakota was perhaps more like a
REXX than a Perl. What I remember is something about controlling the
interactions among a set of subordinate tool processes. Is this correct?
Wayne Throop
> The power of UNIX shell programming
> rests not in the shell language itself, but in the collection of tool
> programs that are standardly available, e.g. sed, awk, find, uniq, sort,
> the execution of the resulting scripts is slow because each tool is
A thought that occurs to me is that the rapid adoption of perl in the
Unix community is a back-door defection to a philosophy that Lisp folks
have been preaching for years. In perl, one is partly abandoning the
the notion of small, stand-alone tools that do one thing well, and
instead adopting the monolithic everything-in-one-language approach that
Lisp has always had. You know. "Swiss army chainsaw." Perl simply
makes this palatable to the Unix community by leaving out some of the
parenthesis and including a baroque syntax and idiosyncratic semantics. :-)
> The main point I would like to make is that it is not such a simple thing
> to design and implement a language, particularly one which is to have
> strong string manipulation capabilities.
Having had recent experience in doing just that (for the usual misguided
reasons), I mildly disagree. By compromising runtime speed somewhat,
one can put together a complete interpreted string-manipulation language
for well under 2000 lines of C code and a month or two of elapsed time.
This doesn't include design time. Double or treble or more that effort
if you then need to squeeze speed out of the thing. Does this match
other folks' estimates/experience?
As an aside, I also find it interesting that "everybody" seems to have
implemented or be implementing a tiny language or two, even if they
later repent. I don't know if that's good, bad, or indifferent,
but it seems to be so.
> Message-ID: <5...@smds.UUCP>
> However my point was really that it is not so simple to develop a general
> language that is a signifigant improvement on what is already available.
Ah. Now *this* formulation seems more apt. "Significant improvement on
what is already available" is the key. Part of the problem is, just
exactly what's "significant" is a difficult question, and easy to be
self-deceptive about. Wrangling with myself over exactly this issue is
what led me down the slippery slope of interpreter implementation.
Somebody who's name I forget just now, talking about TCP/IP and ISO,
coined an apt phrase in this regard. "Just because your local tire shop
doesn't have four-ply radials in stock is no reason to go out and
reinvent the travois."
As I said, I myself have a fine travois which I use daily. I don't
regret inventing it, and I learned a lot from it, and it is a fine and
dandy tool... but my original justification for writing it was, in
retrospect, insufficient.
Finally, I note that I'm familiar with at least one alternative to the
"brutal stripping" of syntax to allow the "outer interpreter" (eg: the
shell) to smoothly encapsulate several "inner interpreters" (eg:
commands with mini-languages in their arguments, like expr, grep, and so
on and on). It is, however, somewhat trickier.
Instead of giving symbols no interpretation at all, you can give them
*lexical* significance, but no *semantic* significance. You can get
away with this because the lexical significance of characters is pretty
standard across languages. For example, () always match, and so on.
One also has to have a regular and predictable quote convention to deal
with the few leftover conflicts, sigh. But one almost always has to
have some moral equavilent of this, even in "brutally stripped"
syntaxes.
What this buys you is the ability to give multiple and more natural
semantic interpretation of characters. Or to put it another way, the
semantics associated with the characters is determined by context, while
at the same time the shell isn't prevented from giving meaning to
characters so strictly. This is especially important in a multi-lingual
debugger.
--
Wayne Throop ...!mcnc!dg-rtp!sheol!throopw
Mark Friedman
A thought that occurs to me is that the rapid adoption of perl in the
Unix community is a back-door defection to a philosophy that Lisp folks
have been preaching for years. In perl, one is partly abandoning the
the notion of small, stand-alone tools that do one thing well, and
instead adopting the monolithic everything-in-one-language approach that
Lisp has always had. You know. "Swiss army chainsaw." Perl simply
makes this palatable to the Unix community by leaving out some of the
parenthesis and including a baroque syntax and idiosyncratic semantics. :-)
Although I understand why many people think of Lisp (esp. Common Lisp)
as a "Swiss army chainsaw", Lisp folks do not, on the whole, preach
the philosophy that you are crediting them with. On the contrary,
Lisp folks have very much espoused the small, do-one-thing-well
approach. A well designed, well programmed Lisp procedure does one
thing well. This, of course, is simply good modular programming.
The "stand-alone" part is where Lisp has sort of failed so far, unless
you consider that Lisp procedures stand alone in the Lisp environment.
As an aside, I also find it interesting that "everybody" seems to have
implemented or be implementing a tiny language or two, even if they
later repent. I don't know if that's good, bad, or indifferent,
but it seems to be so.
This is also a philosophy preached by Lisp folks for years. Large
programs are considered as the creation of application specific
languages. I think that it is good.
Finally, I note that I'm familiar with at least one alternative to the
"brutal stripping" of syntax to allow the "outer interpreter" (eg: the
shell) to smoothly encapsulate several "inner interpreters" (eg:
commands with mini-languages in their arguments, like expr, grep, and so
on and on). It is, however, somewhat trickier.
Instead of giving symbols no interpretation at all, you can give them
*lexical* significance, but no *semantic* significance. You can get
away with this because the lexical significance of characters is pretty
standard across languages. For example, () always match, and so on.
One also has to have a regular and predictable quote convention to deal
with the few leftover conflicts, sigh. But one almost always has to
have some moral equavilent of this, even in "brutally stripped"
syntaxes.
Lisp is nice in this regard because you can leverage on the Lisp
reader which matches the parentheses, handles the quoting, etc. You
can also utilize the Lisp macro facility which is a standard and
powerful machanism for language extension and creation.
-Mark
--
Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139
Larry Wall
: > The power of UNIX shell programming
: > rests not in the shell language itself, but in the collection of tool
: > programs that are standardly available, e.g. sed, awk, find, uniq, sort,
: > and their interconnection with pipes and redirection. [..but..]
: > the execution of the resulting scripts is slow because each tool is
: > a separate process, [...]
:
: A thought that occurs to me is that the rapid adoption of perl in the
: Unix community is a back-door defection to a philosophy that Lisp folks
: have been preaching for years. In perl, one is partly abandoning the
: the notion of small, stand-alone tools that do one thing well, and
: instead adopting the monolithic everything-in-one-language approach that
: Lisp has always had. You know. "Swiss army chainsaw." Perl simply
: makes this palatable to the Unix community by leaving out some of the
: parenthesis and including a baroque syntax and idiosyncratic semantics. :-)
That's not too far off the mark. The baroque syntax and idiosyncratic
semantics are necessary in Perl precisely because they're borrowed from
Unix culture. As such, ugliness is part of its design goal. However,
the monolithicism isn't intended to take anything away from the toolbox
approach, but merely to give you an alternative. Perl isn't a toolbox,
but a small machine shop where you can special-order certain sorts of
tools at low cost and in short order.
As someone else remarked, it's the height of arrogance to design a
language. With normal human languages, nobody can even hope to design
more than a few catchy phrases. Thus, such languages are totally
undesigned. They are, nevertheless, useful upon occasion. I have just
enough hubris to think that I can design a medium-sized language that
has some of the positive aspects of a "large" language without a lot of
its negative aspects. If this is what you're reacting to when you say
"I want anti-perl," then your anti-perl is going to be solving a
different problem than Perl does. More power to you, but I'll keep
doing my thing...
Larry Wall
lw...@netlabs.com
Richard Harter
> You may find that the best you can do prior to some large following
> developing is to literally give your language away. Further, the
> prevailing attitude is that it must be available in source form.
Well, yes, that is generally the case.
> I agree with your reasoning here, but my experience shows that not only
> do you achieve higher productivity via such languages, that you also
> tend to implement more generality, flexibility, and other such
> qualities with the more expressive language. I suspect that a general
> rule here is that the more code a programmer has to write, the more
> corners (s)he will tend to cut.
Particular as deadlines grow closer. :-) I think you are right -- the
gain I see is that a well designed "higher level" language is easier to
write -- line for line of code -- than a traditional compiled 3GL because
irrelevant considerations (for the purpose of the code) do not intrude
themselves. To give a typical example from C, quite often the most natural
way to implement an algorithm is to use pointers into data structures. The
pointers have to all be declared and initialized. While this is simple
enough it is overhead.
I take it as a maxim that any language which does not provide automatic
dynamic storage which you do not have to manage is not really satisfactory.
> > There is a psychological trap involved, a tendency to say "I use and
> > like X, but it could be a lot better so I am going to create my own
> > language Y." The result is X with a bunch of extra miscellaneous features.
> Not necessarily. For example, there is really no resemblance between
> Perl and Accent. The reason for this is that Perl was designed for
> one niche (system administration?), while our needs were somewhat
> different (production CASE software prototyping and development).
This is not what I had in mind. You were trying to do something different.
What I was thinking of more on the lines of fiddling with minor features
and adding gadgets. If you look at the major languages you seen quite
different underlying concepts of what the languages are about. Compare,
for example, FORTRAN, COBOL, lisp, apl, forth, SNOBOL, and eiffel. You
are talking whole different modes of thinking here. My point is that
there is a great tendency to elaborate on the mode of thinking that one
is famliar with. One, in effect, rewrites C with one's particular pet
peeves removed.
> > I gather from your comments about a compile-phase for
> > Perl at runtime that you can parse an accent program in advance and execute
> > off of a representation of the parsed program. Is this correct?
> Yes. Parse once, execute multiple.... Also, we can deliver one object code
> for all of our platforms.
At this point we have settled for parsing at run time (but parsing is
very cheap.) This is a one time cost since procedures, once parsed,
remain available in parsed form for re-execution. Perhaps later.
> Now, back to the topic of Lakota. I remember seeing something you posted
> in the past which suggested to me that Lakota was perhaps more like a
> REXX than a Perl. What I remember is something about controlling the
> interactions among a set of subordinate tool processes. Is this correct?
Just so. The general notion is that you can create execution frames on
the fly which have persistence but which are decoupled. An execution frame
is sort of like a light weight process; however from the viewpoint of the
OS the execution frames are all part of the same process. From a 3GL
program you can start up (or resume) an execution frame which can, in
turn suspend itself and pass control (and data) back to the calling program.
You can also link 3GL routines into the execution frame via an interface
which makes them look like Lakota commands and intrinsic functions.
[3GL is an overstatement -- the interface understands C and the interpreter
is written in C.] The interpreter expects that there is an underlying
shell language that you can pass commands to which is anything that
it doesn't recognize as being a Lakota command. The real difference
between REXX and Lakota (in this regard) is that there isn't a natural
underlying OS such as VM/CMS that Lakota is tied to. (Although AREXX
for the Amiga apparently is a happy combination.) The objective here
is to be able to have multiple pieces of functionality working together
within a common environment.
Richard Harter
> > r...@smds.UUCP (Richard Harter)
> A thought that occurs to me is that the rapid adoption of perl in the
> Unix community is a back-door defection to a philosophy that Lisp folks
> have been preaching for years. In perl, one is partly abandoning the
> the notion of small, stand-alone tools that do one thing well, and
> instead adopting the monolithic everything-in-one-language approach that
> Lisp has always had. You know. "Swiss army chainsaw." Perl simply
> makes this palatable to the Unix community by leaving out some of the
> parenthesis and including a baroque syntax and idiosyncratic semantics. :-)
Baroque?! How can you say such a thing. I opine (loverly word, opine) that
the problem with the UNIX tool set approach is three-fold. The first fold
is that it is (relatively) expensive to connect the tools together. This
is intrinsic to the UNIX approach of making everything a process and the
need to use temporary files for data flows that can't be shoe-horned into
the redirect/pipe model. The second fold is simply that the various
utilities are not all consistent. This is reasonable -- they were
developed independently in an evolutionary fashion. After the fact one
can look at the whole mess and propose [with the aid of hind sight] a
rationalization of the utilities. In some sense this is what perl has
done. The third fold is that the shell (sh, csh) which serves as the
glue to tie all of the pieces together has a number of unfortunate
features.
> > The main point I would like to make is that it is not such a simple thing
> > to design and implement a language, particularly one which is to have
> > strong string manipulation capabilities.
I didn't say what I meant, here. I had in mind a number of issues that
regularly create syntactical awkwardnesses unless they are dealt with
carefully. What I meant to say was that it's simple to design a language
that has a number of messy little annoyances that you don't realize are
there until after you start writing code in it.
> Having had recent experience in doing just that (for the usual misguided
> reasons), I mildly disagree. By compromising runtime speed somewhat,
> one can put together a complete interpreted string-manipulation language
> for well under 2000 lines of C code and a month or two of elapsed time.
> This doesn't include design time. Double or treble or more that effort
> if you then need to squeeze speed out of the thing. Does this match
> other folks' estimates/experience?
Sounds about right, particularly if you sensible about using canned library
utilities. Lakota currently runs about 8500 lines of C and the time spent
in development is much more. [There have been a couple of rewrites and
a fair bit of work on speed.] Lakota does a lot more, which accounts for
the difference in size.
> As an aside, I also find it interesting that "everybody" seems to have
> implemented or be implementing a tiny language or two, even if they
> later repent. I don't know if that's good, bad, or indifferent,
> but it seems to be so.
Who has not cursed the languages that they had available and wished for
better? It seems to me that it would be natural for someone with a modern
CS background to implement a tiny language, given the common emphasis
on language principles and implementation.
> > However my point was really that it is not so simple to develop a general
> > language that is a signifigant improvement on what is already available.
> Ah. Now *this* formulation seems more apt. "Significant improvement on
> what is already available" is the key. Part of the problem is, just
> exactly what's "significant" is a difficult question, and easy to be
> self-deceptive about. Wrangling with myself over exactly this issue is
> what led me down the slippery slope of interpreter implementation.
Self-deceptive? Is that to my address, sir? Name your seconds. It's
pistols at dawn for you. :-)
> Somebody who's name I forget just now, talking about TCP/IP and ISO,
> coined an apt phrase in this regard. "Just because your local tire shop
> doesn't have four-ply radials in stock is no reason to go out and
> reinvent the travois."
> As I said, I myself have a fine travois which I use daily. I don't
> regret inventing it, and I learned a lot from it, and it is a fine and
> dandy tool... but my original justification for writing it was, in
> retrospect, insufficient.
Ah yes. One's own travois is a much finer vehicle than any automobile
from the workshops of Detroit. Most of the time my shell is a Lakota
shell. My, ah, justification is that it looks just like the bourne
shell except when I need something better. However the truth of the
matter is that it is my very own travois. :-)
Doug Philips
+ Perl simply
+makes this palatable to the Unix community by leaving out some of the
+parenthesis and including a baroque syntax and idiosyncratic semantics. :-)
:-) :-)
+As an aside, I also find it interesting that "everybody" seems to have
+implemented or be implementing a tiny language or two, even if they
+later repent. I don't know if that's good, bad, or indifferent,
+but it seems to be so.
Perhaps because "everybody" has read Jon Bentley's Programming Pearls
column on Little Languages?
+As I said, I myself have a fine travois which I use daily. I don't
+regret inventing it, and I learned a lot from it, and it is a fine and
+dandy tool... but my original justification for writing it was, in
+retrospect, insufficient.
I think that one of the important benefits of writing/implementing your
own LL in addition to accomplishing the immediate task at hand, is in
the learning experience.
Darren New
>> Scheme seems to share much of its syntax with
>>Lisp, which tends to be a "write only" language.
>Hardly true of Scheme/Lisp. The only language that might be truly
>said to possess this characteristic is APL, and only because of its
>infernal character set. (Because of this, APL is the one language
>I've encountered in my life that I've never _wanted_ to master.)
>Substituting each APL operator with a descriptive name would certainly
>go a long way towards making it less of a "write-only" language.
Actually, FORTH is also an extremely write-only language. I also find
that Lisp is somewhat write-only when complex programs are programmed
in a funcational style.
I suspect that languages are write-only more because they lack names for
local variables or intermediate results that because they have unusual
characters representing functions. I mean, who would want to write
out "iota" or "rho" every time you wanted an array? :-) :-)
Food for thought, so your brain doesn't starve...
-- Darren
--
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
+=+ Nails work better than screws, when both are driven with hammers +=+
David Gudeman
]In article <21...@sheol.UUCP> thr...@sheol.UUCP (Wayne Throop) writes:
]:a philosophy that Lisp folks
]: have been preaching for years. In perl, one is partly abandoning the
]: the notion of small, stand-alone tools that do one thing well, and
]: instead adopting the monolithic everything-in-one-language approach that
]: Lisp has always had. You know. "Swiss army chainsaw."
]That's not too far off the mark...
Actually, _is_ off the mark. This characterization of Lisp as a
"Swiss army chainsaw" comes from Unix types who are trying to
characterize lisp as a "tool" so that they can have a nice mental box
to put it in. However putting Lisp in a group with lex, yacc, make,
awk, etc. is not quite correct. It would be no less (and no more)
accurate to characterize Lisp as an operating system.
Basically Unix works on the principle that all tools are seperate
programs, loaded seperately by the operating system. This has several
disadvantages -- most obviously that running a seperate program as a
seperate process is expensive.
Another problem with this approach is that communication between tools
is awkward and inefficient because it is all done through character
streams or disk files. For tools that want to communicate complex
data (like a parser communicating with a code generator), each one has
to be able to read and write character representations of the data.
This is expensive in both developement time and execution time.
The Lisp philosophy is to have a system where tools communicate
through high-level data structures, and where communication between
tools is no different from communication between procedures within a
tool. Lisp tries to tie everything into single model and avoid the
two-level system of Unix. In Lisp, the development language, the
shell, the "pipes", the "file system" and sometimes the process
handler are all the same system (Lisp) and the tools are Lisp
procedures. This isn't any more monolithic than Unix, it is just that
the divisions are put in different places.
You can have the "tools" approach in Lisp, but there is no distinction
between a tool and a library routine. In Lisp, you don't need both an
"rm" and an "unlink()". If you have "cp" you don't have to code your
own "copy_file()". And when you write a compiler, you don't have to
decide whether to put the parser and code generator in a single
program for speed, or seperate them for maintainability.
--
David Gudeman
gud...@cs.arizona.edu
noao!arizona!gudeman
Robert Bernecky
>
>>Hardly true of Scheme/Lisp. The only language that might be truly
>>said to possess this characteristic is APL, and only because of its
>>infernal character set. (Because of this, APL is the one language
>>I've encountered in my life that I've never _wanted_ to master.)
>>Substituting each APL operator with a descriptive name would certainly
>>go a long way towards making it less of a "write-only" language.
Easily done: A number of workers in APL design have come up with a new
dialect of APL known as J. J has the following characteristics:
a. Use of ASCII, rather than APL symbols, thereby ending the tyranny of
the keyboard/printer.
b. Simplified syntax and semantics -- a lot of the old rough edges which
crept into APL have been removed, such as funnies with square brackets.
c. First-classness of objects.
d. New versions of J include control structures for DO UNTIL, CASE,
Recursion, as well as generalized reductions. This will appear in
"Gerunds and Representations", in press - ACM SIGAPL APL91 proceedings,
R. Hui and R. Bernecky.
e. ABility to call J from C and vice versa.
Articles on J appear in APL90 (Hui, Iverson, et al), recent issues of
SIGAPL Quote Quad, Vector(British APL Society), and in an article
which appeared in SIGPLAN Notices Feb 1991: "Fortran 90 Arrays", by
yrs trly.
J is available as shareware through a number of bulletin boards (watserv1
is one of them), and from Iverson Software Inc, 33 Major St. Toronto.
($24 for the pc version. Not sure about other versions).
Regarding Character Set Theology: See my article in SIGAPL Quote Quad,
Septmber 1990: "Quad av considered Harmful -- still".
ps: These articles all have the WRRONG email address for me, due to
my inability to type. See below for the correct one(s). the rbe@yrloc...
is preferred.
Robert Bernecky r...@yrloc.ipsa.reuter.com bern...@itrchq.itrc.on.ca
Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9
Canada
Robert Bernecky
>that Lisp is somewhat write-only when complex programs are programmed
>in a funcational style.
>
>I suspect that languages are write-only more because they lack names for
>local variables or intermediate results that because they have unusual
>characters representing functions. I mean, who would want to write
>out "iota" or "rho" every time you wanted an array? :-) :-)
IMHO, languages are write-only less often than applications.
Languages may enhance or reduce the clarity of expression of algorithms
depending on the facilities provided in the languages. For example,
languages which don't supply function call by name, only by line
number (BASIC gosub 12345 is the only one I recall now) reduces
clarity of expression:
a. The 12345 possesses NO semantics content relevant to the algorithm.
b. Maintenence becomes a nightmare, because of line insertion problems.
Applications lead more often to write-only-ness because of design decisions
made (or ignored) by the application developer:
a. Use of globals rather than functional interfaces. This means that
replacement of a functional unit with a new functional unit
(Say a symbol table search/update routine) becomes a nightmare,
in which you must first analyze the ENTIRE system.
b. Use of implicit arguments. This is another globals issue.
c. Failure to write code with an eye toward maintenance and evolution.
The "gee-whiz ain't I bright " approach to coding is fine for rec.puzzles,
or for school coding projects or problems, but is disaster in a real
commercial, scientific, or industrial setting. Even something as
simple as hand-unrolling loops for faster execution on a pipelined
machine, such as the Cray X-MP,comes back to haunt when you try to
port the code to a different architecture, such as a Connection Machine.
Better to suffer the poorer performance on one machine for algorithmic
clarity, and lean on the compiler writers to do it properly.
As a concrete example, consider matrix-matrix product. Writing 5 lines
of DO Loops in Fortran is OK, as newer compilers can figure that out.
Calling MATMUL is also OK. In both cases, the compiler or run-time library
can do its thing properly for the host. However, a tangle of unrolled
code might often run worse when a change in hardware or software
platform occurs.
The write-only code issue is NOT a language issue nearly so much as it
is an issue of attitude and adherence to principles of maintenance.
Bob
Rich Skrenta
rock...@socrates.umd.edu (Raul Rockwell) writes:
> "Write only" languages tend to be ones you don't understand.
>
> Programmers who can't debug programs don't earn high marks in
> anybody's book (except, perhaps, their own).
Strong words, but little insight. Of course you have to understand a
language to debug it. No kidding. But given equal proficiency, could a
programmer debug a similar algorithm implemented in Algol or Forth faster?
How about C vs. Assembly? Scheme vs. teco?
It seems clear that some languages open code written in them to inspection
and understanding. Other languages seem to swallow code in a black goo of
obfuscation.
It's possible that the Magical Power of Lisp-like-languages outweighs the
disadvantages of folding every syntactic construct onto the pattern f(a b c).
I'm suspicious, though. The Scheme crowds' arguments sound an awful lot
like all of the excuses I heard for using Forth.
> [And an inability to
> debug in an interactive environment suggests a severe lack of
> discipline.]
This statement inspired such wonder in me, I couldn't choose between
my responses:
1) My interactive enviroment is Unix and vi, does that count? :-)
2) Good thing all of those nasty undisciplined Fortran programmers
debugging their card stacks between batch runs are gone.
3) What on earth does discipline have to do with using debuggers
and code viewing tools?
> Raul <rock...@socrates.umd.edu>
John Gateley
But given equal proficiency, could a
programmer debug a similar algorithm implemented in Algol or Forth faster?
How about C vs. Assembly? Scheme vs. teco?
As much as it may surprise you, Scheme is a descendent of Algol. And
as much as it may suprise you, the best environment for
coding/debugging in any language I have ever seen was for
Scheme/Common Lisp (the TI Explorer, though scheme is not publically
available).
It's possible that the Magical Power of Lisp-like-languages outweighs the
disadvantages of folding every syntactic construct onto the pattern f(a b c).
I'm suspicious, though. The Scheme crowds' arguments sound an awful lot
like all of the excuses I heard for using Forth.
Your pattern is wrong - it should be (f a b c). But you have missed a
lot: Scheme syntax is simple (<function/command> argument ...), but
that is only one small feature of the language. You can write "the
magical power of lisp" into a C style language if you choose, or you
can write a more restrictive version of "lisp" which is basically
equivalent to C but uses prefix notation. So what - its only syntax.
No, I'm not a Scheme zealot, I just don't like to see a language
trashed because of misunderstanding or dislike of a single feature.
John
gat...@rice.edu
--
"I've thought the thoughts of little children and the thoughts of men
I've thought the thoughts of stupid people who have never been
so much in love as they should be and got confused too easily
to fall in love again." The Residents and Renaldo and the Loaf
Ozan Yigit
skr...@amix.commodore.com (Rich Skrenta) writes:
... But given equal proficiency, could a
programmer debug a similar algorithm implemented in Algol or Forth faster?
How about C vs. Assembly? Scheme vs. teco?
Debugging is an interesting problem. As far as lisp / its descendants go,
they have been well documented in the last two decades, so the answer is
out there in the literature. If you are really in a hurry for something,
a copy of Interactive Programming Environments, from Barstow, Shrobe and
Sandewall may be of some help.
It's possible that the Magical Power of Lisp-like-languages outweighs the
disadvantages of folding every syntactic construct onto the pattern f(a b c).
I don't know what you are trying to say. Could you be a bit more specific?
I'm suspicious, though. The Scheme crowds' arguments sound an awful lot
like all of the excuses I heard for using Forth.
There is no "scheme crowd" making "excuses" for anything. Language is out there
for you to accept or reject. All one can ask is an enlightened response one way
or the other. I hope the bibliography just posted can help facilitate that. Btw
I will have a substantial collection of abstracts before long, in case that may
be more helpful.
enjoy. oz
---
In seeking the unattainable, simplicity | Internet: o...@nexus.yorku.ca
only gets in the way. -- Alan J. Perlis | Uucp: utai/utzoo!yunexus!oz
Raul Rockwell
Looks like I rubbed a scheme zealot the wrong way. :-)
I have a little trouble accepting this idea. Partially because this
is in response to one of my articles, and partially because there are
languages I find much more suited to my purposes than scheme. (Scheme
is too akward at expressing higher-ordered functions for my taste :-).
Raul Rockwell (me):
> "Write only" languages tend to be ones you don't understand.
> Programmers who can't debug programs don't earn high marks in
> anybody's book (except, perhaps, their own).
Rich Skrenta:
Strong words, but little insight. Of course you have to understand
a language to debug it. No kidding. But given equal proficiency,
could a programmer debug a similar algorithm implemented in Algol
or Forth faster? How about C vs. Assembly? Scheme vs. teco?
I seem to recall a team of Forth programmers winning a "recent"
programming contest -- they were the first to come up with a working
program which displayed text on a moving LED bar, or something on that
order. I don't know if anybody even attempted Algol.
The C vs. Assembly argument is basically that there are so _many_
assembly languages that it becomes difficult to learn all of them, let
alone learn many well. C is not the end-all on portability, however.
I'll let scheme and teco fans argue about the virtues of those two
languages.
Anyways, the point [or the "insight", if you prefer] was that
"write-only" is a reflection on programmer skill in a language more
than a reflection of the language itself.
Rich Skrenta:
It seems clear that some languages open code written in them to
inspection and understanding.
Ah, yes, like scheme... ;-)
Other languages seem to swallow code in a black goo of obfuscation.
Obviously refering to C, here... ;-)
It's possible that the Magical Power of Lisp-like-languages
outweighs the disadvantages of folding every syntactic construct
onto the pattern f(a b c). I'm suspicious, though. The Scheme
crowds' arguments sound an awful lot like all of the excuses I
heard for using Forth.
Well, if I pointed out the language that *I* prefer (and find clear
and easy to use), you'd probably choke to death. Let me just say that
I do prefer infix notation.
[This is me:]
> [And an inability to debug in an interactive environment suggests
> a severe lack of discipline.]
[And that's Rich:]
This statement inspired such wonder in me, I couldn't choose
between my responses:
1) My interactive enviroment is Unix and vi, does that count? :-)
to the degree that the environment is interactive, yes.
2) Good thing all of those nasty undisciplined Fortran
programmers debugging their card stacks between batch
runs are gone.
Why? I was simply pointing out that an interactive environment
provides many opportunities for debugging -- if you have the insight
to use them. A batch environment has fewer opportunities for
debugging and so enforces a sort of discipline.
3) What on earth does discipline have to do with using
debuggers and code viewing tools?
And here I thought you were using Unix and vi. ;-)
Anyways, if you get lost in the wonder of it all, you aren't going to
get much debugging done. On the other hand, if you know exactly what
you want to do, and only breakpoint/trace/single-step/dump the key
sections of code, your debugging goes a lot faster.
Once you've been using an environment for a while, this all becomes
second nature, but since the topic seemed to be write-only languages
(which, by definition, are not well understood) I don't think I was
out of line with that comment (3). For instance, breakpoints, and
code viewing, are trivial with scheme.
--
Raul <rock...@socrates.umd.edu>
Darren New
>> debug in an interactive environment suggests a severe lack of
>> discipline.]
> 2) Good thing all of those nasty undisciplined Fortran programmers
> debugging their card stacks between batch runs are gone.
Actually, having done both, I would say an inability to debug in a batch
environment suffests a lack of discipline, and an inability to debug in
an interactive environment suggests inadequate tools.
Raul Rockwell
>> suggests a severe lack of discipline.]
Rich Skrenta:
> 2) Good thing all of those nasty undisciplined Fortran
> programmers debugging their card stacks between batch runs
> are gone.
Darren New:
Actually, having done both, I would say an inability to debug in a
batch environment suffests a lack of discipline, and an inability
to debug in an interactive environment suggests inadequate tools.
Yeah.
Except I'd say that an inability to debug in a batch environment
suggests a lack of paper ;-)
Define the ability and inclination to make tools you need as
"discipline" and you'd have the gist of what I was trying to say.
--
Raul <rock...@socrates.umd.edu>
William Ricker
r...@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>The write-only code issue is NOT a language issue nearly so much as it
>is an issue of attitude and adherence to principles of maintenance.
I'll agree with that. To a large degree, readability is a matter
of discipline in the code's author (& manager & architects). I've
written unreadable code in many lanugages and readable code in as many
-- the same ones. It depends on attitude and taking the time to do it
right the first time, because code you think you'll throw away you
won't be allowed to, or later wish you hadn't.
To call a language write-only because the non-writers can't read the
code of the users is parochial;
To call a language write-only because writers without style can't read
their own code is to inadequately share the blame.
The author and designer of code should always, no matter whether in Knuth's WEB
or an APL workspace, plan the presentation of their code and comments, or
rather, of their comments and code. We can blame a generation with lousy
penmanship and arithmetic skills on Bic Ballpoints, Smith-Corona portable
electric typers, and TI calculators, or we can blame an attitude of quick
and shoddy is good enough.
Certainly in the spirit of Don Norman's /Psychology[Design] of
Everyday Things/, [s]he who designs a hard-to-use tool deserves as
much blame as [s]he who [ab]uses it. Designers of languages *or* the
frontend utilities (like editors & compilers) should consider
readability and writablitity, and be graded on same. But if it's
trivial to write emacs macros that get the syntax right for you, is it
fair to criticize that it's hard to type all the {}; or ((( ))) ??
COBOL and C are both civilized languages when you have the right tools;
colleges with Survey Of Languages courses don't usually have a Screens
Generator and a Data Dictionary to go with the Cobol compiler for the one
COBOL assignement. I wish I had SABRE-C's C editor.
I'll also note that most criticism of languages by those not using
them regularly are usually based on the seminal documentation; no
program written lately in a language calling itself PASCAL or anything
listed above would compile with academic release one of the language
of same name; all the recent usable releases have practical &
theoretical extensions that make them usable. Like loops & if-then-
-else in APL, LISP, FORTRAN, COBOL; standardized I/O in Pascal; Data
Dictionaries to write the boilerplate COBOL automagically, etc.
I've seen incredibly legible APL, FORTH, & LISP, when the
programmers raised the level of the extensible language into the
problem domain; I've also seen APL, FORTH, and LISP that was as
proudly obscure as anything in the Obfuscated C Contest -- and C
almost as bad in products.
APL got a bad wrap from the educational game of "one liners", in
which one competes to invent obscure abuses to do an arbitrary task in
80 chars or fewer, or having done so, challeges colleagues to decipher
same without benefit of comments or sensible variable names. This is
actually an interesting exercise for learning the powerful operators
inside & out -- which wouldn't occur in a language less rich in
operators -- but was (a) the common stereotype of APL hackers, and (b)
adopted by too many folk as the True APL Style. Large APL shops
operated by Boeing, STSC, (and I assume Sharpe) etc gravitated toward
a more maintainable style rapidly; Rose's books document this.
I've written both readable and unreadable code in most of the
so-called Write Only langauges, including several not mentioned here.
My list of Write Only Languages (and which version I used)
APL 370,5110,J
Assembler 370,PDP11,MASM
BASIC EduSystem-8,-11
C Unix PWB,7,III,V.*,4.*,MS5.10
COBOL + TOPS-10
FORTH MMS on TRS-80
FORTRAN-II,IV EduSystem-11/L (II); IBM G,H; TOPS-10; Pr1me [57]50
LISP (before SCHEME) Franz
SNOBOL * **
TECO macros ++ TOPS-10 ***
* begat Icon, alegedly readable, which begat Pearl.
(I fear if I looked at Pearl I might decide it was WO also, and then
I'd have missed two.) I've heard a deck of blank cards attacked
by a lunatic with an icepick would have been a valid Snobol program
which would produce output; I'm not sure if this is true, but ...
** only one I've Missed
*** heard of a fellow at same site who implemented bubble-sort in TECO.
I used TECO macros as equivalent of AWK/SED/TR command pipes.
+ I've written so few lines of COBOL, I think all 3 lines were readable.
++ I doubt I wrote any readable TECO macros! But RMS's mock-lisp for the
TECO-implementation of Emacs would count as having seen some.
Flames to /dev/null, historical oriented followups to alt.folklore.computers,
please.
--- bill [gee, am I getting to be as old as this sounds? ack! ]
--
/s/ Bill Ricker w...@wang.wang.com
"The Freedom of the Press belongs to those who own one."
*** Warning: This account is not authorized to express opinions. ***
Stephen E. Witham
> ...You can write "the
> magical power of lisp" into a C style language if you choose, or you
> can write a more restrictive version of "lisp" which is basically
> equivalent to C but uses prefix notation. So what - its only syntax.
"It's only syntax?" (When you say "more restrictive," you imply more than
syntax, but...) Do you mean that syntax is unimportant, or do you
mean that changing the syntax of Scheme would be easy, or what?
If you say syntax is unimportant, then you're pretty much ignoring
the main issue here. Scheme with a different syntax is a nice idea,
but it would be a different language, as far as this discussion goes.
If you say changing Scheme to look like C would be easy, that's only
half true. I've seen a description of an Algolish, infix-notation front
end for Lisp, and it looked great, and I'm sure that at a certain level,
it's a trivial thing to do, but there are problems, like, how do you
define new operators, and how do you define macros, how do you write
programs that write programs, and how do you put lambda expressions in
the middle of expressions. All of these add little chunks of
complexity, and little chunks of complexity count.
> No, I'm not a Scheme zealot, I just don't like to see a language
> trashed because of misunderstanding or dislike of a single feature.
If a single--integral--feature makes the whole language confusing, then
it's fair to point that out.
--Steve
Stephen E. Witham
> Anyways, the point [or the "insight", if you prefer] was that
> "write-only" is a reflection on programmer skill in a language more
> than a reflection of the language itself.
(Disclaimer up front: I work for SMDS, with Richard Harter, who wrote
Lakota and is in this discussion. The following isn't a plug for Lakota
in particular, though.)
I disagree strongly. When you write a program, you transform your
ideas into a form that the computer can use. In some languages, the
transformation scrambles the evidence of the original thinking process.
In other languages, it's better preserved, so that you can go back and
pick up where you left off.
You might say that a "good" programmer can write a clear program in
any language. This deserves two responses. The first is that the design
of a language (or anything else) should have its users in mind. If the
typical, or natural, way programmers use a language is write-only, then
that's the language designer's fault. Blaming users for the faults of
our designs is one of the crappiest tendencies of computerists, and it's
not mitigated by applying the same macho ethic to ourselves as users of
languages. So, perhaps a programmer could write a clear program in a
given language, but if the language makes this hard for some people, or if
it takes a long time for them to learn how to do it, then the language is
write-only for those people.
Second, it's not true that you can write any program clearly in any
language. In the process of making a program "clearer" in a bad
language, all you can do is add complexity--extra variables, extra lines,
extra function definitions, extra comments--and make the program bigger,
with more parts. This pushes details over the horizon, so that at any one
point, you can see less and less of the relevant detail you need (and more
and more stuff that's just compensating for the weakness of your language).
--Steve
John Gateley
In article <GATELEY.91...@gefion.rice.edu>, gat...@rice.edu (John Gateley) writes:
> ...You can write "the
> magical power of lisp" into a C style language if you choose, or you
> can write a more restrictive version of "lisp" which is basically
> equivalent to C but uses prefix notation. So what - its only
> syntax.
"It's only syntax?" (When you say "more restrictive," you imply more than
syntax, but...) Do you mean that syntax is unimportant, or do you
mean that changing the syntax of Scheme would be easy, or what?
I mean that syntax is relatively unimportant. My personal preference
if for the prefix notation of scheme, but many people don't like it.
What is important about a language though, is the ease with which you
can express algorithms and ideas. This has very little to do with
syntax, unless you choose a completely confusing syntax. Perhaps the
scheme-syntax bashers are claiming that its syntax is completely
confusing. If so, I have to disagree, it's very simple, easy to learn,
and there are lots of tools available to help with those nasty little
parenthesis.
If you say syntax is unimportant, then you're pretty much ignoring
the main issue here. Scheme with a different syntax is a nice idea,
but it would be a different language, as far as this discussion goes.
I disagree with this statement, but ...
If you say changing Scheme to look like C would be easy, that's only
half true. I've seen a description of an Algolish, infix-notation front
end for Lisp, and it looked great, and I'm sure that at a certain level,
it's a trivial thing to do, but there are problems, like, how do you
define new operators,
You don't - scheme doesn't have operators! (cheap answer, I know).
However, it should be fairly easy to come up with some technique. Ada
has the capability of defining new infix operators, doesn't it?
and how do you define macros,
Say foo is a macro, then foo(argument, ... , argument) would be an
invocation of the macro. The parser would have to have a table for
macro definitions, but this wouldn't be hard. See the answer to the
next question for the rest of the answer to this.
how do you write
programs that write programs,
This is the trickiest of the questions you pose. There are cheap
answers: have an intermediate language for these programs which look
like scheme, or just have the program writing program output a text
string. A better idea might be to provide a library with program
constructing functions. Remember, any program writing program must
send its output through eval (or be a macro) and so the parser will
be run on the resulting program as well.
and how do you put lambda expressions in
the middle of expressions.
Whats wrong with saying function (arg ...) { exp ... } a la C? Since
Scheme is expression oriented, these guys can appear anywhere. Perhaps
I missed something here?
All of these add little chunks of
complexity, and little chunks of complexity count.
However, all these little chunks of complexity are already present in
some form in more standard (syntactically) langauges. If you choose
the more complex syntax then you have to pay the price.
David Gudeman
]
]I mean that syntax is relatively unimportant.
How can you say that syntax is unimportant when such a huge percentage
of people who try lisp or scheme are turned off by the syntax? It is
certainly important to them. It is a hindrance to the goal of getting
more people to use the language, and it is a distraction for many
people trying to use the language. Just because it isn't a problem
for _you_ doesn't mean that it isn't a problem.
Any language feature that is unpalatable to large numbers of people is
a misfeature. And calling it "relatively unimportant" isn't going to
make it any less important to the people who are bothered by it. If
you don't think a lot of people are seriously bothered by lisp syntax
then you are mistaken.
By the way, fancy editors may make it easier to balance parens when
writing lisp, but they don't help much in reading it.
Raul Rockwell
How can you say that syntax is unimportant when such a huge
percentage of people who try lisp or scheme are turned off by the
syntax? It is certainly important to them. It is a hindrance to
the goal of getting more people to use the language, and it is a
distraction for many people trying to use the language.
Any language feature that is unpalatable to large numbers of people
is a misfeature. And calling it "relatively unimportant" isn't
going to make it any less important to the people who are bothered
by it.
I don't think that syntax is the big issue for people who don't like
lisp or scheme. The big issues are more along the line of lack of
decent reference works (something like the old MAC-Lisp manual would
be nice -- very complete, to the point, and cheap).
--
Raul <rock...@socrates.umd.edu>
Doug Philips
gud...@cs.arizona.edu (David Gudeman) writes:
+In article <GATELEY.91...@gefion.rice.edu> John Gateley writes:
+]
+]I mean that syntax is relatively unimportant.
+How can you say that syntax is unimportant when such a huge percentage
+of people who try lisp or scheme are turned off by the syntax? It is
+certainly important to them. It is a hindrance to the goal of getting
+more people to use the language, and it is a distraction for many
+people trying to use the language. Just because it isn't a problem
+for _you_ doesn't mean that it isn't a problem.
And just because it is a problem for the so called masses means merely
that is it DIFFERENT from what they are used to. Not wrong. DIFFERENT.
+Any language feature that is unpalatable to large numbers of people is
+a misfeature. And calling it "relatively unimportant" isn't going to
+make it any less important to the people who are bothered by it. If
+you don't think a lot of people are seriously bothered by lisp syntax
+then you are mistaken.
"Tons of people don't like lisp syntax" ... Does ANYONE have any
non-anecdotal, non-fictional data to back this up? Yeah, me'n'my'buddies
donna like it. Wow, am I ever impressed.
No, I don't particular care for LISP syntax because it is not what I use
most of the time. Once you get into the groove its not that big of a deal.
All you've really argued for is making all programming language syntax
sufficiently similar that some first year programming weenie can switch
to it with no hassles.
If you want something really weird try PostScript or Forth.
David Gudeman
]In article <45...@optima.cs.arizona.edu>,
] gud...@cs.arizona.edu (David Gudeman) writes:
]
]+How can you say that syntax is unimportant when such a huge percentage
]+of people who try lisp or scheme are turned off by the syntax?
]And just because it is a problem for the so called masses means merely
]that is it DIFFERENT from what they are used to. Not wrong. DIFFERENT.
No, WRONG. If it is uncomfortable for people, then it is by
definition the wrong syntax to have them program in.
Definition: A "wrong syntax" is any syntax that is uncomfortable for
the people using it.
It is possible that people could become comfortable with a syntax that
they were once uncomfortable with. In this case it would cease being
a "wrong syntax" for that individual. However, in order to make such
an exercise worthwhile you first have to demonstrate that there would
be some great advantage to the new syntax. There is no great
advantage to lisp syntax.
It is possible (but not certain, contrary to what some lispers would
claim) that if everyone had grown up with lisp-like syntax in math
classes that they would all be just as happy with it as they are with
infix syntax. Who cares? The fact is that they didn't grow up with
that sort of syntax, they aren't happy with it, and they shouldn't
have to learn a completely different syntax just because a small
influential community of programmers learned that syntax back in the
days of dinosaurs and IBM 360's when parsing was poorly understood.
It has become institutionalized by now. People who use that syntax on
a regular basis usually had no trouble with it (or they wouldn't be
using it now), and they assume that everyone is just like them, and
should have not trouble with it either. And if anyone _does_ have
trouble with it, then the person must be an uneducated, reactionary
slob who uses phrases like "me'n'my'buddies donna like it".
Wake up. People are different. They have different tastes, different
tolerance for change, and different backgrounds. And when you have
something that a huge majority agree on (like infix notation) then you
should exploit this miracle, not spurn it. And for heaven's sake,
don't try to undermine it (which is just what the lisp community has
been doing).
]"Tons of people don't like lisp syntax" ... Does ANYONE have any
]non-anecdotal, non-fictional data to back this up? Yeah, me'n'my'buddies
]donna like it. Wow, am I ever impressed.
Does anyone have any non-anecdotal, non-fictional data to back up the
claim that the syntax of lisp is _not_ a hindrance to learning it?
(sheesh. If you live in a glass house, don't throw stones.) When the
only evidence available is anecdotal, then that is what you have to
use to form an opinion. My experience involves a non-scientific
sample of perhaps 10 to 20 individuals who learned lisp and didn't
like it. When asked why they didn't like it, the syntax is _always_
mentioned as a negative feature. The sample size is small, but the
variance is impressively low.
By the way, I personally don't have any problem with lisp syntax. I
program in lisp quite a bit and never have minded the syntax (when
using an editor that bounces parens).
]All you've really argued for is making all programming language syntax
]sufficiently similar that some first year programming weenie can switch
]to it with no hassles.
No, I've argued for making syntax comfortable for people in general,
people who have grown up with modern mathematical notations and
learned to program in C or Pascal or BASIC. Beginning programmers
aren't the biggest problem, I expect that it is established
programmers who have the most difficulty with radically different
syntax.
John Gateley
In article <GATELEY.91...@gefion.rice.edu> John Gateley writes:
]
]I mean that syntax is relatively unimportant.
How can you say that syntax is unimportant when such a huge percentage
of people who try lisp or scheme are turned off by the syntax? It is
certainly important to them. It is a hindrance to the goal of getting
more people to use the language, and it is a distraction for many
people trying to use the language. Just because it isn't a problem
for _you_ doesn't mean that it isn't a problem.
Let me try and explain what I mean :^) and at the same time reinforce
what a couple of later posts have already said. Many people don't like
Lisp/Scheme true, but to blame it all or even majorly on the syntax is
unfair. There are many features which require a different mindset:
recursion instead of loops, first class functions, dynamic typing,
macros etc. etc. etc. Among all these new features, I think the
problem of learning an extremely simple syntax is the smallest of the
challenge. The syntax is very regular, has very few special
characters, and can be learned quickly. With a small amount of
practice (and EVERY language requires a small amount, or more) the
programs become understand, and those nasty little parens cease to be
nasty.
Any language feature that is unpalatable to large numbers of people is
a misfeature. And calling it "relatively unimportant" isn't going to
make it any less important to the people who are bothered by it. If
you don't think a lot of people are seriously bothered by lisp syntax
then you are mistaken.
I bet that all the people who are bothered by it are much more
bothered by some of the other features (which are semantic features).
And, a lot of the problem here is being faced with something "new".
For example, I put off learning emacs for the longest time, just
because I hate learning new editors. Different commands, different
styles etc. But, once I did, I really enjoyed it. Similarly
Scheme/Lisp is something new to most people, and all it takes are a
couple of changes to make them frustrated and go back to the old way
of doing it.
By the way, fancy editors may make it easier to balance parens when
writing lisp, but they don't help much in reading it.
I disagree VERY much with this statement. I do most of my code reading
on a terminal in an emacs buffer so that I can use all the commands
when needed. I very rarely print out Scheme code and look at it on
paper.
Michael Coffin
is important to lispers, although others may not find it important.
Lisp programs have a simple, logical representation as data within
lisp: a program is a list of lists, i.e., a tree. In most programming
languages, source-to-source transformations are a pain because to do
anything general you have to parse the language into some idiosyncratic
form, manipulate it, and then translate back into the source language.
In lisp you put a single quote in front of the program and you have
data. That's why lisp is the language of choice for building embedded
languages. It's also why lisp has general-purpose syntax extension
that integrates neatly with the rest of the language (e.g.,
extend-syntax) while C has a crude, tacked-on macro processor
pre-pass.
For people who are interested in the semantics of new constructs as
opposed to syntax, this is a big win. For example, for fun I once
implemented ``Icon in Scheme'', using streams with lazy evaluation to
implement generators and coexpressions. The syntax was lisp-ish, but
it had equivalents for all the interesting Icon constructs except
string scanning. Although I was learning Scheme at the time, it only
took me about three days to get it running.
-mike
John Gateley
[Scheme is good, but not visually graspable]
The problem with Lisp notation, for my "right brain", is that *every*
*structure*looks*the*same*. It's all just forms with arguments.
With C, there are visual differences between function definitions,
variable declarations, [...]
In Lisp or Scheme, in order to tell what type of thing something
is, you have to look at the word at the beginning of the expression or
special form it's in, know what types of arguments that form takes, and
then count down through the arguments.
[...]
My main point was, anybody who can say "just syntax" is either ignoring
the issue of visual clarity, or they have parsers and reference
manuals built into their corneas. Perceptual simplicity is hard to
produce, and Lisp takes a simplistic approach to simplicity.
For me (but of course I am one of those strange Scheme people :^), the
problem is exactly the same but in the other direction. When I look at
languages with more conventional syntax, I have to go through the same
contortions you do. I drag the manual out etc. I accept what you are
saying, but I don't think it implies write-onlyness (perhaps the
problem here is that to me, write-onlyness is a global property which
states that it is ALWAYS hard to read programs in a particular
langauge as opposed to initially hard).
It seems to me, also, that people do have parsers and reference
manuals in their corneas. Consider reading - do you spell out the
words letter by letter and then parse them into a single word? Or do
you get the "gestalt" all at once? But this is getting much too
philosophical and outside my field :^).
I still think that Scheme/Lisp style syntax is a viable alternative
for more conventional syntaxes(syntaci?). With any syntax there is
going to be an initial period where it seems write-only, and I don't
see that this period is any longer for Scheme/Lisp than other
languages (and my personal experience indicates it is shorter). I
think the general idea of "write-onlyness" for Scheme comes from the
amazing amount of languages with more conventional syntax, the extra
expressive power available, and a sort of "social inertia" to new
things.
Tim Barnes
Any language feature that is unpalatable to large numbers of people is
a misfeature. And calling it "relatively unimportant" isn't going to
make it any less important to the people who are bothered by it. If
you don't think a lot of people are seriously bothered by lisp syntax
then you are mistaken.
The CAD Framework Initiative is in the process of standardizing on
Scheme as an extension language for CAD system use. In deciding to use
Scheme, it was critical to the process that we separate the language
semantics from the syntax.
A proposal which did not state categorically that a "C-like or
shell-like" syntax overlay will be defined and made part of the standard
was shot down two months ago. Last week, after rewriting the proposal
to clearly state our committment to dealing with the syntax issue,
Scheme was approved by the Architecture Technical Subcommittee by 24
votes to none (2 abstentions recorded).
The reason for this was that there was clear agreement on the semantic
richness of Scheme, and clear agreement that the normal Scheme syntax
would be difficult to sell to the bulk of the user community. Hence our
compromise.
As the chairperson of the Extension Language Working Group, I am very
happy with this solution. Personally, I'm happy to write Lisp.
However, what I really want is the semantic richness of Scheme, coupled
with whatever it takes to make the language successful.
I believe that's what we're getting, and I think this is an important
point in the life of the Lisp family of languages, because in a sense it
brings them into the main stream. When Scheme implementations (with or
without alternate syntax) are widely available, providing extensibility
to interactive applications, the number of people writing Lisp, (whether
they realize it or not) will increase dramatically.
--
/ / Manager, Framework Technology - Cadence Design Systems
-/- o /__ ___ __ ___ ___ ___ 555 River Oaks Parkway
/ / /\ /\ / / ___/ / / / /__/ /__ San Jose, CA 95134
/__ / / \/ \ /__/ /__/ / / / /__ ___/ bar...@cadence.com (408) 944 7222
Stephen E. Witham
>
> ...Do you mean that syntax is unimportant, or do you
> mean that changing the syntax of Scheme would be easy, or what?
>
> I mean that syntax is relatively unimportant. My personal preference
> if for the prefix notation of scheme, but many people don't like it.
> What is important about a language though, is the ease with which you
> can express algorithms and ideas. This has very little to do with
> syntax, unless you choose a completely confusing syntax. Perhaps the
> scheme-syntax bashers are claiming that its syntax is completely
> confusing. If so, I have to disagree, it's very simple, easy to learn,
> and there are lots of tools available to help with those nasty little
> parenthesis.
Scheme is a great language. Lisp notation is simple to understand--for
my "left brain." That means I can easily figure out (given a manual)
how to write a program, or figure out (given a manual) what a program
means. But I think this thread is about "write-onliness," which to me
includes when I look at a program and my eyes (or "right brain") can't
immediately grasp the structure of it. I think visual "graspability" is
also important to let a program serve as a visual pegboard that memories
and ideas about the program stick to.
The problem with Lisp notation, for my "right brain", is that *every*
*structure*looks*the*same*. It's all just forms with arguments.
With C, there are visual differences between function definitions,
variable declarations, variable assignments, control structures,
expressions, array references, structure field references, and function
calls. In Lisp or Scheme, in order to tell what type of thing something
is, you have to look at the word at the beginning of the expression or
special form it's in, know what types of arguments that form takes, and
then count down through the arguments.
This issue is, for me, only about half of what makes a language readable,
clear, or simple, or not. Scheme is very elegant otherwise.
(Lots of discussion of how do Scheme in C style. John makes good
suggestions. He doesn't get this question:)
> and how do you put lambda expressions in
> the middle of expressions.
>
> Whats wrong with saying function (arg ...) { exp ... } a la C? Since
> Scheme is expression oriented, these guys can appear anywhere. Perhaps
> I missed something here?
Well, what I meant was, in C, function definitions are always on the
top level, and trying to stick them into the middle of expressions
would make a visual mess, sort of like the worst of C and Scheme
combined. Of course, visual mess doesn't bother you. ;^]
My main point was, anybody who can say "just syntax" is either ignoring
the issue of visual clarity, or they have parsers and reference
manuals built into their corneas. Perceptual simplicity is hard to
produce, and Lisp takes a simplistic approach to simplicity.
In order to make a language visually simple, you have to have a good idea
of the kinds of things people will do in it, and in order to do that, you
have to make assumptions. Scheme (even more than older Lisps) goes the
other way and insists on generality in everything. So maybe that makes
Scheme a good AI language--it makes it hard to do easy things, but easy
to do hard things. :-)
--Steve
David Gudeman
]There's at least one advantage to the lisp syntax, and that advantage
]is important to lispers, although others may not find it important.
]Lisp programs have a simple, logical representation as data within
]lisp: a program is a list of lists, i.e., a tree.
I'll agree that that would be a huge advantage if it were only
possible with lisp syntax. But in prolog you can do anything that you
can do with lisp syntax, and prolog uses mostly conventional
function-call and operator syntax.
And I understand (from reading, not first-hand experience) that there
are some languages that have even improved on prolog in this area.
David Gudeman
]Lisp/Scheme true, but to blame it all or even majorly on the syntax is
]unfair. There are many features which require a different mindset:
]recursion instead of loops, first class functions, dynamic typing,
Actually, you _can_ write loops in lisp, and you can ignore
first-class functions and macros if you don't like them. When these
things are mentioned as negative aspects of lisp, they are actually
negative reactions to the way they were taught lisp, or negative
reactions to advanced programming techniques. Neither should be taken
as a criticism of lisp. The lack of static type checking might be
considered a real criticism, but the rest are not.
Giving C News a *HUG*
> In article <2925.UUL1.3#51...@willett.pgh.pa.us> Doug Philips writes:
> ]And just because it is a problem for the so called masses means merely
> ]that is it DIFFERENT from what they are used to. Not wrong. DIFFERENT.
>
> No, WRONG. If it is uncomfortable for people, then it is by
> definition the wrong syntax to have them program in.
Oh? Presumably because object-oriented programming is uncomfortable and
confusing for many people, it is also by definition the wrong way to have
them write programs?
> There is no great
> advantage to lisp syntax.
1. It's simple. You can summarize all the syntax you need to know on the
back of a postcard.
2. It's easy to implement.
3. It's flexible, in the way that (say) infix isn't. Most of the basic
operations (+, *, and so on) naturally extend to any number of arguments.
4. You don't have to worry about any precedence rules whatsoever.
I'm sure other people can come up with lots of advantages I've forgotten.
> It is possible (but not certain, contrary to what some lispers would
> claim) that if everyone had grown up with lisp-like syntax in math
> classes that they would all be just as happy with it as they are with
> infix syntax. Who cares? The fact is that they didn't grow up with
> that sort of syntax, they aren't happy with it, and they shouldn't
> have to learn a completely different syntax [...]
Ah! You're arguing that people should be taught Lisp or RPN in schools? I
agree wholeheartedly. At school I devised a method of using my Casio
calculator in an RPN-like way, because I found it more straightforward. When
I later found out about RPN and got an HP, I thought "Why didn't they teach
me this, or at least mention it, when we started using calculators?"
> ]"Tons of people don't like lisp syntax" ... Does ANYONE have any
> ]non-anecdotal, non-fictional data to back this up? Yeah, me'n'my'buddies
> ]donna like it. Wow, am I ever impressed.
>
> Does anyone have any non-anecdotal, non-fictional data to back up the
> claim that the syntax of lisp is _not_ a hindrance to learning it?
You're the one making the positive assertion, that Lisp's syntax is a
hindrance to learning it. You're the one who has to provide the evidence.
> When the
> only evidence available is anecdotal, then that is what you have to
> use to form an opinion.
When the only evidence is anecdotal, I would advise you not to form such a
strongly-held opinion.
mathew
Doug Philips
gud...@cs.arizona.edu (David Gudeman) writes:
+No, WRONG. If it is uncomfortable for people, then it is by
+definition the wrong syntax to have them program in.
+Definition: A "wrong syntax" is any syntax that is uncomfortable for
+the people using it.
No, it is "uncomfortable syntax." (NOT (EQ 'Uncomfortable 'Wrong))
see also very last comment.
+It is possible that people could become comfortable with a syntax that
+they were once uncomfortable with. In this case it would cease being
+a "wrong syntax" for that individual. However, in order to make such
+an exercise worthwhile you first have to demonstrate that there would
+be some great advantage to the new syntax. There is no great
+advantage to lisp syntax.
Indeed. As someone else has already pointed out, Lisp syntax allows
programs/code to be data, and visa versa. Of course, if you come
from a background in Algol-like languages, you may not see how that
could be valuable. If you think that orthogonality between syntax
and semantics is useful, you would like lisp syntax.
+It is possible (but not certain, contrary to what some lispers would
+claim) that if everyone had grown up with lisp-like syntax in math
+classes that they would all be just as happy with it as they are with
+infix syntax. Who cares? The fact is that they didn't grow up with
+that sort of syntax, they aren't happy with it, and they shouldn't
+have to learn a completely different syntax just because a small
+influential community of programmers learned that syntax back in the
+days of dinosaurs and IBM 360's when parsing was poorly understood.
You have still failed to show whose these "they" are that are so
unhappy, and just how numerous "they" are.
The fact is part of what makes lisp powerful is its highly regular
syntax and that it permits the program/data division to be easily
crossed.
+It has become institutionalized by now. People who use that syntax on
+a regular basis usually had no trouble with it (or they wouldn't be
+using it now), and they assume that everyone is just like them, and
+should have not trouble with it either. And if anyone _does_ have
+trouble with it, then the person must be an uneducated, reactionary
+slob who uses phrases like "me'n'my'buddies donna like it".
Just as the people who use Algol-like languages have become
institutionalized and assume that everyone is just like them.
+Wake up. People are different. They have different tastes, different
+tolerance for change, and different backgrounds. And when you have
+something that a huge majority agree on (like infix notation) then you
+should exploit this miracle, not spurn it. And for heaven's sake,
+don't try to undermine it (which is just what the lisp community has
+been doing).
Wake up? Why? You haven't said anything new. You keep asserting the
same things over and over with no support.
All hail the long and venerated tradition.
+Does anyone have any non-anecdotal, non-fictional data to back up the
+claim that the syntax of lisp is _not_ a hindrance to learning it?
+(sheesh. If you live in a glass house, don't throw stones.)
You: X!
Me: Support it.
You: if not X, then X. Prove not X to me or I'll assume X.
Yawn. Can you distinguish between a challenge to support and a claim
for an opposite position?
+When the only evidence available is anecdotal, then that is what you
+have to use to form an opinion. My experience involves a
+non-scientific sample of perhaps 10 to 20 individuals who learned
+lisp and didn't like it. When asked why they didn't like it, the
+syntax is _always_ mentioned as a negative feature. The sample size
+is small, but the variance is impressively low.
When the sample size is small, the variance don't tell you squat.
You cannot prove your position by lack of opposition. Of course you
gave the game away when you admitted it was a matter of opinion.
+No, I've argued for making syntax comfortable for people in general,
+people who have grown up with modern mathematical notations and
+learned to program in C or Pascal or BASIC. Beginning programmers
+aren't the biggest problem, I expect that it is established
+programmers who have the most difficulty with radically different
+syntax.
I agree that beginning programmers aren't the biggest problem. They
haven't yet learned any preconceived notions about how programming
languages should be written. That admission undermines your position
about "modern mathematical notations", which is not the source of the
difficulty, and highlights that it is instead dogmatic adherence to the
syntax of an early learned language.
Since it is not confusing to beginners who have no preconceived
notions about programming languages, _and_ (tie in from first
comment...) since it is something that people can become accustomed
to, THEN the real point is that rightness/wrongness is nothing
*inherent* about the syntax itself, but is merely a matter of the
habitual experience of people.
Stavros Macrakis
adding more conventional syntax on top of a Scheme-like semantic base.
Algol-like syntax has gone with Lisp-like languages in several
different projects:
-- Lisp 2.0 was a pretty standard Lisp inside, with Algol syntax outside.
-- ECL (or EL/1) had an Algol-like syntax, a Lisp-like approach to
the language environment (interpreter with compatible compiler,
program represented as linked-list data structures available to
other programs, dynamic scoping, ...) and an original approach to
dynamic data typing (types as data, etc.).
-- The Macsyma user language was fairly Algol-like on the outside,
very Lisp-like on the inside. (Macsyma is a large symbolic
algebra system.)
Of course, all of this depends on what you call `Algol-like' and what
you call `Lisp-like'. If you're not careful, you end up calling every
expression-oriented language with a tree-like internal form Lisp-like,
and every language with begin-end blocks Algol-like.
Perhaps Scheme ought to be called Algol-like for that matter, since
Algol had static scoping since the beginning, and Algol 68 even
introduced first-class closures....
And oh, yes, I agree with Witham that there's more to Lisp's syntax
than S-expressions: you've got to count all the special forms as part
of the syntax to be fair.... One of the advantages of Scheme is that
it reduces the number of these.
-s
** I don't have bibliographies, but here are some pointers:
For Lisp 2.0: see Jean Sammet's Programming Languages: History and
Fundamentals
For ECL: Ben Wegbreit's papers in CACM around 1970-75.
For Macsyma: Macsyma Users' Manual (I don't think the language was
described in any detail in the published papers).
Stephen E. Witham
> lisp or scheme.
For people who want a Scheme-like language, but don't like Scheme, like
me, the main reason is probably the syntax.
> The big issues are more along the line of lack of decent reference works...
Last Scheme manual (PC Scheme from TI) seemed pretty complete to me.
--Steve
Stephen E. Witham
> In article <45...@optima.cs.arizona.edu>,
> gud...@cs.arizona.edu (David Gudeman) writes:
> +How can you say that syntax is unimportant when such a huge percentage
> +of people who try lisp or scheme are turned off by the syntax?
> that is it DIFFERENT from what they are used to. Not wrong. DIFFERENT.
To an intellectual populist like myself, something that is inaccessible
to large numbers of people for insufficient reason is WRONG.
> Once you get into the groove its not that big of a deal.
Once you've banged your head enough, you become numb. But that doesn't
mean the damage stops. Lisp syntax just doesn't make good use of the
way human brains and visual systems work. Practice can compensate,
but not totally. It means you spend conscious energy to do what you
can do unconsciously with other languages.
--Steve
Stephen E. Witham
> recursion instead of loops, first class functions, dynamic typing,
> macros etc. etc. etc. Among all these new features, I think the
> problem of learning an extremely simple syntax is the smallest of the
> challenge. The syntax is very regular, has very few special
> characters, and can be learned quickly.
That's true. Learning the rules of Lisp syntax is easy. But there are
two reasons why that doesn't make it easy to read:
#1 is that you're talking about consciously learning
the rules and consciously parsing things. But Lisp syntax doesn't
transfer easily to the unconscious.
#2 is that what other languages do with syntax, lisp does with special
keywords, like defun, lambda, cond, let, prog, loopxxx... I don't know
the exact words, but they all have special structural meanings and
special treatments of certain arguments. Learning all the special
forms and their argument forms takes longer than just learning to
balance parens. And still your eyes can't learn it very well.
> I bet that all the people who are bothered by it are much more
> bothered by some of the other features (which are semantic features).
Well, I for one LOVE the semantics of Scheme and dislike the syntax.
> And, a lot of the problem here is being faced with something "new".
That may be for some people. I've known about Lisp for a long time,
so I don't have a new user's point of view. But I don't think the
semantics are that different from other languages, just more consistent.
I still think syntax is what puts off most of the people who are put off.
> ...I do most of my code reading on a terminal in an emacs buffer so that
> I can use all the commands when needed. I very rarely print out Scheme
> code and look at it on paper.
This sounds like a REAL INTERESTING point. Do you mean you use the
editor to step between arguments and to find matching parens? If so,
you're FEELING your way, or maybe more like WALKING, around the code--
in any case, something kinesthetic is going on...COOL! But notice how
it's like groping in the dark (in a well-labeled, tree-structured space,
(wasn't that a short story by Hemingway?) I grant you). In other words,
Lisp syntax is no help to your EYES, but with emacs as a CANE... This
probably has some great implications for user interfaces for blind people!
--Steve
Stephen E. Witham
> There's at least one advantage to the lisp syntax, and that advantage
> is important to lispers, although others may not find it important.
> Lisp programs have a simple, logical representation as data within
> lisp: a program is a list of lists, i.e., a tree.
Lisp has two features: an internal form for programs, and a (over:-) simple
syntax. I think with an "infix Scheme," having a well-defined internal
form would give you most of the power. You'd need a "code-constant" or
"internal-form-of-this-quoted-code-fragment" construct, e.g.,
x = quote {
function ( a, b ) {
return a+b;
}
};
(That's not a lambda expression, it's a quoted lambda expression.)
> In most programming
> languages, source-to-source transformations are a pain because to do
> anything general you have to parse the language into some idiosyncratic
> form, manipulate it, and then translate back into the source language.
If the compiler (or a library routine) can do the parsing,
and there's a standard (not idiosyncratic) internal form,
and a library routine can print programs,
(or else, you don't go to ASCII, but stay in internal form),
then the situation would be pretty much the same as with Lisp.
Lisp has to be parsed and printed, too, if you're working with ASCII.
> It's also why lisp has general-purpose syntax extension
> that integrates neatly with the rest of the language (e.g.,
> extend-syntax) while C has a crude, tacked-on macro processor
> pre-pass.
I've always wanted "semantic macros" instead of text macros, for C.
--Steve
Stephen E. Witham
> problem is exactly the same but in the other direction. When I look at
> languages with more conventional syntax, I have to go through the same
> Consider reading - do you spell out the
> words letter by letter and then parse them into a single word? Or do
> you get the "gestalt" all at once?
Words--gestalt. Sentences--infix notation (well, mostly) plus special
beginning and end markers! Paragraphs, sections, chapters--visual! Hah!
But English isn't that different from Lisp. On the other hand, English
is constructed for reading straight through rather than hacking on.
--Steve
Raul Rockwell
> Lisp has two features: an internal form for programs, and a (over:-)
> simple syntax. I think with an "infix Scheme," having a
> well-defined internal form would give you most of the power. You'd
> need a "code-constant" or
> "internal-form-of-this-quoted-code-fragment" construct, e.g.,
>
> x = quote {
> function ( a, b ) {
> return a+b;
> }
> };
>
> (That's not a lambda expression, it's a quoted lambda expression.)
Why such a complicated expression? Why not just
x =: +
Then, presumably, when you say
1 x 1
the answer would be
2
Or is it important to quote the thing? You could always say
x =: '+'
(too simplistic? what if you want to have a code constant for some
existing function, independent of its symbol? Well, you could always
adopt a secondary quoting scheme.... Like, maybe
x =: + quoted
)
Requiring a lambda expression to express an anonymous function seems
to me to be one of LISP's flaws, not one of its advantages. Or, put
another way, infix notation already has a clear scheme for
representing arguments, why not take advantage of it?
--
Raul <rock...@socrates.umd.edu>
David Gudeman
]gud...@cs.arizona.edu (David Gudeman) writes:
]>
]> No, WRONG. If it is uncomfortable for people, then it is by
]> definition the wrong syntax to have them program in.
]
]Oh? Presumably because object-oriented programming is uncomfortable and
]confusing for many people, it is also by definition the wrong way to have
]them write programs?
Two answers: (1) there is presumably some other advantage to oriented
programming that gives incentive to go through the discomfort -- the
same does not apply to lisp syntax. (2) if your object oriented
syntax is all that uncomfortable for large numbers of people then,
yes, it is probably wrong. Find a better one.
]> There is no great
]> advantage to lisp syntax.
]
]1. It's simple. You can summarize all the syntax you need to know on the
] back of a postcard.
Not true. You have to specify the special syntax of defun, let,
protect-unwind, do (which is worse than anything I have ever seen in
an algol-like language), etc. You have to specify what operators take
more than the normal number of parameters. And for non-associative
operations you have to specify what multiple parameters mean. Lisp
syntax is _not_ trivial.
]2. It's easy to implement.
That isn't an advantage for the person using the syntax.
]3. It's flexible, in the way that (say) infix isn't. Most of the basic
] operations (+, *, and so on) naturally extend to any number of arguments.
A very minor advantage, and probably the only real one.
]4. You don't have to worry about any precedence rules whatsoever.
The same is true of infix syntax. If you don't know the precedence
you can always use parens (and the result is no worse than lisp). The
difference is that with infix syntax you have the choice.
]> Does anyone have any non-anecdotal, non-fictional data to back up the
]> claim that the syntax of lisp is _not_ a hindrance to learning it?
]
]You're the one making the positive assertion, that Lisp's syntax is a
]hindrance to learning it. You're the one who has to provide the evidence.
The fact is that you seem to believe that lisp syntax does not cause
problems. This is a real opinion. It is different from having no
opinion on the matter, and is just as subject to the need for evidence
as is the opposite opinion. I can even rephrase your stand as a
positive assertion: "lisp syntax is just as good as algol-like
syntax". There, now you have to give evidence and I don't.
]> When the
]> only evidence available is anecdotal, then that is what you have to
]> use to form an opinion.
]When the only evidence is anecdotal, I would advise you not to form such a
]strongly-held opinion.
You have no idea how strongly I hold this opinion.
David Gudeman
]In article <46...@optima.cs.arizona.edu>,
]+Definition: A "wrong syntax" is any syntax that is uncomfortable for
]+the people using it.
]
]No, it is "uncomfortable syntax." (NOT (EQ 'Uncomfortable 'Wrong))
]see also very last comment.
People who choose which programming language to use are going to agree
with my definition, and are not usually going to choose a language
with wrong syntax.
]Indeed. As someone else has already pointed out, Lisp syntax allows
]programs/code to be data, and visa versa. Of course, if you come
]from a background in Algol-like languages, you may not see how that
]could be valuable. If you think that orthogonality between syntax
]and semantics is useful, you would like lisp syntax.
Oh please. I am fully conversant with high-level language issues. I
don't like algol-like languages, and I don't have anything against
lisp syntax personally. My objection to lisp syntax is that it is a
problem for _other_ people. It is not a problem for me. Furthermore,
there is no relationship between lisp syntax and the ability to treat
program as data. Quite the contrary, prolog does a much better job
(in my opinion) of treating programs as data, and prolog has
traditional syntax.
]The fact is part of what makes lisp powerful is its highly regular
]syntax and that it permits the program/data division to be easily
]crossed.
Half true. The program-as-data is an extremely valuable paradigm.
The "highly regular syntax" (which is a myth anyway) has nothing to do
with it. In fact, I suspect that the syntax of lisp was a major
factor in making C the language of the 80's, and the syntax of scheme
is what will make some other language the language of the 90's.
]Just as the people who use Algol-like languages have become
]institutionalized and assume that everyone is just like them.
True enough. People who think there is no alternative to static
typing irritate me even more than people who think lisp syntax is a
non-issue.
]Wake up? Why? You haven't said anything new. You keep asserting the
]same things over and over with no support.
]
]All hail the long and venerated tradition.
Contrary to you? What support have you given for your view except for
your contempt of tradition and of the convenience of others?
]You: X!
]Me: Support it.
]You: if not X, then X. Prove not X to me or I'll assume X.
]
]Yawn. Can you distinguish between a challenge to support and a claim
]for an opposite position?
Yes I can. Can you? You have _not_ just said "support it", you have
been making counter claims (see the end). You have been claiming "not
X" which is different from just asking me to support my view.
Furthermore, I have not said anything similar to "Prove not X to me or
I'll assume X". I reached my conclusions about X on my own, thank
you, with evidence that is conclusive enough for my purposes. If you
can show me counter-X evidence that is stronger than my X evidence, I
will likely change my mind. This is not an emotional issue with me.
]+... My experience involves a
]+non-scientific sample of perhaps 10 to 20 individuals who learned
]+lisp and didn't like it. When asked why they didn't like it, the
]+syntax is _always_ mentioned as a negative feature. The sample size
]+is small, but the variance is impressively low.
]
]When the sample size is small, the variance don't tell you squat.
On the contrary. With a variance of 0, a sample size of 10 is quite
telling. If you tossed a coin 10 times and got heads every time,
wouldn't you feel safe in concluding that the coin is _very_ probably
biased?
]You cannot prove your position by lack of opposition. Of course you
]gave the game away when you admitted it was a matter of opinion.
Where did I admit that? I said that some people are comfortable with
lisp syntax and some aren't. So I guess the anwer to the question "is
lisp syntax comfortable?" is a matter of opinion. But the question
"is lisp syntax a hindrance in getting people to except lisp?" is not
a matter of opinion. The answer is clearly "yes".
]I agree that beginning programmers aren't the biggest problem. They
]haven't yet learned any preconceived notions about how programming
]languages should be written. That admission undermines your position
]about "modern mathematical notations", which is not the source of the
]difficulty, and highlights that it is instead dogmatic adherence to the
]syntax of an early learned language.
That admission does not undermine my position about modern
mathematical notations at all. There are at least two or three
effects here. (Since you seem to like arguing about rhetorical
method, I will observe that the following is speculation. However,
what I am trying to explain by the speculation is the _observation_
that lisp syntax is a hindrance in getting people to accept lisp.)
First, people learn infix notation and f(x) notation from their early
school years. If they learn lisp as their first programming language,
then they have no reason to expect that the programming language will
be like math (after all, prose isn't like math), so they don't rebel
against the difference. But on the other hand, they don't have the
helpful semantic hooks to use when learning lisp that they would have
had learning a language that looks more like math. So learning to
program has been harder for them than it should have been, but they
won't know that.
People who already know a language with a more traditional syntax
already know that it is possible to make languages look like math, and
they will expect it. When these more experienced people don't get
their little semantic hooks they _know_ that they are being subjected
to unnecessary difficulty. That is the source of the negative
reactions to lisp.
A third possible factor is that lisp notation is actually, objectively
harder for the human mind to grasp. I wouldn't want to claim this
outright, but I rather suspect that it is true. I _don't_ believe
this in general about prefix and postfix notations (like Postscript).
Human languages have all three forms of operator/operand distribution:
prefix, infix and postfix (and arguably "outfix" or brackets). What
human languages don't have (as far as I know) is any pervasive feature
that could be described as prefix-with-required-brackets.
]Since it is not confusing to beginners who have no preconceived
]notions about programming languages,
Looks like you are claiming "not X" there. What's your evidence?
] _and_ (tie in from first
]comment...) since it is something that people can become accustomed
]to,
If you mean "everyone" or even "most everyone" can become accustomed
to it, then you are making another assertion without evidence. If you
only mean "some people" then your following:
] THEN the real point is that rightness/wrongness is nothing
]*inherent* about the syntax itself, but is merely a matter of the
]habitual experience of people.
doesn't follow.
Furthermore, _I_ already suggested that this difficulty is probably
caused by experience. Your final sentence makes it sound like like I
was arguing against that. My point (as I clearly stated it before) is
that it doesn't matter why people have difficulty with lisp syntax,
they do. And if their problems are just because they are not used to it
then it is still a real problem. (And you haven't even proven that
the problems can be overcome by everyone).
Michael Coffin
think it's true that Prolog has a conventional syntax. Other than
using infix notation, it looks nothing like any of the popular
languages. That's not surprising; Prolog almost entirely lacks
explicit control structures, which are everywhere in conventional
languages.
And unless you are willing to give up explicit control structures,
things are much more difficult than Prolog. You have to devise ways
to represent not just infix notation, which has a fairly natural tree
representation, but while statements, case statements, for loops,
blocks, procedures, exit statements, ---the list goes on. This has in
fact been done; I once saw a proposal for a Pascal-like language that
allowed programs as data. Each control construct had an internal
format that amounted to a record with fields for each piece. Most of
the fields, were, of course pointers to other records. The result
was, in my opinion, a mess.
By the way, I think we ought to keep in mind that there are several
Lisps. Common Lisp has a rather complicated syntax, as has been
pointed out. Scheme, on the other hand, has a syntax that will fit on
a single page and leave room for comments.
-mike
Mark Friedman
Stephen E. Witham:
> Lisp has two features: an internal form for programs, and a
> (over:-) simple syntax. I think with an "infix Scheme," having a
> well-defined internal form would give you most of the power.
> You'd need a "code-constant" or
> "internal-form-of-this-quoted-code-fragment" construct, e.g.,
>
> x = quote {
> function ( a, b ) {
> return a+b;
> }
> };
>
> (That's not a lambda expression, it's a quoted lambda expression.)
Why such a complicated expression? Why not just
x =: +
Because he was responding to someone who was remarking upon the
usefulness of lisp code being represented as lists. Stephan was trying
to show that you could have some syntax (like 'quote') which when
given a code fragment could return a useful internal representation of
that code, the same way that, in lisp, you can slap a 'quote' around a
piece of code and get a list. He wanted the variable 'x' to be bound
to a representation of the code of the procedure, not the procedure
itself.
Requiring a lambda expression to express an anonymous function
seems to me to be one of LISP's flaws, not one of its advantages.
What's your alternative? You need some syntax to say that you want a
function that takes some number of arguments.
Or, put another way, infix notation already has a clear scheme for
representing arguments, why not take advantage of it?
I won't argue about the usefulness of infix notation, but what has
that to do with anonymous functions?
-Mark
--
Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139
Doug Philips
+In article <2925.UUL1.3#51...@willett.pgh.pa.us>, d...@willett.pgh.pa.us (Doug Philips) writes:
+> And just because it is a problem for the so called masses means merely
+> that is it DIFFERENT from what they are used to. Not wrong. DIFFERENT.
+To an intellectual populist like myself, something that is inaccessible
+to large numbers of people for insufficient reason is WRONG.
Then any computer programming language is WRONG. Your definition is
useless. The dictionary definition even more so.
+> Once you get into the groove its not that big of a deal.
+Once you've banged your head enough, you become numb. But that doesn't
+mean the damage stops. Lisp syntax just doesn't make good use of the
+way human brains and visual systems work. Practice can compensate,
+but not totally. It means you spend conscious energy to do what you
+can do unconsciously with other languages.
There is almost nothing you can do unconsciously without first having
been trained. All you are saying is that there has been sufficient
training/experience with other languages for internalization to have
occurred. That is nothing inherent in the language, it is due to an
external artifact of experience.
In article <6...@smds.UUCP>, s...@smds.UUCP (Stephen E. Witham) writes:
+That's true. Learning the rules of Lisp syntax is easy. But there are
+two reasons why that doesn't make it easy to read:
+#1 is that you're talking about consciously learning
+the rules and consciously parsing things. But Lisp syntax doesn't
+transfer easily to the unconscious.
Another unsubstantiated claim.
+#2 is that what other languages do with syntax, lisp does with special
+keywords, like defun, lambda, cond, let, prog, loopxxx... I don't know
+the exact words, but they all have special structural meanings and
+special treatments of certain arguments. Learning all the special
+forms and their argument forms takes longer than just learning to
+balance parens. And still your eyes can't learn it very well.
Another unsubstantiated claim. Oh, and by the way, obsfucated code
can be written in any language. The formatting (as opposed to syntax)
has much to do with how easily "your eyes" can see structure. That
factor would have to be accounted for as well.
+I still think syntax is what puts off most of the people who are put off.
We are still stuck at unsupported assertions.
+This sounds like a REAL INTERESTING point. Do you mean you use the
+editor to step between arguments and to find matching parens? If so,
+you're FEELING your way, or maybe more like WALKING, around the code--
+in any case, something kinesthetic is going on...COOL! But notice how
+it's like groping in the dark (in a well-labeled, tree-structured space,
+(wasn't that a short story by Hemingway?) I grant you). In other words,
+Lisp syntax is no help to your EYES, but with emacs as a CANE... This
+probably has some great implications for user interfaces for blind people!
Non-sequitur. VI (the editor I use, no comment on preference here) lets
you step over C blocks easily. That I use '%' to move around in a file
has nothing to do with my eyes, but my interaction with the editor.
Do not confuse the format and layout of the code with its syntax, nor
confuse it with the way in which the editor does things. And, _I_
do use printed lisp.
In article <6...@smds.UUCP>, s...@smds.UUCP (Stephen E. Witham) writes:
+Lisp has two features: an internal form for programs, and a (over:-) simple
+syntax. I think with an "infix Scheme," having a well-defined internal
+form would give you most of the power. You'd need a "code-constant" or
+"internal-form-of-this-quoted-code-fragment" construct, e.g.,
+x = quote {
+ function ( a, b ) {
+ return a+b;
+ }
+ };
+(That's not a lambda expression, it's a quoted lambda expression.)
Ok, so that looks like something a Algol-ic would "understand" "easily."
The real question is to show how a program would have written it. What
can the program do with 'x' and how. There are no "built-in" data structres
in a language like (say C, or pascal) for representing that. You'd have
to add one in. Now you aren't talking the same language. I am curious
to follow this part up, but it really isn't part of this thread any more.
+If the compiler (or a library routine) can do the parsing,
+and there's a standard (not idiosyncratic) internal form,
+and a library routine can print programs,
+(or else, you don't go to ASCII, but stay in internal form),
+then the situation would be pretty much the same as with Lisp.
+Lisp has to be parsed and printed, too, if you're working with ASCII.
Yes, but to me the real issue is how do programs manipulate data-which-
is-program? In Lisp you use the same functions you would for any other
list. You'd have to add language level support (for quoted lambda
constants and the "internal form" at least). I suspect, but am willing
to investigate further, that doing so would alter the language in a
non-trivial way.
John Gateley
(hopefully not taken too much out of context).
But Lisp syntax doesn't transfer easily to the unconscious.
And still your eyes can't learn it very well.
I would be interested in some data backing up these assertions. At
this point it is just you and I saying "no you cant! yes you can!".
Unfortunately I don't have any data backing up my assertions other
than I have helped teach scheme for several years, as well as
programming in it, and have not noticed the things you are describing.
I write:
> ...I do most of my code reading on a terminal in an emacs buffer so that
> I can use all the commands when needed. I very rarely print out Scheme
> code and look at it on paper.
This sounds like a REAL INTERESTING point. Do you mean you use the
editor to step between arguments and to find matching parens? If so,
you're FEELING your way, or maybe more like WALKING, around the code--
in any case, something kinesthetic is going on...COOL! But notice how
it's like groping in the dark (in a well-labeled, tree-structured space,
(wasn't that a short story by Hemingway?) I grant you). In other words,
Lisp syntax is no help to your EYES, but with emacs as a CANE... This
probably has some great implications for user interfaces for blind people!
I think you are taking my point slightly incorrectly. Suppose you are
programming in language X, and have a big huge function (several
pages, full of nested loops etc.). Can your eyes parse it? I use the
editor to help me with cases like that, and to make sure that parens
balance. I do not consider myself "feeling my way". I have a good tool
and I use it.
j
Darren New
>syntax. I think with an "infix Scheme," having a well-defined internal
>form would give you most of the power. You'd need a "code-constant" or
>"internal-form-of-this-quoted-code-fragment" construct, e.g.,
I would like to just interject that Hermes is a strongly-typed,
powerful, high-level modular infix distributed programming language
that has "program" as a built-in data type. All of what *I've* seen
Lisp do with programs could be done as easily with Hermes programs.
You can even pass them around, store them in libraries, and so on.
Check it out. It's neet. :-)
Now, if only you could write a constant of any type, we'd be in great shape.
-- Darren
--
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
+=+ Nails work better than screws, when both are driven with hammers +=+
Raul Rockwell
> Lisp has two features: an internal form for programs, and a
> (over:-) simple syntax. I think with an "infix Scheme,"
> having a well-defined internal form would give you most of the
> power. You'd need a "code-constant" or
> "internal-form-of-this-quoted-code-fragment" construct, e.g.,
> x = quote {
> function ( a, b ) {
> return a+b;
> }
> };
> (That's not a lambda expression, it's a quoted lambda expression.)
Raul Rockwell (me):
Requiring a lambda expression to express an anonymous function
seems to me to be one of LISP's flaws, not one of its advantages.
Mark Friedman:
What's your alternative? You need some syntax to say that you want
a function that takes some number of arguments.
Well, you can say that an infix function takes one or two arguments.
Make one argument optional (with greedy binding) and ambiguity may be
resolved when the function is used. e.g. x-y vs. -y
A less elegant solution might be to always require two arguments and
use BOTTOM a lot.
Me: Or, put another way, infix notation already has a clear scheme
for representing arguments, why not take advantage of it?
Mark Friedman:
I won't argue about the usefulness of infix notation, but what has
that to do with anonymous functions?
You can define anonymous functions using infix notation by either (a)
explicitly declaring dummy variables (similar to (lambda (x y) ...))
(b) using a pair of "standard names" for dummy variables, or (c)
tacitly defining functions without the use of any dummy variables
(just say what functions preprocess the arguments/postprocess the
results).
I expect you'd want a good variety of data-structure building
functions for something like this (otherwise you could only work with
"toy" data). [And a good variety of meta-functions for leverage.]
Or maybe I'm missing the point of the question??
--
Raul <rock...@socrates.umd.edu>
Raul Rockwell
Prolog almost entirely lacks explicit control structures, which are
everywhere in conventional languages.
And unless you are willing to give up explicit control structures,
things are much more difficult than Prolog. You have to devise
ways to represent not just infix notation, which has a fairly
natural tree representation, but while statements, case statements,
for loops, blocks, procedures, exit statements, ---the list goes
on.
There is no reason these things can't be expressed as functions and/or
meta-functions. For example, a case statement may be represented as a
meta-function which takes two arguments: (1) a list of function
representations and (2) a selection argument.
Blocks are even simpler -- use the same notation you use to describe
data and pass the results to a meta-function which returns a usable
function.
There are a number of ways to construct for/while loops, ranging from
repeated application of a function to some data (similar to
"foreach"), to a more explicit iteration where you supply a predicate
to determine when the loop is complete.
I'll agree (in advance) that you'll want some sort of meta-function
syntax so that you can take functions as arguments, but that need not
be complex.
--
Raul <rock...@socrates.umd.edu>
Rich Skrenta
> +Once you've banged your head enough, you become numb. But that doesn't
> +mean the damage stops. Lisp syntax just doesn't make good use of the
> +way human brains and visual systems work. Practice can compensate,
> +but not totally. It means you spend conscious energy to do what you
> +can do unconsciously with other languages.
>
> There is almost nothing you can do unconsciously without first having
> been trained. All you are saying is that there has been sufficient
> training/experience with other languages for internalization to have
> occurred. That is nothing inherent in the language, it is due to an
> external artifact of experience.
I could write sentences in all-caps without proper spacing and you would
still be able to understand it. It would just be harder for your eyes to
parse, and experience would never completely overcome this.
Mapping every semantic meaning onto the same syntactic construct makes lisp
hard for eyes to parse.
a[i] * a[i+1]
(* (index a i) (index a (+ i 1)))
Hmmm. Let's do a study. Flash equivalent code up to programmers well versed
in Lisp and an infix language and see which they can parse visually faster.
--
Rich Skrenta (skr...@blekko.commodore.com)
Industrial Poet
> In article <2Xc841...@mantis.co.uk> Giving C News a *HUG* writes:
> ]Oh? Presumably because object-oriented programming is uncomfortable and
> ]confusing for many people, it is also by definition the wrong way to have
> ]them write programs?
>
> Two answers: (1) there is presumably some other advantage to oriented
> programming that gives incentive to go through the discomfort -- the
> same does not apply to lisp syntax.
That's your opinion. A lot of people see great advantages in the syntactic
flexibility and simplicity of Lisp.
> ]1. It's simple. You can summarize all the syntax you need to know on the
> ] back of a postcard.
>
> Not true. You have to specify the special syntax of defun, let,
> protect-unwind, do (which is worse than anything I have ever seen in
> an algol-like language), etc.
Sorry? What "special syntax" are you referring to here with your examples?
I'm not entirely sure I understand what you mean by a "special" syntax as
opposed to the standard one.
> You have to specify what operators take
> more than the normal number of parameters.
You're applying a concept which doesn't fit the language. Lisp functions
like + and cond don't have a "normal number of parameters". (+ 2 3 5) isn't
a special version of + with an abnormal number of parameters; it's the same +
which you find in (+ 2 3).
> And for non-associative
> operations you have to specify what multiple parameters mean.
You have to specify what the parameters mean for other sorts of syntax as
well.
> ]You're the one making the positive assertion, that Lisp's syntax is a
> ]hindrance to learning it. You're the one who has to provide the evidence.
>
> The fact is that you seem to believe that lisp syntax does not cause
> problems.
Untrue. I believe that Lisp syntax does cause problems, I just don't believe
that Lisp syntax is a hindrance to learning the language -- at least, not to
those who are actually prepared to try and learn the language.
> I can even rephrase your stand as a
> positive assertion: "lisp syntax is just as good as algol-like
> syntax".
That isn't what I'm saying at all. You haven't re-phrased my stand, you have
re-defined it.
My opinion is: (not (believe (syntax-hinders-learning Lisp))).
If it were (believe (not (syntax-hinders-learning Lisp))) then you could
indeed re-phrase it as a positive assertion. But as it stands I am not
making an assertion; I am simply doubting an assertion you have made.
> ]When the only evidence is anecdotal, I would advise you not to form such a
> ]strongly-held opinion.
>
> You have no idea how strongly I hold this opinion.
Clearly you hold it fairly strongly, or you wouldn't go on about it so much.
mathew
Richard Harter
I can do this sort of thing in Lakota, e.g.
set-list prog {procedure fooby}
sets the contents of of list prog to be the statements of procedure fooby,
and
execute-string blatifu
interprets the contents of string blatifu as a sequence of statements
which are then executed. I find these capabilities moderately useful.
Example: I have interactively entered a procedure, used it, and then
decided that I want to modify it so I print the procedure to a file,
edit, and then execute the file to recapture the procedure. Convenient
but not earth-shaking. Example: I have a library which I don't want
to load into memory but which I want available. I associate with each
entry point in the library a stub with the same name. The stub executes
the library file, replacing the stub with the real routine, and invokes
the real routine with the arguments passed to the stub. Again, a
convenience, but only that.
My question is this: People regularly cite the ability to treat programs
as data as an important feature of lisp. Fine. What is this ability
good for that makes it so important. I can see the utility of programs
that write programs that will be executed later. But it seems like
treating programs as data involves two steps:
from data X create program (=data) Y
using data Z as input execute program Y producing W
However the program in the first step logically should be able to take
X and Z an inputs and produce W; an interpretation of X is required
in either case. The program writing program may be more efficient
since the interpretation is done once. However that is an engineering
question. What is the conceptual gain and how does it work in practice?
For example, suppose I am writing a natural language whazis, and I
decide to create a procedure for each word. That sounds nice. However
why do I have to create a procedure for the word? The code that writes
the procedure "knows" all the decisions that go into writing the procedure
for the word. Or to take another context if I have table driven code
why create procedures for the table entries?
Can someone cite some examples where data=program is essential.
--
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb. This sentence short. This signature done.
Raul Rockwell
Can someone cite some examples where data=program is essential.
The canonical examples are:
(1) creation of development tools (e.g. debuggers, optimizers,
archival systems).
(2) symbolic math packages.
I'm not sure if these show that data=program is essential, but then
data and control flow are just two aspects of the same thing.
I think the best argument for a language which can manipulate its own
code is Von Neumann's: you can develop faster if you can use the
machine to manipulate your code. Another argument is robustness of
data structures: such a language must have an adequate set of data
structure primitives.
Enough said?
--
Raul <rock...@socrates.umd.edu>
John Gateley
Can someone cite some examples where data=program is essential.
In a word: macros.
Chris Dollin
Doug Philips says:
Indeed. As someone else has already pointed out, Lisp syntax allows
programs/code to be data, and visa versa. Of course, if you come
from a background in Algol-like languages, you may not see how that
could be valuable. If you think that orthogonality between syntax
and semantics is useful, you would like lisp syntax.
Can we dispose of this myth for once and for all?
It's not ``Lisp syntax'' that allows code-as-data; it's because there's a
canonical representation for program texts as a supported datatype. In Lisp,
the supported datatype happens to be lists, and the mapping twixt source and
representation is at least translucent. But there's no reason an ``Algol-like''
language (whatever that means in 1991; are C, Ada, ML, Pop11, or Scheme
Algol-like? Answers on a postcard please ...) shouldn't provide a suitable
data-type and representation scheme.
For example ``here's one I prepared earlier'': in my Pop-like language Pepper,
I plan to include a construct such as ``<$ Expr $>'' to mean ``the parse tree
associated with Expr''. There will be operations on parse trees, such as gluing
them together and taking them apart, or generating code from them. (The present
compiler uses lists for parse trees - surprise! - but the post-bootstrap
compiler will have a more compact representation engineered to its needs.)
So it's not the (concrete) syntax of Lisp that gives code-as-data; it's the act
of making the parse tree *available*.
[Incidentally, rather than an anti-quoting syntax within the quote brackets, I
am thinking of making the quote take a left operand, viz, the names to be taken
as meta-variables inside the quotation, thus:
(x) <$ f(x) $>
would denote the parse tree for an application whose function-part is f and
whose argument part is the expression in the variable x. Any comments on this
idea?]
--
Regards, Chris ``GC's should take less than 0.1 second'' Dollin.
Silver
memory-is-managed, ... languages.
gud...@cs.arizona.edu writes:
>> 1. It's simple. You can summarize all the syntax you need to know on the
>> back of a postcard.
>
> Not true. You have to specify the special syntax of defun, let,
> protect-unwind, do (which is worse than anything I have ever seen in an
> algol-like language), etc. You have to specify what operators take more than
> the normal number of parameters. And for non-associative operations you have
> to specify what multiple parameters mean. Lisp syntax is _not_ trivial.
Make the distinction between SYNTAX and SEMANTICS. In a description of Lisp's
semantics, one should introduce the notions of macros and read-time evaluation.
The semantics of the special forms can then be described in a straightforward
fashion, for example, by noting the equivalence of the following:
(let ((variable-1 value-1) ((lambda (variabl-1 ... variable-N)
... form-1
(variable-N value-N)) ...
form-1 form-M)
... value-1
form-M) ...
value-N)
I tend to agree with you that the SEMANTICS of some `do's are much too hairy,
so I never use it. Nonetheless, this degenerate case works the same as the
others, just a matter of degree.
>> 3. It's flexible, in the way that (say) infix isn't. Most of the basic
>> operations (+, *, and so on) naturally extend to any number of arguments.
>
> A very minor advantage, and probably the only real one.
The ability to handle variable numbers of arguments is a big win. Seriously
affects readability and usability. This feature should be provided by a clean
(hell, transparant) syntax.
>> 4. You don't have to worry about any precedence rules whatsoever.
>
> The same is true of infix syntax. If you don't know the precedence you can
> always use parens (and the result is no worse than lisp). The difference is
> that with infix syntax you have the choice.
YOU can insert the parens, but the next bloke might not. And you may have to
play with his code someday. And when you do, you better remember that C's
bitwise-and operator `&' is of higher precedence than the bitwise-xor operator
`^'. The regular syntax eliminates this type of error even if I'm not fond of
expressiong *every* expression in prefix notation.
Note that I've conveniently sidestepped the issue. Because programs are data,
I know that I can write an infix expression macro within the bounds of the
language. Experience has shown it to be relatively straightforward. (However,
I never use the critter because I am comfortable with prefix notation.)
Extending this toy to handle new operators with a given precedence and
associativity is relatively easy. In fact, I'd say that it does infix better
than most imperative languages because it is so easy to manipulate programs as
data in Lisp.
>> You're the one making the positive assertion, that Lisp's syntax is a
>> hindrance to learning it. You're the one who has to provide the evidence.
>
> The fact is that you seem to believe that lisp syntax does not cause
> problems. This is a real opinion. It is different from having no opinion on
> the matter, and is just as subject to the need for evidence as is the
> opposite opinion. I can even rephrase your stand as a positive assertion:
> "lisp syntax is just as good as algol-like syntax". There, now you have to
> give evidence and I don't.
Well said. But let's dispense with the meta-arguments for the moment. I have
never had a problem teaching Lisp. I've invariably gotten faster results with
Lisp than with imperative languages like C and Pascal. The major issue was one
of syntax. Once we struggled through a formal discussion of the general syntax
and the low-level semantics, they had no problem learning the individual
special forms.
The key words here are simplicity and genericity.
Regards, [Ag]
Silver
> People who choose which programming language to use are going to agree
> with my definition, and are not usually going to choose a language
I dunno 'bout that. I am not as fond of Prolog's syntax as I am of Lisp's.
Yet when the shoe fits, I wear it. The dialect of Lisp I most frequently use
is GNU Emacs Lisp. This Lisp is truly canine, but the Emacs environment is
fantastic.
Regardless, as long as the syntax is short, simple, and unsweetened with fluff,
it is acceptable. Notational simplicity will win out in the end, not only by
virtue of simplicity, but because it is easy to transform and extend. From a
practical perspective, there is no reason why one shouldn't be able to
mechanically switch between reasonably simple syntaxes.
Regards, [Ag]
Richard A. O'Keefe
> It's true that Prolog handles programs-as-data nicely, but I don't
> think it's true that Prolog has a conventional syntax.
Prolog syntax is (extensible) operator-precedence. That's about as
conventional as you can get.
> Other than
> using infix notation, it looks nothing like any of the popular
> languages. That's not surprising; Prolog almost entirely lacks
> explicit control structures, which are everywhere in conventional
> languages.
Prolog has sequence and if->then;else. What's missing? Assignment
and `obvious' while-loops, which go together.
--
I agree with Jim Giles about many of the deficiencies of present UNIX.
Raul Rockwell
The ability to handle variable numbers of arguments is a big win.
Seriously affects readability and usability. This feature should
be provided by a clean (hell, transparant) syntax.
Note that LISP's ability to handle a variable number of arguments is
equivalent to an ability to handle one argument of arbitrary
complexity. Further, it is (or should be) trivial to extend a
function which is associative, and takes two arguments, to a function
which takes an arbitrary number of arguments [or takes one argument
which is a list of arguments...].
--
Raul <rock...@socrates.umd.edu>
David Gudeman
]gud...@cs.arizona.edu (David Gudeman) writes:
]>
]> programming that gives incentive to go through the discomfort -- the
]> same does not apply to lisp syntax.
]
]That's your opinion. A lot of people see great advantages in the syntactic
]flexibility and simplicity of Lisp.
A lot of people don't.
]> ]1. It's simple. You can summarize all the syntax you need to know on the
]> ] back of a postcard.
]>
]> Not true. You have to specify the special syntax of defun, let,
]> protect-unwind, do (which is worse than anything I have ever seen in
]> an algol-like language), etc.
]
]Sorry? What "special syntax" are you referring to here with your examples?
]I'm not entirely sure I understand what you mean by a "special" syntax as
]opposed to the standard one.
The do loop is part of the standard sytax. It is a very complex
structure, and cannot be described on a postcard even by itself, even
along with the rest of the syntax. The syntax of lisp special forms
is just as complicated as control structures in any other language.
The only difference is that in lisp these control structures are
forced to look like function calls (which makes them harder to
recognize). The _only_ think in lisp syntax that can be truly be
called "simpler" than traditional syntax is the lack of infix
operations.
]
]> You have to specify what operators take
]> more than the normal number of parameters.
]
]You're applying a concept which doesn't fit the language. Lisp functions
]like + and cond don't have a "normal number of parameters". (+ 2 3 5) isn't
]a special version of + with an abnormal number of parameters; it's the same +
]which you find in (+ 2 3).
First, cond isn't a function it is a special form (called a control
structure in other languages). People often make such mistakes in
Lisp because of the "simplifying" homogeneous syntax. (In fact when I
taught lisp, I found one of the most confusing things to my students
was trying to distinguish between functions and special forms.)
Second, (+ 2 3 5) certainly _is_ a special version of + with an
abnormal number of parameters. + is taken from mathematics where it
almost always has just two arguments.
]If it were (believe (not (syntax-hinders-learning Lisp))) then you could
]indeed re-phrase it as a positive assertion. But as it stands I am not
]making an assertion; I am simply doubting an assertion you have made.
Sorry, I had you confused with the person who wrote the original
article. He certainly _did_ make positive assertions, therefor your
claim that I was the only one who needed to provide evidence is wrong.
]> You have no idea how strongly I hold this opinion.
]
]Clearly you hold it fairly strongly, or you wouldn't go on about it so much.
Shows what you know. I would go on about anything if I was prodded
right (I expect many of the regular readers of this group can vouch
for that :-). My prodding in this case came from an article where
someone said the issue of syntax isn't important. I find this
attitude to be particularly arrogant. Just because it isn't a problem
for _you_ doesn't mean it isn't a problem. And my observations
indicate that it _is_ a problem for a lot of people.
It so happens that I _don't_ hold this opinion very strongly. I could
be easily swayed by an experimental study on the matter (even though I
am not under the illusion that such studies are always sound).
David Gudeman
]My opinions on this discussion highly favor the all-is-data, syntax-is-simple,
]memory-is-managed, ... languages.
These three things are mostly orthogonal. The only dependency is that
it is pretty hard to have an all-is-data model without memory
managment -- otherwise those features are independent and unrelated.
]Make the distinction between SYNTAX and SEMANTICS.
If you have a wierd syntax that encourages structures with wierd
semantics (like a mulitple-argument minus), then the syntax is making
the semantics more complicated and you have to take that into account
when discussing if the syntax makes the language simpler.
]The semantics of the special forms can then be described in a straightforward
]fashion, for example, by noting the equivalence of the following:
That doesn't make the syntax any simpler. You still have to describe
all the possible variations of all the special forms.
]I tend to agree with you that the SEMANTICS of some `do's are much too hairy,
]so I never use it. Nonetheless, this degenerate case works the same as the
]others, just a matter of degree.
I guess it depends on what you are going to call syntax (the
distinction is not as obvious as you seem to think). I include in the
syntax the positioning of the relevant parts according to their
function. If you are going to claim that syntax is just what is
describe by the BNF grammar then I say that there is no reason to
suppose that such simplicity is an advantage. Who cares if you can
describe lisp syntax as a sequence of s-expressions? That doesn't
tell you anything about how to write a lisp program.
]>> 3. It's flexible, in the way that (say) infix isn't. Most of the basic
]>> operations (+, *, and so on) naturally extend to any number of arguments
]> A very minor advantage, and probably the only real one.
]The ability to handle variable numbers of arguments is a big win. Seriously
]affects readability and usability. This feature should be provided by a clean
](hell, transparant) syntax.
I don't believe (+ x1 x2 ... xn) is any clearer than x1 + x2 + ... +
xn. Hmm. I think I'm going to have to take back where I said that
this is an advantage of lisp. I was really thinking about the ability
to distribute an operation over a sequence, which is unrelated to
syntax.
]YOU can insert the parens, but the next bloke might not. And you may have to
]play with his code someday. And when you do, you better remember that C's
]bitwise-and operator `&' is of higher precedence than the bitwise-xor operator
]`^'. The regular syntax eliminates this type of error even if I'm not fond of
]expressiong *every* expression in prefix notation.
If you don't remember the precedence then look it up and put in the
parens. Or have an editor do it for you. It was lisp defenders who
set the precedent that if an editor function can make up for a
deficiency then the deficiency doesn't count.
]Note that I've conveniently sidestepped the issue. Because programs are data,
]I know that I can write an infix expression macro within the bounds of the
]language.
Terrific. Then I'll get an infix language with programs-as-data and
do the reverse. It doesn't prove anything either way. (Except that
the fact that people always want such things in lisp and never want it
in prolog implies that prolog has better syntax).
][teaching languages]
]I've invariably gotten faster results with Lisp than with imperative
]languages like C and Pascal. The major issue was one of syntax.
]Once we struggled through a formal discussion of the general syntax
]and the low-level semantics, they had no problem learning the
]individual special forms.
It sounds like you are agreeing with me that syntax is the major
problem in getting people to accept lisp. It is obvious to me that
except for the syntax, it is _much_ easier to program in lisp than in
C or Pascal. If lisp had a decent syntax it would be that much better
a language.
(Just to nit-pick, Lisp _is_ an imperative language. It happens to be
expression-based and to have first-class functions and lots of
built-in functionals, but it also has a global store and assignment.)
Norman Diamond
>In article <2928.UUL1.3#51...@willett.pgh.pa.us> Doug Philips writes:
>>In article <46...@optima.cs.arizona.edu>,
>>No, it is "uncomfortable syntax." (NOT (EQ 'Uncomfortable 'Wrong))
>>see also very last comment.
>
>People who choose which programming language to use are going to agree
>with my definition,
Yes.
>and are not usually going to choose a language with wrong syntax.
No. I have to choose and use wrong syntaxes all the time, because languages
with the right syntaxes aren't properly implemented and/or missing a few
occasionally-needed features, and my employer won't let me build a language
with a less-wrong syntax.
--
Norman Diamond dia...@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Permission is granted to feel this signature, but not to look at it.
Richard Harter
> Richard Harter:
> Can someone cite some examples where data=program is essential.
> The canonical examples are:
> (1) creation of development tools (e.g. debuggers, optimizers,
> archival systems).
> (2) symbolic math packages.
> I'm not sure if these show that data=program is essential, but then
> data and control flow are just two aspects of the same thing.
No doubt it's my fault for not being clear. What I was really after
was not just operating on programs as data, but also executing the data.
One can lay out a general schema of programs which look like this:
We have a data hierarchy which runs raw text, lexemes, expressions,
statements, blocks, procedures, and programs. We have the ability to
generate a lower level from a higher level. We have a goal driven
program which transforms a suite of entities at one level to an
equivalent suite of entities satisfying the predefined goals.
I think this schema covers most of the examples cited. But all this
amounts to is that programs which operate on the source for other
programs should have good facilities for representing and manipulating
the structural content of the target programs.
> I think the best argument for a language which can manipulate its own
> code is Von Neumann's: you can develop faster if you can use the
> machine to manipulate your code. Another argument is robustness of
> data structures: such a language must have an adequate set of data
> structure primitives.
> Enough said?
Sorry, no. As I said, it's my fault for not making the question clearer.
Let me try again. Suppose I have a language L which has (a) data
structures suitable for representing programs written in L, and (b)
the capability of executing said data structures. Evidently I can
write tools -- debuggers, optimizers, code analyzers, preprocessors --
for L in L. Moreover the tools can operate in various test modes where
they execute and gather data on the processed L-programs. That's nice,
but frankly it's not too thrilling.
However I have the potential for something rather interesting, which
is to write programs that (re)write themselves during execution. It
is precisely this capability that was cited as a major feature of Lisp
in the old days. What I am looking for is examples where the ability
to dynamically execute dynamically generated code is essential.
Mark Friedman
Raul Rockwell (me):
Requiring a lambda expression to express an anonymous function
seems to me to be one of LISP's flaws, not one of its advantages.
Mark Friedman:
What's your alternative? You need some syntax to say that you want
a function that takes some number of arguments.
Well, you can say that an infix function takes one or two arguments.
Make one argument optional (with greedy binding) and ambiguity may be
resolved when the function is used. e.g. x-y vs. -y
Are you saying that you want `-y' to express the function:
(lambda (x) (- x y))
This is similar to a notion called currying in the funtional language
world, where all functions are functions of one argument. So the '-'
function might be expressed as:
(lambda (y) (lambda (x) (- x y)))
and `x-y' becomes ((- y) x). Your `-y' then becomes `(- y)'. It's a
nice concept and generalizes to n-argument functions reasonably well
(it is still hard to generalize it to arbitrary subsets of the n
arguments, i.e. you can specify the FIRST k arguments to the function
and get back a function of n-k arguments, but you can't supply ANY k
arguments).
Note that you still must specify a lambda expression (or equivalent)
for the original `-' function (although primitive functions may be
pre-defined). Just as I assume that you must somehow specify your
initial `-' function.
A less elegant solution might be to always require two arguments and
use BOTTOM a lot.
Me: Or, put another way, infix notation already has a clear scheme
for representing arguments, why not take advantage of it?
Mark Friedman:
I won't argue about the usefulness of infix notation, but what has
that to do with anonymous functions?
You can define anonymous functions using infix notation by either (a)
explicitly declaring dummy variables (similar to (lambda (x y) ...))
(b) using a pair of "standard names" for dummy variables, or (c)
tacitly defining functions without the use of any dummy variables
(just say what functions preprocess the arguments/postprocess the
results).
Well, (a) is the same as lambda and (c) seems even more complicated.
(b) might be acceptable, but what is the big advantage? You still have
to have some syntax for specifying that the thing is a function and
you've lost the ability to give meaningful names to the arguments.
I expect you'd want a good variety of data-structure building
functions for something like this (otherwise you could only work with
"toy" data). [And a good variety of meta-functions for leverage.]
I don't know what you mean here.
Or maybe I'm missing the point of the question??
Maybe I am too.
Khun Yee Fung
[stuff deleted]
Richard> However I have the potential for something rather interesting, which
Richard> is to write programs that (re)write themselves during execution. It
Richard> is precisely this capability that was cited as a major feature of Lisp
Richard> in the old days. What I am looking for is examples where the ability
Richard> to dynamically execute dynamically generated code is essential.
I did encounter one possible use recently.
I just finished designing a graphics algorithm. To be as general as
possible, I wrote a program generator for generating programs
implementaing the algorithm in 2D, 3D, and beyond. The size of the 2D
program is about 30k (just source). The size of the 3D is 1.2M. I did
not try the 4D version. You can see how practical the program is for
3D and beyond. However, the programs have pieces of duplicating code
for all symmetrical cases. For example, for the fifth case, the third
relational operation should be a ">". For the 31st, it should be "<",
etc. These duplicating pieces of code are about 90% of the whole
program. After these cases are collapsed, the size is rather
acceptable for 3D, 4D, and I guess, many D's. As we are trying to
achieve the ultimate efficiency for the function, we want to avoid
loops, and arrays. We want to avoid any arithmetic operations and
comparisons as much as possible. The algorithm is basically a hardware
algorithm, but software versions are useful too. So, what is the best
method I could think of? Well, use a template for the duplicating
pieces of code, determine the case, and then substitute the correct
operations in correct places in execution time. And then execute the
template with the operations filled in.
This is not as general as what you said, but it is self-modifying code
nonetheless.
So, how useful is programs as data? My standard answer is that one can
always find a place where a programming technique is useful. I work
on low level graphics algorithms where one cycle saved for an
algorithm could be thousands and millions of cycles saved for a
typical application using it. That is why I don't mind writing
programs with Goto's, and self-modifying codes. Hmmmm, is there a
compiled programming language that allows self-modifying code to be
written easily and properly?
Khun Yee
Darren New
>is to write programs that (re)write themselves during execution. It
>is precisely this capability that was cited as a major feature of Lisp
>in the old days. What I am looking for is examples where the ability
>to dynamically execute dynamically generated code is essential.
Well, most any language which is also an environment (Smalltalk, FORTH,
maybe APL) all fall under this category. The fact that the development
tools are part of the environment, i.e., the same address space, is
part of the advantage. In Smalltalk, when you find a bug, you can edit
the code and then restart the buggy procedure *from where it
encountered the bug*! This is tremendously helpful during prototyping.
Hermes is strongly, strictly, statically typed, perhaps moreso than any
other algorithmic language. The ability to pick up (say) a sort routine
from a library, modify the innards to sort (say) matricies instead of
integers, and then execute it is important because of the typing.
FORTH allows the addition of new syntactic constructs. Imagine removing
from your favorite algorithmic language all traces of character
strings. Now go put them back in as procedures, *including string
literals*. I can't imagine how this could be done without dynamically
generated code being executed.
One Transaction Processing system I've seen was written in (shudder :-)
APL because it was possible *for the individual clerks* to add new
queries to the TP system without bothering administrators and without
ever bringing down the TP system for other users. Again, dynamic code
creation and execution.
As far as I can tell, the kinds of code creation I've seen touted for
AI applications aren't really used in "real" systems. (Not that I've
seen many real systems.) I think the main advantage of LISP over other
languages for AI use is that it is possible to simply write
constants/literals of any data type you want. For example, if you are
parsing ATNs, and you want to parse English, you can write an ATN as a
LISP quoted literal and an interpreter for ATNs and you have a system.
In most other languages, you would need to write a procedure which
builds the data structure and passes the data structure and the English
sentence to the parser.
Industrial Poet
> In article <ZTL04...@mantis.co.uk> Industrial Poet writes:
> ]gud...@cs.arizona.edu (David Gudeman) writes:
> ]> Two answers: (1) there is presumably some other advantage to oriented
> ]> programming that gives incentive to go through the discomfort -- the
> ]> same does not apply to lisp syntax.
> ]That's your opinion. A lot of people see great advantages in the syntactic
> ]flexibility and simplicity of Lisp.
>
> A lot of people don't.
Right. So it's opinion, as I said. If you wish to assert something, go
ahead and provide some evidence.
> ]> ]1. It's simple. You can summarize all the syntax you need to know on the
> ]> ] back of a postcard.
> ]>
> ]> Not true. You have to specify the special syntax of defun, let,
> ]> protect-unwind, do (which is worse than anything I have ever seen in
> ]> an algol-like language), etc.
> ]
> ]Sorry? What "special syntax" are you referring to here with your examples?
> ]I'm not entirely sure I understand what you mean by a "special" syntax as
> ]opposed to the standard one.
>
> The do loop is part of the standard sytax. It is a very complex
> structure, and cannot be described on a postcard even by itself, even
> along with the rest of the syntax.
The *semantics* of the do loop can't be described in a small space, no. I
wasn't talking about the *semantics*. I said the *syntax* was easily
specified on the back of a postcard.
> The syntax of lisp special forms
> is just as complicated as control structures in any other language.
> The only difference is that in lisp these control structures are
> forced to look like function calls (which makes them harder to
> recognize).
You're shoe-horning Lisp into a conceptual model it doesn't fit. Lisp
doesn't have special form control structures. It has functions, atoms, and
lists. And that's about it.
The for and while loops in Lisp *really* *are* functions. They're not
"control structures... forced to look like function calls". They look like
functions because that's what they are.
> ]> You have to specify what operators take
> ]> more than the normal number of parameters.
> ]
> ]You're applying a concept which doesn't fit the language. Lisp functions
> ]like + and cond don't have a "normal number of parameters". (+ 2 3 5) isn't
> ]a special version of + with an abnormal number of parameters; it's the same
> ]which you find in (+ 2 3).
>
> First, cond isn't a function it is a special form (called a control
> structure in other languages).
What do you mean "cond isn't a function"? It is a piece of code which takes
a number of arguments, evaluates them, and returns a value. What peculiar
definition of "function" are you using here?
The fact that 'cond' happens to do the same sorts of things as some sort of
special form in some other language doesn't mean it isn't a function.
> (In fact when I
> taught lisp, I found one of the most confusing things to my students
> was trying to distinguish between functions and special forms.)
Sorry, but if you tried to teach the two as being different then you really
shouldn't have been teaching Lisp.
> Second, (+ 2 3 5) certainly _is_ a special version of + with an
> abnormal number of parameters.
Only in your conceptual model. The Lisp code called for + is the same for
(+ 2 3) as for (+ 2 3 5) [except if you compile and optimize, of course.]
> + is taken from mathematics where it
> almost always has just two arguments.
That's a syntactic convention used in algebra, and adopted by Common Lisp
because it is familiar to people. Lisp addition is more like $\sum$.
Cambridge Lisp uses 'plus' rather than '+', because '+' is really an infix
symbol.
mathew
Mike (My Watch Has Windows) Meyer
Another unsubstantiated claim. Oh, and by the way, obsfucated code
can be written in any language. The formatting (as opposed to syntax)
has much to do with how easily "your eyes" can see structure. That
factor would have to be accounted for as well.
This, of course, is the bottom line. Compared to the formatting, the
syntax has little to do with how "readable" the language is. You can
format C to with LISP-like formatting, or format LISP with C-like
formatting. Both formats will look odd to the people used to reading
the other format, but are liable to be easier to read for the people
used to that format.
Now, that LISP expressions tend to be multi-line, nested function
invocations may create problems. If what normally gets tucked inside
of a C control structure were written as a single expression, C might
be a lot uglier. But this is more a problem with the style of
programming used, rather than the syntax.
<mike
--
All around my hat, I will wear the green willow. Mike Meyer
And all around my hat, for a twelve-month and a day. m...@pa.dec.com
And if anyone should ask me, the reason why I'm wearing it, decwrl!mwm
It's all for my true love, who's far far away.
David Gudeman
]gud...@cs.arizona.edu (David Gudeman) writes:
]
]ahead and provide some evidence.
These meta-arguments are getting really tiresome.
]The *semantics* of the do loop can't be described in a small space, no. I
]wasn't talking about the *semantics*. I said the *syntax* was easily
]specified on the back of a postcard.
Only if you define "syntax" so narrowly that it is a worthless concept
and no one needs to see it defined anyway.
]You're shoe-horning Lisp into a conceptual model it doesn't fit. Lisp
]doesn't have special form control structures...
The term "special form" is a technical term invented specifically by
lisp designers and programmers to discuss lisp. Other languages use
"control structure" which means more or less the same thing. I've
never heard of a "special form control structure" before.
]... It has functions, atoms, and lists. And that's about it
Modern Lisp's have functions, atoms, dotted pairs (from which lists
are constructed), special forms, macros, property lists, arrays, hash
tables, machine integers, arbitrary-precision integers, machine
floats, arbitrary precision floats, a restricted form of continuation,
static environments, fluid environments and many other things. The
days of Lisp 1.5 are long gone (though even Lisp 1.5 had special
forms).
]The for and while loops in Lisp *really* *are* functions. They're not
]"control structures... forced to look like function calls". They look like
]functions because that's what they are.
They are not functions. In Lisp, all of the arguments of a function
are evaluated before the function is called. In special forms, the
evaluation of the arguments depends on the special form. This is an
important distinction in special forms such as
(let ((x 1)) ...)
which declares x as a local variable before evaluating "...". If 'let
were a function, this would cause an error message like "(x 1) is not
a function or special form". You cannot define 'let with lambda. Not
only does this effect what is treated as an evaluable expression but
there is also the matter of when side-effects take place. Note that
thants to the "simple" and "general" syntax, not all expressions of
the form '(f x) are evaluable expressions. That is, it is not always
the case that when you see '(f x) you can assume that 'f is a function
or special form and that 'x is a parameter. In the example of 'let
above, in '(x 1), 'x is a new variable name and 1 is the value to be
assigned to it.
]What do you mean "cond isn't a function"? It is a piece of code which takes
]a number of arguments, evaluates them, and returns a value. What peculiar
]definition of "function" are you using here?
I'm using the definition of "function" that is used in the lisp
community. It is not all that peculiar, but it is slightly different
from common mathematical definitions. But the common mathematical
definitions can't really be applied to a language with side-effects
anyway.
]Sorry, but if you tried to teach the two as being different then you really
]shouldn't have been teaching Lisp.
Thanks for your concern, but I think my students were helped slightly
by being told how evaluation works. Actually, they didn't have
trouble with the evaluation mechanisms, they had trouble remembering
how some things worked so differently from functions even though they
looked exactly the same. I had never had this problem, but seeing it
in others made me realize what dumb a syntactic convention that is.
]> Second, (+ 2 3 5) certainly _is_ a special version of + with an
]> abnormal number of parameters.
]
]Only in your conceptual model. The Lisp code called for + is the same for
](+ 2 3) as for (+ 2 3 5) [except if you compile and optimize, of course.]
OK, if you use the "Lisp conceptual model" then you don't have to be
told how '+ works. I'll just change my comment to "Lisp makes you
learn a different conceptual model for arithmetic." I think
"conceptual model" is a little presumptuous a term for something so
trivial though. The fact is that a person learning lisp has to learn
what operations take what number of operations and what it does with
them. A person learning Pascal just has to learn that Pascal
expressions have addition.
]
]> + is taken from mathematics where it
]> almost always has just two arguments.
]
]That's a syntactic convention used in algebra, and adopted by Common Lisp
]because it is familiar to people. Lisp addition is more like $\sum$.
]Cambridge Lisp uses 'plus' rather than '+', because '+' is really an infix
]symbol.
Plus is a special case. How do you describe '- with multiple
arguments? You have to say that the special syntax of Lisp allows you
to specify multiple parameters to the '- operation, and what it means
when you do so (whether an error or some arbitrarily defined result).
In Pascal it is impossible to give '- too many arguments.
Actually, I'm not saying this is a big disadvantage. It is actually
pretty trivial. Just as trivial as the disadvantage of having to
specify precedence in languages with infix syntax. Neither one should
be brought up in a serious discussion, and I only brought this up as a
counter to the silly precedence thing.
Right now, I'm sorry I argued about either one of these trivialities.
Lars P. Fischer
Rich> It's possible that the Magical Power of Lisp-like-languages
Rich> outweighs the disadvantages of folding every syntactic construct
Rich> onto the pattern f(a b c).
It's strange how certain things earn the reputation of being
impossible to understand. Somehow lots of people have come to believe
that DOS is so much more user friendly than UNIX ("del" is easy, "rm"
is obscure). Likewise, LISP has earned this reputation of being hard
to read. ( (print-index entries start-page number-of-columns) is hard,
print_index (entries, start_page, number_of_columns) is easy).
The fact that LISP has a uniform representation makes some things very
easy to read, since the structure is immediately seen. The dangling
else problem comes to mind.
/Lars
--
Lars Fischer, fis...@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Univ. of Aalborg, DENMARK. | these things. -- Calvin
Stephen E. Witham
> > x = quote {
> > function ( a, b ) {
> > return a+b;
> > }
> > };
> >
> > (That's not a lambda expression, it's a quoted lambda expression.)
> Why such a complicated expression? Why not just
> x =: +
> Requiring a lambda expression to express an anonymous function seems
> to me to be one of LISP's flaws, not one of its advantages.
I was giving a complicated example of using code as data. Equivalent to
(' (lambda (a b) (+ a b))). x := + isn't using code as data. That's
just assigning a function to a variable. Also the syntax is iffy.
x := '+' would quote it, but it doesn't make the point that you can
quote arbitrary code chunks...so I did something complicated.
--Steve
Stephen E. Witham
> In article <6...@smds.UUCP> s...@smds.UUCP (Stephen E. Witham) writes:
> > ...I do most of my code reading on a terminal in an emacs buffer so that
> > I can use all the commands when needed. I very rarely print out Scheme
> > code and look at it on paper.
> This sounds like a REAL INTERESTING point. Do you mean you use the
> editor to step between arguments and to find matching parens? If so,
> you're FEELING your way, or maybe more like WALKING, around the code...
> I think you are taking my point slightly incorrectly. Suppose you are
> programming in language X, and have a big huge function (several
> pages, full of nested loops etc.).
Are you suggesting I write functions that are longer than a screen!? How
dare you! :-) Actually, I avoid that at all costs and I was assuming
that we were comparing to Scheme programmers as wise as myself :-)
> I do not consider myself "feeling my way". I have a good tool
> and I use it.
You're missing MY point. I was praising your use of what I think is
a partly kinesthetic way of understanding your code.
--Steve
Stephen E. Witham
> In message <6...@smds.UUCP>, s...@smds.UUCP (Stephen E. Witham) writes:
> +To an intellectual populist like myself, something that is inaccessible
> +to large numbers of people for insufficient reason is WRONG.
> Then any computer programming language is WRONG.
Well, you may have a point there. I'm willing to be understanding about
what's a "sufficient reason" for inaccessibility--like, not everyone can
relate to the idea of programming yet, or, we haven't figured out how to
make it that easy yet...
> Your definition is
> useless. The dictionary definition even more so.
I'm sorry, what definition?
> There is almost nothing you can do unconsciously without first having
> been trained. All you are saying is that there has been sufficient
> training/experience with other languages for internalization to have
> occurred.
I'm saying that certain kinds of language are easier on the human brain
than others, and that NO amount of training can compensate.
Unsubstantiated claim.
> +#1 is that you're talking about consciously learning
> +the rules and consciously parsing things. But Lisp syntax doesn't
> +transfer easily to the unconscious.
> Another unsubstantiated claim.
Yup.
> +#2 is that what other languages do with syntax, lisp does with special
> +keywords...
This hardly needs substantiation.
> + ...And still your eyes can't learn it very well.
> Another unsubstantiated claim...
Yup.
> ...The formatting (as opposed to syntax)
> has much to do with how easily "your eyes" can see structure. That
> factor would have to be accounted for as well.
Yes. But I was thinking of well-written, nicely formated examples of
Scheme vs. C. Well-formated Scheme still looks like piles of
marshmallows to my eyes. (Okay, I exaggerate.)
> +I still think syntax is what puts off most of the people who are put off.
> We are still stuck at unsupported assertions.
Yup.
> +x = quote {
> + function ( a, b ) {
> + return a+b;
> + }
> + };
> Ok, so that looks like something a Algol-ic would "understand" "easily."
Seems easy enough to me...
> The real question is to show how a program would have written it. What
> can the program do with 'x' and how. There are no "built-in" data structres
> in a language like (say C, or pascal) for representing that. You'd have
> to add one in. Now you aren't talking the same language.
Definitely! I was talking about Scheme with C-style syntax.
Scheme has cons, car, cdr, etc., for manipulating lists. That's what
you'd use. In Scheme, of course, it's more obvious what you get from
(cons '+ (cons 'x (cons 'y '()))). Of course, you could invent a function
called consinfix, as in (consinfix 'x '+ 'y).
But personally I prefer the use of lambda expressions to construct
functions, as opposed to manipulating code. Anyway, as far as I know,
code that creates or manipulates code is hairy-looking in any language.
> ...I suspect, but am willing
> to investigate further, that doing so would alter the language in a
> non-trivial way.
--Steve
Lars P. Fischer
Larry> [...] but I'll keep doing my thing...
We sure hope so !!!
Lars P. Fischer
Stephen> When you write a program, you transform your ideas into a
Stephen> form that the computer can use. In some languages, the
Stephen> transformation scrambles the evidence of the original
Stephen> thinking process. In other languages, it's better preserved,
Stephen> so that you can go back and pick up where you left off.
I don't think so. When you write a program, you are trying to grasp a
subject matter and write down your how your understanding makes it
possible to provide solutions to problems (specific or general).
("To program is to understand" -- Kristen Nygaard).
The expressions of your understanding should be as well structured and
as simple to understand as possible. It should also make it possible
to derive a automatic procedure that is as efficient as possible (or
as deemed necessary).
I find that I often think more about a human reader than the compiler.
This often leads to much better code. Try reading Knuth's paper on
Literate Programming. It is worth it. So is using WEB (for Pascal, C,
scheme, SML, ....)
Raul Rockwell
Requiring a lambda expression to express an anonymous function
seems to me to be one of LISP's flaws, not one of its advantages.
Mark Friedman:
What's your alternative? You need some syntax to say that you want
a function that takes some number of arguments.
Raul Rockwell:
Well, you can say that an infix function takes one or two arguments.
Make one argument optional (with greedy binding) and ambiguity may be
resolved when the function is used. e.g. x-y vs. -y
Mark Friedman:
Are you saying that you want `-y' to express the function:
(lambda (x) (- x y))
Ah.. no.. neither of the above were intended to be functions.
Translating to LISP: 'x-y' is (- x y) and '-y' is (- y).
Mark Friedman:
... a notion called currying in the funtional language world, where
all functions are functions of one argument. So the '-' function
might be expressed as:
(lambda (y) (lambda (x) (- x y)))
and `x-y' becomes ((- y) x). Your `-y' then becomes `(- y)'. It's a
nice concept and generalizes to n-argument functions reasonably
well ...
I've played with an implementation of that idea. It was rather
painful, because while the concept generalizes to n-argument functions
it does not generalize nicely to an *arbitrary*-number-of-arguments
function. So, you could have a statement like
(((((f a) b) c) d) e)
And have all sorts of fun pondering whether 'f' really takes 5
arguments.
In my opinion, a function which takes an arbitrary number of arguments
is better expressed as a function which takes a single argument of
arbitrary length.
Mark Friedman:
Note that you still must specify a lambda expression (or
equivalent) for the original `-' function (although primitive
functions may be pre-defined). Just as I assume that you must
somehow specify your initial `-' function.
Primitive functions *must* be pre-defined, otherwise they're not
primitive. I like to think that this is a consequence of one of
Godel's incompleteness theorems.... If not that, it at least gives a
common point so we can talk about such things.
Raul Rockwell:
... infix notation already has a clear scheme for representing
arguments, why not take advantage of it?
Mark Friedman:
I won't argue about the usefulness of infix notation, but what
has that to do with anonymous functions?
Raul Rockwell:
You can define anonymous functions using infix notation by
either (a) explicitly declaring dummy variables (similar to
(lambda (x y) ...)) (b) using a pair of "standard names" for
dummy variables, or (c) tacitly defining functions without the
use of any dummy variables (just say what functions preprocess
the arguments/postprocess the results).
Well, (a) is the same as lambda and (c) seems even more
complicated. (b) might be acceptable, but what is the big
advantage? You still have to have some syntax for specifying that
the thing is a function and you've lost the ability to give
meaningful names to the arguments.
(a) is indeed the same as lambda
(b) is more concise, and allows a simpler syntax (just provide the
text of the function body to a meta-function which creates an
anonymous function). [[[ aside: presume a different syntax for
meta-functions (which can take functions as arguments, and which can
return functions or even meta-functions) than for functions. This
helps provide some stability to the syntax and (in my opinion) makes
it easier for a person [and maybe a compiler] to disambiguate between
some otherwise slippery simularities. ]]] [[[ yes, I'm assuming that
functions are somehow "typed" as such, and an object can not be used
as both without explicit conversion between one form and the other ]]]
(c) is simpler for a number of cases. Also note that for infix
notation, you can use the left_identity and right_identity functions
in place of variables.
Raul Rockwell:
I expect you'd want a good variety of data-structure building
functions for something like this (otherwise you could only work
with "toy" data). [And a good variety of meta-functions for
leverage.]
I don't know what you mean here.
I'm talking about an actual implementation of such a language...
Basically, "what I've said does not a complete specification make".
--
Raul <rock...@socrates.umd.edu>
Harley Davis
From: mat...@mantis.co.uk (Industrial Poet)
You're shoe-horning Lisp into a conceptual model it doesn't fit. Lisp
doesn't have special form control structures. It has functions, atoms, and
lists. And that's about it.
I don't know what Lisp you use, but in Scheme, CommonLisp, Le-Lisp,
EuLisp, and every other Lisp I know, forms such as COND, QUOTE,
LAMBDA, IF, and some others are not functions, but special forms, part
of the language syntax. It is absolutely true that they look like
function calls, but they are not, in any sense. Please read some
basic Lisp texts before spouting off.
The for and while loops in Lisp *really* *are* functions. They're not
"control structures... forced to look like function calls". They look like
functions because that's what they are.
No, they *really* *aren't* functions. You can't do (funcall #'cond
...). (functionp #'cond) returns (). They are not functions. Please
don't brag about your ignorance to the entire world; it does you no
honor.
> First, cond isn't a function it is a special form (called a control
> structure in other languages).
What do you mean "cond isn't a function"? It is a piece of code
which takes a number of arguments, evaluates them, and returns a
value. What peculiar definition of "function" are you using here?
COND does not evalutate its arguments. Look, when I write:
(cond ((symbolp x) (print "It's a symbol")))
The "argument" to COND is the list ((symbolp x) (print "It's a
symbol.")). Evaluating this list in any Lisp would be an error, since
its car is not a function. Therefore, COND does not evaluate its
arguments. It does destructure its arguments and evaluate part of
them sometimes, but that is hardly the same thing.
An even starker example is the special form QUOTE, whose sole purpose
is to *not* evaluate its argument.
> (In fact when I
> taught lisp, I found one of the most confusing things to my students
> was trying to distinguish between functions and special forms.)
Sorry, but if you tried to teach the two as being different then you really
shouldn't have been teaching Lisp.
You continue to embarrass yourself.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: da...@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
Richard Harter
> >>>>> On 1 Jul 91 03:36:01 GMT, r...@smds.UUCP (Richard Harter) said:
> Richard> to dynamically execute dynamically generated code is essential.
> I did encounter one possible use recently.
[... graphics example with multiplicity of cases ..]
> So, how useful is programs as data? My standard answer is that one can
> always find a place where a programming technique is useful. I work
> on low level graphics algorithms where one cycle saved for an
> algorithm could be thousands and millions of cycles saved for a
> typical application using it. That is why I don't mind writing
> programs with Goto's, and self-modifying codes. Hmmmm, is there a
> compiled programming language that allows self-modifying code to be
> written easily and properly?
Well, this is sort of thing is easily done in an interpreted language
with dynamic interpretation of symbols, e.g. in Lakota the fragment
{(operand) (arg1) (arg2)}
is a function call where the items in parentheses are replaced by their
contents. Thus
set-string operand +
set-string arg1 2
set-string arg2 3
print {(operand) (arg1) (arg2)}
will print 5. This really does what you want if it weren't for the
fact that there is (for your purposes) humumgous overhead concealed in
the interpreter. [Other languages mentioned here recently offer the
same capability.]
As you say, what you really need is for this capability to be compilable
directly without the overhead. To do this you need both an architecture
that lets you manipulate executables (no image/data splitting) and a
capability for altering machine instructions. Next best (and may be
fine for your purposes) is dynamic compilation with run time linking.
Doug Philips
gud...@cs.arizona.edu (David Gudeman) writes:
+People who choose which programming language to use are going to agree
+with my definition, and are not usually going to choose a language
+with wrong syntax.
We are just going to have to agree to disagree. In my view, wrong syntax
would be something like:
duplicate { body; } unless (condition);
with the semantics of the regular C:
while(condition) { body;}
wrong syntax is just that, wrong, not different. Is a hammer "WRONG" because
you can't use it to cut 2x4s? No.
+ Furthermore,
+there is no relationship between lisp syntax and the ability to treat
+program as data.
I don't think anyone ever claimed (or intended to claim) that lisp
syntax was the only way to treat programs as data (and visa versa).
+True enough. People who think there is no alternative to static
+typing irritate me even more than people who think lisp syntax is a
+non-issue.
Horrors! Something we can agree on! :-)
+ I reached my conclusions about X on my own, thank
+you, with evidence that is conclusive enough for my purposes. If you
+can show me counter-X evidence that is stronger than my X evidence, I
+will likely change my mind. This is not an emotional issue with me.
Your evidence is statistically insignificant, and as to your
purposes, well whatever they were for you, for me this has passed the
idle moments most amusingly. I might recommend you read "How We
Know What Isn't So", but I don't have it in front of me to cite the
author and ISBN.
+But the question "is lisp syntax a hindrance in getting people to except
+lisp?" is not a matter of opinion. The answer is clearly "yes".
No, it is not. You have not shown any statistically valid support
for that answer.
+ But on the other hand, they don't have the
+helpful semantic hooks to use when learning lisp that they would have
+had learning a language that looks more like math. So learning to
+program has been harder for them than it should have been, but they
+won't know that.
Interesting. How do you know (divine?) just how hard it is for
someone to have have done something they didn't do? Without real
data we are just arguing puffs of smoke. I find it equally plausible
that it is not harder and it is just your point of view that makes it
seem like it must be that way.
+People who already know a language with a more traditional syntax
+already know that it is possible to make languages look like math, and
+they will expect it. When these more experienced people don't get
+their little semantic hooks they _know_ that they are being subjected
+to unnecessary difficulty. That is the source of the negative
+reactions to lisp.
I have never (intended) to dispute that a programmer experienced in
more traditional syntax would find lisp/scheme very different and
therefore harder.
+A third possible factor is that lisp notation is actually, objectively
+harder for the human mind to grasp. I wouldn't want to claim this
+outright, but I rather suspect that it is true.
Good, your objectivity is far from being demonstrated.
+ What
+human languages don't have (as far as I know) is any pervasive feature
+that could be described as prefix-with-required-brackets.
Check out the alt.usage.english discussions about the lack of more
than one level of bracketing: bright red coke machine buttons. But,
I'll concede, that the need for brackets is not pervasive.
+]Since it is not confusing to beginners who have no preconceived
+]notions about programming languages,
+Looks like you are claiming "not X" there. What's your evidence?
I was agreeing, for sake of discussion, with your point.
+] _and_ (tie in from first
+]comment...) since it is something that people can become accustomed
+]to,
+If you mean "everyone" or even "most everyone" can become accustomed
+to it, then you are making another assertion without evidence. If you
+only mean "some people" then your following:
No, I am again acceding your point for sake of discussion.
+] THEN the real point is that rightness/wrongness is nothing
+]*inherent* about the syntax itself, but is merely a matter of the
+]habitual experience of people.
+doesn't follow.
Yes, it does, because I don't mean only "some people". You did not
have that qualifier initially, nor did I add it on in reference.
+Furthermore, _I_ already suggested that this difficulty is probably
+caused by experience. Your final sentence makes it sound like like I
+was arguing against that. My point (as I clearly stated it before) is
+that it doesn't matter why people have difficulty with lisp syntax,
+they do. And if their problems are just because they are not used to it
+then it is still a real problem. (And you haven't even proven that
+the problems can be overcome by everyone).
As you have so aptly pointed out, even when I agree with your
position it doesn't work (contains unproven assertions). You have
yet to show that there is in fact general difficulty with lisp
syntax. You have still to show that I should believe that lisp
syntax is a hinderance to learning/using lisp (or scheme). I can
just as well believe that programmers weaned on lisp would not have
that difficulty and would find the arbitrary and limiting syntax of a
conventional programs grating. I will not try to convince you to
take my position, because I have no evidence to offer. I am simply
(hopefully) stating that I have seen no reason to accept your view,
and that there are other views that can be as easily explained with
the same kind of evidence.
-Doug
---
Preferred: d...@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
Industrial Poet
> From: mat...@mantis.co.uk (Industrial Poet)
> You're shoe-horning Lisp into a conceptual model it doesn't fit. Lisp
> doesn't have special form control structures. It has functions, atoms, an
>
> I don't know what Lisp you use, but in Scheme, CommonLisp, Le-Lisp,
> EuLisp, and every other Lisp I know, forms such as COND, QUOTE,
> LAMBDA, IF, and some others are not functions, but special forms, part
> of the language syntax.
As I've posted in another response, I think we must be using different sorts
of Lisp.
The Lisp I use talks about functions which take evaluated arguments, and
functions which take unevaluated arguments. You seem to re-name the latter
as a "special form". Then someone comes along and moans because special
forms look like functions. Hardly a surprise!
> It is absolutely true that they look like
> function calls, but they are not, in any sense.
I don't see what you're getting at here. What's the fundamental difference
which leads you to say that they are not "in any sense" function calls? To
me they look like function calls with unevaluated arguments.
> Please read some
> basic Lisp texts before spouting off.
I have, trust me... Perhaps I've just not read the right ones.
> COND does not evalutate its arguments. Look, when I write:
>
> (cond ((symbolp x) (print "It's a symbol")))
>
> The "argument" to COND is the list ((symbolp x) (print "It's a
> symbol.")). Evaluating this list in any Lisp would be an error, since
> its car is not a function. Therefore, COND does not evaluate its
> arguments. It does destructure its arguments and evaluate part of
> them sometimes, but that is hardly the same thing.
Right. You are clearly using a more restricted definition of "function". I
wasn't aware of that.
Now that we've cleared that up, can I ask what the advantage is of treating
these two similar things (functions with evaluated arguments and functions
with unevaluated arguments) as being different? Why should a function have
to evaluate all its arguments? Doesn't that make "function" a synonym for
"function which is strict in all its arguments"?
> You continue to embarrass yourself.
Hardly. I'm just using a different conceptual model to you, but confusing
you by using the same words. :-)
I suppose this means it's time I got a proper Common LISP system and changed
conceptual models...
mathew
[ Or maybe I *am* terminally confused. ]
Khun Yee Fung
[An example using Lakota is deleted...]
I know how to do the self-modifying code in Perl too. The eval
operator is sufficient. As you say, the hidden overhead is too much.
Richard> As you say, what you really need is for this capability to be
Richard> compilable directly without the overhead. To do this you
Richard> need both an architecture that lets you manipulate
Richard> executables (no image/data splitting) and a capability for
Richard> altering machine instructions. Next best (and may be fine
Richard> for your purposes) is dynamic compilation with run time
Richard> linking.
I have thought about this for a while. I think the best place to do it
is on the level of microprogramming where the micro-language is really
an interpreted language. Dynamic compilation, run-time linking, and
other techniques are too expensive.
My graphics algorithm may well be a freak instance. Nevertheless, it
is an example where the programs as data technique is almost the only
way to preserve the efficiency of the algorithm and yet not use vast
amount of memory.
Khun Yee
Raul Rockwell
One can lay out a general schema of programs which look like this:
We have a data hierarchy which runs raw text, lexemes, expressions,
statements, blocks, procedures, and programs. We have the ability
to generate a lower level from a higher level. We have a goal
driven program which transforms a suite of entities at one level to
an equivalent suite of entities satisfying the predefined goals.
I think this schema covers most of the examples cited. But all
this amounts to is that programs which operate on the source for
other programs should have good facilities for representing and
manipulating the structural content of the target programs.
Well, yes... but a lot rests in the concept of "good facilities".
Essentially, "good" means time and space efficient -- and that what is
"good" for the programmer is "good" for the machine.
So if you want to be doing development work of any sort you want
"good" facilities for converting target programs to executable form
(and the ability to execute code fragments).
This may sound boring, but as far as I'm concerned, it's the heart of
all computer work.
Suppose I have a language L which has (a) data structures suitable
for representing programs written in L, and (b) the capability of
executing said data structures. Evidently I can write tools --
debuggers, optimizers, code analyzers, preprocessors -- for L in L.
Moreover the tools can operate in various test modes where they
execute and gather data on the processed L-programs. That's nice,
but frankly it's not too thrilling.
Well, what would be thrilling?
Essentially, on a computer, code is a form of data, and data is a form
of code. The more flexible one is, the more powerful the other is...
However I have the potential for something rather interesting,
which is to write programs that (re)write themselves during
execution. It is precisely this capability that was cited as a
major feature of Lisp in the old days. What I am looking for is
examples where the ability to dynamically execute dynamically
generated code is essential.
No such beast -- unless you realize that variable data with a constant
program is analogous to variable code (and data) on a constant
machine. I like to think of this as a consequence of the concept of
"Turing Equivalence".
--
Raul <rock...@socrates.umd.edu>
Raul Rockwell
> > x = quote {
> > function ( a, b ) {
> > return a+b;
> > }
> > };
Raul Rockwell:
> x =: +
Stephen E. Witham:
I was giving a complicated example of using code as data. Equivalent to
(' (lambda (a b) (+ a b))). x := + isn't using code as data. That's
just assigning a function to a variable. Also the syntax is iffy.
I don't see how the syntax is iffy. [Constrained, yes. Iffy, no.]
x := '+' would quote it, but it doesn't make the point that you can
quote arbitrary code chunks...so I did something complicated.
Well, there was my other example:
x =: + quoted
That seems to capture all the meaning of the "complicated" quoted
function. (I assume here that the word 'quoted' has meaning
sufficient to declare the preceding function as quoted.)
--
Raul <rock...@socrates.umd.edu>
Richard Harter
RH: However I have the potential for something rather interesting, which
RH: is to write programs that (re)write themselves during execution. It
RH: is precisely this capability that was cited as a major feature of Lisp
RH: in the old days. What I am looking for is examples where the ability
RH: to dynamically execute dynamically generated code is essential.
DN: Well, most any language which is also an environment (Smalltalk, FORTH,
DN: maybe APL) all fall under this category. The fact that the development
DN: tools are part of the environment, i.e., the same address space, is
DN: part of the advantage. In Smalltalk, when you find a bug, you can edit
DN: the code and then restart the buggy procedure *from where it
DN: encountered the bug*! This is tremendously helpful during prototyping.
I see that I still haven't made the point clear. In a suitable
interpretative environment I can do this sort of thing. One of the strong
points of Basic was that it was an interpreted environment and that you
could stop/edit/restart. [Do people still use Basic?] Very useful indeed.
However what I meant was code that that dynamically generated by the
executing program, which is quite different from code created "on the
fly" outside the program which the program can execute. To illustrate
the point, suppose that I have an OS and linker which permits dynamic
linking of object files. Here's what I can do in C** [C** is a product
of Vaporware Inc. which is *exponentially* better than C]: I can have
a program which reads data as an input, uses the data to drive a code
generator, compile the generated code, link in the compiled code, and
then use the routines in the compiled code to process the data. Does
this make sense? Yes it does, and something equivalent is done all the
time. What this amounts to is a multipass processor with intermediate
data representations. Instead of running generated/compiled code to
process the next pass one uses a table driven threaded code interpreter.
In this context "data" is a program, written in a special purpose
mini-language.
Now what all of this does is to effect a series of transformations to
an original data stream to produce a series of intermediate data streams.
In the ordinary multi-pass process the transformations themselves are
fixed, i.e. they are independent of the data.
However one can consider transformations which are are derived by
prior transformations. E.g. suppose we have data D, and transformation
T1. Then T1(D) produces data stream D1 and transformation T2. At
first sight it might seem that there is a generic transform T2' that
is fixed and that does the same thing as the produced T2. Our
reasoning would be that T2' would have, in effect, embedded in it the
knowledge of how T1 generates T2. However this doesn't follow because
the input to T2 is D1. Since there can be information loss from D to
D1, our hypothetical T2' cannot reconstruct T2 from <D1,T1>. In
particular, if the discarded information was used in the specification
of T2 we cannot reconstruct T2 from <D1,T1>. Whence if follows, if
I haven't overlooked a fine point, that dynamic generation of intermediate
transformations is stronger than the use of fixed transformations.
The implication is that programs which are capable of self-modification
(via the dynamic generation of code by the program) are more powerful
than static programs. However the actual use of self-modification is
very limited. The most common kind of usage is to handle initialization
sequences, e.g. the first pass through a procedure does sundry initialization
operations and then the procedure replaces itself with a steady state
version of the procedure.
So, with that *short* discussion out of the way, the question I am asking
is: What other kinds of usage of self-modification by a program are
there? In particular, are there examples, techniques, whatever that
are stronger (more interesting, whatever) than ordinary procedural
programming? [It won't shock me if no one comes up with an answer.]
DN: Hermes is strongly, strictly, statically typed, perhaps moreso than any
DN: other algorithmic language. The ability to pick up (say) a sort routine
DN: from a library, modify the innards to sort (say) matricies instead of
DN: integers, and then execute it is important because of the typing.
Again, this is a useful capability, but also in the "dynamic modification
by the user" category. There is an issue here which I regard as important.
Most compiled languages distinguish between subroutines and programs. The
effect of this is that you cannot independently execute subroutines as
though they were programs. E.g. if I have a sort subroutine I cannot
execute it from the command line. And, vice versa, I cannot call a
program from another program as though it were a subroutine. [Except
in COBOL where a "call" really is a program invocation.] What this
means is that at the environment is multi-layered. At the top level
(the visible environment) there are programs. In the internal
environments of the programs (which are not visible) there is a much
richer environment of subroutines. In an interpeted environment, e.g.
smalltalk, the whole environment is visible.
DN: FORTH allows the addition of new syntactic constructs. Imagine removing
DN: from your favorite algorithmic language all traces of character
DN: strings. Now go put them back in as procedures, *including string
DN: literals*. I can't imagine how this could be done without dynamically
DN: generated code being executed.
DN: One Transaction Processing system I've seen was written in (shudder :-)
DN: APL because it was possible *for the individual clerks* to add new
DN: queries to the TP system without bothering administrators and without
DN: ever bringing down the TP system for other users. Again, dynamic code
DN: creation and execution.
There are people who love APL. These instances illustrate a different
kind of capability. The FORTH example is really the ability to modify
the language dynamically, i.e. revise the syntax and the constructs of
the language within the language, aka as extensible languages. To be
frank, I have come to the conclusion that this sort of thing is a bad
idea in practice. It's nice for language experimentation; however
it amounts to every program being written in a private language.
DN: As far as I can tell, the kinds of code creation I've seen touted for
DN: AI applications aren't really used in "real" systems. (Not that I've
DN: seen many real systems.) I think the main advantage of LISP over other
DN: languages for AI use is that it is possible to simply write
DN: constants/literals of any data type you want. For example, if you are
DN: parsing ATNs, and you want to parse English, you can write an ATN as a
DN: LISP quoted literal and an interpreter for ATNs and you have a system.
DN: In most other languages, you would need to write a procedure which
DN: builds the data structure and passes the data structure and the English
DN: sentence to the parser.
I used to follow AI work fairly closely, but I haven't for the last fifteen
years. My impression is that very little progress has been been made in
the areas that used to be of interest. I.e. we have game playing programs,
expert systems, and pattern recognition programs, and the intellectual
technology in these areas has advanced. However if you look at the
Winograd block dialog program and ask where have we gone from there
in programs that understand natural language, it doesn't seem as though
much has been done. Similarly there doesn't seem to have been much that
has happened in the area of programs that create programs. [Data driven
code generators, yes, goal driven code generators, no.] It is just
those areas where the capability that I am talking about was used and
was cited as being essential.