let me extend on this. [Re: looking for interpreter ...]

[Ozan Yigit]

ajb at miles.WPI.EDU (Arthur J. Butler) writes:

>hi.  i am looking for advice and/or suggestions on an interpreter or
>macro language facility which i plan on adding to my application. 

Here are some selections/suggestions of extension languages you can freely
(depending on your meaning of the term) use, reuse (by ripping it out of
its original application), hack, imitate, munge, adapt and do whatever
else necessary to make your application stand-out, and gain instant fame. ;-)

In no particular order [and from memory, sorry about omissions]:

	o Ousterhout's TCL. This is a well thought-out simple, embeddable
	  command language with one data type: strings. It seems to
	  interface and work well.

	o Guido's PYTHON looks very interesting, and also seems to be
	  developed for extension or standalone uses. It comes with the
	  appropriate hooks for interfacing.

	o GnuEmacs Elisp. If you can rip this out of its original
	  application, it may actually be useful elsewhere.

	o Xlisp (earlier versions PD). Instead of breaking your nails
	  trying to rip-out elisp, you may use this one instead. AutoCad uses it,
	  and so does Winterp. You can study the latter to learn more
	  about using xlisp as an extension language.

	o gwm (generic window manager) and crisp (a brief clone) has
	  lisp-ish (read: lotsa parens) extension languages, the former is
	  called wool, and looks better thought-out than the latter. Both
	  will take some ripping effort.

	o There are Scheme interpreters you can use for extension purposes.
	  ELK is a well-known one specially designed for the task, but
	  there are other interpreters around as well, so you have a
	  choice.  The positive thing about using scheme is that this is
	  not just another (yawn) extension language.. It is a very nice
	  language with simple syntax and powerful semantics, has been
	  around since mid-seventies, It has several excellent books on
	  it, has an IEEE standard, and you can be sure it won't take 300
	  pages to explain.

	o There are C (subset) interpreters. Why not? You may choose to
	  use a language that most people actually know something about,
	  for a change.  Two of these were published in DrDobb's journal,
	  another one in the appendix of "Software Engineering in C", and
	  yet another one is part of UPS, an X-oriented debugging program
	  that is freely distributed.

	o Betz publised another simple object-oriented extension language in
	  Byte, DEC. 1988 (I think). Look for a Byte source archive for that
	  month. It is a byte-code-compiler/vm combination that looks easy
	  to extend and modify, and may be useful for your needs.

	o There is zsh, Rayan's zmailer extension language that is actually
	  an implementation of sh with list processing and database access
	  enhancements. Actually, you probably could pick some of the
	  simpler, more comprehensible shells floating about, and adapt as
	  an extension language. The recently posted "rc" (plan-9 shell)
	  clone, for example, or a version of pd ksh could be useful.

	o Well, there is always the well-loved awk, (free versions being
	  mawk or gawk) which may be somewhat easier to adapt as an
	  extension language than its larger distant-relative with warts.

	o Long time ago, an ealier version of ICON was adapted as an
	  extension language for Gosling's Emacs. I don't know if one can
	  still perform this trick. ICON has grown somewhat.

	o If you are an old-timer, there are at least two versions of TECO
	  in C I know of. :-)

	o You can always get more radical, and use Little SmallTalk (budd)
	  as an extension language. Objects, classes, inheritence, methods,
	  all the good things are there. Another possibility is to use one
	  of the free PostScript interpreters (such as Crispin Goswell's)
	  for this purpose. I know at least one person who wanted to use
	  it as an extension language for his editor, and we all know of a
	  small computer company that uses it as a basis for an extensible
	  windowing system. ;-)

	o Get Samuel Kamin's "Programming languages: An Interpreter-Based
	  Approach". There are small interpreters in that book for APL, CLU,
	  SASL, LISP, SCHEME, SMALLTALK and PROLOG, and all with lisp-ish
	  syntax. It is not too hard to adapt one of those as an extension
	  language. [the book is excellent. Get it anyway.]

	o You can always use one of two (that I know of) LOGO implementations
	  as an extension language, and claim that even a child can program
	  your application. ;-). Actually, logo is a much better language than
	  most of those crufty extension (?) languages some hackers come up with,
	  but it usually takes a small kid to figure that out.


I can probably list another dozen or more in a good day. There are counless
interpreters our there for various known or better-not-known languages you
can pick up and use for extending your application. 

> are
>there common languages which are used to add macro facilities to
>applications?
 
Why, who would ever gain anything if there was anything common about macro
or extension languages? But I would say syntax-less (lisp-ish) languages
are probably more popular, and the most common thing about them is the
Cambridge Polish notation, plus some commonplace control syntax. I think
Scheme is the best choice amongst them, but I am biased. ;-)


>in the worst case i can develop my own language using
>lex / yacc but why reinvent the wheel.

Yes, indeed. I wish more people could take the time to ask that very
question. [sigh]

>thanks.

No problem.

oz
---
In seeking the unattainable, simplicity  |  Internet: oz at nexus.yorku.ca
only gets in the way. -- Alan J. Perlis  |  Uucp: utai/utzoo!yunexus!oz