Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As programming in JavaScript, I've noticed everything that can be done with statements and blocks can be done with expressions alone. Can a programming language work fine with only expressions? And, if yes, why are statements used at all?

share|improve this question
2  
Yes, there are many everything-is-an-expression languages, such as Ruby and all dialects of Lisp. –  sparkleshy Dec 16 '12 at 13:02
    
@sparkleshy I see, just a guess: they all have an operator analog to the JavaScript's comma (it executes two statements and returns the value of the last)? Is this generally the solution for executing two statements in sequence? I'm counting CL's progn as an analog, I guess, even if it works for >2 expressions. –  Dokkat Dec 16 '12 at 13:04
1  
Everything-is-an-expression doesn't have to look different than an ordinary statement language, statements just... have values. If you made javascript's statements expressions, all existing code would be completely valid. –  sparkleshy Dec 16 '12 at 13:09
    
Of the traditional statements, if, switch, and {} have the obvious values, try {} has the same value as its {}, for, while, and other looping constructs have the value null BUT you have list comprehensions, map, filter, and stuff, which you should look up, and the various goto statements (throw, break, continue) have the value null (but it doesn't matter). –  sparkleshy Dec 16 '12 at 13:16
    
CoffeeScript is an everything-is-an-expression language, that compiles to JavaScript. –  Spoike Dec 16 '12 at 13:29
show 1 more comment

4 Answers 4

Sure. The simplest way is to assign a result value to every construct that's currently a statement and thereby turn it into an expression. That's not necessarily useful or meaningful though. The only potential gain is a bit of conceptual simplicity. However, if you then proceed to remove things like semicolons and loops (requiring chaining via other operators and functions instead), programs heavily using statements become ugly.

A more radical but meaningful way to do this is to design the language such that almost everything has a meaningful value, and use it in a way that you almost always use an expression for that meaningful value, not for other effects. Functional programming languages do this (to some degree; for example, Haskell has declarations, which aren't expressions).

Statements are used because in the imperative paradigm, there are many common operations which don't have a useful result value, and because the notion of sequential instructions (rather than calculations) fits that paradigm quite well. If a large percentage of your program is mutating state, rather than calculating new values, it doesn't make sense to require producing a value (what's the result of a for loop?). In contrast, when your entire paradigm (FP) is built around the calculation of values, outliers that don't have a result value don't warrant an exception: Instead you give them a sentinel result that doesn't mean a thing.

share|improve this answer
    
-1 this is not really true –  sparkleshy Dec 16 '12 at 13:17
3  
@sparkleshy What part isn't true, and how? –  delnan Dec 16 '12 at 13:17
1  
first paragraph: you doubt the idea that statements have useful return values (but many do), propose an ugly thing (why?). second paragraph: declares that all functional programming languages use this ugly fringe concept, which is ridiculous. third paragraph: false, we have that in {} blocks already, the value is ignored and it doesn't cause any problems, incorrect; you're already giving them the lack-of-a-value of void, how is null any less meaningful than that? overall: this is not really true –  sparkleshy Dec 16 '12 at 13:28
2  
@sparkleshy - No statements have useful return values, that's why they're statements. They may have useful side effects (like assignment), but that's not the same thing. This isn't really a fringe concept. It's well known if not entirely practical if taken to the Nth degree. And that sentinel value isn't null or void, it is unit which is subtly different from both. +1 for delnan to make up for this. –  Telastyn Dec 16 '12 at 13:52
4  
@sparkleshy (1) You may be confusing expressions (which can the sole component of a statement) with statement (which aren't expression and have no result value). (2) What? Any FP advocate will confirm that (and argue that it's a good thing). Or is it only the "all" part which you object to? (3) {} blocks are what I'm talking about ("notion of sequential instructions"). And where do I say anything causes any problems? The difference between void and null/unit is that the latter are values and can be passed around, whereas void is special in that there's no value of that type. –  delnan Dec 16 '12 at 14:09
show 3 more comments

Depends on how you define "statement" and "expression".

A very strict definition would distinguish between statements as "things that have side effects, and maybe a return value" and expressions as "things that have return values, but cannot have side effects". With such a definition, no meaningful program can be written without at least one statement (which would have to evaluate an expression and output its return value) - pure expressions alone cannot interact with the world outside the program. A language alone can still be completely pure (i.e., not have any statements), if the impure part is moved out of the language and into the supporting ecosystem (which is exactly what Haskell does, although the language has definitions as well as expressions).

If, however, you allow for side effects in expressions, then the distinction between statements and expressions becomes arbitrary and much less interesting - of course you can invent a programming language that consists of expressions only; most Lisp dialects work much like that. In such a situation, evaluating an expression for its side effects is pretty much exactly the same as executing a statement, and one could argue that in such a language, expressions and statements are the same thing. The difference between a statement and an expression, then, is only syntactic.

Many languages still make this syntactic distinction, because it is useful not for technical reasons, but for readability. Making something an expression signals that you are interested in its return value, less so its side effects; making it a statement tells the reader that you intend it to cause side effects, and the return value may or may not be interesting.

share|improve this answer
    
+1 for comments about readability... In the end, humans need to understand it... –  mattnz Dec 16 '12 at 22:23
add comment

Yes.

Functional languages (and single assignment languages) everything is an expression. Examples are Haskal (and SISAL). Where both if statements and for loops return values.

There are other classes of languages: The easy one that springs to mind is declarative languages (I am sure there are many others that don't depend on statements). These languages don't even need expressions (in the same sense as you would normally think). You declare what is true and you can get multiple results backs. The easy one here is prolog.

share|improve this answer
    
Haskell has declarations, they are not expressions. –  Janus Troelsen Jul 21 '13 at 15:41
add comment

ATL and Xtend are statement-less well working programming languages. Many functional languages are also statement-less. So, yes a programming language can work fine without statements. I think statements are in many languages a relict from imperative programming. They are still used because they are widely known and for some cases they make code more readable.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.