Read lots and keep it simple
Designing a new language is hard. Really hard. But ultimately very satisfying if it becomes popular and really solves a problem that people are experiencing in an elegant manner.
As I mentioned in the comments, I'd advise you to read Domain Specific Languages by Martin Fowler for the following reasons:
- He goes into a lot of practical depth about why you should design a language
- There are details on how to do it (parsers, lexical analysers, language workbenches etc)
- There are detailed implementation instructions about how your chosen syntax can be made to handle concepts like closures, annotations, literal lists, dynamic reception etc
As for how to go about writing your specification, think about your audience. Obviously, before putting finger to keyboard to design your language you will have thought carefully about what it is intended to do.
If it's going to be used on the next mission to Titan, then extremely detailed specifications showing exact formal proofs of the behaviour of each component will be the minimal entry level.
So, it's not a straightforward thing. To approach the specification, you would probably be better off gaining a lot of experience in creating your languages and also working with those who actually use them on a day to day basis. If you have willing victims... er... developers, at work who can take some time to learn your language then they can give you feedback on what is needed to get them to use it.
In short, keep it simple and more people will use it.