October 2008 - Haskell-Cafe

Pandoc questions
by Andrew Coppin 23 Oct '08

23 Oct '08

There doesn't seem to be any option to make Pandoc produce actual MathML output. Is there a reason for this? (The only option I can see is to spit out raw LaTeX plus a 70KB JavaScript program to transform this into MathML at the client end --- which seems a little silly to me. There's also no way to style the raw LaTeX differently in case JavaScript is unavailable.) Also, while Markdown *almost* does what I want, there are a few small constructs it doesn't have. For example, I'd like to have some way to denote a "term" the first time I use it. I could just use italics, but I'd prefer some way to visually indicate that this isn't just an emphasised word, it's a new technical term. In HTML, I'd use a style class, and in LaTeX I'd define a new command. But I can't see a way to do something that will still allow Pandoc to generate correct LaTeX *and* correct HTML from a single Markdown source... Any hints?

4 8

Re: External Sort: Sort a 10-million integer file with just 256M of ram.
by Ben 23 Oct '08

23 Oct '08

the problem with the current externalSort is that it is not recursive -- it tries to do everything in one pass. basically instead of attempting to merge all of the chunks together it should only merge chunksize chunks together, producing a new list of chunks. then those get merged, etc....there is a discussion of this in knuth i think. it shouldn't be hard to make this work, i just didn't have time when i wrote it. ben

1 0

Re: [Haskell-cafe] Fwd: enhancing type classes with properties
by Alberto G. Corona 23 Oct '08

23 Oct '08

It seems that some of the goals are not so hard. here I publised my progress. http://docs.google.com/Doc?id=dd5rm7qq_165rshp74gf&pli=1 I show how to define a Ring, such a mathematical structure in Haskell, how to instantiate the class Num as a Ring , how to (possibly in other moment of space-time) instantiate a new class as Num and how to test the axioms for the new class. All of then is something like a sophisticated "assert" mechanism, but , I think, much more flexible and elegant. 2008/10/22 Alberto G. Corona <agocorona(a)gmail.com> > I guess that the namespace thing is not necesary. Maybe it can be done in > template haskell. I never used TH however. it is a matter of inserting code > here and there and rewrite rules somewhere at compile time. It´s a nice > project. I´ll try. > > > 2008/10/22 Mitchell, Neil <neil.mitchell.2(a)credit-suisse.com> > >> Hi Alberta, >> >> It's a lot of work, but I wish you luck :-) Many of the underlying tools >> exist, but there definately needs more integration. >> >> Thanks >> >> Neil >> >> >> This material is sales and trading commentary and does not constitute >> investment research. Please follow the attached hyperlink to an important >> disclaimer >> *<www.credit-suisse.com/emea/legal>* >> >> >> ------------------------------ >> *From:* Alberto G. Corona [mailto:agocorona@gmail.com] >> *Sent:* 22 October 2008 4:23 pm >> *To:* Mitchell, Neil >> *Subject:* Re: [Haskell-cafe] Fwd: enhancing type classes with properties >> >> Hi Neil, >> >> I see the contract type mechanism and safety check techniques reflected >> in the above paper are a good step, But I think that something more >> general would be better. What I propose is to integrate directly in the >> language some concepts and developments that are already well know to >> solve some common needs that I thing can not be solved without this >> integration: >> >> To make use of: >> >> -Quickcheck style validation. By the way, Don Steward recommend to add >> quckcheck rules close to the class definitions just for better >> documentation >> >> - Implicit class properties defined everywhere in the documentation but >> impossible to reflect in the code (for example the famous monad rules: >> return x >>= f == f x etc ) >> >> - The superb ghc rewrite rule mechanism (perhaps with enhancements) >> >> - object style namespaces, depending on class names. >> >> To solve problems like >> >> - code optimization >> >> - code verification. regression tests for free!! >> >> - The need for safe overloading of methods and operators (making the >> namespaces dependent not only on module name but also in class names) . Why >> I can not overload the operator + in the context of a DSL for >> JavaScript generation if my operator does what + does? >> >> - strict and meaningful rules for class instances. >> - to make the rewrite rule mechanism visible to everyone >> >> >> >> 2008/10/22 Mitchell, Neil <neil.mitchell.2(a)credit-suisse.com> >> >>> Hi Alberto, >>> >>> Take a look at ESC/Haskell and Sound Haskell, which provide mechanisms >>> for doing some of the things you want. I don't think they integrate with >>> type classes in the way you mention, but I think that is just a question of >>> syntax. >>> >>> http://www.cl.cam.ac.uk/~nx200/ <http://www.cl.cam.ac.uk/%7Enx200/> >>> >>> Thanks >>> >>> Neil >>> >>> >>> This material is sales and trading commentary and does not constitute >>> investment research. Please follow the attached hyperlink to an important >>> disclaimer >>> *<www.credit-suisse.com/emea/legal>* >>> >>> >>> ------------------------------ >>> *From:* haskell-cafe-bounces(a)haskell.org [mailto: >>> haskell-cafe-bounces(a)haskell.org] *On Behalf Of *Alberto G. Corona >>> *Sent:* 22 October 2008 1:43 pm >>> *To:* haskell-cafe(a)haskell.org >>> *Subject:* [Haskell-cafe] Fwd: enhancing type classes with properties >>> >>> I´m just thinking aloud, but, because incorporating deeper mathematics >>> concepts has proven to be the best solution for better and more flexible >>> programming languages with fewer errors, I wonder if raising the type >>> classes incorporating axioms can solve additional problems. >>> >>> At first sight it does: >>> >>> >>> class Abelian a where >>> (+) :: a -> a -> a >>> property ((+))= a+b == b+a >>> >>> >>> >>> this permits: >>> 1- safer polimorphism: I can safely reuse the operator + if the type >>> and the property is obeyed. The lack of ability to redefine operators is a >>> problem for DSLs that must use wreid symbols combinations with unknow >>> meanings. To use common operators with fixed properties is very good. the >>> same aplies for method names. >>> >>> 2- the compiler can use the axions as rewrite rules. >>> >>> 3- in debugging mode, it is possible to verify the axiom for each >>> value a generated during execution. Thus, a generator is not needed like >>> in quickcheck. The logic to quickcheck can be incorporated in the debugging >>> executable. >>> >>> 3 guaranties that 1 and 2 are safe. >>> >>> >>> >>> >>> >>> a type class can express a relation between types, but it is not >>> possible to define relation between relations. >>> >>> ============================================================================== >>> Please access the attached hyperlink for an important electronic communications disclaimer: >>> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html >>> ============================================================================== >>> >>> >> ============================================================================== >> Please access the attached hyperlink for an important electronic communications disclaimer: >> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html >> ============================================================================== >> >> >

