You might get some ideas from the Lua syntax (http://lua-users.org/wiki/SampleCode). It's a nice compromise between the Python and C syntaxes; despite not having syntactically-significant whitespace, it tends to look about as clear as Python, IMHO.
You can definitely improve upon it, though -- the syntax for anonymous functions is a bit cumbersome, in particular. The Lua syntax was deliberately kept tiny to reduce the memory footprint on embedded systems, so some things like switch/case statements are missing, but your language likely won't have the same constraint.
Also, you might want to get an interpreter working 100% first before writing the compiler, as it will be easier to make changes to smooth out emergent quirks in the language. Just a suggestion.
Thanks for your suggestions. Yes, I checked Lua of course, it's neat, but as I said elsewhere, the if ... end syntax is not considered because I find it slightly less appealing than C and Python.
As for interpreter vs. compiler, I thought about this. One approach is to build a simple VM-based system with the entire language infrastructure in place (fundamental types, minimal standard library), which is not much harder than to write an interpreter with the same infrastructure. Then start fine-tuning the VM itself and possibly thinking about the JIC. The original compiler code, which is not the biggest part of your system, is left almost intact in this case.
As opposed to the "interpreter - first" approach, where you will be throwing away some significant portions of your code once you start writing the real compiler. I thought it would be a waste of time. Interpreters and compilers are too different in almost every respect.
The main Lua book points out that such code is "ugly, but valid", and leaves it at that. It seems to me that "x, y = 1, 2" would be cleaner, if someone were determined to make it a one-liner.
You can definitely improve upon it, though -- the syntax for anonymous functions is a bit cumbersome, in particular. The Lua syntax was deliberately kept tiny to reduce the memory footprint on embedded systems, so some things like switch/case statements are missing, but your language likely won't have the same constraint.
Also, you might want to get an interpreter working 100% first before writing the compiler, as it will be easier to make changes to smooth out emergent quirks in the language. Just a suggestion.