Making changes

2 files changed, 29 insertions, 31 deletions

diff --git a/comal.lsp b/comal.lsp
index 12f8d0a..571d4a6 100644
--- a/comal.lsp
+++ b/comal.lsp
@@ -1,22 +1,14 @@
-#!/Users/dbane/openlisp-10.9.0/uxlisp -shell
-(defun error-handler (condition)
-   (cond
-         ((eq (class-of condition) (class <lexer-error>)) )))
+#!/home/snuc/openlisp-10.9.0/uxlisp -shell
 
-(defun one-command-h (st)
-   (let ((l parse (read-line)))
-        (case (car l)
-              ((line) (insert (cadr c)))
-              ((p-end) (throw 'end nil))))   ; ok? No condition stuff?
+;;; Not sure yet if it's a good idea or not,
+;;; but I'm trying to keep the number of top-level functions the same as in OCaml.
 
 (defun one-command (st)
    (with-handler #'error-handler
-      (one-command-h st)))
-
-;; Should this be in (for or something since it's called -loop?
-(defun main-loop (st)
-   (format (standard-output) "> ")
-   (catch 'error (one-command st)))
+      (let ((l parse (read-line)))
+           (case (car l)
+                 ((line) (insert (cadr c)))
+                 ((p-end) (throw 'end nil)))))) ; throw and conditions are orthogonal
 
 (defclass <state> () ((prog :accessor prog)
                       (env :accessor env)))
@@ -24,14 +16,11 @@
    (setf (prog self) nil)
    (setf (env self) nil))
 
-(defun main-h ()
-   (format (standard-output) "OpenCOMAL version 0.4~%~%")
-   (for ((st (create (class <state>))))
-        (main-loop st)))
-
-(defun bye ()
-   (format (standard-output) "See you later...~%"))
-
 (defun main ()
-   (catch 'end (main-h))
-   (bye))
+   (catch 'end (lambda ()
+                  (format (standard-output) "OpenCOMAL version 0.4~%~%")
+                  (for ((st (create (class <state>))))
+                       (())
+                       (format (standard-output) "> ")
+                       (catch 'error (one-command st)))))
+   (format (standard-output) "See you later...~%"))
diff --git a/doc/breaking_rules.md b/doc/breaking_rules.md
index a20bdac..7933efb 100644
--- a/doc/breaking_rules.md
+++ b/doc/breaking_rules.md
@@ -24,11 +24,6 @@ invalidated this.
 
 *TODO*: case study
 
-*Colophon*: this document tries to depend only on GFM,
-in the same spirit as the software.
-The use of tools like
-PP, PlantUML and Pandoc is postponed indefinitely.
-
 # Literature Review
 
 There is a long history of recommending prototyping as a way to construct
@@ -90,7 +85,9 @@ The following technology is recommended:
 * Emacs for the view layer
 * JSON-RPC for inter-process communication
 
-Even though this is a prototype, attention should be paid to basic craftsmanship:
+## Codinmg standards
+
+Even though this is a prototype, attention should be paid to basic craftsmanship.
 
 * Divide the system into packages, using at least the subset of CL that is
   supported by OpenLisp
@@ -142,6 +139,14 @@ Then, the following code & documentation improvements should be made:
 
 ## Documentation Details
 
+Depend only on GFM,
+in the same spirit as the software.
+The use of tools like
+PP and Pandoc is postponed indefinitely.
+PlantUML *should* be used where it can replace ad-hoc text.
+
+Documents should be stored under git in a "doc" subdirectory of the project.
+
 I think it is a good idea to keep the separation between library and UI code.
 And JSON-RPC is perfectly adequate for that.
 
@@ -172,6 +177,9 @@ The following can be added as sections to the README:
 And a proper software requirements spec should be written filling in any blanks that the man pages leave.  
 The specification of input and output variables is best left at the level of tables and Basic English again.
 
+For the UI *technology*, it's probably best to skip local GUIs altogether and go
+straight to ParenScript, Backbone, etc.
+
 ## Testing
 
 Unit (olunit) tests should be derived from the module interface specs.
@@ -180,6 +188,7 @@ System tests should be derived from the requirements spec.
 It's ok for system tests to use the JSON-RPC interface.
 All tests should be automated,
 except possibly for the UI/view layer.
+Q: These scripts could be generated from a literate test plan?
 
 Where there is scope to push some of the testing work "back" in the V model to contracts for the functions,
 this should be done instead.