Published version of scheme25 and nearly finished draft of scheme26

3 files changed, 211 insertions, 205 deletions

diff --git a/artima/scheme/scarti.txt b/artima/scheme/scarti.txt
index edfa2b2..c569a07 100644
--- a/artima/scheme/scarti.txt
+++ b/artima/scheme/scarti.txt
@@ -83,7 +83,7 @@ order hygienic macro like the following one:
         ((v z) #'(vector-ref _v 2)))))
 
 so you would use the syntax ``(v x), (v y), (v z)`` instead of ``v.x, v.y, v.z``
-(more parenthesis the better ;) Notice that the auxiliary variabile ``_v``
+(more parentheses the better ;) Notice that the auxiliary variabile ``_v``
 is introduced hygienically so that it cannot be accessed directly; still,
 you can get the value of the vector with the syntax ``(v)``.
 
@@ -133,7 +133,7 @@ Macros with helper functions
 ``define-macro``-style macros often use helper functions as building blocks.
 ``syntax-rules`` is unable to do that, but ``def-syntax``, being based on 
 ``syntax-case`` has no trouble at all.  For instance, suppose you want
-to define a version of ``let`` with fewer parenthesis (as done in Arc),
+to define a version of ``let`` with fewer parentheses (as done in Arc),
 such that
 
 .. code-block:: scheme
@@ -625,33 +625,6 @@ Here is the implementation using list comprehension::
 module-system
 -----------------------
 
-The Scheme module system is complex both for technical reasons
-(because of the complications caused by macros and because
-of the want of separate compilation) and for political reasons.
-You can discovered about the political reasons in the archives
-of the R6RS editors mailing list. Consider for instance
-this
-
-
-
-Implementation with phase separation make it possible
-to write programs that work the same when typed in the REPL and
-when compiled, at the price of making the REPL less convenient
-to use: for instance they could force the programmer to use
-``define-for-syntax`` even at the REPL: this is how PLT Scheme
-works, however its REPL is not consistent with R6RS mode (strictly
-speaking there is not such a thing as a R6RS-conforming REPL).
-
-
-There are people in the Scheme community thinking that strong phase
-separation is a mistake, and that weak phase separation is the right thing
-to do. On the other side people (especially from the PLT community where
-all this originated) sing the virtues of strong phase separation and say
-all good things about it. I personally I have not seen a compelling
-use case for strong phase separation yet.
-On the other hand, I am well known for preferring simplicity over
-(unneeded) power. 
-
 
 --------------------------- order of evaluation -----------------
 
@@ -1006,3 +979,41 @@ storage of names working across modules?
 .. _thread: http://groups.google.com/group/comp.lang.scheme/browse_frm/thread/509c781e720d28a0/201944b0ac50c594?#201944b0ac50c594
 
 
+
+This is episode #25, the beginning of another block
+of six posts constituting part V of my Adventures.
+Part I was an introduction to the language; part II was
+an introduction to macros; part III was an introduction to functional
+programming and part IV an introduction to the module system.
+We are done with the introductions now, and we are ready to face
+more beefy matters. In particular part V main is concerned with
+expert-level macrology.
+
+In the following six episodes I will
+discuss various techniques and patterns which are commonly
+used by Scheme macro writers, such as recursive macros, higher order
+macros, and more. I will go more in detail
+about how macros work, explaining what a syntax object is, what
+a (non-)hygienic macro is and how you can to compare lexical
+identifiers in macros.
+
+I will also discuss the relation
+between my own ``sweet-macros`` and traditional macros (``syntax-rules``,
+``syntax-case`` and ``define-macro``) so that you should be able to
+program with any Scheme macrology out there. 
+
+Finally I will give some nontrivial example of macro, such as a
+macro implementing runtime pattern matching for lists, by filling the
+gap left in episode 15_ .
+
+power and simplicity
+---------------------
+
+When it comes to designing programming languages, easy of use and
+power seems to go in opposite directions. There are plenty of examples
+where something went wrong, i.e. simple languages which are
+good only for teaching and not for professional use, and
+professional languages which are too tricky to use
+for the casual programmer. We have also examples of languages which
+are both weak in power *and* difficult to use (insert your chosen
+language here).
diff --git a/artima/scheme/scheme25.ss b/artima/scheme/scheme25.ss
index f2cb01a..c75b070 100644
--- a/artima/scheme/scheme25.ss
+++ b/artima/scheme/scheme25.ss
@@ -1,125 +1,109 @@
-#|Macros, again
+#|Back to macros
 =====================================================================
 
-This is episode #25, the beginning of another block
-of six posts constituting part V of my Adventures.
-Part I was an introduction to the language; part II was
-an introduction to macros; part III was an introduction to functional
-programming and part IV an introduction to the module system.
-We are done with the introductions now, and we are ready to face
-more beefy matters. In particular part V main is concerned with
-expert-level macrology.
-
-In the following six episodes I will
-discuss various techniques and patterns which are commonly
-used by Scheme macro writers, such as recursive macros, higher order
-macros, and more. I will go more in detail
-about how macros work, explaining what a syntax object is, what
-a (non-)hygienic macro is and how you can to compare lexical
-identifiers in macros.
-
-I will also discuss the relation
-between my own ``sweet-macros`` and traditional macros (``syntax-rules``,
-``syntax-case`` and ``define-macro``) so that you should be able to
-program with any Scheme macrology out there. 
-
-Finally I will give some nontrivial example of macro, such as a
-macro implementing runtime pattern matching for lists, by filling the
-gap left in episode 15_ .
-
 .. _homoiconicity: http://en.wikipedia.org/wiki/Homoiconicity
 .. _15: http://www.artima.com/weblogs/viewpost.jsp?thread=249681
 .. _MetaPython: http://metapython.org/
 .. _Logix: http://www.livelogix.net
 .. _Dylan: http://en.wikipedia.org/wiki/Dylan_programming_language
+.. _PLOT: http://users.rcn.com/david-moon/PLOT/
 
-Macros pros and contras
-------------------------------------------------------------------
 
 Macros are the reason why I first became interested in Scheme, five or
 six years ago. At the time - as at any time - there was a bunch of
 people trolling in comp.lang.python, arguing for the addition of macros
 to the language.  Of course most Pythonistas opposed the proposal.
 
-However, at the time I had no idea of the advantages/disadvantages of
-the proposal and I felt quite ignorant and powerless to argue. Since I
-never liked to feel ignorant, I decided to learn macros, especially
+At the time I had no idea of the advantages/disadvantages of
+macros and I felt quite ignorant and powerless to argue. I
+never liked to feel ignorant, so I decided to learn macros, especially
 Scheme macros, because they are the state of the art for what concerns
-the subject.
+the topic.
 
-Nowadays I can say that the addition of macros to Python would be
-a bad idea knowing what I am talking about. I have two main objections,
-one technical (and less important) and one political (the more important).
+Nowadays I have some arguments to back up the position against macros.
+I have two main objections, one technical (less important) and one
+political (more important).
 
-The technical reason is that I do not believe in macros in languages
-without S-expressions. There are plenty of examples of macros for
-languages without S-expression - for instance Dylan_ in the Lisp
-world, or Logix_ and MetaPython_ in the Python world, but none of
+The technical reason is that I do not believe in macros for languages
+without S-expressions. There are plenty of examples of macro systems
+without S-expressions - for instance Dylan_ or PLOT_ in the Lisp
+world and Logix_ and MetaPython_ in the Python world, but none of
 them ever convinced me. Scheme macros are much better because of
 the homoiconicity_ of the language ("homoiconicity" is just a big word for
-the *code is data* concept).
+the *code is data* concept). [Notice that technically Scheme macros work on syntax
+objects and not directly on S-expressions like traditional Lisp
+macros, but this is a subtle point I will discuss when talking about
+hygiene; I can skip it for the moment being.]
 
 I have already stated in episode 12_ my political objection, i.e. my
