Re: [Haskell-cafe] Re: File path programme

Stefan Monnier <[EMAIL PROTECTED]> writes: >> The various UTF encodings do not have this particular problem; if a UTF >> string is valid, then it is a unique representation of a unicode string. >> However, decoding is still a partial function and can fail. > > And while it is partly true, it is qu

Re: [Haskell-cafe] Looking for these libraries...

On Thu, Jan 27, 2005 at 02:45:25PM +0100, Marcin 'Qrczak' Kowalczyk wrote: > John Goerzen <[EMAIL PROTECTED]> writes: > > > I'm looking for libraries / interfaces to these systems from Haskell: > > > > LDAP > > ncurses > > zlib (the one in darcs doesn't suit my needs) > > bz2lib > > I once wrapp

[Haskell-cafe] Re: JVM-Bridge with Kaffe

In article <[EMAIL PROTECTED]>, John Goerzen <[EMAIL PROTECTED]> wrote: > I could not convince jvm-bridge's Native/configure to even see a gcj > environment. That's because GCJ is commented out in jvm.list. > Kaffe worked (after updating the include path to > /usr/lib/kaffe/include). However,

Re: [Haskell-cafe] File path programme

Ben Rudiak-Gould wrote: > Symbolic links complicate things a bit, since they are followed like > edges but are actually paths. Actually, they're essentially arbitrary byte strings. The OS doesn't automatically require them to be valid paths. Most of the API functions to which you might pass a

Re: [Haskell-cafe] File path programme

Keean Schupke wrote: > >I guess it's just that I'm more concerned with making possible what is > >currently impossible (according to the library standards)--that is, using > >FFI and IO on the same file--rather than just adding utility features that > >application developers could have written th

[Haskell-cafe] The Nature of Char and String

Char in Haskell represents a Unicode character. I don't know exactly what its size is, but it must be at least 16 bits and maybe more. String would then share those properties. However, usually I'm accustomed to dealing with data in 8-bit words. So I have some questions: * If I use hPutStr on a

Re: [Haskell-cafe] File path programme

On Sun, Jan 30, 2005 at 02:17:01PM +, Glynn Clements wrote: > Ben Rudiak-Gould wrote: > > > pathToForeign :: p -> IO (Ptr CChar) > > > pathFromForeign :: Ptr CChar -> IO p > > > > This interface is problematic. Is the pointer returned by pathToForeign > > a heap pointer which the caller is

Re: [Haskell-cafe] File path programme

robert dockins wrote: > > I don't pretend to fully understand various unicode standard but it > > seems to me that these problems are deeper than file path library. The > > equation (decode . encode) > > /= id seems confusing for me. Can you give me an example when this > > happen? > > I am pre

Re: [Haskell-cafe] Re: File path programme

