>> That's the kind of thing I'm trying to do. Except that figuring out 
>> every possible case is surprisingly hard.
> 
> Yes it is. That's why you need to do it. :-)  Run it thru a 3rd-party 
> postscript interpreter if you don't know what the function is supposed 
> to be. You don't have to test exhaustively. You just have to figure it out.
> 
> Look, you have to figure out every possible case to *write* the code, yes?

Yeah. But you sit down and write some code which you think should work, 
and then you have to write lots of test cases for

- Does it fail on a zero-length literal name. [The spec explicitly 
*allows* such names.]
- Does it correctly handle [what would otherwise be] comments inside a 
literal string?
- Does it choke if the input contains a comment [and so is non-empty] 
but no further actual tokens?
- Does it parse all possible reals, but not invalid ones such as "." and 
"e1"?
- Does it handle balanced brackets and escaped brackets in strings?

It's easy to *think* you got all these working, only to suddenly 
discover that in some sufficiently obscure case it falls over. :-/

>> (And how do you figure out what
>> the "correct" answer is? This is sometimes non-obvious.)
> 
> If you can't tell from the spec, you have to run it against someone 
> else's implementation. If you're attempting to build a compatible 
> implementation, it has to match Adobe's(?) regardless of what the spec 
> says.

I'm not aware of any Adobe implementation that's freely available. 
(Except perhaps for the one inside the nearest laser printer. And I 
already tried to get that to parse stuff; it didn't seem to want to do 
it for some reason.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message