Thanks for the patient explanation. I know it's too late, but ... On Tue, Apr 19, 2005 at 11:41:02PM +0100, Ian Lynagh wrote: > Given you suggest workarounds I'm going to assume this really means "why > isn't the new hugs in sarge?" and answer accordingly, but FWIW I don't > remember anything not on your lists above.
That too, but the specific point was that the decision to hold Hugs until the others were ready was based on library incompatibilities, and these seem to be rather minor. Indeed because hugs98-200503 supports a bit more of the libraries, one could argue that it's more compatible with ghc 6.2 than 200311 is. > The locale based filename thing in hugs is also a concern, though, in my > opinion. Currently two packages build-depend on hugs: haskell-utils and > cpphs. I think haskell-utils currently only uses filenames containing > a-zA-Z0-9./_ so we could wrap that in a script that sets the locale to C > (or maybe do that at the start of main?). That shouldn't be necessary -- all the locales in Debian agree with C on ASCII-only text. > cpphs currently accepts 8-bit > chars in filenames being #included, as does cpp; maybe you will argue > that making use of that is foolish, but nevertheless I think I would > rather drop the ability to "compile" with hugs in order to keep its > behaviour consistent. Do you mean #include's in the source file, which is read in text mode? That tends to illustrate why it's hard to go halfway (files but not strings). But, yes, there is a problem when the filenames come from getDirectoryContents, getArgs or getEnv. > We'll also have to go over any packages that stay using hugs to make > sure they are opening files in binary mode when appropriate etc. (In > principle this should be done regardless, but within the systems Debian > currently supports it's not been an issue thus far). Hugs is Suggest'ed by ctklight, haskell-mode, haskell-utils and haskell-doc. Presumably ctklight is in the same boat as cpphs. > Finally, it also means that if everything /did/ go into sarge then the > implementations would be less consistent with each other. In terms of > non-binary-IO this is probably a good thing, as we shouldn't be > encouraging people to use readFile etc as if they did binary IO. But for > filenames we just have 2 incompatible designs. I think I've said this > before, but while I applaud the efforts to put unicode support into > Haskell implementations I would have prefered a suitable replacement of > the IO libraries to have been designed first so that the problems with > unrepresentable filenames would never have come up. GHC just ignores the issue. I guess that ultimately it will have to do something similar, once those other libraries are available. I appreciate your point about waiting for the new library, but these things seem to take a very long time. And when that library does appear, a lot of code will need changing. Maybe Hugs has jumped the gun, but maybe there was no gun. It's a tradeoff, I just don't think it's a grave bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
