Re: Perl embedding: trial balloon
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
This depends on whether the Perl code is able to act directly on
large pieces of the buffer for things like regexp matching and
substitution. If Perl regexps in Mule are implemented by pulling
characters out of the buffer one at a time, it's going to be
incredibly slow.
I don't know if our regexp matcher is much smarter than that. It
might be.
Here we are talking about something like:
perl_char = mule_to_ucs (BUF_FETCH_CHAR (buf, pos));
...where mule_to_ucs() is a table-driven function. There is also the
possibility to make the matcher smarter so that it pre-fetches a part
of the buffer, and converts it. And so on.
I think it would be OK to ignore the Mule efficiency issues at the
very beginning, and worry about them later, when the rest of the
infrastructure is in place.
So presumably what John has in mind is using XEmacs's low-level
C
code to access buffers, Lisp strings, and so on. But if that's "all
Perl support going through funcall," I don't see what safety that is
supposed to guarantee.
XEmacs is not about "safety", at least not in the C++ sense of the
word. The safety XEmacs is about is the run-time safety of Lisp,
which relies on correctly implemented internals. If John writes
correct code, it will work. If not, not. As always.
To rephrase: the C code I've written today is not guaranteed to be
safe, and neither will John's code he writes tomorrow be guaranteed to
be safe. But if he writes it well, the resulting Perl-Emacs
combinations (what a horror) *will* be safe, and that's what counts.
I don't think the analogy is correct. Windows-enabled XEmacs
can't
get at Lisp structures except through the same Lisp engine.
Evidently the Perl engine is going to be able to get at a lot of
Lisp data, maybe all of it.
So what's your point?