Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Braces and Brackets #30

Open
FemtoEmacs opened this issue Oct 19, 2016 · 0 comments
Open

Braces and Brackets #30

FemtoEmacs opened this issue Oct 19, 2016 · 0 comments

Comments

@FemtoEmacs
Copy link

My name is Vernon Sipple. I am currently writing a tutorial on femtolisp as a scripting language for femtoemacs. Mr. Hugh Barney's present standing on femtolisp is that our implementation should not diverge from the main branch. However, the present syntax of femtolisp is lacking a Scheme feature that is desperately needed in order to produce a higher compatibility with teaching material. I am talking about the issue of using square brackets or curly braces as synonyms for parentheses.

The use of square brackets and curly braces breaks stacks of parentheses, therefore making it easier for students to recognize patterns in a sequence of right parentheses. For instance, the snippet below shows a higher readability than a version without the curly braces.

(define (fib n)
(cond { (< n 2) 1}
{ else (+ (fib (- n 1))
(fib (- n 2))) } ))

From the point of view of a teacher, there is another reason for using braces instead of parentheses for grouping sequences of statements. Lisp and Lambda Calculus have two kinds of expressions, applications and abstractions. In Cambridge Prefix Notation, applications take the form (E1 x y z ...) and abstraction take the shape (lambda(x) E). According to the Church-Rosser theorem, if an expression is evaluated from left to right, it may reach a normal form that cannot be reduced further. Besides this, if a different reduction strategy reaches the normal form, the alternative strategy form will be the same as the one achieved with the left to right strategy. However, one cannot guarantee that a strategy different to the left-right reduction, proposed by Church, will arrive at the normal form.

Lisp adopts a strategy different to the left-right reduction. Therefore, one needs macros to define certain Lisp operations that require the Church strategy. To tell you the truth, I really don't know whether this explanation for the macro origin is entirely true. At least it is a teacher way of explaining the necessity of macros in Lisp, but not in Haskell. This explanation for the macro origin makes macro and function calls semantically identical. Therefore, both macro and function calls should be placed between parentheses. However, a sequence of statements, as in a cond-clause, has no equivalent in Lambda Calculus, and it is reasonable to put sequences between brackets or braces, as is usually the case when it comes to the Scheme community.

The situation of different Schemes is the following:

Both brackets and braces are undefined in R5RS, then one could use these as synonyms for parentheses. In R6RS, square brackets are synonyms for parentheses, but curly braces are still undefined. Again, in R6RS the implementor can use braces instead of parentheses.

Brackets are synonyms for parentheses in Racket, Gambit, Gauche, Bigloo, Guile, etc. Braces are synonyms for parentheses in Racket, Gauche, Chicken and Gambit. Since femtolisp has used brackets as vector constructors, I suggest the use of braces as synonym for parentheses.

By the way, my tutorial with latex sources is distributed at the following address:

https://github.com/FemtoEmacs/femtodocs

You can use this documentation as you please. As for braces, I will raise an issue concerning both braces and brackets on the femtolisp site. The change has already been made on the femtoemacs site.

JeffBezanson added a commit that referenced this issue Nov 16, 2016
vector syntax is now only `#()`

make `{}` invalid characters to reserve them for future use

this implements an approach to issue #30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants