Hmmm. The nicety of other Inline:: modules is that you can put the source of the other language at either the use statement, or after a __Language__ tag. The you program normal Perl, and just call the routines like you would call any other Perl routine.
Your module doesn't do that. Therefore I think it shouldn't be part of the Inline:: hierarchy; perhaps Acme::Brainfuck?

Acme is certainly a fine namespace. Any module would be proud to be in it but I would like to try adding the features you mentioned. __Brainfck__ I could probable manage if I squint at the Filter::Simple man page long enough but how would I go about implementing the other thing?

--
જલધર

You could start by studying the Inline-API man page.

Abigail

Also, making this a filter and having the ablity to mix perl and brainf*ck isn't really well-implemented -- using any of the BF keywords in the perl code will do unexpected things -- using the Inline API will fix that. (You could also require some sort of delimiter around the BF code, like ({{ }}) that are unlikely to occour in perl code, but that's a hack, IMHO, and not as cool as a real Inline module.)

Also, making this a filter and having the ablity to mix perl and brainf*ck isn't really well-implemented -- using any of the BF keywords in the perl code will do unexpected things -- using the Inline API will fix that. (You could also require some sort of delimiter around the BF code, like ({{ }}) that are unlikely to occour in perl code, but that's a hack, IMHO, and not as cool as a real Inline module.)




How so? I do have delimiters—whitespace. So something like: ++$a = ++ ; will do the right thing. I agree the Inline modules are cool. Unfortunately using the API will need a huge rewrite so it will be Acme::Brainfck (plus the u.) I'm thinking of doing a proper Inline:: version after I'm done with this.




--
જલધર