[Haskell] How to find out who is leaking memory?
My program is leaking memory. It is fairly complex and long running on the test that leaks. On that particular test it exits abnormally telling me that heap is overflown. Is there a way to find out what part is leaking memory without refactoring? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Injecting stateful computations into pure Haskell code.
It is widely spread convention to simulate electronic circuits using infinite lazy lists. This works well for high level modeling, but when engineers ask to cosimulate it with Verilog or VHDL modules it goes somewhat off of pure functional programming. The main obstacle is that those modules have their own internal state. Is it possible to represent a result of several impure calculation as a pure list? The only way I can think of is the use of unsafePerformIO. Maybe State monad will help? And how? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Template Haskell Question: Spliced expr. of type TypeQ
Hi, maybe someone can help me with this: I was wandering if I could do something similar to Depended Types using Template-Haskell. The documentation of GHC (6.2.2 and 6.4) says that a splice may occur in place of a type, but I get a parse error when I try that. So here is what I did: made a Module Templates: module Templates where expr = [| 1337*7331 |] decl = [d| hello = putStr "Hello\n"|] ty= [t| Int |] and made test file: import Templates $(decl) -- works well (tested with ghci) e = $(expr) -- works also well i :: ($tyr) -- gives a parse error i = 1 I would be really happy if someone knows how to make the last example must be written, or if that works at all. (If not, maybe the Documentation should get updated) and thanks you for reading this posting, anyway. -- Eike ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CLIMA VI :: new deadline April 15
[Apologies for cross-postings. Please send to interested colleagues and students] == * DEADLINE EXTENSION * CLIMA VI Sixth International Workshop on Computational Logic in Multi-Agent Systems featuring: the First CLIMA Tutorial Programme and the First CLIMA Competition City University, London, UK, June 27-29, 2005 http://clima.deis.unibo.it/ * SUBMISSIONS OPEN UNTIL APRIL 15, 2005 * == ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CLIMA VI :: First Call for Papers
committee --- * José Júlio Alfers, New University of Lisbon, Portugal * Rafael H. Bordini, University of Durham, UK * Gerhard Brewka, University of Leipzig, Germany * Jürgen Dix, Technical University of Clausthal, Germany * Thomas Eiter, Vienna University of Technology, Austria * Klaus Fischer, DFKI, Germany * Michael Fisher, University of Manchester, UK * James Harland, RMIT, Australia * Katsumi Inoue, National Institute of Informatics, Japan * Antonis Kakas, University of Cyprus * Evelina Lamma, University of Ferrara, Italy * João Leite, New University of Lisbon, Portugal * Paolo Mancarella, University of Pisa, Italy * Paola Mello, University of Bologna, Italy * John Jules Ch. Meyer, Utrecht University, The Netherlands * Leora Morgenstern, IBM T.J. Watson Research Center, USA * Wojciech Penczek, Polish Academy of Sciences, Poland * Jeremy Pitt, Imperial College London, UK * Enrico Pontelli, New Mexico State University, USA * Fariba Sadri, Imperial College London, UK * Ken Satoh, National Institute of Informatics, Japan * Renate Schmidt, University of Manchester, UK * Trao Can Son, New Mexico State University, USA * Kostas Stathis, City University London, UK * Wiebe van der Hoek, University of Manchester, UK * Cees Witteveen, Delft University of Technology, The Netherlands ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Problems with Happy and GHC
Hello, I am trying to make a parse to Haskell and I am using Happy. I used this parser and it generated a haskell file parser.hs. When I try to compile it, it requests a module called preladdr . How can I obtain this module?? Thanks, Fernando
SV: Haskell 1.4 and Unicode
Let me reiterate: Unicode is ***NOT*** a glyph encoding! Unicode is ***NOT*** a glyph encoding! and never will be. The same character can be displayed as a variety of glyphs, depending not only of the font/style, but also, and this is the important point, on the characters surrounding a particular instance of the character. Also, a sequence of characters can be displayed as a single glyph, and a character can be displayed as a sequence of glyphs. Which will be the case, is often font dependent. This is not something unique to Unicode. It is just that most people are used to ASCII, Latin-1 and similar, where the distinction between characters and glyphs is blurred. I would be interested in knowing why you think "the idea of it as a character encoding thoroughly breaks down in a mathematical context". Deciding what gets encoded as a character is more an international social process than a mathematical process... /kent k PS This may be getting too much into Unicode to fit for the Haskell list... In particular any argumentation regarding the last paragraph above should *not* be sent to the Haskell list, but could be sent to me personally. PPS I don't know what you mean by "semantics of glyphs". Hans Aberg wrote: > I leave it to the experts to figure out what exactly Unicode is. I > can > only note that the idea of it as a character encoding thoroughly > breaks > down in a mathematical context. I think the safest thing is to only > regard > it as a set of glyphs, which are better, because ampler, than other > encodings. I think figuring out the exact involved semantics of those > glyphs is a highly complex issue which cannot fully be resolved. >
SV: Haskell 1.4 and Unicode
Hi! 1. I don't seem to get my messages to this list echoed back to me... (Which I consider a bug.) 2. As I tried to explain in detail in my previous message, (later) options 1 and 2 **do not make any sense**. Option 3 makes at least some sense, even though it has some problems. You could generalize option 4 to make sense too. The layout rule does not generalise well. I still think that one should not give up entirely on it. One way may be to require that "where", and other layout starters, are to have only spaces (U+0020), no-break spaces (U+00A0) and tabs (U+0009) in front of them on the same line, keeping the width rule for the tabs relative to the spaces. (I know, present Haskell programs are not written that way.) 3. (In reply to Hans Aberg (Aberg?)) > The easiest way of thinking of Unicode is perhaps as a font encoding; a > font using this encoding would add such things as typeface family, style, > size, kerning (but Unicode probably does not have ligatures), etc., which As everyone (getting) familiar with Unicode should know, Unicode is **NOT** a font encoding. It is a CHARACTER encoding. The difference shows up mostly for 'complex scripts', such as Arabic and Devanagari (used for Hindi), but also in the processing of combining characters for 'latin'. Glyph (at a "font point") selection is based also on *neighbouring* characters. Unicode does have a number of compatability characters, but the explicit intent is that they should only be used for backwards compatability reasons. /kent k PS B.t.w. Did you know... that CR and LF should not be used in "newly produced" Unicode texts. One should use Line Separator (U+2028) and Paragraph Separator (U+2029) instead. Line Separator is the one expected to be used in program source files. > -Ursprungligt meddelande- > Fran: John C. Peterson [SMTP:[EMAIL PROTECTED]] > Skickat: den 8 november 1997 03:25 > Till: [EMAIL PROTECTED] > Kopia:[EMAIL PROTECTED]; [EMAIL PROTECTED] > Amne: Re: Haskell 1.4 and Unicode > > I had option 1 in mind when that part of the report was written. We > should clarify this in the next revision. > > And thanks for your analysis of the problem! > >John > >
CFP for PASCO'97
[Forwarded since this might be of interest to Haskellites. Papers on f.p. are definitely welcome! KH] Dear colleague, we think that you might be interested in either contributing a paper to or in attending the second international ACM symposium on Parallel Symbolic Computation (PASCO'97) July 20 to July 22, 1997 Aston Wailea Resort, Maui, Hawaii (near Maui Super Computer Center) The conference is sponsored by ACM and the proceedings will be published by the ACM press. Many execellent papers chosen from the proceedings of the first symposium have been also published as a special issue of Journal of Symbolic Computation (http://www.risc.uni-linz.ac.at/people/hhong/jsc-pasco/main.html). This year, the conference will take place in federation with ISSAC'97 and IMACS-ACA'97. Please, take a look at our CFP and visit our site on the WWW for more information. If you know of other interested researchers in the area of parallel symbolic computation, please pass on the news. Best regards from the PASCO'97 program committee. === CALL FOR PAPERS PASCO'97 Second International Symposium Parallel Symbolic Computation July 20 - 22, 1997 Aston Wailea Resort, Maui, Hawaii, USA === The Second International Symposium on Parallel Symbolic Computation (PASCO'97) seeks papers presenting original research on all aspects of high performance symbolic computation. High performance is meant as pertaining to the solution of large problems by means of parallel, distributed, multi-processor, or networked computers. Typical, but not exclusive topics of interest include: - high performance parallel algebraic computation, - high performance combined symbolic/numeric methods - high performance combinatorial and discrete methods, - high preformance automatic theorem proving, - design of high performance symbolic, functional, and constraint/logic languages and systems, - symbolic solution of applications problems in mathematics, science, and engineering by high performance means. Sponsors SIGSAM ACM SIG Symbolic Manipulation SIGNUM ACM SIG Numerical Mathematics Meeting Format -- PASCO'97 will be held in federation with ISSAC'97 (the International Symposium on Symbolic and Algebraic Computation, July 20-23 at the same location). There will be plenary speakers addressing the joint audience, and the exhibitions and systems demonstration area will be shared among the conferences. Papers to ISSAC'97 and PASCO'97 are submitted normally to the respective PC Chairs. For electronic submission to PASCO'97, see below. The final version of accepted papers will be published in Proceedings by ACM Press and will be available at the meeting. Several high quality papers from the first conference (PASCO'94) were published in a JSC special issue. Authors of accepted papers are expected to present their work at the meeting. Persons registering for PASCO'97 can attend ISSAC'97 talks. Program Committee - Gene Copperman Northeastern University Wayne Eberly University of Calgary Tetsuro Fujise Mitsubishi Research Inc. Kevin HammondUniversity of St. Andrews Jieh Hsiang National Taiwan University Jean-Marie Jacquet FUNDP Namur Sverker Janson Swedish Institute of Computer Science Herbert Kuchen RWTH Aachen Wolgang Kuechlin Universitaet Tuebingen Mohamed O. Rayes Texas Instruments Jean-Louis Roch LMC/IMAG Grenoble Stan Steinberg University of New Mexico Program Committee Chair --- Erich Kaltofen Mathematics Department North Carolina State University Raleigh, N.C. 27695-8205 Phone: +1 (919) 515 8785 Fax: +1 (919) 515 3798 email: [EMAIL PROTECTED] Symposium Chair --- Hoon Hong RISC-Linz, Research Institute for Symbolic Computation Johannes Kepler University A-4040 Linz, Austria/Europe Phone: +43 (7236) 3231-48 Fax: +43 (7236) 3231-30 email: [EMAIL PROTECTED] Local Organization -- Stan Steinberg Department of Math. and Statistics University of New Mexico email: [EMAIL PROTECTED] Importa
