Language Syntax Suggestion

[Jeremy Dunn]

Hans-Dieter Dreier wrote:


> [if,A
>    ,B
>    ,C
>    ,D
> ]
>
>>Shouldn't there be a comma before the "if"? I'd think that the if must
>>be
>>the first element (hence ordered) to make it a condition clause.

Good question, this brings up the distinction that I made earlier about
a SET and what I called a FUNCTION SET. The expression [,if,A,B] would
mean that I have a set of three ordered elements if,A, and B. In this
case "if" has no meaning as a function because we have declared it to be
some general element that happens to be designated by a combination of
"i" and "f" joined together, it is nothing more than a name for an
arbitrary element. If I now write [if,A,B] we still have an ordered set
of three elements but the lack of period or comma in front of the "if"
is telling us "the following sequence of symbols up to the next comma or
period designates the name of a rule that is to be applied to the rest
of the elements". We have to make this exception in the case of function
sets in order to be able to discern that it is a function at all.
Naturally, only the first element of a function set can be unmarked like
this since there is only one such name for each group of arguments to
the function. There is no case where we would wish the function name to
be unordered and so it is always the first element of the function set.

> Break would be a function with an empty argument that does nothing
but
> break the loop. There are probably several ways to do this.
>>Yeah, but why use the <test>? If it is needed, it too can be written as
>>a
>>break clause that happens to be the first element of the body.

Correct, the example was not intended to cover all possible applications
of a break statement but merely to show that a break statement could be
included in the loop any place that we want it. Any function that we
might need can be viewed as a function set with none or several
arguments and can be embedded wherever necessary.

>not always be true). You see, it is quite conventional. I think writing
>effort is not significantly bigger than in your approach; error
>catching
>may actually be better in pratice. I'd claim that everyone who has ever
>programmed a line in BASIC can read it right from the start without any
>explanation; I'd regard that as an advantage.

I would too if what you said is correct. Just as you don't have a LISP
parser in your head, I don't have a unary-operator/precedence parser in
mine. I recently got through taking a Visual Basic class and I had to
read your email several times to get the gist of how one applies some of
your operators to normal loop structures. I am not faulting your
approach, only you are finding out like I am that what one says to
another seems perfectly clear to oneself but not so clear to the other.
It was educational for me to observe the struggle of the students in my
class as they were required to produce the result of statements in
Visual Basic that required the knowledge of what took precedence. It was
my observation that the average person couldn't understand anything more
than short statements written in such a fashion and they invariably
started throwing parentheses around the subsections of the expression so
that they could figure out what the heck was going on. Only the very
talented "geeks" or math students
did very much better. It was for this reason that I am not entirely
convinced of the argument that they are "clearer" in certain cases. Like
the Chinese word symbology, unary operators always require a special
symbol each time they are invoked, a symbol that we then must apply
context rules to if we use the symbol for any other purpose. And if the
expression is more than a few levels deep...

I think perhaps that you are trying to create a language that reads more
like this email where I am trying to create a format that reads more
like a mathematical expression. Mathematicians in ancient times took
your approach and wrote down their discoveries in verbal form "the
square of the hypotenuse...". What they discovered was that as the
expressions got more involved it was impossible to describe your
relation verbally to someone else unless you wrote an equation. And an
equation is composed of those nasty parentheses and brackets without
which we wouldn't be able to understand hardly anything.

For instance, you have the pairs do/od if/fi and case/esac. All these
are just verbal equivalents of parentheses. Lets have the expression

[(3 * 5)/(2 - 6)] - (2 + 4)(3 - 2)

Is the next expression clearer?

if do 3 * 5 od / do 2 - 6 od fi - do 2 + 4 od do 3 - 2 od

I would argue that our visual system sees order better than our phonetic
system does.
You use , and ; which in my scheme could be represented as two binary
function sets such as [h,,] and [H,,] (or whatever names we might choose
for the functions). The counterargument here is that my way requires 5
symbols where your way requires 1. True, but I would counter-argue that
we have made up in clarity what we lost in typing.

>easier to understand. It also had a set of rather unusual control flow
>constructs (operators, of course). I can give some examples if you
>like.
>BTW, we have been discussing primarily the "executable" parts. I'd like
>to
>know how you would do the declarations and module structure as well.

I do indeed need several examples, sorry I am such a dunderhead. I am
very interested in how one applies the , and ; operators you are
proposing. You'll have to forgive my lack of understanding of some of
the terms you guys are using. I do not have a computer science degree, I
am just a poor schmuck who has had to learn some languages in the course
of my work as a CAD operator and have never dealt with anything as
esoteric as writing a compiler or something of that level. I couldn't
write a compiler if my life depended on it. You'll have to explain to me
what you mean by "doing the declarations" and "module structures".

Also, I enjoyed the website you pointed me to.

jeremydunn@ibm.net