[ThinLisp-commits] CVS: thinlisp-1.0/src/docs tl-manual.texinfo,1.15,1.16

[Jim A. <ja...@us...>]

Update of /cvsroot/thinlisp/thinlisp-1.0/src/docs
In directory sc8-pr-cvs1:/tmp/cvs-serv2714

Modified Files:
	tl-manual.texinfo 
Log Message:
Fixed some grammatical problems in the rant.


Index: tl-manual.texinfo
===================================================================
RCS file: /cvsroot/thinlisp/thinlisp-1.0/src/docs/tl-manual.texinfo,v
retrieving revision 1.15
retrieving revision 1.16
diff -C2 -r1.15 -r1.16
*** tl-manual.texinfo	13 Oct 2001 02:47:23 -0000	1.15
--- tl-manual.texinfo	1 Mar 2003 19:52:43 -0000	1.16
***************
*** 11,15 ****
  for real time applications and anything that shouldn't be fat and slow.
  
! Copyright (c) 1999-2001 The ThinLisp Group
  @end ifinfo
  
--- 11,15 ----
  for real time applications and anything that shouldn't be fat and slow.
  
! Copyright (c) 1999-2003 The ThinLisp Group
  @end ifinfo
  
***************
*** 25,29 ****
  @page
  @vskip 0pt plus 1filll
! Copyright @copyright{} 1999-2001 The ThinLisp Group
  @*Copyright @copyright{} 1995 Gensym Corporation.
  @*All rights reserved.
--- 25,29 ----
  @page
  @vskip 0pt plus 1filll
! Copyright @copyright{} 1999-2003 The ThinLisp Group
  @*Copyright @copyright{} 1995 Gensym Corporation.
  @*All rights reserved.
