EBNF or BNF for the LOGO programming language

Question

Does anyone know where I can get the BNF or EBNF for the LOGO programming language?

Smack

Not sure who voted to close this as off-topic. "Programming language" is even in the title... – Fulgent

It appears this made its way to Reddit, I'm protecting this for now (will be unprotected in a few days). It's not a problem, yet, just a precaution. – Cockboat

@Tim Post This made it to the reddit programming subreddit, I fail to see how this is cause for alarm. Might have even been a good opportunity to attract new users? – Dewayne

Off topic? Well played, mods. Voting to reopen. – Kneecap

How is a question about EBNF's and BNF's off-topic?! – Smack

Answer 1

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.

Melonie

So are you saying that there cannot be a grammar for the language that is unambiguous? – Smack

Yes, I think no such grammar exists (regardless of ambiguity) unless it's a naive grammar that parses the command string mostly as-is, and just resolves infix operators and the like – Melonie

Right, a naive parser would just parse according to the grammar, but it wouldn't understand the arity of built-in functions. It would seem that while parsing, one would need to look up the arity of the function before deciding how to parse the succeeding tokens. It also makes more sense then as you said, to "parse as you go". – Smack

"Parse as you go" is the way my own logo implementation Logo Arabic does it. I haven't really studied the LOGO implementation scene, and the parser itself is ad-hoc, so I don't claim my work is best practice or even good practice; but the source might be useful for your work. – Melonie

Thanks a bunch! I'm definitely going to take a look at it! – Smack

@VivinPaliath, one particularly bad one is the minus sign (i.e. the - in -52). When you parse you save your words (minus is a "word") in a list. When you print a list, you write spaces between words EXCEPT the minus sign because if you add a space after the minus it becomes a DIFFERENCE (i.e. 33 -52 is different from 33 - 52). For numbers you are likely to convert the value immediately. However that's very important when you write -:A. In this case you want the opposite of :A... – Folkestone

Answer 2

There is no standard LOGO implementation.

Your best call is probably to look at the source of a popular implementation, such as UCBLogo

Saturant