On Tuesday, January 15, 2002, at 09:27 AM, Hans Aberg wrote:
> Do you understand you right, that you have not the actual
> HyperTalk grammar
> given, but try to fix it up, to your perception of the match
> the HyperTalk
> language?
I would LOVE to have a good grammar for HyperTalk. However, all
I've got is two things: First, a book called the Script Language
Guide which is a worse source for writing an interpreter than
using a "C For Dummies" book would be for writing a C compiler.
Second, I have a reference implementation to play with.
So, I have to write my own grammar from the horribly inaccurate
book and observations of how HyperCard (the reference
implementation) actually works.
So, when I say one way is correct, it's because thats the way
HyperCard does it.
Someone has put together a BNF grammar which I'm not sure is
legal (at quick glance, it is ambiguous), but even if it weren't
I'm not sure of its copyright status and seriously doubt the
translation to LALR(1) would be trivial:
http://www.jaedworks.com/hypercard/scripts/hypertalk-bnf.html
>
>> answer_statement: ANSWER expr answer_btn_list
>> ...
>
>> answer_btn_list: WITH answer_btn_list_oneplus
>> | /* empty */
>
>> answer_btn_list_oneplus: answer_btn_list_oneplus OR expr
>> | expr %prec PSEUDO_MAX
>
>> expr contains a lot of things, expr OR expr is one of them.
>
> This is what looks wrong to me: That both
> answer_btn_list_oneplus and expr
> contains OR.
Yes, that's correct. They have to -- it means two different
things. Compare it to calling a C function where you can
certainly do:
answer(a || b, c, d || e).
In HyperTalk "||" becomes "or". Unfortunately, in the case of
answer's button list, "," also becomes "or". So:
answer ... with (a or b) or c or (d or e)
> The second point is that in order to avoid parsing conflicts in
> answer_statement, it should normally have a terminator:
> answer_statement -> ANSWER expr answer_btn_list "."
It does, it's just in statement where it has newline as a
terminator. I've clipped a lot of the grammar as it is over 400
lines and growing. Though a lot of that 400 lines is support
code and comments.
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freecard-general
