March 2006 - Haskell - Haskell.org

Trying to get a Composite design pattern to work
by Asfand Yar Qazi 14 Mar '06

14 Mar '06

I'm trying to implement hierarchical states in Haskell, following on from my work at doing them in C++. Here's what I've got so far: data StateNode a = CompositeState [ StateNode a ] | State a stateslist :: StateNode a -> [a] stateslist(State x) = [x] stateslist(CompositeState xs) = {- return list of objects of type a -} The following give errors (as they should) -- stateslist(CompositeState xs) = [ stateslist(x) | x <- xs ] -- stateslist(CompositeState xs) = map stateslist xs You see what I'm trying to do? This is how I want it to behave: sm1 = CompositeState [ State 1, State 2, State 3 ] stateslist(sm1) => [1, 2, 3] How can I get this to work? My mind has just gone all wobbly! Thanks

3 3

debuggers
by Ernesto De Santis 11 Mar '06

11 Mar '06

Hi everybody I'm searching debuggers for Haskell, and I have this list: nhc tracer hood QuickCheck Auburn Hugs interpreter ghci (GHC interpreter) Some body know another debugger? Thanks a lot! Ernesto.

5 4

Trying On Learn Haskell Web Server
by Aditya Siram 11 Mar '06

11 Mar '06

Hi all, I am former imperative programmer (Java/C/Python) I have recently discovered Haskell and read through "Yet Another Haskell Tutorial" (the best I have found) and "Tackling The Awkward Squad". This paper mentions a Haskell Web Server (HWS) but I am not able to find the source. Where can I find the source? Has this code been updated since the paper was written? Can it be compiled and run on a recent version of GHC?Hugs? I would like to use it as an example program to teach myself Haskell. Thanks... Deech

8 9

TFP2006: Call for Participation
by Henrik Nilsson 10 Mar '06

10 Mar '06

Dear Colleague, Please find enclosed the call for participation in Trends in Functional Programming (TFP) 2006. Registration deadline: 17 March. My apologies for duplicate copies. Best regards, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn(a)cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. TFP 2006 Seventh Symposium on Trends in Functional Programming Nottingham, UK, 19 - 21 April, 2006 http://www.cs.nott.ac.uk/~nhn/TFP2006 Co-located with Types 2006 and Spring School on Datatype-Generic Programming CALL FOR PARTICIPATION ABOUT TFP The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best papers presented at the symposium for publication in a high-profile volume. The TFP symposium is the successor to the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in Edinburgh, Scotland in 2003, in Munich, Germany in 2004, and in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE). For further general information about TFP, see http://www.tifp.org/. PROGRAMME The list of papers accepted for presentation at TFP 2006 is available via the TFP 2006 website: http://www.cs.nott.ac.uk/~nhn/TFP2006/TFP2006-TalkList.html REGISTRATION TFP 2006 takes place Nottingham, UK, 19 - 21 April. It is co-located with Types 2006 (18 - 21 April) and and the Spring School on Datatype-Generic Programming 2006. Registration is open. Deadline: 17 March, 2006 CO-LOCATION WITH TYPES 2006 AND DATATYPE-GENERIC PROGRAMMING 2006 TFP 2006 is co-located with Types 2006 (to be held 18 - 21 April). To take advantage of the synergies offered by these two complementary events, there are joint keynote speakers, joint sessions on topics of mutual interest, such as dependently typed functional programming, and common social events. The schedule will be arranged so that participants may freely move between parallel sessions of the two events. See http://www.cs.nott.ac.uk/types06/ for further details. TFP 2006 and Types 2006 are immediately followed by the Spring School on Datatype-Generic Programming 2006 (24 - 27 April), which should be of direct interest to many of the TFP and Types Participants. See http://www.cs.nott.ac.uk/ssdgp2006/ for further details. ORGANISATION Symposium Chair: Marko van Eekelen, Radboud University Nijmegen, NL Programme Chair: Henrik Nilsson, University of Nottingham, UK Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Joel Wright, University of Nottingham, UK PROGRAMME COMMITTEE: o Kenichi Asai, Ochanomizu University o Gilles Barthes, INRIA, Sophia Antipolis o Olaf Chitil, University of Kent o Catherine Dubois, IIE, Evry o Marko van Eekelen, Radboud Universiteit Nijmegen o Jeremy Gibbons, Oxford University o Kevin Hammond, University of St Andrews o Zoltán Horváth, Eötvös Loránd University o Frank Huch, Christian-Albrechts-University of Kiel o Johan Jeuring, Universiteit Utrecht o Greg Michaelson, Heriot-Watt University o Henrik Nilsson, University of Nottingham o Ricardo Peña, Universidad Complutense de Madrid o Morten Rhiger, Roskilde University o Colin Runciman, University of York o Carsten Schürmann, IT University of Copenhagen o Zhong Shao, Yale University o Phil Trinder, Heriot-Watt University SPONSORS We are actively looking for additional TFP sponsors, who may help to subsidise attendance by research students, for example. If you or your organisation might be willing to sponsor TFP, or if you know someone who might be willing to do so, please do not hesitate to contact the Symposium chair: Marko van Eekelen. Your students will be grateful!

