Re: ghc image size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 14 December 2001 11:09, Krasimir Angelov wrote: Executables are smaller when build them with dynamic libraries. Unfortunately dynamic libraries are supported only from ghc-4.08.X for Windows. I am not sure for ghc-5.02.1 looks like it's not that bad under linux orion:malfunctor$ ls -al ./test-malfunctor - -rwxrwxr-x1 exa exa608222 Sep 1 05:28 ./test-malfunctor orion:malfunctor$ ldd test-malfunctor libm.so.6 = /lib/libm.so.6 (0x40032000) libgmp.so.3 = /usr/lib/libgmp.so.3 (0x40054000) libc.so.6 = /lib/libc.so.6 (0x40076000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) that's a haskell app btw, cheers, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8G0msfAeuFodNU5wRAsIDAJ9w3kgGAGXv6EY50HJNvjcudhCG4wCeIOcD eC8H1v0Y+QOgDYuWOZBbaUw= =ypyZ -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: Hugs98 Christmas release
--
__ __ __ __ ___
_
|| || || || || || ||__ Hugs 98: Based on the Haskell 98
standard
||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001
||---|| ___|| World Wide Web: http://haskell.org/hugs
|| || Report bugs to: [EMAIL PROTECTED]
|| || Version: Dec
2001 _
--
We are pleased to announce a new release of Hugs98, a Haskell
interpreter and programming environment for developing cool Haskell
programs. Sources and binaries are freely available on the
World-Wide Web.
The most important features of this new release are:
- The incompatibilities between Hugs and the Haskell Graphics Library
have been fixed, and binaries for the HGL are now available on the
Hugs download page.
- The missing standard libraries Directory, CPUTime, Time and Locale
have been added along with a complete implementation of
Haskell98 IO.
- Hugs is now delivered with most of the hslibs libraries installed
in the lib/exts/ directory. The added modules cover the Edison,
Parsec, HaXml, QuickCheck, concurrent, monad, and html
subdirectories
of hslibs.
- The :set option now refuses the user to set a module search path
that doesn't contain the Prelude. This is to protect users from
accidentally rendering their Hugs setups unusable, esp. so on
Windows machines where the options are persisted to the Registry.
- MacOS X is now one of the supported unix ports, with pre-built
binaries available on the download page.
- Experimental support is provided for hierarchical module names,
where a module name A.B.C is mapped onto the file path
A/B/C{.hs,.lhs} and appended to each of the path prefixes in
HUGSPATH until the name of a readable file is found.
Most reported bugs have also been fixed; however, some issues still
remain. See the heading Hugs Bugs Features on the Hugs web site
for further information.
Send email to [EMAIL PROTECTED] to join the hugs-users
mailing list. Bug reports should be sent to [EMAIL PROTECTED]
Send email to [EMAIL PROTECTED] to subscribe to the
hugs-bugs list.
The home page for Hugs is at http://www.haskell.org/hugs.
--
The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the
Yale Haskell Group, and the Oregon Graduate Institute of Science and
Technology, 1994-2001, All rights reserved. It is distributed as
free software under the license in the file License, which is
included in the distribution.
--
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Announce: Hugs Graphics Library
We are pleased to announce a new release of the Hugs Graphics Library, version 2.0.4. The Hugs Graphics Library gives the programmer access to the most interesting and portable parts of the Win32 and X11 library. The library is distributed as open source and is suitable for use in teaching and applications. This version is compatible with the December 2001 release of Hugs, but won't work with the February 2001 release. This version supports: * filled and unfilled 2-dimensional objects (text, lines, polygons, ellipses). * Bitmaps (Win32 version only, for now). * Control over text alignment, fonts, color. * Simple input events (keyboard, mouse, window resize) to support reactivity. * Timers and double-buffering to support simple animation. * Use of concurrency to avoid the usual inversion of the code associated with event-loop programming. * Multiple windows may be handled at one time. To keep the library simple and portable, the library makes no attempt to support: * User interface widgets (menus, toolbars, dialog boxes, etc.) * Palette manipulation and other advanced features. * Many kinds of input event. The library can be downloaded from: http://www.haskell.org/graphics/. Installation instructions are in graphics-2.0.4/Install. Bug reports should be sent to [EMAIL PROTECTED] Enjoy! ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Integer Enum ?
Frank Dellaert wrote: Hi I'm not entirely clear how Integer can be an Enum instance. I thought Integer was arbitrary size, while for the Enum class you need to define a mapping from and to Int, which is bounded (in a machine dependent way, even ?). I'm probably missing something obvious... You're right to wonder about that. It's even worse than you thought. Float and Double are also Enum instances! IMHO, this is a wart in the Haskell definition. Enum is used for two purposes: to support the [x,y..z] syntactic sugar, and to define conversion to/from Int. I think everybody agrees that the [x,y..z] syntax should support Integers, so it has to be an instance of Enum. I suspect that for convenience, the fromEnum and toEnum functions were put in the class to allow easier definitions of new Enum instances for small bounded enumerations. It has the undesireable effect of forcing the implementer of an Enum instance to produce a mapping to/from Int even when it doesn't make any sense. My preference would be to define them as errors in that case; the Haskell Report does not. The Report defines fromEnum for Float and Double; it is silent on Integer, and the Ratio module in the Library Report defines fromEnum for Ratio. In all cases, the reports specify truncation to integer, and there is a comment that the conversion may overflow. Complex does not define an Enum instance, even though it would make sense to me to be able to write [0, 1:+2 .. 5:+10] or the like. I guess fromEnum for Complex, if it existed, would have to just truncate the imaginary part! Regarding the Integer instance, Hugs only issues errors on fromEnum x where x is out of range. GHC just returns the value modulo 2^32, or something like that. My advice is to just ignore fromEnum and toEnum for Integer, Float, Double, and Ratio, and, if you need to define your own Enum instance, just define some reasonable mapping to Int, and don't worry much about truncation and overflow... the Haskell designers didn't! :) Matt Harden P.S. I hope the Haskell designers don't take offense; in reality, they have nothing but my deepest respect! ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: gcd 0 0 = 0
From: Simon Peyton-Jones [EMAIL PROTECTED] Date: Fri, 14 Dec 2001 01:18:56 -0800 ... If someone could write a sentence or two to explain why gcd 0 0 = 0, (ideally, brief ones I can put in the report by way of explanation), I think that might help those of us who have not followed the details of the discussion. Well, Serge and I have both offered variations on the real reason why mathematicians agree that gcd 0 0 = 0. I prefer my simpler specialized-for-integers version, but I suspect even that is more mathematics than you want. At the other extreme, you could follow Knuth and simply state: it is convenient to set gcd(0, 0) = 0, but that seems a bit unconvincing. If I were in your shoes, I'd simply pass the buck to the authorities by saying something like: Mathematicians agree that gcd(0, 0) = 0. Incidentally, somebody wrote here that Common Lisp defines `(gcd 0 0)' to be 0, but it looks to me like all the language definition really does is state that `(gcd)' (no arguments) is 0 because 0 is an identity for this operation (which is technically false, but never mind), from which it is natural for the reader to conclude that `(gcd 0 0)' must be 0. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: modules, classes, instances
On 14-Dec-2001, David Feuer [EMAIL PROTECTED] wrote: Well, I've been doing some more stupid thinking, and I've decided that I am not satisfied with the module system in haskell, or the way it deals with namespaces. It seems to me that there are four kinds of things that need to be dealt with: classes, instances, types, values, and possibly some kind of ML-style structures/functors. I see no good reason not to treat a class declaration similarly to the way Haskell treats modules. For example, if I have a class class A x where f1::... f2::... I would like to access the functions by writing A.f1, A.f2, etc. There should, however, be some way to unqualify the names, the way ML allows structures to be opened. A proposal very similar to this has recently been suggested on the mercury-developers mailing list [1]. This proposal, and others related to it, have then been discussed at some length. See the threads titled Module qualification of typeclass methods [1] Automatic inclusion of modules [2], and Module system discussion [3]. One drawback with this proposal was noted by Simon Taylor: | The proposal is also a step backwards for classes that are already | defined in a module of the same name, for example library/enum.m. | With the proposed change, the methods of that class would be | enum__enum__to_int and enum__enum__from_int. Finally: I want nested modules!!! They probably couldn't be compiled separately, but they'd provide some namespace control. Mercury supports separate compilation of sub-modules. Mercury has two kinds of sub-modules, nested modules, which are physically nested in the same source file, and separate sub-modules, where the parent (containing) module just contains a `:- include_module' declaration naming the child module, and the source code for the child module occurs in a separate file. You get separate compilation of separate sub-modules. [1] http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/mercury-developers.0110/0066.html [2] http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/m ercury-developers.0111/0082.html [3] http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-developers/m ercury-developers.0111/0097.html. -- 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-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
