[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Statements and Expressions - a pointless distinction?




>[paul graham]...the pointless
>traditional distinction between statements and expressions
>(which Javascript and Smalltalk have already tossed, and
>Perl at least hides)...

Is there a general agreement among progammers/language 
designer/ll1-listmembers on this (that the distinction of statements and 
expressions is pointless)? Is there an agreement between lisp'ers and 
pythoneers, for example?

Thomas Kühne in A Functional Pattern System 
http://www-agce.informatik.uni-kl.de/~kuehne/fps/, concludes that when 
wanting to integrate FP and OO in one lang, it is a good/helpful feature to 
have distinct syntax for queries and things that change state and don't 
return a value.

In many langages there is a tendency to use either expressions or statments 
independently of the nature of the operation (in dylan one can choose 
either syntax with no semantic difference what so ever, in Ryby most 
statements return a value (for succintness and flexibility, in lisp 
expressions are the only "syntax" that exist, but it's semantics can be 
statementlike(sideffects), or expressionlike(querylike) or both at the same 
time)). Whereas in _all_ natural languages, (hidden behind the surfacial 
complexities that are the main target of linguistics), a expression _can 
not have side effects_ and must return a value, while a statement does 
never return a value and always have side effects. Wouldn't that fact 
indicate, if not theoretical superiority of that distinction, _at least_ 
that human thinking would have an easier time if those concepts 1) does 
exist in the syntactical repertouaire, and 2) is not semantically mixed up?

The constant mixing of the semantics of statements and expressions in 
computer languages leaves it up the the programmer's memory capacity and 
naming conventions to know about what a lingual action really does (side 
effects/database update or query-like actions), thus makin code more 
error-prone-ness, and less readily understanable.

This goes down to the philosofical level:

The uttermost distinction of a statement from an expression is time. 
Evaluation of an expression is in principle timeless (in natural 
languages), thus _there can not be_ any side effects. While for a 
statement, the situation is the opposite, time does 'tick' and side-effects 
do take place. This is not a bad thing. This is just a mirroring of the 
reality. Time do pass. Things do change. The human mind database does get 
updated.
So the distinction of statements is not a misinvention af computer 
lang-designers, but a transfer from how the human brains treats information 
lingually, which in turn is a result of the nature of reality. From the 
above arguments, I would guess that letting statements be statements and 
expressions expressions would be helpful, not pointless.

 From the above, it is a quite natural thing that FP's have only 
expressions (the "def" set aside; it sholuld be a statement), since time is 
excluded from the founding paradigm. Still the naming conventions are often 
verbical/imperative, like "map", and "inc", which is inherently misleading, 
at least from the above reasoning. This indicates to me that human 
thinking, can not be kept out of language usage for long, no matter how 
formal the approach.

I am interested in understanding this better, and would be thankful for any 
comments.

/Henning