1 0

Non-trivial transformations from the Haskell markup
by oleg＠pobox.com 09 Mar '06

09 Mar '06

The earlier message showed that Haskell as it is can represent semi-structured data with reasonable syntax, extensible set of `tags', and statically enforced content restrictions. This follow-up demonstrates non-trivial transformations of so marked-up data -- rendering data in HTML and RSS/XML. The resulting document has the structure different from that of the original markup: hierarchies may be flattened, some pieces of data rearranged among elements. Rendering of a particular markup element may be truly context sensitive, e.g., by pulling data from the parent element. Creating an RSS document further requires `subordinate' HTML rendering. We also demonstrate markup transformations by successive rewriting (aka, `higher-order tags') and the easy definition of new tags. Our running example is rendering change log data in HTML and RSS/XML. This project has been inspired by Shae Matijs Erisson, who suggested I provide rss.xml feed for my site. You can see the ChangeLog in the master format and its two renderings at http://pobox.com/~oleg/ftp/ChangeLog.hs http://pobox.com/~oleg/ftp/ChangeLog.html http://pobox.com/~oleg/ftp/rss.xml The updated archive http://pobox.com/~oleg/ftp/Haskell/HSXML.tar.gz has the complete code. Here's a small example of the marked up semi-structured data/code in Haskell: > test_h = CLHead > HeadAttrs { > ha_description = "list of updates to this whole site", > ha_DateRevision = (5,February,2006), > -- snipped > } > (updates > > [update (5,February, 2006) > [ui (FileURLA "Computation/lambda-calc.html" "switch") > [[a [[code "switch"]]]] "in lambda-calculus"] > [ui (FileURLA "Haskell/types.html" "dependently-typed-append") > [[a "Dependently-typed" [[code "append"]]]]] > ] > ) Our document is made of a (heterogeneous!) sequence of update chunks; each chunk is a sequence of update elements, which contain the URL and additional markup. The corresponding HTML document looks like this <h2>February 5, 2006</h2> <ul> <li><a href="Computation/lambda-calc.html#switch"><code>switch</code></a> in lambda-calculus</li> Each 'ui' element turned into the HTML 'li' element. Please note that the value of the HREF attribute of the 'a' element comes from the URL attached to the _parent_ element. That is, rendering of the 'a' element of the original mark-up indeed depends on the context. The RSS code looks like the following: <item> <description><code>switch</code> in lambda-calculus</description> <link>http://top/Computation/lambda-calc.html#switch</link> <pubDate>5 Feb 2006 12:00:00 GMT</pubDate></item> <item> <description>Dependently-typed <code>append</code></description> <link>http://top/Haskell/types.html#dependently-typed-append</link> <pubDate>5 Feb 2006 12:00:00 GMT</pubDate></item> The 'update' element from the original markup is turned into nothing, with the update date spliced into each of the 'items'. The body of the 'description' element contains HTML-rendered (and then encoded) text. The HTML transformation is done by the following code: > toHTML (CLHead attrs updates) = > render (document > (head > [title (ha_title attrs)] > [meta_tag [description (ha_description attrs)]] > [author_address] > [meta_tag [pub_date (ha_DateRevision attrs)]] > [head_link LR_start [href (ha_top attrs)] > [title "All you can find here"]] > ) > (body > [h1 "Log of changes on" [[aref (ha_top attrs) "this site"]]] > [p nbsp] > [updates] > [change_log_prev (ha_history_first attrs)] > [change_log_prev (ha_history_last attrs)] > ) > ) We convert the original markup into another, intermediate markup (which, in turn, may go through a couple of more stages). It seems that complex transformations are sometimes easier if represented as a sequence of simple re-writings. The RSS rendering is equally simple: > toRSS (CLHead attrs updates) = > render (as_doc (HW (RSSChannel > (tdiv > [title "okmij.org"] > [GBE_description .= "okmij.org"] > [GBE_language .= "en-us"] > [GBE_ttl .= "21600"] -- 15 days > [GBE_generator .= "HSXML->RSS"] > [pub_date (ha_DateRevision attrs)] > [rss_link (ha_top attrs)] > [HW . UpdatesForRSS $ updates] > ) > ))) This code demonstrates easy extensibility via 'ad-hoc' tags like GBE_ttl. These tags still have to be declared: > data GBE_ttl = GBE_ttl deriving Show but that is the only one thing the user has to do for the tag. One could have introduced the notation ["ttl" .= "21600"] However, strings as element names are error prone: if the tag is mentioned several times in the code, we have to make sure it is spelled exactly the same way. Requiring a declaration at least enforces the uniform spelling. Another advantage is that the tag becomes apparent in the type of the element where it appears. Therefore, we may do more extensive content model validation. As mentioned already, writing an RSS document requires `subordinate' HTML rendering, for the content of the `description' element. In our framework, that is quite easy to accomplish. The HTML rendering code is polymorphic over the output monad, MonadOut. To render HTML into a string, we merely need an appropriate instance of MonadOut: > newtype ShowMonad a = ShowMonad (Writer [String] a) > deriving (Monad, MonadWriter [String]) > instance MonadOut ShowMonad where > emit_lit x = tell [x] > runShowMonad (ShowMonad m) = let (_,x) = runWriter m in x and so we can write > render_rss_item date url body = > emit_elem "item" [Hint_nl] Nothing > (Just . render . as_block $ > (tdiv > [GBE_description .= > (concat $ runShowMonad (runHTMLRender (render_inline False body)))] > [rss_link url] > [pub_date date])) without any need for unsafePerformIO.

