Pragmatic Core Language definition
"Aryeh M. Friedman" <[email protected]> Thu, 7 Aug 2003 12:03:12 -0400 (EDT)
| Newsgroups | gmane.comp.programming.pragmatic |
|---|---|
| Message-ID | <[email protected]> |
Transformational Code: Pragmatic "core" Language (PCL) By Aryeh M. Friedman Document status: Pre-strawman Overview -------- The main purpose of any general purpose computer is to transform a set of inputs into a set of outputs. It it fairly trivial to see _every_ program and/or computer ever made has only one goal which can be expressed as: Input State(s) -----> Internal State(s) -----> Output State(s) Ideally when we as programmers write such a state transform we want to make it as general as possible while at the same efficiently solving specific "problems". Specifically it does not help us to have a set of such transforms that will work, in theory, for all possible binary math operations of it does not, for example, add efficiently. This means we have to finally balance genericality with abstraction. In this context generic is taken to mean it can solve all problems in a well defined problem domain such as addtion and abstract means it can solve multiple problem domains such as all math operations. Different programming "paradigms" lend themselves to the transform of certain subset of the problem domains of all problems and even then only to a certain style of solving these problems. It is highly unlikely that one paradigm will ever solve all problems with equal ease and/or hardship. For this reason it is best to allow certain number of very basic constructs, that are themselves as paradigm "neutral" as possible, be used in an almost mix and match manner to construct the results of current and future paradigms. Pragmatic provides just such a set of building blocks in PCL. The remainder of this document will discuss how to implement these general prinicibles in a general set of structures and other PCL concepts. A small note about terminology is in order here. Even though many of the concepts covered in this document have very familor counter parts in other languages using more "tractional" names I have purposally used some "oddball" termini logy to ensure that the reader/implementer does not bring forward a incomplete and/or incorrect definition of some term. State Machines -------------- Any time a system is at rest it is said to be in a given state. It is theoretically possible to have the "at rest" state of a system actually be in motion. So a fuller definition of a systems state is the current internal "configuration" of the system. In the largest possible sense all systems can be defined as being infinite [1] in terms of the number of possible states they can be in. One of the very first formulations of what a "computer" is was done by Alan Turning in the 1940's. This is a very simple model, too simple to be used in a modern environment, but is still instructive: 1) There is a infinite "tape" of a 1 dimensional stream of data slots 2) The tape can be read one position to the right and one position to the left 3) The "main" machine consists of finite number of possible states that can be in one of the following states: "Right" "Left" "Read" "Write" "Do Nothing" 4) At any given time the machine is said to be in state X and this state determines what action is taken on the tape determined by some other state Y The above is a oversimplification of "infinite" turning machines (ITM) but enough to show that all possible computational operations on all modern computers can be simulated using this model and vice versa. Thus as long we feed the proper tape (program) into the machine and have it start at a well defined beginning state we can get any desired output from any desired input we wish. State Context ------------- While modern computers bare very little resememblence to a ITM they do share a number of striking similarities. The first is their can only exist a certain number of internal states. The second is the presence of a given state or lack there of has no internsic meaning out of the context assigned to it by some external force (the user). Also in order to account for all the possible states a ITM can be in we must allow the "total" state of the ITM to be infinite. Thus all states have the following properties: * They have no context free internsic meaning * Any given state can have an "infinite" number of sub-states For the remainder of this document a specific state will be referred to as a Pstate. PStates come in two main varieties: Lavs and Mstates. Lavs ---- The simplest possible PState is a Lav. A Lav is a single byte value associated with an optional tag. All it does is define the value of some piece of memory. For example to assign the number 10 to tag a we do: a (10) and to use the value 128 as is (no tag) we do: (128) Combining Lavs with Mtates and macros, explained below, any conviable data "type" can be formed. Tags ---- Any pstate can be associated with a tag by doing: tag (...) The tag now acts as a stand in value for the entire Pstate and whenever referenced will include the entire pstate. To reference a tag surround it's name in |'s. Thus we can do a=b=15 as follows: a (15) b (|a|) Mstates ------- A Mstate is any Pstate where a transformation is performed. It has three possible arguments only one of which is required. The first one is the input PState then next is the "sub" mstate to do the transformation on and the final one is the output PState. For example to increment 2 by 1 (i.e. 2+1=3) we do: result (2 incr |result|) Note that it is possible for the output Pstate to refer to the tag for the whole MState. Sets PStates ------------ A PState may contain a set of values in it. For example to define a the set of 5,10,15 we do the following: (5 10 15) Note it is only possible to define sets as Lavs not as MStates. Nested PStates -------------- It is possible to nest pstatements for example a Mstate to add two Lavs can be defined as: ((|a| |b|) add |result|) Macros ------ Macros allow you to define the syntext for any given Pstate to be what ever convention the High Level Language (HLL) implimenter wishs. The basic format of a macro is to encapsulate it within #'s which the first field being the macro syntax and the second field being the associated PState. For example to define a tradtional assignment operation we do: #|a|=|b|#|a| (|b|)# To do the add above we do: #|a|+|b|#((|a| |b|) add |result|)# So now we can do a=2+2 and get the following output code: a ((|a| |b|) add |result|) Code Generation --------------- Code is generated from the above by "splatting" all the assicated nested Pstates into a linear form. For example the above add macro whould bue generated as: mov c,0 add c,a add c,b Programs -------- As mentioned in the overview a program can be viewed as one big MState thus we by definition execute the first encountered MState. If the MState can not be fully evaluated at this time it is pushed onto the unevaluated MState stack and everytime a new MState is evaluated the current top of this stack is popped and an evaluation attempt is made, if it is still not evaluatable then it is pushed back onto the stack. The reason for this method is it allows for compilers to be efficiently written while still allowing intepritation of indivual MStates at run time. Lexical Structure ----------------- Tags: A tag may consist of any character except #. Any purely numeric tag is assumed to identify a specific memory node. Non-macro use PStates: PStates are not allowed outside of macro definitions. HLL Language Construction ------------------------- The PCL platform provides a number of macro-preprocessors so constructing a HLL should be nothing more then defining the language in terms of PCL macros. Atomic MStates -------------- The following atomic MStates are defined: Mstate Input PState Size Output PState Size ------ ----------------- ------------------ Nothing 0 0 Increment 1 1 Decrement 1 1 Jump 1 0 Branch_compare 2 0 Nothing: Does nothing (never terminates) Icnrement: a=a+1 Decrement: a=a-1 Jump: Set current instruction pointer to input Branch_compare: Set current instriction pointer to second input if first input is 0 The PAM backend implimentor is free to support other atomic MStates at there descrition. Notes: 1. This theoretically true of even "single" state systems ------------------------ Yahoo! Groups Sponsor ---------------------~--> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511 http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/W4wwlB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/