- Haskell - Haskell.org

GHC / Hugs Disagree on Constraints
by oleg＠pobox.com 10 Oct '04

10 Oct '04

> instance (Ord a, Bits a, Bounded a, Integral a, LargeWord a, > Bits b, Bounded b, Integral b, LargeWord b) => > Bounded (LargeKey a b) where > minBound = 0 > maxBound = > fromIntegral $ > (1 + fromIntegral (maxBound::b))* > (1 + fromIntegral (maxBound::a)) - 1 > > Hugs rejects it with +N -98 with One fix is to bring type variables into the local scope, for example, > instance (Ord a, Bits a, Bounded a, Integral a, LargeWord a, > Bits b, Bounded b, Integral b, LargeWord b) => > Bounded (LargeKey a b) where > minBound = 0 > maxBound :: (LargeKey a b) = > fromIntegral $ > (1 + fromIntegral (maxBound::b))* > (1 + fromIntegral (maxBound::a)) - 1 You still need -98 flag for Hugs. Another solution is totally Haskell98: introduce two functions > aoflk:: (LargeKey a b) -> a; aoflk = undefined > boflk:: (LargeKey a b) -> b; boflk = undefined then maxBound can be implemented as > maxBound = result where > result = > fromIntegral $ > (1 + fromIntegral (maxBound `asTypeOf` (boflk result)))* > (1 + fromIntegral (maxBound `asTypeOf` (aoflk result))) - 1 The apparent recursion in the above definition is superficial. The definition isn't actually recursive. We merely need the type of the 'result' rather than its value.

3 4

CFP: TFP04 Symp on Trends in Functional Programming
by Hans-Wolfgang Loidl 09 Oct '04

09 Oct '04

[ The registration page for TFP04 is now open: registration deadline is Nov 1; Deadline for paper submissions is Nov 15th. Apologies for repeated copies of this message -- HWL ] CALL FOR PAPERS TFP 2004 Fifth Symposium on Trends in Functional Programming November 25-26th 2004, Ludwig-Maximilians University, Munich, Germany http://www.tcs.ifi.lmu.de/~hwloidl/TFP04 The Symposium on Trends in Functional Programming is an international forum for researchers with interests in all aspects of functional programming languages. It succeeds TFP03 in Edinburgh and continues the Scottish Functional Programming Workshop series from 1999-2002. Papers on all aspects of functional programming are welcomed, be they theoretical, implementation-oriented, or experience papers. The venue for this year's symposium will be Ludwig-Maximilians University in central Munich. WORKSHOP TOPICS Papers on any aspect of functional programming are welcomed. Papers on the following subject areas are particularly welcome: * design and implementation of functional or declarative languages; * rich type systems, including type systems for expressing side-effects, resource bounds, or other safety properties; * linear type systems, soft type systems, typeful programming; * formal aspects of functional programming, semantics, reasoning, verification; * inductive or co-inductive techniques, proof nets; * mobile-code functional programming languages; * parallel programming with functional languages, cost models for functional programs; * functional aspects of imperative programming, functional bytecode; * interoperability with imperative programming languages, calling imperative from functional or vice versa; * type inference algorithms, type error repair, deep types; * strongly-typed imperative languages with inference; * optimisation techniques, implementation techniques, and performance measurements; * experience papers: applications of functional programming or functional programming in education. PROCEEDINGS As with the previous instances of TFP and SFP, we intend to publish a high-quality subset of contributions in the Intellect Trends in Functional Programming series. All speakers attending the workshop are invited to submit a paper for the draft proceedings. Revised papers will be refereed after the symposium according to normal conference standards for publication by Intellect. This implies (among other things) that: * the paper should be written in English * the paper is well written * the topic of the paper should be stated clearly * the approach to solve the problem should be outlined clearly * a detailed discussion of the solution has to be given * the solution is compared with relevant related work * there is an abstract, introduction and conclusion. * the conclusion should summarise the problem, the solution, and how this solves the problem. * papers must not exceed 16 pages. * the paper should conform to the TFP format <http://www.tcs.ifi.lmu.de/~hwloidl/TFP04/cameraready.zip> * the paper should be submitted as a PostScript or a PDF file using the paper submission page <http://lionel.tcs.informatik.uni-muenchen.de/TFP04/submit.html> in case of problems with the on-line submission process, send the paper by email to the programme chair, Hans-Wolfgang Loidl <hwloidl(a)informatik.uni-muenchen.de> DATES Nov 1st 2004: Registration deadline Nov 15th 2004: Submission for draft proceedings Nov 25-26th 2004: Symposium at Ludwig-Maximilians University, Munich Dec 20th 2004: Submission for referees process Jan 31st 2005: Notification of acceptance/rejection PREVIOUS WORKSHOPS The previous instance of TFP was held in Edinburgh 2003 and continues the Scottish Functional Programming Workshop series with previous meetings at Stirling (2001), St. Andrews (2000), and Stirling (1999). The TFP series <http://www.tifp.org/> strives to combine an active workshop environment for presenting latest research, with a formal post-symposium refereeing process and the publication of a high-profile proceedings (see <http://www.intellectbooks.com/authors/hammond/trends3.htm>). For a review of past TFP proceedings, see the July 2003 issue of the JFP 13(4):823-824 at <http://titles.cambridge.org/journals/JFP/>. Sponsorship funding available to us will be used to reduce registration rates for PhD students, who present proof of affiliation in advance of the symposium. PROGRAM COMMITTEE * Stephen Gilmore, University of Edinburgh * Gaetan Hains, Universite d'Orleans * Kevin Hammond, University of St Andrews * John Hughes, Chalmers University * Hans-Wolfgang Loidl, Ludwig-Maximilians-University Munich (Chair) * Rita Loogen, Philipps-University Marburg * Greg Michaelson, Heriot-Watt University * John O'Donnell, University of Glasgow * Ricardo Pena, Universidad Complutense de Madrid * Phil Trinder, Heriot-Watt University * Marko van Eekelen, University of Nijmegen * Phil Wadler, University of Edinburgh SPONSORS TFP is supported this year by the APPSEM II Thematic Network and the Mobile Resource Guarantees project, funded by the IST programme of the European Union.

