Re^26: aXML vs TT2

without quoting, there are certain programs and pieces of data you can't represent.

I'm not sure specifically why, however I have a gut feeling that that comment is infact incorrect.

You might have to write the program in a different way to what your used to, but I see no reason why you cannot get any output at all from aXML, by virtue of the fact that the plugins have the full expressivity of Perl itself, and aXML is therefore Turing complete.

Comment on Re^26: aXML vs TT2

Replies are listed 'Best First'.
Re^27: aXML vs TT2 by chromatic (Archbishop) on Oct 24, 2011 at 05:25 UTC
You may be right, but ikegami is trying to get you to do an inductive proof of that. I've written a few compilers myself and patched more than a few parsers. Given that experience, I think you're going to run into a nasty bug at some point due to this evaluation strategy, and it's going to be a real trial debugging it. Improve your skills with Modern Perl: the free book.	[reply]
Re^28: aXML vs TT2 by Logicus (Initiate) on Oct 24, 2011 at 05:49 UTC
Ok, I'm not actually familiar what that an 'inductive proof' actually is or how it works, but I am more than willing to study up on the concept and put the time in to make such a proof. Regarding your feeling that I am going to run into a nasty bug at some point, I have a feeling that I already ran into that bug a long time ago, and solved it. If it's the same bug which your possibly starting to realise the existence of, then all I can tell you is that that bug is the reason for the existence of the two extra bracket delimiter types ; `( ) (/) and [ ] [/]` which no one yet seems to have really picked up on or asked about. They are not there for the sake of my health! If it's some other sort of bug, then all I can say is that in the last 4 years of using aXML to build some really big and complex apps with, I have yet to encounter it.	[reply] [d/l]