Language Syntax Suggestion

[Jeremy Dunn]

Hans Dieter Dreier wrote:
>Apparently you got me wrong. I'd never suggest to define a language so
>that [ x] would have a different meaning from [x] just because of the
>missing space. That would really invite programming errors. What I
>wanted to say is that one token (here: the comma) should not be used
to
>denote different things. If it is used inside a list, it acts as a
>separator, maybe carrying some other semantics as well. If it is used
>as a "prefix" (certainly there is a better term for that, but you get
>the point) like in [,a,b], it means something different. Not knowing
>your definition, I would intuitively take it as "a list of three
>elements, where the first one is empty". You see, it's just a matter
of
>ergonomics. It is not only important to keep the number of keywords at
>bay but also the number of rules. And to keep them consistent to each
>other and to what people might expect. At least if you want others to
>understand your program.

I think the confusion is this, the comma (as I am using it) precedes
the
element it designates and says "the following element is ordered, it
must be in this position in the list". So the comma both separates
elements and carries syntax as you say. Thus [,a,b] is a list of two
ordered elements, [,,a,b] is a three element ordered list whose first
element is empty, [.a.b] is a list of two unordered elements i.e.
equivalent to both the lists [,a,b] and [,b,a]. In conventional
languages the comma as you say is nothing more than a separator because
it is always assumed that the list is ordered. I merely suggest that we
allow the programmer the ability to decide for himself whether order or
disorder is appropriate to his particular problem.

>True, but again the reader has to scan the context to detect what ","
>means in a particular place. That's one reason why they invented
>keywords - to make the token express its meaning more clearly if it is
>a special one (like a control construct) without the need to look at
>the surrounding text. Of course no special symbols are ever required
>except () - just look at Lisp. But many people have big problems to
>read a Lisp program as fluently as a more traditional one, say Pascal
>or C, at least until they are used to it.

Let us take the example "If A Then B ElseIf C Then D" again and
consider
it in my format as it would probably be written in an actual program:

[if,A
   ,B
   ,C
   ,D
]

This is more LISP like. With the individual program statements written
with proper indentation it is really not so difficult to pick out the
structure, but if you write it as a single line as I did for my example
it would be confusing if it got too large. I agree that this again
falls
back to a matter of personal taste.

If we are willing to adopt some more strictures on presentation we can
adopt my notation to a vertical format that can eliminate half the
parentheses, in this case indentation becomes MANDATORY and not merely
aesthetic presentation. My original notation was designed to be
suitable
for a continuous 1-dimensional string of symbols, if we take advantage
of two dimensions we can simplify things further. Consider a statement
such as [e,K,{C,{b,{A,s,a},{A,s,b},{A,s,c},{A,s,d}}}]. This is a
representation of the formula for the area K of a cyclic quadrilateral
in my notation. It is not important to know the details of what each
symbol stands for but to consider how we can rewrite it vertically and
omit half the brackets. We can write it as

[e
 ,K
 {C
  {b
   {A
    ,s,a
   {A
    ,s,b
   {A
    ,s,c
   {A
    ,s,d

And using my apostrophe for collection of arguments we can write

[e
 ,K
 {C
  {b
   {A
    ,s,a',s,b',s,c',s,d

And using the apostrophe again for nested functions we can write

[e
 ,K
 {C'b'A
  ,s,a',s,b',s,c',s,d

It should be clear that the arguments of a function are always indented
farther to the right for each increase in the depth of the expression,
we don't need the trailing brackets because it is always clear what
each
expression is operating upon. This type of code would be very easy to
parse and at least as readable as most languages, it would eliminate
LISP's trailing parentheses. This layout is one reason I was suggesting
writing an expression such as s+t as {a,s,t}, it is necessary to write
it this way to make the proposed vertical layout workable.

>How do you express a loop that has a conditional break somewhere in
the
>middle of the loop body? Or two of them?

Other than the appearance and layout of the test condition my Loop
function behaves pretty much like any other loop, the body is merely a
series of steps like we would normally see. You could have something
like:

[Loop,<test>
   ,[
     ,step1
     ,step2
     ,[if,X,[Break,]]
     ,
     ,stepN
    ]
]

Break would be a function with an empty argument that does nothing but
break the loop. There are probably several ways to do this.

>Is this rule a special form of a more general one, or does it apply
>only to loops? Which means if there is [,a,] and [,,a,], is there a
>general rule, regardless of context? What about [,,,a]?

The meaning of the commas was explained above. The test condition of
the
loop is either an integer or a list. If a list the list can have only 2
or 3 elements and they must be the form and type indicated for the Loop
function. The expressions you wrote would be interpreted as:

[,a,] an ordered two element list with the 2nd element empty
[,,a,] an ordered three element list with the 1st and 3rd elements
empty
[,,,a] an ordered three element list with the 1st and 2nd elements
missing

I hope this clarifies things.

>So do I, but I would do it differently.

I'm game, how would you do it differently? This is precisely the kind
of
discussion I am interested in.

jeremydunn@ibm.net