Syntax that cheats and a lesson for R7RS

Talk to any schemer and they will extol the value of prefix notation. The conversation might go like this:

Non-Schemer> Prefix notation is ugly

Schemer> What are you talking about? How are these two different? foo(a, b) and (foo a b)

Non-Schemer> Well, what about operators?
Schemer> It takes some practice, but having (+ a b c) means that your expressions are never ambiguous. Besides you can read the above as "add a b and c" - seems readable to me.

Non-Schemer> Oh yeah, what about conditional operations like <

Schemer> Oh you just don't get it, do you?

And the conversation goes downhill from there. But this last point is a good one. Even with years of Scheme practice, I find:

  (< i j)

clunkier than I would like to admin. The problem, partially, may have to do with the fact that < isn't so much a word as it is a graphic. Combine that with the fact that it's read as "less than i j" -- and you can see that it's not that natural.

A novel solution I've seen recommended is to do the following:

 (define increasing? <)
 (when (increasing? a b)
  (printf "~a is less than ~b\n" a b))

Cool, but then I have to think does increasing? correspond to < or >?

And then, yesterday, I saw a pretty solution to this. For some time, I've known that PLT Scheme offers infix type notation that allows you to say:

 (i . foo . j)

Which automatically is mapped to: (foo i j) (notice the two dots).

Well, it never occurred to me to use this for conditionals. I can now write:

 (cond [(i . < . j) ...]
       [else ...])

And the conditional reads just like I'm used to.

Now I have to decide, do I stick with the standard Scheme or give in to this nifty syntax? Oh, decisions, decisions.

A Lesson For R7RS

So what does this all have to do with R7RS, the next scheme standard? Well, I'm certainly not suggesting that this notation become standard. But I would say this feature captures part of the equation for a successful scheme standard.

Mainly, there are two goals that come to mind for R7RS:

• Make it as brief as possible. Let's face it, the R5RS standard is a work of art. Compact enough to print and read, yet powerful enough to build great systems.
• While it's easy to side for minimalism, try using PLT-Scheme for some time, and you'll quickly learn to appreciate the extensive set of features it offers. The infix notation is just one example of a cool feature that makes production programming more effective in a non-standard scheme.

So how do you reconcile these two, apparently contradictory goals? So far, my personal litmus test for a successful R7RS is as follows:

1. Is it brief? Have we removed every possible feature that could possibly be removed?^*
2. Does it provide a path for developers to add the sophisticated features that a PLT-Scheme and other robust implementations offer? For example, to implement the infix notation above, R7RS may offer the ability to alter the reader, and leave it up to the developer to actually make such a heretical decision as to allow for infix notation.

If it can pass those two tests, R7RS will get my vote. Not that I won't change my mind by the time it's written.

Now I have to go off and ponder the value of infix versus prefix notation...

^*This remove all functionality philosophy is standard in the schemers world. I wonder if the standards process should embrace this and specifically have a feature removal stage/vote? Just a thought.