1 0

Announcement: Bluespec, Inc. is seeking summer interns
by Ravi Nanavati 07 Mar '06

07 Mar '06

Bluespec, Inc. is a hardware design startup based in Waltham, Massachusetts that is building the next generation of Electronic Design Automation (EDA) tools. Bluespec's toolset, which is based on functional programming technology, delivers a high-level design and verification environment to current Verilog and VHDL designers of ASICs and FPGAs. Bluespec is the first high-level synthesis product that accelerates the design cycle and reduces verification costs while retaining the ability to deliver no-compromise hardware. Bluespec's technical team includes the noted programming-language luminaries Rishiyur Nikhil and Joe Stoy. Join Bluespec and be part of what's next in silicon design! For further details, please visit our website: www.bluespec.com Internship duration Full-time (40 hrs/week) during the summer of 2006. Roles and responsibilities Potential internship projects include: - Developing new language and tool features for the Bluespec synthesis engine, simulator and/or source-level GUI debugger - Creating hardware design benchmarks for synthesis and simulation - Designing and validating hardware design flows that include Bluespec and third-party EDA tools Interns will learn about cutting-edge approaches in hardware design and verification and will also gain experience with functional programming in a commercial context. Requirements - Currently enrolled in a BS/MS/PhD program with Computer Science or Electrical Engineering as a major - Strong programming background with a wide variety of languages (languages of specific interest include Haskell, C, Tcl/Tk and Perl) - Functional programming experience strongly preferred - Hardware design experience strongly preferred - Working knowledge of Linux/UNIX/Windows - Excellent communication, leadership and interpersonal skills - Knowledge of Verilog/VHDL/SystemVerilog/SystemC is a plus - Knowledge of current EDA products is a plus The number of internship slots is limited so applicants should send resumes to skp(a)bluespec.com (Sathyam Pattanam, VP Engineering) or careers(a)bluespec.com (Human Resources) as soon as possible. Thank you, - Ravi Nanavati P.S. Bluespec, Inc. is also seeking full-time software engineers. Please see http://www.bluespec.com/about/SWEngineers.htm for more information.

1 0

GPCE'06 Call for Tutorials/Workshops
by Emir Pasalic 07 Mar '06

07 Mar '06

------------------------------------------------------------------------ CALL FOR TUTORIALS/WORKSHOPS Fifth International Conference on Generative Programming and Component Engineering (GPCE'06) http://www.gpce.org/06/ October 22-26, 2006 Portland, Oregon (co-located with OOPSLA'06) Sponsored by ACM SIGPLAN, in cooperation with ACM SIGSOFT. Proceedings to be published by ACM Press. ------------------------------------------------------------------------ IMPORTANT DATES * Proposal submission deadline: Mar 18, 2006 * Date for notification of acceptance: May 01, 2006 WORKSHOPS --------- Overview GPCE workshops provide intensive collaborative environments where generative and component technology researchers and practitioners meet to discuss and solve challenging problems facing the field. We encourage proposals for innovative, well-focused workshops on a broad spectrum of component engineering and generative programming topics. All topics related to the theme of the conference are potential candidates for workshops. Workshops typically fall into the following categories: - A workshop may address a specific sub-area of generative and component technology in depth, e.g. model driven development. - A workshop may cover areas that cross the borders of several sub areas. Workshops that cross the borders of the formal and the applied areas is one example. - A workshop may also cross the border to other technologies or software engineering fields, e.g. development processes. - A workshop may focus on the application and deployment of generative and/or component technology in areas such as telecommunications, mobile computing or real-time systems. Workshops reporting on industrial experiences are particularly welcome. Workshop topics are by no means limited to the categories mentioned above. However, in each case, the proposed area is supposed to have enough impetus to yield new results that can be considered important and worth more detailed investigation. Submission Format Workshop proposals should be sent in ASCII or PDF format to the workshop chairs and should consist of the following four parts: 1. Cover Page - Name of the proposed workshop. - Names and addresses of the organizers. - Primary contact. - Intended number of participants. - Requested Audio/Video equipment. 2. Abstract Why is the proposed workshop relevant to GPCE? The abstract should provide a short overview of the rationale for the workshop and the major topics. In particular, statements about the review process and ways to ensure creativity during the workshop would be appreciated. The abstract should preferably not exceed 200 words. 3. Call for Participation A preliminary version of the Call for Participation that the organizers must prepare if the workshop is accepted. It should provide a brief overview of the proposed workshop including a description of the goals of the workshops and the work practices. It may repeat some of the statements made on the abstract page, but should be targeted specifically to potential workshop participants. 4. Organizers Bio and Past Events - Short biography of each organizer. - References to similar workshops organized at previous conferences, including the number of participants. If a workshop is accepted, the organizers will be requested to prepare a WWW page that will contain the latest information about the workshop. The web pages of each workshop will be linked to the GPCE workshop web site. Each workshop must have at least two organizers, preferably from different organizations. Please keep complete submissions to under four pages. Submission Process Electronic submission of proposals must be sent to workshops06(a)gpce.org. Proposals must be submitted no later than Mar 18, 2006, BUT EARLIER IS BETTER, as it allows for a more satisfactory coordination between workshop proposals. For More Information The complete call and additional information can be found at http://www.gpce.org/06/. For additional information, clarification, or questions please feel free to contact the Workshop Chairs (workshops06(a)gpce.org) The workshop chairs Christa Schwanninger, Siemens AG Hans-Arno Jacobson, University of Toronto TUTORIALS --------- Overview Proposals for high-quality tutorials in all areas of generative programming and component-based development, from academic research to industrial applications, are solicited. Tutorial levels may be introductory, intermediate, or advanced. A tutorial's purpose is to give a deeper insight into an area than a conventional lecture. Tutorials extend over a half or a full day. This gives the speaker the possibility to select a proper length for their tutorial. The topic of a tutorial can come from a truly broad spectrum. Any nteresting theme included but not restricted to the following topic list is welcome: - Generative programming - Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, step-wise refinement - Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, program transformation - Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, reflection - Generative techniques for - Product lines and architectures - Embedded systems - Model-driven development / architecture - Component-based software engineering - Reuse, distributed platforms, distributed systems, evolution, analysis and design patterns, development methods, formal methods - Integration of generative and component-based approaches - Domain engineering and domain analysis - Domain-specific languages (DSLs) including visual and UML-based DSLs - Separation of concerns - Aspect-oriented programming and feature-oriented programming, - Intentional programming and multi-dimensional separation of concerns - Industrial applications However, you should keep in mind that a tutorial must be expected to attract a reasonable number of participants. This is most likely the case if the topic is new or relevant to a broad community. If you have deep experience in a GPCE topic area, from which others could benefit, please consider submitting a proposal. Submission Format Proposals must contain all information specified in the tutorial submission template. See http://www.program-transformation.org/GPCE06/SubmissionFormat What should a tutorial look like? In case your tutorial is accepted, the tutorial guidelines document offers suggestions for preparing and presenting your tutorial. See http://www.program-transformation.org/GPCE06/TutorialGuideline Submission Process Electronic submission of proposals must be sent to tutorials06(a)gpce.org. Proposals must be submitted no later than Mar 18, 2006. The proposals received will be reviewed by the Tutorial Committee to ensure a high quality and appropriate mix for the conference. The Tutorial Chairs will work toward a diverse program that attracts a large interest among the broad segments within GPCE. For More Information The complete call and additional information can be found at http://www.gpce.org/06/. For additional information, clarification, or questions please feel free to contact the Tutorial Chairs (tutorials06(a)gpce.org) The tutorial chairs Christa Schwanninger, Siemens AG Hans-Arno Jacobson, University of Toronto

