gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: in-tree pristines fatally wounded (merge-fest e


From: David Allouche
Subject: Re: [Gnu-arch-users] Re: in-tree pristines fatally wounded (merge-fest etc)
Date: Thu, 4 Dec 2003 11:47:02 +0100
User-agent: Mutt/1.5.4i

On Thu, Dec 04, 2003 at 10:01:05AM +0900, Stephen J. Turnbull wrote:
> >>>>> "Samuel" == Samuel A Falvo, <Samuel> writes:
> 
>     Samuel> I haven't been following this thread in depth, so forgive
>     Samuel> me if I'm way off base.  But perhaps using some Scheme
>     Samuel> interpreter like Guile or pika would come in handy here.
> 
> This is exactly what itla is supposed to be about.
> 
> However, if you look at the code for the tla driver program, what
> you'll see is a command interpreter that does basically what you
> proceed to suggest, except for providing control structures for
> looping and conditional execution of commands.  And of course it's
> less flexible because the searching for libraries is done at build
> time.
> 
>     Samuel> This way, it'd be very easy to extend tla's built-in
>     Samuel> command-set just by dropping in Scheme files.
> 
> Right.  But willy-nilly extension is exactly what people who want to
> create other language bindings (for example) want to avoid.

I'll medidate more on that issue in the future.

> The flip side of that problem is that if what is later judged to be
> core functionality is implemented in Scheme in a Scheme-ish way,
> people creating (eg) Python bindings will have to embed the Scheme
> interpreter in their binding module.  Ugh.

Unless you care about the bloat, I do not think that is really going to
be a big problem as long as there is a unified API to bind with. As long
as the core defines single link points for initialization and cleanup, a
well defined set of data structures and concepts and a consistent
calling convention, the way functionality is implemented is mostly
irrelevant.

The bottom line of course is that since C/C++ is the esperanto of
language binding, the API should be usable in that language.

-- 
                                                            -- ddaa




reply via email to

[Prev in Thread] Current Thread [Next in Thread]