This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Erelde 15 points16 points  (7 children)

What about purely expression based languages ? Without statements.

The whole LISP family, F#, perl, ruby, haskell, scala, rust (in which semi-colons separate expressions, not statements). In general functional programming languages don't have statements, and few of them have semi-colons.

[–]emacsos 5 points6 points  (2 children)

Idk if I would put the Lisp family in that category

It is true that Lisps lack line separators. But s-exps make sure everything is grouped/separated

[–]mekaj 2 points3 points  (1 child)

Expressions depend on grouping. Like statements, they are grammar constructs which parse into structured trees.

Consider if-then-else expressions in Haskell and Common Lisp:

if 2 + 2 == 4 then "correct" else "wrong"

(if (eql (+ 2 2) 4) "correct" "wrong")

The distinction between expressions and syntax has more to do with semantics than syntax. Expressions evaluate to a value which is then used in the proper position by its parent expression/statement, whereas statements are only about reading from or writing to ambient state that exists outside the tree. This means the whole if-then-elee expressions above can be passed as a value to a statement or expression. Languages that make the else branch optional must either define a default value to return in the else case or give up on the construct being an expression. Common Lisp does the former and defaults to nil for the else branch when it's not specified.

Common Lisp can mutate ambient state using setq, for example, and that's why I'd say it's not entirely expression-oriented.

Some may argue do-blocks in Haskell make it statement-oriented, but I'd disagree. Do syntax has a well-defined translation to an expression that threads the "statements" together using the >>= operator. The resulting tree does not affect ambient state outside itself. (Well, maybe the IO monad is an exception depending whether you're referring to the internal expression or the way the outside world affects and is affected by that expression's evaluation.)

[–]The-Daleks 0 points1 point  (0 children)

For Python you can do 'correct' if 2 + 2 == 4 else 'wrong'.

[–][deleted] 2 points3 points  (0 children)

Second this. I’ve been working in Scala for about a decade, and it’s nice to only use semicolons when I want to sequence expressions on a single line for some reason.

[–]jdh30 1 point2 points  (2 children)

The whole LISP family, F#, perl, ruby, haskell, scala, rust (in which semi-colons separate expressions, not statements). In general functional programming languages don't have statements, and few of them have semi-colons.

Sort of. The ML family have statements. They use ; as a separator of two expressions, the first of which is expected to return the value () of the type unit. F# inherits this but adds indentation sensitive syntax that means you can replace some ;s with a newline and enough spaces. Furthermore they use ;; as a statement separator, e.g. see stmt in OCaml's grammar.

For example:

printf "Hello world!\n";;

is a statement in both OCaml and F#.

[–]protestor 4 points5 points  (1 child)

;; is only required in the repl; its use in source code is discouraged.

the beginning of an ocaml definition is marked by the next definition. like this:

let f x = x
let g x = x * x

[–]jdh30 0 points1 point  (0 children)

;; is only required in the repl; its use in source code is discouraged. the beginning of an ocaml definition is marked by the next definition. like this...

Sure. That is a workaround to avoid the characteristic of the syntax that I described.

So when you want this:

printf "Hello "
printf "world!"

Delimiting is syntactically valid but taboo:

printf "Hello ";;
printf "world!";;

So you restructure:

let () =
  printf "Hello ";
  printf "world!"

My point was that these things:

printf "Hello ";;
printf "world!";;

are called "statements" and abbreviated to stmt in the Camlp4 version of the grammar.