I have working logic for automatic memoization of Pegged-generated parsers from Peg grammars here

https://github.com/nordlow/justd/blob/master/firstPegged/source/app.d

Now I wonder if this logic could be modularized in some way making it more easy to use (and not so verbose).

The key question is if it's possible to somehow replace

the module ctor at

https://github.com/nordlow/justd/blob/master/firstPegged/source/app.d#L339

that writes the grammar and parser to disk with some automatic registration logic.

My plan is to append these to an array of pairs of string at

https://github.com/nordlow/justd/blob/master/firstPegged/source/app.d#L52

that contain file and string to persistently memoized. But when uncomment the lines declaring and appending to fileWrites I get a compilation error

source/app.d(63): Error: no identifier for declarator fileWrites
source/app.d(63): Error: Declaration expected, not '~='
source/app.d(64): Error: no identifier for declarator fileWrites
source/app.d(64): Error: Declaration expected, not '~='

Have I missed something?

Destroy!

On Wednesday, 26 November 2014 at 22:31:04 UTC, Nordlöw wrote:
> source/app.d(63): Error: no identifier for declarator fileWrites
> source/app.d(63): Error: Declaration expected, not '~='
> source/app.d(64): Error: no identifier for declarator fileWrites
> source/app.d(64): Error: Declaration expected, not '~='
>
> Have I missed something?
>
> Destroy!

Update: I guess this means D doesn't allow any statements in global scope. Can/Should I instead use some compile-time reflection to get list of parser strings that should be cached to disk? I guess if I wrap the path-parser-string-pair in a struct, say CachingPeggedParser, defined in global scope I could get a list of all the enum instances of this struct and do something with these in module constructor right?

Please tell me if this approach is unneccessary complicated!