czwartek, 15 listopada 2012

Scheme and parentheses

Being a dialect of LISP, Scheme has two important features:
As the name LISP stands for LISt Processing, the language is particularly convenient for list processing. And indeed lists are the data type most commonly found in programs written in Scheme.
The shortcoming for this feature is that other useful and versatile data types, such as vectors and hash tables, are in a way neglected, or inconvenient to operate on.
This approach constrasts with the one taken in the other popular programming languages, such as C (which is array-oriented), PHP (which is hash table-oriented) or Python (which is object-oriented).

The syntax for accessing arrays and hash tables in Scheme is cumbersome -- in order to get an n-th element of array, one needs to write:
(vector-ref array n)
which is terribly lengthy, compared to the C notation, where one usually addresses arrays using the special operator []:
array[n];
The Scheme-style vector access gets particularly annoying when the value stored in an array is further used for indexing:
(vector-ref array1 (vector-ref array2 n))
versus the C's short and elegant
array1[array2[n]];
The same argument applies to hash tables and PHP, the power of which stems from, among others, the simplicity of the way in which hash tables are used.

The second feature of LISP is that it uses Lots of Irritating, Superfluous Parentheses. The previous statement is true only partially with regard to Scheme: before R6RS it has only been using one pair of parentheses (although in irritatingly many instances), namely (). This is really few, considering the fact that other languages also use [], {}, or even <>.
With the advent of R6RS things have changed, because the square brackets can be used interchangably with the round parentheses. This seems particularly popular among the societies focused around Racket and Chez Scheme implementation. They are frequently used, for instance, to surround the bindings within the let forms:
(let ([+ *])
  (+ 3 3))
Probably those people find this more readable or elegant, but it's mostly a matter of taste. Many Schemers, however, complain on the idea of equating rounds and squares, and not entirely for the aesthetical reasons.

It rather looks like a missed chance for the improvement that could be made to the language. If the square braces are supposed to be supported by any R6RS-compilant implementation, why does their existence need to be so redundant?

There are various people out there who suggest adding some special meaning to the non-round parens. Some time ago, I have been suggesting, that the square brackets could be used for array and/or hash-map indexing, so one could write
[array n]
instead of
(vector-ref array n)
David A. Wheeler fights a hopeless and insane battle against parentheses and prefix notation in Lisp-based languages, and he suggested in SRFI-105, that the curly braces could be used to introduce infix notation to Scheme.

Both our ideas are equally silly. There will always be opponents who won't like this or that usage of square/curly/some other braces. But it would seem sound if the language offered a programmer the possibility of specifying this or that behaviour to a certain type of brackets or other delimiters -- so the people who like to embrace their bindings with [] would still be able to do so.

EDIT: After thinking for a long time about the issue, I eventually concluded that it would be nonsense to employ different kinds of parentheses to Lisp. And very misleading too. After all, these are just issues of typography, and not logic, so an editor that could typeset Scheme code (through LaTeX, for instance) according to some rules specified by programmers. I think that having such an editor would be a big win for the Scheme community.

As to the issue with array/list indexing, it would be sufficient to make those structures applicable, so that one could simply write:

('(1 2 3) 0)

to get

1

There are some more advanced considerations regarding this solution, and I will hopefully present them in the future.

Brak komentarzy:

Prześlij komentarz