September 2001 - Haskell

Re: Unicode support
by Marcin 'Qrczak' Kowalczyk 30 Sep '01

30 Sep '01

30 Sep 2001 14:43:21 +0100, Colin Paul Adams <colin(a)colina.demon.co.uk> pisze: > I think it should either be amended to mention the BMP subset of > Unicode, or, better, change the reference from 16-bit to 24-bit. 24-bit is not accurate. The range from 0 to 0x10FFFF has 20.087462841250343 bits. There is no simple answer to the question "how many bits is Unicode". It's hard to decide what should go into the standard when the support for Unicode in actual implementations is still limited. For example the standard doesn't say how characters are stored in files and the current status of what implementations do is not satisfactionary (they can't store characters above '\xFF'). Unfortunately there is no simple answer here too. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Haskell <-> Java and floats
by pachinko＠magicaldesk.com 30 Sep '01

30 Sep '01

Has anyone ever tried to pass/receive a float to/from a Java app? If so, how did you manage it? I need an algorithm for converting an IEEE 754 format float to a 32 bit integer? I want something that can convert a haskell float into a int that can be stored to disk for later input to a Java app that converts it back to a float with the Java floatToIntBits function. I think I'm OK in the reverse direction, converting an int into a float (as implemented by the Java intBitsToFloat function). The following link to the Java docs gives the bit masks and expression required to convert an int to a float. http://java.sun.com/products/jdk/1.2/docs/api/java/lang/Float.html Unfortunately, although the page gives a brief description of the the floatToIntBits function, specfically how to place the components of the floating point number into a 32 bit int, it doesn't describe how to extract those components. Things seem to be complicated a bit by things such as the hidden bit, and Java interpreting the floating point to the far left of the mantissa, instead of the far right. I found the following page describing how the floatToIntBits function works, but I think it's wrong, since when I try to run this function it gives a different integer that when I use the standard Java floatToIntBits function. Maybe the page describes a different version of the IEEE format? http://www.jos.org/redist/kore-0.0.7/java.lang.Float.src.html I'm not an expert on any of this - so any algorithm, in any language (including english), would be much appreciated. BTW - all of the above applies double (64 bit integer, doubleToIntBits/intBitsToDouble). _____________________________________________________________ Global Virtual Desktop http://www.magicaldesk.com

1 0

Re: Wish list: expanded defaulting, dependent types, reflection
by Ashley Yakeley 30 Sep '01

30 Sep '01

At 2001-09-29 17:07, Mike Gunter wrote: >class Add a b c | a b -> c where add :: a -> b -> c >instance Add Integer Integer Integer where add = (+) >pt1 = (3::Integer) `add` (4::Integer) -- Works fine, >--ft2 = (5::Integer) `add` 6 -- Fails OK, you're running across a fundamental design shortcoming in GHC's instance overlap calculation. What you want to do is this: class Add a b c | a b -> c where add :: a -> b -> c instance (Integral a,Integral b) => Add a b Integer where add a b = (toInteger a) + (toInteger b) pt1 = (3::Integer) `add` (4::Integer) ft2 = (5::Integer) `add` 6 So far so good. The trouble comes when you want to add your own type: instance (Integral b) => Add MyInt b MyInt where add (MkMyInt a) b = MkMyInt (a + (toInteger b)) Provided you don't declare 'instance Integral MyInt', the two instances will not de facto overlap. But GHC will complain that they do, because GHC's understanding of overlapping instances is excessively conservative. This is currently top of my list of GHC problems. GHC annoyingly ignores the class contexts and simply sees this: Add a b _ Add MyInt b _ ...from which it deduces that the instances overlap. So can't you just switch on -fallow-overlapping-instances and not worry about it? Ordinarily, yes, but for some reason that doesn't work when you have a dependent parameter in your class. It's like it's a different piece of code doing the checking, or something. I've entered a bug for this, see <http://sourceforge.net/tracker/?func=detail&aid=441389&group_id=8032&atid= 108032>. I don't know if this has been fixed in 5.02. -- Ashley Yakeley, Seattle WA

1 0

Re: Wish list: expanded defaulting, dependent types, reflection
by Mike Gunter 30 Sep '01

30 Sep '01

> >There does not seem to be a way to do everything I'd like in GHC even > >in its most permissive mode (I'm using "-fallow-overlapping-instances > >-fallow-undecidable-instances".) In particular, I'd like to use bare > >integer literals together with values of the types I define. > > Do you have a code example of what you're trying to do? Here's a simple example of the problem: class Add a b c | a b -> c where add :: a -> b -> c instance Add Integer Integer Integer where add = (+) pt1 = (3::Integer) `add` (4::Integer) -- Works fine, --ft2 = (5::Integer) `add` 6 -- Fails mike If you uncomment ft2, GHC (as expected) says: /home/gunter/haskell/hdl/PlusTest.hs:20: No instance for `Add Integer b c' arising from use of `add' at /home/gunter/haskell/hdl/PlusTest.hs:20 in the definition of function `ft2': (5 :: Integer) `add` 6 /home/gunter/haskell/hdl/PlusTest.hs:20: Ambiguous type variable(s) `b' in the constraint `Num b' arising from the literal `6' at /home/gunter/haskell/hdl/PlusTest.hs:20 In the second argument of `add', namely `6'

1 0

Re: Wish list: expanded defaulting, dependent types, reflection
by Ashley Yakeley 29 Sep '01

29 Sep '01

At 2001-09-29 09:11, Mike Gunter wrote: >There does not seem to be a way to do everything I'd like in GHC even >in its most permissive mode (I'm using "-fallow-overlapping-instances >-fallow-undecidable-instances".) In particular, I'd like to use bare >integer literals together with values of the types I define. Do you have a code example of what you're trying to do? -- Ashley Yakeley, Seattle WA

1 0

Re: Wish list: expanded defaulting, dependent types, reflection
by Mike Gunter 29 Sep '01

29 Sep '01

> You know about fundeps, right? This may help: > > class Add a b c | a b -> c where {add :: a -> b -> c;}; Indeed, it's quite hopeless without fundeps. They don't solve with the ambiguous-literal problem, though. mike

1 0

Re: Wish list: expanded defaulting, dependent types, reflection
by Ashley Yakeley 29 Sep '01

29 Sep '01

At 2001-09-29 09:11, Mike Gunter wrote: > class Add a b c where add :: a -> b -> c > >There does not seem to be a way to do everything I'd like in GHC even >in its most permissive mode (I'm using "-fallow-overlapping-instances >-fallow-undecidable-instances".) In particular, I'd like to use bare You know about fundeps, right? This may help: class Add a b c | a b -> c where {add :: a -> b -> c;}; -- Ashley Yakeley, Seattle WA

1 0

Wish list: expanded defaulting, dependent types, reflection
by Mike Gunter 29 Sep '01

29 Sep '01

I would like define arithmetic operations with heterogenous types. (I'm interested in sized types for an embedded hardware description language.) One approach would be to use multiple-parameter type classes; e.g: class Add a b c where add :: a -> b -> c There does not seem to be a way to do everything I'd like in GHC even in its most permissive mode (I'm using "-fallow-overlapping-instances -fallow-undecidable-instances".) In particular, I'd like to use bare integer literals together with values of the types I define. The more straightforward approach, using the standard fromInteger definition, runs up against the limitation of default mechanism to standard classes. What's the purpose of this limitation? Any chance GHC could optionally relax it? (Absent an implementation it's hard to be sure this is sufficient for my purposes.) Another scheme is to give GHC the -fno-implicit-prelude option and redefine fromInteger to return a type, say, ConstInteger, for which all of the operations have an instance. This seems to work for operations I am defining but makes it impossible to use bare literals as arguments to functions defined elsewhere (which are expecting an Int/Integer/Double/...) I think (I have no experience here!) I'd be happiest if GHC implemented dependent types. That would seem to solve this problem and others. Even if this broke most Haskell 98 code, I think I'd turn on the -fdependent-types option. A completely different approach would be to use the standard Haskell numeric classes (with homogeneous types) with the size-constraint system implemented in my Haskell code. This approach would be more attractive if my Haskell implementation provided a small amount of reflective capability. In particular, I would want to generate error messages with the source file, line number, and function. GHC does a very good job of reporting this information for type errors. Could it be made available to the program being compiled? (I could also use such a mechanism to make it possible to give sensible names to entities (wires, gate instances) in the output generated from the HDL.) So, my wish list is (1) dependent types, or (2) remove the restriction that default only works on standard classes and (3) a small amount of reflection (file,line number,function name) or (4) (best) a way to do what I need without (1)-(3). Thanks. mike

1 0

GHC 5.02 is released
by Julian Seward (Intl Vendor) 28 Sep '01

28 Sep '01

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 5.02 ============================================================ We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 5.02. This is the first version of GHC that has all of the following: * An interactive read-eval-print loop, similar to Hugs. You can load a mixture of compiled and interpreted modules; in particular, you automatically use the precompiled libraries, so your "interpreted" programs often run pretty fast. * Works solidly on Windows platforms. Installation is simple (Installshield); you don't have to install anything else; and GHC does not get confused if you also happen to have (say) Cygwin installed. * Implements the changes adopted for the (now almost finalised) Revised Haskell 98 Language and Library Reports. * The ability to emit "External Core", a documented typed intermediate language, suitable for slurping up into other tools. [Andrew Tolmach's work.] * A particularly thorough pre-release test programme. Some releases are more solid than others; this one is at the solid end of the spectrum. We fondly hope. So if you have been waiting to upgrade your GHC 4.08, this is the moment. How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. The source distribution is freely available via the World-Wide Web, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, Solaris and Win32 are also available. More details about what's new ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5.02 incorporates many small refinements and bug fixes over the previous stable release (5.00.2). There are no major language changes. - Implements Haskell 98 (revised) - Ability to emit External Core. GHC can't read External Core back in. Yet. - Much improved support for Windows platforms. Binary builds are now entirely freestanding. There's no need to install Cygwin or Mingwin to use it. It's a one-click-install-and-off-you-go story now. - Several small changes to bring GHC into line with the newest Haskell 98 report. - GHCi (the interactive system) now works on Windows. - Partial FFI support in GHCi. At the moment, foreign import (both static and dynamic) is supported on x86 and sparc platforms. - A compacting garbage collector, to try and reduce space use. - Ability to disconnect built-in numeric syntax from the supplied Prelude. This allows you to define your own arithmetic packages, which Haskell98 doesn't quite support. - Experimental: partial support for hierarchical module names. - Experimental: following heroic hacking by Ken Shan, 5.02 now works on Alpha (Tru64 only). Many 64-bit bugs have been shaken out. At the moment only the batch-mode compiler works -- no GHCi or native code generator yet. We've found and fixed more bugs than you could possibly imagine. A big thank-you to all those who reported bugs in the 5.00.X series. We claim to have fixed almost all reported bugs. In general we've spent a large amount of effort trying to improve the stability of the system relative to 5.00.X. (Famous last words ...) For full details see the release notes: http://www.haskell.org/ghc/docs/5.02/set/release-5-02.html Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * alpha-dec-osf{2,3} * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/5.02/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

2 1

RE: Haskell report (August release)
by Simon Peyton-Jones 28 Sep '01

28 Sep '01

A reasonable suggestion, but I'm afraid I don't want to make structural changes to the Report. Simon | -----Original Message----- | From: Mark Tullsen [mailto:mtullsen@cse.ogi.edu] | Sent: 27 September 2001 20:35 | To: Simon Peyton-Jones | Cc: haskell(a)haskell.org | Subject: Re: Haskell report (August release) | | | Simon, | | Here's a minor quibble with the organization of the Report | and Library, not with the content. Sorry if this has been | brought up before. | | In section 4.3.3, Derived Instances, of the Report there is | | The only classes in the Prelude for which derived instances are | allowed are Eq, Ord, Enum, Bounded, Show, and Read, all mentioned in | Figure 5, ... Classes defined by the standard libraries may also be | derivable. | | In the introduction to the Library Report there is | | Classes defined in libraries may be derivable. This report includes | the derivation of such classes when appropriate. | | Now, unless I missed something, the only class in the Library | Report which is derivable is Ix. | | I would argue for bringing the Ix class into the Report for | these reasons | | * One does not have to search through the Library Report to | determine | what is derivable. | | * I think one would expect that the Libraries contain stuff | that could be | implemented in Haskell by the user. Until Haskell has | the ability | to allow for user-defined derivable classes, Ix cannot be | defined by the user. | | - Mark |

1 0