***************
*** 39,43 ****
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  
! For additional information see @url{http://www.thinlisp.org/}.
  
  @end titlepage
--- 39,43 ----
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  
! For additional information see @uref{http://www.thinlisp.org/}.
  
  @end titlepage
***************
*** 110,114 ****
  imposed by ThinLisp cannot by sped up by rewriting it in C.
  
! The ThinLisp home is @url{http://www.thinlisp.org/}.  The newest source
  distributions of TL and this manual can be found here.  Bugs should be
  reported to @email{bugs@@thinlisp.org}.
--- 110,114 ----
  imposed by ThinLisp cannot by sped up by rewriting it in C.
  
! The ThinLisp home is @uref{http://www.thinlisp.org/}.  The newest source
  distributions of TL and this manual can be found here.  Bugs should be
  reported to @email{bugs@@thinlisp.org}.
***************
*** 162,166 ****
  programmer's productivity in developing new functionality by enabling the purest
  form possible of coded solutions, and so to hide as many of the platform
! specific details as possible.  In the ongoing evolution of Lips, considerations
  of the efficiency of processing speed and memory use came in a distant second to
  programmer convenience and to the attempt to protect the programmer from bugs
--- 162,166 ----
  programmer's productivity in developing new functionality by enabling the purest
  form possible of coded solutions, and so to hide as many of the platform
! specific details as possible.  In the ongoing evolution of Lisp, considerations
  of the efficiency of processing speed and memory use came in a distant second to
  programmer convenience and to the attempt to protect the programmer from bugs
***************
*** 199,203 ****
  However, when it came to deploying these systems, things didn't turn out so
  smoothly.  Most software products of that era were coded in languages such as
! Fortran, Cobol, Pascal, C, and assembly language.  It turned out that Software
  developers who could breathe fire in Lisp were clumsy, inefficient, or flatly
  unwilling to port their systems to these traditional languages.
--- 199,203 ----
  However, when it came to deploying these systems, things didn't turn out so
  smoothly.  Most software products of that era were coded in languages such as
! Fortran, Cobol, Pascal, C, and assembly language.  It turned out that software
  developers who could breathe fire in Lisp were clumsy, inefficient, or flatly
  unwilling to port their systems to these traditional languages.
***************
*** 250,254 ****
  direct consequence of the performance problems caused by garbage collection this
  pilot project was closed out, and this particular deployment approach was
! dropped.  A different 
  
  The G2 system is a real-time supervisory level control system built by Gensym
--- 250,255 ----
  direct consequence of the performance problems caused by garbage collection this
  pilot project was closed out, and this particular deployment approach was
! dropped.  A different implementation containing some of Cooker's ideas
! eventually became the TDC Expert product.
  
  The G2 system is a real-time supervisory level control system built by Gensym
***************
*** 406,416 ****
  default choice for people building big systems.
  
! Lisp and other languages (such as CLU, Smalltalk, Eiffel, and recently Java)
! were are exemplars of the mathematical style, emphasizing denotational
! semantics.  The operations in these languages were defined with semantics that
! are deep (or fat if you prefer), focusing not on what an operation @emph{did}
! but on what it @emph{meant}.  Of course there had to be implementations of these
! operations, but the actual machine instructions carried out were allowed (even
! expected) to vary widely depending on the manner and situation in which it was
  used.
  
--- 407,417 ----
  default choice for people building big systems.
  
! Lisp and other languages (such as CLU, Smalltalk, Eiffel, and recently Java) are
! exemplars of the mathematical style, emphasizing denotational semantics.  The
! operations in these languages were defined with semantics that are deep (or fat
! if you prefer), focusing not on what an operation @emph{did} but on what it
! @emph{meant}.  Of course there had to be implementations of these operations,
! but the actual machine instructions carried out were allowed (even expected) to
! vary widely depending on the manner and situation in which the operation was
  used.
  
***************
*** 418,424 ****
  consequences of each style evoking surprise, disbelief, or even indignant
  disgust in ardent followers of the opposing camp.  Denotational fans can't
! believe how much of the underlying limitations of systems are exposed, and
! operational fans can't believe how disassociated operations are from the
! machine.  One sees too much exposed, and the other sees too much being hidden.
  
  @section GOTO Right Now, or GOTO When You're Ready
--- 419,426 ----
  consequences of each style evoking surprise, disbelief, or even indignant
  disgust in ardent followers of the opposing camp.  Denotational fans can't
! believe how much of the underlying limitations of systems are exposed in
! operational languages, and operational fans can't believe how disassociated
! operations are from the machine in denotational languages.  One sees too much
! exposed, and the other sees too much being hidden.
  
  @section GOTO Right Now, or GOTO When You're Ready
***************
*** 471,484 ****
  function, and the @code{(go bad)} form is contained within an embedded
  @code{lambda} form defining a different function, then the situation is very
! different.  Because goto tags have lexical scope, even across function
! boundaries, requires that the @code{go} be able to exit the function it is in
! and re-enter the outer function at the appropriate point.  In this case,
! entering the @code{tagbody} statement would require establishing a restart point
! similar to a @code{setjmp}, and the @code{go} would become something similar to
! a @code{longjmp}.  If the iteration contains an @code{unwind-protect}, then
! cleanup code will be executed after the @code{go} executes, but before the code
! at the @code{bad} statement.  If the @code{unwind-protect} clean-up forms
! contain a go to a further surrounding tagbody, then the code after the
! @code{bad} tag will never be executed.
  
  In this example, operational prorammers are floored by how complicated a simple
--- 473,486 ----
  function, and the @code{(go bad)} form is contained within an embedded
  @code{lambda} form defining a different function, then the situation is very
! different.  The fact that Lisp @code{go} tags have lexical scope, even across
! function boundaries, requires that the call to @code{go} be able to exit the
! function it is in and re-enter the outer function at the appropriate point.  In
! this case, entering the @code{tagbody} statement would require establishing a
! restart point similar to a @code{setjmp}, and the @code{go} would become
! something similar to a @code{longjmp}.  If the iteration contains an
! @code{unwind-protect}, then cleanup code will be executed after the @code{go}
! executes, but before the code at the @code{bad} statement.  If the
! @code{unwind-protect} clean-up forms contain a go to a further surrounding
! tagbody, then the code after the @code{bad} tag will never be executed.
  
  In this example, operational prorammers are floored by how complicated a simple
***************
*** 494,511 ****
  @section ThinLisp's Compromises
  
! While C++ and Java can be viewed as attempts to move C more towards a
! denotational footing, Thinlisp is an attempt to move Common Lisp more towards an
! operational footing.  I've attempted to lessen the impact of Lisp's "gotchas"
! that frustrate programmers who look at languages from an operational semantics
! point of view.  Attempting to allow the benefits of deep denotational semantics
! while warning of performance and behavior surprises is the underlying goal for
! ThinLisp.
! 
! One of the goals of ThinLisp is to implement the deep semantics of Lisp, while
! offering compile time warnings whenever these semantics force behavior that
! deviates from expectations consistent with operational (or "thin") semantics.
! If the programmer really intends to use the full, deep semantics, then a
! lexically apparent declaration can be used to suppress the warnings and accept
! the more expensive behavior required by the deep semantics.
  
  There are three main areas where ThinLisp warnings are used to help prevent
--- 496,512 ----
  @section ThinLisp's Compromises
  
! While C++ can be viewed as an attempt to move C more towards a denotational
! footing, Thinlisp is an attempt to move Common Lisp more towards an operational
! footing.  I've attempted to lessen the impact of Lisp's "gotchas" that frustrate
! programmers who look at languages from an operational semantics point of view.
! Attempting to allow the benefits of deep denotational semantics while warning of
! performance and behavior surprises is the underlying goal for ThinLisp.
! 
! In ThinLisp we've implemented the deep semantics of Lisp, while offering compile
! time warnings whenever these semantics force behavior that deviates from
! expectations consistent with operational (or "thin") semantics.  If the
! programmer really intends to use the full, deep semantics, then a lexically
! apparent declaration can be used to suppress the warnings and accept the more
! expensive behavior required by the deep semantics.
  
  There are three main areas where ThinLisp warnings are used to help prevent
***************
*** 616,629 ****
  @section Overview of Translations
  
! There are four different modes in which GL (Gensym Lisp, oops, er, Language)
! source code will need to be processed, two Lisp compilation modes and two
! translation modes.  The first is development compilation in an underlying Lisp
! environment.  The second is a macro definition compilation to define macros in
! preparation for a translation.  These are otherwise unremarkable uses of the
! underlying Lisp implementations compile-file and load functions, distinguished
! only by what we do with the :development and :distribution compiler switches.
! The third is a translation pre-process step in which the names and data types
! of variables and functions are determined.  The fourth and final is a
! translation mode in which C files and H files are generated.
  
  The translator from GL to C will be written to make as few dependencies as
--- 617,631 ----
  @section Overview of Translations
  
! There are four different modes in which GL (Gensym Lisp, oops, er, Language,
! oops, er ThinLisp) source code will need to be processed, two Lisp compilation
! modes and two translation modes.  The first is development compilation in an
! underlying Lisp environment.  The second is a macro definition compilation to
! define macros in preparation for a translation.  These are otherwise
! unremarkable uses of the underlying Lisp implementations compile-file and load
! functions, distinguished only by what we do with the :development and
! :distribution compiler switches.  The third is a translation pre-process step in
! which the names and data types of variables and functions are determined.  The
! fourth and final is a translation mode in which C files and H files are
! generated.
  
  The translator from GL to C will be written to make as few dependencies as