 |
lua-l archive |
|
|
||
|
KHMan wrote:
Hey, thanks for letting me know. From the little I've had time to play with this so far, I've found the method of entering an expression, thinking of how I'd like that read with a screen reader, and then matching those bits of text I like read out and calling my own functions from :log good enough at this point. Even the code is rather readable due to that. I'm not sure yet but it seems to me I might not need variable management, though, if I can get the local keyword, and most other keywords announced. People can keep track of localness mentally and whether or not something is a variable should not have to be announced either. That is as long as things that are not variables, such as strings, function calls and field accesses are distinguished unambiguously.Veli-Pekka Tätilä wrote: > KHMan wrote: > <heavy snippage> > > Yueliang is a casual project with no clear goals, so it's in bits > > and pieces. You can follow what the bits and pieces are by looking > > at what the test scripts use. > > > > test_lparser_mk3.lua in the test directory exercises the > > lparser_mk3.lua parser, and uses the llex_mk3.lua lexer as well. > > The parser_log directory shows the result of the message logger > > calls, basically showing which functions are called during > > parsing, and it closely follows the original C equivalents. > [snip snip] If they are locals rather than object fields then ummm I > reckon I'd need to access the callers namespace then, too. Technically > overriding log is still an object method but it is also my own code, not > really extending the parser per se. This introduces a dependencey on the > parser internals. but at this point in which I'm trying to figure out > whether attempting to improve Lua code read outs for screen reader users > like me is worth it in the first place, even that quick n dirty solution > would probably do fine. In fact I think I'll do just that. A very brief note. I've just updated Yueliang with simple variable management code to classify variables into locals, upvalues or globals. It's around 100 lines of added code only. The release include sample parser log output also, but note that parts of the output, such as internal variables in a 'for' loop, may not be relevant to a screen reader.
There's one earlier point I'd like you to clarify a bit:When I asked about call backs, you said that one can pass the parser a table and get callbacks called in it? I've been looking at, method calls used in parser, the returned function from parser, the parser function and bits of the lexer and cannot figure out where this table is passed to the parser or the lexer, or where the methods get called, unless you ment the possibility of adding such a thing myself, which came to mind. To me only the code string, what type of item it is, and the lexer are passed to the parser eventually and most method calls are either log or those of the lexer.
Then I thought it might be some extra parameter of require but unlike in Perl, where use takes arguments other than the package name controlling importing, require in Lua doesn't. So could you clarify what you ment perhaps with a simple example snippet setting up the table so that it merely prints the function names it tries to call via ____index.
-- With kind regards Veli-Pekka Tätilä