🚀 go-pugleaf

In article <17132@helios.TAMU.EDU>, byron@donald.tamu.edu (Byron Rakitzis) writes:
> In article <541@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
     .....

> Your comment is perfectly valid. So far, I have received numerous messages
> with suggestions for (already existing) alternatives to perl. Most people
> named TCL, Python, Icon (as above) but I have also heard that people use
> Scheme. This is the first I've heard of Lakota. Is it available for anonymous
> ftp?

Sorry, no, you'll need to sign a license.  However write me at the address
below or give me an address to send it to, and I'll get a copy to you.

> What it boils down to is this: whether or not ap is a lot of work, I fear it
> is going to get written sometime in the near future. When I re-implemented
> rc, I thought I came close to what I wanted as my command interpreter, but
> now that I am aware of its shortcomings, I want to try to improve on the
> rc model. I have at least several goals in mind:

Also look at Scheme and Rexx as others have noted.  Elsewhere David Gudeman
has deprecated Perl and Python as reinventing an unneeded wheel (see his
article in comp.unix.shell).  I think David is wrong, but that is a matter
for another article.  He argues that refinement of existing languages is
the right way to go.  There is something to this; the problem, however, is
that this approach doesn't lead to fundamental improvements in language
design.  Taking an existing language and hacking at it (which is what most
people do when they tackle creating a language) is unprofitable -- a
language is more than a sum of pieces.  Moreover the "improved" language
is more than likely to be a dead end.


> 1) I want the core command interpreter to be independent of any particular
> application.

By this I gather you mean application area.

> 2) I want it to be easy to add modules so that the core command interpreter
> may be grown into, say, an ap.

This is an interesting topic.  The approach in Lakota is to have a core
library (the interpreter and the basic commands) and an extension facility
to add new commands and functions.  I believe TCL does the same thing.
And, of course, one can provide libraries of predefined scripts.  It
occurs to me that this is a somewhat parochial approach -- that there
may be a more powerful and general way to deal with language extension.
I would be interested in seeing comments on this topic.

> 3) I want the syntax of the language to be elegant. This sounds like a tall
> order, but what I'm doing is ruling out languages like Scheme; I just cannot
> deal with the Lots of Irrelevant and Stupid Parentheses. Also, I'm afraid that
> Python does not quite fit the bill either. Syntax that is whitespace dependent
> just feels "wrong". I know, I tried using Python for a while.

I haven't used Python, so I don't know what the whitespace dependencies are.
I'm not sure what "elegance" is -- I would take it as a combination of
conciseness, coherence, simplicity, and power.  I would rate Scheme as
elegant.  I would also rate Lakota as elegant, but I'm prejudiced.  It
does use indentation for grouping.

> Let me state here that I have not ruled out any of the other interpreters yet.
> I still want to see if, say, TCL cannot satisfy my needs. Also, let me state
> right away that (1)-(4) contain strong doses of religion; please don't take my
> comments as flames. However, if you disagree, I'm always willing to argue. :-)

Understood.  One way to approach languages is in terms of the needs that
they fulfill.  This, in no particular order, is a list of needs that Lakota
was designed to meet.

(a)	The general objective was to provide a language in which it was
	convenient and feasible to write moderately large-scale administrative
	scripts.

(b)	It should be possible to embed the interpreter in programs written
	in other languages and have it available as a service utility.

(c)	It should be possible to write programs which which are a mixture
	of 3GL compiled code and interpreted routines.

(d)	The code should be readable and maintainable by someone with a
	modest exposure to the language.

(e)	As much as possible, scripts should be portable across OS's.

(f)	OS commands (or commands in any other underlying target language)
	should be directly executable.

(g)	Standard structured programming concepts should be natural.

(h)	It should be able to handle string and list manipulation.

(i)	The language should have the functionality of standard UNIX
	tools such as sed, awk, and find.

(j)	There should not be any arbitrary size restrictions.

-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.