Re: [Haskell] Haskell 6.4 perfomance
Think this should really go to glasgow-haskell-users... If this is true - how do I get ghc to use C--, and is it really faster than using gcc as a backend with all the bells whistles turned on (for a pentium-III) something like -O3 -mcpu=pentium3 -march=pentium3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fno-crossjumping -mfpmath=sse,387 -ffast-math -fsched-spec-load -fprefetch-loop-arrays -maccumulate-outgoing-args -fmove-all-movables -freduce-all-givs Keean. Alexandre wrote: As I heard, 6.4 version of the Haskell using C-- backend and make lots of the resulting code perfomance (programs executed faster). If so, does any test/comparison with other languages available? Thank you in advance, Regards, /Alexandre. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] The FunctorM library
| Yes, I think this should be fixed, and perhaps it could be done in a | backward compatible way? If classes were allowed to declare default | methods for superclasses, then you could have | | class Functor f where fmap :: ... | class Functor m = Monad m where | ...the usual stuff... | fmap = liftM | | Then declaring | | instance Monad T where ... | | for some T, would implicitly introduce an instance Functor T, if it is | not defined explicitly... It seems overkill to have a whole new language feature to deal with one library issue. It would take a bit of implementing too, and it's not clear to me what the specification is. For example, what if Functor T *is* defined explicitly, but in a later module? The idea comes up very occasionally, but I wouldn't say it's been a hot issue. Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Research papers on Advanced Functional Programming?
On 23 Mar 2005, at 21:50, Johan Glimming wrote: I will soon give a course in Advanced Functional Programming at Stockholm University ... As far as I know there is no obvious choice of textbook for this kind of course, although there are of course several volumes emitted from the AFP summer schools. plug Don't forget The Fun of Programming (Jeremy Gibbons and Oege de Moor, editors), which is specifically intended to be a textbook for an advanced course on functional programming. http://www.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/ index.html#fop /plug Jeremy [EMAIL PROTECTED] Oxford University Computing Laboratory,TEL: +44 1865 283508 Wolfson Building, Parks Road, FAX: +44 1865 273839 Oxford OX1 3QD, UK. URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell on QNX?
Matthew M. Munz [EMAIL PROTECTED] writes: Is it possible to compile and run Haskell programs on QNX? [1] [1] http://www.qnx.com/ From a brief glance at the QNX website, it appears to support POSIX, GNU make tools, and gcc-compatible C compilers. Thus it should be possible to get either Hugs or nhc98 up and running very quickly, maybe even straight out of the box, on all architectures. It is also likely that ghc could be persuaded to bootstrap (with a little work) on at least PowerPC and ix86 platforms, since the native codegen for those architectures is well maintained - MIPS, SH-4, StrongARM, and Xscale would be much more of a challenge for ghc though! Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The FunctorM library
Why not just have the new definition with a different import path, so that legacy code continues to do: import Control.Monad And new code could do: import Control.Category.Monad (or something) And we could take this opportunity to incorporate premonads... class Functor f -- defines fmap class Functor p = Premonad p -- defines return class Premonad m = Monad m -- defines bind Keean. Simon Peyton-Jones wrote: | Yes, I think this should be fixed, and perhaps it could be done in a | backward compatible way? If classes were allowed to declare default | methods for superclasses, then you could have | | class Functor f where fmap :: ... | class Functor m = Monad m where | ...the usual stuff... | fmap = liftM | | Then declaring | | instance Monad T where ... | | for some T, would implicitly introduce an instance Functor T, if it is | not defined explicitly... It seems overkill to have a whole new language feature to deal with one library issue. It would take a bit of implementing too, and it's not clear to me what the specification is. For example, what if Functor T *is* defined explicitly, but in a later module? The idea comes up very occasionally, but I wouldn't say it's been a hot issue. Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The FunctorM library
On Thu, Mar 24, 2005 at 08:40:14AM -, Simon Peyton-Jones wrote: [Thomas Hallgren wrote:] | Yes, I think this should be fixed, and perhaps it could be done in a | backward compatible way? If classes were allowed to declare default | methods for superclasses, then you could have | | class Functor f where fmap :: ... | class Functor m = Monad m where | ...the usual stuff... | fmap = liftM | | Then declaring | | instance Monad T where ... | | for some T, would implicitly introduce an instance Functor T, if it is | not defined explicitly... It seems overkill to have a whole new language feature to deal with one library issue. It would take a bit of implementing too, and it's not clear to me what the specification is. For example, what if Functor T *is* defined explicitly, but in a later module? It's not just here -- this would make lots of fairly fine-grained class hierarchies a lot less painful. But I agree that there's a cross-module problem. It may be necessary to require that instances of classes linked in this way be defined in the same module, but that wouldn't be backwards compatible either. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Type inference and principal typings for record concatenation and mixin modules
We would like to announce a technical report and a web-accessible software demonstration. The technical report is: Type Inference and Principal Typings for Symmetric Record Concatenation and Mixin Modules by Henning Makholm and J. B. Wells http://www.macs.hw.ac.uk/~makholm/papers/bowtini-long.pdf In this report we present a new type system, Bowtie, for a lambda calculus with records and a symmetric record concatenation operation. The system has been designed to allow feasible _type inference_ with a complexity of O(nm*alpha(n)) where n is the input size and m the number of different field labels in the program, as well as _compositional type inference_ and a notion of _principal typings_. (Because alpha(n) = 4 for n 10^(10^100) (a googolplex), one can think of this factor as a constant for practical purposes.) Most previous type systems for record concatenation have relied on subtyping polymorphism. Bowtie does not, and because subtyping is absent, we have been able to straightforwardly extend Bowtie to a type system, Martini, for _mixin modules_. Bowtie and Martini are both non-polymorphic type systems, but because both have principal typings it is straightforward to extend either with Milner's let-polymorphism, and we do so. Apart from the definition of Bowtie and Martini we also present some negative results (things that don't work). Most notable among these is a series of proofs that the straightforward typing rule for a record concatenation operator in an SML-like type system leads to an NP-hard typability problem --- *even for the let-free (non-polymorphic) fragment*, and *no matter whether the concatenation operator is symmetric or asymmetric/overwriting*. We have also made available a web-accessible type inference demo for Bowtie/Martini; it can be found at http://www.macs.hw.ac.uk/DART/software/Bowtini/ We hope you enjoy our paper and web demo and we welcome any feedback. -- Henning Makholm Joe Wells ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CFP: Developments on Computational Models (satellite of ICALP 05)
== Call for Papers Developments in Computational Models http://www.dcs.kcl.ac.uk/events/DCM/index.html Lisbon, Portugal Sunday, 10 July 2005 A satellite event of ICALP 2005 === Several new models of computation have emerged in the last few years, and many developments of traditional computational models have been proposed with the aim of taking into account the new demands of computer systems users and the new capabilities of computation engines. A new computational model, or a new feature in a traditional one, usually is reflected in a new family of programming languages, and new paradigms of software development. The aim of this workshop is to bring together researchers who are currently developing new computational models or new features for traditional computational models, in order to foster their interaction, to provide a forum for presenting new ideas and work in progress, and to enable newcomers to learn about current activities in this area. DCM 2005 will be a one-day satellite event of ICALP 2005. Topics of interest include all abstract models of computation and their applications to the development of programming languages and systems. For instance: Functional calculi: lambda-calculus, rho-calculus, term and graph rewriting; Object calculi; Interaction-based systems: interaction nets, games; Concurrent models: process calculi, action graphs; Calculi expressing locality, mobility, and active data; Quantum computational models; Biological or chemical models of computation. Submissions and Publication: Please submit an abstract (max. 5 pages) in PDF/PostScript format by e-mail to [EMAIL PROTECTED] by 9 May, 2005. After the workshop authors will be invited to submit a full paper of their presentation. Accepted contributions will appear in a special issue of the international journal Mathematical Structures in Computer Science. Important Dates: Submission Deadline for Abstracts: 9 May 2005 Notification: 30 May 2005 Pre-proceedings version due: 27 June 2005 Submission Deadline for Special Issue of MSCS: 15 October 2005 Notification: 15 January 2006 Programme Committee: Vincent Danos, CNRS and University of Paris 7 (France) Mariangiola Dezani, University of Torino (Italy) Maribel Fernandez, King's College London (UK), co-chair Claude Kirchner, LORIA and INRIA (France) Cosimo Laneve, University of Bologna (Italy) Ian Mackie, King's College London (UK), co-chair Nobuko Yoshida, Imperial College London (UK) Local Organizer: Jorge Sousa Pinto, University of Minho (Portugal) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] PAT2005 Summer School Announcement
Announcement of PAT2005 Summer School: Program analysis and transformation Copenhagen, Denmark Monday-Friday 6-10 June, 2005 This summer school on Program analysis and transformation will span theory and practice in the field. The overall theme is semantics-based program manipulation, in which practically-motivated operations on programs are solidly based in the semantics of the underlying programming languages. Research profile of the Summer School's topics: This research field began with classical compiler optimisations. These were pragmatically successful and well-automated, but lacking in semantic foundations. This led to the long-pursued goal of truly semantics-based generation of compilers and of abstract machines to implement programming languages. Parallel academic developments included more powerful and interesting program transformations that were developed by hand, one at a time. Major progress has been made in all three areas: semantically well-founded compiler optimisations have been devised and well-automated; compilers and abstract machines can now be generated by semantics-based methods including partial evaluation; and there now exist more powerful, general and well-founded program transformations. The speakers at this Summer School represent the state of the art in this research field. Confirmed speakers and their topics are: Mooly Sagiv (Israel: Tel Aviv) Program analysis using Three-Valued Logic Olivier Danvy (Denmark: Aarhus) On one-step reduction, evaluation, and abstract machines Oege De Moor (UK: Oxford) Incremental execution of transformation specifications Nick Benton, Microsoft Research Cambridge Semantics of static analyses and program transformations Neil Jones (Denmark: DIKU, Copenhagen) Size-change termination analysis of first and higher-order programs Torben Mogensen (Denmark: DIKU, Copenhagen) Introduction to partial evaluation; Program semi-inversion Arne Glenstrup (Denmark: ITU, Copenhagen) Tool tutorial for the Scheme partial evaluators PGG and Similix John Gallagher (Denmark: Roskilde) Program analysis and specialisation using tree automata Robert Glueck (Denmark: DIKU, Copenhagen) Program inversion Kazuhiko Kakehi (Japan: MIST, Tokyo Uniiversity) Attribute grammars and program transformations Prerequisites: Students should have some familiarity with classical compiler optimisations. A basic knowledge of operational semantics of programming languages (eg Structural operational semantics, Natural semantics or Action semantics) would be helpful. Sponsors: The PAT Summer Schools is partly supported by FIRST Graduate School: http://first.dk/ APPSEM-II: http://www.tcs.informatik.uni-muenchen.de/~mhofmann/appsem2/ Microsoft Research: http://research.microsoft.com/aboutmsr/labs/ Web pages: PAT home page: http://www.diku.dk/~neil/PAT2005/ (with details on lecture topics, speaker profiles, timetable, etc.) DIKU guest page: http://www.diku.dk/diku/gaester/index.html (with details on local transport, maps, hotels, etc.) Registration: The registration fee is currently estimated at DKK 1500 = EURO 200. This includeslecture materials, lunches and coffees, and a Summer School dinner. A block of rooms will be reserved at a hotel in central Copenhagen (probably the new Cab Inn). Unless otherwise arranged, all attendees will arrange and pay for their own travel and lodging. Registration will Open: April 1, 2005 Close: May 15, 2005. Scholarships: There will be a limited number of scholarships covering part or all of the registration fee. Application materials will be available at the course's web page at the beginning of the registration period. Local Organisation Committee: Neil Jones neil(a)diku.dk Andrzej Filinski andrzej(a)diku.dk Torben Mogensen torbenm(a)diku.dk Jesper Andersen jespera(a)diku.dk Karin Outzen karino(a)diku.dk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ICLP 2005: Call for Workshops
*** CALL FOR WORKSHOP PROPOSALS *** ICLP'05 Twenty First International Conference on Logic Programming October 2-5, 2005 Sitges (Barcelona) Spain URL: http://www.iiia.csic.es/iclp2005/ ICLP'05, the 21st International Conference on Logic Programming, will be held in Sitges(Barcelona), Spain, from October 2 to October 5, 2005. We plan to have several workshops in parallel with the conference. Workshops have a key role in Logic Programming Conferences. They provide an ideal platform for the presentation of preliminary work or novel ideas in a less formal way than the conference itself. They also are an opportunity to disseminate work in progress, particularly for new researchers. Workshops also provide a venue for presenting more specialized topics and opportunities for more intensive discussions, exchange of ideas, and project collaboration. The topics of the workshops can cover any areas related to logic programming, including cross-disciplinary areas. To encourage active participation and exchange of ideas, the workshops will be kept small, preferably under 40 participants. The format of the workshop will be determined by the organizer(s) proposing the workshop, but ample time must be allowed for general discussion. Workshops can vary in length, but the optimal duration will be half a day or a full day. Having two or three co-organizers for a workshop is strongly advised. Workshop Proposal: == The persons intending to organize a workshop at ICLP'05 are invited to submit a workshop proposal. Proposals should be in English and about two pages in length. They should contain: * The title of the workshop. * A brief technical description of the topics covered by the workshop. * A discussion of the timeliness and relevance of the workshop. * The names, affiliation and contact details (email, web page, phone, fax) of the workshop organizing committee together with a designated contact person as the workshop coordinator. * A preliminary plan/schedule for organizing the workshop, including the required number of half-days allotted to the workshop. * A list of previously-organized related workshops by any of the workshop organizing committee. Although previous experience with organizing similar workshops is not required, this information will be helpful to the Workshop Chair. * An estimate of the number of expected attendees. Proposals are expected in ASCII or LaTeX format. All proposals should be submitted to the Workshop Chair by email by March 31, 2005. Workshop Organizers' Tasks: === * Producing a Call for Papers for the workshop and posting it on the net and/or other means. Please provide a web page URL which can be linked into the ICLP'05 home page by May 5, 2005. * Providing a brief description of the workshop for the conference program. * Reviewing/accepting submitted papers. * Scheduling workshop activities in collaboration with the local organizers and the workshop chair. * Sending workshop proceedings in LaTeX format to the workshop chair for printing, by August 31, 2005 (if the proceedings are to be printed by the local organizers) Reviewing Process: == Each submitted proposal is reviewed by the Workshops Chair and the Conference Program Chairs. Proposals that appear well-organized and that fit the goals and scope of ICLP will be selected. The decision will be notified by email to the responsible organizer by April 13, 2005. The definitive length of the workshop will be planned according to the number of submissions received by the different workshops. For every accepted workshop, the ICLP local organizers will prepare a meeting place and can print the workshop proceedings, whose LaTeX preparation is however in charge to the workshop organizers. The workshop registration fees will be handled together with the conference fees. Workshop Date and Location: === All workshops will take place on October 5th, 2005 at the site of the main conference. ICLP'05 will be held in Sitges (Barcelona), Spain. Sitges is a town 15 minutes away from the Barcelona international airport and 30 minutes from the center of Barcelona. The town of Sitges is situated in the Catalan region of Spain, and it is a well-established tourist resort and residential area thanks to its warm climate and fantastic natural panoramic views. The conference will be held at Melia Sitges Hotel, located on the sea-front facing the Mediterranean and is within five-minute walking distance from the city center. Important Dates: March 31, 2005: Proposal submission deadline April 13, 2005: Acceptance notification May 5, 2005: Deadline for receipt of CFP and URL for workshop web page August 31, 2005: Deadline for preliminary
RE: [Haskell] URLs in haskell module namespace
On 23 March 2005 13:11, Malcolm Wallace wrote:
I think this will be trivially possible once the compilers support
multiple versioning of packages. (Ghc may even support it already.):
{-# OPTIONS -package foo-1.0 #-}
module Old (module Foo) where
import Foo
{-# OPTIONS -package foo-2.2 #-}
module New (module Foo) where
import Foo
module Convert where
import qualified Old
import qualified New
convert (Old.Foo x y) = New.Foo y x
We're not going to support this, at least for the forseeable future.
It's a pretty big change: every entity in the program becomes
parameterised by the package name as well as the module name, because
module names can overlap.
This means a change to the language: there might be multiple types
called M.T in the program, which are not compatible (they might have
different representations). You can't pass a value of type M.T that you
got from version 1.0 of the package to a function expecting M.T in
version 2.
This issue came up in the thread about grafting from late 2003 on the
libraries list (sorry don't have a link to hand).
Cheers,
Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Calling Haskell from (Objective-)C
Hi, I'm attempting to call Haskell functions from Objective-C (a required parser is gonna come out much nicer in Haskell than in Objective-C). As far as I can make out HOC is the only way to do this (damn, knew I shouldn't have upgraded to GHC 6.4). Does anyone know of any other way to do something like this? Bob ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell on QNX?
Malcom, ... Thus it should be possible to get either Hugs or nhc98 up and running very quickly, maybe even straight out of the box, on all architectures. So it sounds like nobody has done this yet (or at least nobody on this list)? I'm very unfamiliar with QNX ATM, but perhaps when I'm acclimated, I might try to get Hugs running on it. Thanks. - Matt Quoting Malcolm Wallace [EMAIL PROTECTED]: Matthew M. Munz [EMAIL PROTECTED] writes: Is it possible to compile and run Haskell programs on QNX? [1] [1] http://www.qnx.com/ From a brief glance at the QNX website, it appears to support POSIX, GNU make tools, and gcc-compatible C compilers. Thus it should be possible to get either Hugs or nhc98 up and running very quickly, maybe even straight out of the box, on all architectures. It is also likely that ghc could be persuaded to bootstrap (with a little work) on at least PowerPC and ix86 platforms, since the native codegen for those architectures is well maintained - MIPS, SH-4, StrongARM, and Xscale would be much more of a challenge for ghc though! Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell on QNX?
I have successfully installed Hugs on QNX machine. As far as I can remember, you only need to make a few changes in the Makefile, (change gcc to qcc and change to proper qcc flags). Liwen - Original Message - From: [EMAIL PROTECTED] To: Malcolm Wallace [EMAIL PROTECTED] Cc: haskell@haskell.org Sent: Thursday, March 24, 2005 12:50 PM Subject: Re: [Haskell] Haskell on QNX? Malcom, ... Thus it should be possible to get either Hugs or nhc98 up and running very quickly, maybe even straight out of the box, on all architectures. So it sounds like nobody has done this yet (or at least nobody on this list)? I'm very unfamiliar with QNX ATM, but perhaps when I'm acclimated, I might try to get Hugs running on it. Thanks. - Matt Quoting Malcolm Wallace [EMAIL PROTECTED]: Matthew M. Munz [EMAIL PROTECTED] writes: Is it possible to compile and run Haskell programs on QNX? [1] [1] http://www.qnx.com/ From a brief glance at the QNX website, it appears to support POSIX, GNU make tools, and gcc-compatible C compilers. Thus it should be possible to get either Hugs or nhc98 up and running very quickly, maybe even straight out of the box, on all architectures. It is also likely that ghc could be persuaded to bootstrap (with a little work) on at least PowerPC and ix86 platforms, since the native codegen for those architectures is well maintained - MIPS, SH-4, StrongARM, and Xscale would be much more of a challenge for ghc though! Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] URLs in haskell module namespace
S. Alexander Jacobson wrote: As I move from machine to machine, it would be nice not to have to install all the libraries I use over and over again. I'd like to be able to do something like this: import http://module.org/someLib as someLib If the requested module itself does local imports, the implementation would first try to resolve the names on the client machine and otherwise make requests along remote relative paths. Embedding the path in the source code seems like a bad idea. If you want to allow modules to be loaded via URLs, it would make more sense to extend GHC's -i switch, i.e. ghc -i http://module.org/ ... -- Glynn Clements [EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell 6.4 perfomance
As I heard, 6.4 version of the Haskell using C-- backend and make lots of the resulting code perfomance (programs executed faster). If so, does any test/comparison with other languages available? Thank you in advance, Regards, /Alexandre. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell 6.4 perfomance
Think this should really go to glasgow-haskell-users... If this is true - how do I get ghc to use C--, and is it really faster than using gcc as a backend with all the bells whistles turned on (for a pentium-III) something like -O3 -mcpu=pentium3 -march=pentium3 -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -fno-crossjumping -mfpmath=sse,387 -ffast-math -fsched-spec-load -fprefetch-loop-arrays -maccumulate-outgoing-args -fmove-all-movables -freduce-all-givs Keean. Alexandre wrote: As I heard, 6.4 version of the Haskell using C-- backend and make lots of the resulting code perfomance (programs executed faster). If so, does any test/comparison with other languages available? Thank you in advance, Regards, /Alexandre. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell on QNX?
Liwen Huang wrote: I have successfully installed Hugs on QNX machine. As far as I can remember, you only need to make a few changes in the Makefile, (change gcc to qcc and change to proper qcc flags). It would be very helpful if you could mail the required changes. This way we could tweak the autoconf magic so Hugs can build on QNX out-of-the-box. Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Question on leazy evaluation
Hello, I'm very new to Haskell and I'm learning it in my spare time (ie. just for fun ;) ). I already had a quick look through tutorials, some articles, the Wiki, ... My question is: is there some (simple?) rule/criteria to ensure leazy evaluation will be efficient ? Typically, I process a list and I know each list item can be processed as it come. But I'm not sure my code uses correctly this property ! Is there some way to be sure leazy evaluation is correctly used by my code ? And are there coding rules that will ensure correct leazy evaluation ? Thanks, Pierre -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on leazy evaluation
On Thu, 24 Mar 2005, Pierre Barbier de Reuille wrote: My question is: is there some (simple?) rule/criteria to ensure leazy evaluation will be efficient ? One rule of thumb is: If your implementation works for infinite lists then it will also be quite efficient for finite lists. Do you mean criteria of this kind? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on leazy evaluation
Henning Thielemann a écrit : On Thu, 24 Mar 2005, Pierre Barbier de Reuille wrote: My question is: is there some (simple?) rule/criteria to ensure leazy evaluation will be efficient ? One rule of thumb is: If your implementation works for infinite lists then it will also be quite efficient for finite lists. Do you mean criteria of this kind? I think you mean doing something like : take 10 (fct infiniteList) .. this answers my first question: how to be sure it uses leazy evaluation :). But now the second (hardest ?) question: if the answer is no, how can I detect where leazy evaluation fails ? Is there first approximation rules, at least pointing where leazy evaluation is likely to fail ? (like avoiding functions like length, minimum, ..., some structure ...) Pierre -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] URLs in haskell module namespace
Dear list members, I'd like to share some sketchy ideas I have on the subject to address some of the issues raised. At 12:14 22/03/05 +, Malcolm Wallace wrote: I cannot see any of the Haskell compilers ever implementing this idea as presented. It would introduce an enormous raft of requirements (networking client, database mapping, caching, etc) that do not belong in a compiler - they belong in separate (preprocessing/packaging) tools. Furthermore, these tools already exist, albeit they are young and have a long maturation process still ahead of them. An external program acting as an URI streamer might be the solution. Such a program (identified via an environment variable or a compiler's command line option, just like Hugs external editor) would take an URI as its command line argument, and respond with a streamed contents of that URI on its stdout. Like e. g. curl/wget -O -. All the compiler has to do is popen() that program if an import statement contains an URI. Using curl/wget helps get around various issues with proxies/encryption/etc. as those programs are specifically designed for that. I do not believe this would result in significant overhead comparing to regular fopen() used by the compiler for opening source files. On a non-networked system, such a program would be a not so complicated shell script pretending it downloads from an URI, but reading from local disk (flash, any other kind of storage) instead. To address the problem of module/package URI changes over time, the following may be suggested. Either purl.org is used (and then it is responsibility of a package maintainer to keep its URL pointer valid). Or, some kind of a purl server may be set up somewhere (at haskell.org for example) which also supports mirroring. This means that for each package/module registered with this server, multiple locations are known (well, probably willing people might allocate their computer resources for that, at least I would not object as long as I have my own web server). The hypothetical purl server serves redirects as usual, but shifting randomly to another mirroring location for each new request for a module/package. So, if an attempt to retrieve a module/package fails, it may be repeated, and other mirror location will be tried. Mirrors will be synchronized behind the scenes. Will such a centralized purl server a bottleneck or a single point of failure? Probably not more than a centralized Hackage database (or is it planned to be distributed?) Also, some resolver might be part of the URI streamer which maps module names to URIs. For example, the Prelude will most likely be stored locally, but some other module will not. This means that the resolver consults the local package database (cabal), and its own cache, and either streams a local file or popens curl with some URI constructed specifically based on the desired module name. Once downloaded, a module may be cached with some TTL, so further recompilations do not result in curl involvement (until the TTL expires). PS This all is written in the assumption that Haskell source files are served. Binary distributions, of course would require different techniques. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
