Re: Appreciation / Financial support

[David Kastrup]

Joseph Rushton Wakeling <address@hidden> writes:

> On 03/06/12 17:44, David Kastrup wrote:
>> I don't want to remove "as much C++ as possible".  That's about as
>> useful as to remove "as much C as possible" from Emacs.  The point is to
>> consider C++ as the building language for primitives, and tie together
>> the primitives in Scheme.
>
> OK, I misinterpreted your remarks somewhat.  I had read them as
> meaning that (besides re-architecting things so that control flow
> etc. was organized from within Scheme) you wanted to strip out the
> object-oriented side of things and move that over to Scheme, so that
> what was currently C++ would be pared back to being fairly pure C.

Well, the code written in C++ needs to stay manageable as well.  If you
take a look at Goops, you have considerable leeway for adding a Scheme
OO layer modeled along an existing C++ layer.

As I said, I am going through the context/property system, and I don't
intend to change the C++ code using it significantly (well, there will
be a number of macros redefined and obviously things like
context-property.cc and other stuff _implementing_ those interfaces are
bound to go).  But there are things like a "let's implement the Ambitus
engraver as an example in Scheme" project that are sort of an academic
exercise because of hand-cranking a lot of stuff.  And there are a few
examples in snippets and/or regtests that actually use Goops, and they
are ad-hoc-ing some artificial and arbitrary structures together that
make understanding matters harder for the average reader.

If the context/property system has a _natural_ Goops/Scheme interface,
then you have an object oriented _framework_ you can get into.  Doing a
full-featured engraver in Scheme, including interfaces, grobs, mobs,
event-classes, whatever, is then just an exercise of following existing
practice and using existing structures and mechanisms.  You don't need
to make it all up.  Learning how to _use_ stuff is orders of magnitude
easier than learning how to _invent_ stuff.

Most importantly: you don't need to make design decisions.

-- 
David Kastrup