mrodz / mscript

Programming Language

Hi, I'm Mateo

I am a passionate teenager who loves to code ❤️

I enjoy programming in Rust but am also well-versed in Java, Python, and C. I am always looking out for the newest technologies and try to learn something new with each project I create!

I'm pretty active on GitHub: HMU for inquiries or if you want to collab.

mscript's Issues

Vector Primitive Datatype

What is it

A list-like data structure.

Why is it useful

Allows for array-like operations

Details

Can easily be implemented with a Vector

To Add:

• make_vector
• indexing capability
• vec_op [function_name] interface for vector operations.

type checking for return instruction based on function signature

Compiler

Create AST from .ms files.

clash between modify and callback

All three should work:

• Callbacks

adder = fn(number: int) -> (fn(int) -> int) {
    return fn(input: int) -> int {
        return number + input
    }
}

add_five = adder(5)
print add_five(10) # should be 15

• Update Parent Scope

a = 5
add_five = fn() {
    modify a = a + 5
}
print a # 5
add_five()
add_five()
add_five()
print a # 20

• Copy to Local Scope

a = 5
add_five = fn() {
    a = a + 5
}
print a # 5
add_five()
add_five()
add_five()
print a # 5

Beta Bytecode

Complete before working on source code parsing:

• Turing Completeness
  • Conditional Processing (if/else) #4
    • Equality Checks #5
    • Comparison Checks #14
  • Loops #91
    • While #92
    • Integer Step #94
    • For-Each not part of release candidate v1
  • Functions #11
    • Jumps
      • Jump via a file handle and a fseek pos. #11
      • Always mutable Stack Trace and frames
    • Closures #12
  • Arithmetic
    • +
    • -
    • *
    • /
    • %
    • Binary & #164
    • Binary | #164
    • Binary ^ #164
    • Binary ! #164
    • Binary << #164
    • Binary >>#164
  • Variables
    • CRUD
      • Copy scrapped
      • Read
      • Update scrapped
      • Delete
    • Store #1
    • Load #1
    • Types
      • Primitives
      • Objects #20
      • Type Checking (Moved to compilation, #46 )
• Other
  • Linking via dll (https://crates.io/crates/libloading) #100 not part of release candidate v1
  • Modules #136
    • Preload File
    • Public/Private/Protected Flags
  • Performance not part of release candidate v1
  • stdlib not part of release candidate v1

Comparisons

• lt
• gt
• lte
• gte
• eq
• neq

Documentation for #5

Update docs to reflect changes brought by #5 (PR: #13)

Function as Type

Desired Syntax:

1: fn(int, bool, ...) -> str
2: fn() -> int
3: fn(float)
4: fn()

1. Args + Return Type
2. No Args + Return Type
3. Args + Void Return
4. No Args + Void Return

Idea for Compiled Setup

Split bytecode files according to the following:

Layout
Functions referenced in the file (callbacks & anonymous functions included)
Objects referenced in the file
Code declared on the global scope included in a __module_init__ function
Exports included in a __module_exports__ function

Arithmetic

• PEMDAS
• Pratt Parsing
• Rules of associativity
• Look at built-in precedence for rules in Pest

Functions and compiler architecture

cloning, equality, etc.

Moving out of #20 , this will be a separate concern for the time being.

Strings

Allow for raw strings in the parser.

• \" should be an escape sequence, as should all other escape sequences valid in bytecode.

"Store" & "Load" Bytecode Instruction

Spec

store [name] (==1)

• Save variable to stack frame.
• HashSet or Trie to store names for quick lookups (maybe)

load [name]

• Search for a variable in the current stack frame, trickling upwards.
• Push the variable to the end of the local stack.

Concerns

1. Should these operations be infallible? This would increase the speed of read/write operations at the expense of safety.
2. Possibility for a store_fast [to_eval, name] command that would combine constexpr [to_eval] and store [name].

Command Line App

Equality Bytecode Instructions

• "equ"
  Custom comparison implementation.
  • Float == Int/BigInt/Byte
  • Int/BigInt/Byte == Float
  • Int/BigInt/Byte == Int/BigInt/Byte
  • String == String
  • String("true") == Bool(true)
• "type_equ"
  Compares whether or not the items have the same type.
• "strict_equ"
  Compares values of the same type for an exact Eq match, or PartialEq if dealing with floats.

Chaining

• and
• or
• not
• xor

Progress Bars for Compilation

`while` loop

Planned Syntax

while condition {
    # code
}

Checklist

• PEST Grammar
• Control Flow
  • continue keyword
  • break keyword

Recursive Functions

Since MScript's design is to have every function be anonymous, there is no way to call a function recursively.

To fix this, the language will support the self keyword. self will allow any function to call itself.

Example

factorial_impl = fn(input: int, result: int, counter: int) -> int {
	if counter > input {
		return result
	}

	result = result * counter

	return self(input, result, counter + 1)
}

factorial = fn(input: int) -> int {
	return factorial_impl(input, 1, 1)
}

print factorial(5)

Crate to compile human readable IR to bytecode

Should take a file in legacy bytecode syntax...

function main
    string "hello world!"
    printn *
    ret
end

... And compile it to bytecode that can actually be interpreted.

THIS IS NOT THE LANGUAGE!

This is for developers to debug and test bytecode features without constantly opening a Hex Editor.

Native Instruction

Additions:

call_native !

Ability to call native functions via ffi.

Steps:

• Use the libloading crate
• Expose rust types to C++, C, etc.

---

Concerns:

Acknowledge that ffi functions are unsafe.

Extra Info:

• Implementing native methods should be as easy for the end-user as possible.

STEP_ITER Instruction

Additions:

step_iter <! if fallible> [end_idx, binding_name, start_inclusive, stop_exclusive, [step]?]

For-style loop.

Steps:

• Use Goto Requests plus built-in comparisons.
• Docs

scope

Create a new scope for variables.

---

done

End a scope.

• The only instructions after a done instruction should be a jmp.

---

Rework Instruction Parsing Entirely

Switch to a slice of Enums approach, instead of reading from a file.

Type safety for return in divergent function branches

AST Children of functions should be able to signal whether they cause the function to return. This implementation should be broad enough to support future features, like loops, evaluable blocks, and more.

Bail Templates for a consistent error format.

Create a system (perhaps Factory-structured) to build a consistent error format for similar failure cases.

Turn Textual Bytecode into Binary Format

Option in #28

Add documentation to all files in /bytecode

As of now, none of this code has documentation. It'll soon be time to fix that!

• src/bytecode/attributes_parser.rs
• src/bytecode/file.rs
• src/bytecode/function.rs
• src/bytecode/instruction.rs
• src/bytecode/interpreter.rs
• src/bytecode/stack.rs
• src/bytecode/variable.rs

If

Support if statements and boolean expressions

if condition {
    print "Truthy!"
} else if function_call() {
    print "The function returned true"
} else {
    print "Neither are true"
}

• if
• if/else
• if/else if chains
• basic boolean implementation

[specification] Template Strings

• Similar to raw strings #49
• Perhaps use a format like "this is a normal string, but {my_variable} can go here!"

Loops

• #92

• #94
  Inspired by Fortran's do construct, which is surprisingly beginner friendly.

• for each loop
  Depends on #96 Moved to Release 2

• Loops as evaluable expressions
  It would be neat if loops could be evaluable themselves. Moved to Release 2

  Proposed syntax (Moved to Release 2)

  test = fn() {
    i = 0
  
    my_variable: str = while i < 5 {
      api_response = send_api_request()
      if api_response.status == 200 {
        break api_response.message
      }
      i = i + 1
    } default "Error! Tried five times and could not get result"
  
    print my_variable
  }
  
  test()

Rework binary operations

#14

Object Primitive Datatype

What is it

Object/Struct, ie. primitives bound to names

Why is it useful

Allows for grouping of data.

Details

Could possibly be implemented with HashMap

• make_object
• call_obj
• access object fields
• #24 - Closing #20 for now, and moving this feature to a new issue.

Function Context Bridge Notification System

What is it

A standardized method of sending messages from instructions to the interpreter. This will be needed to avoid spaghetti code for future bytecode features.

How might one implement it

#[derive(Clone, Copy)]
enum Messages {
    SayHi,
    SayMessage(String),
    MakeFriend
}

struct NotificationBridge<T> {
    items: Vec<T>
}

impl <T>NotificationBridge<T> {
    pub fn poll(&mut self) -> &Vec<T> {
        let c = *self.items;
        self.items.clear();
        c
    }

    pub fn notify(&mut self, T item) {
        self.items.push(item);
    }
}

...

pub fn check_messages<'a>(ctx: &mut Context<'a>) {
    match ctx.poll() {
        ...
    }
}

Callback dependencies are askew

Variables defined inside a callback are not labeled by the compiler correctly.
#57 fixed this issue, but codebase changes since then broke this PR.

• #73
• Detect Local variables
• Detect Captured variables (dependencies)

Boolean operations

• #82
• #84
• #88

Functions pt. 2

File Meta Attributes

To be determined.

Comparison Bytecode Instructions (<, <=, >, >=)

See #5

Mutability of foreign variables outside of callback (make_function instruction)

All callbacks should use an Arc'd reference to the original variable to allow mutability from foreign sources. The current implementations passes data by value (which is cloned), but this is probably not desired behavior.

See:
https://github.com/mrodz/mscript-lang/blob/054d271b48d2f8289ecbf4af13f56649660a48f2/bytecode/src/instruction.rs#L327

Steps:

• fix make_function
• fix store_object

Variable flags, ie. a lookup keyword similar to the global keyword in python.

Unit tests for function variable dependency graphs

For future sanity

Bytecode If Statements

Spec

if (>=1)

• Should look at the last item on the local stack
• Check if it is boolean
• Send a signal to the interpreter that informs it whether the evaluation proved truthy.
• Clear the local operating stack.

else

• If the condition is not true, this code is ran.
• Error if this is encountered outside of an if-statement.

endif

• Close this if-statement.
• Clear the local operating stack.

function main
    bool true
    if
        string "hi"
        printn *
    else
        string "awww"
        printn *
    endif
end

Concerns

This is unoptimized and there is much room for improvement.

Functions

• Specify arguments for function calls.
  • Should it pass the current operating stack as arguments? yes! ✅
• make_function instruction to create a function "pointer"
• call should be able to call a function "pointer"
• New primitive: Function Pointer
  • Contains the location of the function.
  • Can contain an Arc of variables to freeze, perhaps to facilitate callbacks. This is tentative.

The line to distinguish this feature from #12 is very blurry. Stay tuned for updates as I decide what should go into which branch.

Note: I am using "pointer" very loosely here, as it is not an integer that points to a location in memory. It contains a String that tells the interpreter how to find a function.

Lazy and Eager Boolean evaluation

• a || b should only evaluate b if a is falsey.
• a && b should only evaluate b if a is truthy.

Closures

Similar to #11

• make_function should take an optional list of arguments to freeze their values to be later used.
• load_callback should be able to load frozen variables.

Move away from nightly builds

Using nightly features, most notably box patterns, makes for more concise code. However, the instability from depending on the nightly channel makes for CI/CD issues and harder toolchain setup. Moving forward, this project will depend exclusively on stable releases of Rust.

Return

Support

idk = fn() {
    return fn() {
        ...
    }
}

Nested Functions Break Bytecode

If a function is nested inside another function...

a = fn() {
    b = fn() {
        
    }
}

... the resulting bytecode will take the following shape...

function a
function b
    void
    ret
end
    void
    ret
end

... which is invalid.

Comments

Support comments in source code. For now, the proposed symbol is #.

Limit visibility of functions, structs, and traits.

Create specialized pub(in ..), pub(super), etc. for functions in /bytecode. As of now, everything is just pub.