Marcin 'Qrczak' Kowalczyk (qrczak@knm.org.pl)
8 Jan 2001 18:32:54 GMT
Mon, 8 Jan 2001 16:01:48 +0000, Malcolm Wallace <malcolm-nhc@cs.york.ac.uk> pisze: > > Array.// takes time size_of_array * number_of_changed_elements. > > Actually, I think: size_of_array + number_of_changed_elements, (*), because it uses List.\\ to determine the set of unchanged indices. (+) would be OK IMHO. I believe that Array.// is not possible to implement in nhc without an additional function in C. The only (?) function which is able to deteremine the union of the set of indices (or its complement), primVector, unconditionally puts bottoms in missing and duplicated places. > I imagine we could go to a 16- or 32-bit representation in object > code without too much difficulty. I wouldn't be keen on adopting > a variable-width coding like UTF-8, unless you can point me in the > direction of a C-library which could do most of the work for me...? I guess that using the array of 32-bit words for strings which contain characters above '\xFF' would be the best way. At least given the way they appear in the generated C files - I don't know internals of nhc's code generation to judge it. ghc uses UTF-8 because it outputs them as C string literals and does not have "[Word32] literals" in the code generation. Encoding and decoding functions are written in Haskell. It uses a modified UTF-8 with '\0' encoded as "\xC0\x80", to have '\0' available as the end of string mark. Strings are in UTF-8 if they contain characters outside '\1'..'\xFF', and in ISO-8859-1 otherwise. QForeign now supports Unicode in nhc, but I had to replace some character literals with "chr int_value"s and conditionally skipped places where I didn't bother to do it (well, currently I skip too few and some modules compile but don't work correctly). QForeign is being continuously updated in CVS: cvs -d:pserver:anonymous@cvs.qforeign.sourceforge.net:/cvsroot/qforeign \ login (empty password) cvs -d:pserver:anonymous@cvs.qforeign.sourceforge.net:/cvsroot/qforeign \ -z3 get qforeign > Most of the explicit constructors in the IOError datatype are going to > vanish soon anyway, leaving just IOErrorC, IOErrorEOF, and IOErrorUser. > There is no currently-exported interface function that allows you > to throw an IOErrorC with a specific ErrNo (or Int), but I can offer > you the opportunity to specify one if you like. :-) What signature > do you prefer? Where would you like it to be exported from? It is still quite fluid. The FFI libraries currently being agreed on allow to throw (perhaps should be: construct) an error based on an errno value and a string describing the location the error occured at (function name). Textual descriptions are currently provided by us, but will probably be taken from strerror. So I assume that I would want to access nhc's IOErrorC construction function as it stands now, together with ErrNo constructors. I would not use the filename part yet, but since it is present in nhc, I will talk to the FFI people and perhaps we would want to add it to the interface. I don't mind if errno values are ErrNo or Int. The FFI libraries take the number as a newtyped CInt, but I can have an easy machinery to convert them for nhc (as long as I know what to do with unknown errors). I don't mind where it is exported from. All this can change... -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTĘPCZA QRCZAK