🚀 go-pugleaf

In article <11396@alice.UUCP> dbm@alice.UUCP (David MacQueen) writes:

   Standard ML does have references and assignments, and some implementations
   (such as Standard ML of New Jersey) have arrays with destructive array
   update.  So it is possible to define hash tables.  src/util/intmap.sml
   in the SML of New Jersey distribution is one such definition.

Yes, but I thought we weren't supposed to talk about those sort of 
perversions here, unless they guaranteed Ref. Transparency :-)

Still, this thread, and the parallel discussion in comp.lang.prolog on
declarative arrays, did put me in mind of one idea:

Since workstation screens have got bigger and bigger, with more and more
bit-planes, a lot of work has gone into producing chips which can copy and
move large blocks of contiguous memory very quickly. Has anybody ever tried
applying these BLTers to the problem of declarative arrays? After all,
the main difficulty with most schemes is that whilst they can catch most
cases where the physical array can be reused, most of them 
seem to get really complex when applied to examples that weren't in 
appendix A of the paper describing them :-) 

If you have a fast BLTer behind the stumps, you should be able to use
a simpler algorithm, which combined with compile-time garbage collection
and a clever instruction scheduler, should make it possible to have all
copying performed in parallel with useful work. 

Although copying will turn over a lot of memory, the holes in the heap
left will be precisely the right size for further generations of the same
array. 

Has anybody tried this approach? 

Simon
--
 sispero@compulink.cix.co.uk 		       ..!mcsun!ukc!slxsys!cix!sispero
------------------------------------------------------------------------------
The Poll Tax.    | Saddam Hussein runs     | +44-(0)81-500-3000 
I'm Not. Are you?| Lotus 123 on Apple Macs |"Read my lips. No Nuke Tactics"