1 1

Re: [Haskell-cafe] Crash!
by Andrew Coppin 23 Oct '08

23 Oct '08

D.V. wrote: > On Thu, Oct 23, 2008 at 10:30 PM, Andrew Coppin > <andrewcoppin(a)btinternet.com> wrote: > >> Really? Well I've never ever seen GNOME crash. Hell, I run a GNOME desktop >> on a 0.01 GHz Amiga 1200 and it works! (Sure, it's slower than MS Vista on >> > > Now that's cool. I wish my Amiga still worked. > Hint: If you ever get it to work again... don't install Debian. Or rather, don't install Debian if you enjoy programs that open on the same calendar day as you click the icon. o_O It's really neat that you can make Linux run on anything, but that doesn't necessarily mean you _should_...

1 0

Re: [Haskell-cafe] Detecting unused read handles? (was: File handles and pipes)
by Thomas Hartman 23 Oct '08

23 Oct '08

>> Specifically I'm trying to concatenate the output of two system calls >> into the input of a third. The following code does not get the job Can the left-fold enumerator described by oleg in http://okmij.org/ftp/Haskell/fold-stream.lhs and with more references at http://okmij.org/ftp/Haskell/ be adapted for reading the output from arbitrary system calls? I.e., to deal with pipes? My intuition says yes but I'm still trying to wrap my head around the whole left fold enumerator approach to io. The text around "We can now test reading from two streams with interleaving:" in the first reference seemed particularly promising to me. > > > > > 2008/10/19 Stephen Hicks <sdh33(a)cornell.edu>: >> On Sun, Oct 19, 2008 at 1:44 AM, Brandon S. Allbery KF8NH >> <allbery(a)ece.cmu.edu> wrote: >>> On 2008 Oct 19, at 1:37, Stephen Hicks wrote: >>>> >>>> I'm trying to understand how to get pipes working in Haskell, in >>>> particular with the revamped System.Process (though I've tried similar >>>> experiments with System.Posix.IO and Control.Concurrent). >>>> Specifically I'm trying to concatenate the output of two system calls >>>> into the input of a third. The following code does not get the job >>>> done: >>> >>> Pipes are perhaps a bit misnamed: if you want to combine the output of two >>> pipes and funnel it into a third you can't simply "plumb them together", you >>> need to provide code which reads from the output pipes and writes into the >>> input pipe. If you don't care about order, forkIO a thread for each output >>> pipe which reads from the output pipe it's passed and writes to the input >>> pipe. If order is significant, use mapM/forM to run the output-to-input >>> code on each handle in turn. >> >> Thanks a lot - that seems to work very well, and even scales to large >> amounts of data nicely (and quickly, with Lazy ByteStrings). >> >> I've got one more question now. Suppose I want to do the same thing >> on the other side, with two processes *receiving* the data. Is there >> a way to tell whether the first process wants input, and if not, wait >> for the second process to do anything? >> >> That is, suppose I have something like >> >>> do (Just inh1, _, _, p1) <- createProcess (shell "echo 1") { std_in = CreatePipe } >>> -- wait for p1, possibly feeding it some input? >>> (Just inh2, _, _, p2) <- createProcess (shell "cat") { std_in = CreatePipe } >> >> Is there a way to figure out that the "echo 1" process never wanted >> any input, and therefore not give it any? I looked through all of >> System.IO and everything seemed to indicate that inh1 was open, even >> after the process ended. The only indication otherwise was that >> "hflush inh1" failed with "resource vanished". I guess what I'm >> asking is I want to "wait until the process p1 is waiting for input >> and/or terminates", and if it's the latter, move on to the next >> process in line, before actually doing any hPutStr into the read >> handles. Is that possible? >> >> Thanks, >> steve >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >

2 1

any idea why cabal install cabal-install cant update itself in windows?
by Anatoly Yakovenko 23 Oct '08

23 Oct '08

C:\Documents and Settings\anatolyy>cabal install cabal-install Resolving dependencies... 'cabal-install-0.6.0' is cached. Configuring cabal-install-0.6.0... Preprocessing executables for cabal-install-0.6.0... Building cabal-install-0.6.0... ... Linking dist\build\cabal\cabal.exe ... Installing: C:\Documents and Settings\anatolyy\Application Data\cabal\bin C:\Documents and Settings\anatolyy>cabal --version cabal-install version 0.5.2 using version 1.4.0.2 of the Cabal library

3 4

building c2hs on Mac
by John Lato 23 Oct '08

23 Oct '08

Hello, I've been trying to build c2hs-0.15.1 on an Intel Mac (10.4), and am having some difficulty. It has dependencies on happy and alex, which would be fine, except that alex itself seems to require alex (using alex 2.2). Does anyone have any suggestions for how to get around this? I have ghc-6.8.3 and ghc-6.10 RC, and could use either. Last time I tried to build c2hs on a mac I think I used macports, which worked fine, except that's not an option this time because the computer in question isn't (and won't be) online. I'd have to rebuild ghc anyway, which I don't want to do. Thanks, John Lato

3 4

Plans for new System.Process?
by Stephen Hicks 23 Oct '08

23 Oct '08

Hi, I've been trying out the new System.Process and have found it to be very useful. I was wondering what the plans for it were - I'd rather not give up support for older versions of ghc just because I want to use createProcess. Are there plans of releasing process-1.0.1 so that it's compatible with older compilers too? Or does it depend on something internally that makes this impossible? Cheers, steve

2 1

Re: [Haskell-cafe] Re: universal algebra "support" in Haskell?
by Nathan Bloomfield 23 Oct '08

23 Oct '08

This question is relevant to a project I'm working on. I've been putting together an abstract algebra library for handling computations inside group rings, polynomial rings, and rings with adjoined elements. Once I've got it cleaned up a little I'll upload it to an appropriate place. (I forgot to cc haskell-cafe- sorry DavidA!) Nathan Bloomfield

1 0

Call for Papers: Workshop on Language Descriptions, Tools and Applications 2008
by Jurgen Vinju 23 Oct '08

23 Oct '08

