xtbjh@levels.sait.edu.au (behoffski) (05/10/91)
In article <5764@mindlink.bc.ca>, Nick_Janow@mindlink.bc.ca (Nick Janow) writes: > I suggest that you read "Thinking Forth" by Leo Brodie. Forth's postfix > notation makes adverbs and adjectives (natural language modifying words) easy > to implement. FORTH also allows applications to use near-natural language. > For instance, LIGHT BLUE BOX might add a light blue box to your screen. LEFT > QUICKLY MOVE DOWN SLOWLY MOVE might control a robot arm. > > Take a look at Forth; it's a good language for writing other languages. Perhaps not surprisingly, some of my ideas can be traced back to PostScript, which can be traced back to Forth. You will find that assembly language is often rich in adjectives and adverbs -- my favourite is the Zilog mnemonics for the Z80 .vs. the Intel mnemonics -- but this was abandoned when algebra was chosen as the base. Thanks to ideas provided by a superb software/hardware engineer, David Knight, I've also considered the relationship of language design to circuit diagrams. The verb "add" (e.g. in PostScript) can be contrasted to a single inverter in a package -- it costs heaps to use, but is convenient. When you want some performance, then you combine the primitive in a larger component (e.g. rendering fonts can be compared to a VLSI circuit). I'm not that familiar with Forth, so: is there any special reason that your examples use upper case? cheers, behoffski -- Brenton Hoff (behoffski) | Senior Software Engineer | My opinions are mine xtbjh@Levels.UniSA.edu.au | AWA Transponder | (and they're weird).
Nick_Janow@mindlink.bc.ca (Nick Janow) (05/10/91)
> I'm not that familiar with Forth, so: is there any special reason that your > examples use upper case? No, just a way of keeping them separate from the rest of the sentence. It's a habit from this local bbs: we always use upper case when referring to system commands (like INCLUDing part of a message). In Forth, I use upper and lower case as I see fit. Since there are no absolute rules about it, people develop personal styles, so you'll see some people using upper case for core commands and lower case for others, and other people using the opposite. We (the Forth community) are presently working on an ANS standard Forth. I don't think readability has been addressed. I'll bring the issue up in the Forth group; it might be worthwhile adding a standard writing style. Of course, there'd probably be a very loud outcry at the thought of any restrictions on personal coding style. :) In case you haven't looked at "Thinking Forth" yet because you don't know Forth, take a look anyways. It's more a programming philosophy book than a language reference. > The parameters handed through the interface, and the results and return > control point, can be declared in a fixed piece of RAM. This saves the cost > of continually grabbing and releasing space off of stacks. There are several high-speed "stack machines" available now (Harris RTX series, SC32, a couple from Chuck Moore {designer of Forth}). These chips are optimized to run Forth and have hardware stacks, multiple references (can access both stacks and memory simultaneously) and have one-cycle subroutine call with zero-cycle return. These are _fast_ chips. You might want to look into them for your adjective/adverb language.
xtbjh@levels.sait.edu.au (behoffski) (05/14/91)
In article <5816@mindlink.bc.ca>, Nick_Janow@mindlink.bc.ca (Nick Janow) writes: > There are several high-speed "stack machines" available now (Harris RTX series, > SC32, a couple from Chuck Moore {designer of Forth}). These chips are > optimized to run Forth and have hardware stacks, multiple references (can > access both stacks and memory simultaneously) and have one-cycle subroutine > call with zero-cycle return. These are _fast_ chips. You might want to look > into them for your adjective/adverb language. One of the great advances in PostScript (and I presume Forth) is the separation of the control stack (e.g. return addresses) from the operand stack. This allows the structure of the control to be well separated from the structure of the data. I would attempt to design the same separation into any implementation of Languish. > ... FORTH also allows applications to use near-natural language. > For instance, LIGHT BLUE BOX might add a light blue box to your screen. LEFT > QUICKLY MOVE DOWN SLOWLY MOVE might control a robot arm. Your usage of adverbs here is what I would hope to achieve with Languish, but LIGHT BLUE BOX does not seem to capture adjectives well -- you have really given three verbs. There is the verb DRAW implicit in your example. I want adjectives to work on groups, e.g. "light blue boxes slowly delete". While Forth might be a suitable starting point, I believe the following details can only be achieved via a smarter language: - the individual tokens can be ambiguous (light car .vs. light blue) but the entire request must resolve all ambiguity, and - the language can choose groups of tokens from the request where optimised algorithms have been given for those groups. Long term, I see that given a Languish kernel (the code to maintain the active language elements and to parcel out requests to individual machines) plus a set of standard machines (integer, trees, stacks, hash tables or whatever), then portability of systems built on top of this interface should be extremely high. There will hopefully be a range of implemetations of each interface. Each implementation provides a different set of tradeoffs between typical resources (CPU, memory, reliability, capacity). The implementor can then choose between the implementations at any stage of construction of the design. -- Brenton Hoff (behoffski) | Senior Software Engineer | My opinions are mine xtbjh@Levels.UniSA.edu.au | AWA Transponder | (and they're weird).