Re: [Gnu-arch-users] Nit

[Tom Lord]

    > From: Colin Walters <address@hidden>

    > On Sun, 2003-10-19 at 00:55, Tom Lord wrote:
    > >     > From: Colin Walters <address@hidden>

    > >     > Here's a good one,
    > >     > [...]
    > >     > But it's not
    > >     > an argument for embedding a language inside tla.

    > > As far as I am aware, nobody is arguing to do so.

    > Ok.  I am very relieved then.  That was my major point of concern.
    > Thank you for clarifying this.

Oh geeze!  That's what the discussion became confused over?!  That
makes perfect sense.  I even noticed you argue against doing that
previously and just thought (to myself) "Ok, we all agree about
that..." but then why worry about making libarch binding friendly?

Sure, if I were planning on screwing up tla that way then encouraging
me to do so by making libarch "binding friendly" would at least keep
most crap code out of libarch in the process. :-)

    > > I've previously mentioned may reasons why it is better to layer on tla
    > > rather than libarch -- is it really necessary to repeat them?

    > If this is all we're debating, then good.  

That's my reaction too.

    > Because it doesn't particularly matter whether you think wrapper
    > libraries should fork/exec tla or be in the same process.  Until
    > libarch is cleaned up, fork/exec is the only option.  But
    > eventually someone will do the work of converting libarch to
    > cleanly pass back errors and such, and this will enable the
    > second approach, which I know to be much easier and better.

Maybe.  I think it's less economic, anyway.  Not trying to do that
keeps the cost of making changes to libarch much lower and systems
built using the multi-process technique are at least potentially more
fault tolerant.


    > But implementing it wouldn't hurt the first approach at all (and
    > would actually improve the code, thus making things more
    > reliable overall).  So really we have nothing to argue about.

I'm relieved that we got to the bottom of what the real issue was --
and that it turned out to be a non-issue.

-t