Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.lang.scheme
Subject: Re: extension languages can be darn small, yet still powerfull
Message-ID: <NWQ5K6F@xds13.ferranti.com>
Date: 7 Sep 90 18:44:01 GMT
References: <9008220403.AA03028@schizo> <S=O5I9F@xds13.ferranti.com> <176@smds.UUCP>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 32

In article <176@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
> > One thing you frequently want to do in extension languages is manipulate
> > code as data, to do things like saving definitions you're working on.
> > This is easy in lisp like languages (like lisp itself, or scheme, or
> > TCL) but a pain in algol-like languages (like REXX).

> I don't see procedural command language format as being a major
> problem.

Not at all. After all, Lisp is a procedural language.

> The things that we dispensed with are types (everything
> is a string) and in-fix operators (we use lisp format functions).

That's the bottom line. Sounds like what you have is pretty close to
TCL. Have you looked at it? It looks like this:

proc key_'^K' {} {
	browse message {Edit key }
	set key [get key]
	set func key_[get keyname $key]
	set file [get env HOME]/.function
	if { [length [info procs $func] ] != 0 } {
		set def [list proc $func {} [info body $func]]
	} else {
		set def [list proc $func {} { ... }]
	}
	print $def\n $file
	browse message !vi $file
	browse shell [concat vi $file]
	source $file
}
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com