Lard Version 2.0.14 Release Notes

LARD is now being maintained by the team of:

• Peter Riocreux - Thread state display, new configuration mechanism, command line arguments to the lard code
• W. John Bainbridge - Channel display and debugging improvements
• Andrew Bardsley - Arbitrary precision integer support, new value display format format

Upgrading from version 2.0.13

Release 2.0.14 is just a bug fix release. The only major change is the new `generic binary' file `lard.sh'. Sourcing lard.sh into your (Bourne-like) shell sets the obscure environment variables required by LARD and adds LARD to your ${PATH}.

For users who already have .profile... entries for a previous version 2 LARD: there are no changes to the environment variable set in this release.

Existing LARD programs only need to be recompiled if they are older than version 2.0.12

Changes since version 2.0.13

• Minor bug fixes

Known Bugs

• 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.

• Bad things sometimes happen when a parameterised type declaration contains a record declaration with a field type using the parameter. This can sometimes generate bad code; under some conditions it will pick up the wrong actual value of the parameter and give a run-time error.