Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!quiroz
From: quiroz@rochester.ARPA (Cesar Quiroz)
Newsgroups: net.lang
Subject: Re: Discussion on removing punctuation in programming languages
Message-ID: <21461@rochester.ARPA>
Date: Thu, 9-Oct-86 23:58:05 EDT
Article-I.D.: rocheste.21461
Posted: Thu Oct  9 23:58:05 1986
Date-Received: Fri, 10-Oct-86 03:29:57 EDT
References: <7796DMB@PSUVMA>
Reply-To: quiroz@rochester.UUCP (Cesar Quiroz)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 79
Keywords: s-expressions punctuation
Summary: Good idea, but can be improved by removing syntax.
Emacs: -*- Mode: subMH -*-

Expires:

Sender:

Followup-To:


In a very interesting article, dmb@psuvm.bitnet writes:
>>     Punctuation or seperators (; , .) have long been a part of programming
>> language design. Anyone who has programmed for even the shortest amount of
>> will realize that these little demons are responsible for a large amount of
>> possible errors, thus the question is why have them at all?
>> 
>>    ...  A proposal follows, removing separators in favor
>>         of fully-bracketed syntax ...
>> 
    The idea is certainly interesting.  A few random ramblings
before I forget I wanted to follow up:

    1- Bravo!  You are about to rediscover S-expressions (and suggest
    we abandon syntax as a problem?)

    2- I don't think separators (or, in general, punctuation) are an
    unmitigated evil. As with case sensitivity, type equivalence and
    other areas, I think one can find people who intensely prefer
    one of the extremes over the other, as well as people who will
    be indifferent.

    As  an example: Some   languages "free" you  from  semicolons by
    expecting all your statements to end properly in a  single line.
    The language processor  supplies  the  delimiters needed.   This
    causes on occasion the following interesting situation:

        x := y || z
        x := y ||
             z
        x := y
             || z
        x := y
             ||
             z

    The statements above are  not equivalent.  For  the  second, the
    system should recognize that  the  statement is incomplete  and,
    after looking in the next line, will produce the same results as
    the first statement. The third and fourth actually might produce
    syntax errors,  or worse,  unintended behavior, because this way
    of fixing the "semicolon problem" is sensitive to indentation...
    I consider  it  aesthetically repugnant, but  I   am pretty sure
    there are quite reasonable people  who will  find it the "right"
    tradeoff.

    3- BASICs used  to require LET as an  assignment  initiator (the
    end was bracketed by a newline).  That gave the whole language a
    proper nesting syntax (punctuation had uses, though).  I seem to
    recall  a   similar  structure  for  Cobol  procedure   division
    statements:  <verb>  <things>.   But   I bet there  were  enough
    irregularities to mask off this sane intention.  And again, see
    my note 1.  What you *really* want is Lisp...
    
>> 
>> 
>> As a side note does any language allow the mathematically normal syntax of
>>    IF (4 < x < 8) THEN blabla
>>

    ICON  (Griswold&Griswold) allows it.   You  might (or might not)
    like to take a look at its syntax  (it contains the ugly example
    I gave above) but is a  generally sane language.   I would count
    it along  with  'awk'  for writing text  processing  stuff under
    UNIX, but that alone doesn't  do  enough justice to the concepts
    offered in the  language (the syntax, then again,  ...)  I don't
    quite remember  if   Cobol  allows  it   (perhaps *some* Cobol?)
    Common Lisp extends some  of  the comparisons to  take more than
    one argument, in whose case the predicate is true if the
    arguments form a monotonic sequence.  Sort of: if (0<x<y<1)
    then... 

    This question has recurred already.  Perhaps somebody who
    followed the previous round could post a Definitive List of
    Languages Whose Comparisons Bind the Usual Way?
-- 
Cesar Augusto  Quiroz Gonzalez
Department of Computer Science     {allegra|seismo}!rochester!quiroz
University of Rochester            or
Rochester,  NY 14627               quiroz@ROCHESTER