This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ wrapping


On Thu, Apr 15, 2004 at 08:36:49PM +0100, Brian Gough wrote:
> is too horrible, as demonstrated by the code flying past.

Beauty is in the eye of the beholder ... 

All I wanted to suggest was that the GUI world has long struggled 
with the problem of "how do I call method X on object Y when I don't
know what X & Y are/do.', and have come up with workable if not
always elegant solutions.  These were needed because there simply
wasn't any other way of doing things.

Since GSL 'already works' in C, it doesn't have to be driven in this way.
So I guess the whole point of having a GSL C++ is to have an *elegant*
GSL C++, since one has the luxury of putting off the solution until
one can do it really really well...

> For numerical code one needs to be able to write a single high-level
> description of the algorithm, and then do code-generation to
> specialise it.  This requires a powerful macro facility to enable
> transformations before compilation, which is really only found in
> Lisp.  I don't consider C++ templates to be adequate, they are also a
> hack, and are not programmable in the same way as lisp macros.

Well, there's at least one if not several scheme-to-C compilers.
One of them, I forget the name, produced actually rather nice, 
human-readable C code (which looked like it would run quickly).

In scheme, the ability to run the same algorithm on any type
is called 'closure'. I haven't the vaguest idea of how one could 
take your type-any aka 'closure' scheme/lisp code and generate 
c/c++ bindings that would work on 'any' type.

--linas



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]