mustafif/mufiz

Mufi Lang with Ziggyness

Mustafif Khan

Skills

Stats

mufiz's Issues

Add fast hashmap implementation `hashdict`

Provide a zig implementation towards hashdict, that uses ObjString as the key value and Value as the value type.

https://github.com/exebook/hashdict.c

Homebrew Support

Just like Scoop, Homebrew works very similarly. Since it supports x86_64 Linux, we can test the installation, and supporting the brew package manager will allow us to help make MacOS fellows' lives easier.

`system.repl()` hanging on Windows: `next` branch

I am currently running windows on my laptop, and trying system.repl causes hang, but running with pre.repl works fine.
This function works fine on Linux, so I'm assuming its some issue with how stdin reads from Windows.

Indexing syntax for Mufi Lang Arrays/FVec

We hope to introduce native indexing for arrays and float vectors, since we still have pending work on Matrix, and many things can change with that, its better to bring the initial support for arrays/float vectors.

Syntax:

We will follow similar to Matlab, and reduces the need for extra tokens to declare.

var first_element = arr(0);

Stack Representation:

We will need to introduce a new instruction OP_INDEX that will be when we have an indexable type ObjArray/FloatVector on the left, follow by Left Paten, an integer constant, then right parent.

So we expect:

<indexable> (   <int const> ) => get mutable ref to indexable 

First thing to figure out, how can we reproduce this by the following:

var a = array(5);
push(a, 1, 2, 3, 4, 5);

nth(a, 0) = 201;

Once we can make this possible, then we can have the same behaviour called to the OP_INDEX instruction

Matrix and Numerical Stability

We want to refine our Matrix support and create "state-of-the-art" algorithms for it. This will help us ensure that our results are similar to those of more sophisticated languages like Matlab and ensure that users get the correct results.

Before we port these algorithms to Mufi-Lang, we will do the initial work in https://github.com/Mustafif/MatrixAlgo

Softening Numeric Type Requirements in Builtins

Consider the following example:

var v1 = linspace(1.0, 2.0, 2);
var v2 = linspace(1, 2, 2);

Currently, v1 can compile, but v2 can't since the first and second arguments need to be strictly double. However, we should enable the user to choose either version and for them to be the "same."

The notion of softening the numeric type means that if we expect a double but receive an int, then we accept any number type (double, int) and cast it to the correct expected type. This means we need a new macro IS_NUMBER to check if its either a double or integer, and another macro or function to cast it to the correct expected type. This change should resolve many accidental compile errors for the users, and simplify builtin requirements as we can just simply say any number (real).

`wasm32-wasi` unable to use Zig's allocation

We have reintroduced wasm32-wasi support, however you will only be able to use the repl system without filesystem features.
So I'd like to want to figure out why the allocation from Zig's side is not working.

Hashing Benchmarks

In v0.6.0, we switched from FNV-1a to xxhash64. However, we don't know its true impact on the language. So this means we need someway to benchmark how it affects the language, such as dispersion, hashmap collisions, and speed.

Helpful Boolean Macros

When it comes to type checking, we have a lot of if(!IS_ARRAY(args[0) && !IS_LINKEDLIST(args[0])), for example, that can better be handled by a single macro to check if we explicitly only want list, array, or collection types.
Got it, here's the updated list with the items inside each category enumerated:

• array:

  1. ObjArray
  2. FloatVector

• list:

  1. ObjArray
  2. ObjLinkedList
  3. FloatVector

• collection:

  1. ObjArray
  2. ObjLinkedList
  3. ObjHashTable
  4. ObjMatrix
  5. FloatVector

Test Suite Implementation

In our Mars release, I shipped it with broken Vec3 functions which are now fixed in v0.7.0 but this was mainly a boolean issue. This could've been caught if we had a test suite implementation instead of random test files.

Here's my proposition:

test_suite/
      vec/
          slice.mufi
          splice.mufi 
          ops.mufi
          ....

On the Zig side:

// src/test_suite.zig
test "slice vec3"{
        // run interpret to check if an error occurs 
} 

This will involve making runtime and compile errors, an error union in Zig so we can properly see if tests fail or pass.
This will allow us to utilize Zig Unit Testing to create a nice framework.

Create a VSCode Extension

It would be nice to have a VSCode extension to help writers of programs for Mufi-Lang since many primarily develop their programs there.

Vec3 Functions **BROKEN**

Since we do not have a proper test suite, especially with newer functions, we have the occasionally broken built-in, and sadly, this plague has affected our Vec3-specific functions.

Dot

Version 0.6.0 (Mars Release)
(mufi) >> var x = fvec(3);
(mufi) >> var y = fvec(3);
(mufi) >> push(x, 1.0, 2.0, 3.0);
(mufi) >> push(y, 1.0, 2.0, 3.0);
(mufi) >> print dot(x, y);
Vectors are not of size 3
0

Cross

(mufi) >> print cross(x, y);
Vectors are not of size 3
Segmentation fault at address 0x0
???:?:?: 0x1092db3 in ??? ()
Unwind error at address `:0x1092db3` (error.InvalidDebugInfo), trace may be incomplete

Norm

Version 0.6.0 (Mars Release)
(mufi) >> var x = linspace(1.0, 3.0, 3);
(mufi) >> var y = linspace(1.0, 3.0, 3);
(mufi) >> print norm(x);
Cannot normalize a zero vector
Segmentation fault at address 0x0
???:?:?: 0x1092db3 in ??? ()
Unwind error at address `:0x1092db3` (error.InvalidDebugInfo), trace may be incomplete

Angle

Version 0.6.0 (Mars Release)
(mufi) >> var x = linspace(1.0, 3.0, 3);
(mufi) >> var y = linspace(1.0, 3.0, 3);
(mufi) >> print angle(x, y);
Vectors are not of size 3
nan

Proj

(mufi) >> print proj(x, y);
Vectors are not of size 3
Vectors are not of size 3
[nan, nan, nan]

Others behave just like proj, the main issue we can see is that the size 3 not being detected properly. That will be the first issue tackled, and hopefully 90% of these errors will be fixed.