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

[Pierce T.Wetter III]

> > The problems I see with Furth, irrespective of the details like RPN 
> > are:
> >
> >    1. No debuggers...
>
> There's not even an interpreter yet, you expect a debugger?

 Well, if the interpreter used was a more common one, it might include 
said beast...

> >    2. No syntax award editing...
> >    3. No test beds for double checking scripts...
>
> Huh?

  Er. No syntax aware editors.

  A test bed would be a program that "emulates" arch but runs inside the
debugger to let you step through complicated scripts.

> >    Is there an O'Reilly book for the language?
>
> Is there an O'Reilly book for Arch's config scripts?

  Someday. :-)

> Better stop
> using it.
>
> You've mentioned your love of Python, but do you think the moment
> Guido first got a running python interpreter he got a publishing
> contract with O'Reilly to ensure there'd be a book for all the new
> developers to use?  If every user held the same O'Reilly book
> prerequisite for languages, Python would never have earned the user
> base it has now.

  I don't know of I "love" Python. I use both Python and Perl for what
I think they were intended to, and not much else. I use Perl for 
processing
text files, and Python for testing my Objective-C code.

  Anyways, if Tom wanted to create his own language, then obviously 
there
wouldn't be an O'Reilly book for it, but I would still support his 
attempt.
In this case, Tom wants to embed a language inside another tool, in the 
same
way that lisp is embedded inside Emacs. That I'm not so sure is a good 
idea
because its one more step away from the user.

 Of course, really, if I now understand correctly, Tom wants to compile 
pika
code into Furth, and use pika code in arch. That's quite different, 
because
its not furth that Tom wants to embed into arch, its scheme.

  Then the question is whether it make sense to use scheme in config 
files...

 Pierce