Re: weird :t uncurry flip
On 2002-08-09T15:52:04-0700, Hal Daume III wrote: Prelude :t uncurry flip forall a c b. (a - b - c, b) - a - c Um, what is weird about this type? -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig http://www.ethnologue.com/ msg04997/pgp0.pgp Description: PGP signature
Re: weird :t uncurry flip
On 2002-08-09T15:52:04-0700, Hal Daume III wrote: Prelude :t uncurry flip forall a c b. (a - b - c, b) - a - c Um, what is weird about this type? Shouldn't it be (a - b - (c,b)) - a - c ? like Prelude :t (\f - fst . f) forall a b a1. (a1 - (a, b)) - a1 - a ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: weird :t uncurry flip
Nevermind, I'm dumb :) -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Fri, 9 Aug 2002, Hal Daume III wrote: On 2002-08-09T15:52:04-0700, Hal Daume III wrote: Prelude :t uncurry flip forall a c b. (a - b - c, b) - a - c Um, what is weird about this type? Shouldn't it be (a - b - (c,b)) - a - c ? like Prelude :t (\f - fst . f) forall a b a1. (a1 - (a, b)) - a1 - a ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Text in Haskell: a second proposal
At 2002-08-08 23:10, Ken Shan wrote: 1. Octets. 2. C char. 3. Unicode code points. 4. Unicode code values, useful only for UTF-16, which is seldom used. 5. What handles handle. ... I suggest that the following Haskell types be used for the five items above: 1. Word8 2. CChar 3. CodePoint 4. Word16 5. Char I disagree, they should be: 1. Word8 2. CChar 3. Char 4. Word16 5. Word8 Let me elaborate. Files are funny because the information units they contain can be treated as both numbers and characters. No, a file is always a list of octets. Nothing else (ignoring metadata, forks etc.). Of course, you can interpret those octets as text using ASCII or UTF-8 or whatever, equally, you can interpret those octets as an image using PNG, JPEG etc. But those are secondary transformations, separate from the business of reading from and writing to a file. We should have Word8-based interfaces to file and network handles. Whether or not the old Char-based ones should be deprecated, or whatever, I don't know. As for Unicode codepoints, if there's to be an internationalisation effort for Haskell, the type of character literals, Char, should be fixed as the type for Unicode codepoints, much as it already is in GHC. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: UTF-8 library
anatoli [EMAIL PROTECTED] writes: Dependence on the current locale is EXTREMELY inconvenient. Imagine that you're writing a Web browser. Web browsers get input with MIME declarations, and shouldn't rely on *any* default setting. Instead, they should read [Word8] and decode the contents according to Content-Type/Content-Transfer-Encoding. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Storable tuples and what is 'alignment'?
On 06-Aug-2002, Alastair Reid [EMAIL PROTECTED] wrote: Andrew J Bromage [EMAIL PROTECTED] writes: This number is called the alignment, and a good rule of thumb for computing it is: instance Storable a where alignment a = sizeOf a `min` machine_word_size The way we calculate it in GHC and Hugs is: #define offsetof(ty,field) ((size_t)((char *)((ty *)0)-field - (char *)(ty *)0)) You shouldn't define offsetof() yourself. The C standard provides offsetof() in stdlib.h -- you should use that rather than defining it yourself. Defining offsetof() yourself is an error if stdlib.h is included, because you are stepping on the implementation's namespace. Furthermore, the definition there is not standard-conforming C code, since it dereferences a null pointer. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: UTF-8 library
On 06-Aug-2002, George Russell [EMAIL PROTECTED] wrote: Converting CStrings to [Word8] is probably a bad idea anyway, since there is absolutely no reason to assume a C character will be only 8 bits long, and under some implementations it isn't. That's true in general; the C standard only guarantees that a C character will be at least 8 bits long. But Posix now guarantees that C's `char' is exactly 8 bits. Posix hasn't taken over the world yet, and doesn't look like doing so in the near future. So Haskell should not limit itself to being only implementable on Posix systems. However, systems which don't have 8-bit bytes are getting very very rare nowadays -- it might well be reasonable for Haskell, like Posix, to limit itself to only being implementable on systems where C's `char' is exactly 8 bits. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Text in Haskell: a second proposal
Ken Shan [EMAIL PROTECTED] writes:
I suggest that the following Haskell types be used for the five items
above:
1. Word8
2. CChar
3. CodePoint
4. Word16
5. Char
On most machines, Char will be a wrapper around Word8. (This
contradicts the present language standard.)
Can you point out any machine where this is not the case? One with a
Haskell implementation, or likely to have one in the future?
If not, I don't see much point, and agree with Ashley to restrict
real IO to [Word8].
I like the Encoding data structure, though.
data Encoding text code
= Encoding { encode :: [text] - Maybe [code]
, decode :: [code] - Maybe [text] }
utf8 :: Encoding CodePoint Word8
iso88591 :: Encoding CodePoint Word8
Perhaps changing it to
data Encoding text code
= Encoding { encode :: text - Maybe code, ...}
so that
utf8 :: Encoding String [Word8]
but more importantly
jpeg :: Encoding Image [Word8]
Perhaps [Word8], if it is the basis for IO, should be the target for
*all* Encodings? And encoding, can it really fail? How about:
data Encoding text -- or rather, 'data_item' or something?
= Encoding {encode :: text - [Word8],
decode :: [Word8] - Maybe text}
?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Text in Haskell: a second proposal
On Fri, 2002-08-09 at 08:40, Ashley Yakeley wrote: At 2002-08-08 23:10, Ken Shan wrote: 1. Octets. 2. C char. 3. Unicode code points. 4. Unicode code values, useful only for UTF-16, which is seldom used. 5. What handles handle. ... I suggest that the following Haskell types be used for the five items above: 1. Word8 2. CChar 3. CodePoint 4. Word16 5. Char I disagree, they should be: 1. Word8 2. CChar 3. Char 4. Word16 5. Word8 Yes. Let me elaborate. Files are funny because the information units they contain can be treated as both numbers and characters. No, a file is always a list of octets. Nothing else (ignoring metadata, forks etc.). Of course, you can interpret those octets as text using ASCII or UTF-8 or whatever, equally, you can interpret those octets as an image using PNG, JPEG etc. But those are secondary transformations, separate from the business of reading from and writing to a file. Ack! We should have Word8-based interfaces to file and network handles. Whether or not the old Char-based ones should be deprecated, or whatever, I don't know. I think any notion of treating the _raw_ contents of a file as Chars must go, because it is simply incorrect. It's like a typo someone made, because for a moment, he got Haskell Char and C char mixed up. As for Unicode codepoints, if there's to be an internationalisation effort for Haskell, the type of character literals, Char, should be fixed as the type for Unicode codepoints, much as it already is in GHC. Ack. Sven Moritz ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Text in Haskell: a second proposal
At 2002-08-09 01:19, Sven Moritz Hallberg wrote: Whether or not the old Char-based ones should be deprecated, or whatever, I don't know. I think any notion of treating the _raw_ contents of a file as Chars must go, because it is simply incorrect. Right. Certainly we need to come up with _correct_ Word8-based file functions, and separately, text-encoding functions. After that we need to consider what is to be done with the existing expedient (and conceptually ugly) Char-based file functions. Should they be deprecated, or should we fix them with a particular encoding scheme such as UTF-8 or ISO 8859-1, or what? What about newline handling? etc. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Text in Haskell: a second proposal
Here's my take on the Unicode issue. Summary: unless there's a very
good reason, I don't think we should decouple encoding/decoding from
I/O, at least for the standard I/O library.
Firstly, types. We already have all the necessary types:
- Char, a Unicode code point
- Word8, an octet
- CChar, a type representing the C 'char' type
The latter two are defined by the FFI addendum.
Taking hGetChar as an example:
hGetChar :: Handle - IO Char
This combines, IMO, two operations: reading some data from the file, and
decoding enough of it to yield a Char. Underneath the hood, the Handle
has a particular encoding associated with it. In GHC, currently we have
two encodings, ISO8859 (aka binary, but we shouldn't use that term
because the I/O library works in terms of Char) and MS-DOS text. We
could easily extend the set of encodings to include UTF-8 and others.
Seeking only works on Handles with a 1-1 correspondence between handle
positions and characters (i.e. in the ISO encoding).
Why combine I/O and {en,de}coding? Firstly, efficiency. Secondly,
because it's convenient: if we were to express encodings as stream
transformers, eg:
decodeUTF8 :: [Word8] - [Char]
Then we would have to do all our I/O using lazy streams. You can't
write hGetChar in terms of hGetWord8 using this: you need the non-stream
version which in general looks something like
decode :: Word8 - DecodingState
- (Maybe [Char], DecodingState)
for UTF-8 you can get away with something simpler, but AFAIK that's not
true in general. You might want to use compression as an encoding, for
example. So in general you need to store not only the DecodingState but
also some cached characters between invocations of hGetChar. It's
highly unlikely that automatic optimisations will be able to do anything
useful with code written using the above interface, but we can write
efficient code if the encoder/decoder can work on the I/O buffer
directly.
There's no reason why we shouldn't provide encoders/decoders as a
separate library *as well*, and we should definitely also provide
low-level I/O that works with Word8.
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
AlphaBeta (chess) in Haskell
Hello. Does anyone know of a AlphaBeta/Minimax module for haskell, and / or a chess module? I've found several references on the web, but no code. There are little examples in whyfp paper and in some other Haskell related paper, but both are far from complete. Also, I've found a reference to a working mate-problem solver which was used for HAT testing, but also, no code. Maybe someone has something already working which could be used as a basis. My plan is to provide a generic AlphaBeta module which could be used for different kind of two-player games. -- Thanks, Mario ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: AlphaBeta (chess) in Haskell
Does anyone know of a AlphaBeta/Minimax module for haskell http://www.informatik.uni-leipzig.de/~joe/projekte/phutball/clients/alpha-beta/ this is rather generic. it's applied in the Flankengott client for the Philosopher's Football game http://theopc.informatik.uni-leipzig.de/~joe/phutball/ for a brief description, search for Modules for Boardgames in http://haskell.cs.yale.edu/communities/05-2002/html/report.html -- -- ungefähr drittes leipziger einrad-picknick am 18. august -- http://www.informatik.uni-leipzig.de/~joe/juggling/picknick/ -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/207 -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Text in Haskell pedantry
Ashley wrote [quote]No, a file is always a list of octets. Nothing else (ignoring metadata, forks etc.). [/quote] On MVS at least a file is a list of list of octets, because record boundaries are not handled by a record boundary character but by other means. There are still more horrible details of MVS access methods no-one here will want to know about. I think it would be more correct to say a file is always a list of C characters, since while this may not be true, at least every system in the foreseeable future is going to make it possible to pretend it is, at least for the sort of files people are likely to want to process using Haskell. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
George Russell [EMAIL PROTECTED] writes: Ketil wrote (quoting Ken) On most machines, Char will be a wrapper around Word8. (This contradicts the present language standard.) Can you point out any machine where this is not the case? One with a Haskell implementation, or likely to have one in the future That's easy enough. On Sun/Solaris (which I use and which came out as being very popular on the Haskell survey) characters are SIGNED, so the values run from -128 to 127 and the wrapper would be not Word8 but Int8. How does the file system know the difference? I think you mean that C chars on Solaris are signed, not that files and sockets don't contain octets. I think this demonstrates the perils of saying It's safe to assume everything is 8 bit because everything is now. I don't think it does so at all. There may be a peril in assuming octet IO, but frankly I think trying to anticipate different futures will only make things messy, and have a great likelyhood of turning out useless anyway. Remember, worse is better. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
Ketil Z. Malde wrote: George Russell [EMAIL PROTECTED] writes: Ketil wrote (quoting Ken) On most machines, Char will be a wrapper around Word8. (This contradicts the present language standard.) Can you point out any machine where this is not the case? One with a Haskell implementation, or likely to have one in the future That's easy enough. On Sun/Solaris (which I use and which came out as being very popular on the Haskell survey) characters are SIGNED, so the values run from -128 to 127 and the wrapper would be not Word8 but Int8. How does the file system know the difference? I think you mean that C chars on Solaris are signed, not that files and sockets don't contain octets. Well, you can define the files to contain only directed graphs if it makes you feel any happier, but the fact is that the standard access functions return characters*, and on Solaris the default representation of a characters is as a signed quantity. *. Though in fact it must be admitted that some, such as fgetc, actually return an integer usually containing an _unsigned_ char, so that negative values can be preserved for other information. Life can be very complicated sometimes. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
George Russell [EMAIL PROTECTED] writes: How does the file system know the difference? I think you mean that C chars on Solaris are signed, not that files and sockets don't contain octets. Well, you can define the files to contain only directed graphs if it makes you feel any happier, but the fact is that the standard access functions return characters*, What standard access functions? The functions found in C libraries? From Solaris man pages, the read system call reads bytes into a void * buffer. I would propose that the standard access functions in *Haskell* return Word8, *regardless* of operating system or C libraries. As long as you have primitives to do octet IO, this should be straightforward, regardless of whether the OS (or other programming languages or libraries) thinks the octet is signed or not. and on Solaris the default representation of a characters is as a signed quantity. Why should we care? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
Ketil Z. Malde wrote: [snip] and on Solaris the default representation of a characters is as a signed quantity. Why should we care? [snip] If you want to talk to any C libraries or C programs which use characters, which some of us do. GNU readline and regex come to mind. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ANNOUNCE: hmake-3.06
hmake-3.06 -- We are pleased to announce a fresh, bugfix, release of hmake, the Haskell compilation manager. The usual hmake highlights -- * hmake knows about interface (.hi) files. * hmake is compiler-independent, and allows multiple compiler versions. * hmake is aware of many pre-processors. * hmake can generate object files in a separate directory from your sources. * hmake understands the library package system. * hmake understands hierarchical module namespaces. * hmake understands the Hat tracer. What's new in 3.06 -- * Better handling of package libraries. Previously, the package import directories were detected at installation time, so the addition of a new package required hmake-config to be invoked to update the config database. Also, because all of the package dirs were searched on every invocation, hmake could not warn of a missing -package flag. Now, package dirs are detected at runtime, and only for the requested packages - this fixes both problems. * Added the cmdline option list to hmake-config to display the set of Haskell compilers known to hmake. * Bugfix for the -hat option. Ensure that if a file goes through cpp before hat-trans, the resulting .hx file is moved from the temporary dir back to the build dir. * Bugfix, to ensure that hmake isn't confused by the escaped character \\ in a literal string. More info, and downloads http://www.cs.york.ac.uk/fp/hmake/ Regards, Malcolm Wallace ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: AlphaBeta (chess) in Haskell
Mario Lang [EMAIL PROTECTED] writes: Also, I've found a reference to a working mate-problem solver which was used for HAT testing, but also, no code. The chess end-game solver we used with Hat is one written by Colin Runciman. The code is attached (the main program is in Mate.hs), in a tar file together with several example board positions and solutions. Regards, Malcolm P.S. We plan to release a whole bunch of small Haskell programs of this nature at some point in the near future. Mate.tar Description: Binary data
Re: Yet more text pedantry
George Russell [EMAIL PROTECTED] writes: Ketil Z. Malde wrote: [snip] and on Solaris the default representation of a characters is as a signed quantity. Why should we care? If you want to talk to any C libraries or C programs which use characters, which some of us do. GNU readline and regex come to mind. Yes, which is why we all agree on CChar for FFI purposes. But we were discussing IO, weren't we? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
Ketil Z Malde wrote: George Russell [EMAIL PROTECTED] writes: Ketil Z. Malde wrote: [snip] and on Solaris the default representation of a characters is as a signed quantity. Why should we care? If you want to talk to any C libraries or C programs which use characters, which some of us do. GNU readline and regex come to mind. Yes, which is why we all agree on CChar for FFI purposes. But we were discussing IO, weren't we? Well for example I mentioned regex. Using a different sort of char will potentially break regex, since it means the meaning of a range of characters [A..B] will change if A and B have different signs. So either RegexString will have to do complicated transformations of the regular expression string to fix this (you will need to buy Simon Marlow several drinks) or else the manual will have to admit that the ordering used by RegexString differs from that used anywhere else. This is just something that comes to mind, there are probably lots of other cases where C libraries we might want to interface to provide things which depend on the order of char. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GHC bug,or Hugs feature?
I believe the incompatibilities are explained thus:
In section 4.5.1 of the Haskell Report it only states that
A dependency analysis transformation is first performed to increase
polymorphism
But hugs appears to be using a more refined version of the dependency
analysis as explained in section 11.6.3 of Mark Jones' paper Typing
Haskell in Haskell. Read that section.
- Mark
Arthur Baars wrote:
In Mark Jones' paper Typing Haskell in Haskell, I found the following
example(in the section on binding-groups):
f :: Eq a = a - Bool
f x = x==x || g True
g y = y=y || f True
According to the paper the inferred type of g should be:
g::Ord a = a - Bool
Hugs infers this type but GHC infers the following *ambiguous* type:
*Main :i g
-- g is a variable, defined at Test.hs:25
g :: forall a. (Eq a) = Bool - Bool
When adding an explicit type signature for g, Hugs happily accepts the code,
but GHC gives the following error:
f :: Eq a = a - Bool
f x = x==x || g True
g :: Ord a = a - Bool
g y = y=y || f True
Test.hs:24:
Couldn't match `{Ord a}' against `{Eq a1}'
When matching the contexts of the signatures for
g :: forall a. (Ord a) = a - Bool
f :: forall a. (Eq a) = a - Bool
The signature contexts in a mutually recursive group should all be
identical
When generalising the type(s) for g, f
Failed, modules loaded: none.
I think the problems are caused by differences in the binding group analysis
in Hugs and GHC.
Malcolm, could you check what NHC says about the examples above?
Cheers,
Arthur
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Yet more text pedantry
Can we stop the pedantry and have some people go off in a corner and produce a design which: 1) Solves some of the internationalization issues notably those involving unicode and locales. 2) Will work on a decent range of existing and plausible future Windows and Unix boxes. (Embedded systems, mainframes, PDAs, etc. are also worthwhile but since we would not run the full Haskell libraries on them they are of secondary importance.) That is, follow a standard spec if you can but when the spec becomes impossible to use because of some wild generalization which covers situations that will never come up, make a few assumptions based on what real systems do. 3) Can support nearly all of the current Haskell '98 libraries without change and as much as possible of the Hugs-GHC/hslibs/hierarchial libraries with slight changes. This is partly because, for all its faults, the current interface has the virtue of being simple. I envisage a veneer which implements the old interface on top of the new design. That is, the new design might expose all kinds of information about the encoding in the typesystem or through conversion functions or whatever but this complexity could be hidden behind an interface which reads and writes characters and does something plausible when it encounters UTF-32 and friends. 4) Relies on (and plays well with) Haskell'98 and approved addenda. (It's possible to meet this goal by lobbying for other common extensions to become approved addenda.) 5) Someone is going to produce a decent quality implementation for. (Talk is cheap and all that...) This is much easier now that both Hugs and GHC are working from the same source tree for libraries (with suggestions that NHC will follow suit). -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: hmake-3.06
On Fri, 9 Aug 2002, Malcolm Wallace wrote: hmake-3.06 -- We are pleased to announce a fresh, bugfix, release of hmake, the Haskell compilation manager. www.cs.york.ac.uk seems to be down. Does anyone know of a mirror that might have the new release, or when the home site will be back up? Thanks in advance, Murray Gross ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