LDTA: Workshop on Language Descriptions Tools and Applications ===Call For Papers 2009=== This is the Call For Papers for the Ninth Workshop on Language Descriptions, Tools and Applications (LDTA 2009) LDTA is a two-day satellite event of ETAPS which takes on the 28th and 29th of March 2009 in York, England. ==Scope== LDTA is an application and tool oriented forum on meta programming in a broad sense. A meta program is a program that takes other programs as input or output. The focus of LDTA is on generated or otherwise efficiently implemented meta programs, possibly using high level descriptions of programming languages. Tools and techniques presented at LDTA are usually applicable in the context of "Language Workbenches" or "Meta Programming Systems" or simply as parts of advanced programming environments or IDEs. The applications areas include, but are not limited to: * Program analysis, transformation, generation and verification * Implementation of Domain Specific Languages (both visual and textual) * Reverse engineering and reengineering * Refactoring and other source-to-source transformations * Application modelling (MDE, MDA, Software Factories, Software product lines) * Grammar engineering / Grammarware * Language definition and language prototyping * Debugging, profiling and testing * IDE construction * Compiler construction LDTA is a well-established workshop next to other conferences and workshops on (programming) language engineering topics such as SLE and GPCE.LDTA is traditionally a forum where computer science theories are put to the test of real-world software engineering issues, for example by applying: * context-free grammars to parser generation for real programming languages, * attribute grammars to static analyzer and compiler generation, * term rewriting to source-to-source transformation, * action semantics to programming language implementation, * model checking to software verification. Note that LDTA solicits submissions from any technological or theoretical domain, as long as the paper is within the application scope. ==Submission Procedure and Publication== Submissions in the following categories are admissible: * research papers, * tool papers, * experience papers The final versions of accepted papers will probably(*) be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science, and will be made available during the workshop. (*)Due to organizational changes at Elsevier, publication by ENTCS publication is provisional; another comparable venue will be found otherwise. Each submission must: * clearly and unambiguously state in which of the three categories it falls * be original, i.e. not published or submitted elsewhere, * contain a clear motivation, * contain a thorough analysis of the claimed contributions (for example by comparing to related work), * be written in less than 15 pages (research papers and experience reports), or less than 10 pages (tool papers) * use the ENTCS style. The authors of each submission are required to give a presentation at LDTA 2009. The authors of the tool papers are required to include an interactive demonstration in their presentations. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, assuming acceptance, be published in journal form. As in past years, this will be done in a special issue devoted to LDTA 2009 of the journal Science of Computer Programming (Elsevier Science). The authors of the best tool papers will be invited to write a paper and submit the source of code of their tool, which will both be separately reviewed and, assuming acceptance, be published in the special issue on Experimental Software and Toolkits (EST) of the journal Science of Computer Programming (Elsevier Science). Please submit your abstract and paper using http://www.easychair.org/conferences/?conf=ldta2009 ==Program Committee== Jurgen Vinju, CWI, Amsterdam (co-chair) Torbjörn Ekman, Oxford, UK (co-chair) Erik Meijer, Microsoft, Redmond, USA Walid Taha, Rice University, Houston USA Bob Fuhrer, IBM TJ Watson, USA Susan Eisenbach, Imperial College, UK Jean-Marie Jacquet, FUNDP, Namur, Belgium Sibylle Schuppe, Chalmers, Sweden Elizabeth Scott, RHUL, UK Robert Grimm, NYU, USA Judith Bishop, Pretoria, South Africa Tudor Girba, Univ of Berne, Switzerland Marjan Mernik, University of Maribor, Slovenia Thomas Dean, Fondazione Bruno Kessler - IRST, Italy Martin Bravenboer, Univ. of Oregon, USA Pierre-Etienne Moreau, INRIA-LORIA, France Gabi Taentzer, Philipps-Universität Marburg, Germany Joao Saraiva, Universidade do Minho, Braga, Portugal Tijs van der Storm, CWI, The Netherlands Stephen Edwards, Columbia University, USA Peter Thiemann, Universität Freiburg, Germany ==Important Dates== Abstract submission deadline:Friday November 28th, 2008 Paper submission deadline:Friday December 5th, 2008 Notification of acceptance:Friday February 6th, 2009 Workshop date:28th and 29th of March, 2009

1 0