-belief that macros are not a good fit for enterprise-oriented
-languages. Of course, I am *not* implying that every enterprise should
-adopt only enterprise-oriented languages; it is a matter of fact that
+belief that macros have a high cost in terms of complication of the
+language (look how much complicated the R6RS module system is!). Moreover,
+codes based on macros tends to be too clever, difficult to debug, and
+sometime idiosyncratic; I do not want to maintain code such kind of code
+in a typical enterprise context, with programmers of any kind of competence.
+Sometimes I wish that even Python was a simpler language!
+There is a difference between *simpler* and *dumber*, of course.
+I am *not* implying that every enterprise should
+adopt only enterprise-oriented languages; as a matter of fact
 various cutting edge enterprises are taking advantage of
 non-conventional and/or research-oriented languages, but I see them as
 exceptions to the general rule.
 
-In my day to day work (I use Python exclusively there)
-I had occasion to write both small declarative
-languages and small command-oriented languages, but they were so simple
-that I did not feel the need for Scheme macros. Actually, judging
-from my past experience, I think extremely unlikely that I will
-ever need something as sophisticated as Scheme macros in my
-daily work. This is why my opinion is against macros in (most)
-enterprise programming.
+My opinion is based on the fact that on my daily work (I use Python
+exclusively there) I have never felt the need for macros. For
+instance, I had occasion to write both small declarative languages and
+small command-oriented languages, but they were so simple that I had
+no need for Scheme macros. Actually, judging from my past
+experience, I think extremely unlikely that I will ever need something
+as sophisticated as Scheme macros in my daily work. The one thing
+that I miss in Python which Scheme has is *pattern matching*, not
+macros.
 
 Having said that, I do not think that macros are worthless, and actually
 I think they are extremely useful and important in another domain,
 i.e. in the domain of design and research about programming
