At 13:56 -0700 2002/01/16, Scott Raney wrote: >Hey, and that's an easy one. Wait until you get to "the number of >card", at which point the next token could be "button", at which point >"number" is a property, or "buttons", at which point it's a function.
I am not sure why this would be a problem, because the Bison parser selects the rule based on a one lookahead token. >> Otherwise, I think this is a sign of poor language design. If you later >> want to design your own scripting language, then you should avoid the >> confusion that will inevitably arise by the "or"'s having different >> semantic meaning. > >Natural language has always been a major headache for computer-science >types specifically because of these kinds of token ambiguities. But I >wouldn't go so far as to say HT is an example of poor design (well, it >does have its flaws, but this kind of multi-use token isn't one of >them). It's just much more English-like than is convenient for >language implementers ;-) The problem arises when interfacing with the humans interact with the compiler, and need to avoid producing errors: The less the error depends on context information, the easier it is for the computer to catch and produce a correct error, it seems. Hans Aberg _______________________________________________ Freecard-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freecard-general
