Ken Raeburn wrote:
Obviously, it would help a lot to do so. On the other hand, switching
to primitive-ref's would help even more, but I fear we can not easily
do so, because we can not know if a symbol targets a primitive or was
rebound at compile time... BTW, a quick test with Scheme:
[....]
So it seems that the Scheme compiler just ignores this possibility...
Is (set! + ...) and expecting (+ 1 2) to change invalid, or should
this strictly be regarded as a bug?
In general I don't think you can assume it for all symbols, but if it
helps, the Emacs byte-compiler also assumes that "+" and "cons" and
certain other functions won't be redefined. It's even got an "add1"
opcode.
So if I understand right, if you make similar assumptions and change how
function bindings are handled, your performance for this code drops to
under a second? It sounds like maybe you can get within shouting
distance of Emacs's own performance already, at least for certain test
cases.
Well, that's partially true. For those built-ins that map directly to
Guile primitives, it would probably be an advantage to build
make-primitive-ref's for the generated TreeIL code directly; I'm not
sure if that's done at the moment, but in the future this will help for
things like optimization and special op-codes (e.g. add1).
I think it would really be reasonable to assume certain symbols don't
get rebound, if they don't have a different lexical binding at the
moment; although I think that the concept of dynamic binding is actually
also about the ability to rebind even built-ins to allow for changes...
For instance, what if I wanted to write a program that evaluates the
"efficiency" of some numerical algorithm by overloading + and * to count
the number of operations performed? This seems like a valid need to me
(in fact, I might be doing something similar for my Bachelor's thesis;
though probably not in Scheme or elisp, so this does not directly matter
here).
So my idea was to provide a compiler option to always use an ordinary
function call for certain or all primitives as a compromise; that sounds
like a quite good idea to me catering for both needs.
However, as a side-note: I don't think my code would drop below one
second if this was implemented (hm, at least I'm not sure), because for
instance all built-ins returning booleans (like < in the example) can
not map directly to Guile primitives because I need to translate #f to
%nil inbetween... It's a pity because comparisons are probably quite
common especially in such loops, but if we don't want to get rid of
translation and don't care about #f in elisp (see my other post in the
%nil thread), I see no way around this.
Would this interfere with possibly blending Scheme GOOPS code with Elisp
someday? Or is the generic support there at a lower level than this?
(E.g., a "marker" object holds a buffer handle, possibly nil, and an
offset that automatically gets adjusted if text is inserted before it.
You can use "(+ 1 marker)" and get back an integer one greater than the
marker's current offset. If markers were implemented using GOOPS, would
this use of "+" work, given the changes you're suggesting?)
To be honest, I've nearly no idea about GOOPS so far and thus can't
comment here...
Yours,
Daniel
--
Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri
