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

[Pierce T.Wetter III]

> >   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.