Confused by profiling
Hi all I am confused by the GHC profiling output. I have put some abstracts below to illustrate my confusion. I compiled my code with: HFLAGS=-Wall -package lang -prof -auto-all hmake -ghc main and then ran it with: ./main -t +RTS -p test5.hs Here is some of main.prof: individual inherited COST CENTRE MODULE entries %time %alloc %time %alloc [...] parse Parser 10.0 0.0 81.4 62.3 p_module Parser 00.0 0.0 81.4 62.3 | PC_base 69517 20.3 5.7 81.4 62.3 [...] p_aexp_list Parser 00.0 0.0 0.0 0.3 con2tag_Token# Tokens 8800.0 0.0 0.0 0.0 pIfThing PC_base8960.0 0.0 0.0 0.0 $ PC 00.0 0.0 0.0 0.3 $ PC 00.0 0.0 0.0 0.3 pSucceed PC_base8960.0 0.3 0.0 0.3 * PC_base8960.0 0.0 0.0 0.0 *PC_base8960.0 0.0 0.0 0.0 p_aexp_tupleParser 00.0 0.0 0.0 0.3 [...] and here is the code for p_aexp_list: p_aexp_list :: Parser Token Aexp p_aexp_list = (Aexp_list . get_rights) $ pIfThing ((==) (Special '[')) * pSList False p_comma p_exp * pIfThing ((==) (Special ']')) Now basically my problem is how things under p_aexp_list can be entered 896 times if p_aexp_list is entered 0 times - am I reading it wrong? And the only place p_aexp_list is called from is p_aexp_init = p_aexp_qvar | p_aexp_gcon | p_aexp_literal | p_aexp_paren | p_aexp_tuple | p_aexp_list | p_aexp_arith | p_aexp_listcomp | p_aexp_left | p_aexp_right but my reading of the profile output shows it as being called from | which is in turn called from p_module (all lines in the second [...] are indented with at least ). Am I missing something obvious? Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc/HopenGL/cygwin/W2K
I'm trying to get to the point where I can use ghc and OpenGL under Windows 2000. Unfortunately, I'm lost in a maze of version numbers. I had cygwin-1.3.2 installed, I think, which did not match the 1.3.1 used in the ghc-4.08 package. I tried to install cygwin 1.3.1, but got 1.3.3 instead. Nowhere can I find a course for 1.3.1. Nor can I find 5.00.2 compiled for Windows, though there is some mention of W2K support in the documentation. Can anyone provide me with a recent road map? I don't mind compiling everything, if that's what it takes, I just feel I'm wandering in the wilderness. Thanks, Clifford Beshers ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Haskell98 undefinedness
Personally I think this is ok, and it's compatible with the relaxed story about cumulative imports. I don't propose to change this unless there are yells. | So, it's not considered an error if you do something | like | | module A ( B(C), ...some other stuff..., B(D) ) where | ... | data B = C | D | | but C and D is exported. Is the extra flexibility of | allowing duplicates really worth it? Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] asks:
12 Sep 2001 12:37:25 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] pisze:
* Currently HOPS implements only one evaluation strategy,
namely leftmost outermost graph rewriting with sharing preservation
(without automatic sharing maximisation).
With the standard rules in place, this corresponds
to the original definition of lazy evaluation
(also known as the ``D-rule''), which is different
from the lazy pattern matching evaluation
of sequential Haskell implementations.
What is the difference?
If you have
f x [] = 0
f x (y:ys) = 1 + f x ys
bot = bot
and consider the redex
f bot (enumFromTo 1 2)
then leftmost outermost rewriting (sharing is irrelevant here) diverges:
f bot (enumFromTo 1 2) -
f bot (enumFromTo 1 2) - ...
while the ``functional strategy'' finds out that the second argument
needs to be evaluated first, and terminates:
f bot (enumFromTo 1 2) -
f bot (1 : enumFromTo 2 2) -
1 + f x (enumFromTo 2 2) -
1 + f x (2 : enumFromTo 3 2) -
1 + (1 + f x (enumFromTo 3 2)) -
1 + (1 + f x []) -
1 + (1 + 0) -
1 + 1 -
2
For a definition of the functional rewriting strategy
see for example p. 139f in:
@Book{Plasmeijer-vanEekelen-1993,
author = {Rinus Plasmeijer and van Eekelen, Marko},
title ={Functional Programming and Parallel Graph Rewriting},
publisher ={Addison-Wesley},
year = 1993,
series = {International Computer Science Series},
ISBN = {0-201-41663-8}
}
The fact that Haskell uses the functional strategy
should also follow from the translation for function bindings
given in the Haskell report, section 4.4.3
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/decls.html#sect4.4.3
in conjunction with the pattern matching semantics, section 3.17.
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/exps.html#pattern-matching
However, I already have troubles with
the first sentence of 3.17.2 ``Informal Semantics of Pattern Matching'':
http://research.microsoft.com/~simonpj/haskell98-revised/haskell98-report-html/exps.html#sect3.17.2
which says: ``Patterns are matched against values.'':
Variables are patterns, and in the above example,
the variable x is matched against the non-value bot ---
if my understanding of values is correct.
(Also, the direction of ``matching against'' in this
sentence is contrary to that used in most of the explanations that follow
after it.)
For the examples section of 3.17.2,
perhaps one might add an example under item 1. that illustrates this effect:
| If (x,'b') is matched against (_|_,'b'),
| the match succeeds and binds x to _|_.
Wolfram
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
LOPSTR 2001 - Submission Deadline Extension
___ Our apologies if you receive multiple copies. ___ CALL FOR PAPERS LOPSTR 2001 11th International Workshop on Logic-based Program Synthesis and Transformation http://www.iasi.rm.cnr.it/~adp/lopstr01_cfp.html Paphos, Cyprus, November 28 - 30, 2001 The deadline for abstract submission has been extended to: *** September 24th, 2001. Invited Speaker: Natarajan Shankar, SRI, Menlo Park, CA, USA, Generating Efficient Code from Logic. The following is a non-exhaustive list of topics: specification analysis component-based software development synthesis optimization software architectures verification composition design patterns and frameworks transformationreuse specializationapplications Any other information is available at: http://www.iasi.rm.cnr.it/~adp/lopstr01_cfp.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
FME 2002: Call for Papers
** Apologies if you receive multiple copies... ** ** Also apologies if you have unsubscribed to this mailing list in the past, we had to reinstall the original list and were unable to recover the unsubscriptions. Please note that the list is ONLY used to announce the 18-monthly FME (Formal Methods Europe) symposia. ** FORMAL METHODS EUROPE FME 2002 Formal Methods: Getting IT Right International Symposium and Tutorials http://floc02.diku.dk/FME/ 20-24 July 2002 Call for Papers *** FME 2002 is the eleventh in a series of symposia organised by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. These symposia have been notably successful in bringing together a community of users, researchers, and developers of precise mathematical methods for software development. In 2002 the symposium will be held in conjunction with the third Federated Logic Conference (FLoC'02) in Copenhagen, Denmark. The theme of FME 2002 is Formal Methods: Getting IT Right. The double meaning is intentional. On the one hand, the theme acknowledges the significant contribution formal methods can make to Information Technology, by enabling computer systems to be described precisely and reasoned about with rigour. On the other hand, it recognises that current formal methods are not perfect, and further research and practice are required to improve their foundations, applicability and effectiveness. FME seeks papers in all aspects of formal methods for computer systems, including the following: * theoretical foundations * practical use and case studies * specification and modelling techniques * software development and refinement * tool support and software engineering environments for formal methods * verification and validation * hidden formal methods, and making benefits available to non-experts * reusable domain theories * method integration * hardware verification In addition to presentations of submitted papers, the symposium will offer tutorials, workshops, invited speakers, and tool demonstrations. PAPERS Full papers should be submitted in Postscript or PDF format by e-mail to reach the Program Co-chairs by 15 January 2002. Papers will be refereed by the Program Committee and must be original research papers that have not been submitted elsewhere for publication. Accepted papers will be published in the symposium proceedings. Papers should not exceed twenty pages, although longer papers will be considered if their content justifies it. LNCS format should be used: see http://www.springer.de/comp/lncs/authors.html for details. Please include a short list of keywords on a separate line at the end of the abstract, beginning with the word Keyword: in boldface. OTHER SYMPOSIUM ACTIVITIES Tutorials and workshops will be held on 20-21 July 2002. Each tutorial will last one-half or one day. Proposals are welcome, and should be directed to the Program Co-chairs by 15 January 2002; more details will appear on the web-site above. Tool demonstrations will also take place during the symposium, with the opportunity for presentations to be made about each tool. Proposals for tool demonstrations should be made to the Tool Demonstration Coordinator, with whom provison of necessary computing facilities should be discussed. PEOPLE Organising Chair Dines Bjørner Informatics and Mathematical Modelling Building 322, Richard Petersens Plads Technical University of Denmark DK-2800 Lyngby, Denmark Tel: +45 4525 3720 Email: [EMAIL PROTECTED] Programme Co-chairs Lars-Henrik Eriksson, Industrilogik L4i AB Box 21024, SE-100 31 Stockholm, Sweden Tel: +46 1859 1690 Fax: +46 1847 17058 Email: [EMAIL PROTECTED] Peter Lindsay, Software Verification Research Centre The University of Queensland, Queensland 4072, Australia Tel: +61 7 3365 2005 Fax: +61 7 3365 1533 Email: [EMAIL PROTECTED] Programme Committee Bernhard Aichernig Graz University of Technology, Austria Juan Bicarregui SERC Rutherford Labs, UK Ernie Cohen Telcordia Technologies, USA Ben Di Vito NASA Langley Research Center, USA Cindy Eisner IBM Haifa Research Laboratory, Israel Lars-Henrik Eriksson (co-chair) Industrilogik, Sweden John Fitzgerald Transitive Technologies Ltd, UK Jim Grundy Intel Corporation, USA Yves Ledru LSR/IMAG, Domaine Universitaire, France Peter Lindsay (co-chair) University of Queensland, Australia Markus Montigel University of New Orleans, USA Richard Moore IFAD, Denmark Tobias Nipkow Technische Universität München, Germany Colin O'Halloran Qinetiq (ex-DERA), UK Jose Oliveira Universidade do Minho, Portugal Nico Plat West Consulting, The Netherlands Jeannette Wing
Re: The future of Haskell discussion
Olaf Chitil [EMAIL PROTECTED] wrote, Here a short summary by Malcolm and me of the final discussion at the Haskell workshop: I also took a couple of notes which I like to add. John Launchbury and many further people made a plea that the single biggest hindrance to the further spread of Haskell is the lack of a standard cross-platform GUI. Alas, no answer to the problem was found. There is no agreement which (existing) library could be the basis of a standard one and nobody wanted to commit himself to developing and supporting such a library. Well, Manuel Chakravarty promised to continue developing the GTK+ binding and would be happy about people helping him. (The GUI library presented at the workshop is not intended to solve the standard GUI problem.) In fact, the recent release of binary packages for Gtk+HS and an example applications that demonstrates how to use the GTK+ API in Haskell have been a reaction to the discussions at HW ICFP. Let me reiterate: Gtk+HS as it is today is sufficient for applications requiring a GUI of medium complexity. As far as I see, despite not covering all of GTK+ yet, Gtk+HS already has a wider variety of widgets and functionality than Tcl/Tk provides in its whole API. So, at least on Unix, the statement that there is no GUI for Haskell is just not valid anymore. For Win32, somebody would have to set up the binding for use with the Win32 port of GTK+. I am happy to include any patches coming out of this into the main distribution. You can see how programs coded against the GTK+ API in Haskell look like at the following example: http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html (As for Unix/Win32 portability of GUI code, that's not great for C or C++ either.) Rather than starting work on a successor to Haskell, people generally want to see `blessed addendums' to the Report, for common agreed extensions, e.g. FFI, exceptions, concurrency, MPTC, fundeps, etc. The FFI addendum is almost ready, but any others need volunteers, not to mention agreement between designers and implementations. The idea is that a solid reference definition/documentation of each extension should exist independent of any particular compiler (but there is a lack of volunteers). It was noted that the future job of designing Haskell-2 will be made much easier by many small steps rather than one large effort. Generally, as last year, there seemed to be not much interest to look into Haskell 2. Meanwhile, addenda to H98 seem to be a feasible alternative. In fact, one aim with the FFI Addendum was to create a precedent that can be repeated for other extensions. The nature of an addendum brings with it that the extension should be rather non-invasive. For example, in the case of the FFI, one new keyword (`foreign') is added, taking it from the pool of available variable identifiers. The rest of the functionality should not invalidate any existing H98 programs. As a consequence, the kind of extensions that can be realised in this way are limited. For example, extensions of the type system are much more likely to have a severe effect on existing H98 programs. So, they will be less easy to add in this form. It was also pointed out that we should go for an addendum only where - the design is clear and tested (example implementations exist and have been used in applications) and - where there is considerable demand. The first point is surely self-explanatory. As for the second, defining an addendum is a lot of work, which can be used better otherwise unless the extension is really important. Possible further addenda (in addition to the FFI), which have been mentioned, are the following: - The core library (in fact, there is already exists a task force to look into this extension) - Concurrency support (there just are applications that are virtually impossible to implement well without concurrency) - Exceptions (again a really elementary feature of modern languages) - Graphics library (obviously there is a lot of demand, but it is also a rather involved task) In my opinion, all the above functionality falls into the catergory embarrassing not to have. The lack therefore, in fact, promotes the image of Haskell being an academic toy language. The only exception is to a degree the graphics library (again my opinion, which obviouly is not shared by everybody, most notably John Launchbury). My reason is that, while access to GUI toolkits is a must, few languages standardise them. Type extensions (multi-parameter type classes, existential types, rank-2 polymorphism, etc.) have been mentioned, but it seemed that there isn't really a consus as to how they should exactly be implemented and whether they are really so urgently needed. Moreover, they tend to be more invasive. Personally, I would believe that multi-parameter type classes may maybe be the most likely candidate for an addendum. There was the feeling that there is not frequent
Re: The future of Haskell discussion
Rather than talking about general features of the language that might improve adoption in general, it is more useful to talk about specific features of the language that make it killer in a particular application domain. In his classic book, Crossing the Chasm : Marketing and Selling High-Tech Products to Mainstream Customers, Geoffrey Moore argues that the way to gain mainstream adoption of a new technology is to target specific segments of the customer population and to deliver whole product to them (because integration challenges are daunting). In http://www.paulgraham.com/lib/paulgraham/bbnexcerpts.txt, Paul Graham argues that: One of the reasons to use Lisp in writing Web-based applications is that you *can* use Lisp. When you're writing software that is only going to run on your own servers, you can use whatever language you want. And further that: Until recently, writing application programs meant writing software to run on desktop computers. In desktop software there was a strong bias toward writing the application in the same language as the operating system. I would add that web based applications can use web interfaces and that HTML is a good interface to many applications. (and that Paul Graham's comments about Lisp are also true of Haskell) As such, I would like to see a focus on making Haskell great for web application and web service development. Some of the the pieces required are application level, some are libraries, and some are language features. Here is my quick take: Application Framework * a simple build/install process on both unix and win32 * a way to run/link haskell applications to a web server (apache) * a decent libary organization and CPAN-like library sharing system * a system for publishing apps to live servers Libraries * an OS file/directory access library * a database connection library (even just ODBC would be fine!) * a database connection pool library * a mail handling library * an XML parser library * an XML-RPC/SOAP library Language Features * concurrency (to make requests to multiple servers simultaneously) * FFI (to access libraries in other languages) * exceptions (may not matter depends on the webserver/haskell interface!) Documentation * an O'Reilly class book on learning and developing web apps in Haskell * sample applications that demonstrate useful web service functions * a process for managing Haskell web app development As a general matter, the addendum process strikes me as confusing and dangerous. I don't want to have a conversation like: I am using Haskell'98 with Addendum A, C, and E. I'd rather say, I am using Haskell 2001 and know that it is useful for developing web apps. I know this is a lot of work, but it was what you get from Python, Perl, and Java. If Haskell wants to compete in this arena, it needs to provide this level of service. Also, I think a lot of these exist in pieces, so the real work is in compiling it all into a good usable package. I am not volunteering to do it, but I would be happy to help beta if someone else does. -Alex- PS There may be other better/easier initial application domains for Haskell, but this is what I know. ___ S. Alexander Jacobson Shop.Com 1-646-638-2300 voiceThe Easiest Way To Shop (sm) On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: Olaf Chitil [EMAIL PROTECTED] wrote, Here a short summary by Malcolm and me of the final discussion at the Haskell workshop: I also took a couple of notes which I like to add. John Launchbury and many further people made a plea that the single biggest hindrance to the further spread of Haskell is the lack of a standard cross-platform GUI. Alas, no answer to the problem was found. There is no agreement which (existing) library could be the basis of a standard one and nobody wanted to commit himself to developing and supporting such a library. Well, Manuel Chakravarty promised to continue developing the GTK+ binding and would be happy about people helping him. (The GUI library presented at the workshop is not intended to solve the standard GUI problem.) In fact, the recent release of binary packages for Gtk+HS and an example applications that demonstrates how to use the GTK+ API in Haskell have been a reaction to the discussions at HW ICFP. Let me reiterate: Gtk+HS as it is today is sufficient for applications requiring a GUI of medium complexity. As far as I see, despite not covering all of GTK+ yet, Gtk+HS already has a wider variety of widgets and functionality than Tcl/Tk provides in its whole API. So, at least on Unix, the statement that there is no GUI for Haskell is just not valid anymore. For Win32, somebody would have to set up the binding for use with the Win32 port of GTK+. I am happy to include any patches coming out of this into the main distribution. You can see
Re: The future of Haskell discussion
On Thu, 13 Sep 2001, S. Alexander Jacobson wrote: (snip) As such, I would like to see a focus on making Haskell great for web application and web service development. Some of the the pieces required are application level, some are libraries, and some are language features. Here is my quick take: (snip) I know this is a lot of work, but it was what you get from Python, Perl, and Java. If Haskell wants to compete in this arena, it needs to provide this level of service. Also, I think a lot of these exist in pieces, so the real work is in compiling it all into a good usable package. I am not (snip) For what little it's worth, I'm encouraged just to see people talking like this lately: such things would make a lot of difference in making me much more comfortable about using Haskell for non-trivial commercial projects. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
There was the feeling that there is not frequent enough feedback from the Task Forces (eg, FFI Task Force, Library Task Force) to the Haskell community as a whole. Clause Reinke kindly volunteered to collect status reports of Task Forces on a 6-monthly basis and post them to the Haskell mailing list. Claus, maybe you should give the Task Forces an idea of when you expect the first status report. Just a quick update: when I was volunteered for organising more frequent feedback from the task forces to the Haskell community as a whole, I thought of just collecting individual summaries from the existing lists. However, my current opinion on the matter is that this alone would actually be a bad idea, as there are too many lists, no lists for some important topics, some topics spread over several lists, and generally not enough useful structure for the wide range of Haskell sub-communities. So what has been holding up the call for status reports from here (apart from the usual real work:-) is my attempt to (a) gather as many of the various Haskell interest groups as I can and (b) find some way to organise them, so that I get an idea of who is out there and how the pieces might fit together. I won't even try to get everything right in the first go, so I hope to send round a first draft of a structure (based on existing info at haskell.org and elsewhere) in the next days. The main point I'm still undecided on is at what level to ask for status reports. In my current version of the hierarchy, there are three levels, with 4-5 broad areas at the top (such as libraries, implementations, etc.), and many of the existing mailing lists or projects, such as Gtk+HS, at the most detailed level. If our community was more organised, I would really like to see reports at the middle (e.g., what's up in terms of GUIs?-) or top level, but as it stands, I will probably need to look for anything I can get at the mailing-list level and then try to edit all those fragments into a more useful overview. For the timescale, I still think that 6-monthly reports are a sensible compromise, and the Haskell workshops are a good reference point. I'll ask for the first status reports as soon as I've got an idea of how everything might fit together, probably early next week. The second round will then take place in between Haskell workshops, and so on. It would be nice if we could cover not only the explicit task forces, but all Haskell (sub-)communities (such as the folks interested in generic programming, or in concurrent/parallel/distributed programming, functional reactive programming, etc.). That'll mean that the individual status reports themselves will have to be brief (plus pointers to more detailed documents, and instructions about how to join the communities or find archives), which should also make it easier to find people who write them;-). More later, Claus ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Just a quick remark: S. Alexander Jacobson wrote (on 13-09-01 12:40 -0400): As a general matter, the addendum process strikes me as confusing and dangerous. I don't want to have a conversation like: I am using Haskell'98 with Addendum A, C, and E. I'd rather say, I am using Haskell 2001 and know that it is useful for developing web apps. Eventually, you will be saying that, but about Haskell-2. In the interim, having extensions described in addendums is probably better than the situation we have now, in which you are forced to say that I am using Haskell with extension X (but with whose semantics?) or I am using GHC Haskell (but Hugs also supports my extension). At least if an extension is described in a Haskell Report Addendum one knows where to look for its semantics, that its semantics are standardized, and that it is reasonably accepted by the community and not some Bizarro (I love that word :) extension which will only ever be implemented in some obscure researcher's pet compiler project. -- Frank Atanassow, Information Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands Tel +31 (030) 253-3261 Fax +31 (030) 251-379 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
Quick reply to just one point (more later, I hope): Also, do these books have good coverage of things like existential types, functional dependencies, other experimental-but-apparently-crucial features that are hard to find documentation for? I consider myself a fairly hardcore Haskell user (I used to be a language designer and compiler/library developer but now I work on another language and write my tools in Haskell and perl). Despite this, I don't think I use any of the features you list (I guess I'm suggesting that these might not be the most important to you either). I do use the IO monad, IORefs (sparingly), constructor classes, lots of libraries, the foreign function interface (lets you call C and C++), parser generators (happy) and parser combinators, exception handling and concurrency (even just the lame non-preemptive version that Hugs provides). Of course, this partly reflects the kinds of programs I write and, to some extent, my being comfortable with the features and libraries I know and not having time to really explore what I can do with the other features. -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Application letters at the Haskell workshop: suggestion
Thanks, that's very valuable information. It's hard to appreciate the relative utility (as you can see :-)) of different experimental features. It's also confusing that things like exceptions, concurrency, and FFI are labeled 'experimental'. They're so (IMHO) crucial that I find myself saying, Okay, if exceptions are 'experimental', what other really important things might I be missing by not being familiar with all the experimental extensions? Thanks for clearing that up somewhat. On a tenuously related note, I should mention that so many Haskell examples focus on things which fit easily into a functional mold (factorial, etc.) that I did not actually have the faintest idea how to create a real and useful Haskell program until I saw the code for Simon Marlow's web server. The snippets on Doug Bagley's Computer Language Shootout were also helpful. It's also very difficult to find examples which demonstrate the use of experimental features. I mention this only because your report below of what features you use daily provides a useful point of reference for people wondering what actually goes into a non-trivial Haskell application. Bryn I consider myself a fairly hardcore Haskell user (I used to be a language designer and compiler/library developer but now I work on another language and write my tools in Haskell and perl). Despite this, I don't think I use any of the features you list (I guess I'm suggesting that these might not be the most important to you either). I do use the IO monad, IORefs (sparingly), constructor classes, lots of libraries, the foreign function interface (lets you call C and C++), parser generators (happy) and parser combinators, exception handling and concurrency (even just the lame non-preemptive version that Hugs provides). Of course, this partly reflects the kinds of programs I write and, to some extent, my being comfortable with the features and libraries I know and not having time to really explore what I can do with the other features. -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On Thursday, 13. September 2001 17:50, Manuel M. T. Chakravarty wrote: [...] Let me reiterate: Gtk+HS as it is today is sufficient for applications requiring a GUI of medium complexity. As far as I see, despite not covering all of GTK+ yet, Gtk+HS already has a wider variety of widgets and functionality than Tcl/Tk provides in its whole API. So, at least on Unix, the statement that there is no GUI for Haskell is just not valid anymore. For Win32, somebody would have to set up the binding for use with the Win32 port of GTK+. I am happy to include any patches coming out of this into the main distribution. In my opinion GTK+ is not that nice to develop Win32 applications because it provides its own look-and-feel which conflicts with the one of Windows. On UNIX-like systems where each desktop environment has its own look-and-feel it does not conflict under GNOME because GNOME is based on it. That's why I think GTK+ should be used mainly to develop applications which are intended to run under GNOME and preferably not to do cross-plattform GUI programming. I think the best solution for the latter thing is to use a library which has multiple implementations based on different native libraries like Win32, GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this kind of library. [...] Type extensions (multi-parameter type classes, existential types, rank-2 polymorphism, etc.) have been mentioned, but it seemed that there isn't really a consus as to how they should exactly be implemented and whether they are really so urgently needed. I need at least multi-parameter type classes urgently. I am currently working on a software package allowing website implementation in Haskell which relies on them. [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: The future of Haskell discussion
In my opinion GTK+ is not that nice to develop Win32 applications because it provides its own look-and-feel which conflicts with the one of Windows. On UNIX-like systems where each desktop environment has its own look-and-feel it does not conflict under GNOME because GNOME is based on it. That's why I think GTK+ should be used mainly to develop applications which are intended to run under GNOME and preferably not to do cross-plattform GUI programming. I think the best solution for the latter thing is to use a library which has multiple implementations based on different native libraries like Win32, GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this kind of library. [Bryn Keller] Yes, exactly. Additionally, I have had trouble with bugginess in GTK on Win32 (not the Haskell bindings, but GTK itself), and things which want to compile with GTK usually insist on using an executable called gtk-info (IIRC) or something similar -- but on windows, only the DLLs are available (last time I checked). My personal vote would be for wxWindows - it's good stuff, and it's free even for commercial use. Qt's main advantage IMHO is in internationalization. The thing I'd most like to see, however, is not a standard C++ toolkit, but a standard Haskell GUI API which could then be implemented on top of other things (wxWindows, GTK, OpenGL, XUL, etc.). Frantk is implemented something like this I believe, and Fruit also has an interesting (if young) model. Bryn ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
[EMAIL PROTECTED] wrote: Thanks, that's very valuable information. It's hard to appreciate the relative utility (as you can see :-)) of different experimental features. It's also confusing that things like exceptions, concurrency, and FFI are labeled 'experimental'. They're so (IMHO) crucial that I find myself saying, Okay, if exceptions are 'experimental', what other really important things might I be missing by not being familiar with all the experimental extensions? Thanks for clearing that up somewhat. I have been writing substantial Haskell programs and I use *NO* experimental features. What I'm currently working on is over 2 lines of Haskell 98. No extensions whatsoever. (It even compiles and runs with all available Haskell implementations.) Granted, I write mostly compiler like programs (files in, files out), but there is still a lot you can do in Haskell just as it is. Sometimes it might require bending slightly backwards to get it done, though. -- Lennart PS. OK, a small confession, that program contains one unsafePerformIO for performance reasons. It works fine without it, but 5% slower. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
Lennart Augustsson wrote: I have been writing substantial Haskell programs and I use *NO* experimental features. What I'm currently working on is over 2 lines of Haskell 98. No extensions whatsoever. (It even compiles and runs with all available Haskell implementations.) Granted, I write mostly compiler like programs (files in, files out), but there is still a lot you can do in Haskell just as it is. Sometimes it might require bending slightly backwards to get it done, though. Well, that's nothing! I have been writing substantial ANSI C programs and I use *NO* experimental features. What I'm currently working on is over 2 lines of ANSI C. No extensions whatsoever. (It even compiles and runs with all available C implementations.) Granted, I write mostly compiler like programs (files in, files out), but there is still a lot you can do in ANSI C just as it is. Sometimes it might require bending slightly backwards to get it done, though. ;-) --Jeff ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Application letters at the Haskell workshop: suggestion
[EMAIL PROTECTED] wrote, Thanks, that's very valuable information. It's hard to appreciate the relative utility (as you can see :-)) of different experimental features. It's also confusing that things like exceptions, concurrency, and FFI are labeled 'experimental'. They're so (IMHO) crucial that I find myself saying, Okay, if exceptions are 'experimental', what other really important things might I be missing by not being familiar with all the experimental extensions? Thanks for clearing that up somewhat. Maybe it should be clarified that there are exceptions in H98, but *only* in the IO monad. What the extension is about are exceptions in pure functions. As for the FFI and concurrency, I agree with you, but these are also the two extensions of which it is very clear how to do them by now and it is more a matter of getting all implementations in sync. Languages like Perl and Python don't have this problem. There is just one implementation and that defines the language. Otherwise, I can assure you, Haskell has a rather complete feature set and is ready for serious use. Cheers, Manuel [1] I know that this is not entirely true for Python, but the net effect is the same. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Wolfgang Jeltsch [EMAIL PROTECTED] wrote, That's why I think GTK+ should be used mainly to develop applications which are intended to run under GNOME and preferably not to do cross-plattform GUI programming. I think the best solution for the latter thing is to use a library which has multiple implementations based on different native libraries like Win32, GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this kind of library. wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages of GTK+ is that it was written with bindings for other languages in mind. Therefore, it is probably the toolkit with the most language bindings. One alternative would be to standardise on a kind of subset of the GTK+ API and then somebody with a lot of spare time could implement that on top of the Win32 API natively - in the meantime, the original GTK+ libraries would at least provide some form of implementation under Win32. (You should bear in mind that anything that doesn't build on existing infrastructure involves a lot of coding and I haven't seen many volunteers stepping forward yet.) Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: (snip) wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages (snip) Of course, wxPython also exists - I assume that the emphasis on object orientation is the problem? -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Out of curiosity, how does GTK+ compare with Fruit? It seems like it would make sense for the standard Haskell GUI also to be functional. -Alex- PS I don't do GUI stuff so I don't really know much. I did read the Fruit paper and it looked interesting. On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: Wolfgang Jeltsch [EMAIL PROTECTED] wrote, That's why I think GTK+ should be used mainly to develop applications which are intended to run under GNOME and preferably not to do cross-plattform GUI programming. I think the best solution for the latter thing is to use a library which has multiple implementations based on different native libraries like Win32, GTK+, Qt. wxWindows (http://www.wxwindows.org/) is an example for this kind of library. wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages of GTK+ is that it was written with bindings for other languages in mind. Therefore, it is probably the toolkit with the most language bindings. One alternative would be to standardise on a kind of subset of the GTK+ API and then somebody with a lot of spare time could implement that on top of the Win32 API natively - in the meantime, the original GTK+ libraries would at least provide some form of implementation under Win32. (You should bear in mind that anything that doesn't build on existing infrastructure involves a lot of coding and I haven't seen many volunteers stepping forward yet.) Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ S. Alexander Jacobson Shop.Com 1-646-638-2300 voiceThe Easiest Way To Shop (sm) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