-languages.
-
-Of course Scheme is not the only language where you can experiment
+languages. Scheme is certainly not the only language where you can experiment
 with language design, it is just the best language for this kind of
-tasks.
+tasks, at least in my humble opinion.
 
-A few months ago I have described
-some experiment I did with the Python meta object protocol, in
+For instance, a few months ago I have described
+an experiment I did with the Python meta object protocol, in
 order to change how the object system work, and replace
-multiple inheritance with traits_. I am interested with this
+multiple inheritance with traits_. Even if in Python it is possible to
+customize the object system, I do not thing the approach is optimal,
+because changing the semantics without changing the syntax
+does not feel right. In Scheme I could have implemented the same
+with a custom syntax and in a somewhat less magical way.
+I am interested with this
 kind of experiments, even if I will never use them in
 production code, and I use Scheme in preference for such purposes.
 
-.. _traits:
+.. _traits: http://www.artima.com/weblogs/viewpost.jsp?thread=246488
 
 Writing your own programming language
 ----------------------------------------
 
 The major interest of Scheme macros for me lies in the fact that they
 *enable every programmer to write her own programming language*.
-I think this is a valuable thing. Everybody who has got opinions
+I think this is a valuable thing. Anybody who has got opinions
 about language design, or about how an object system should should work, or
 questions like "what would a language look like if it had feature X?",
 can solve his doubts by implementing the feature with macros.
 
 Notice that I recognize that perhaps not everybody should design its
-own programming language, and certainly not everybody should
+own programming language, and that xcertainly not everybody should
 *distribute* its own personal language. Nevertheless, I think
-everybody can have opinions about language design and some experiment
+everybody can have opinions about language design. Experimenting
 with macrology can help to put to test such opinions and to learn
 something.
 
 The easiest approach is to start from a Domain Specific
 Language (DSL), which does not need to be a fully grown programming
-language.
-
-As a matter of fact, it seems that in the Python world
+language. For instance, in the Python world
 everybody is implementing his own templating language to generate web
 pages. In my opinion, this a good thing *per se*, the problem is that
 everybody is distributing his own language so that there is a bit of
-anarchy, but this is not such a serious problem after all.
+anarchy.
 
 Even for what concerns fully grown programming languages we see nowadays
 an explosion of new languages, especially for the Java and
@@ -142,8 +126,8 @@ on your own.*
 
 You can the replace the words "web framework" with "programming
 language" and the quote still makes sense. You should read my
-*Adventures* in this spirit: the ambition of this series is to give to
-my readers the technical competence to write their own Scheme-embedded
+*Adventures* in this spirit: the ambition of the series is to give to
+the readers the technical competence to write small Scheme-embedded
 languages by means of macros. Even if you are not going to design your
 own language, macros will help you to understand how languages work.
 
@@ -176,7 +160,8 @@ run-time.
 .. image:: scarab.png
 
 In order to give an example I will define a macro *cond minus*
-(``cond-``) which works like ``cond``, but with less parenthesis:
+(``cond-``) which works like ``cond``, but with less parenthesis.
+Here is an example:
 
 .. code-block:: scheme
 
@@ -186,7 +171,7 @@ In order to give an example I will define a macro *cond minus*
         ...
     else return-default)
 
-I want the code above to expand to:
+should expand to:
 
 .. code-block:: scheme
 
@@ -197,7 +182,7 @@ I want the code above to expand to:
    (else return-default))
 
 
-Here is the solution, which makes use of an accumulator and of an auxiliary
+Here is a solution, which makes use of an accumulator and of an auxiliary
 macro ``cond-aux``:
 
 $$COND-
@@ -245,8 +230,8 @@ $$COND3
 
 These tricks are quite common in Scheme macros: we may even call them
 design patterns. In my opinion the best reference
-detailing these technique and others is the `Syntax-Rules Primer
-for the Merely Eccentric`_, by Joe Marshall. The title is a play on the essay
+detailing these techniques and others is the `Syntax-Rules Primer
+for the Merely Eccentric`_, by `Joe Marshall`_. The title is a play on the essay
 `An Advanced Syntax-Rules Primer for the Mildly Insane`_ by
 Al Petrofsky. 
 
@@ -258,8 +243,8 @@ Petrofsky's essay, which is intended for foolish Scheme wizards ;)
 
 .. _An Advanced Syntax-Rules Primer for the Mildly Insane: http://groups.google.com/group/comp.lang.scheme/browse_frm/thread/86c338837de3a020/eb6cc6e11775b619?#eb6cc6e11775b619
 .. _6: http://www.artima.com/weblogs/viewpost.jsp?thread=240198
-
 .. _Syntax-Rules Primer for the Merely Eccentric: http://www.xs4all.nl/~hipster/lib/scheme/gauche/define-syntax-primer.txt
+.. _Joe Marshall: http://funcall.blogspot.com/
 
 |#
 
diff --git a/artima/scheme/scheme26.ss b/artima/scheme/scheme26.ss
index 14415eb..21360c7 100644
--- a/artima/scheme/scheme26.ss
+++ b/artima/scheme/scheme26.ss
@@ -6,39 +6,49 @@ In this episode I will give a couple of examples of second order
 macros taking other macros as argument. Moreover I will bring
 an argument in favor of good old parenthesis.
 
+.. _even Javascript: https://developer.mozilla.org/en/New_in_JavaScript_1.7
+
 Scheme as an unfinished language
 -----------------------------------------------------------------------
 
-Python is an example of a *finished* language. With *finished*, I mean
-that the language has not only a well defined and complete core, but also
-a full toolbox of shortcuts and niceties to take care of common
-cases and to make easier the life of the programmer. In other words
-Python (but I could name Ruby or a few other languages here) is an
-example of a language which is both easy to use and powerful. It
-spoils the programmer, and this is the reason it is so much popular
-nowadays. Of course, others will prefer Ruby, or Scala, or
-something else, but the concept of finished language should be
-clear.
-
-On the other hand, Scheme feels very much like an unfinished language
-from somebody coming from the Python world. While there are many
-practical reasons why Scheme it is the way it is and could not be
-different, I am convinced that Scheme has been left unfinished also
-*on purpose*: the language is incomplete, but it provides a built-in
-mechanism to give the user the ability to finish the language
-according to its preferences. Such a mechanism of course is the
-mechanism of macros and one of the main use of macros is to fill
-the deficiencies left by the standard.
-
-.. image:: bikeshed.jpg
- :class: right
- :width: 400
+Most programmers are used to work with a *finished* language.  With
+*finished*, I mean that the language provides not only a basic core of
+functionalities, but also a toolbox of ready-made solutions, with the
+goal of making easier the life of the application programmer.  Here I
+am not considering the quality of the library coming with the
+language (which is extremely important in practice) but really
+language-level features, such as providing syntactic sugar for common
+use cases.
+
+As a matter of fact, developers of the XXI century takes for granted a
+*lot* of language features that were unusual just a few years
+ago. This is particularly true for developers working with dynamic
+languages, which are used to features like builtin support for regular
+expressions, a standard object system with a Meta Object Protocol, a
+standard Foreign Function Interface, a sockets/networking interface,
+support for concurrency via microthread *and* native threads *and*
+multiprocesses and much more; nowadays `even Javascript`_ has list
+comprehension and generators!. Compared to the expectations of a
+modern developer, Scheme feels very much like an unfinished language.
+
+Finished languages spoil the programmer, and this is the
+reason why they are so much popular nowadays. Of course not all
+finished languages are equivalent, ans some are powerful or easy to
+use. Some will prefer Python over Java, others will
+prefer Ruby, or Scala, or something else, but the concept of finished
+language should be clear. Certainly Scheme, at least as specified
+in the R6RS standard - I am not talking about concrete implementations
+here - is missing lots of the features that modern languages
+provide out the box and it does not feel finished.
 
 I think the explanation for the current situation in Scheme is more
 historical and social than technical. On one side, a lot of people in
 the Scheme world want Scheme to stay the way it is, i.e. a language
 for language experimentations and research more than a language for
-enterprise work.  On the other side, the fact that there are so many
+enterprise work (for instance a standard object system would
+effectively kill the ability to experiment with alternative object
+systems and this is not wanted).
+On the other side, the fact that there are so many
 implementations of Scheme makes difficult/impossible to specify too
 much: this the reason why there are no standard debugging tools for
 Scheme, but only implementation-specific ones.
@@ -51,32 +61,46 @@ However, when it comes to simple functionality of common usage, everybody
 has got a different opinion and it is practically impossible to get
 anything approved at all.
 
+.. image:: bikeshed.jpg
+ :class: right
+ :width: 400
+
 To avoid that, the standard does not provide
 directly usable instruments: instead, it provides general instruments
 which are intended as building blocks on that of which everybody can
-write the usable abstractions he/she prefers. Most people nowadays
-prefer to have ready-made solutions, because they have deadlines,
-projects to complete and no time nor interest in writing things
-that should be made by language designers, so that Scheme is little
-used in the enterprise world.
+write the usable abstractions he/she prefers.
 
 The difference between Scheme and its concrete implementations
 --------------------------------------------------------------------
 
-In the previous paragraph I have been a little unfair: while it is
+While for many features there are practical reasons why Scheme it is
+the way it is and could not be different, for many other features
+Scheme has been left unfinished also *on purpose*: the language is
+incomplete, but it provides a built-in mechanism to give the user the
+ability to finish the language according to its preferences. Such a
+mechanism of course is the mechanism of macros. Actually, one of the
+main use of macros is to fill the deficiencies left out by the
+standard.  Most people nowadays prefer to have ready-made solutions,
+because they have deadlines, projects to complete and no time nor
+interest in writing things that should be made by language designers,
+so that Scheme is dismissed in the enterprise world.
+
+Here I have been a little unfair: while it is
 true that Scheme - in the sense of the language specified by the
 R6RS standard - is unfinished, concrete implementations of Scheme
 tends to be much more complete. Consider for instance PLT Scheme,
 or Chicken Scheme, which are two big Scheme implementations: they
 have both decent size libraries and they are perfectly usable
 (and used) for practical tasks you could do with Python or another
-more mainstream language. Another option is to use a Scheme
-implementation running on the Java virtual machine or on the .NET
-platform. Alternatively, you could use a Scheme-like
-language such as Clojure_. Clojure runs on the Java Virtual Machine,
+mainstream language. Another option is to use a Scheme
+implementation running on the Java virtual machine (SISC, Kawa ...)
+or on the .NET platform (IronScheme). Alternatively, you could use a Scheme-like
+language such as Clojure_.
+
+Clojure runs on the Java Virtual Machine,
 it is half lisp and half Scheme, it has a strong functional flavour in
-it, it has interesting things to say about concurrency_. It also
-shares the following caracteristics with Python:
+it, and an interesting support to concurrency_. It also
+shares the following caracteristics with Python/Ruby/Perl/...:
 
 1. it is a one-man language (i.e. it is not a comprimise language made
    by a committee) with a clear philosophy and internal consistency;
