9fans archive / 2001 / 04 / 716 /    prev next

From: "kazumi iwane" <kiwane@dre...>
Subject: [9fans] little languages and file servers
Date: Sun, 29 Apr 2001 19:26:12 +0900

Hello 9fans,

Recent threads on programming languages got me
started on this. Hope this is more plan9 specific.

I think plan9 is a heaven for creators of little
languages. UTF-8 support is for free. Services
traditionally only available via system calls are now
gotten just by reading/writing a piece of text from/to
files (it obliterates most of the needs for module
loading hassles found in perl or python, or at least
cluttering of reserved words, I think).

It also presents a unique challenge to the writers,
though; should a capability in a file server or in your
language? A "division-of-labour" issue. For example...

1) textual control over graphics

When I first saw Tk, back in early 90's, it was a
revelation. When I learned that inferno had its
graphics system integrated with Tk-style interface,
I thought, "hey, why not on plan9, too?"

Note that I didn't say Tcl. Tcl is a lot worse than
csh when it comes to decent programming. Thank
goodness we have rc(1).

We now have control(2), which is a lot like Tk's
"widgets," and a good interpretive language, rc(1).
Could we benefit from "rc-control" combination
after the style of Tcl-Tk (something analogous to
wksh)? Or should we go for a file-server approach,
a wrapper to the draw(3) device that presents text-
based, higher level constructs to clients, even to
good old tools like awk(1)?

2) plumber

I think plumber(4) is the best idea since unix's
invention of pipe(2). But when I look at the rules
file, I feel uneasy. It claims to be language-driven,
but it looks to me like yet another configuration file
syntax. I expected something more in the line of
pattern-action language like awk.

Is it a good idea to distill the language part of
plumber out of it and let a general purpose language
interpreter assume the responsibility, while keeping
the file server aspect to the plumber itself? There
may be some security issues I'm overlooking here.

- kazumi