1 0

Haskell Weekly News: March 06, 2006
by dons＠cse.unsw.edu.au 07 Mar '06

07 Mar '06

Haskell Weekly News: March 06, 2006 Greetings, and thanks for reading issue 27 of HWN, a weekly newsletter covering developments in the Haskell community. Each Monday, new editions are posted to [1]the Haskell mailing list and to [2]The Haskell Sequence. [3]RSS is also available. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://sequence.complete.org/node/feed Announcements * Haskell as a markup language. Oleg Kiselyov [4]writes on using Haskell to represent semi-structured documents and the rules of their processing. [5]SXML is embedded directly in Haskell, with an open and extensible set of `tags'. The benefit of this is of course in static type guarantees, such as prohibiting an H1 element to appear in the character content of other elements. 4. http://www.haskell.org/pipermail/haskell/2006-March/017656.html 5. http://ssax.sourceforge.net * hmp3 1.0. Don Stewart [6]released hmp3 version 1. hmp3 is a curses-based mp3 player written in Haskell, designed to be fast, small and stable. 6. http://www.haskell.org/pipermail/haskell/2006-March/017674.html * Edison 1.2rc2. Robert Dockins [7]announced the second release candidate for Edison 1.2 is now ready for comments. 7. http://www.haskell.org/pipermail/libraries/2006-March/004983.html Haskell' This section covers activity on [8]Haskell'. * [9]Overlapping instances and constraints * [10]realToFrac * [11]instance Functor Set * [12]Keep the present Haskell record system! * [13]Relaxed instance rules spec * [14]Collections * [15]Partial type signatures/annotations/declarations.. * [16]How to create a proposal 8. http://hackage.haskell.org/trac/haskell-prime 9. http://www.haskell.org/pipermail/haskell-prime/2006-February/000783.html 10. http://www.haskell.org/pipermail/haskell-prime/2006-February/000791.html 11. http://www.haskell.org/pipermail/haskell-prime/2006-March/000834.html 12. http://www.haskell.org/pipermail/haskell-prime/2006-March/000836.html 13. http://www.haskell.org/pipermail/haskell-prime/2006-March/000837.html 14. http://www.haskell.org/pipermail/haskell-prime/2006-March/000854.html 15. http://www.haskell.org/pipermail/haskell-prime/2006-March/000861.html 16. http://www.haskell.org/pipermail/haskell-prime/2006-March/000867.html Discussion * Library Reorganisation. Simon Marlow [17]opened up a discussion on library reorganisation, in the light of the oncoming Haskell'. 17. http://www.haskell.org/pipermail/libraries/2006-March/004965.html * Deprecating FunctorM. Ross Paterson [18]proposes to replace FunctorM with Data.Traversable. 18. http://www.haskell.org/pipermail/libraries/2006-March/004966.html * cabal-setup. Simon Marlow [19]posted a patch to wrap the Setup.hs Cabal script with a generic cabal-setup interface. 19. http://www.haskell.org/pipermail/libraries/2006-March/004966.html Code Watch * Make -split-objs work with --make Thu Mar 2 09:05:05 PST 2006 Simon Marlow This turned out to be a lot easier than I thought. Just moving a few bits of -split-objs support from the build system into the compiler was enough. The only thing that Cabal needs to do in order to support -split-objs now is to pass the names of the split objects rather than the monolithic ones to 'ar'. Quotes of the Week [OConnor's Law] roconnor :: As an online discussion of static types vs dynamic types grows longer, the probability of mentioning heterogenous lists approaches 1. [Lemmih's Law] Lemmih :: Every 18 months, compilers will make their warnings and error message s twice as cryptic Claus Reinke :: The point about overlapping instances is that they shouldn't. Contributing to HWN You can help us create new editions of this newsletter. Please see the [20]contributing information, send stories to dons -at- cse.unsw.edu.au. The darcs repository is available at darcs get http://www.cse.unsw.edu.au/~dons/code/hwn 20. http://haskell.org/haskellwiki/HWN

