Woops, I forgot to mention that I'm not currently subscribed, so
please CC: jtobey(a)channel1.com.
Jan Vroonhof <vroonhof(a)math.ethz.ch> wrote:
> How easy is to introduce new types in Perl (or should I say perl)? In
> standard Emacs you can get away without out it but in XEmacs you
> really read a character type or better a string type that can contain
> Mule strings... Note that you can crash XEmacs by polluting the buffer
> with illegally encoded multibyte characters. Recoding everything when
> calling perl seems a bit over done. Without access to strings and
> buffers it doesn't make much sense.
Perl has a high-level object system in which ordinary data references
are assigned at run time to a package, from which they acquire
methods, possibly by way of a package inheritance hierarchy. There is
a configuration option to enable overloading of primitive operators
based on the package, but I believe it is turned off by default. The
preferred way is to "tie" a scalar variable to a package that contains
FETCH and STORE methods, which then get invoked whenever the variable
is used. A tied variable has an associated object which may contain a
Lisp object, allowing FETCH and STORE to perform necessary
translations. This probably involves a lot of copying, so it won't
give optimal performance if implemented naively.
> I presume you already had to introduce perl types for markers and such?
Actually, I haven't got that far. Perlmacs is pre-1.0. But I'm not
sure whether such new types are necessary. Perl can call any Lisp
function and store any Lisp object. It might be nice to encapsulate
these Emacsy types to give them a more Perlish feel someday.
> Do the perl reference counting and the elisp garbage collector know
> about each other?
Yes. The Perl-to-Lisp wrapper function incs the Perl data's refcount,
and the finalizer decs it. Since decrementing the refcount can invoke
user code, this happens after the mark bits have been cleared. I
didn't notice whether XEmacs finalizers have this luxury..
The Lisp-to-Perl wrapper puts a copy of the Lisp object in the Perl
interpreter object for marking. The Perl wrapper's destructor removes
it.
> As for getting it into mainstream XEmacs, how general would it be?
> Would somebody be able to put in say a Python binding or even a clisp
> binding instead? Have you looked at the XEmacs loadable modules in
> 21.2.x? It would be nice for maintainability if one could make
> Perlemacs just a loadable module (after a providing some services like
> the type extensions in
> the core maybe).
This is my feeling. The Perlmacs patch modifies Emacs very little,
other than to add generic extensibility hooks and a syms_of_perlmacs
call. There is one exception, which can be omitted if it is thought
to be troublesome. That is that main() has been overloaded to parse
its command line as perl would if "perl" appears in the invocation
filename. This is especially handy for building and testing
extensions distributed as Perl modules, because it allows one to use
the usual installation mechanisms with PERL=perlmacs. For editing
files, the program is also installed as "pmacs".
