Recent changes to TODO

TODO modified by David A. Wheeler

David A. Wheeler — Fri, 30 Sep 2016 13:25:01 -0000

--- v35
+++ v36
@@ -1,13 +1,12 @@
 This is the general "to do" list.
-
-Version 1.0 requirements (current draft) - goal completion date mid-November 2013.  At this point, the main thing is to get all comments resolved on SRFI-110.

 Key things to do:

 1.  In-a-browser implementation of sweeten, unsweeten, and a sweet REPL.  If we can't do that, back off to server-side PHP and implement sweeten/unsweeten. See [Website].
-2.  Find a way to fix clisp REPL.
-3.  Good editor mode, at least for emacs.
-4.  Clean up website - especially front page http://readable.sourceforge.net - to make it look nicer.  See [Website].
+2.  Good editor mode, at least for emacs.
+3.  Clean up website - especially front page http://readable.sourceforge.net - to make it look nicer.  See [Website].
+4.  Add implementation for Racket; see: http://beautifulracket.com/appendix/master-recipe.html
+5.  Improve integration with guile.

 Other stuff:

TODO modified by David A. Wheeler

David A. Wheeler — Sun, 11 Aug 2013 22:37:05 -0000

--- v34
+++ v35
@@ -1,24 +1,21 @@
 This is the general "to do" list.

-Version 1.0 requirements (current draft) - goal completion date mid-November:
+Version 1.0 requirements (current draft) - goal completion date mid-November 2013.  At this point, the main thing is to get all comments resolved on SRFI-110.