(BMarcin 'Qrczak' Kowalczyk wrote: (B (B> >> The various UTF encodings do not have this particular problem; if a UTF (B> >> string is valid, then it is a unique representation of a unicode string. (B> >> However, decoding is still a partial function and can fail. (B> > (B> > And while it is

Re: [Haskell-cafe] File path programme

Ben Rudiak-Gould wrote: > Is there an MSDN page that actually gives a grammar, or at least a > taxonomy, of Win32 pathnames? That would be useful. It would also be longer than "War and Peace", once you start allowing for MS-DOS "8.3" pathnames, codepages, the fact that anything anywhere which c

Re: [Haskell-cafe] The Nature of Char and String

John Goerzen wrote: >Char in Haskell represents a Unicode character. I don't know exactly >what its size is, but it must be at least 16 bits and maybe more. >String would then share those properties. > >However, usually I'm accustomed to dealing with data in 8-bit words. >So I have some questions:

Re: [Haskell-cafe] File path programme

Glynn Clements <[EMAIL PROTECTED]> writes: >> Then of course there's the issue that Win32 edge >> labels are Unicode, while Posix edge labels are [Word8]. Hmm. > > Strictly speaking, they're [CChar], but I doubt that anyone will ever > implement Haskell on a platform where a byte isn't 8 bits wid

Re: [Haskell-cafe] File path programme

David Roundy <[EMAIL PROTECTED]> writes: > No, it's not Unix-specific, it's portable. If you want to write > portable C code, you have to use the standard library, which means > that file names are represented as Ptr CChar. I disagree. We are talking about portable Haskell, not portable C. The n

Re: [Haskell-cafe] File path programme

Glynn Clements <[EMAIL PROTECTED]> writes: > And it isn't a theoretical issue. E.g. in an environment where EUC-JP > is used, filenames may begin with $)B (designate JISX0208 to G1), > or they may not (because G1 is assumed to contain JISX0208 initally). I think such encodings are never used as d

[Haskell-cafe] Re: mathematical notation and functional programming

Chung-chieh Shan wrote: On 2005-01-28T20:16:59+0100, Henning Thielemann wrote: I can't imagine mathematics with side effects, because there is no order of execution. To clarify, I'm not saying that mathematics may have side effects, but that the language we use to talk about mathematics may have si

Re: [Haskell-cafe] File path programme

On Sun, Jan 30, 2005 at 09:25:00PM +0100, Marcin 'Qrczak' Kowalczyk wrote: > David Roundy <[EMAIL PROTECTED]> writes: > > > No, it's not Unix-specific, it's portable. If you want to write > > portable C code, you have to use the standard library, which means > > that file names are represented as

[Haskell-cafe] Re: File path programme

On 2005-01-30, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > Glynn Clements <[EMAIL PROTECTED]> writes: > >> And it isn't a theoretical issue. E.g. in an environment where EUC-JP >> is used, filenames may begin with $)B (designate JISX0208 to G1), >> or they may not (because G1 is assumed

Re: [Haskell-cafe] Re: File path programme

Aaron Denney <[EMAIL PROTECTED]> writes: >> It provides variants of UTF-16/32 with and without a BOM, but >> UTF-8 only has the variant with a BOM. This makes UTF-8 a stateful >> encoding. > > I think you mean "UTF-8 only has the variant without a BOM". No, unfortunately. Unicode standard section

[Haskell-cafe] Re: File path programme

On 2005-01-30, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote: > Aaron Denney <[EMAIL PROTECTED]> writes: > >>> It provides variants of UTF-16/32 with and without a BOM, but >>> UTF-8 only has the variant with a BOM. This makes UTF-8 a stateful >>> encoding. >> >> I think you mean "UTF-8 only

Re: [Haskell-cafe] Re: File path programme

Aaron Denney <[EMAIL PROTECTED]> writes: > Better yet would be to have the standard never allow the BOM. If I could decide, I would ban the BOM in UTF-8 altogetger, but I'm afraid the Unicode Consortium doesn't want to do this. Miscosoft Notepad puts a BOM in UTF-8 encoded files. -- __("<

Re: [Haskell-cafe] The Nature of Char and String

On Sun, Jan 30, 2005 at 07:39:59PM +, Ben Rudiak-Gould wrote: > > * If I use hPutStr on a string, is it guaranteed that the number of > > 8-bit bytes written equals (length stringWritten)? > > Yes, if the handle is opened in binary mode. No if not. Thank you for the informative response. I

Re: [Haskell-cafe] Re: File path programme

Marcin 'Qrczak' Kowalczyk writes: > AFAIK MacOS normalizes filenames, but using a slightly different > algorithm than Unicode (perhaps just an older version). According to , Mac OS X uses different forms depending on the file system. | For exampl

[Haskell-cafe] Re: ocr'ed version of "The implementation of functional languages"

On 9005 day of my life Matthew Roberts wrote: > I have just embarked on creating a ocr'ed version of the jpeg images > that have been made available for "The implementation of functional > languages". I have high-resolution scans of this books. If Simon permits, I will create OCR from these sca

Re: [Haskell-cafe] Re: ocr'ed version of "The implementation of functional languages"

On Monday, January 31, 2005, at 05:48 PM, Ivan Boldyrev wrote: On 9005 day of my life Matthew Roberts wrote: I have just embarked on creating a ocr'ed version of the jpeg images that have been made available for "The implementation of functional languages". I have high-resolution scans of this book