Related articles |
---|
Current work in compiler/language design. hackeron@Athena.MIT.EDU (Harris L. Gilliam - MIT Project Athena) (1991-11-10) |
Syntax andy@SAIL.Stanford.EDU (1991-11-27) |
Re: Syntax drw@cantor.mit.edu (1991-12-03) |
Re: Syntax salomon@silver.cs.umanitoba.ca (1991-12-04) |
Re: Syntax rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) (1991-12-05) |
Re: Syntax buzzard@eng.umd.edu (1991-12-05) |
Re: Syntax ea08+@andrew.cmu.edu (Eric A. Anderson) (1991-12-05) |
Re: Syntax gaynor@remus.rutgers.edu (1991-12-05) |
Re: Syntax kend@data.rain.com (1991-12-04) |
Newsgroups: | comp.compilers |
From: | buzzard@eng.umd.edu (Sean Barrett) |
Keywords: | syntax, design |
Organization: | Fraternity of Avian Deists |
References: | 91-11-030 91-12-021 |
Date: | Thu, 05 Dec 91 17:01:22 GMT |
In article 91-12-021 (Dan Salomon) writes:
>Usually arguments about the "naturalness" of programming language
>constructs are a waste of time, since our understanding of human
>psychology is still very superficial and subjective.
This is something that can be experimented on for particular cases. Even
without a model for why one notation is better than another, a designer
can simply conduct studies to find out which constructs lead to higher
productivity (e.g. test both time to create a program and time to modify
an existing program).
>In any case, infix is more concise than
>prefix since it usually requires fewer parentheses.
I often find that C's precedences for &,|,^ vs. ==, != are exactly the
opposite of what I desire, and that this leads to many extra parentheses,
and that for ease of maintenance, it is best to parenthesize all of the
non-arithmetic operations. Writing obfuscated C code has however
sharpened my feel for C precedence and I often live without the "extra"
parentheses, but I do think some readability is lost without them (I have
included a comical example at the end).
Also postfix can be more concise than infix, since it requires no
parentheses, although it does requires delimiters between successive
tokens. Moreover, a similar style prefix syntax can be developed. One
loses the ability to have operations that take variable numbers of
arguments when using postfix instead of prefix, but infix never had this
to begin with; in fact, infix is generally clumsy for expressions
involving three arguments.
Furthermore, I don't think you can find in the literature any evidence
that concise expression is beneficial. The time spent typing code is, I
think, not significant enough that saving a few keystrokes here and there.
The far more important issue is readability, and small != more readable.
In fact, I would expect things like use of whitespace and indentation
would have a much greater impact than use of infix vs. prefix, for users
experienced with both.
>In addition, it is fairly easy to show that humans are not very good at
>matching parentheses beyond about three levels.
But are they any better at tracking infix expressions nested to the
same depths?
buzzard@eng.umd.edu
Can you parse this in your head without parentheses?
x = 10 * 10 - 5 * 5 - 4 * 3
- 2 * 2 * 2 - 2 * 2 + 222 - 1 ^ 2 * 2 * 2 * 2
* 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2
- 1 << 237 + 483 - 3 * 99 - 10 * 10 - 5 * 8 + 8
* 5 * 4 * 3 + 56131 % 123 - 300 - 505 & 316 &
711 + 9 * 9 | 5 * 5 * 5 * 5 - 84
& 01 * 012 * 012 * 012 + 06 * 012 * 012 + 04 * 012 + 0
>> 1 + 1 + 1 ^ 649 & 111111 / 1001 * 7 & 3 * 4 * 5
+ 333 | 0x281 / 0176 << 17 / 7 ^ 17 & 7 * 7
^ 289 & 13107 * 5 >> 1 + 2 + 3 + 4 ^ 444 / 12;
I find that my eyes seem to naturally group the * over the - and +,
but beyond that I get lost. Of course this is an outrageously
artificial example.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.