- Haskell - Haskell.org

RE: Haskell and principal types
by Simon Peyton-Jones 12 Oct '01

12 Oct '01

| semantics). In doing so, I've come across an oddity. It seems | that Haskell does not have the principal type property It looks to me that you are correct. I hadn't realised that consequence of the dreaded M.R. It may be "well known in the Haskell community", it wasn't well known to me. John's solution is only a solution if (as he said) the call-by-need form of binding is *completely* monomorphic (not even parametric polymorphism). But then it does solve the problem, at some linguistic cost admittedly. Death to the MR! Simon

1 0

RE: GUI Library Task Force
by Simon Peyton-Jones 12 Oct '01

12 Oct '01

| *** The GUI Library Task Force Strategy Proposal *** Great! | * Start from the API of GTK+ as a base line: That's fine by me. But can I suggest that the task force be sure to read the details of the Clean GUI library design. Peter Aachten (while visiting Cambridge) rendered a good chunk of it into Haskell, using MVars exactly as you describe. (The type structure became a good deal simpler than the Clean library when using MVars instead of state-passing.) The reason I think its worth a careful look is that the Clean folk have developed their library interface over a long period, and have a lot of experience in its use. It is not specific to any one platform or toolkit, nor does it attempt to implement everything, so its general goals fit with the ones you describe. I wondered whether its design would not "fit" Haskell because of the different approaches to I/O, but that turned out not to be an issue. There's a paper that introduces the Haskell rendering of the Clean library at http://research.microsoft.com/~simonpj/papers/haskellobjectio.htm Simon

16 23

code for exercise 4.10
by rock dwan 11 Oct '01

11 Oct '01

Iam having some difficulties doing exercise 4.10 from craft of fucntional programming book ..is their a possible solution for this ? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

2 1

Re: Harmful spammers
by jefu 11 Oct '01

11 Oct '01

There are a couple things to do that can at least cut down on spam. 1) Make sure that your mail gateway, or (in this case) the mailing list host is not an open relay site. Check http://www.mail-abuse.net/ and especially http://www.mail-abuse.net/rss/ for more information. 2) Every time you get spam, locate all the hosts it came through in the header. Check both hostnames and ip addresses as one of the common spammer techniques is to give a different hostname than the ip address maps to. These are in the "Recieved-by:" headers. Then send mail to everyone reasonable at the site you get. If there are any mail addresses in the body of the message, add them too - similarly with web addresses. Given a site name of "foo.bar.com", my usual list of addresses is : root(a)foo.bar.com administrator(a)foo.bar.com postmaster(a)foo.bar.com webmaster(a)foo.bar.com abuse(a)foo.bar.com mail-abuse(a)foo.bar.com I have a program to generate this list, as often I send mail to several sites at a time. In that mail, complain about the spam and include the entire mail message that you got (including the headers). (If I get really bugged - for example by getting the same spam over and over again, I'll often include a huge image file that contains the text "SPAM IS BAD" just for amusement. This technique is for experienced drivers on closed courses only. Don't try this at home.) If your MUA supports changing your "Reply-To:" and "From:" headers, change them to something nonsensical. Ignore mail bounces. Often the sysadmins will do their best to fix the problem, however, many recent spams have originated in China and they don't seem to be doing much to change that. jefu -- jeff putnam -- jefu(a)eou.edu -- http://cs.eou.edu/~jefu

3 2

Re: Monomorphism, monomorphism...
by Ashley Yakeley 10 Oct '01

10 Oct '01

At 2001-10-10 03:59, Marcin 'Qrczak' Kowalczyk wrote: >We need some type T such that it's possible to define a family of >functions for arbitrary choices of A: > upA :: A -> T > downA :: T -> Maybe A >satisfying downA (upA a) = Just a. We want to choose the type for T >before deciding the exact set of types for A. I'm convinced extensible datatypes are the cleanest and most in-spirit extenstion to Haskell to solve this. data T = _; ... data T |= MkAT A; upA = MkAT; downA (MkAT a) = Just a; downA _ = Nothing; -- Ashley Yakeley, Seattle WA

1 0

Re: Haskell and principal types
by Karl-Filip Faxen 10 Oct '01

10 Oct '01

