Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!crackers!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.lang.scheme Subject: Re: extension languages can be darn small, yet still powerfull Summary: What are the criteria for manipulating code as data Message-ID: <176@smds.UUCP> Date: 7 Sep 90 05:46:51 GMT References: <9008220403.AA03028@schizo> Organization: SMDS Inc., Concord, MA Lines: 33 In article , peter@ficc.ferranti.com (Peter da Silva) 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). Currently we are working on an extension language so this topic is dear to my heart. I would be very interested in seeing a more complete elucidation of your comment. As far as I can see at the moment the criteria for *easy* manipulation of code as data are: (a) An interpreted language (b) The ability to execute "data" as a series of commands in the form of a string. (c) The ability to build strings without cumbersome quoting and character escape problems. (d) Minimal syntax restrictions (related to (c)). I don't see procedural command language format as being a major problem. The things that we dispensed with are types (everything is a string) and in-fix operators (we use lisp format functions). We also have lists, which may be cheating :-). It seems to me that types, in fix operators, and function format in the form f(arg1,arg2) rather than (f arg1 arg2) induce the problems. -- 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.