From: Nix [mailto:[EMAIL PROTECTED] > > On 26 Nov 2006, [EMAIL PROTECTED] told this: > > From: "Nix" <[EMAIL PROTECTED]> > > > >> On 20 Nov 2006, Giampaolo Tomassoni spake thusly: > >> > >>>> That's not even mentioning the metaprogramming and higher-order > >>>> programming techniques that we use extensively in > SpamAssassin -- those > >>>> are basically *just not possible* in C/C++. ;) > >>> > >>> Ops. What's this stuff? Let me know. > >> eval and all that it implies. Compiling and executing code at runtime. > >> Calling functions by name. That sort of thing. > >> Of course you *can* do it in C/C++. The traditional method is to write > >> an interpreter or JIT-compiler for another language and do whatever-it- > >> is in that other language. > > > > Of course, you can do that from fast C/C++ code using exec() or > a perhaps > > better a spamc/spamd trick to call these fancy perl facilities. > But that's > > cheating, isn't it? > > Yeah, you could chatter with perl over a pipe, or just embed > perl. Or just, > y'know, use perl :)
Ok. Just a note: I didn't mean to write a perl interpreter, but just to supply with a simple SOA parser and ExpressionBTree builder to an hypotetical rule compiler for an even more hypotetical SAC++ deamon. Most of the rules in my rule body follow a simple SOA pattern. I didn't mean to "embed perl" into it nor to exec SA or otherwise use actual SA (apart for rules): that would be patently stupid. giampaolo > > > Language wars get boring, ya know. > > Never! Rewrite SpamAssassin in Objective Caml, Curry, and Cayenne now! > It'll be so much more efficient afterwards, and the hair our users > lose trying to install the myriad loony interpreters will *help* them > in the long run! > > -- > `The main high-level difference between Emacs and (say) UNIX, Windows, > or BeOS... is that Emacs boots quicker.' --- PdS
