A BNF grammar might not be too useful in certain circumstances...

Writing a LOGO that's accurately compatible with existing/historical implementation isn't an easy task (I worked on such a project). The problem is that the parser doesn't do the full job, and the evaluator (interpreter) has to work with partial data. Consider this example:

proc1 a b proc2 c

It could mean proc1(a, b, proc2(c)) or proc1(a, b, proc2(), c) according to the number of parameters for proc1 & proc2.

Furthermore the LOGO interpreters I know, for example Berkely LOGO, seem from a cursory glance not to write a traditional parser that additionally has access to each procedure and its arity; instead they run the procedures and the procedures 'eat up' the number of parameters that they need. This makes the parser a little naive and the main role is that of an interpreter, and thus parsing is kind of unusual.