(Aside for those who follow the ghc-bugs list: I got 2.04 to build on
Solaris using 0.29 (thank you Alex Ferguson for the build.mk file!),
and 2.05 seems to be building OK as well, so far.  So I won't be
begging for a binary distribution...)

Some questions about arrays:

The Haskell 1.4 Library report, in the Array section, says:

"
The second argument of "array" is a list of associations of the form
(index, value). Typically, this list will be expressed as a
comprehension. An association (i, x) defines the value of the array at
index i to be x. The array is undefined (i.e. _|_) if any index in the
list is out of bounds. If any two associations in the list have the
same index, the value at that index is undefined (i.e. _|_). Because
the indices must be checked for these errors, "array" is strict in the
bounds argument and in the indices of the association list, but
nonstrict in the values. ... "
^^^^^^^^^
  It sounds like, according to this specification, there has to be a thunk
for every element of the array.  This brings up the usual trade-off: this is
elegant and flexible, but slow.
------------------------------------------------------------
??? - For generic GHC Array's, is a thunk created for each individual array
element?  That is, if I do

a = array (1,10) (zip [1..10] (repeat 1))
main = print (a!1)

will a!2 through a!10 all be allocated and evaluated, even though they're
not used?
  Or are all the elements of the Array a "forced" at once?  (If this differs
from the Library Report spec. above, it might be good to put that in the
documentation... though personally, I'm happy with this solution.)
------------------------------------------------------------
??? - As it stands, all the elements of an Array are boxed, because Array is
a polymorphic type.  Could you add {-#SPECIALISE -} pragmas to the part of
the Prelude that defines "Array"s to get arrays of unboxed things?  It sounds
like this would be very difficult, if Arrays are implemented exactly as the 
Library report seems to describe, with a thunk for every element (or
something equivalent.)

  I think it might be useful in many situations to have an array
in which all the elements were evaluated at once.  For one thing, you could
unbox the elements of the array, which should make them faster.  Also, there
are fewer thunks.  As usual, you lose language flexibility.  Still, it seems
sort of analogous to creating a Complex type which requires both the real
and imaginary components to be defined.  Also, you're allocating space for
the whole array anyways, so maybe it's reasonable to assume the whole thing
(or at least, the part defined by the second argument to "array") should be
filled in.

  Then again, the speed gain from not building thunks would still be offset
by the speed loss from having all the elements boxed (if they were in fact
boxed...)

  Or, if MutableArrays are strict in state, I could write array accessing
functions for every type of array that I was going to use; but it seems that
just using C would be simpler at that point...
------------------------------------------------------------
  Thanks for any advice,

  Josh

-- 
Josh Burdick ([EMAIL PROTECTED])
http://www.cs.umd.edu/~burdick

Reply via email to