Re: Perl embedding: trial balloon
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> wrote:
John> you see any other Emacs features that cannot be
accessed
John> simply by calling functions with the usual elisp data types?
Calling _Lisp_ functions (or low-level XEmacs functions), you mean?
That will always work in the sense of "do something" and "not crash
XEmacs unless there's an underlying bug".
I personally will be happy if all Perl support goes through funcall.
Maybe things like car and cdr can avoid it for speed, but that will
happen in a Perl module (Emacs::Lisp) and will not touch the xemacs
binary. (by the way, are XEmacs headers installed by default?)
Whether the behavior will
make sense to Perl programmers is another question. And it probably
won't make sense to Lisp programmers, who will be expecting the "usual
side-effects" and will be presented with a different set.
One idea is to write a standard set of Perl modules that use
Emacs::Lisp as the backend and present a Perl-like programming
interface. I'm not sure why any of this concerns Lisp programmers,
unless they choose to use Perl. Can you give an example of a "usual
side-effect" and how Perl would make it different?
>> This is a MUCH better idea. Please consider using the
external
>> widget interface instead.
John> Huh? I want Perl to chew on the text in my buffer, not draw
John> widgets. Could you please elaborate.
"External widget" means to set up Perl to use XEmacs as an embedded
editor. Perl can slurp the file you want to edit into a Perl string,
pass it back and forth to XEmacs, etc. Similarly, it can slurp Perl
code out of another buffer. Restricting yourself in this way is
guaranteed Mule-safe, because strings will always be in external
represention rather than Mule representation (which internal
representation may change in the not-so-distant future if Oliver
Galibert has his way).
This is of course a variation on Kyle's `shell-command-on-region'
strategy, except that XEmacs itself is your shell, and it's embedded
into Perl.
So, if I understand you, XEmacs can be linked as a library and
dynamically loaded? What about unexec?
John> The sequence `C-u M-| perl' is etched in my spinal
cord, but
John> sometimes one wants Perl for more sophisticated jobs, and
John> sometimes one is deprived of a reasonable shell.
If "more sophisticated" means running external processes, etc, (all
those things that Perl has nice primitives for), it scares me, too.
For example, take the file writing functions. Are you going to
disable Perl's functions? If not, how are you going to make them
respect Emacs's locking conventions?
It is possible to override some core Perl functions. I believe `open'
is among them. Already, I have written a tied version of Perl's %ENV
hash that updates `process-environment'. I plan to coordinate signal
handlers using a similar strategy.
John> Sure, I suppose you could implement a major mode as a
John> separate Perl process, but who really wants to invent
John> protocols for such things? Not to mention ways to serialize
John> and deserialize interesting data structures.
You have to invent protocols and [de]serialize anyway, unless you
don't care about any users who aren't you. You can just be more
flexible and less careful when you grab access to the internal
representation (== longer rope). No?
The default conversion function performs deep copying of nested lists
as anonymous array references and uses a similar trick for vectors.
It is also easy to make shallow copies.
I imagine it would be possible, and perhaps relatively easy, to design
a system whereby a separate Perl process has enough access to Lisp to
do many of the things I want to do. Heck, if you're going to support
Corba, it'll be guaranteed.
However, that simply does not appeal to me. An embedded interpreter
is more elegant, in my opinion, so it is what I chose to work on. If
someone else writes an IPC-based alternative that does everything I
could imagine wanting and does it well, I will jump.