Re: Perl embedding: trial balloon

John> I personally will be happy if all Perl support goes through John> funcall. This would be rather slow for typical Perl-ish direct buffer manipulations, I should think. John> Maybe things like car and cdr can avoid it for John> speed, but that will happen in a Perl module (Emacs::Lisp) John> and will not touch the xemacs binary. ??? Why would Perl code go ripping into list structure? It was in a different context, but you did write "I want Perl to chew on the text in my buffer". And car and cdr are not good examples, I think; they're heavily optimized already. Any attempt to speed them up ... you're rattling coffins here .... John> I'm not sure why any of this concerns Lisp programmers, John> unless they choose to use Perl. Because they shouldn't have to care what's in any package that XEmacs can execute. So they might be using Perl, but they shouldn't have to know it. Worse, a package that they thought was Lisp (because that's the language it was written in) could require a Perl module. Of course, you could always add "This XEmacs is Perlmacs-enabled. That means that nothing can be relied upon to behave like it used to (although as far as we know it does, we cannot _prove_ that it will continue to do so), and you could experience severe data loss unless you carefully check all possible Lisp/Perl interactions in all packages that you may explicitly or implicitly load." to the splash screen. That's what Kyle was saying, although much more politely. John> So, if I understand you, XEmacs can be linked as a library John> and dynamically loaded? What about unexec? Yes to the first. I don't understand unexec, so I can't answer that. John> It is possible to override some core Perl functions. I John> believe `open' is among them. Already, I have written a John> tied version of Perl's %ENV hash that updates John> `process-environment'. I plan to coordinate signal handlers John> using a similar strategy. OK, that all sounds doable. But there's a lot of stuff that Perl can do, and that XEmacs can do; I don't see how we can claim to be trying to guarantee no dangerous interactions of the kind referenced in my hypothetical splash screen. That's what XEmacs.org means when it says "XEmacs supports" AFAIK. John> However, that simply does not appeal to me. An embedded John> interpreter is more elegant, in my opinion, so it is what I John> chose to work on. Well, you have my best wishes; that's as good a reason as I've heard for working on anything. But I've heard enough to know that, speaking for exactly one person, I'm not much interested in the goals you've stated. I admit that there are times when I would use a limited Perl functionality to munge buffers (although fewer as time goes on), but the halfway house you describe sounds too unpredictable to me for writing reusable packages; I'll stick to `shell-command-on-region' plus a few extra keystrokes where necessary. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."