in reply to Re^2: An Unreal Perl Hacker!
in thread An Unreal Perl Hacker!

I hate to be a nay sayer, but if you follow exclusions 2, 3 and 4 you likely cut out about 75% of the material posted. Many of the best contributions are best exactly because they do use a module to get work done.

Likely the best code discoverd by such a system will be the system's own code! Bet modules are used to write it though.

In any case, best of luck with it. It's a neat idea, but I suspect pretty tricky to realise.

Perl is Huffman encoded by design.

Replies are listed 'Best First'.
Re^4: An Unreal Perl Hacker!
by samizdat (Vicar) on Oct 13, 2005 at 19:38 UTC
    That's why I'm drastically limiting its initial functionality spec, GrandFather. I would like to see something that might work, first. Of course I'd like to be able to include modules, and read/write, and everything else, but the problem space explosion would make it completely un-doable. Just building an expression modeller that would handle a limited subset of Perl imperative and declarative code would be a non-trivial undertaking, and, of course, I expect that we will use modules in its execution. How much code is there in your Ook! interpreter??? This is a much bigger problem domain, even if we also throw out ReGex and things like that. My SPICE equation parser was 26 pages of code, no modules, and that was pretty trivial compared to this. Even if we just handle loops, conditionals, assignments and things like that, it's a big set of possible patterns.
[reply]

In Section Perl Monks Discussion