- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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.
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.
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
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.