1 0

Succ Zeroth IOHCC Results http://www.scannedinavian.org/iohcc/succzeroth-2004/
by Shae Matijs Erisson 09 Oct '04

09 Oct '04

After a long delay, the Succ Zeroth IOHCC Results are online! http://www.scannedinavian.org/iohcc/succzeroth-2004/ The minimalistic results page links to three winning submissions of much entertainment. Winners by Category: Best overall entry UlfNorell with MetaSteganoGraphicObfuscation Best Abuse of Compiler Specific Features and Best Signature Sized Entry DonSteward with Crawl Most Useful submission JeremyGibbons with PiSpigot Thanks to everyone who entered! Please enter again next year! -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby

1 0

threading mutable state through callbacks
by Jules Bean 08 Oct '04

08 Oct '04

Hi, I've been playing with some haskell bindings which basically bind C procedures in the IO monad. To write 'interesting' programs, you often need to manage your own state in addition to the implicit IO state. I have been allocating references with newIORef and then passing them around all my functions. But having to thread a parameter through all your functions is inconvenient (and fragile). I can see the solution to this problem in layering a state monad over the IO monad, and I can just about grok the syntax I need to use StateT, with a nice encapsulated environment record type and nice selector functions to use with gets. Now of course I don't even need to use IORefs any more since I can be more explicit and precise about my state and how it's manipulated. (this is potential even a useful feature, since I can step back to earlier time points just by saving the state, etc.) Unfortunately, it's not going to work. It's not going to work because some of the procedures take callbacks, and the callbacks are values of type IO (). I can see two solutions to this: a) revert to using an IORef, and use lexical scoping to define my callbacks in a location such that the reference to the environment is in scope. This will work, but it's just not convenient to define all your functions inside another function so you can do a lexical scoping trick... b) write the callbacks as values of type StateT Env IO () and then use the following 'environment binder' bindEnv env s = do { x <- readIORef env ; s' <- execStateT s x; writeIORef env s'} when I pass them to a callback. (which works fine as long as I have used lexical scoping to make sure env is visible at the binding site) Is this the right approach? Is there a better one? From the library perspective, would it be cool if library callback routines, which currently have a type like addCallback :: IO() -> IO() could be given the type addCallback :: MonadIO() -> IO() So that they'll let you add callbacks for any monad layered over IO. Or doesn't this idea work? Jules

