[vidarh]

While I agree with you that it's worth learning to parse something "non-Lisp", I think that starting with an s-expression type syntax is worthwhile for a first-time even if you want to eventually implement a non-Lisp, for the simple reason that parsing is "easy" and very well documented compared to code-generation.

Unless your language has a particularly hairy grammar (Ruby, I'm looking at you...), figuring out how to parse it into your desired structure afterwards is fairly straight-forward in comparison.

That's why I took the approach of bypassing the parser entirely with my compiler series ( http://www.hokstad.com/compiler ), where the first several parts involved going straight to code-generation from code simply abusing the Ruby Array notation. Then later adding a simple s-expression parser.

I didn't even decide to turn it into a Ruby compiler for quite some time (in retrospect, had I planned to do Ruby from the very beginning, there are a few things I'd likely do differently, but not that much; the biggest issues with writing the series have been learning a lot of new things about how writing about code influences the entire process)

[bunderbunder]

The approach I'm taking for a current language project is to start with a minimalist syntax for the first iteration. This allows me to focus on the actual language implementation, which is the part I'm most interested in learning. It also allows me to rapidly iterate on language features without having to spend too much time fiddling with the parser.

Once I've got a semantics I like, I'll probably do a second pass to come up with a new syntax if I haven't decided I'm done with the project. By then I'll have written plenty of test cases using the first syntax, so I should have a much better idea of what I'd like to get out of a more complex one.