Feature ability to predefine records enabling record recursion

[Ulti]

While trying to create an ash equivalent of simple_html_dom.php to add to the framework I've been working on, I've been creating many workarounds to overcome ash's limitations. You can get an idea of what I've been busy with by running this state-of-the-art masterpiece in the making: http://pastie.org/pastes/9665440/text
it runs flawlessly and outputs an html tree constructed with DOM methods represented internally as a nested set.

To workaround ash's limitations, notice how I had to create a treeRegistry and use a treeId for a node within the tree to reference the tree itself. My workaround, creating a registry special to manage the record recursion, is an ugly one attempting so very hard to implement a means for ash to manage multidimensional arrays. The workaround is a cry of desperation.

So, with the future of ash scripting in mind, I'd like to propose the following to the developers:
The ability to predefine records, so they can be used recursively:

	record nestedSetTree;//predefine in the same manner that we can already predefine functions in ash
	record nestedSetTree
	{
		record nestedSetNode
		{
			string data;
			int left;
			int right;
			nestedSetTree tree;//reference our predefined record for recursion
		}[int] node;
	};

 

[Fluxxdog]

Quick question: Why this:

record nestedSetTree
{
	record nestedSetTreeProperties
	{
		int depth;
		int left;
		int right;
		int treeId;
	} _props;
	record nestedSetNode
	{
		record nestedSetNodeProperties
		{
			string data;
			int left;
			int right;
			int depth;
			int treeId;
		} _props;
	}[int] _nodes;
};

record
{
	nestedSetTree tree;
}[int] treeRegistry;

...and not this?:

record nestedSetTree
{
	record nestedSetTreeProperties
	{
		int depth;
		int left;
		int right;
		int treeId;
	} _props;
	record nestedSetNodeProperties
	{
		string data;
		int left;
		int right;
		int depth;
		int treeId;
	} [int] _nodes;
};

nestedSetTree [int] treeRegistry;

You have records with nothing but a nested record inside them.

 

[Ulti]

Both work and the point of this thread is to avoid having to use either ugly lack-of-recursion workaround. The first way defines the registry as an entity as itself and is thus more flexible if I need to add more fields to it down the line. What would I need to add? Who knows, ask my future self. Let's say I needed the ability to preform complicated selecting queries on a tree. Where would I store temporary data to make back-to-back queries faster? I might add a revisionNumber to nestedSetTreeProperties so whenever a change occurs in a tree, I would know if my temporary data were still up-to-date. An example of this is if I needed to sort the tree nodes in multiple orders such as pre-order, in-order, post-order and breath-first. If I wrote it the second way, if a change were needed to the treeRegistry, I would need to go back and edit all references to treeRegistry in my functions, such as appendNode, and in multiple files if I tried to organize things later, making debugging harder somewhere down the line adding suspicion to several files. In the case of my framework, I have a record called ashpp_registry for storing all global properties related to the framework itself such as the version number, trees, virtual memoryAddresses for storing the contents of an all-encompassing data type wrapper I'm using. The first way is simply more dynamic.

 

[jasonharper]

Merely allowing forward declaration of record types would NOT solve this problem. ASH has no concept of null values; every field of a record is filled in with an object of appropriate type at the moment a record is created. A recursively-defined record would therefore require infinite memory to store!

Adding nulls to the language would be a very messy change - there are probably dozens of places where a Java NullPointerException would become possible, all of them would have to catch that and translate it to an ASH error.

Another possibility would be to have a canonical null value for each recursive record type that is an actual record, with all automatically-created instances of that type (everything other than an explicit 'new') simply returning a reference to that null value. There would need to be some way - perhaps an is_null() function, perhaps a conversion to boolean - to distinguish the null value from other instances of the type. I suspect that this would be confusing to use, as there would be subtle differences in behavior between recursive and normal records. In particular, you would need to remember to use 'new' in places where you normally wouldn't, as you would otherwise be operating on a shared reference to the null record.

 

[Ulti]

What if there was added, to the language, a unifying record type, namely "record", so an instance of any record could be assigned to the record?

	record nestedSetTree
	{
		record nestedSetNode
		{
			string data;
			int left;
			int right;
			record tree;//accept any record type
		}[int] node;
	};

 

[xKiv]

What if there was added, to the language, a unifying record type, namely "record", so an instance of any record could be assigned to the record?

IIRC, that already exists, is called aggregate, and is not very useful because you can't cast it to the type you want.

 

[Ulti]

Hmm, perhaps what I'd need then is a pair of functions aggregate_to_record and record_to_aggregate so it can be used as a wrapper.