Given that Pyret is functional, there's a good chance there will be an emphasis on simple, pure functions.

Beyond that, I'd agree completely. Doctests, for instance, are quite terrible when you can't fit all of the logic into one line, but then I think it's usually a sign of a well-designed function when it's good a good enough interface to get a few pithy doctests in.

Though Pyret is not pure, our emphasis is heavily on "functional first", even for objects. We believe state should be used carefully and for good reasons. HtDP (www.htdp.org) has two whole chapters on state at the end, giving design recipes for their use, and I'm revising some of these in PAPL (papl.cs.brown.edu/2013/).

This is why a test block is a block. Writing inline tests for stateful functions in Racket was a bit painful because it is so heavily expression-oriented. We want to make this feel more natural.

(Another virtue of test blocks: you can write little local helper functions. There's an example of this on the Pyret home page.)

They didn't say one way or the other whether the language was pure FP, but I don't think any of the examples featured mutuality

Pyret is not pure. We have mutation. But mutation has its own syntax different from regular binding. Variables (as opposed to identifiers) are preceded by "var", and variable mutation uses ":=". [Similarly for fields.] This it to make clear to all forms of readers -- programmers, compilers, IDEs -- when something is mutable.