- Haskell-Cafe - Haskell.org

Language Workbenches - the Haskell solution?
by Yoel Jacobsen 13 Sep '05

13 Sep '05

It seems that Martin Fowler's article "Language Workbenches: The killer-App for Domain Specific Languages?" - http://www.martinfowler.com/articles/languageWorkbench.html - has generated some nice dynamic solution where a configuration file is written in the same language as the program. Notable examples are lisp - http://lispm.dyndns.org/news?ID=NEWS-2005-07-08-1 and python - http://billionairebusinessman.blogspot.com/2005/09/drop-that-schema-and-put… I'm trying to create an _elegant_ solution in Haskell. But I'm stuck. Since the native record-like access in Haskell syntax is using labelled fields in datatype decleration but the later are strictly compile-time. Therefore, if I compile my program and add a field in the configuration file (written in Haskell, using, for instance hs-plugins), I'll need to recompile the data declaration as well. Further, what is the type of the parser? Consider the following implementation: source = "#123456789012345678901234567890123456789012345678901234567890\n\ \SVCLFOWLER 10101MS0120050313.........................\n\ \SVCLHOHPE 10201DX0320050315........................\n\ \SVCLTWO x10301MRP220050329..............................\n\ \USGE10301TWO x50214..7050329..............................." data Configuration = Config String [(String, Int, Int)] config = [ Config "SVCL" [("CustomerName", 4, 18), ("CustomerID", 19, 23), ("CallTypeCode", 24, 27), ("DateOfCallString", 28, 35)], Config "USGE" [("CustomerID", 4, 8), ("CustomerName", 9, 22), ("Cycle", 30, 30), ("ReadDAte", 31, 36)]] -- parse takes the configuration, a line from the source string and generate a record parse :: Configuration -> String -> Record What is the type of Record? Anyway, any elegant solution or a hint towards one are most welcome. Thanks, Yoel

3 4

Template Haskell and Types
by Gracjan Polak 13 Sep '05

13 Sep '05

