Does anyone know where I can get the BNF or EBNF for the LOGO programming language?
Asked
Active
Viewed 3,319 times
14
-
4Not sure who voted to close this as off-topic. "Programming language" is even in the title... – Cody Gray - on strike Jul 25 '11 at 16:46
-
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. – Tim Post Jul 26 '11 at 01:30
-
3@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? – Sled Jul 27 '11 at 13:20
-
Off topic? Well played, mods. Voting to reopen. – Sep 21 '12 at 06:35
-
1How is a question about EBNF's and BNF's off-topic?! – Vivin Paliath Sep 21 '12 at 06:43
2 Answers
13
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.
Mohamed Samy
- 178
- 1
- 8
-
So are you saying that there cannot be a grammar for the language that is unambiguous? – Vivin Paliath Jul 25 '11 at 21:16
-
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 – Mohamed Samy Jul 25 '11 at 21:19
-
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". – Vivin Paliath Jul 25 '11 at 21:21
-
1"Parse as you go" is the way my own logo implementation [Logo Arabic](http://code.google.com/p/logoarabic/) 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. – Mohamed Samy Jul 25 '11 at 21:56
-
-
1@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`... – Alexis Wilke Jun 27 '19 at 21:18
