Toi (programming language): Difference between revisions

Revision as of 06:52, 24 October 2016

Latest revision as of 14:24, 11 April 2025

(38 intermediate revisions by 19 users not shown)

Line 1:

'''ToyToi''' is an imperative, type-sensitive language that provides the basic functionality of a [[programming language]]. The language was designed and developed from the ground-up by Paul Longtine.<ref>{{cite web|url=https://github.com/bannana/language/blob/master/doc/OVERVIEW|title=bannana/language|website=[[GitHub]]|date=17 February 2021|publisher=}}</ref> Written in C, ToyToi was created with the intent to be an educational experience and serves as a learning tool (or toy, hence the name) for those looking to familiarize themselves with the inner-workings of a programming language.<ref>{{cite web|url=https://banna.tech/projects/post/toy_language/|title=banna - useless things|publisher=|access-date=2016-10-23|archive-date=2016-10-24|archive-url=https://web.archive.org/web/20161024151620/https://banna.tech/projects/post/toy_language/|url-status=dead}}</ref>

{{Dead end|date=October 2016}}

'''Toy''' is an imperative, type-sensitive language that provides the basic functionality of a programming language. The language was designed and developed from the ground-up by Paul Longtine.<ref>https://github.com/bannana/language/blob/master/doc/OVERVIEW</ref> Written in C, Toy was created with the intent to be an educational experience and serves as a learning tool (or toy, hence the name) for those looking to familiarize themselves with the inner-workings of a programming language.<ref>https://banna.tech/projects/post/toy_language/</ref>

== Specification<ref>{{cite web|url=https://github.com/bannana/language/blob/master/doc/SPECIFICATION|title=bannana/language|website=[[GitHub]]|date=17 February 2021|publisher=}}</ref><ref>{{Cite web|url=http://dev.nanner.co/language/file/doc/SPECIFICATION.html|title=SPECIFICATION - language - some fools attempt at an interpreted language}}</ref> ==

=== [[Type (computer science)|Types]] ===

0 VOID - Null, no data

1 ADDR - Address type (bytecode)

Line 22 ⟶ 21:

15 G_FIFO - Stack

=== [[Run time (program lifecycle phase)|Runtime]] ===

==== RUNTIMERuntime CONTEXTcontext DEFINITIONdefinition ====

The runtime context keeps track of aan individual threads metadata, such as:

* The operating [[Stack (abstract data type)|stack]]

** The operating stack where current running instructions push/pop to.

*** refer to STACK DEFINITION

* Namespace instance

** Data structure that holds the references to variable containers, also proving the interface for Namespace Levels.

*** refer to NAMESPACE DEFINITION

* ArguementArgument stack

** Arguments to function calls are pushed on to this stack, flushed on call.

*** refer to STACK DEFINITION, FUNCTION DEFINITION

* Program counter

** An interface around bytecode to keep track of traversing line-numbered instructions.

*** refer to PROGRAM COUNTER DEFINITION

This context gives definition to an 'environment' where code is executed.

==== NAMESPACE[[Namespace]] DEFINITIONdefinition ====

A key part to any operational computer language is the notion of a 'Namespace'.

Line 58 ⟶ 57:

* Implicitly move in/out of scopes

The scope arguementargument is a single byte, where the format is as follows:

Namespace|Scope

Line 65 ⟶ 64:

Scopes are handled by referencing to either the Global Scope or the Local Scope.

The Local Scope is denoted by '0' in the scope argument when referring to names,

and this scope is initialized when evaluating any new block of code. When a different block of code is called, a new scope is added as a new Namespace level. Namespace levels act as context switches within function contexts. For example, the local namespace must be 'returned to' if that local namespace context needs to be preserved on return. Pushing 'Namespace levels' ensures that for every ''n'' function calls, you can traverse ''n'' instances of previous namespaces. For example, take this namespace level graphic, where each Level is a namespace instance:

Level 0: Global namespace, LSB == '1'.

Line 77 ⟶ 76:

Level 2: Namespace level, where Local Level is at 2, LSB == '0'.

Global scope names (LSB == 1 in the scope arguementargument) are persistientpersistent through the runtime as they handle all function definitions, objects, and

through the runtime as they handle all function definitions, objects, and

names declared in the global scope. The "Local Level" is at where references

that have a scope arguementargument of '0' refer to when accessing names.

The Namespace arguementargument refers to which Namespace the variable exists in.

When the namespace arguementargument equals 0, the current namespace is referenced.

The global namespace is 1 by default, and any other namespaces must be declared

by using the

==== [[Variable (computer science)|Variable]] definition ====

==== VARIABLE DEFINITION ====

Variables in this definitondefinition provide the following mechanimsmechanisms:

* Provide a distinguishable area of typed data

* Provide a generic container around typed data, to allow for labeling

* Declare a set of fundementalfundamental datatypes, and methods to:

** Allocate the proper space of memory for the given data type,

** Deallocate the space of memory a variables data may take up, and

Line 110 ⟶ 108:

scope in terms of ___location within a given set of scopes. This is what is called

'Ownership'. In a given runtime, variable containers can exist in the following

structures: A stack instance, Bytecode arguementsarguments, and Namespaces

The concept of ownership differentiates variables existing on one or more of the

Line 117 ⟶ 115:

structures.

==== [[Function (computer science)|Function]] definition ====

==== FUNCTION DEFINITION ====

Functions in this virtual machine are a pointer to a set of instructions in a

program with metadata about parameters defined.

==== [[Object (computer science)|Object]] definition ====

==== OBJECT DEFINITION ====

In this paradigm, objects are units that encapsulate a seperateseparate namespace and

collection of methods.

==== BYTECODE[[Bytecode]] SPECspec ====

Bytecode is arranged in the following order:

<nowiki><opcode>, <arg 0>, <arg 1>, <arg 2></nowiki>

Where the <opcode> is a single byte denoting which subroutine to call with the

following arguementsarguments when executed. Different opcodes have different arguementargument

lengths, some having 0 arguementsarguments, and others having 3 arguementsarguments.

'''===== Interpreting Bytecode Instructions''' =====

A bytecode instruction is a single-byte opcode, followed by at maximum 3

arguementsarguments, which can be in the following forms:

* Static (single byte)

* Name (single word)

* Address (depending on runtime state, usually a word)

* Dynamic (size terminated by NULL, followed by (size)*bytes of data)

** i.e. FF FF 00 <nowiki><0xFFFF bytes of data></nowiki>,

** 01 00 <nowiki><0x1 bytes of data></nowiki>,

** 06 00 <nowiki><0x6 bytes of data></nowiki>, etc.

Below is the specification of all the instructions with a short description for

each instruction, and instruction category:

=== [[Opcode]] ===

Keywords:

TOS - 'Top Of Stack' The top element

TBI - 'To be Implemented'

S<nowiki><[variable]></nowiki> - Static ArguementArgument.

N<nowiki><[variable]></nowiki> - Name.

A<nowiki><[variable]></nowiki> - Address ArguementArgument.

D<nowiki><[variable]></nowiki> - Dynamic bytecode arguementargument.

----

Hex | MemnonicMnemonic | arguments - description

----

'''1 -==== Stack manipulation''' ====

These subroutines operate on the current-working stack(1).

----

10 POP S<nowiki><n></nowiki> - pops the stack n times.

11 ROT - rotates top of stack

12 DUP - duplicates the top of the stack

13 ROT_THREE - rotates top three elements of stack

----

'''2 -==== Variable management''' ====

20 DEC S<nowiki><scope></nowiki> S<nowiki><type></nowiki> N - declare variable of type

----

2021 DECLOV S<nowiki><scope> S<type/nowiki> N<ref> - declareloads reference variable ofon to typestack

2122 LOVSTV S<nowiki><scope> N<ref/nowiki>- loadsN reference- variablestores onTOS to stackreference variable

2223 STVCTV S<nowiki><scope></nowiki> N D<refnowiki><data></nowiki>- stores- TOSloads toconstant referenceinto variable

2324 CTVCTS SD<scopenowiki> N<refdata>D<data/nowiki> - loads constant into variablestack

24 CTS D<data> - loads constant into stack

==== OBJECTType DEFINITIONmanagement ====

----

'''3 - Type management'''

Types are in the air at this moment. I'll detail what types there are when

the time comes

----

30 [[typeof|TYPEOF]] - pushes type of TOS on to the stack TBI

31 CAST S<nowiki><type></nowiki> - Tries to cast TOS to <nowiki><type></nowiki> TBI

----

'''4 -==== Binary Ops''' ====

OPS take the two top elements of the stack, preformperform an operation and push

the result on the stack.

----

Line 209 ⟶ 207:

4D OR - or's TBI

4E XOR - xor's TBI

4F NAND - and's TBI

----

'''5==== -[[Conditional (computer programming)|Conditional Expressions''']] ====

Things for comparison, < > = ! and so on and so forth.

Line 226 ⟶ 224:

57 OR - Boolean OR

58 AND - Boolean AND

----

6 -==== Loops ====

----

60 STARTL - Start of loop

61 CLOOP - Conditional loop. If TOS is true, continue looping, else break

6E BREAK - Breaks out of loop

6F ENDL - End of loop

----

'''7 -==== Code flow ====

'''

These instructions dictate code flow.

----

70 [[GOTO]] A<nowiki><addr></nowiki> - Goes to address

71 JUMPF A<nowiki><n></nowiki> - Goes forward <n> lines

72 IFDO - If TOS is TRUE, do until done, if not, jump to done

73 ELSE - Chained with an IFDO statement, if IFDO fails, execute ELSE

Line 247 ⟶ 244:

7D ERR - Start error block, uses TOS to evaluate error TBI

7E DONE - End of block

7F CALL N<ref> - Calls function, pushes return value on to STACK.

----

'''8 - Generic object interface. Expects object on TOS'''

----

80 GETN N<name> - Returns variable assosiated with name in object

'''8 -==== Generic object interface. Expects object on TOS''' ====

81 SETN N<name> - Sets the variable assosiated with name in object

80 GETN N<nowiki><name></nowiki> - Returns variable assosiatedassociated with name in object

81 SETN N<nowiki><name></nowiki> - Sets the variable assosiatedassociated with name in object

Object on TOS, Variable on TOS1

82 CALLM N<nowiki><name></nowiki> - Calls method in object

83 INDEXO - Index an object, uses arguementargument stack

84 MODO S<nowiki><OP></nowiki> - Modify an object based on op. [+, -, *, /, %, ^ .. etc.]

==== F - Functions/classes ====

82 CALLM N<name> - Calls method in object

FF DEFUN NNS<refnowiki>S<type></nowiki> D<nowiki><args></nowiki> - Un-funs everything. no, no- it defines a

83 INDEXO - Index an object, uses arguement stack

function. D<ref> is its name, S<nowiki><type></nowiki> is

the return value, D<nowiki><args></nowiki> is the args.

FE DECLASS N<ref>DND<args> - Defines a class.

84 MODO S<OP> - Modify an object based on op. [+, -, *, /, %, ^ .. etc]

FD DENS S<ref> - Declares namespace

----

F2 ENDCLASS - End of class block

F - Functions/classes

F1 NEW S<scope> N<ref> - Instantiates class

----

F0 RETURN - Returns from function

FF DEFUN N<ref>S<type> D<args> - Un-funs everything. no, no- it defines a

function. D<ref>is its name, S<type> is

the return value, D<args> is the args.

==== Special Bytes ====

FE DECLASS N<ref>D<args> - Defines a class.

00 [[Null character|NULL]] - No-op

01 LC N<nowiki><name></nowiki> - Calls OS function library, i.e. I/O, opening files, etc. TBI

FD DENS S<ref>- Declares namespace

F2 ENDCLASS - End of class block

F1 NEW S<scope> N<ref>- Instantiates class

F0 RETURN - Returns from function

----

'''0 - SPECIAL BYTES'''

----

00 NULL - No-op

01 LC N<name> - Calls OS function library, i.e. I/O, opening files, etc TBI

02 PRINT - Prints whatever is on the TOS.

03 DEBUG - Toggle debug mode

0E ARGB - Builds arguementargument stack

0F PC S<ref> - Primitive call, calls a subroutine A<ref>. A list of TBI

0E ARGB - Builds arguement stack

0F PC S<ref>- Primitive call, calls a subroutine A<ref>. A list of TBI

primitive subroutines providing methods to tweak

objects this bytecode set cannot touch. Uses argstack.

=== [[Compiler|Compiler/Translator/Assembler]] ===

==== LEXICAL[[Lexical ANALYSISanalysis]] ====

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:

<nowiki><node></nowiki>

/\

/ \

/ \

<nowiki><arg></nowiki> <nowiki><next></nowiki>

node> can be an argument of its parent node, or the next instruction.

Line 329 ⟶ 311:

null 3

Functions are expressed as individual [[binary trees]]. The root of any file is

treated as an individual binary tree, as this is also a function.

The various instruction nodes are as follows:

* def <nowiki><type></nowiki> <nowiki><name></nowiki>

** Define a named space in memory with the type specified

*** See the 'TYPES' section under 'OVERVIEW'

Line 343 ⟶ 325:

The various instruction nodes within the tree will call specific functions

that will take arguemetsarguments specified and lookahead and lookbehind to formulate the

correct bytecode equivilentequivalent.

== Developer's Website ==

The developer of the language, Paul Longtine, operates a publicly available website and blog called [http://banna.tech banna.tech], named after his online alias 'banna'.

==References==

{{Reflist}}

[[Category:Programming language topics|Specification]]

{{Uncategorized|date=October 2016}}