Hello again! John Hughes suggested that Haskell should have two forms of binding, one with call-by-name (does not preserve sharing) semantics and polymorphism and overloading and monomorphic with call-by-need (preserves sharing). The question is; would this restore principal types in general? Actually, I don't know. I came across this problem when I was thinking about how one would go about constructing a complete inference algorithm for Haskell (Mark Jones's THIH algorithm, as well as other algorithms built on W, fails to type some programs containing type synonyms). So my idea was to see if was possible to do type inference in two passes, forgetting about type classes on the first pass, and then go back and collect and solve class constraints. For that strategy to work, the classes must not influence the other part of the types, ie the type schemes derived would only need to get their context parts filled in by the later pass. And as far as I could see, it was defaulting and the monomorphism restriction that could cause trouble. And while thinking of ways to make the trouble from the monomorphism restriction go away, I came up with this counter example. So I have absolutely not done any general proof about principality, but if my idea about doing HM typechecking first and then patch the class stuff can be made to work, I suppose that would be quite close to a proof of principal types. And I think that John's suggestion does fix the problem with the monomorphism restriction (since the restriction goes away and we already have constructs with the type of := in the language, eg "case e of x -> body" or "(\x->body) e". What remains is the defaulting mechanism. Cheers, /kff

2 2

Re: Monomorphism, monomorphism...
by cwitty＠newtonlabs.com 10 Oct '01

10 Oct '01

"Marcin 'Qrczak' Kowalczyk" <qrczak(a)knm.org.pl> writes: > 09 Oct 2001 13:55:04 -0700, Carl R. Witty <cwitty(a)newtonlabs.com> pisze: > > > The TREX paper from Mark Jones and Benedict Gaster (I hope I > > have the names right) had both extensible records and extensible > > variants (extensible variants being what you would need to implement > > downcasts), > > I don't think so. Here is how the requirement can be formulated: > > We need some type T such that it's possible to define a family of > functions for arbitrary choices of A: > upA :: A -> T > downA :: T -> Maybe A > satisfying downA (upA a) = Just a. We want to choose the type for T > before deciding the exact set of types for A. It is true that extensible variants do not give you a single, closed type T with this property. However, I think it is likely that any program you wanted to write using these functions could instead be written in a system with extensible variants. Functions would be polymorphic over the exact variant type, and the typechecker would stitch together all the requirements on the variant type so that when compiling "main", it could decide what the actual type was. (I say "likely" because I'm not certain that the type inference described in the Gaster/Jones paper would work the way I want it to, since I've never used a system that implemented extensible variants.) Carl Witty

1 0

Re: Unicode support
by Marcin 'Qrczak' Kowalczyk 10 Oct '01

10 Oct '01

Tue, 9 Oct 2001 14:59:09 -0700, John Meacham <john(a)repetae.net> pisze: > I think a cannonical way to get at iconvs ('man 3 iconv' for info.) > functionality in one of the standard librarys would be great. perhaps > I will have a go at it. even if the underlying platform does not have > iconv then some basic conversions (utf8, utf16, latin1, [Char]) could > easily be provided with the same API and minimal implementation effort. I've already done some of this: <http://www.sf.net/projects/qforeign/>. There is a framework for conversions - I'm not entirely happy with it but I don't know how to do it nicer. I implemented a binding to iconv, UTF-8, some 8-bit encodings. It should be suitable for associating Handles with a conversion: in particular the conversion performed by iconv can be done without intermediate Haskell lists but directly on some handle buffers, provided that we can get a Ptr to it (it's tricky in the case of ghc's ByteArrays). There is also a Char module replacement with extra character properties. It works with ghc and parts of it work with nhc98. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Monomorphism, monomorphism...
by Marcin 'Qrczak' Kowalczyk 10 Oct '01

10 Oct '01

09 Oct 2001 13:55:04 -0700, Carl R. Witty <cwitty(a)newtonlabs.com> pisze: > The TREX paper from Mark Jones and Benedict Gaster (I hope I > have the names right) had both extensible records and extensible > variants (extensible variants being what you would need to implement > downcasts), I don't think so. Here is how the requirement can be formulated: We need some type T such that it's possible to define a family of functions for arbitrary choices of A: upA :: A -> T downA :: T -> Maybe A satisfying downA (upA a) = Just a. We want to choose the type for T before deciding the exact set of types for A. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RFC: GUI Library Task Force
by Manuel M. T. Chakravarty 10 Oct '01

