[GHC] #1084: Improve coalescing of dynamic breakpoints in the ghci debugger
#1084: Improve coalescing of dynamic breakpoints in the ghci debugger +--- Reporter: mnislaih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: normal |Keywords: Difficulty: Easy (1 hr) |Testcase: Architecture: Unknown | Os: Unknown +--- (or disable it altogether) Right now coalescing of breakpoints works at instrumentation time by: 1. Not inserting a breakpoint if there are no local bindings in the site 1. Removing adjacent breakpoints, i.e. removing one of them (not implemented yet) 1. adhoc case: if we are about to insert a breakpoint but the subexpresion is a HsLet, then don't. Proposal is to disable cases 1 and 3 and implement case 2 using rewriting rules. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1084 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1083: ghci says a module wasn't loaded under debugging mode when in fact it was
#1083: ghci says a module wasn't loaded under debugging mode when in fact it was --+- Reporter: mnislaih | Owner: mnislaih Type: bug | Status: new Priority: normal| Milestone: 6.8 Component: GHCi |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Easy (1 hr) Testcase:| Architecture: Unknown Os: Unknown | --+- Comment (by mnislaih): Observe that there are no breakpoints because of coalescing, as explained in ticket #1084. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1083 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS
#1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS -+-- Reporter: mnislaih | Owner: Type: task | Status: new Priority: normal| Milestone: 6.8 Component: Runtime System| Version: 6.6 Severity: normal|Keywords: Difficulty: Moderate (1 day) |Testcase: Architecture: Unknown | Os: Unknown -+-- Currently, from the closure we get its info table address, and since those are static for Constr closures, we use a hashtable (defined in Linker.c) to relate symbol names obtained when linking and the addresses. The proposal is to extend the info table with a field for the symbol name, making this process much more straightforward. The trade-off is that this will augment the size of binaries a bit, so we could make this 'labelling' of info tables optional via a flag. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1085 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS
#1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS +--- Reporter: mnislaih| Owner: Type: task| Status: new Priority: normal | Milestone: 6.8 Component: Runtime System |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | +--- Comment (by mnislaih): Does this explanation make sense? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1085 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS
#1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS +--- Reporter: mnislaih| Owner: Type: task| Status: new Priority: normal | Milestone: 6.8 Component: Runtime System |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | +--- Comment (by mnislaih): I wonder if then there would be special versions of the libs compiled under this 'debugging' flag, as currently happens for the profiling libs. Would the increment in size be big enough to justify this inconvenience? Most probably not. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1085 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1067: assertion failure in Schedule.c
#1067: assertion failure in Schedule.c +--- Reporter: ms43| Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | +--- Changes (by simonmar): * owner: = simonmar Comment: I'll take it. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1067 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1047: Increase gurantees of semantics of block/unblock/throwTo
#1047: Increase gurantees of semantics of block/unblock/throwTo +--- Reporter: ChrisKuklewicz | Owner: simonmar Type: task| Status: new Priority: normal | Milestone: Component: Runtime System |Version: 6.6 Severity: normal | Resolution: Keywords: concurrency | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by simonmar): * owner: = simonmar Comment: As far as I can tell, the semantics in the paper don't have the guarantee that you're looking for either: there's no requirement that the Receive rule in the semantics '''must''' fire if an exception is waiting. Also, the paper is based on an asynchronous version of `throwTo`, so things are quite different in various ways. I think you're reading a different version of the paper though, in the version on my web page here [http://www.haskell.org/~simonmar/papers/async.pdf], section 7.2 is called Symmetric process abstractions and doens't seem to talk about this. Still, I'm going to make the improvement suggested, since it's a good idea and easy to do (I just noticed how easy). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1047 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
IOExts problem
IOExts seems to be unavailable on my system, whereas I'm guessing it should be since the file /usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi exists...(wrong guess?) Within ghci I get Prelude :m IOExts Could not find module `IOExts': it is not a module in the current program, or in any known package. Prelude I am trying to build the latest version of haskore with ghc 6.4.1 and have edited the Makefile to put in references to the location of IOExts.hi: HC_OPTS = -cpp -i/usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi IOExtensions.o : /usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi Now make gives the error: [EMAIL PROTECTED]:~/haskore/Src$ make ghc -c IOExtensions.hs -cpp -i/usr/lib/ghc-6.4.1/hslibs-imports/lang/IOExts.hi IOExtensions.hs:20:0: Failed to load interface for `IOExts': Could not find module `IOExts': use -v to see a list of the files searched for make: *** [IOExtensions.o] Error 1 Is IOExts installed as standard with GHC or do I have to tell it the path to the hi file somehow? -- View this message in context: http://www.nabble.com/IOExts-problem-tf2919193.html#a8158283 Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: importing in place and packages
Ashley Yakeley wrote: Simon Peyton-Jones wrote: Anyway, the solution for you is to install it. I can't install it, the package isn't finished being built at that point. Or perhaps I could find a way of installing the partial package to the user database. I build part of package javavm. Then I use that to build ShowClasses. Then I run ShowClasses to generate more source files. Then I use those to build the rest of javavm. Cabal provides 'setup register --inplace' for exactly this purpose. We don't currently allow the use of completely local package databases - you must use the global or user database - but the package can be used without the files actually being installed. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: importing in place and packages
Simon Peyton-Jones wrote: The main program must be in package 'main', which is why compiling ShowClasses with -package-name javavm doesn't work. I'll modify the documentation to say this more clearly When you say import JVMBoot, and your javavm package is not installed, GHC thinks you mean JVMBoot from package main. The only way at the moment you can make GHC realise you mean JVMBoot from package javavm is to install it. You may say that's a bit silly -- after all, GHC can simply look at the interface file, and that is what you want here. I'll talk to Simon about whether that could be possible, but I'm guessing there's a good reason why not. It would be a bit strange to allow this. The compiler knows nothing about the javavm package at this stage: it isn't installed. So if we came across a module that we were expecting to be part of the main package and it turns out to belong to another, non-existant, package, we'd probably have to invent a package. I just don't have a clear idea for how this would work; my gut feeling is that we shouldn't pursue it, since the right way is to register the package with GHC first (temporarily, to a local database, perhaps). Cheers, Simon Anyway, the solution for you is to install it. Cabal? There must be a well-understood process but I'm not the one to ask. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow- | [EMAIL PROTECTED] On Behalf Of Ashley Yakeley | Sent: 22 December 2006 10:44 | To: glasgow-haskell-users@haskell.org | Subject: importing in place and packages | | I'm compiling the files for package javavm with GHC 6.6 (using | -package-name javavm). As part of the compilation process, I need a | runnable program that uses the modules I've compiled in place: | |import JVMBoot | | But I get this error when compiling my Main module (ShowClasses.hs): | | ShowClasses.hs:23:1: | Bad interface file: JVMBoot.hi | Something is amiss; requested module main:JVMBoot differs | from | name found in the interface file javavm:JVMBoot | | Really I want to import javavm:JVMBoot, not main:JVMBoot. I tried this, | but GHC doesn't like it (because it's not Haskell): | | import javavm:JVMBoot | | I tried compiling ShowClasses.hs with -package-name javavm. This let | me compile, but then I get this on link: | | /usr/bin/ld: Undefined symbols: | _ZCMain_main_closure | ___stginit_ZCMain | collect2: ld returned 1 exit status | | I tried adding a -main-is in the compile step, but this didn't help. | | Is there any way to create a main function that calls files imported | in | place that are in some package? I have the same issue when writing | tests for my time package. | | -- | Ashley Yakeley | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: LLVM back end
Simon Peyton-Jones wrote: How about * concurrency (the ability to have zillions of little stacks, with stack overflow checks and growing the stck on overflow)? * exception handling (the ability to crawl over the stack looking for exception catch frames)? * garbage collection (the ability to find pointers in the stack) I'd imagined that we'd use LLVM as a low-level code generator, doing our own stack management and using the existing GHC runtime support for all of these things. Michael seems to be saying something different though... but it seems to me that anything other than using LLVM as a code generator only is a *lot* of work, and in direct competition with C--, so not an easy sell. Cheers, Simon Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow- | [EMAIL PROTECTED] On Behalf Of Wolfgang Thaller | Sent: 20 December 2006 23:55 | To: [EMAIL PROTECTED] | Cc: GHC Users; Simon Marlow | Subject: Re: LLVM back end | | On 20-Dec-06, at 10:10 AM, Michael T. Richter wrote: | | Well, I'm almost entirely ignorant of LLVM and of Haskell -- | especially the internals of both. That makes me ideally suited for | this project since I'm not aware that it's impossible. | | I'm afraid LLVM currently lacks some features that are required for | efficient GHC code generation, specifically: | | a) Global Register Variables | b) The ability to put data next to code | c) (maybe, I'm not sure) Tailcalls | | ad a) | We need to keep some things in global registers for speed reasons | (depending on the number of available registers); among other things, | the haskell stack pointer and the heap pointer. Using regular global | variables instead would be a lot slower. | | ad b) | With (almost) every chunk of code, we want to associate a smal chunk | of data (the info table) which contains information used by the | garbage collector and other parts of the run time system. We want to | use only one pointer to point to both of those things, and we don't | want to waste time with any additional indirections, so we make the | pointer point between the data chunk and the code chunk. | | ad c) | While they are supported in theory, I couldn't get LLVM to generate | any tailcalls. Maybe I've done something wrong, maybe they're not | really implemented yet. | | So I guess step one would be to start negotiating about those things | with the LLVM people. | | Cheers, | | Wolfgang | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci attempts to link entire package
Bayley, Alistair wrote: Related to some of the problems Takusen users have had, I have a question about ghci's linker/loader: why does it appear to try to link an entire package archive, rather than just the modules that are used? This is in contrast to the GNU ld program which the compiler uses, which only tries to link modules which are actually used. Is this a feature or a bug? Neither really, just a consequence of the design. GHCi's linker only knows how to link object files, and when it links a package it actually linked a specially generated single .o file constructed by linking together all the object files in the package. There has been talk of adding support to link .a files which would simplify package management, but I guess it might make linking slower. If there's a use case that requires partial linking of a package, then we could consider the lack of partial linking a bug - can you describe why you need it? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC on the IBM Cell
Bulat Ziganshin wrote: Hello Jaap, Friday, December 22, 2006, 9:45:39 PM, you wrote: * Are the .hc files cross-platform? just want to mention that jhc compiler generates pure ansi c code. may be it's better suit your needs? It's all very well generating pure ANSI C code - GHC can do that too (we call it unregisterised, and it's how you port GHC to a new platform), but if the original Haskell code you compiled contained any #ifdefs then you still don't have platform-independent intermediate code. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC on the IBM Cell
Suter, Jaap wrote: I'm trying to get GHC to run on the Cell processor. Cool :) That is, just on the PPU PowerPC side. The SPUs will continue to run C programs, managed and driven by a Haskell manager on the PPU. I'm mostly interested in GHC for its concurrency features (STM in particular). Not knowing much about GHC yet, here's what I would expect in the ideal situation. 1. The RTS is largely cross-platform already. I might have to make some minor tweaks, but for the most part it should compile out of the box. 2. I setup GHC to compile my .hs files to .hc files; the C intermediates. 3. These are hopefully cross-platform as well, instead of being tied to my GHC distribution's platform. 4. I compile the RTS and .hc files and link them all together. 5. Done. This raises a few questions... * Are the .hc files cross-platform? Or does a GHC compiled for PowerPC generate different intermediate C code than a GHC compiled for X86? Ideally the platform specifics are hidden inside the RTS and two different GHC builds will output identical .hc files. The .hc files are not cross-platform, you need to generate them for your target platform using a working GHC on another machine first. The porting instructions describe how to do this. * How cross-platform is the RTS? As long as your platform is POSIX compatible, you're probably in reasonable shape. If you're not using gcc, then things might get more difficult, but I believe the RTS has compiled with non-gcc compilers in the past so it shouldn't be too hard. I downloaded the source tarball and dropped it on top of my XP installation of GHC. I then generated a simple Hello World haskell .hc intermediate and tried to compile that and the RTS. Unfortunately I ran into problems because things like HAVE_WINDOWS_H and HAVE_SIGNALS_H were defined. I started manually editing the code to tweak the configuration but ran into more problems (signal_set_t doesn't exist on my platform, but can't be conditionally compiled. static arrays of unknown size (StgWordArray) make my compiler unhappy. Etcetera). At this point I figured I would stop and ask for some help first, before I invest a lot of energy in a dead-end path. There must be a simpler way. I read parts of the porting GHC to your platform documentation, but I believe it addresses a different problem. I don't want to recompile GHC itself. I want to run my existing GHC on my XP machine and output intermediate .hc files. I then feed these plus a cross-platform RTS to my Cell compiler to get a workable program. Ok. So what you want to do is similar to what the porting instructions describe, in that you want to generate a cross-compiler on your host system that can generate .hc files for your target, but you want to continue using this cross-compiler to compile target binaries rather than use it to compile a native GHC. It seems plausible, though it's not something we typically do, so it might be a bit of an adventure. For example, you'll have to invoke the C compiler and linker by hand on the target machine, and those command lines can be pretty long and complicated. First thing to do is follow the porting instructions up until the point wher you have a compiled set of libraries and RTS on the target machine. You can omit compiling GHC itself. From that point, you ought to be able to take .hc files for your program to the target machine, compile them against the .h files in your GHC build, and link them against the libraries and RTS. I suppose I need to regenerate the ghautoconf for my particular platform (rather than hand-tweaking the existing one). Unfortunately I'm not much of a Linux or Gnu toolset expert. I see a bunch of config.* and configure.* file in the root folder. I suppose I should read up on those a little more. I'll do my homework first. In the meanwhile, if anybody has any quick and simple advice to make this process smoother that would be greatly appreciated. Kind regards, Jaap Suter - http://www.jaapsuter.com Some more random questions... * ghautoconf.h and HsBaseConfig.h have similar #defines (like HAVE_WINDOWS_H). Is there a reason for that? I always need to update them in two places now. * After downloading the source tarball and unzipping over my XP GHC installation, I got both an 'include' and an 'includes' directory. This is somewhat confusing. I wouldn't recommend unzipping the source tree over the installed tree, they aren't designed to coexist. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghci attempts to link entire package
From: Simon Marlow [mailto:[EMAIL PROTECTED] Is this a feature or a bug? Neither really, just a consequence of the design. Well, that would make it a feature, then ;-) There has been talk of adding support to link .a files which would simplify package management, but I guess it might make linking slower. If there's a use case that requires partial linking of a package, then we could consider the lack of partial linking a bug - can you describe why you need it? With Takusen, all modules, including the DBMS-specific modules, are compiled into a single library. At present we have 3 DBMS's: Sqlite, Oracle, and PostgreSQL. For example, suppose you had just the Oracle DBMS client libraries installed, and you write a program which only uses the Oracle modules from Takusen. When you link, the gnu ld program attempts to resolve the symbols in only the modules that you've used. You don't need to have PostgreSQL or Sqlite installed, and the linker ignores these modules from the package archive. This is quite nice, because we can distribute the entire library as a single package, and it will work even if the user does not have all of the DBMS client libraries installed. In contrast, when ghci (or runhaskell) attempts to link it tries to resolve all of the symbols in the PostgreSQL and Sqlite modules, and fails because you don't have them installed. The result is that a user of Takusen can't easily use the library with ghci/runhaskell out of the box, unless they have the full set of DBMS client libraries installed. There are a couple of workarounds, but they're both a bit fiddly, so it'd be nicer (from my POV) if the ghci linker behaved like gnu ld. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghci attempts to link entire package
From: Bayley, Alistair The result is that a user of Takusen can't easily use the library with ghci/runhaskell out of the box, unless they have the full set of DBMS client libraries installed. I forgot to mention that there's another difference between ghci and gnu ld: if the external library is called libxx.dll, rather than xx.dll (which is the convention on Windows, it seems), then gnu ld is still able to locate link to it when you say -lxx, but ghci fails to find it. You have to say -llibxx to ghci for it to work. This also makes distributing the Takusen library as a single package awkward, because 1. the cabal installation detects the presence of the library and configures the package with the -lxx option 2. ghc --make passes -lxx to gnu ld, which is nice... 3. ... but ghci tries to use -lxx also, and fails. So PostgreSQL users can't use ghci with the installed package unless they're willing to re-configure/build/install and change the -l option to from -lpq to -llibpq, which breaks normal compilation with ghc, because gnu ld can't find the library when you say -llibpq. (This affects the PostgreSQL client library on Windows, which is called libpq.dll.) Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unpacking polymorphic fields
Thank you, that helped a lot. Takano Akio ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] FW: WoLLIC'2007 - 2nd CFP
[ posting on behalf of Ruy de Queiroz [EMAIL PROTECTED] ] [** sincere apologies for duplicates **] Call for Papers 14th Workshop on Logic, Language, Information and Computation (WoLLIC'2007) Rio de Janeiro, Brazil July 2-5, 2007 WoLLIC is an annual international forum on inter-disciplinary research involving formal logic, computing and programming theory, and natural language and reasoning. Each meeting includes invited talks and tutorials as well as contributed papers. The Fourteenth WoLLIC will be held in Rio de Janeiro, Brazil, from July 2 to July 5, 2007, and sponsored by the Association for Symbolic Logic (ASL), the Interest Group in Pure and Applied Logics (IGPL), the European Association for Logic, Language and Information (FoLLI), the European Association for Theoretical Computer Science (EATCS), the Sociedade Brasileira de Computacao (SBC), and the Sociedade Brasileira de Logica (SBL). PAPER SUBMISSION Contributions are invited on all pertinent subjects, with particular interest in cross-disciplinary topics. Typical but not exclusive areas of interest are: foundations of computing and programming; novel computation models and paradigms; broad notions of proof and belief; formal methods in software and hardware development; logical approach to natural language and reasoning; logics of programs, actions and resources; foundational aspects of information organization, search, flow, sharing, and protection. Proposed contributions should be in English, and consist of a scholarly exposition accessible to the non-specialist, including motivation, background, and comparison with related works. They must not exceed 10 pages (in font 10 or higher), with up to 5 additional pages for references and technical appendices. The paper's main results must not be published or submitted for publication in refereed venues, including journals and other scientific meetings. It is expected that each accepted paper be presented at the meeting by one of its authors. Papers must be submitted electronically at www.cin.ufpe.br/~wollic/wollic2007/instructions.html A title and single-paragraph abstract should be submitted by February 23, and the full paper by March 2 (firm date). Notifications are expected by April 13, and final papers for the proceedings will be due by April 27 (firm date). PROCEEDINGS Proceedings, including both invited and contributed papers, will be published in advance of the meeting. Publication venue: Springer's Lecture Notes in Computer Science. INVITED SPEAKERS: Veronique Cortier (LORIA Nancy) Martin Escardo (Birmingham) Georg Gottlob (Oxford) Achim Jung (Birmingham) Louis Kauffman (U Illinois Chicago) Sam Lomonaco (U Maryland Baltimore) Paulo Oliva (London/QM) John Reif (Duke) Yde Venema (Amsterdam) STUDENT GRANTS ASL sponsorship of WoLLIC'2007 will permit ASL student members to apply for a modest travel grant (deadline: April 1, 2007). See www.aslonline.org/studenttravelawards.html for details. IMPORTANT DATES February 23, 2007: Paper title and abstract deadline March 2, 2007: Full paper deadline (firm) April 12, 2007: Author notification April 26, 2007: Final version deadline (firm) PROGRAM COMMITTEE Samson Abramsky (U Oxford) Michael Benedikt (Bell Labs) Lars Birkedal (ITU Copenhagen) Andreas Blass (U Michigan) Thierry Coquand (Chalmers U, Goteborg) Jan van Eijck (CWI, Amsterdam) Marcelo Finger (U Sao Paulo) Rob Goldblatt (Victoria U, Wellington) Yuri Gurevich (Microsoft Redmond) Hermann Haeusler (PUC Rio) Masami Hagiya (Tokyo U) Joseph Halpern (Cornell U) John Harrison (Intel UK) Wilfrid Hodges (U London/QM) Phokion Kolaitis (IBM Almaden Research Center) Marta Kwiatkowska (U Birmingham) Daniel Leivant (Indiana U) (Chair) Maurizio Lenzerini (U Rome) Jean-Yves Marion (LORIA Nancy) Dale Miller (Polytechnique Paris) John Mitchell (Stanford U) Lawrence Moss (Indiana U) Peter O'Hearn (U London/QM) Prakash Panangaden (McGill, Montreal) Christine Paulin-Mohring (Paris-Sud, Orsay) Alexander Razborov (Steklov, Moscow) Helmut Schwichtenberg (Munich U) Jouko Vaananen (U Helsinki) ORGANISING COMMITTEE Marcelo da Silva Correa (U Fed Fluminense) Renata P. de Freitas (U Fed Fluminense) Ana Teresa Martins (U Fed Ceara') Anjolina de Oliveira (U Fed Pernambuco) Ruy de Queiroz (U Fed Pernambuco, co-chair) Petrucio Viana (U Fed Fluminense, co-chair) WEB PAGE www.cin.ufpe.br/~wollic/wollic2007 --- ___ Haskell mailing list Haskell@haskell.org
[Haskell] Re: state of HaXml?
Norman Ramsey wrote: The simplest thing is to use readFile (from the Prelude) instead of using handles. readFile will take care of everything for you when the time is right. Thanks---I'll try it. Somehow my hoogle query missed readFile... undoubtedly because I asked for 'String - IO String' instead of 'FilePath - IO String'. Dunno if this is a bug or a feature, since as far as the compiler is concerned, FilePath and String are the same type... There seems to be a misunderstanding here: readFile in itself is not the solution. readFile is defined thus: readFile name = openFile name ReadMode = hGetContents and the original code was this: load fn = do handle - IO.openFile fn IO.ReadMode contents - IO.hGetContents handle IO.hClose handle return $ XP.xmlParse fn contents Sure, you can replace the openFile/hGetContents pair by readFile, but the real problem is the presence of the hClose. Removing that will solve your problem (but note that you now have no control over when the file is actually closed). Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: state of HaXml?
There seems to be a misunderstanding here: readFile in itself is not the solution. readFile is defined thus: readFile name= openFile name ReadMode = hGetContents and the original code was this: load fn = do handle - IO.openFile fn IO.ReadMode contents - IO.hGetContents handle IO.hClose handle return $ XP.xmlParse fn contents Sure, you can replace the openFile/hGetContents pair by readFile, but the real problem is the presence of the hClose. Removing that will solve your problem (but note that you now have no control over when the file is actually closed). Can I just leave it hanging and rely on the garbage collector to close it in the fullness of time? Because of laziness, I believe there's no point in my writing the following: load fn = do handle - IO.openFile fn IO.ReadMode contents - IO.hGetContents handle let xml = XP.xmlParse fn contents IO.hClose handle return xml Is that correct? Norman ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: IntelliJIDEA for Haskell
If you prefer IntelliJIDEA for your development, you might be interested in Haskell syntax highlighting. IntellijIDEA for Haskell is released under a BSD licence and can be found here: http://www.workingmouse.com/research/IntelliJIdea%2DHaskell/ -- Tony Morris Workingmouse Research signature.asc Description: OpenPGP digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Composing functions with runST
On 1/3/07, Seth Gordon [EMAIL PROTECTED] wrote: David House wrote: So I can't just tell someone who's just starting to learn Haskell that f $ g y is equivalent to f (g y); I have to say those two are *almost always* equivalent, but if you use $ and the compiler complains about not being able to match the expected and the inferred type and a type signature in the error message has the word 'forall', try rewriting that expression without the $ and see if it compiles. Eeeww. Why would someone just starting to learn Haskell be using ST? The canonical tutorial structure is to start with the pure stuff and only introduce the (more complicated!) impure stuff (ST, IORefs, etc.) in an 'advanced techniques' or similar section. I (and one other person on this list) ran into this issue when I was trying to use takusen to make Haskell talk to a RDBMS. You obviously need to learn advanced techniques to *implement* such a thing, but you shouldn't need advanced knowledge to *use a library* that happens to use higher-rank polymorphic types in its API. That other person was me, and I agree entirely. I have a little sample project, using databases and concurrency, which I wanted to rewrite in Haskell, as a learning exercise. I hit exactly this issue when simply trying out some sample code, and my reaction was very much one of irritation, frustration and confusion. One of the nice things about Haskell, coming to it from an imperative POV, is that monads can be thought of a little like first-class composable statement blocks. When I understood that, I had a real hey, that's neat! reaction. One of the nasty things about Haskell (at my level of experience) is that your nice helpful intuitions about monads can break down into real confusion when you hit complex monads, monad transformers and the like - *and you hit them quite early in the APIs of some libraries*! It's not a big deal, but it's a bit offputting for a newcomer. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Composing functions with runST
On 1/3/07, Neil Mitchell [EMAIL PROTECTED] wrote: As for beginner issues with rank-2 types, I've been learning Haskell for years now, and have never felt the need for a rank-2 type. If the interface for some feature requires rank-2 types I'd call that an abstraction leak in most cases. It certainly means that you can't properly Hoogle for it, can't compile it with Yhc, can't do full type inference etc. That may well be true. Something I forgot to mention in my previous posting was that I'm not 100% convinced that the issue I hit with Takusen isn't a problem with the library - I find it very hard to read or understand some parts of the library documentation, basically because the types seem so complex. My intuition says that reading a database is logically similar to reading a file, so types like doQuery :: (Statement stmt sess q, QueryIteratee (DBM mark sess) q i seed b, IQuery q sess b) = stmt - i - seed - DBM mark sess seed look pretty baffling to me - and don't match my intuition that main = do withSession (connect user password server) $ do -- simple query, returning reversed list of rows. r - doQuery (sql select a, b, c from x) query1Iteratee [] liftIO $ putStrLn $ show r otherActions session is basically I/O. (Oh, by the way - that $ on the withSession line is the one that caused the error which started this thread...) Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Composing functions with runST
Seth Gordon wrote: From a friendliness-to-newbies point of view, these error messages are a tremendous wart... Eeeww. Neil Mitchell wrote: If the interface for some feature requires rank-2 types I'd call that an abstraction leak in most cases. As the original poster of this thread, the one who was bitten this time, let me point out that the use of rank-2 polymorphism here is actually really nice. It provides a strong safety guarantee for the ST monad at *compile time*. But the protection is a bit heavy-handed, so there are some painful side effects that need to be addressed. One is the confusion caused by the strange semantics to those not familiar with the theory. That should be fixed by simple, prominant, task-oriented documentation. (You must always provide runST with an argument. So, for example, you cannot write runST $ or runST ..) And yes, perhaps the error messages in GHC could be improved for newbies, but that was never intended to be the strong point of GHC. I think Hugs is fine here. The other is awkwardness in extending the capabilites of ST. For that, I would propose that the function unsafeRunST be added to the library. Of course, if there is some way to improve both of these situations by compilers relaxing the restrictions on rank-2 types somewhat, that would be great. But that is probably for the future. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Composing functions with runST
Paul Moore wrote: ...your nice helpful intuitions about monads can break down into real confusion when you hit complex monads, monad transformers and the like - *and you hit them quite early in the APIs of some libraries*! I don't think that is a problem with the design of the libraries. It is a problem with the documentation. Almost all library documentation could be written so that any user could easily use the library in a simple, practical, straightforward way. I am not saying that it would be easy, but it could be done. Nowadays, that type of documentation is taken for granted for every popular programming language. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Composing functions with runST
Neil Mitchell wrote: As for beginner issues with rank-2 types, I've been learning Haskell for years now, and have never felt the need for a rank-2 type. If the interface for some feature requires rank-2 types I'd call that an abstraction leak in most cases. It certainly means that you can't properly Hoogle for it, can't compile it with Yhc, can't do full type inference etc. I think that the term abstraction leak is too harsh. In some sense, you may as well call strong typing an abstraction leak because one can do the stuff as well in a dynamic typed language and adding strong typing means that you can't compile it with current compilers, you need to implement type checking/inference etc. Of course, this analogy has flaws as higher rank types go to the edge of computability whereas strong typing can be implemented. Concerning interfaces, higher rank types offer crucial static checking that cannot be achieved without them. The prominent example is ST. The next example is the parsing library frisby. In both cases, it would be easy to wrack havoc in case the interface would not use higher rank types. The same analogy as above applies: one uses strong typing because one does not want to wreak havoc. I would not call this an abstraction leak. Concerning implementation, higher rank types are even more widespread: almost everything involving continuations needs them: ReadP, Exceptions (as opposed to Either), deforestation etc. In fact, it is quite possible to throw away algebraic data types altogether and build everything you need with higher rank types. A prominent example is [a] ~= (forall b . (a - b - b) - b - b) ~= (forall b . (Maybe (a,b) - b) - b) The denotational semantics do not change, but the time and space behavior is much different. Perhaps the above remarks misinterpret your statement and you meant abstraction leak in the sense that, because higher rank types are available, the interface author used them without thinking whether the same effect can be achieved in ordinary Haskell. Alas, such problems are not tied to higher rank types: proper interface design is an art and does not come for free, not to mention interface documentation[1]. One could easily berserk: why does this library use String and doesn't abstract it with a type class? Why does that interface only provide IO, why isn't this available as a library of pure functions? What do these obviously crappy semantics mean? In this case, higher rank types are a symptom, not the problem. If one wants to cure the problem by disallowing the symptom, then I suggest to also erase the symptom IO. Thoroughly. Of course, the drawbacks of higher rank types you mentioned remain. In the case of hoogleability, I'm confident that it is possible to implement them, it's only that someone has to think hard about it. Implementing higher rank types in YHC is even harder but not impossible. Sure, type inference is the most difficult thing, and one has to accept glitches and drawbacks to make it work. Compared to these difficulties, I think that the remark So I can't just tell someone who's just starting to learn Haskell that f $ g y is equivalent to f (g y); I have to say those two are *almost always* equivalent, but if you use $ and the compiler complains about not being able to match the expected and the inferred type and a type signature in the error message has the word 'forall', try rewriting that expression without the $ and see if it compiles. Eeeww. posted in this tread is too harsh. That's life, every language has its flaws and glitches: parts of the layout rule, pattern guards, I want a better records system, views, generic programming, etc. But, when code has to be finished, those glitches or annoying things are best countered with a shrug: they are not life-threatening. A programming language with nonexistent type system and ugly semantics is. And much to our joy, Haskell is far from this. In that sense, dear reader of this post, just rewrite that expression without $ and see if it compiles. The complier authors don't want to annoy you, it's just that the exact reasons why this cannot yet be put to work are damn hard. You are encouraged to learn about System F to get a grasp of what is going on, but spending this one $ will be much cheaper. Regards, apfelmus [1] Concerning library documentation, I think that literate Haskell sources have the drawback that they are either tied to TeX (\begin{code}..\end{code}) or that every line has to start with a ''. I'd suggest to add a code../code or something else. The point is that while (La)TeX can be cranked up to a publishing system, it is not suited for many tasks such as media-dependent processing. TeX is a macro language, not a structured document type. And for the strongly typed Haskell programmer used to referential transparency, macros are a nightmare. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Composing functions with runST
I wrote: Combining ST and MTL can be messy, even in this simple case. You will probably write something with a type like RandomGen g = [a] - g - ST s ([a], g) Udo Stenzel wrote: But why would you even want to do this? It's ugly and cumbersome. Yes indeed. You'd plug a runST in there and get shuffle :: RandomGen g = [a] - g - ([a], g) Yes. In fact, that is what I did in practice. As you say, the overall effect is ugly and cumbersome. And this is with only the simplest of stateful calculations. I shudder to think about what happens when things are more complex. That is why I am thinking that - Wouldn't it be nice if instead you could just write: shuffle :: (RandomGen g, MonadState g m) = [a] - m [a] shuffle = stToState . shuffleST and then just use that directly inside a calculation that is otherwise purely non-ST? It seems, what you really want is shuffleST :: RandomGen g = [a] - StateT g ST [a] Actually, I tried that. It didn't help - it was just one more layer I had to peel away to get at the ST inside. There seems to be no way to avoid the fact that you think about state in two very different ways in these two monads. Every program is written in either one style or the other. Occasionally, you require an isolated use of the opposite style, and I am looking for ways of simplifying the resulting mess. StateT st ST and MonadST look like ways of combining the two, but in practice I find that they just seem to get in the way. I am starting to be convinced that the only way to write the function I want is by using unsafeRunST. Or type it as stToState :: MonadState st m = (st - ST s (a, st)) - m a and then write in the documentation that the user is require to write do r - newSTRef x ... y - readSTRef r return (z, y) by hand every time. Yuck. Am I missing something? -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Composing functions with runST
Yitzchak Gale wrote: Well, it turns out that using Data.Sequence or Data.IntMap to shuffle a list becomes prohibitive if you might have more than about 10^5 elements in your list. So in that case you will need to use a mutable array, and you now need ST. [..] Wouldn't it be nice if instead you could just write: shuffle :: (RandomGen g, MonadState g m) = [a] - m [a] shuffle = stToState . shuffleST and then just use that directly inside a calculation that is otherwise purely non-ST? It seems, what you really want is shuffleST :: RandomGen g = [a] - StateT g ST [a] Actually, I tried that. It didn't help - it was just one more layer I had to peel away to get at the ST inside. There seems to be no way to avoid the fact that you think about state in two very different ways in these two monads. Every program is written in either one style or the other. Occasionally, you require an isolated use of the opposite style, and I am looking for ways of simplifying the resulting mess. StateT st ST and MonadST look like ways of combining the two, but in practice I find that they just seem to get in the way. I don't get what exactly you want. If you want to carry your state named MyState (f.i. type MyState = [Cards,Players]) around in a monad, you use Control.Monad.State MyState. If (and only if) you have an algorithm (like depth-first search) that carries an array as state around (nodes already visited) and you know that this array is used in a single threaded fashion, it might be worth to update the array in place. For that, you use Control.Monad.ST and Data.Array.ST and you can be confident that the state carrying has been strictness analyzed and fine tuned to match the machine. In short, you get updates in place without selling your soul to IO, runST is your protection from evil and will keep you pure. ST does not really have more uses than this one (besides being the foundation for IO). For more info on ST, see http://research.microsoft.com/Users/simonpj/Papers/state-lasc.ps.gz Note that the you can now achieve the array thing as well with Data.Array.Diff. This is a purely functional interface to an array type that uses destructible updates internally and keeps a history to become persistent. However, I doubt that an array makes a difference over Data.IntMap for all but the most special cases. I am starting to be convinced that the only way to write the function I want is by using unsafeRunST. Or type it as stToState :: MonadState st m = (st - ST s (a, st)) - m a and then write in the documentation that the user is require to write do r - newSTRef x ... y - readSTRef r return (z, y) by hand every time. Yuck. If the programmer needs to adhere to a policy, the type system may well enforce it for him. No unsafeRunST. It's far better to struggle with the safety device than to discover the hard way that running without it will directly lead into the debugging hell. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Composing functions with runST
Hello Yitzchak, Thursday, January 4, 2007, 12:25:41 PM, you wrote: The other is awkwardness in extending the capabilites of ST. For that, I would propose that the function unsafeRunST be added to the library. this function exists, but named unsafeIOtoST. IO and ST is exactly the same things, the only difference that foreign imports may be marked as IO operations but both ST ones. as a result, ST is restricted to a few standard operations that guarantees to bo be mutually transparent for consumers of runST. when one goes to extend ST functionality, unsafeIOtoST is used. for 3xample, in Hugs it is used to convert peek/poke IO operations into STUArray implementation. except for compile-time type sugar, there is no difference between those two type constructors. unsafeIOtoST is like liftIO: unsafeIOtoST :: IO a - ST s a -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Composing functions with runST
I wrote: Am I missing something? Yes! In reality, I do not need unsafeSTRef for this at all, using a type suggested earlier by Udo: stToState :: MonadState st m = (forall s. STRef s st - ST s a) - m a stToState f = do s - get let (y, s') = runST (stm f s) put s' return y where stm f s = do r - newSTRef s y - f r s' - readSTRef r return (y, s') This works! Thanks, Udo! -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Composing functions with runST
Hi Bulat, I wrote: One is the confusion caused by the strange semantics to those not familiar with the theory... Like me, of course. The other is awkwardness in extending the capabilites of ST. For that, I would propose that the function unsafeRunST be added to the library. Bulat Ziganshin wrote: this function exists, but named unsafeIOtoST. That wasn't what I had in mind, because it forces the thread parameter to take the specific value RealWorld. But I am not sure anymore that it is needed. It turned out that my case was just another instance of the first kind of awkwardness. So I no longer have any evidence that the second kind of awkwardness exists. So I withdraw my proposal. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arrays performance
Quoting Paolo Veronelli [EMAIL PROTECTED]: I paste new version in case you care give me some moe suggestion. import Data.Maybe import Data.List import Data.Array.Diff import System.Environment import Control.Arrow import Control.Monad import Random inc l i = l // [(i,l!i + 1)] switch l i = l // [(i,not (l!i))] constArray n v = listArray (0,n-1) (repeat v) data Folding = Folding {clusters :: [(Int,Int)], remi :: Int, colsCount :: DiffArray Int Int ,rowsCheck :: DiffArray Int Bool} result (Folding cs _ _ _) = cs rcluster ls d s = let devil s@(Folding cs r hs fs) l@(row,col) = let ns = s { clusters = (l:cs), rowsCheck = switch fs row, colsCount = inc hs col } rowtest | c d = ns | (c == d) (r 0) = ns { remi = r - 1 } | otherwise = s where c = hs ! col in if (not (fs ! row)) then rowtest else s in foldl devil s ls mcluster :: (Int,Int) - [(Int,Int)] - [(Int,[Int])] mcluster (lr,lc) ls = let (k,r) = divMod lr lc start = Folding{clusters = [],remi = r,colsCount = constArray lc 0,rowsCheck = constArray lr False } cs = result $ rcluster ls k start in map collapse . groupBy (comp fst (==)) . sort . map swap $ cs where comp f g x y = (f x) `g` (f y) swap = snd fst collapse = (head unzip) (fst *** snd) cluster :: (Ord b) = (a - a - b) - [a] - [a] - [(a,[a])] cluster fxy xs ys = let mkArray (l,xs) = (listArray :: (Int,Int) - [e] - DiffArray Int e) (0,l-1) xs xls = mkArray (lc,xs) yls = mkArray (rc,ys) (lc,rc) = (length xs,length ys) in map ((yls !) *** map (xls !)) (mcluster (lc,rc) (snd.unzip.sort $ delta)) where delta = [(fxy x y,(n,m))|(n,x) - zip [0..] xs, (m,y) - zip [0..] ys] -- call it with 2 args, the number ov values and the number of clusters -- prog 101 10 will cluster 101 values in 10 clusters points m n = do gen - getStdGen return $ splitAt n (take (m + n) (randomRs (0,100::Int) gen)) test1 = do args - getArgs return $ map read args :: IO [Int] main = do [m,n] - test1 --let [m,n] = [10,3200] (ps,bs) - points m n print $ cluster (\x y - abs (x - y)) ps bs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Package rdtsc for reading IA-32 time stamp counters
Hi, version 1.0 of package rdtsc has just been released. This small package contains one module called 'Rdtsc.Rdtsc'. I am wondering what it would take to get rdpmc in there as well. Of course, you'd need some way to set the pmcs before running, but that can be done using e.g. perfctr. I'd like to take a swing at implementing this, unless somebody else volunteers or thinks it's basically useless. -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arrays performance
Paolo Veronelli wrote: Quoting Paolo Veronelli [EMAIL PROTECTED]: I paste new version in case you care give me some moe suggestion. import Data.Maybe import Data.List import Data.Array.Diff import System.Environment import Control.Arrow import Control.Monad import Random inc l i = l // [(i,l!i + 1)] switch l i = l // [(i,not (l!i))] constArray n v = listArray (0,n-1) (repeat v) I don't know about performance differences, but I write constArray using the default value I can give to accumArray: constArray n v = accumArray (const) v (0,n-1) [] where (const) might as well be (undefined) or (error unused) data Folding = Folding {clusters :: [(Int,Int)], remi :: Int, colsCount :: DiffArray Int Int ,rowsCheck :: DiffArray Int Bool} result (Folding cs _ _ _) = cs rcluster ls d s = let devil s@(Folding cs r hs fs) l@(row,col) = let ns = s { clusters = (l:cs), rowsCheck = switch fs row, colsCount = inc hs col } rowtest | c d = ns | (c == d) (r 0) = ns { remi = r - 1 } | otherwise = s where c = hs ! col in if (not (fs ! row)) then rowtest else s in foldl devil s ls I cannot tell by a quick glance, but you may want foldl' instead of foldl here. mcluster :: (Int,Int) - [(Int,Int)] - [(Int,[Int])] mcluster (lr,lc) ls = let (k,r) = divMod lr lc start = Folding{clusters = [],remi = r,colsCount = constArray lc 0,rowsCheck = constArray lr False } cs = result $ rcluster ls k start in map collapse . groupBy (comp fst (==)) . sort . map swap $ cs where comp f g x y = (f x) `g` (f y) swap = snd fst collapse = (head unzip) (fst *** snd) snd.unzip is better written as map snd so this is collapse = (fst.head map snd) which is identical to the pointful collapse x@((a,_):_) = (a,map snd x) cluster :: (Ord b) = (a - a - b) - [a] - [a] - [(a,[a])] cluster fxy xs ys = let mkArray (l,xs) = (listArray :: (Int,Int) - [e] - DiffArray Int e) (0,l-1) xs xls = mkArray (lc,xs) yls = mkArray (rc,ys) (lc,rc) = (length xs,length ys) in map ((yls !) *** map (xls !)) (mcluster (lc,rc) (snd.unzip.sort $ delta)) snd.unzip is better written as map snd Do you need the sort $ delta to sort the snd field as well as the fst? If not then using sortBy (comp fst compare) might be clearer (and may be faster or slower). where delta = [(fxy x y,(n,m))|(n,x) - zip [0..] xs, (m,y) - zip [0..] ys] I don't know if it matters, but zip [0..] xs is the same as assocs xls and the same for ys/yls. And now something slightly bizarre occurs to me. The list map swap delta looks perfect to initialize a two dimensional Array to cache the fxy x y values you pre-compute for the sorting. Rather than form (n*m) pairs you could form a single unboxed n by m Array: deltaArray :: UArray (Int,Int) Int -- Unboxed for efficiency deltaArray = listArray ((0,0),(lc,rc)) [fxy x y | x - xs, y - ys] delta :: [(Int,Int)] delta = sortBy (comp (deltaArray!) compare) deltaArray.indices If you only need to sort by the fst field, i.e. the (fxy x y), then this is sufficient and you can call (mcluster (lc,rc) delta). If you needed delta sorted by both fields, then a more complicated function to sortBy is needed: delta = sortBy (\nm1 nm2 - compare (deltaArray!nm1) (deltaArray!nm2) `mappend` compare nm1 nm2) deltaArray.indices The `mappend` depends on the instance Monoid Ordering and import Data.Monoid and is a great way to chain comparisons. -- call it with 2 args, the number ov values and the number of clusters -- prog 101 10 will cluster 101 values in 10 clusters points m n = do gen - getStdGen return $ splitAt n (take (m + n) (randomRs (0,100::Int) gen)) test1 = do args - getArgs return $ map read args :: IO [Int] main = do [m,n] - test1 --let [m,n] = [10,3200] (ps,bs) - points m n print $ cluster (\x y - abs (x - y)) ps bs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: January 02, 2007
On Tue, 2 Jan 2007, Donald Bruce Stewart wrote: Dimensional: Statically checked physical dimensions. Björn Buckwalter [4]announced version 0.1 of [5]Dimensional, a module for statically checked physical dimensions. The module facilitates calculations with physical quantities while statically preventing e.g. addition of quantities with differing physical dimensions. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/14691 5. http://code.google.com/p/dimensional/ How is it related to this one: http://www.haskell.org/haskellwiki/Dimensionalized_numbers ? It should certainly be mentioned on http://www.haskell.org/haskellwiki/Physical_units http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics#Physical_units ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Package rdtsc for reading IA-32 time stamp counters
Andy Georges schrieb: Hi, version 1.0 of package rdtsc has just been released. This small package contains one module called 'Rdtsc.Rdtsc'. I am wondering what it would take to get rdpmc in there as well. Of course, you'd need some way to set the pmcs before running, but that can be done using e.g. perfctr. I'd like to take a swing at implementing this, unless somebody else volunteers or thinks it's basically useless. I welcome any patches. Currently, I do not plan to support other performance counters or measurement schemes. BTW, version 1.1 of rdtsc is now available from http://uebb.cs.tu-berlin.de/~magr/projects/rdtsc/doc/ or darcs get --partial http://uebb.cs.tu-berlin.de/~magr/projects/rdtsc/ (thanks to Bjorn Bringert for the hask-home tool used to generate the homepage for rdtsc). Bye, Martin signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MVar style question
When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa? I'm not sure if this is really a question of style, or if there are practial implications I'm missing one way or another. Thanks! -- Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Redefining superclass default methods in a subclass
Hi, Looking at some of the ideas in http://www.haskell.org/haskellwiki/The_Other_Prelude , it struck me that the class system at the moment suffers from the problem that as hierarchies get deeper, the programmer is burdened more and more by the need to cut-and-paste method definitions between instances because Haskell doesn't allow a superclass (or ancestor class) method default to be redefined in a subclass. For example, consider this part of a proposal for Functor = Applicative = Monad: -- I've just used 'm' so it's easy to see what parts are relevant to Monad class Functor m where fmap :: (a - b) - m a - m b class Functor m = Applicative m where return :: a - m a (*) :: m (a - b) - m a - m b () :: m a - m b - m b ma mb = -- left as exercise for a rainy day! class Applicative m = Monad m where (=) :: m a - (a - m b) - m b The problem with this is that whereas someone defining a Monad at the moment only needs to define (return) and (=), with the above, though it gives obvious advantages in flexibility, generality etc, defining a new Monad involves providing methods (in instance decls) for fmap and (*) as well, and the default method for () is ma mb = (fmap (const id) ma) * mb (from that page above) which I'm sure everyone will agree is a *lot* more complicated than: ma mb = ma = (\_ - mb) Not only is the first definition for () more complicated, it obscures the simple fact that for monads it's just a trivial special-use case of = where the bound argument is ignored. Therefore I'm wondering if it would be possible to allow default methods for a superclass to be defined, or redefined, in a subclass, so we could write: class Applicative m = Monad m where (=) :: m a - (a - m b) - m b mf * ma = mf = \f - ma = \a - return (f a) ma mb = ma = \_ = - mb fmap f ma = ma = \a - return (f a) (I know the above can be written in a more point-free style but I wrote it like that to make it easy to understand what's happening.) The essential point here (excuse the pun :-) ) is that it is impossible to write the default methods in the class in which the operation is defined, because the implementation depends on methods of the relevant subclass (and will therefore be different for different subclasses though not for each particular instance of a given ancestor class of a particular subclass). As Haskell stands at the moment, we are forced to cut and paste identical methods for each individual instance of each ancestor class of a particular subclass because we can't override an ancestor class method in the *class* decl for a subclass. The type class system at present is based on the idea that you can define related methods together and in terms of each other, at one level of the hierarchy. However as the above example shows, related methods sometimes need to be spread over the hierarchy but we still want to be able to define default implementations of them in terms of each other. Perhaps there is some reason this can't be done? Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Seeking advice on a style question
[Apologies for the long delay in replying; I've been traveling, etc.] On Sun, 31 Dec 2006 20:11:47 +0100, you wrote: The other extreme is the one I favor: the whole pipeline is expressible as a chain of function compositions via (.). One should be able to write process = rectangles2pages . questions2rectangles This means that (rectangles2pages) comes from a (self written) layout library and that (questions2rectangles) comes from a question formatting library and both concern are completely separated from each other. If such a factorization can be achieved, you get clear semantics, bug reduction and code reuse for free. I favor that approach, too. ;) The problem is that when there is a multi-step process, and various bits of information get propagated throughout, as required by the various steps in the process, the overall decomposition into a series of steps a . b . c . ... can become brittle in the face of changing requirements. Let's say, for example, a change request comes in that now requires step 13 to access information that had previously been discarded back at step 3. The simple approach is to propagate that information in the data structures that are passed among the intervening steps. But that means that all of the steps are touched by the change--because the relevant data structures are redefined--even though they're just passing the new data along. The less simple (and not always feasible) approach is to essentially start over again and re-jigger all of the data structures and subprocesses to handle the new requirement. But this can obviously become quite a task. If there are only the cases of some single question or a full questionnaire, you could always do blowup :: SingleQuestion - FullQuestionaire preview = process (blowup a_question) ... In general, I think that it's the task of (process) to inspect (Item) and to plug together the right steps. For instance, a single question does not need page breaks or similar. I would avoid overloading the (load*) functions and (paginate) on (Item). A single question can be several pages long, so it does need to be paginated. The reason for the decomposition as it now stands is that any item (and there are more kinds of items than just questions and questionnaires) can be decomposed into a pagemaster and a list of questions. Once that has occurred, all items acquire essentially the same shape. That's why loading the pagemaster and loading the questions are the first two steps in the process. Btw, the special place end suggests that the question markup language does not incorporate all of: conditional questions, question groups, group templates? Otherwise, I'd just let the user insert if media=print template-instance ref=endquestions.xml / /if at the end of every questionnaire. If you use such a tiny macro language (preferably with sane and simple semantics), you can actually merge (stripUndisplayedQuestions) and (appendEndQuestions) into a function (evalMacros) without much fuss. If only I had the power to impose those kinds of changes Unfortunately, I have little control over the logical organization of questions, questionnaires and all of the other little bits and pieces. (I assure you I would have done it quite differently if I could.) Instead, I have to deal with an ad hoc pseudo-hierarchical quasi-relational database structure, and to settle for occasional extra columns to be added to the tables in order to specify information that I can't synthesize any other way. Uh, that doesn't sound good. I assume that the post-processing is not implemented in Haskell? Not even remotely so. ;) In the paper world, post-processing consists of semi-automated collation and stapling of the actual printed pages. In the electronic world, during previous survey periods, an analogous process was used (a front questionnaire and a back questionnaire would be figuratively stapled together); we're looking to make the merging a bit smoother and more automatic this time around. As is often the case, the motivation for the rather arcane post-processing is human, rather than technical. Let's say I have ten different questionnaires, where the first five pages of each questionnaire are identical, and these are followed by six additional pages that differ from one questionnaire to another. That's a total of 10 * 11 = 110 pages, but only 5 + 10 * 6 = 65 _distinct_ pages. As hard as it may be to believe, the people who are responsible for approving the questionnaires see it like this: If the system produces one 5-page front questionnaire and ten 6-page back questionnaires, then that's 65 pages that they have to inspect. But if the system were to produce ten 11-page questionnaires, even though the first five pages of each questionnaire are generated from exactly the same data using exactly the same software, that's 110 pages that they have to inspect. Fine, though I don't see exactly why this isn't done before after the questions have
Re: [Haskell-cafe] MVar style question
Chad Scherrer wrote: When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa? No one is strictly better than the other. But there are practical implications of choosing between them. For instance, MVar (A,B) is less prone to deadlock issues than (MVar A, MVar B). Consider (a,b) :: (MVar A, MVar B) alice = do takeMVar a ; takeMVar b ; foo ; putMVar a x ; putMVar b y bob = do takeMVar b ; takeMVar a ; bar ; putMVar b w ; putMVar a z If alice and bob run concurrently, it might happen that alice takes a, bob takes b, and no one can proceed further. So, you must be very careful about the ordering of the takeMVar's (e.g. if you need both, always take a before taking b). There is no such issue using MVar (A,B), since only a single takeMVar is needed. On the other hand using MVar (A,B) may reduce concurrency, imposing unnecessary locks. If alice2 only needs a, why should she be blocked from bob2 using only b? This issue gets worse once one starts using MVar (A,B,C,...), or MVar [A]. So, the solution is: choose wisely! ;-) Regards, Roberto Zunino. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] trivial function application question
greetings to this helpful and informative list i have a small problem that will be certainly trivial for almost everyone reading this, i would appreciate a little help lets say i have a string s = abcdefg now i have two lists of strings, one a list of patterns to match, and a list of replacement strings: patterns = [a,b] replace = [Z,Y] from which my intent is that a be replaced by Z, b by Y etc now using the replace function from MissingH.Str (which i know is now renamed), i wish to apply replace to s using (pattern[0], replace[0]), (pattern[1], replace[1])...(pattern[N], replace[N]). i am sure there is an elegant way to apply replace to s for all of these argument pairs without composing replace N times myself, but the solution escapes me. thanks in advance for any help you can provide for this trivial issue brad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trivial function application question
Hi Brad, i have a small problem that will be certainly trivial for almost everyone reading this, i would appreciate a little help If you have trivial problems, its often useful to ask on Haskell IRC (http://www.haskell.org/haskellwiki/IRC_channel) from which my intent is that a be replaced by Z, b by Y etc i am sure there is an elegant way to apply replace to s for all of these argument pairs without composing replace N times myself, but the solution escapes me. In your example all strings are one letter long, is that how this works? If so, then you can simplify the problem significantly to use Char's, and use the following library functions: First off, if you want to apply the same transformation to each item of a list, namely to either replace it or leave it the same. This calls out for map. Secondly you want to do lookups in some sort of table. The lookup function can be very handy here. The lookup function works on associative lists, so you'd need to zip patterns and replace into an associative list. If you really want to operate on strings, rather than characters, then you have to be more clever. Also replace called multiple times probably won't be enough, consider replacing 1 with 2, 2 with 3. If you just call replace multiple times, 1 may well end up at 3, when 2 is more likely to be the right answer. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trivial function application question
On 1/4/07, brad clawsie [EMAIL PROTECTED] wrote: lets say i have a string s = abcdefg now i have two lists of strings, one a list of patterns to match, and a list of replacement strings: patterns = [a,b] replace = [Z,Y] from which my intent is that a be replaced by Z, b by Y etc now using the replace function from MissingH.Str (which i know is now renamed), i wish to apply replace to s using (pattern[0], replace[0]), (pattern[1], replace[1])...(pattern[N], replace[N]). You can create the replacing functions using zipWith :: (a - b - c) - [a] - [b] - [c] (from the Prelude) as follows: replacers = zipWith patterns replace You then need to apply these functions to your starting string s. I would probably use foldr for that, something like this: foldr ($) s replacers Where ($) performs function application. As Neil points out, if your replacements overlap, this could cause replacement text to itself be replaced. /g -- It is myself I have never met, whose face is pasted on the underside of my mind. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Redefining superclass default methods in a subclass
Brian Hulley wrote: Hi, Looking at some of the ideas in http://www.haskell.org/haskellwiki/The_Other_Prelude , it struck me that the class system at the moment suffers from the problem that as hierarchies get deeper, the programmer is burdened more and more by the need to cut-and-paste method definitions between instances because Haskell doesn't allow a superclass (or ancestor class) method default to be redefined in a subclass. The class aliases proposal lists several similar shortcomings of the current class system. http://repetae.net/john/recent/out/classalias.html Perhaps there is some reason this can't be done? Some random thoughts: How one would write instances? Using your Monad class, does instance Monad F where return = ... (=) = ... automatically define an instance for Applicative? If it does: What if there already is such an instance? Which one gets used for ()? The user-defined one or the Monad default? Is separate compilation still possible? (If there is no instance right now, one might pop out in another module...) If it does not: How can one define it, without copy-and-pasting the default? Zun. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MVar style question
Do you need to maintain invariants that span the two? Put operationally, do you want different threads to be able to access a and b concurrently? -m Chad Scherrer [EMAIL PROTECTED] writes: When using MVars, is there a reason to prefer using MVar (a,b) over (MVar a, MVar b), or vice versa? I'm not sure if this is really a question of style, or if there are practial implications I'm missing one way or another. Thanks! -- Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Redefining superclass default methods in a subclass
Roberto Zunino wrote: Brian Hulley wrote: because Haskell doesn't allow a superclass (or ancestor class) method default to be redefined in a subclass. How one would write instances? Using your Monad class, does instance Monad F where return = ... (=) = ... automatically define an instance for Applicative? Yes, but I'd make the method names be call-site-bound so the actual method that is called is determined by the set of instance decls and class decls visible at each particular call site, and any instances that are automatically created would be hidden by any explicitly defined instances that are visible. If it does: What if there already is such an instance? Which one gets used for ()? The user-defined one or the Monad default? A possible proposal could be: 1) Class and instance decls would allow method implementations to be given for any methods in the class or any ancestor class. 2) Whenever an instance decl is visible there would always be a full set of instance decls for all ancestor classes, by supplementing the set of explicitly given instance decls that are visible by automatically generated implicit instance decls. 3) The most specific method implementation would always be chosen (ie prefer an explicit instance method over a class method and prefer a subclass method to a superclass method) In particular rule 2) would mean that the actual method used depends on what's available at the call site which means that a Haskell program could no longer be thought of as being re-written into a single module before compilation, since the meaning of overloaded names would be determined by (CalledFromModule, Type) not just Type. (The desire to hide instance decls or have different instance decls for the same type within the same program has come up before on the list but unfortunately I can't remember who posted something along these lines or when.) Is separate compilation still possible? (If there is no instance right now, one might pop out in another module...) I think it should still be possible because within a module, the overloadings would be determined by the set of explicitly defined instances in scope in that module. Various optimizations might be more tricky because the call site module associated with each overloaded name would need to be taken into account when inlining across module boundaries (ie a name used inside an inlined function needs to be resolved as if it had been used in the module where the function was defined not the module where the function is inlined). For example: module A where import Proposed.Control.Monad data T a = T a instance Monad T [-# INLINE foo #-} foo :: a - T a foo = return -- uses Monad class default -- which is inherited from the Applicative -- class default module B where import A import Proposed.Control.Monad instance Applicative T where return x = retB x bar :: T a bar = return 'q'-- would use (retB) zap :: T a zap = foo 'q'-- would use (return) from A A question is whether the extra difficulty in resolving overloadings (for human reader as well as complier) is worth the advantages of being able to get generated definitions for () for Applicative and (fmap) for Functor from a single instance decl for (Monad.=) etc. [Rearranged] The class aliases proposal lists several similar shortcomings of the current class system. http://repetae.net/john/recent/out/classalias.html IIUC the class alias proposal is about being able to group classes together and deal with them as a whole so similar issues of resolving overloadings arising from overlapping aliases/ explicit instance decls etc would arise (and I imagine the solutions would lie in similar directions). Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: state of HaXml?
nr: Sure, you can replace the openFile/hGetContents pair by readFile, but the real problem is the presence of the hClose. Removing that will solve your problem (but note that you now have no control over when the file is actually closed). Can I just leave it hanging and rely on the garbage collector to close it in the fullness of time? Yeah, once your program has demanded the entire file, it'll close the Handle. Because of laziness, I believe there's no point in my writing the following: load fn = do handle - IO.openFile fn IO.ReadMode contents - IO.hGetContents handle let xml = XP.xmlParse fn contents IO.hClose handle return xml Is that correct? Yep. Its not neccessary in the usual programming cases to explicitly close the handle. IF you start really hammering the filesystem do you start to care about ensuring files are closed (so you don't hang on to too many FDs). Or if you start mutating files on disk. For these situations there are strict readFiles, or Data.ByteString.readFile -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trivial function application question
So the core question (speaking as a perler) is how do you write my $s= 'abcdefg'; $s =~ s/a/z/g; $s =~ s/b/y/g; print $s\n; in haskell? There are various haskell regex libraries out there, including ones that advertise they are PCRE (Perl Compatible Reg Ex). But which one to use? How hard to install? With the libs mentioned above, the PCRE-ness seems only to be for matching, not for substitutions. http://www.cs.chalmers.se/~d00nibro/harp/ http://repetae.net/john/computer/haskell/JRegex/ So, I would like to know a good answer to this as well. thomas. brad clawsie-2 wrote: greetings to this helpful and informative list i have a small problem that will be certainly trivial for almost everyone reading this, i would appreciate a little help lets say i have a string s = abcdefg now i have two lists of strings, one a list of patterns to match, and a list of replacement strings: patterns = [a,b] replace = [Z,Y] from which my intent is that a be replaced by Z, b by Y etc now using the replace function from MissingH.Str (which i know is now renamed), i wish to apply replace to s using (pattern[0], replace[0]), (pattern[1], replace[1])...(pattern[N], replace[N]). i am sure there is an elegant way to apply replace to s for all of these argument pairs without composing replace N times myself, but the solution escapes me. thanks in advance for any help you can provide for this trivial issue brad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://www.nabble.com/trivial-function-application-question-tf2922232.html#a8173692 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] trivial function application question
Oops, I seem not to have proofread my message. On 1/4/07, J. Garrett Morris [EMAIL PROTECTED] wrote: On 1/4/07, brad clawsie [EMAIL PROTECTED] wrote: s = abcdefg patterns = [a,b] replacements = [Z,Y] I changed the name here so as not to conflict with the replace function. snip You can create the replacing functions using zipWith :: (a - b - c) - [a] - [b] - [c] (from the Prelude) as follows: replacers = zipWith replace patterns replacements This line was previously incorrect. /g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe