Recent changes to Goals

Goals modified by David A. Wheeler

David A. Wheeler — Tue, 15 Oct 2013 00:03:51 -0000

--- v6
+++ v7
@@ -20,8 +20,6 @@

 For any syntax to be widely used, there must be trustworthy, widely-usable implementations.  Thus, adoption would be helped by having at least one FLOSS reference implementation with a generous license that permits use by proprietary programs and Free-libre / open source software (FLOSS) programs.  Any FLOSS software should be GPL-compatible, since there is so much GPL’ed code.  This reference implementations would need to be widely portable and modular, so that it can be widely used as a starting point.  Thus, we've worked to develop software under the MIT license; it meets those requirements, and it is the license the Scheme SRFI ("surfie") submissions use.

-We decided to start our focus on Scheme.  We had to start somewhere, Scheme is widely used, and Scheme is picky (e.g., it has distinct values for false and the empty list) so it's probably easier to port *from* it than *to* it.  In the end, specialized implementations well-tuned to different environment will be necessary for an improved syntax to really work.  Scheme and Common Lisp aren’t really compatible at all, in the sense that real code written for one won't run on the other.  Translators like scm2cl (Scheme to Common Lisp translator) could help initially, certainly to get started (suggesting that it'd be best to start with Scheme, and then transition at least an initial version to Common Lisp).  Also, in a pinch the "unsweeten" tool can be used as a front-end for other tools.  The "unsweeten" and related tools even have a mode that makes them useful for Common Lisps, and Lisps like Common Lisp, in many circumstances.
-
-Since the time we started this, we have developed a Common Lisp implementation as well.
+We have implemented this approach for both Scheme and Common Lisp, since those are both widely-used Lisp-based systems.

 You might be interested in reviewing our [Solution], or in seeing our [Rationale].

Goals modified by David A. Wheeler

David A. Wheeler — Tue, 15 Oct 2013 00:01:23 -0000

--- v5
+++ v6
@@ -9,7 +9,7 @@
     *   *Readable*. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation.  For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses.  Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. **Goal met** - we believe sample code looks far clearer.
     *   *Homoiconic* (mappable). There needs to be an obvious and clear (to humans) mapping to and from current s-expression notation, which must work for both data and code.  The key advantage of Lisp-like languages is that you can easily manipulate programs as data and vice-versa; that must remain for any modified syntax.  Otherwise, there’s no point; there are lots of other very good programming languages that support infix and other nice notations.  This means that the notation must be *homoiconic*. **Goal met**.
     *    *General*.  It must not be tied to one particular underlying semantic.  If you have to edit the parser after you write a macro, something is wrong. **Goal met**.
-    *    *Standardizable*.  It should be very standardizable across all systems that accept s-expressions (Lisp's original syntax); nobody wants to relearn basic syntax everywhere.  It should be useful in Common Lisp, Scheme, Emacs Lisp, Clojure,  Arc, BitC, ACL2, DSSSL, AutoLISP (built into AutoCAD), ISLISP (standardized by ISO) BRL, and so on.  A thread about guile noted this very need. **Goal met**.
+    *    *Standardizable*.  It should be very standardizable across all systems that accept s-expressions (Lisp's original syntax); nobody wants to relearn basic syntax everywhere.  It should be useful in Common Lisp, Scheme, Emacs Lisp, Arc, ACL2, DSSSL, AutoLISP (built into AutoCAD), ISLISP (standardized by ISO) BRL, and so on.  A thread about guile noted this very need. **Goal met**.
     *   *Work with macros*.  There will probably be some tweaks for indenting and infix notation (especially since infix reorders things!), but macro processing should continue to work in most cases. **Goal met**.
 * **Secondary Goals**
     *   *Easily implemented* (relatively speaking).  It must not require tens of thousands of lines of code to do.  However, if it takes a little extra code to produce nice results, that is fine; better to do things well once.  It need not be easily implementable via a few tweaks of an existing reader, though that’d be nice.  Yes, rewriting a reader is a pain, but those only have to be written once per implementation.  Note that even among implementations of a particular language there is often much variance, so the format needs to be simple enough to support many implementations. **Goal met**.

Goals modified by David A. Wheeler

David A. Wheeler — Sun, 05 May 2013 15:30:48 -0000

--- v4
+++ v5
@@ -20,6 +20,8 @@

 For any syntax to be widely used, there must be trustworthy, widely-usable implementations.  Thus, adoption would be helped by having at least one FLOSS reference implementation with a generous license that permits use by proprietary programs and Free-libre / open source software (FLOSS) programs.  Any FLOSS software should be GPL-compatible, since there is so much GPL’ed code.  This reference implementations would need to be widely portable and modular, so that it can be widely used as a starting point.  Thus, we've worked to develop software under the MIT license; it meets those requirements, and it is the license the Scheme SRFI ("surfie") submissions use.

-We decided to start our focus on Scheme.  We had to start somewhere, Scheme is widely used, and Scheme is picky (e.g., it has distinct values for false and the empty list) so it's probably easier to port *from* it than *to* it.  In the end, specialized implementations well-tuned to different environment will be necessary for an improved syntax to really work.  Scheme and Common Lisp aren’t really compatible at all, in the sense that real code written for one won't run on the other.  Translators like scm2cl (Scheme to Common Lisp translator) could help initially, certainly to get started (suggesting that it'd be best to start with Scheme, and then transition at least an initial version to Common Lisp).  Also, in a pinch the "unsweeten" tool can be used as a front-end for other tools.
+We decided to start our focus on Scheme.  We had to start somewhere, Scheme is widely used, and Scheme is picky (e.g., it has distinct values for false and the empty list) so it's probably easier to port *from* it than *to* it.  In the end, specialized implementations well-tuned to different environment will be necessary for an improved syntax to really work.  Scheme and Common Lisp aren’t really compatible at all, in the sense that real code written for one won't run on the other.  Translators like scm2cl (Scheme to Common Lisp translator) could help initially, certainly to get started (suggesting that it'd be best to start with Scheme, and then transition at least an initial version to Common Lisp).  Also, in a pinch the "unsweeten" tool can be used as a front-end for other tools.  The "unsweeten" and related tools even have a mode that makes them useful for Common Lisps, and Lisps like Common Lisp, in many circumstances.
+
+Since the time we started this, we have developed a Common Lisp implementation as well.

 You might be interested in reviewing our [Solution], or in seeing our [Rationale].

WikiPage Goals modified by Alan Manuel Gloria

Alan Manuel Gloria — Thu, 17 Jan 2013 02:27:48 -0000

--- v3
+++ v4
@@ -5,14 +5,16 @@

 Here are our more specific goals for a programming notation for Lisp-like systems, and how well we believe we've met them in our [Solution].  We wanted notation(s) that were:

-*   *Readable*. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation.  For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses.  Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. **Goal met** - we believe sample code looks far clearer.
-*   *Homoiconic* (mappable). There needs to be an obvious and clear (to humans) mapping to and from current s-expression notation, which must work for both data and code.  The key advantage of Lisp-like languages is that you can easily manipulate programs as data and vice-versa; that must remain for any modified syntax.  Otherwise, there’s no point; there are lots of other very good programming languages that support infix and other nice notations.  This means that the notation must be *homoiconic*. **Goal met**.
-*    *General*.  It must not be tied to one particular underlying semantic.  If you have to edit the parser after you write a macro, something is wrong. **Goal met**.
-*    *Standardizable*.  It should be very standardizable across all systems that accept s-expressions (Lisp's original syntax); nobody wants to relearn basic syntax everywhere.  It should be useful in Common Lisp, Scheme, Emacs Lisp, Clojure,  Arc, BitC, ACL2, DSSSL, AutoLISP (built into AutoCAD), ISLISP (standardized by ISO) BRL, and so on.  A thread about guile noted this very need. **Goal met**.
-*   *Easily implemented* (relatively speaking).  It must not require tens of thousands of lines of code to do.  However, if it takes a little extra code to produce nice results, that is fine; better to do things well once.  It need not be easily implementable via a few tweaks of an existing reader, though that’d be nice.  Yes, rewriting a reader is a pain, but those only have to be written once per implementation.  Note that even among implementations of a particular language there is often much variance, so the format needs to be simple enough to support many implementations. **Goal met**.
-*   *Quote well*.  In particular, for both forward quote (’) and backquote/quasiquote (‘), it must be easy to find the end of the quote, and for backquote/quasiquote, it would be very desirable to support initial comma (,) and friends to locally reverse the quoting (the whole point of quasiquoting). **Goal met**.
-*   *Work with macros*.  There will probably be some tweaks for indenting and infix notation (especially since infix reorders things!), but macro processing should continue to work in most cases. **Goal met**.
-*   *Backward-compatible*.  Ideally, it should be able to read regular s-expressions (at least normally-seen formats of them) as well as the extensions.  I’m willing to give a little on this one where necessary. **Goal generally met**.  There are bizarre edge cases, such as someone writing a(b) and expecting that to be two separate values, but normally-formatted s-expressions work just fine, and pretty-printers can automatically fix the rest.
+* **Primary Goals**
+    *   *Readable*. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation.  For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses.  Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. **Goal met** - we believe sample code looks far clearer.
+    *   *Homoiconic* (mappable). There needs to be an obvious and clear (to humans) mapping to and from current s-expression notation, which must work for both data and code.  The key advantage of Lisp-like languages is that you can easily manipulate programs as data and vice-versa; that must remain for any modified syntax.  Otherwise, there’s no point; there are lots of other very good programming languages that support infix and other nice notations.  This means that the notation must be *homoiconic*. **Goal met**.
+    *    *General*.  It must not be tied to one particular underlying semantic.  If you have to edit the parser after you write a macro, something is wrong. **Goal met**.
+    *    *Standardizable*.  It should be very standardizable across all systems that accept s-expressions (Lisp's original syntax); nobody wants to relearn basic syntax everywhere.  It should be useful in Common Lisp, Scheme, Emacs Lisp, Clojure,  Arc, BitC, ACL2, DSSSL, AutoLISP (built into AutoCAD), ISLISP (standardized by ISO) BRL, and so on.  A thread about guile noted this very need. **Goal met**.
+    *   *Work with macros*.  There will probably be some tweaks for indenting and infix notation (especially since infix reorders things!), but macro processing should continue to work in most cases. **Goal met**.
+* **Secondary Goals**
+    *   *Easily implemented* (relatively speaking).  It must not require tens of thousands of lines of code to do.  However, if it takes a little extra code to produce nice results, that is fine; better to do things well once.  It need not be easily implementable via a few tweaks of an existing reader, though that’d be nice.  Yes, rewriting a reader is a pain, but those only have to be written once per implementation.  Note that even among implementations of a particular language there is often much variance, so the format needs to be simple enough to support many implementations. **Goal met**.
+    *   *Quote well*.  In particular, for both forward quote (’) and backquote/quasiquote (‘), it must be easy to find the end of the quote, and for backquote/quasiquote, it would be very desirable to support initial comma (,) and friends to locally reverse the quoting (the whole point of quasiquoting). **Goal met**.
+    *   *Backward-compatible*.  Ideally, it should be able to read regular s-expressions (at least normally-seen formats of them) as well as the extensions.  I’m willing to give a little on this one where necessary. **Goal generally met**.  There are bizarre edge cases, such as someone writing a(b) and expecting that to be two separate values, but normally-formatted s-expressions work just fine, and pretty-printers can automatically fix the rest.

 Our notion is that the underlying system would not fundamentally change...  instead, systems would simply update their reader, so that it can an extended notation and convert it into s-expressions.  A printer could then redisplay s-expressions later in the traditional notation, or same kind of notation used to input it.  It would also be nice if the notation was not confusing or led to likely errors.

WikiPage Goals modified by David A. Wheeler

David A. Wheeler — Mon, 06 Aug 2012 10:23:22 -0000

--- v2
+++ v3
@@ -3,7 +3,7 @@
 Specific Goals
 ==============
 
-Here are our more specific goals for a programming notation for Lisp-like systems, and how well we believe we've met them.  We wanted notation(s) that were:
+Here are our more specific goals for a programming notation for Lisp-like systems, and how well we believe we've met them in our [Solution].  We wanted notation(s) that were:
 
 *   *Readable*. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation.  For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses.  Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. **Goal met** - we believe sample code looks far clearer.
 *   *Homoiconic* (mappable). There needs to be an obvious and clear (to humans) mapping to and from current s-expression notation, which must work for both data and code.  The key advantage of Lisp-like languages is that you can easily manipulate programs as data and vice-versa; that must remain for any modified syntax.  Otherwise, there’s no point; there are lots of other very good programming languages that support infix and other nice notations.  This means that the notation must be *homoiconic*. **Goal met**.
@@ -19,3 +19,5 @@
 For any syntax to be widely used, there must be trustworthy, widely-usable implementations.  Thus, adoption would be helped by having at least one FLOSS reference implementation with a generous license that permits use by proprietary programs and Free-libre / open source software (FLOSS) programs.  Any FLOSS software should be GPL-compatible, since there is so much GPL’ed code.  This reference implementations would need to be widely portable and modular, so that it can be widely used as a starting point.  Thus, we've worked to develop software under the MIT license; it meets those requirements, and it is the license the Scheme SRFI ("surfie") submissions use.
 
 We decided to start our focus on Scheme.  We had to start somewhere, Scheme is widely used, and Scheme is picky (e.g., it has distinct values for false and the empty list) so it's probably easier to port *from* it than *to* it.  In the end, specialized implementations well-tuned to different environment will be necessary for an improved syntax to really work.  Scheme and Common Lisp aren’t really compatible at all, in the sense that real code written for one won't run on the other.  Translators like scm2cl (Scheme to Common Lisp translator) could help initially, certainly to get started (suggesting that it'd be best to start with Scheme, and then transition at least an initial version to Common Lisp).  Also, in a pinch the "unsweeten" tool can be used as a front-end for other tools.
+
+You might be interested in reviewing our [Solution], or in seeing our [Rationale].

WikiPage Goals modified by David A. Wheeler

David A. Wheeler — Mon, 06 Aug 2012 10:22:12 -0000

--- v1
+++ v2
@@ -1,21 +1,21 @@
+The overal goal of the "Readable Lisp s-expressions" project is to develop, implement, and gain widespread adoption of more readable format(s) for the S-expressions of Lisp-based languages (such as Common Lisp, Scheme, Emacs Lisp, Clojure, and Arc).
 
-Goals
-=====
+Specific Goals
+==============
 
-Here were my goals for a programming notation for Lisp-like systems, and how well I believe we've met them.  I wanted notation(s) that were:
+Here are our more specific goals for a programming notation for Lisp-like systems, and how well we believe we've met them.  We wanted notation(s) that were:
 
-*   *Readable*. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation.  For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses.  Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. **Goal met**.
+*   *Readable*. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation.  For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses.  Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. **Goal met** - we believe sample code looks far clearer.
 *   *Homoiconic* (mappable). There needs to be an obvious and clear (to humans) mapping to and from current s-expression notation, which must work for both data and code.  The key advantage of Lisp-like languages is that you can easily manipulate programs as data and vice-versa; that must remain for any modified syntax.  Otherwise, there’s no point; there are lots of other very good programming languages that support infix and other nice notations.  This means that the notation must be *homoiconic*. **Goal met**.
 *    *General*.  It must not be tied to one particular underlying semantic.  If you have to edit the parser after you write a macro, something is wrong. **Goal met**.
 *    *Standardizable*.  It should be very standardizable across all systems that accept s-expressions (Lisp's original syntax); nobody wants to relearn basic syntax everywhere.  It should be useful in Common Lisp, Scheme, Emacs Lisp, Clojure,  Arc, BitC, ACL2, DSSSL, AutoLISP (built into AutoCAD), ISLISP (standardized by ISO) BRL, and so on.  A thread about guile noted this very need. **Goal met**.
 *   *Easily implemented* (relatively speaking).  It must not require tens of thousands of lines of code to do.  However, if it takes a little extra code to produce nice results, that is fine; better to do things well once.  It need not be easily implementable via a few tweaks of an existing reader, though that’d be nice.  Yes, rewriting a reader is a pain, but those only have to be written once per implementation.  Note that even among implementations of a particular language there is often much variance, so the format needs to be simple enough to support many implementations. **Goal met**.
 *   *Quote well*.  In particular, for both forward quote (’) and backquote/quasiquote (‘), it must be easy to find the end of the quote, and for backquote/quasiquote, it would be very desirable to support initial comma (,) and friends to locally reverse the quoting (the whole point of quasiquoting). **Goal met**.
 *   *Work with macros*.  There will probably be some tweaks for indenting and infix notation (especially since infix reorders things!), but macro processing should continue to work in most cases. **Goal met**.
-*   *Backward-compatible*.  Ideally, it should be able to read regular s-expressions (at least normally-seen formats of them) as well as the extensions.  I’m willing to give a little on this one where necessary. **Goal generally met**; there are bizarre edge cases, but most normally-formatted s-expressions work just fine, and pretty-printers can handle the rest.
+*   *Backward-compatible*.  Ideally, it should be able to read regular s-expressions (at least normally-seen formats of them) as well as the extensions.  I’m willing to give a little on this one where necessary. **Goal generally met**.  There are bizarre edge cases, such as someone writing a(b) and expecting that to be two separate values, but normally-formatted s-expressions work just fine, and pretty-printers can automatically fix the rest.
 
+Our notion is that the underlying system would not fundamentally change...  instead, systems would simply update their reader, so that it can an extended notation and convert it into s-expressions.  A printer could then redisplay s-expressions later in the traditional notation, or same kind of notation used to input it.  It would also be nice if the notation was not confusing or led to likely errors.
 
-My notion is that the underlying system would not fundamentally change...  instead, the system would support a reader that takes an extended notation and converts it into s-expressions.  A printer could then redisplay s-expressions later in the traditional notation, or same kind of notation used to input it.  It would also be nice if the notation was not confusing or led to likely errors.
+For any syntax to be widely used, there must be trustworthy, widely-usable implementations.  Thus, adoption would be helped by having at least one FLOSS reference implementation with a generous license that permits use by proprietary programs and Free-libre / open source software (FLOSS) programs.  Any FLOSS software should be GPL-compatible, since there is so much GPL’ed code.  This reference implementations would need to be widely portable and modular, so that it can be widely used as a starting point.  Thus, we've worked to develop software under the MIT license; it meets those requirements, and it is the license the Scheme SRFI ("surfie") submissions use.
 
-For any syntax to be widely used, there must be trustworthy, widely-usable implementations.  I think at least one FLOSS implementation with a generous license that permits use by proprietary programs and Free-libre / open source software (FLOSS) programs.  Any FLOSS software should be GPL-compatible, since there is so much GPL’ed code.  The implementations would need to be widely portable and modular, so that they can be widely depended on.  Thus, I've worked to develop software under the MIT license; it meets those requirements, and it is the license the Scheme SRFI ("surfie") submissions use.
-
-Scheme and Common Lisp aren’t really compatible at all, in the sense that real code written for one won't run on the other.  Translators like scm2cl (Scheme to Common Lisp translator) could help initially, certainly to get started (suggesting that it'd be best to start with Scheme, and then transition at least an initial version to Common Lisp).  But in the end, specialized implementations well-tuned to different environment will be necessary for an improved syntax to really work.  I decided to start my focus with Scheme, however, since I had to start somewhere.
+We decided to start our focus on Scheme.  We had to start somewhere, Scheme is widely used, and Scheme is picky (e.g., it has distinct values for false and the empty list) so it's probably easier to port *from* it than *to* it.  In the end, specialized implementations well-tuned to different environment will be necessary for an improved syntax to really work.  Scheme and Common Lisp aren’t really compatible at all, in the sense that real code written for one won't run on the other.  Translators like scm2cl (Scheme to Common Lisp translator) could help initially, certainly to get started (suggesting that it'd be best to start with Scheme, and then transition at least an initial version to Common Lisp).  Also, in a pinch the "unsweeten" tool can be used as a front-end for other tools.

WikiPage Goals modified by David A. Wheeler

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

Goals ===== Here were my goals for a programming notation for Lisp-like systems, and how well I believe we've met them. I wanted notation(s) that were: * *Readable*. Any notation should be more “readable” to the uninitiated, in particular, it should look like more traditional notation. For example, ideal format would support infix notation for operations that normally use infix (+, -, <=, etc.), support having function names before parentheses, and not require as many parentheses. Today's developers have to collaborate with many others, and having an easy-to-read notation is important for enabling collaboration. **Goal met**. * *Homoiconic* (mappable). There needs to be an obvious and clear (to humans) mapping to and from current s-expression notation, which must work for both data and code. The key advantage of Lisp-like languages is that you can easily manipulate programs as data and vice-versa; that must remain for any modified syntax. Otherwise, there’s no point; there are lots of other very good programming languages that support infix and other nice notations. This means that the notation must be *homoiconic*. **Goal met**. * *General*. It must not be tied to one particular underlying semantic. If you have to edit the parser after you write a macro, something is wrong. **Goal met**. * *Standardizable*. It should be very standardizable across all systems that accept s-expressions (Lisp's original syntax); nobody wants to relearn basic syntax everywhere. It should be useful in Common Lisp, Scheme, Emacs Lisp, Clojure, Arc, BitC, ACL2, DSSSL, AutoLISP (built into AutoCAD), ISLISP (standardized by ISO) BRL, and so on. A thread about guile noted this very need. **Goal met**. * *Easily implemented* (relatively speaking). It must not require tens of thousands of lines of code to do. However, if it takes a little extra code to produce nice results, that is fine; better to do things well once. It need not be easily implementable via a few tweaks of an existing reader, though that’d be nice. Yes, rewriting a reader is a pain, but those only have to be written once per implementation. Note that even among implementations of a particular language there is often much variance, so the format needs to be simple enough to support many implementations. **Goal met**. * *Quote well*. In particular, for both forward quote (’) and backquote/quasiquote (‘), it must be easy to find the end of the quote, and for backquote/quasiquote, it would be very desirable to support initial comma (,) and friends to locally reverse the quoting (the whole point of quasiquoting). **Goal met**. * *Work with macros*. There will probably be some tweaks for indenting and infix notation (especially since infix reorders things!), but macro processing should continue to work in most cases. **Goal met**. * *Backward-compatible*. Ideally, it should be able to read regular s-expressions (at least normally-seen formats of them) as well as the extensions. I’m willing to give a little on this one where necessary. **Goal generally met**; there are bizarre edge cases, but most normally-formatted s-expressions work just fine, and pretty-printers can handle the rest. My notion is that the underlying system would not fundamentally change... instead, the system would support a reader that takes an extended notation and converts it into s-expressions. A printer could then redisplay s-expressions later in the traditional notation, or same kind of notation used to input it. It would also be nice if the notation was not confusing or led to likely errors. For any syntax to be widely used, there must be trustworthy, widely-usable implementations. I think at least one FLOSS implementation with a generous license that permits use by proprietary programs and Free-libre / open source software (FLOSS) programs. Any FLOSS software should be GPL-compatible, since there is so much GPL’ed code. The implementations would need to be widely portable and modular, so that they can be widely depended on. Thus, I've worked to develop software under the MIT license; it meets those requirements, and it is the license the Scheme SRFI ("surfie") submissions use. Scheme and Common Lisp aren’t really compatible at all, in the sense that real code written for one won't run on the other. Translators like scm2cl (Scheme to Common Lisp translator) could help initially, certainly to get started (suggesting that it'd be best to start with Scheme, and then transition at least an initial version to Common Lisp). But in the end, specialized implementations well-tuned to different environment will be necessary for an improved syntax to really work. I decided to start my focus with Scheme, however, since I had to start somewhere.