10 Oct '01

The following is a summary of a discussion about a strategy to develop a standard GUI library for Haskell. The discussion was initiated by Simon Peyton Jones and involved Koen Claessen, George Russell, and me. The next step in our plan is the creation of a public mailing list (we propose, "gui(a)haskell.org") that can be used to develop an API definition according to the outlined strategy. Anybody who is interested in participating in this discussion is very welcome to join this mailing list, once it is set up. I expect that there will be feedback here on the main list to the appended proposal. As soon as this becomes technical, I propose to take it off the main list to the new GUI mailing list. Cheers, Manuel -=- *** The GUI Library Task Force Strategy Proposal *** Goals ~~~~~ * Development of a GUI library API for Haskell that is portable across Haskell systems and operating/windowing systems * The library focuses on graphical *user interfaces* (ie, buttons, menus, scrollbars, selection lists, etc) as opposed to drawing and animation routines. * Verification of the design by at least one implementation of a library that exports the GUI API * Minimal use of features that are not included in Haskell 98 (in fact, we currently believe that we can keep the API completely free of any non-H98 features; however, application programs that use the API will need some non-H98 functionality) * While we do not require support of concurrency by Haskell systems implementing the API, the use and behaviour of the API must be well-defined on systems that do support concurrency * Core library: - Due to the complexity of modern GUIs, we cannot hope to cover a fully-fledged GUI library in reasonable time and with reasonably effort; thus, we concentrate on a core library (what exactly constitutes the core remains to be defined) - The core library needs to provide a migration path to at least one fully-fledged GUI library * Openness for tools support; for example, it should be possible to support graphical interface builders (such tools are not part of the API, but we need to ensure that we do not seriously complicate the construction of such tools) Non-goals ~~~~~~~~~ * We will not design a fully-fledged GUI library from scratch: Just as a reference point, GTK+ has 93 different widgets (and that's just the base set) and probably over 1000 functions. Moreover, there are surely 100-200 different types of callbacks. I am pretty sure that Qt, the Win32 GUI API, and the MacOS are of similar size. This is well beyond the scope of what we can achieve with our resources. * We will not design a "purely functional GUI": - The pragmatic reason: H98 textual I/O works via the IO monad; so what's the problem with having graphical I/O in the IO monad? - The state-of-the-art reason: There doesn't seem to be a clear favourite in the proposals for purely functional GUIs. Moreover, it has yet to be shown that any of the proposals scales to real-life GUI applications. We do not intend to solve sophisticated research problems here. We want to get a workable solution quickly. Always remember: Worse is Better <http://www.jwz.org/doc/worse-is-better.html>. The Plan ~~~~~~~~ * Handling of state altered by both the application and by GUI widgets: - The GUI API will be kept free of any commitment as to which mechanism to use here. - The simplest solution, for a single-threaded application, is to use `IORef's and, for a multi-threaded application, is to use `MVar's (or primitives that are defined in terms of these). - Advantages of this design: + Doesn't require Haskell systems that want to provide the GUI library to also support concurrency + Doesn't preclude the use concurrency (where it is available) + `IORef's are very easy to implement if any system doesn't have them yet + More sophisticated approaches (that often require language extensions or are still experimental) can be implemented on top of this basic API - eg, FranTk, Yahu, Fruit, iHaskell, etc. - It is possible to write reasonably nice Haskell programs in this approach; for an example, see http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html (Note how many of the functions need to be in the IO monad anyway, because they need to perform file I/O.) * Start from the API of GTK+ as a base line: - This is an API that has a proven track record of being suitable for small, medium, and large-scale applications - The API does not overly rely on object-oriented language features - A large body of free documentation exists for the API, which can be adapted to our purpose - A working Haskell binding exists that can be extended to provide a first implementation of the Haskell GUI API - A clear migration path exists for applications that need more sophisticated features than the core API provided by the Haskell GUI - GTK+ itself is already reasonably platform independent * Ensure platform independence: - The Haskell GUI will be restricted to GTK+ features that can be implemented on other major platforms with reasonable effort * Haskell-ise the API: - C-ish functionality will be cut out - Full use will be made of Haskell's type system and, in particular, type classes * Convenience libraries - The API will include a set of convenience libraries on top of the basic API (eg, by providing layout combinators)

5 6