gibeson

Thanks.

Still reading through, it's definitely piqued my interest. However, in the interest of consistency [as it translates to readability] two issues right away:

1) Get rid of the infix modifier to the filter. The statement is made that in ANI everything flows left to right. The infix operator while providing familiar 1+6->7 notation conflicts with the above flow statement. 1,6+->7 while not immediately familiar is easy to understand after explained. However, added special case rules for infix operation muddies the water.

2) In the following code sample provided, the left to right rule is again not followed and thus leads to increased difficulty in [human] parsing:

multiPrint= [string\ s, int\ times] {

        \\[std.gen] <- \times s ->std.out;

"Hello, World!\n", 10 ->multiPrint;

Instead, to be consistent and follow the previous left to right flow rule, use the following syntax:

multiPrint= [string\ s, int\ times] {

        \times -> \\[std.gen];

        s ->std.out;

"Hello, World!\n", 10 ->multiPrint;

In general if there is an everything flows left to right rule, there should not be a <- operator.

imho

Sorry, but what do you mean by "knowing all the forms of the questions"? It seems like maybe you mean all that all the questions formatted via one of several formulas like: name <x> of list<a..z>. Which would imply your tool simply identifies the format then applies some specific logic to solve the question. I'm unclear that if that is what you mean, why then do you know all the forms of the questions? Text capture purports over 180 million questions, so isn't it likely you may not have found all the possible formats of the questions? Or perhaps did you know because you have a relationship with the text captcha creator and they provided that info to you. Or better yet, did your comment mean something entirely different.

Just curious, thanks.

I'd like to formally propose the hoplist law, which dictates Hitler is at most 3 degrees of separation from anything.