Lard Version 8 Release Notes

This version enhances the language by adding improved support for strings and files. This includes non-backward-compatible changes.

Existing local users will need to

If your environment variables were set up as described in the v6 release notes all you need to change is LARDHOME:
```
	LARDHOME=/home/amulinks/lard/v8
```
Recompile all existing programs.

Improved Strings Package
At last LARD has a proper strings package. This uses reference counting to free strings that are no longer used, so programs that make extensive use of strings won't run out of memory any more. It also has a more comprehensive set of string functions. The only downside is that you have to call initialisation and termination functions for string variables and parameters. Full details here. I appologise for the inconvenience that these initialisation and termination functions cause; I hope to make this automatic in some (distant) future version. All programs that use strings will have to be updated to take account of these changes.
Binary Files
LARD now distinguishes between text files and binary files, with an extended set of operations for each type. Full details here. All programs that use files will have to be updated to take account of these changes.
Vector and record constructor function size increased
You may now have vector and record constructor functions (i.e. [0,1,2] and {true,0,"foo"} of up to 33 elements.
Assorted bug fixes

There can be class checking problems when using an expression in the class of a declaration, for example v:var(int^(a+1)). The problem hasn't been thoroughly investigated, but is seems that it can be made to go away using an explicit eval, for example v:var(int^(eval(a+1))).
If a recursive function's return type depends on its parameters (explicit or implicit), things will go wrong. For example, compiling the following program fails to terminate:
(foo(T:type):expr(T)=foo(T)).null
Multi-dimensional array declarations work "backwards", for example if I declare V:var(int^100^200) then the highest numbered element of V is V[199][99], not V[99][199] as you would have expected.
If a channel's receiver has no delay in its ?() expression then other processes that are watching the channel using wait_until(chan_ready()) may "miss" any activity on the channel. This needs a mechanism like VHDL's delta timing model in order to get the correct behaviour.