2 1

Lazy evaluation
by Amadeo Casas Cuadrado 08 Oct '04

08 Oct '04

Hello, Could anyone tell me where can i find a webpage or a paper about how lazy implementation is done is Haskell? Thanks a lot! --Ama

2 1

Re: threading mutable state through callbacks
by oleg＠pobox.com 08 Oct '04

08 Oct '04

Jules Bean wrote: > Unfortunately, it's not going to work. It's not going to work because > some of the procedures take callbacks, and the callbacks are values of > type IO (). I can see two solutions to this: > > a) revert to using an IORef, and use lexical scoping to define my > callbacks in a location such that the reference to the environment is > in scope. This will work, but it's just not convenient to define all > your functions inside another function so you can do a lexical scoping > trick... > > b) write the callbacks as values of type > > StateT Env IO () > > Is this the right approach? Is there a better one? Yes: implicit parameters and implicit configurations. The end user code is often identical in both of these approaches (but the latter may require a bit more preparation. OTH, implicit parameters are supported by the compiler whereas the latter is just a Haskell library). Both approaches are compared in Appendix A of the paper http://www.eecs.harvard.edu/~ccshan/prepose/prepose.pdf The example is writing JNI functions in Haskell. Incidentally, the example illustrates passing of the implicit state (JNIEnv pointer) _around_ the exception handler. The problem is that the function 'handle' has the type handle :: (Exception -> IO a) -> IO a -> IO a rather than handle :: (Exception -> MonadIO a) -> MonadIO a -> MonadIO a > revert to using an IORef, and use lexical scoping to define my > callbacks in a location such that the reference to the environment is > in scope. This will work, but it's just not convenient to define all > your functions inside another function so you can do a lexical scoping > trick... The stated motivation of the implicit configurations is precisely that: make it appear that the IORef is `lexically scoped' over all of its clients without putting all the clients inside one giant function. The master file for the paper http://www.eecs.harvard.edu/~ccshan/prepose/prepose.lhs is a literate Haskell code, which you can load into GHCi as it is. You can then run all of the examples in the paper. If you have trouble using implicit configurations, have a particular application in mind and can turn it into a self-contained example (by replacing various functions with stubs wherever possible: e.g., see the very end of prepose.lhs), you may want to let Ken and me know. I'll see what can be done.

2 1

Random selection
by ldou 06 Oct '04

06 Oct '04

I have a string,e.g. "1245670398", now I want to select two element from the string randomly, and the two element must be different, how can I do?

3 2

different element
by ldou 06 Oct '04

06 Oct '04

In the random selection, it perhaps select the same element of the string, how can I select two different elements?

2 1

RE: [Haskell] Building from source
by Simon Marlow 06 Oct '04

06 Oct '04

On 06 October 2004 10:10, Christian Maeder wrote: > after checking out fptools from cvs. The simple sequence > > $ autoreconf > $ ./configure > $ make > > failed in the directory hood, because the target boot is unknown > there. Could/Should this be fixed? > > I know how to use mk/build.mk and the ProjectsToBuild variable. I > don't need hood, but make still should not fail (after ./configure). If you don't want to build hood, then remove it from the tree. Did you perhaps check out *everything*? The right way is to check out fpconfig first, and then each of the projects you're interested in separately, eg. for GHC you would check out ghc, libraries, and hslibs. The section on CVS in the building guide has more info: http://www.haskell.org/ghc/docs/latest/html/building/sec-cvs.html Cheers, Simon

2 1

How to get different two random numbers
by ldou 06 Oct '04

06 Oct '04

How to get different two random numbers, and use the two numbers in program,e.g x = b + c where b && c are different random numbers between 1..n

2 1