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

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

Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")


From: Jan Hudec
Subject: Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")
Date: Wed, 30 Jun 2004 15:52:51 +0200
User-agent: Mutt/1.5.6+20040523i

On Wed, Jun 30, 2004 at 09:32:23 -0400, Aaron Bentley wrote:
> Jan Hudec wrote:
> >>My question was more to know why Arch need a so specific embedded
> >>langage. But i should wait for your third roadmap !
> >
> >
> >For one thing arch needs SOME embeded language. The reason is, if
> >nothing else, the number of wrapper and scripts around tla that exist.
> >The kind of stuff they do is mostly glueing primitive commands, which is
> >too cumbersome to do in C. 
> 
> Actually, tla includes some infrastructure for calling user-level 
> commands-- "update" actually calls the "replay" or "apply-delta" user 
> commands.  So it may not be as cumbersome as you think.

No, it's not that cumbersome there. But you need to recompile each time,
which makes it harder -- and less likely -- for someone to put up
a simple enhancement while hacking something else. That's what scripting
languages are nice. That's why shell wrappers around tla exist. It is
better if the scripting support is integrated.

> >So the idea is, that tla should have the
> >primitive commands in C, cleaned up, simple and flexible. And a simple
> >interpreter to build a user friendly interface on top of them.
> 
> The plan is *also* to make libtla into a real library, which can then 
> have bindings for various languages, scripting or otherwise.  So Furth's 
> not necessary for the purpose of creating friendly interfaces.

Yes, that's an even nicer plan.

> But there's a lot of sense in mixed-language programming; using a 
> scripting language for the high-level stuff, and using C for the 
> low-level stuff.  I just don't know whether the advantages of using 
> Furth instead of an existing language will outweigh the disadvantages that
> - No one knows Furth
> - There are no Furth libraries or GPLed code that we can use
> - Furth will take time and effort to develop

Personaly I believe it won't. Partly because I don't see any advantages
in Furth. The only advantage I see is, that Tom wants to write it
anyway, as a base for pika. And now that parrot promisses to run scheme
pretty fast, I wonder how big success pika will be.

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

Attachment: signature.asc
Description: Digital signature


reply via email to

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