There are currently no sets within Dictu. This would be a nice addition along with the relevant set operations.

Dictu Version: 0.1.6
>>> var x = {"t": 0};
>>> x["t"] += 1;
[line 1] Error at '+=': Expect ';' after expression.

This is because the subscript function within the compiler has no concept of the TOKEN_*_EQUALS tokens, and only simply allows the getting of a value and the setting of a value.

Dictu Version: 0.1.6
>>> var x = 10;
>>> x ^= 10;
[line 1] Error at '=': Expect expression.

Bitwise operators do not have the <operator>_equals syntax.

Currently Dictu only has support for single inheritance. This is fine assuming we have a method to "inherit" from more than one source. I think the best method is to keep single parent inheritance (to avoid the diamond problem) and instead introduce something like traits (sometimes called Mixins) instead. The benefit of this is we have a "linear" structure, so the last most overridden method is the one which will take place in the class.

e.g

trait MyTrait {
    hello() {
        print("Hello there!");
    }
}

trait MyOtherTrait {
    hello() {
        print("Hello there!!!!!!!!!");
    }
}

class MyClass {
    use MyTrait, MyOtherTrait;
}

var myObject = MyClass();
myObject.hello(); // Hello there!!!!!!!!!

As we can see here, the trait included last, takes priority.

class Test {
    static func(a) {
        print(a); //Expect 10
    }
}

Test.func(10);

Output: <fn func>.

Add the ability to define a function with optional parameters. Be that by nil-ing the variables or allowing default values to be passed.

10.format(10); // Segfault!

This should raise a runtime exception however in its current state its converting to an object and getting a segfault instead.

Currently the REPL only registers single lines for everything entered. Instead we need a way for a block of code to be inputted.

Parsing issue

for (var i =0; i < 10; ++i) {
    "string";
}

This will error due to the parsing thinking this is the construct for a dictionary. <left brace><string>.

Currently, you can setup a dictionary, add to it and replace values, however you are unable to delete values from it.

Currently there is no support for continue

Dictu has no dictionary datatype

Include some more operators such as:

• +=
• -=
• *=
• /=

str(12) == "12" evaluates to false.
str(12) + " some string"; returns 12

In the interpreter, when a line contains one or more tabs, moving in the line with arrow keys or using backspace offsets the cursor as if the tabs were spaces.

Reproduction

1. Launch Dictu
2. Press TAB twice
3. Press left or backspace

Expected behaviour:

After step 3, the cursor is offset by one TAB to the right.

Observed behaviour:

After step 3, the cursor is offset by one SPACE to the right.

Dictu version

Dictu Version: 0.3.0

Environment

OS: Linux
Kernel: x86_64 Linux 5.4.11-arch1-1
Target: x86_64-pc-linux-gnu
Thread model: posix
gcc version 9.2.0 (GCC)
ldd (GNU libc) 2.30

STACK_MAX is a constant and there is no checking in push() to see if we have hit the stack limit. This is for good reason, as push() happens so frequently, a branch in here would hit performance significantly, however this does mean the VM can run into undefined behaviour if the stack count out grows the hard constant. This should instead be a value based on the "worst case" amount of values worked out at compile time.

Things such as:

• split
• find
• replace
• join
• upper
• lower
  And so on.

Currently there’s no way to build Dictu on windows.

Dictu Version: 0.1.1
>>> someUndefinedVar;
[line 1] in script: Undefined variable 'someUndefinedVar'.
>>> print("Some string!");
'Some string!'
[line 1] in script: Undefined variable 'someUndefinedVar'.
>>> print("Some string!");
'Some string!'

As shown, the runtime error is thrown twice.

someFile.du

def test() {
    print("Hello");
}

main.du

import "someFile.du";

test(); // Available via global namespace

someFile.test(); // We should prefer something like this

The repl needs improving. Things such as multiline inputs, past inputs (history of commands) and so on.

Currently the code for inserting a value into a dictionary is:

while (dict->items[index] && !dict->items[index]->deleted && strcmp(dict->items[index]->key, key) != 0) {
        index++;
        if (index == dict->capacity) {
            index = 0;
        }
    }

However, because of !dict->items[index]->deleted we could end up with the same key in the dictionary twice!!

Lets take this chain of linked lists for example

test->test1->test2

And lets say test2 has the same index as test1, since linear open addressing is used, we find the next available space from test1.

Now lets say we remove test1

test->test(DELETED)->test2.

We now update test2's value, but remember the hashed index, was where test1 was, which is now marked as deleted, it will insert here!

test->test2->test2.

Instead we should check for none null OR matching keys, and not deal with "deleted" values.

Currently the only way to access attributes is via a hard coded identifier, however there may be a time where an attribute needs to be accessed dynamically based on some conditions. We should implement getAttribute and setAttribute on instances.

Currently there is no support to read/write from/to files in Dictu.

Currently there is only one example program. We should create some more to showcase a little bit more of the language

Accessing an undefined object attribute throws a runtime exception. This is wanted behaviour however there needs to be a way to determine whether an object has an attribute.

var index = 0;
var list = [1, 2, 3];
print(list[index]); // Error!

This is because the compiler is currently expecting a numeric token, not an identifier.

Currently Dictu has no method of modulusing its source files.

Type is returning the wrong value when using the REPL.

Steps to reproduce:

• Open the repl
• Enter type("test string");
• See the output be _

>>> var x = {"test": 10};
>>> x.remove("test");
>>> x.exists("test");
true

Dictionaries don't actually delete values when you call remove, they mark them as "deleted" and they are cleaned up when a dictionary is resized. However, in the dictItemExists function, this "deleted" factor is not accounted for, which in turn returns false values

        if (strcmp(dict->items[i]->key, key) == 0) {
            push(TRUE_VAL);
            return true;
        }

This check needs to include the "deleted" flag.

Seems as though from version 0.2.0 to now, there has been an introduced bug with the GC which causes a segfault.

Outdated file

debug.c is currently outdated and missing some new opcodes which have been implemented

There needs to be the ability to loop through individual characters within a string, this is currently not possible.

Dictu Version: 0.1.7
>>> var x = [10, [11, 12]];
>>> x.contains([11, 12]);
false
>>> 

Because the check is using == rather than the valuesEqual function

var dict = {};

for (var i = 0; i < 100; ++i) {
  dict[str(i)] = i;
  print(i);
  print(dict[str(i)]);
}

Produces

0
0
1
1
2
2
3
3
4
4
5
5
6
nil
7
7
8
8
9
9
10
nil
11
nil
12
12
13
13
14
14
15
15
16
16
17
17
18
18
19
19
20
nil
21
nil
22
nil
23
nil
24
24
25
25
26
26
27
27
28
28
29
29
30
nil
...

nil values should not be getting inserted.

For example, OP_CALL_X has 32 different opcodes (to get the arg count) when instead the arg count can just be emitted.
Same for OP_INVOKE_X and OP_SUPER_X

If a native function raises a runtime error a segfault is not far behind.

Dictu Version: 0.1.1
>>> assert();
[line 1] in script: assert() only takes a boolean as an argument.
[1]    74643 segmentation fault  ./dictu

FRAMES_MAX being a constant means there is a hard limit on things like recursion depth, or function call depth. This limit is currently 64. This in reality should really be a value that grows as it needs.

Enter the repl and enter:

>>> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255];

Return

dictu(28539,0x114fe25c0) malloc: Incorrect checksum for freed object 0x7fc50f501540: probably modified after being freed.
Corrupt value: 0xb000000000000020
dictu(28539,0x114fe25c0) malloc: *** set a breakpoint in malloc_error_break to debug
[1]    28539 abort      ./dictu

Currently there are a bunch of builtin functions within Dictu. I think these functions would be better suited if they were part of related classes instead of just global functions.

i.e

// Old
round(10.4)

// New
Math.round(10.4);

Currently you can only return a single element from an array or string. This is fine, however adds more complexity than should be required when trying to gather part of a string or part of a list.

There should be a way to join list items together to form a String: str(List) returns the [] and '' if the List contains a String.

When I do:

var list = [1, 2, 3];
print(list.join());

I expect:
1, 2, 3 to be printed to the screen.

I should also be able to do list.join(" + ") and get a result like 1 + 2 + 3.

Currently there is no way to pass arguments to the script via the command line. This would be a nice addition.

Currently there is no support for string interpolation.

There is a slight issue with dictionary removing:

    while (dict->items[index] && strcmp(dict->items[index]->key, key) != 0) {
        index++;
        if (index == dict->capacity) {
            index = 0;
        }
    }

This code finds the index within the linked list for the given key, however, if the given key was previously deleted, it will mark the same key for deletion again. Instead this should skip the deleted key

Currently running import "x.du" multiple times will cause the file to be compiled and interpreted many times. Instead once an import has finished, it should not be imported again.

Currently there is no support for break statements.