chad-fast - [no description]

	Commit message (Collapse)	Author	Age
*	Pass around an accumMap (but it's empty still)	Tom Smeding	3 days
\|
*	D2[Array] now has a Maybe instead of zero-size for zero	Tom Smeding	5 days
\| \| \| \|	Remaining problem: 'add' in Compile doesn't use the D2 stuff
*	Much process with accumulator revamp	Tom Smeding	2025-03-14
\|
*	Clean up code organisation a little	Tom Smeding	2025-03-09
\|
*	Compile: Implement EWith (TODO EAccum)	Tom Smeding	2025-03-05
\| \| \| \|	That's going to be a mess
*	test: Simplify and make it a bit faster	Tom Smeding	2025-02-28
\|
*	Pretty-printer that supports extension fields	Tom Smeding	2025-01-28
\|
*	Add ext field to remaining AST constructors	Tom Smeding	2025-01-27
\|
*	WIP accum top-level args	Tom Smeding	2024-11-26
\|
*	Prepare for introducing top-level args in accum mod	Tom Smeding	2024-11-23
\|
*	Configuration for CHAD	Tom Smeding	2024-11-14
\|
*	Benchmark	Tom Smeding	2024-11-07
\|
*	Towards a test suite	Tom Smeding	2024-10-07
\|
*	WIP better zero/plus, fixing Accum (...)	Tom Smeding	2024-09-13
	The accumulator implementation was wrong because it forgot (in accumAdd) to take into account that values may be variably-sized. Furthermore, it was also complexity-inefficient because it did not build up a sparse value. Thus let's go for the Haskell-interpreter-equivalent of what a real, fast, compiled implementation would do: just a tree with mutable variables. In practice one can decide to indeed flatten parts of that tree, i.e. using a tree representation for nested pairs is bad, but that should have been done _before_ execution and for _all_ occurrences of that type fragment, not live at runtime by the accumulator implementation.