From the Jargon File:
A language lawyer is distinguished by the ability to show you the five sentences scattered through a 200-plus-page manual that together imply the answer to your question "if only you had thought to look there".
See Language Lawyer Required, where Gareth Mc Caughan most definitely qualifies ...
An alternate definition: Someone skilled in the Problem Domain of programming languages--or at least in the implementation details of a particular language.
Language Lawyers are folks more concerned with what a language is supposed to do, and how to specify that, than they are with how to use it day to day. Bjarne Stroustrup and Larry Wall are a couple of the more creative examples. Most mere mortals would do better to stick to what's simple and what works.
... but be sure you know a language lawyer. It helps to have one on the team. You may have to twist the lawyer's arms to make her keep it simple, but she will be able to tell you what's wrong when the language is fighting you on some simple thing and you can't figure out why.
If you're in the business of designing and/or implementing a language, then you should either be a language lawyer, or have one (or more) on retainer.
Brooks in The Mythical Man Month describes the role of a Language Lawyer in more detail. Brooks' information is based Harlan Mills' article "Chief programmer teams, principles, and procedures." To Brooks, a Language Lawyer is not a bad thing to be but is the "go to guy" when you can't figure out how to do something in your language, or have an error that you don't understand, similar to the role of the Unix Guru.
See original on c2.com 