commit 656934b6315834177fdb8e0bfee7d022af19cd32 parent df025a61536c61d2c5e630456ff366a66a9c93bb Author: paul <paul@hacky> Date: Tue Sep 22 13:23:52 2015 blah specs blah Diffstat: doc/OVERVIEW | 8 +++---- doc/SPECIFICATION | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/doc/OVERVIEW b/doc/OVERVIEW @@ -1,4 +1,4 @@ - Python-like Interpreted Language Proposal + Interpreted Language Proposal by Paul Longtine (paul@nanner.co) @@ -8,11 +8,11 @@ INTRODUCTION Python and along with that, I learned a lot about software development and programming concepts. Python built a bridge between ideas and reality when learning programming concepts because of the ease of prototyping ideas and -architectures. Going from python to a language where implementing ideas takes +architectures. Going from python to a language where implementing ideas takes much more time and effort is a big wall in my growth as a programmer. The main issue with this wall is that most ideas I came up with needed much more thought if the idea was even worth the effort. Why not take the knowledge I learned in -and re-create my own version of a Python-like interpreted language? And, because +and re-create my own version of a Python-like interpreted language? And because of that thought I wrote this paragraph explaining my reasoning. GOALS @@ -58,7 +58,7 @@ PLAN +-----------------+-----------------------------------+------+ |1st week: | Finish this document. |(*) | +-----------------+-----------------------------------+------+ - |2nd week: | Finish SPECIFICATION document |( ) | + |2nd week: | Outline SPECIFICATION document |( ) | +-----------------+-----------------------------------+------+ |3rd-6th week: | Finish VM/rudimentary interpreter |( ) | +-----------------+-----------------------------------+------+ diff --git a/doc/SPECIFICATION b/doc/SPECIFICATION @@ -0,0 +1,64 @@ + Detailed Specification for + Various Componets + + Paul Longtine (paul@nanner.co) + +OVERVIEW + This language will look and feel like any other normal, ordinary language. +The goal is not to innovate, but to see if _I_ can. This is a personal refuge +before my inevitable contributions to large group projects where individuals +are deemed inferior. + + SYNTAX + #TO BE DETERMINED# + + TYPES + Providing basic types, such as: + * integer + * float + * character + * boolean + Will be elaborated on as thoughts progress. + +STACK MACHINE + + +LEXICAL ANALYSIS + + Going from code to bytecode is what this section is all about. First off an +abstract notation for the code will be broken down into a binary tree as so: + + <node> + /\ + / \ + / \ + <arg> <next> + + <node> can be an argument of its parent node, or the next instruction. +Instruction nodes are nodes that will produce an instruction, or multiple based +on the bytecode interpretation of its function. For example, this line of code: + + int x = 3 + + would translate into: + def + /\ + / \ + / \ + / \ + / \ + int set + /\ /\ + / \ / \ + null 'x' 'x' null + /\ + / \ + null 3 + + The various instruction nodes are as follows: + + * def <type> <name> + - Define a named space in memory with the type specified + - See the 'TYPES' section under 'OVERVIEW' + * set <name> <value> + - Set a named space in memory with value specified