@@ -87,48 +111,48 @@ shares the following caracteristics with Python:
 3. it provides special syntax/libraries for common operations (
    `syntax conveniences`_) that would never enter in the Scheme standard.
 
-Such caracteristics make Clojure very appealing to me. The only
-problems is that professionally I have no need to
-interact with the Java platform (and even there I would probably
-choose Jython over Clojure for reason of familiarity) so I have not
+Such caracteristics make Clojure very appealing. However,
+personally I have no need to
+interact with the Java platform  professionally (and even there I would probably
+choose Jython over Clojure for reason of greater familiarity) so I have not
 checked out Clojure and I have no idea about it except what you can
 infer after reading its web site. If amongst my readers
 there is somebody with experience in Clojure, please feel free to add
 a comment to this post.
 
-My point here is that users that do not care at all for the freedom
-to "finish" their language and prefer a BDFL language where
-everything has been already finished and polished for them have
+Users that wants a Scheme-like language but do not care for the
+freedom to "finish" their language and prefer a BDFL language where
+most things have been already finished and polished for them, have
 that option, by choosing Clojure.
 
 I personally am using Scheme since I am interested in macrology and no
 language in existence can beat Scheme in this respect. Also, I am
 using for Scheme for idle speculation and not to get anything done ;-)
-A typical example of idle speculation is
-the following question: would Scheme be a better language if it has
-fewer parenthesis?
 
 .. _Clojure: http://clojure.org/
 .. _syntax conveniences: http://clojure.org/special_forms
 .. _concurrency: http://clojure.org/concurrent_programming
 .. _bikeshed effect: http://en.wikipedia.org/wiki/Bikeshed
+.. _25: http://www.artima.com/weblogs/viewpost.jsp?thread=258580
+.. _case: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_idx_384
 
-
-Two second order macros to reduce parenthesis
+Two second order macros to reduce parentheses
 -------------------------------------------------------------
 
-While finding tricks for reducing parenthesis is pointless,
-it gives me a reason to teach a few other macro programming
+A typical example of idle speculation is
+the following question: can we find a way to reduce the number of
+parentheses required in Scheme? Finding tricks for reducing parentheses
+is pointless, but it gives me a reason to teach a few other macro programming
 techniques: in particular, here I will discuss second order
 macros taking macros as arguments.
 
-In the last episode I defined a recursive ``cond-`` macro taking
-less parenthesis than a regular ``cond``, using an accumulator.  Here
+In episode 25_ I defined a recursive ``cond-`` macro taking
+less parentheses than a regular ``cond``, using an accumulator.  Here
 I will generalize that approach, by abstracting the accumulator
 functionality into a second order macro, called ``collecting-pairs``,
 which takes as input another macro and a sequence of arguments, and
 calls the input macro with the arguments grouped in pairs. 
-That makes it possible to call with less parenthesis any macro of
+That makes it possible to call with less parentheses any macro of
 the form ``(macro expr ... (a b) ...)``, by calling it as
 ``(collecting-pairs (macro expr ...) a b ...)``.
 
@@ -147,9 +171,9 @@ with the case_ expression::
        else 'unknown))
  one
 
-.. _case: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_idx_384
-
-Consider the "colon" macro defined as follows:
+``collecting-pairs`` cannot do anything to reduce parentheses in
+``let``-style forms. To this aim we can introduce a
+different second order macro, such as the following "colon" macro:
 
 $$lang:COLON
 
@@ -157,50 +181,46 @@ The colon macro expects as argument another macro, the
 ``let-form``, which can be any binding macro such that
 ``(let-form ((patt value) ...) expr)`` is a valid syntax. For instance
 ``(let ((name value) ...) expr)`` can be rewritten as ``(: let name value
-... expr)``, by removing four parenthesis. The latest version of the
-``aps`` package provides a colon form in the ``(aps lang)`` module.
+... expr)``, by removing four parentheses. Here is a test:
+
+$$TEST-COLON
 
