Language Syntax Suggestion

Hans-Dieter.Dreier@materna.de Hans-Dieter.Dreier@materna.de
Mon, 8 Mar 1999 14:03:57 +0100


--GbVpXRYBrSQU60UOUxrnO4guv2ZFTqDv
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Jeremy Dunn wrote:

>Matthew Tuck wrote:
>
>>This is basically what LISP does.  Everything is done with lists,
>>including
>>function applications.
>
>This is true to a point. LISP does allow you to create lists like '(a b
>c) but it does not treat what I call a FUNCTION SET as a list i.e. you
>cannot cannot write something like (nth (+ 2 3 4) 1) to extract one of
>the arguments to the expression. Being able to do this would eliminate
>the need for many math functions that are necessary in other languages.
>I will come back to this point later. LISP also does not allow you to
>collect functions or arguments in the manner that I was proposing using
>the apostrophe and caret, this feature reduces expressions and reduces
>the amount of bracketing that one has to do. I tried this out on my CRC
>math tables book with large lists of equations to experiment with
>notational choices and found this to work far better than other choices.

Can't you write a LISP function that does what you like or are you saying t=
hat there is no built-in (standard) way to handle this? I always thought th=
at lists can be arbitrarily traversed and "executable" nodes (such as opera=
tors) can be treated as data as well?

>>Just a question - why do you allow two different ways of writing
>>strings,
>>yet not two different ways of writing expressions?
>
>I assume you mean why do I allow both (boat) and (,b,o,a,t)? In a holor
>set like {,1,2,3} we have to write it this way because we have to insure
>that we are not confusing it with {123} which would simply be the
>integer 123 rather than the separate integers 1, 2 and 3.

How about writting blanks between the digits to separate them ?

>Not being familiar with APL I can't really comment on that but I can say
>something about readability. I think readability is largely dependant on
>what language the user is most experienced at using. I have used
>AutoLISP extensively in my CAD programming and I find languages like
>PERL or Visual Basic very cluttered looking. I can glance at a LISP
>program and see the structure just by the grouping of the parentheses. I

Lucky you!
Since I have no built-in parentheses matcher in my brain, I have to rely on=
 pretty printing if there are too many of them. The editor that came with t=
he package I tried (a long time ago) didn't do automatically, however, and =
there always arises the question where to break the lines.

>...
>By writing all operations in this way the user is
>never bothered with learning rules of precedence or of context.
>Precedence is only necessary in languages where the language creator
>uses function names to separate arguments rather than using brackets and
>commas. Why have precedence rules when you don't need them?

In everyday programming life some combinations occur more often than others=
. Precedence rules are created to minimize the use of parentheses (so users=
 won't get lost, see above). If there are not too many operators (or groups=
 of similar operators sharing a predence rule), they are learned quite easi=
ly. But, as you pointed out, it really is a matter of taste. And of course =
an AST can be displayed either way (infix, prefix, postfix; with or without=
 precedence rules), as long as the editor knows how to treat the nodes (or =
the user is comfortable with some default assumption).

>Jeremy Dunn

--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--GbVpXRYBrSQU60UOUxrnO4guv2ZFTqDv
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a17462a.txt IA5 DX-MAIL X.400 User Agent=

--GbVpXRYBrSQU60UOUxrnO4guv2ZFTqDv--