-1.  More experience with syntax. At least two developers have to have developed code with it beyond a few short functions.  (David A. Wheeler is one, with sweeten.sscm; Alan Manuel Gloria is expected to be another).  More would be great.  Give this at least 3 months (August-October 2012).
-    * Alan Manuel Gloria: Done with [letterfall](http://github.com/AmkG/letterfall/)
-    * David A. Wheeler: sweeten.sscm
-2.  In-a-browser implementation of sweeten, unsweeten, and a sweet REPL.  If we can't do that, back off to server-side PHP and implement sweeten/unsweeten. See [Website].
-3.  Find a way to fix clisp REPL.
-4.  Good editor mode, at least for emacs.
-5.  Clean up website - especially front page http://readable.sourceforge.net - to make it look nicer.  See [Website].
+Key things to do:
+
+1.  In-a-browser implementation of sweeten, unsweeten, and a sweet REPL.  If we can't do that, back off to server-side PHP and implement sweeten/unsweeten. See [Website].
+2.  Find a way to fix clisp REPL.
+3.  Good editor mode, at least for emacs.
+4.  Clean up website - especially front page http://readable.sourceforge.net - to make it look nicer.  See [Website].

 Other stuff:

 *   Make sure [Analysis] uses the latest specs.
 *   Go through R6RS parser definition and make sure reader is consistent. E.G., upper-case #X should be accepted.
-*   Should unsweeten (and sweeten?) readers have options to read other Lisps, e.g., Arc, emacs Lisp, Common Lisp?  That would make it possible to do "unsweeten | arc" or such.
 *   Get it into guile's distribution (that's probably easier than creating packages for Ubuntu + Debian + Fedora + RHEL + ...)
     * Partially done: [SRFI-105 on guile](http://www.gnu.org/software/guile/manual/html_node/SRFI_002d105.html)
 *   Get it other Lisps: Arc, Clojure, ACL2, etc.
-*   Create SRFI
-    * Sweet-Expressions: ongoing, SRFI-110.

+

TODO modified by David A. Wheeler

David A. Wheeler — Sun, 11 Aug 2013 22:35:25 -0000

--- v33
+++ v34
@@ -5,23 +5,10 @@
 1.  More experience with syntax. At least two developers have to have developed code with it beyond a few short functions.  (David A. Wheeler is one, with sweeten.sscm; Alan Manuel Gloria is expected to be another).  More would be great.  Give this at least 3 months (August-October 2012).
     * Alan Manuel Gloria: Done with [letterfall](http://github.com/AmkG/letterfall/)
     * David A. Wheeler: sweeten.sscm
-2.  A video tutorial. (Wheeler to do)
-3.  In-a-browser implementation of sweeten, unsweeten, and a sweet REPL.  If we can't do that, back off to server-side PHP and implement sweeten/unsweeten. See [Website].
-4.  More test cases... and make sure we pass them :-). I want it to be *shocking* if a guile user finds an error in our reader.
-5.  Formal spec. We have two older "spec" files to use as a starting point.
-    * David A. Wheeler: on-going (January 2013)
-6.  Further clean-up of kernel code. Some complexity we can't avoid, but it should be as obvious as possible that it's *right*. I'd like for it to match the formal spec as much as makes sense (e.g., key functions and key formal spec productions should match), again, so that we can increase confidence that our implementation is correct. Also, I want it to be maximally portable, not only between Schemes, but make it easier to port to non-Schemes by limiting functionality that's really Scheme-specific.  E.G., limit named "let" and call/cc use so that they are easily translated, by hand or by tools such as [scm2cl](http://www.ccs.neu.edu/home/dorai/scmxlate/scm2cl.html)
-    * Awaiting formal spec.; current plan (January 2013) is that kernel code will be rewritten based on new formal spec.
-7.  Fix bugs wherever they're identified.
-8.  Improve docs.
-9.  Post some hall-of-shame examples of existing (UGLY!) s-expressions, and what they look like when rewritten as sweet-expressions.
-    * Isn't [Analysis] already this?  Admittedly, needs updates for latest developments (this is before SPLICE was finalized), and fix some bugs.
-10. Clean up website - especially front page http://readable.sourceforge.net - to make it look nicer.  See [Website].
-11.  New commands to:
-    -   Verify that a given file would be interpreted the same way with either the sweet-reader or traditional reader (to enable transition - if any files come with guile that are interpreted differently, we want to know and maybe fix the guile file or our reader)
-    -   Verify that a given file1 written with sweet-expressions semantically matches a file2 written with traditional s-expressions (to enable transition and hall-of-shame)
-
-
+2.  In-a-browser implementation of sweeten, unsweeten, and a sweet REPL.  If we can't do that, back off to server-side PHP and implement sweeten/unsweeten. See [Website].
+3.  Find a way to fix clisp REPL.
+4.  Good editor mode, at least for emacs.
+5.  Clean up website - especially front page http://readable.sourceforge.net - to make it look nicer.  See [Website].

 Other stuff:

@@ -30,9 +17,8 @@
 *   Should unsweeten (and sweeten?) readers have options to read other Lisps, e.g., Arc, emacs Lisp, Common Lisp?  That would make it possible to do "unsweeten | arc" or such.
 *   Get it into guile's distribution (that's probably easier than creating packages for Ubuntu + Debian + Fedora + RHEL + ...)
     * Partially done: [SRFI-105 on guile](http://www.gnu.org/software/guile/manual/html_node/SRFI_002d105.html)
-*   Create a Common Lisp ASDF package, make that easy to download/install, try to get it included in many Common Lisps
 *   Get it other Lisps: Arc, Clojure, ACL2, etc.
 *   Create SRFI
-    * Curly Infix: [SRFI-105](http://srfi.schemers.org/srfi-105/srfi-105.html)
-    * Sweet-Expressions: on-going (January 2013)
+    * Sweet-Expressions: ongoing, SRFI-110.

+

WikiPage TODO modified by Alan Manuel Gloria

Alan Manuel Gloria — Thu, 17 Jan 2013 03:38:51 -0000

--- v32
+++ v33
@@ -3,14 +3,19 @@
 Version 1.0 requirements (current draft) - goal completion date mid-November:

 1.  More experience with syntax. At least two developers have to have developed code with it beyond a few short functions.  (David A. Wheeler is one, with sweeten.sscm; Alan Manuel Gloria is expected to be another).  More would be great.  Give this at least 3 months (August-October 2012).
+    * Alan Manuel Gloria: Done with [letterfall](http://github.com/AmkG/letterfall/)
+    * David A. Wheeler: sweeten.sscm
 2.  A video tutorial. (Wheeler to do)
 3.  In-a-browser implementation of sweeten, unsweeten, and a sweet REPL.  If we can't do that, back off to server-side PHP and implement sweeten/unsweeten. See [Website].
 4.  More test cases... and make sure we pass them :-). I want it to be *shocking* if a guile user finds an error in our reader.
 5.  Formal spec. We have two older "spec" files to use as a starting point.
+    * David A. Wheeler: on-going (January 2013)
 6.  Further clean-up of kernel code. Some complexity we can't avoid, but it should be as obvious as possible that it's *right*. I'd like for it to match the formal spec as much as makes sense (e.g., key functions and key formal spec productions should match), again, so that we can increase confidence that our implementation is correct. Also, I want it to be maximally portable, not only between Schemes, but make it easier to port to non-Schemes by limiting functionality that's really Scheme-specific.  E.G., limit named "let" and call/cc use so that they are easily translated, by hand or by tools such as [scm2cl](http://www.ccs.neu.edu/home/dorai/scmxlate/scm2cl.html)
+    * Awaiting formal spec.; current plan (January 2013) is that kernel code will be rewritten based on new formal spec.
 7.  Fix bugs wherever they're identified.
 8.  Improve docs.
 9.  Post some hall-of-shame examples of existing (UGLY!) s-expressions, and what they look like when rewritten as sweet-expressions.
+    * Isn't [Analysis] already this?  Admittedly, needs updates for latest developments (this is before SPLICE was finalized), and fix some bugs.
 10. Clean up website - especially front page http://readable.sourceforge.net - to make it look nicer.  See [Website].
 11.  New commands to:
     -   Verify that a given file would be interpreted the same way with either the sweet-reader or traditional reader (to enable transition - if any files come with guile that are interpreted differently, we want to know and maybe fix the guile file or our reader)
@@ -24,7 +29,10 @@
 *   Go through R6RS parser definition and make sure reader is consistent. E.G., upper-case #X should be accepted.
 *   Should unsweeten (and sweeten?) readers have options to read other Lisps, e.g., Arc, emacs Lisp, Common Lisp?  That would make it possible to do "unsweeten | arc" or such.
 *   Get it into guile's distribution (that's probably easier than creating packages for Ubuntu + Debian + Fedora + RHEL + ...)
+    * Partially done: [SRFI-105 on guile](http://www.gnu.org/software/guile/manual/html_node/SRFI_002d105.html)
 *   Create a Common Lisp ASDF package, make that easy to download/install, try to get it included in many Common Lisps
 *   Get it other Lisps: Arc, Clojure, ACL2, etc.
 *   Create SRFI
+    * Curly Infix: [SRFI-105](http://srfi.schemers.org/srfi-105/srfi-105.html)
+    * Sweet-Expressions: on-going (January 2013)

WikiPage TODO modified by David A. Wheeler

David A. Wheeler — Mon, 06 Aug 2012 10:28:21 -0000

--- v31
+++ v32
@@ -21,8 +21,8 @@
 Other stuff:
 
 *   Make sure [Analysis] uses the latest specs.
-    * (almkglor): I've at least replaced most references to group with \\\\
 *   Go through R6RS parser definition and make sure reader is consistent. E.G., upper-case #X should be accepted.
+*   Should unsweeten (and sweeten?) readers have options to read other Lisps, e.g., Arc, emacs Lisp, Common Lisp?  That would make it possible to do "unsweeten | arc" or such.
 *   Get it into guile's distribution (that's probably easier than creating packages for Ubuntu + Debian + Fedora + RHEL + ...)
 *   Create a Common Lisp ASDF package, make that easy to download/install, try to get it included in many Common Lisps
 *   Get it other Lisps: Arc, Clojure, ACL2, etc.

WikiPage TODO modified by David A. Wheeler

David A. Wheeler — Mon, 06 Aug 2012 10:26:30 -0000

--- v30
+++ v31
@@ -20,22 +20,6 @@
 
 Other stuff:
 
-*   Update [Rationale].
-    *   I (almkglor) suggest factoring out the "Goals" section to a new page.  At the end (after all the rationale) add a section that refers to that page and sees how well the goals are met.
-    *   (dwheeler): Why separate it?  My intent was to make the page all-in-one, since fewer people will want all that (they'll just want to know how to use it).  The "how well met" is a good idea, though.
-    *  (almkglor): Because people might be interested in learning the goals of the project, without yet committing to read a really long "Rationale" article.  The sheer size of the "Rationale" article might dissuade users from reading the goals.  The Goals section is also a few sections into Rationale - it is preceded by "Problems" and "Past work".  The user has probably already read the "Problems" page, and might not be so interested in history to read Past Work, so they might decide not to continue reading Rationale after seeing the first two sections do not interest them.  So: I think people would appreciate reading the goals, without it being buried inside "Rationale".
-    * (almkglor): Possibly reorganize the "More Information" section of [Home]:
-        * [Home] - about the Readable Lisp project
-            * [Problem] - more information on the problem we're trying to solve
-            * [Solution] - a more detailed description of our solution
-            * [Tutorial] - a tutorial on how to try it out
-            * [Style] - style guide for using them
-            * [Examples] - examples of code using these formats
-        * Philosophy behind the Readable Lisp project
-            * [Goals] - what we want to achieve in this project
-            * [Rationale] - why we chose what we did in our [Solution]
-            * [Retort] - a retort to the critics who claim that this can't be done
-            * [Analysis] - an analysis of our notations, trying them out in different Lisps
 *   Make sure [Analysis] uses the latest specs.
     * (almkglor): I've at least replaced most references to group with \\\\
 *   Go through R6RS parser definition and make sure reader is consistent. E.G., upper-case #X should be accepted.

WikiPage TODO modified by Alan Manuel Gloria

Alan Manuel Gloria — Mon, 06 Aug 2012 06:50:28 -0000

--- v29
+++ v30
@@ -25,7 +25,7 @@
     *   (dwheeler): Why separate it?  My intent was to make the page all-in-one, since fewer people will want all that (they'll just want to know how to use it).  The "how well met" is a good idea, though.
     *  (almkglor): Because people might be interested in learning the goals of the project, without yet committing to read a really long "Rationale" article.  The sheer size of the "Rationale" article might dissuade users from reading the goals.  The Goals section is also a few sections into Rationale - it is preceded by "Problems" and "Past work".  The user has probably already read the "Problems" page, and might not be so interested in history to read Past Work, so they might decide not to continue reading Rationale after seeing the first two sections do not interest them.  So: I think people would appreciate reading the goals, without it being buried inside "Rationale".
     * (almkglor): Possibly reorganize the "More Information" section of [Home]:
-        * [Main] - about the Readable Lisp project
+        * [Home] - about the Readable Lisp project
             * [Problem] - more information on the problem we're trying to solve
             * [Solution] - a more detailed description of our solution
             * [Tutorial] - a tutorial on how to try it out

WikiPage TODO modified by Alan Manuel Gloria

Alan Manuel Gloria — Mon, 06 Aug 2012 06:49:59 -0000

--- v28
+++ v29
@@ -24,6 +24,18 @@
     *   I (almkglor) suggest factoring out the "Goals" section to a new page.  At the end (after all the rationale) add a section that refers to that page and sees how well the goals are met.
     *   (dwheeler): Why separate it?  My intent was to make the page all-in-one, since fewer people will want all that (they'll just want to know how to use it).  The "how well met" is a good idea, though.
     *  (almkglor): Because people might be interested in learning the goals of the project, without yet committing to read a really long "Rationale" article.  The sheer size of the "Rationale" article might dissuade users from reading the goals.  The Goals section is also a few sections into Rationale - it is preceded by "Problems" and "Past work".  The user has probably already read the "Problems" page, and might not be so interested in history to read Past Work, so they might decide not to continue reading Rationale after seeing the first two sections do not interest them.  So: I think people would appreciate reading the goals, without it being buried inside "Rationale".
+    * (almkglor): Possibly reorganize the "More Information" section of [Home]:
+        * [Main] - about the Readable Lisp project
+            * [Problem] - more information on the problem we're trying to solve
+            * [Solution] - a more detailed description of our solution
+            * [Tutorial] - a tutorial on how to try it out
+            * [Style] - style guide for using them
+            * [Examples] - examples of code using these formats
+        * Philosophy behind the Readable Lisp project
+            * [Goals] - what we want to achieve in this project
+            * [Rationale] - why we chose what we did in our [Solution]
+            * [Retort] - a retort to the critics who claim that this can't be done
+            * [Analysis] - an analysis of our notations, trying them out in different Lisps
 *   Make sure [Analysis] uses the latest specs.
     * (almkglor): I've at least replaced most references to group with \\\\
 *   Go through R6RS parser definition and make sure reader is consistent. E.G., upper-case #X should be accepted.

WikiPage TODO modified by Alan Manuel Gloria

Alan Manuel Gloria — Mon, 06 Aug 2012 06:38:05 -0000

--- v27
+++ v28
@@ -25,6 +25,7 @@
     *   (dwheeler): Why separate it?  My intent was to make the page all-in-one, since fewer people will want all that (they'll just want to know how to use it).  The "how well met" is a good idea, though.
     *  (almkglor): Because people might be interested in learning the goals of the project, without yet committing to read a really long "Rationale" article.  The sheer size of the "Rationale" article might dissuade users from reading the goals.  The Goals section is also a few sections into Rationale - it is preceded by "Problems" and "Past work".  The user has probably already read the "Problems" page, and might not be so interested in history to read Past Work, so they might decide not to continue reading Rationale after seeing the first two sections do not interest them.  So: I think people would appreciate reading the goals, without it being buried inside "Rationale".
 *   Make sure [Analysis] uses the latest specs.
+    * (almkglor): I've at least replaced most references to group with \\\\
 *   Go through R6RS parser definition and make sure reader is consistent. E.G., upper-case #X should be accepted.
 *   Get it into guile's distribution (that's probably easier than creating packages for Ubuntu + Debian + Fedora + RHEL + ...)
 *   Create a Common Lisp ASDF package, make that easy to download/install, try to get it included in many Common Lisps

WikiPage TODO modified by Alan Manuel Gloria

Alan Manuel Gloria — Mon, 06 Aug 2012 06:36:55 -0000

--- v26
+++ v27
@@ -22,8 +22,9 @@
 
 *   Update [Rationale].
     *   I (almkglor) suggest factoring out the "Goals" section to a new page.  At the end (after all the rationale) add a section that refers to that page and sees how well the goals are met.
+    *   (dwheeler): Why separate it?  My intent was to make the page all-in-one, since fewer people will want all that (they'll just want to know how to use it).  The "how well met" is a good idea, though.
+    *  (almkglor): Because people might be interested in learning the goals of the project, without yet committing to read a really long "Rationale" article.  The sheer size of the "Rationale" article might dissuade users from reading the goals.  The Goals section is also a few sections into Rationale - it is preceded by "Problems" and "Past work".  The user has probably already read the "Problems" page, and might not be so interested in history to read Past Work, so they might decide not to continue reading Rationale after seeing the first two sections do not interest them.  So: I think people would appreciate reading the goals, without it being buried inside "Rationale".
 *   Make sure [Analysis] uses the latest specs.
-    *   (dwheeler): Why separate it?  My intent was to make the page all-in-one, since fewer people will want all that (they'll just want to know how to use it).  The "how well met" is a good idea, though.
 *   Go through R6RS parser definition and make sure reader is consistent. E.G., upper-case #X should be accepted.
 *   Get it into guile's distribution (that's probably easier than creating packages for Ubuntu + Debian + Fedora + RHEL + ...)
 *   Create a Common Lisp ASDF package, make that easy to download/install, try to get it included in many Common Lisps