-The case for parenthesis
+The latest version of the ``aps`` package provides a ``:`` form in the
+``(aps lang)`` module.
+
+The case for parentheses
 -------------------------------------------------------------
 
 Parens-haters may want to use ``collecting-pairs`` and the colon macro
-to avoid parenthesis. They may even go further, and rant that the
-basic Scheme syntax should require less parenthesis, since for
-most programmers it is easier to write code with less parenthesis.
+to avoid parentheses. They may even go further, and rant that the
+basic Scheme syntax should require less parentheses.
 However, that would be against the Scheme philosophy:
-the Scheme philosophy favors automatic code generation
-over manual writing.
+according to the Scheme philosophy a programmer should not write
+code, he should write macros writing code for him. In other words,
+automatic code generation is favored over manual writing.
 
 When writing macros, it is much easier
-to use a conditional with more parenthesis like ``cond`` than a
-conditional with less parenthesis like ``cond-``. The parenthesis
+to use a conditional with more parentheses like ``cond`` than a
+conditional with less parentheses like ``cond-``. The parentheses
 allows you to group expressions in group that can be repeated via
-the ellipsis symbol; in practice, you can writing things like
+the ellipsis symbol; in practice, you can write things like
 ``(cond (cnd? do-this ...) ...)`` which cannot be written
 with ``cond-``.
 
 On the other hand, different languages adopt different philosophies;
-for instance Paul Graham's Arc_ uses less parenthesis. This is
+for instance Paul Graham's Arc_ uses less parentheses. This is
 possible since it does not provide a macro system based on
 pattern matching (which is a big *minus* in my opinion). Is it possible
-to have both? A syntax with few parenthesis for writing code manually
-and a syntax with many parenthesis for writing macros?
+to have both? A syntax with few parentheses for writing code manually
+and a syntax with many parentheses for writing macros?
 
 The answer is yes:
-the price to pay is to double the constructs of the language and to
-use a Python-like approach.
-
-..  _Arc: http://www.paulgraham.com/arcll1.html
-
-A two-level syntax
----------------------------------
-
-Python is a good example of language with a two-level syntax: a
+the price to pay is to double the constructs of the language, by
+using a Python-like approach.
+Python is a language with a two-level syntax: a
 simple syntax, limited but able to cover the most common case, and a
-fully fledged syntax, giving all the power which is needed, which
-however should be used only rarely. The best designed programming
-language I know is Python. While not perfect, Python takes full
-advantage of the two-level syntax idea. For instance
+fully fledged syntax, giving all the power you need, which
+however is used rarely. For instance
 
 ====================    =================================
 Simplified syntax       Full syntax          
@@ -211,20 +231,13 @@ c = C()                 c = C.__new__(C); c.__init__()
 ====================    =================================
 
 In the case of the conditional syntax, in principle we could have
-a fully parenthesised ``__cond__`` syntax for usage in macros and
+a fully parenthesized ``__cond__`` syntax for usage in macros and
 ``cond`` syntax with less parens for manual usage. That, in theory:
 in practice Scheme only provides the low level syntax, leaving to
 the final user the freedom (and the burden) of implementing his
-own preferred high level syntax.
-
-When it comes to designing programming languages, easy of use and
-power seems to go in opposite directions. There are plenty of examples
-where something went wrong, i.e. simple languages which are
-good only for teaching and not for professional use, and
-professional languages which are too tricky to use
-for the casual programmer. We have also examples of languages which
-are both weak in power *and* difficult to use (insert your chosen
-language here).
+preferred high level syntax.
+
+..  _Arc: http://www.paulgraham.com/arcll1.html
 |#
 
 (import (rnrs) (sweet-macros) (for (aps lang) run expand)
@@ -275,11 +288,10 @@ language here).
     ))
 ;;END
 
-;;TEST-COLON
 (run
- (test "ok"
-       (: let* x 1 y x (+ x y))
-       2)
+ ;;TEST-COLON
+ (test "colon-macro" (: let* x 1 y x (+ x y)) 2)
+ ;;END
 ;  (test "err"
 ;     (catch-error (: let* x 1 y x z (+ x y)))
 ;      "Odd number of arguments")
@@ -290,5 +302,3 @@ language here).
          (Book b ref title))
        "T")
  )
-
-;;END