[Top][All Lists]
[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: |
Pierce T.Wetter III |
Subject: |
Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to") |
Date: |
Fri, 2 Jul 2004 11:49:18 -0700 |
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.
You don't understand _quite_ correctly, mostly I think because I
haven't managed to articulate something very well.
Well, it could just be a lack of caffeine on my part...this developer
conference is sadly lacking in dead animals and expresso.
[ points about scheme/furth omitted]
It's sort of like I can commit to a Furth VM without precluding
what the high-level language tools in arch look like beyond that.
So, that's what I'm doing.
(I have some ideas about specific languages to use in various places
but nothing _quite_ worth trying to write an essay about yet. Code
first.)
Ok, here's what I haven't articulated well.
My thinking process for evaluating things is something like this:
1. Produce general rule
2. Apply general rule to specific case
3. Test
4. If rule doesn't work, go back to step one.
So in all of this, in the back of my mind, I have the specific case
in mind of a
submit rule. I would picture this submit rule as doing the following
tasks:
a. Make one or more command line calls.
b. Check the results of those command line calls, which often
involves parsing
text.
c. Make decisions.
d. Send emails, write log messages, store entries in a database,
whatever.
e. return result
Now looking at the definition of furth, I know how to do c and e since
that's basic language stuff.
a, b, d are undefined as part of the interpreter, yet to me, they are
the real challenge in writing a submit rule. So it makes it hard to see
if furth makes sense.
Putting the topic of furth aside, let me illustrate how I would
choose between
shell scripting, Python and Perl, since I often use all of those
languages at work.
That will in turn illustrate how I'm looking at furth.
If the task doesn't make any decisions, I would probably use a shell
script. As soon as I have to make one decision, I would use Python or
Perl, because "eval" is just, lame.
I prefer Perl for just making some command line calls, because
Python forces me to use the system call, while in Perl I can use
backticks. I suppose that:
os.system("ps cax")
and
`ps cax`
Are functionally equivalent, but they don't "feel" that way, and I
find the Perl version easier to read. Similarly, if I have to look at
the output I prefer Perl, while:
lines=os.system("ps cax").readlines()
and
$lines=`ps cax`
are pretty much the same, again they don't feel that way, because:
$lines=`ps cax`
`/usr/bin/mail` if not ($lines =~ /mail/);
seems more obvious to me than:
mailcheck=re.compile("mail")
lines=os.system("ps cax").readlines()
for line in lines:
etc.
I suppose this is because its all "running commands" kind of stuff,
so I'm really thinking of something like:
ps cax | grep "mail"
So why would I ever use Python then? Well in part d where I'm doing
some other sort of process where I need to hook into some other library
to send an email, or record an entry in a database, I find the Python
libraries clearer and easier to use then Perl. I also
prefer Python above a certain complexity level.
So I like Perl when I'm banging on text files, not so much when I'm
doing
procedural programming, because Python has so much better structures
for that.
I like shell scripts when they don't have any language constructs,
because I think
that they're all terrible as a programming language.
Ok, now lets apply my standard evaluation to furth...
Except I can't. I have details about the VM, but not enough information
to see how some other language might execute commands, collect the
results
of those commands, etc. So as a top-down designer, I don't have enough
information to evaluate furth.
Then the question is whether it make sense to use scheme in config
files...
Often not, I suspect. The next question is whether it makes sense to
use a Schemish-VM to interpret any tiny languages that do show up
in arch. I think: "yes".
Well, you're a bottom-up designer, I'm a top-down designer.
Of my three typical "duct-tape" languages, Perl, Python, and shell
scripts, none of them are particularly elegant, but they're quite
excellent at doing the job. From the top level point of view, if I had
to choose a language for a submit rule at this point I would ask myself
two questions:
1. Is it necessary to even make the choice? That is, will rules be
used continuously enough during the execution of a large tree that
the overhead of just making a system() call to a shell/Python/Perl/C
program will be too much? If they're only used once per checkin,
then
the system() call would be find. If they're used once per file, then
we would need something embedded.
2. Is it really necessary to have my own language for this sort of
glue, especially since a submit rule may just consist of calling
make?
If 1 is true, I would say no new language for 2. Instead, if I had to
embed an interpreter I'd lead towards Perl or Python since they have
a long history as glue languages. With them I'd get the benefit of:
1. External libraries for sending emails, talking to databases. The
whole point of this sort of thing is that we're giving people
the ability to extend tla in weird ways, so they're going to want
to do weird things.
2. Easy parsing & processing of text. It doesn't matter what the
runtime size of the interpreter is if it doesn't have an RE
engine and it doesn't handle strings well.
However, I'm sure that its possible that someone could dazzle me with
a simple, very small "language", which they could then implement in
furth, and I'd be wrong. I just haven't seen it yet. Perhaps this
language would look something like:
#define build_check procedure
build_check = `make`;
#define no_naughty_words procedure
no_naughty_words = `grep uck $1`;
#define email sending script
send_email = `sendmailtomaintainer.sh`
#define submit_rule, which calls the other three
submit_rule = build_check() && no_naughty_words() && send_email();
So we're back to a config file language again, but that doesn't bother
me
so much because its kind of a "one page" language. Of course, the hard
stuff
I wanted to do in this language (send an email) I've just punted off to
a shell
script, so furth didn't buy me anything, because it could still be
calling a
shell script for each file. Of course, I'm not a language designer, so
that's not surprising.
So back to you:
So it's not (from the arch perspective) that I want to compile Pika
to Furth VM. Rather, it's that:
a) we need some high-level language tools in arch
b) all such language can reasonably be written to translate
into Furth
c) Furth is practical in the same way that arch is practical:
relatively small and simple.
It's sort of like I can commit to a Furth VM without precluding
what the high-level language tools in arch look like beyond that.
So, that's what I'm doing.
(I have some ideas about specific languages to use in various places
but nothing _quite_ worth trying to write an essay about yet. Code
first.)
ok, then my point ultimately starts at a:
a) we need some high-level language tools in arch
1) Those high-level language tools need to make system() calls,
parse
the results in certain cases.
2) system() calls may end up dominating such that it makes more
sense
to mooch from some existing language. At that point, perhaps
we could
replace all of those tools with system() and let people
program in .sh,
.pl, .py, .tcl, or even C as they wish.
Pierce
P.S.
Random brainstorm:
Perhaps tla could just launch a task, send "start" on a line, then send
commands to execute, read the results, then send "quit" to quit. Sort
of a client server model, where tla is the client sending requests to
the rules program.
We could provide simple libraries for perl, python and C such that
writing these could be trivial.
- Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to"), (continued)
Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to"), Tom Lord, 2004/07/01
Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to"), Scott Parish, 2004/07/01
Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to"), Pierce T.Wetter III, 2004/07/01
Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to"), Robert Collins, 2004/07/02
Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to"), Colin Walters, 2004/07/02
Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to"), Colin Walters, 2004/07/02