[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

  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
  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")


  `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()


  $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:

    lines=os.system("ps cax").readlines()
    for line in lines:

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

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 = ``
 #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

  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.



 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.

reply via email to

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