Cygwin's GCC creates dependency on cygwin-1.dll. MSYS2 with MINGW64 doesn't.

To compile on MSYS2 MINGW64, on Makefile of cish remove -ldl and on Makefile of Capote add -mconsole

Everything compiled fine, but cish is unable to compile any examples.

The error message:

$ cish -c -s fib.cish -o fib
in fib.cish: row 1, col 26
        ;
Syntax error(cannot open file).

The guide on release page said copy stdlib directory into either cish or Capote working directory. But I found this directory are already there on both directories. I overwrote it with my downloaded stdlib anyway. Doesn't work. The last resort, I copied stdlib directory into examples directory where fib.cish is placed. Still doesn't work!

I'm out of ideas.

Not sure how serious the issue is at the moment, I am still investigating. It looks pretty serious, but I don't think it has anything to do with the memory saftey additons made in #31, but rather the changes made in #30.

The program segfaults because of an invalid array at IP 177.

While garbage-collection can ultimately be deferred in the code-gen of a procedure that requires generic-type-parameters, it cannot be done for records/structs that have generic-type-parameters.

The proposed solution would be to analyze inputted type arguments, which are ultimately all non-generic, and configure garbage collection trace settings based off of them.

SuperForth crashes when trying to generate a type-signature while compiling top-level code(code that isn't encapsulated in a procedure).

The following code was used: hashmap.txt:

abstract record hash_bucket<K, V>
final record empty_bucket<K, V> extends hash_bucket<K, V>
final record full_bucket<K, V> extends hash_bucket<K, V> {
	mustinit K key;
	mustinit V value;
}

final record hash_map<K, V> {
	mustinit array<hash_bucket<K, V>> buckets = [new empty_bucket<K, V>, new empty_bucket<K, V>, new empty_bucket<K, V>, new empty_bucket<K, V>, new empty_bucket<K, V>,
						new empty_bucket<K, V>, new empty_bucket<K, V>, new empty_bucket<K, V>, new empty_bucket<K, V>, new empty_bucket<K, V>];
	mustinit proc<int, K> hasher;
}

global readonly auto hash_map_emplace = proc<K, V>(hash_map<K, V> map, K key, V value) return nothing {
	readonly auto rehash = proc<K, V>(hash_map<K, V> map, int new_size) return auto {
		array<hash_bucket<K, V>> old_buckets = map.buckets;		

		map.buckets = new hash_bucket<K, V>[new_size];
		int i = 0;
		while(i < new_size) {
			map.buckets[i] = new empty_bucket<K, V>;
			i = i + 1;
		}

		return old_buckets;
	};
	
	int bucket = map.hasher(key) % #map.buckets;
	while(bucket < #map.buckets) { $find the first empty bucket after computed hash_location
		if(map.buckets[bucket] is empty_bucket<any, any>) {
			map.buckets[bucket] = new full_bucket<K, V> {
				key = key;
				value = value;
			};
			return;
		}
		bucket = bucket + 1;
	}

	$no availible bukets were found if this code is reached
	auto reinsert_buckets = rehash<K, V>(map, bucket + 5);
	bucket = 0;
	while(bucket < #reinsert_buckets) {
		thisproc<K, V>(map, key, value);
		bucket = bucket + 1;
	}	
	thisproc<K, V>(map, key, value);
	return;
};

test.txt:

include "hashmap.txt";
include "io.sf";

auto mymap = new hash_map<int, array<char>> {
	hasher = proc(int i) return int {
		return i;
	};
};

hash_map_emplace<int, array<char>>(mymap, 5, "Michael");
hash_map_emplace<int, array<char>>(mymap, 2, "Michael");
hash_map_emplace<int, array<char>>(mymap, 7, "Tim");

println("HI!");

It can be reproduced by running: superforth -cr -s test.txt.

Given the following code:

include "io.txt";
include "string.txt";

record cell {
	int team_no;
	bool is_empty = true;
}

record board {
	int rows;
	int cols;
	int win_cells;

	array<array<cell>> cells;
}

global array<char> team_symbols = ['X', 'O', '*', '@', '&'];
global array<char> num_symbols = ['1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'];

global readonly auto init_board = proc(int rows, int cols, int win_cells) return board {
	if(cols > #num_symbols or rows > #num_symbols or
	   cols <= 0 or rows <= 0){
		println("Error: Invalid row/col");
		abort;
	}
	else if((win_cells > cols and win_cells > rows) or win_cells <= 0) {
		println("Error: Invalid cells to win");
		abort;
	}
	else {
		board new_board = new board {
			rows = rows;
			cols = cols;
			win_cells = win_cells;
		};

		new_board.cells = new array<cell>[rows];
		int r = 0;
		while(r < rows) {
			new_board.cells[r] = new cell[cols];

			int c = 0;
			while(c < cols) {
				new_board.cells[r][c] = new cell;
				c = c + 1;
			}
			r = r + 1;
		}
	  return new_board;
	}
};

global readonly auto print_board = proc(board b) return nothing {
	int c = 0;
	put_char(' ');
	put_char('|');
	while(c < b.cols) {
		put_char(num_symbols[c]);
		put_char('|');
		c = c + 1;
	}
	put_char('\n');

	int r = 0;
	while(r < b.rows) {
		c = 0;

		put_char(num_symbols[r]);
		put_char('|');

		while(c < b.cols) {
			if(b.cells[r][c].is_empty) {
				put_char(' ');
			}
			else {
				put_char(team_symbols[b.cells[r][c].team_no]);
			}
			put_char('|');
			c = c + 1;
		}
		put_char('\n');
		r = r + 1;
	}
	return;
};

int n = stoi(prompt("Board size?>"));
global board game_board = init_board(n, n, n);

print_board(game_board);

SuperForth would simply segfault, however only when the inputted "board size" is 11 or more.

Per this reddit thread that discussed various different methodologies of significantly speeding up SuperFetch's virtual machine - reducing the instruction size by encoding offset flags as part of the instructions opcode seemed to be the most feasible and performant because it reduces the overall size of the instruction by 3 bytes(assuming there aren't more than 256 opcode types - I'll explain that later) herby reducing cache misses, and it'll reduce the processing time per instruction by bypassing the need for runtime computation of registers and their offsets.

A potential issue would be that there may be more than 256 (the max amount of enum types that can still fit in a byte), opcode types, there may be certain performance issues. However, instructions sizes will still have been signifgantly decreased and runtime offsetting bypassed.

The next major goal would be to add an dynamically linking capabilities for c libraries to SuperForth's foreign function interface. This would enable SuperForth to utilize many existing c libraries, and open up new possibilities for significantly more complex SuperForth programs to be created.

I made a hello world program and after changing import to include, it gave me a invalid token error but no location of the error. Here is my code: include "io.txt"; print("Hello, World!")

I hadn't considered the possibility until now that one couldn't downcast safely because of mutability. See this SO thread for details.

One potential fix I am considering is to allow down-casting for arrays, and type-check each assignment during runtime. See the upcasting branch, which will add run-time type information for runtime-typechecking and runtime-typecasting, for more information. Array assignment will leverage this new feature for safety.

However that still leaves out regular types. I think the only soloution at this point would be to disallow implicit down-casting for record type arguments during compile time, like Java.

More compile time analysis, in essence a third pass - right after the ast has finished parsing and right before the ast is fed into the compiler, would be a good idea because it gives more room to do certain types of static analysis that requires everything to be defined and all linking issues resolved before moving on to potentially platform dependent compilation.

There is already a small amount of processing done in this phase - linking struct/record declarations, references, and creations is finalized at the end of ast parsing.

Often times inherited records do some stuff with type arguments/extra stuff. There needs to be some transformation in regards to inheritance and the type tree.

While it would be somewhat difficult to create object message receivers that fully support the capabilities of a first-class function, a good first step would be to implement simple object messaging capabilities that don't need first class support - for example operator overloads and constructors, which can be overloaded with different parameters and return types, are good candidates to support.