1 0

ANNOUNCE: hmp3 1.0
by dons＠cse.unsw.edu.au 06 Mar '06

06 Mar '06

A new version of hmp3 has been released, version 1.0. All features that I'm interested in are implemented (and it appears to be extremely stable, running non-stop for the last 3 months on one machine). This release adds the ability to dynamically reconfigure the colours using a configuration file. Available as a cabalised src tarball, a darcs repo, and binaries for (currently): * Linux/x86 It is also known to run on FreeBSD, OpenBSD, OSX and Irix/mips64. http://www.cse.unsw.edu.au/~dons/hmp3.html Cheers, Don

1 0

Re: [Haskell] Problems compiling hs-plugins
by Duncan Coutts 05 Mar '06

05 Mar '06

Hi Ben, Yes, I did what dons recommended and copied the Typeable.h from ghc-6.4.1 to make it compile with ghc-6.5, however in the end I couldn't get all the hIDE plugins to load with hs-plugins anyway (even though they would all load in ghci). So what I did in the end is to do a static build of hIDE. That is to have a main module that just directly imports all the plugins and calls their initialisation routines in dependency order. Until we have a reliable plugin loading system I think this is the way to go. It makes it much easier to build. But yes, you still have to use the ghc.hide and gtk2hs.hide darcs repos. These are both development snapshots that work with hIDE. Duncan On Sun, 2006-03-05 at 10:18 +0000, Axel Simon wrote: > Ben, > > Duncan has just managed to get hIDE to compile. There's some issue that > after the hs-plugins dilemma, you run into another one sine hIDE was > developed against a CVS snapshot of Gtk2Hs. Duncan has a patch to work > with the released version. > > Axel. > > On Sun, 2006-03-05 at 00:12 +0100, Benjamin Franksen wrote: > > On Saturday 04 March 2006 03:32, you wrote: > > > benjamin.franksen: > > > > [...] > > > > INSTANCE_TYPEABLE1([],listTc,"[]") > > > > > > > > However, I could not find any definition for these macros. Nor does > > > > the package docs mention what to install in order to get them. > > > > > > [...] > > > This Typeable macro issue is due to the Typeable.h header, which used > > > to be distributed with GHC. It's not distributed with the GHC head > > > anymore -- are you using ghc 6.5? > > > > Ah, yes. This is because I want to build hIDE. The hIDE readme suggested > > to use http://scannedinavian.com/~lemmih/hs-plugins, but scannedinavian > > seems to be dead. Anyway, in the meantime the suggestion has been > > fixed, it now points to http://darcs.haskell.org/~lemmih/hs-plugins > > which I just downloaded. So, maybe all troubles go away now. > > > > > You can work around it by copying Typeable.h from the darcs > > > repository into the include/ directory of your ghc distribution, or > > > using ghc 6.4.x > > > > I'll try the version above and see what I get. If it doesn't work, I'll > > try copying the Typeable.h file from somewhere. > > > > Many thanks! > > > > Ben > > _______________________________________________ > > Haskell mailing list > > Haskell(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell >

2 2