Re: Callbacks for Yueliang : Speaking Lua for Screenreaders

[KHMan <keinhong@...>]

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.
> OK, I took a second longer glance and armed with your advice on which
> bits of files to look into figured it all out. YOur naming in the
> comment about example usage, talking about x and y, was what made it
> difficult for me. Variable names do matter, especially if reading out
> with speech. I really like code that sounds good spoken e.g:
> if not ready then return end

Yeah, obviously some extra effort is necessary to make it output
reasonably spoken words. The test script's output is simply for
studying and understanding the parser, nothing more.

> [snip]
> which does show me a lot about how the code is parsed. If I wanted to
> create call backs in a SAX-like fashion,, what would be a good way to go
> about this?

You can pass the parser the name of a module (table) to use. The
parser will call various methods (functions) in the module. The
module will do whatever necessary processing since you can keep
state in the module. At the end, the module can be accessed for
the results.

> [snip]
> Produces much the same output as above, the major difference being
> access to the parser object as a table. Which reminds me, I have a
> feeling this re-parsing of the logged output might not be the *right*
> way to do things, might it?

Nope, you should rip out all the message logger calls, they are
only inserts for educational or study purposes. So you can either
code your processing code directly into the parser or keep it
separate via a call mechanism.

> Ah, I think I got it now rendering the post rather useless. Looking at
> how the parser catenates strings for logging, it does of course have
> state based on which the output is generated, and it is accessing this
> parser state that would make writing a simple function dispatch system
> so much easier i.e. avoiding the need for re-parsing the log. My
> question is, how bad form is it if I look at what fields are used in
> generating the log and directly access these fields in my own log method
> as I see fit? 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.

There are many ways of processing. Apart from a purpose-coded
parser or callbacks, you can make the parser generate an
intermediate form and process that instead. The intermediate form
can be simpler than what the message logger generates. I don't
have an opinion as to which method is best.

> Also, in Perl stuff is private by contract unless you rely on lexical
> closure, i.e. private implicitly if not mentioned in the module
> documentation. But in Lua, I'm not sure if the attitude is the same? I
> guess it is since Lua is even more runtime checked than Perl is, even
> strict is a runtime rather than compile time thingy.

Well, if you need to identify whether a variable is a local or
global, a bit of extra code to track local variable liveness
should do the job. Since we are not doing code generation, this
would be less complex than the equivalent in lparser.c.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia