> I suppose it depends on how the interface between a scripting language and
> the core of lyx is designed. If the scripting language accesses the core
> only through lyxfunctions, it won't be much of a help regarding
> extensibility. A client couldn't be developed separate from the set of
> available lyxfunctions -- for every odd new need, a new lyxfunction would
> be necessary. :P Maybe it's possible to have a scripting language that
> can n/handle any arbitrary c++ object, but I have no idea how that would
> be implemented. If a scripting language should operate on such a low
> level, it should be a language following the same paradigm as c++.
> ...like, c++? =) (mixing fundamentally different paradigms is asking for
> trouble imo)
Check out SWIG at www.swig.org. This is a package that is designed to solve
this problem: Create an interface between different data-structures and
procedures in different programming languages.
Mixing different paradigms is exactly what makes things powerful!
The best illustration of this is C++ itself: This language supports multiple
programming paradigms simultaneously: 1) Classic imperative programming a la C.
2) Object oriented programming. 3) Generic programming via templates.
Because you have the option to do things in different ways, you are much better
suited to solve difficult problems. In LyX, we use the classic imperative
programming for much of the logic code. We use the object orientation for the
insets. And the generic programming is used indirectly through the STL.
(Incidentally, I think we should use generic programming much more now that the
compilers handle templates.)
By extending LyX with a functional language, we can gain a quantum leap in
expressive power. Suddenly we can handle an entire document (or chapter, or
....) as a first class variable. We can add two documents together like were
they integers. We can apply any given function on a chapter. The possibilities
are mostly limited by imagination.
And the glue that is needed to make this possible is limited. After all, the
data structure in LyX need not be expressed that complicated: A list of
glyphs. Granted, a glyph can be a complex object, including another list of
glyphs, but interface-wise, this is not that complicated to express.
> A scripting language is useful, but only on a higher level of abstraction I
> should think. (and a scripting language interpretator itself could be a
> module)
Even if the scripting language is not higher level, we still gain the benefit
of much faster development: An interpreted language means that we have much
faster development, because we don't have to wait for compiling, linking and
start-up of LyX in order to debug the code, (not to forget stepping through the
code with gdb). You just write it inside LyX (or in an editor that is
connected to LyX), press run, and there you are.
> The more interesting and complicated tasks would involve retrieving
> information about the contents of the buffer, or portions thereof (the
> current paragraph, chapter..), something which is difficult or even
> impossible through text strings, but trivial with a dynamic object with
> direct access to the objects in the core. If the dynamic objects are
> completely opaque to the core, the core won't have to be altered for a new
> dynamic object.
What is the advantage of providing a DLL system that requires access to all the
LyX header files?
The point about the core being ignorant about extensions is not valid: We
already have this with the front-end set-up: The kernel is ignorant about each
front-end.
Don't get me wrong: I can see the benefit of a DLL system, but in order for
this to be useful, I think it should have very restricted access to the LyX
kernel. Otherwise, we end up with a versioning hell and no real benefits.
On the other hand, if we have a fixed interface that is more or less cut in
stone, we could hopefully get people to write extensions to LyX just like
people are doing with the Gimp.
Yes, a restricted interface might make some things impossible to solve from a
DLL. I say that's just too bad.
Greets,
Asger
