So, I guess Jesse came up with this: http://ceramicpig.no-ip.org/dictproposal.pdf That's a good start for dictionary functionality, but I think it could be improved a bit down the line to be less ugly.

Dunno if this is too complicated, or OOP-like, but the following could work for a later stage of dictionary control. It could give lots of functionality and give a really good list structure. I'm sure it would probably give headaches trying to get the compiler and interpretter to manage with the following, but it would pay off.

dictionary myDict;			// Create new dictionary type.

myDict['dood'] = 'Bill';		// Create new key in dict by setting it.

myDict['ohshi'] = 'Bubbles';		// Create *another* new key in dict by setting it.

s = myDict['dood'];		// Return the value of a key if it exists.

myDict.remove('dood');			// Remove a key in the dict.

myDict.clear();				// Clear out all keys from the dict.

exists = myDict.contains('dood');	// True/false return.

myDict['subDict'] = dict();		// Create a dictionary in a dictionary.

myDict['subDict']['bob'] = 'cool';	// Assign the subdictionary a new key.

myDict['anotherDict'] = myDict['subDict']; // Copy the dictionary.

myDict['subDict'] = '';			// Wipe the dictionary from existance and replace key with a new value.

s = myDict['anotherDict']['bob'];	// Read from a subdictionary.

dict(); in the above case, would be a function that would return a dictionary type. And assigning it to a dictionary would let you have subdictionaries. The dict() function's return would only assignable to dictionary types, not ints or strings. It would surely be pain, having to add new rules to the compiler and a whole new variable type to screw around with. But I dunno, weigh the risks to better-verge-c-code-as-a-result benefits? Comments?

Ah, I figured it *could* have been Kildorf, after all, the pdf is on his server, but eh. Hmm, yeah, OOP is probably a bad idea. Hmm. Would something like the following work instead? It's a little more syntactically pleasing, and refrains from OOP.

dict myDict;	// Dictionary exists until it escapes its scope. Initialized to a value of DictNew() by default.

myDict['dood'] = 'Bill';

myDict['ohshi'] = 'Bubbles';

s = myDict['dood'];

DictRemove('dood');

DictClear(myDict);

exists = DictContains(myDict, 'dood');

myDict['subDict'] = DictNew();

myDict['subDict']['bob'] = 'cool';

myDict['subDict']['subSubDict'] = DictNew();

myDict['subDict']['yetAnotherDict'] = DictCopy(myDict['subDict']['subSubDict']);

myDict['anotherDict'] = DictCopy(myDict['subDict']);

myDict['subDict'] = '';

s = myDict['anotherDict']['bob'];

Log(DictToString(myDict)); // A string-able representation of a dictionary.

// Scope is escaped (unless myDict is global), free the chunks of memory used by the dict and its subdictionaries.

DictNew() would probably return an int, but VergeC would be able to detect subdictionaries, by the way the player tries to access them. myDict['subDict']['bob'] would first check that myDict exists and is a dictionary, then myDict['subDict'] is a valid associative array key, and that the entry was a dictionary, and then it would check if 'bob' was a valid key with in the subdictionary, and if any of the conditions fail, it raises either a wrong type error, array-out-of-bounds-error. Maybe to distinguish dicts from ints could instead be a string of chr(255) + str(index), because ints can't start with a non-numeric, and following it would be a useful index with a character nobody will probably ever use. So, all the dictionary functions, you'd end up passing integer string indices to, but with a special character at the beginning.

I should mention that the garbage collection route isn't impossible - we could have reference semantics for the dicts if people want. I'd just like some consensus on the issue.

There's a bug or two still lurking in the typing code, and I've been too busy to look at it recently. I expect that to continue to be the case for at least a couple weeks.