Hi, Probably very simple question about template haskell: How do I make a type for an argument to splice? Example: data MyData = MyData1 | MyData2 mysplice mytype = [| litE $ stringL $ show mytype |] main = do putStrLn $(mysplice MyData) The above is not accepted, error: Compiling Main ( thtest.hs, thtest.o ) thtest.hs:51:34: Not in scope: data constructor `MyData' So how do I provide type as an argument? Besides: documentation that I found for th is very dated. Could somebody point me to something more up to date about th? Thanks! -- Gracjan

4 4

RE: [Haskell-cafe] Language Workbenches - the Haskell solution?
by Ralf Lammel 13 Sep '05

13 Sep '05

Hi Yoel, This looks like fun. Just some general comments: - One should try to *also* provide a simple solution. Here I would pick a solution that doesn't need a lot of explanation (of Haskell and the solution) and a lot of defense to score with it. - As a second step, one should identify a sweet spot upfront. The sweet spot could indeed be to get some extra static typing; some extra DSL checks; some increased declarativeness. (Or all of it.) To this end, I would study the DSL problem at hand, and not so much yet think of Haskell encoding. You can only score with Haskell, if there is something to be scored with in the problem at hand. - Now one can explore the identified sweet spot by trying to put strong Haskell features such as hs-plugins or Data.Generics or Data.Dynamic or phantoms or all of them or something else to work. - I haven't looked at the discussion, but a sophisticated Java solution could also try to score with dynamic class loading, reflection, perhaps even with compile-time reflection a la OpenJava. One would need to be prepared to cope with that ;-) - XML wasn't mentioned in your message. I wonder whether they discuss it in the actual thread. (Yes, you might be saying XML is not the same language as you are programming in, but it so easy to process XML in many languages, and one uses XSD for the DSL syntax). In fact, in Haskell I would strongly consider using HaXML or similar technology for non-trivial configuration problems. XML makes configuration also more portable. In reality, I don't see much value in using the programming language syntax for representing the configuration information. This makes it only harder to process those configurations with other tools. Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Yoel Jacobsen > Sent: Thursday, September 08, 2005 11:41 AM > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] Language Workbenches - the Haskell solution? > > I'm trying to create an _elegant_ solution in Haskell. > ... > Further, what is the type of the parser?

3 3

Where to start about writing web/HTTP apps ?
by gary ng 13 Sep '05

13 Sep '05

Hi, I just start learning haskell and have to say that it is stunning in how precise it can be(coming from a background of C then python/perl/js). I want to write apps for WEB and have briefly read WASH. However, that seems to be a CGI based solution. What I want is a native HTTP server(written in haskell), like Twisted/Cherrypy in Python. Are there any boilerplate(I know I should scrap the boilerplate but I need to have something to get start) for reference ? In addition, during my learning process, I keep on using my old experience as reference such as writing simple programs that needs functions like ltrim/rtrim/substr etc. that is in almost any language I have used. But it seems that haskell doesn't have it. I know that a haskell expert can write them in no time with things like dropWhile and reverse, it is a bit frustrating for new comers from a imperative background. Oh, while I am still here, I am reading "The Evolution of a Haskell Programmer" http://www.willamette.edu/~fruehr/haskell/evolution.html and learning the various way to tackle the same problem. Obviously, there are lots of things I don't know what it is about and I would tackle them as time go by. But I have problem even with the seems to be simple one like this : fac n = foldr (\x g n -> g (x*n)) id [1..n] 1 I can understand a foldl or foldr version but have problem with this, especially the "id" and the trailing "1" and the function being folded takes 3 parameters instead of 2(as in standard foldr/foldl solution). Would appreciate if someone can knock on my head and tell me what is going on in it. thanks for help in advance. regards, gary ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

7 10

Fwd: [Haskell-cafe] ghc for sunos
by Brian McQueen 12 Sep '05

12 Sep '05

---------- Forwarded message ---------- From: Brian McQueen <mcqueenorama(a)gmail.com> Date: Sep 9, 2005 9:14 AM Subject: Re: [Haskell-cafe] ghc for sunos To: Donald Bruce Stewart <dons(a)cse.unsw.edu.au> I installed it and its choking while looking for libreadline. I'm not an admin on these machines, so my options are limited. It seems to be a bit of an odd error msg though in that the search path looks wrong: ld.so.1: /users/bqueen/lib/ghc-6.2.2/ghc-6.2.2: fatal: libreadline.so.4: open failed: No such file or directory Why would the ghc dir be in there twice? Brian McQueen On 9/8/05, Donald Bruce Stewart <dons(a)cse.unsw.edu.au> wrote: > mcqueenorama: > > Is there a ghc for SunOS? I don't see on in the list. How hard would > > it be to make one? I'm surrounded by Sun boxes here. > > GHC runs on sparc/solaris and i386/solaris. Is that what you're looking > for? Have a look at the earlier 6.x releases for binaries for this OS. > > -- Don >

3 3

RE: [Haskell-cafe] Language Workbenches - the Haskell solution?
by Ralf Lammel 12 Sep '05

12 Sep '05

Yoann, Thanks for your comments. Yoann wrote: I don't think XML is a good idea for files that are managed/edited by humans. I think the users prefer simpler files with a custom syntax, and the user is the king. I don't mind, but when you say "user" do you mean "application configuration admin" or "plain application user". The former may know/like/dislike PL syntax, the latter may not like *anything* but very simple and foolproof formats or GUI-based configuration. There is no reason to believe that the latter wants to feel like programming in Haskell, Java, ... at least not in the universe I live in or that I observe. Yoann wrote: Of course the job of the programmer is easier when the file is coded in XML, ... This is unrelated to what I said. Perhaps my wording wasn't clear enough. I was trying to refer to the software life cycle and tool support as a whole. Doing software re-engineering for configurations that are formulated in a Turing-complete language is no fun. This is quite similar to the known issues with macros, when used for configuration; you may want to read about software asbestos here: http://homepages.cwi.nl/~ralf/am/ Yoann wrote: I am a programmer and personally I don't want to code my Haskell code in XML I didn't propose *that*. Anyway, picking up the new subject that you introduced accidentally, let me reply: you are not alone: most programmers don't like to code their PL code in XML. (As an aside, XML is used even for coding these days, just in case you don't know: check out some widely used AOP language extensions for Java. I am not saying whether I like this or not.) Yoann wrote: so I presume it is the same for the user with configuration files. So you presume that a user of application XYZ prefers to configure his/her application in the syntax of the underlying implementation language, supposing there is just one? That's a very interesting presumption. Have you any data to substantiate your presumption, or is that a prediction for the future? Yoann wrote: if your programming langage is lisp in which case parsing the configuration file is just a call to read. Sure! Sounds a bit like comparing apples and oranges. I can also parse my configuration file to "Data.Tree String" in Haskell, or something similarly weakly typed. Then parsing is just a call to read, too. (Lisp really doesn't score here.) So what's the point? I guess we won't be happy with that Haskell solution, or at least we would like to see whether we can score with Haskell in some way. Ralf

1 0

Monad, more than one of them ?
by gary ng 11 Sep '05

11 Sep '05

I am reading "Monads for functional programming" from http://homepages.inf.ed.ac.uk/wadler/topics/monads.html, which is IMO the best explanation of monad I have seen so far. What I would like to know is, what if I need more than one of them at the same time. Using the example given in the paper, it is quite comment that one would need exception handling, state management and output all at the same time. In an imperative language, one can do all three at the same time in the normal flow like wrapping a try/catch block, make some state changes to a global variable and make some io calls. How would one do it in a monadic way ? As my understanding of Monad is that it is something like a "wrapper/container" where the side-effect is kept. One way of doing it is of course expand it to include all three side effects. But this is unmanageable and it is no different than the non-monadic version mentioned in the paper. Another way I can see is to "wrap" one monad with another and so on. But this can also get complicated as what if I have 10 type of monads that can be permutated in various way. ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

3 2

RE: [Haskell] Monadification as a refactoring [was: Mixing monadicand non-monadic functions]
by Ralf Lammel 11 Sep '05

11 Sep '05

Frederik, [I am trying to drag this voluminous thread to cafe.] Jeremy Gibbons mentioned Martin Erwig and Deling Ren's paper on monadification. Very useful, indeed -- also with regard to the question you seem to ponder about; also see here for an early take on monadification, if you like http://homepages.cwi.nl/~ralf/sfp99/ and more recently, an interesting use case for it: http://homepages.cwi.nl/~ralf/foal03/ I disagree with you: Monadification transformations are certainly reversible. I *do* realize that you were not talking about plain reversibility but rather "a refactorization should have an inverse which commutes with simple edits". Let's talk about plain reversibility first. So you go from a non-monadic program to a monadic program. What monad do you choose initially? You use the identity monad, at least conceptually. (Making the monadic parametric, if intended, can be seen as an extra generalization step. To use such a generalized program, you would still need to commit to a specific monad eventually at a higher level of the program. So for simplicity it makes sense to start from a monadified program that uses the identity monad. A single monadification refactoring is not enough anyhow, if you care about monad-related program edits in a broader scope. You would also need extra refactorings and refinements for extending and reducing the monad through symbolic monad transformations and a few others, I presume.) Inlining the identity monad operations plus some bits of beta reduction get you back to the original program. (There are some subtle technical issues. For instance, getting rid of a monad, even if it is not used through actions, may still be difficult due to strictness/bottom lifting issues. See such details in Martin's paper.) How do go beyond plain reversibility for monadification? Your examples of refactorings were not fair. They did not admit that undoing refactorings *after program edits* is a problem for *many* established refactorings. Monadification is not really special in so far. (It is perhaps special in so far that it is generally a rather involved refactoring, compared to extract/inline method.) You mention (i) "extract function" followed by (ii) "edit function" followed by (iii) "inline function". (iii) is the inverse refactoring for (i). Now try this (iii), (ii') edit inlined code, (i). How do you know what to extract in the last step? How do you know where to extract (if you changed only n out of m inlining locations)? AND SO ON. These are all not insurmountable problems but they are quite similar to the "challenges" you run into once you want to inverse monadification. *As long as we keep the notion of "edits" vague, as you did, it shouldn't be surprising that reversibility after edits is not clear either.* Obviously, some edits can be handled by de-monadification. As long as the edits do not start to commit to monadic style by means of engaging into a specific non-identity monad *and* using monadic actions, then it is safe to exclude monadic style again. (Making this precise and really *safe* is difficult enough.) But even once you start to use commit/engage, after monadification, there are ways to eliminate it again on the basis of special treatments per monad. (Think of refactorings that extract or inline monadic style for specific monads; for instance state passing through extra argument and result components.) Also, you may reduce the amount of monadic style. HaRe efforts are addressing some concepts like this, I guess. Ralf > -----Original Message----- > From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Frederik Eaton > Sent: Saturday, September 10, 2005 4:25 PM > To: Claus Reinke > Cc: haskell(a)haskell.org > Subject: Re: [Haskell] Monadification as a refactoring [was: Mixing > monadicand non-monadic functions] > > On Sat, Sep 10, 2005 at 12:55:15AM +0100, Claus Reinke wrote: > > life is funny, isn't it? so many people so eagerly > > lazily, in my case > > > discussing conversion between non-monadic and monadic code, > > I'm trying to discuss a new syntax, not code transformations. I agree > that the two are related. I'm interested in the latter, but I don't > understand it very well. I think of refactoring as an operation that > takes source code to source code, i.e. unlike most operations done on > source code, refactoring produces output which is meant to be edited > by humans. Is this correct? But if it is, doesn't it mean that one > would like refactorizations to have some ill-defined "reversibility" > property: > > a refactorization should have an inverse which commutes with simple > edits > > For instance, if I (a) rename a variable, and then (b) introduce a new > reference to the renamed variable somewhere, I can later decide to > change the name back, reverting (a), without losing the work I did in > the meantime in (b). I can do this by applying another rename > operation, which will also affect the new reference. > > Or, if I (a) take a bit of code and remove it to a separate function, > and then (b) modify the body of that function, I can later decide to > inline the function back into the one place which calls it, thus > reverting (a), without losing the modification done in (b). > > Yet, I don't see how the "monadification" operations you propose could > have this property. They are certainly code transformations! But they > seem irreversible - once I (a) apply your transformations and (b) edit > the output, I can't revert (a) without losing the work done in (b). > Changes to the code become tightly coupled, design becomes less > tractable. > > > yet when we asked for your opinions and suggestions on this very > > topic only a short while ago, we got a total of 4 (four) replies - > > all quite useful, mind you, so we were grateful, but still one > > wonders.. we might have assumed that not many people cared after > > all: > > > > http://www.haskell.org//pipermail/haskell/2005-March/015557.html > > It might have been more useful to ask for survey replies to be sent to > the list. Often the various opinions of a large number of people can > be compressed to a few representative positions. But if respondents > can't see what opinions have been expressed so far, then this > time-saving compression becomes impossible. That is just my opinion. > > > shall I assume that all participants in this discussion have joined > > the Haskell parade since then, and have proceeded rapidly to the > > problems of monadic lifting?-) in which case I'd invite you to have > > a look at that survey and the papers mentioned. > > I should do that, yes! > > It's just that I was a bit late, having misplaced my trumpet. > > > > > I thought the easy answer would be to inject non-monadic values into > the > > > > monad (assuming one already rejiggered things to do automatic > lifting). > > > > I'd phrase it slightly differently: what (I think) one wants are > implicit coercions > > between monadic and non-monadic types of expressions, where the > coercions > > lift non-monadic values into the monad in question, while embedding > monadic > > computations in the current monad to get a non-monadic result if only > that is > > needed (although one might think of the latter as partially lifting the > operation > > that needs the non-monadic result). > > > > only I wouldn't want those implicit coercions to be introduced unless > > programmers explicitly ask for that (one usually only converts code from > > non-monadic to monadic once, and while the details of that step might > > be tiresome and in need of tool-support, the step itself should be > explicit > > - see my comment on (2) below). > > > > > Note that in (a), "pure" values are never used where monads are asked > > > for, only the other way around. > > > > that is probably where some would beg to differ - if you lift > operations, > > why not lift values as well? > > Oh, one should do both, I was just giving a case where value-lifting > didn't happen, as a counterexample to Aaron's viewpoint. > > > > I think that supporting syntax (a) for semantics (b) should be a > > > feature because: (1) it is (usually) obvious what (a) means; (2) it > > > eliminates the single-use variable 'v' - single-use variables like > > > this occur a lot in monadic Haskell code, and I think they make it > > > harder to read and write; (3) it would support the math-like syntax > > > that I presented in my original message. > > > > (1) "(usually) obvious" is tech-speak for "(perhaps) possible to > > figure out, though probably not uniquely determined"?-) > > > > when mathematicians abuse notation in the "obvious" way, > > there is usually an assumed context in which the intended > > abuses are clearly defined (if not, there is another context > > in which the "obvious" things will go unexpectedly awry). > > > > (2) the nice thing about Haskell is that it *distinguishes* between > > monadic and non-monadic computations, and between evaluation > > and execution of monadic computations. if you want everything > > mixed into one soup, ML might be your language of choice > > (http://portal.acm.org/citation.cfm?id=178047 , if I recall > correctly? > > see the paper discussed in > > http://lambda-the-ultimate.org/node/view/552 > > for one application that demonstrates the power/danger of such > > implicit monads). > > > > (3) using math-like syntax for lifted expressions is common practice > > in some families of Haskell-DSELs, eg. Conal Elliot's Fran. As John > > pointed out, the predefined class-hierarchy is not really helpful > > for such endeavours, but if one isn't picky, one may ignore classes > > not used.. the "trick" is to lift even constants, so when you get > > to applications, all components are already lifted, and lifting most > > arithmetic works out fine (Boolean operations are another matter). > > > > note, however, that the resulting language, while looking > > mathematically pure and permitting concise expression of complex > > circumstances, may not have the reasoning properties you expect.. > > At this point I think we have to look at more examples. I'm not > convinced that my position is right, but I'm not convinced that that > it is wrong either. I just think it's promising, based on my > experience. If I were a better person, and had more free time, I would > work on producing examples and working things out myself, and perhaps > write a paper or something. > > Of course, experienced people are disagreeing with me, so maybe I > should just accept their good judgment! In any case, I'm afraid I > don't have much more to contribute, beyond the idea itself. > > > > It might be hard to modify the type checker to get it to work, but I > > > think it is possible, and I see no reason not to be as general as > > > possible. > > > > here I'd agree, although in contrast to you, I'd be talking about a > > complex refactoring under programmer control, not about an implicitly > > invoked collection of coercions. I played with that idea after Martin > > Erwig visited our refactoring project in March, and got to a prototype > > type-coercion inference system for a very simple functional language, > > because I found the situation with various existing and, as Erwig/Ren > > pointed out, apparently unrelated monadification algorithms confusing. > > > > apart from the various styles of monadification, which we'd like > > to permit, and have the programmer select, e.g., by type annotations, > > there is the slight problem that there are an unbounded number of > > different monadifications (more if one wants to keep annotations to > > a minimum), so one needs a sensible bound (one that does not > > exclude any of the alternatives one might want). one also might > > want to be able to choose between the alternatives (or tune the > > system so that taking the first choice works out ok most of the > > time). oh, and it shouldn't be too inefficient, and it is really a pain > > to re-implement a type-system just to add a few coercion rules to > > it (which is why I haven't extended my mini fpl to Haskell yet..). > > Well, I've said a little about why I don't like irreversible > refactoring. I've been reading "Notes on the Synthesis of Form" by > Christopher Alexander, I think this has helped me understand the > process of design in more abstract terms, if you want a reference. > > I think the source code of a program should be as close to its initial > specification as possible. The goal should be to make it as easy to > read and modify as it was to write. However, if the design is spread > out over write/test/debug cycles, as is often the case in interpreted > languages such as perl; or refactor cycles, as you seem to be > proposing; then a lot of the decisions and rationales which determine > that design will not be visible in the final version of the code - > rather, they will be stored in the succession of modifications which > have been applied to create this final version. But these > modifications are, as it were, difficult to go back and modify. The > more a program is produced through a process of accretion or > evolution, the more tightly coupled various aspects of its design will > be, and the more difficult it will be to change any one of them. > > Even if most of the design decisions are good ones, eventually the > number of unfixable bad decisions will grow until continued > development of a particular component becomes untenable. This might > happen at a function level or a module level or a program level - but > in any case I think the development style in question should be > avoided where possible, and made avoidable where feasible. > > Frederik > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

How to debug GHC
by Monique Louise de Barros Monteiro 11 Sep '05

11 Sep '05

Hi, all, I'm developing a back end for GHC and I have the following problem: my program is throwing an "empty list exception" due to head [] and I need to compile GHC with -prof -auto-all in order to see the stack trace when running it with +RTS -xc -RTS. I changed the makefile but the option +RTS -xc -RTS was not recognized as an available RTS option Does anyone have any idea about how I can do that ? Thanks in advance, __________________________________________________ Monique Louise Monteiro Mestranda em Ciencia da Computacao Centro de Informatica - CIn - UFPE

14 21

[Announce] CabalFind 0.1
by Dimitry Golubovsky 10 Sep '05

10 Sep '05

Some time ago, I expressed an idea that certain search engines may be used to collect information about existing .cabal packages whose developers made them indexable by those engines. Finally, I have written an experimental library, CabalFind. The library provides a generalized interface to search engines, and also sample implementations for Google and Yahoo* I haven't set it up as a separate project, say, on SourceForge because I am not sure whether it is feasible to do so. Instead, I am suggesting that the developers of Haskell Library Infrastructure decide whether this library may serve as a basis for library infrastructure maintenance utilities. The library may be downloaded at darcs get http://www.golubovsky.org/repos/cabalfind/ or http://www.golubovsky.org/repos/cabalfind/cabalfind.tar.gz The .cabal file for the package is tailored for GHC 6.2.2. For use with 6.4, changes may be necessary, as the XML Toolbox for 6.4 no longer includes the HTTP module, so HTTP.cabal needs to be included in build-depends. More information provided at http://haskell.org/hawiki/CabalFind Any feedback is appreciated. Dimitry Golubovsky Middletown, CT ------ * Only these two search engines are found to be able to search by URI suffix (.cabal in our case); without this feature package search becomes very inefficient.

1 0