Re: [Haskell] installing streams library
On 5/20/06, Chad Scherrer <[EMAIL PROTECTED]> wrote: Thanks, Bulat. I'm looking forward to trying it out this weekend. Is there any indication what fast IO approach might work its way into the standard libraries? It would be nice for idiomatic Haskell to be really fast by default, and I'd love to be able to show off the language shootout implications to coworkers. Cabal doesn't seem obvious to me. Currently my uninformed point of view is that the whole thing is too complicated to be worth the benefit it provides. Since it generally seems popular, I'm guessing that means it's either much simpler than it seems, or else the benefit provided is just enormous. Can anyone point me to a sales pitch, or provide some motivation for me to RTFM? A quick sales pitch: usually you, the library user, can just type: ./runhaskell Setup.hs configure ./runhaskell Setup.hs build ./runhaskell Setup.hs install And it will Do The Right Thing(TM), which is nice. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] installing streams library
On 2006-05-20 at 12:00+0200 "Sebastian Sylvan" wrote: > A quick sales pitch: usually you, the library user, can just type: > > ./runhaskell Setup.hs configure > ./runhaskell Setup.hs build > ./runhaskell Setup.hs install > > And it will Do The Right Thing(TM), which is nice. This is something I've never understood about the current fashion. Make allows one to set up rules about what depends on what, so why can't we just arrange it so that someone who wants to install the thing just hast to type ./runhaskell Setup.hs install ? I'm aware that part of this process might require root privileges, and that it would be bad to do the rest of it as root, but there are ways around that, surely? Even if not, the first line ought to be unnecessary, since configure produces something that build depends upon. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Ambiguous type variable when using Data.Generic
Hello, I'm writing a function 'preProcess' that simplifies the AST that comes out of Language.Haskell.Parser.parseModule. Simplifying means rewriting infix applications to normal prefix applications (in both patterns and expressions), removing parentheses, rewriting guards to if-then-else expressions, etc.. At the moment I use Data.Generic to traverse the AST and apply simplification functions to the different values. Like this: --- preProcess :: HsModule -> HsModule preProcess = em simplifyRhs . em simplifyPat . em simplifyExp where em f = everywhere (mkT f) simplifyExp :: HsExp -> HsExp simplifyExp (HsInfixApp e1 op e2) = HsApp (HsApp (opToExp op) e1) e2 simplifyExp (HsLeftSection e op)= HsApp (opToExp op) e simplifyExp (HsRightSection op e) = HsApp (opToExp op) e simplifyExp (HsParen e) = e simplifyExp e = e opToExp (HsQVarOp name) = HsVar name opToExp (HsQConOp name) = HsCon name simplifyPat :: HsPat -> HsPat simplifyPat (HsPInfixApp p1 consName p2) = HsPApp consName [p1, p2] simplifyPat (HsPParen p) = p simplifyPat p = p simplifyRhs :: HsRhs -> HsRhs simplifyRhs (HsGuardedRhss rhss) = HsUnGuardedRhs $ makeIf rhss where makeIf :: [HsGuardedRhs] -> HsExp makeIf [] = nonExhaustivePatternError makeIf (HsGuardedRhs _ con exp : rhss) = HsIf con exp $ makeIf rhss nonExhaustivePatternError = HsApp (HsVar (UnQual (HsIdent "error"))) (HsLit (HsString "Non-exhaustive patterns")) simplifyRhs rhs = rhs --- This works, however I would like to have a single function 'simplify' that can be applied to different values in the AST. This calls for a class Simplify with instances for expressions, patterns, etc.: --- preProcess :: HsModule -> HsModule preProcess = everywhere (mkT simplify) class Simplify a where simplify :: a -> a instance Simplify HsExp where simplify (HsInfixApp e1 op e2) = HsApp (HsApp (opToExp op) e1) e2 simplify (HsLeftSection e op)= HsApp (opToExp op) e simplify (HsRightSection op e) = HsApp (opToExp op) e simplify (HsParen e) = e simplify e = e instance Simplify HsPat where simplify (HsPInfixApp p1 consName p2) = HsPApp consName [p1, p2] simplify (HsPParen p) = p simplify p = p instance Simplify HsRhs where simplify (HsGuardedRhss rhss) = HsUnGuardedRhs $ makeIf rhss where makeIf :: [HsGuardedRhs] -> HsExp makeIf [] = nonExhaustivePatternError makeIf (HsGuardedRhs _ con exp : rhss) = HsIf con exp $ makeIf rhss nonExhaustivePatternError = HsApp (HsVar (UnQual (HsIdent "error"))) (HsLit (HsString "Non-exhaustive patterns")) simplify rhs = rhs opToExp (HsQVarOp name) = HsVar name opToExp (HsQConOp name) = HsCon name --- However, compiling the above gives the following type error: Ambiguous type variable `b' in the constraints: `Typeable b' arising from use of `mkT' at Special.hs:145:25-27 `Simplify b' arising from use of `simplify' at Special.hs:145:29-36 Probable fix: add a type signature that fixes these type variable(s) How can I make this work? Greetings, Bas van Dijk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Ambiguous type variable when using Data.Generic
Hi Bas, I had a requirement to do something similar as part of one of my projects, essentially reduce full Haskell to a small and manageable subset. Unfortunately I think you'll find that this task is a lot bigger than you first realise, and in particular that case-of is probably the expression you want to reduce everything to - rather than if-then-else. case-of can represent pattern matches in a much more uniform way than if-then-else, which is just a case-of on a boolean. The way I went about this was by using Yhc -core [1] to generate a Core language. GHC also has a Core language, which has various differences to the Yhc generated Core, and may be more to your liking (or perhaps less). I would suggest you explore these avenues before trying to write your own simplifier. Thanks Neil [1] http://www.haskell.org/haskellwiki/Yhc/API/Core ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] installing streams library
On Saturday 20 May 2006 06:53 am, Jon Fairbairn wrote: > On 2006-05-20 at 12:00+0200 "Sebastian Sylvan" wrote: > > A quick sales pitch: usually you, the library user, can just type: > > > > ./runhaskell Setup.hs configure > > ./runhaskell Setup.hs build > > ./runhaskell Setup.hs install > > > > And it will Do The Right Thing(TM), which is nice. > > This is something I've never understood about the current > fashion. Make allows one to set up rules about what depends > on what, so why can't we just arrange it so that someone who > wants to install the thing just hast to type > > ./runhaskell Setup.hs install > > ? I'm aware that part of this process might require root > privileges, and that it would be bad to do the rest of it as > root, but there are ways around that, surely? Even if not, > the first line ought to be unnecessary, since configure > produces something that build depends upon. FWIW, it's almost identical to the incantation necessary for projects based on autotools, where it usually reads something like: ./configure make make install That means Cabal should fit nicely into package management systems that are used to dealing with autotools projects (Debian, Gentoo, bsd ports, darwinports, etc). > Jón Rob Dockins ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] installing streams library
Hi FWIW, it's almost identical to the incantation necessary for projects based on autotools, where it usually reads something like: ./configure make make install But sadly compared to Windows tools, where its just a case of "double click" this sounds a bit too complex. I am hoping that I can register Cabal with Windows in some way to automate this down to "double click" once more. Thanks Neil ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Registration open for IFL 2006, Budapest, Sep 4-6, 2006
SECOND ANNOUNCEMENT and CALL FOR PAPERS !!! REGISTRATION IS NOW OPEN !!! The registration site: http://www.inf.elte.hu/rendezvenyek/ifl/registration.htm ** * 18th International Symposium on * * Implementation and Application of Functional Languages * * IFL 2006 * ** * September 4-6, 2006 * * Budapest, Hungary* * http://plc.inf.elte.hu/ifl2006 * ** * Hosted by the * *Department of Programming Languages and Compilers of* *the Faculty of Informatics at Eotvos Lorand University * ** - IMPORTANT DATES - * July 30th 2006 Registration deadline * Aug 4th 2006 Submission deadline for draft proceedings * Oct 24th 2006 Submission deadline for post-refereeing process * Dec 8th 2006 Notification of acceptance/rejection * Jan 31th 2007 Camera-ready papers Scope and Topics The IFL workshops form a tradition that has lasted for nearly two decades. The aim of these workshops is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. They provide an open forum for researchers who wish to present and discuss new ideas and concepts, work in progress, preliminary results, etc. related primarily but not exclusively to the implementation and application of functional languages. IFL becomes symposium from 2006. Topics of interest include, but are not limited to: * language concepts * concurrent/parallel programming * type checking * concurrent/parallel program execution * compilation techniques * heap management * generic programming techniques * runtime profiling * (abstract) interpretation * performance measurements * automatic program generation * debugging and tracing * (abstract) machine architectures * verification * formal aspects * tools and programming techniques * array processing * demos of well working, useable tools and applications in functional languages Papers on applications demonstrating the suitability of novel ideas in any of the above areas and contributions on related theoretical work are also welcomed. The change of the workshop name adding the term "application", introduced in 2004, is to reflect the broader scope IFL has gained over recent years. Prospective authors are encouraged to submit papers to be published in the draft proceedings and to give presentations at the workshop. All contributions must be written in English, conform to the Springer-Verlag LNCS series format. Attendees at IFL'06 will have an opportunity to submit a revised version of their paper for post-workshop reviewing. Selected papers will be published by Springer Verlag in the well-known Lecture Notes in Computer Science (LNCS) Series, as has been a long-standing tradition for the IFL. Programme Committee Matthias Blume Toyota Technological Institute, Chicago, USA Zoran Budimac University of Novi Sad, Serbia Andrew Butterfield Trinity College Dublin, Ireland Ralf Hinze University of Bonn, Germany Zoltan Horvath Eotvos Lorand University, Budapest, Hungary (Chair) Tamas Kozsik Eotvos Lorand University, Budapest, Hungary Hans-Wolfgang LoidlLudwig-Maximilians-University Munich, Germany Rita LoogenPhilipps-University Marburg, Germany Frederic Loulergue University of Orleans, France Simon Marlow Microsoft Research, Cambridge, UK Marco Morazan Seton Hall University, New Jersey, USA Yolanda Ortega-Mallen University Complutense of Madrid, Spain Rinus Plasmeijer Radboud University Nijmegen, The Netherlands Jaroslav Poruban Technical University of Kosice, Slovakia Anna Soos Babes-Bolyai University, Cluj-Napoca, Romania Doaitse Swierstra Utrecht University, The Netherlands Peter Thiemann University of Freiburg, Germany German Vidal Technical University of Valencia, Spain Symposium Organization Zoltan Horvath, Viktoria Zsok Department of Programming Languages and Compilers Faculty of Informatics Eotvos Lorand University, Budapest, Hungary Further information Web-site: http://www.i
Re: [Haskell] Ambiguous type variable when using Data.Generic
On 5/20/06, Bas van Dijk <[EMAIL PROTECTED]> wrote:
How can I make this work?
As far as I know, you can't. To see the problem, rewrite it using dictionaries:
data Simplify a = Simplify { simplify :: a -> a }
simplify_HsExp (HsInfixApp e1 op e2) = HsApp (HsApp (opToExp op) e1) e2
simplify_HsExp (HsLeftSection e op)= HsApp (opToExp op) e
simplify_HsExp (HsRightSection op e) = HsApp (opToExp op) e
simplify_HsExp (HsParen e) = e
simplify_HsExp e = e
Simplify_HsExp = Simplify simplify_HsExp
etc.
You will end up with a bunch of Simplify_* objects. Now in the application:
preProcess = everywhere (mkT simplify)
how do you convert this? If you use (mkT (simplify ...)), you're
fixing simplify to only one type. If you use (mkT simplify), you get a
type error.
GHC is telling you that you need to tell it which instance of simplify
to use. In your example, you can use:
everywhere (mkT (simplify :: HsExp -> HsExp))
. everywhere (mkT (simplify :: HsPat -> HsPat))
. everywhere (mkT (simplify :: HsRhs -> HsRhs))
Of course, that's not any simpler.
--
Taral <[EMAIL PROTECTED]>
"You can't prove anything."
-- Gödel's Incompetence Theorem
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Ambiguous type variable when using Data.Generic
On 5/20/06, Bas van Dijk <[EMAIL PROTECTED]> wrote: simplifyExp (HsLeftSection e op)= HsApp (opToExp op) e simplifyExp (HsRightSection op e) = HsApp (opToExp op) e By the way, I think this looks wrong. One of these needs to create a lambda expression. -- Taral <[EMAIL PROTECTED]> "You can't prove anything." -- Gödel's Incompetence Theorem ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] installing streams library
On 2006-05-20 at 11:58EDT Robert Dockins wrote: > On Saturday 20 May 2006 06:53 am, Jon Fairbairn wrote: > > Make allows one to set up rules about what depends > > on what, so why can't we just arrange it so that someone who > > wants to install the thing just hast to type > > > > ./runhaskell Setup.hs install > > > FWIW, it's almost identical to the incantation necessary > for projects based on autotools, where it usually reads > something like: > > ./configure > make > make install I know. That's the fashion I'm complaining about! I think we shouldn't follow it if we can possibly avoid it. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] installing streams library
Neil Mitchell wrote: Hi FWIW, it's almost identical to the incantation necessary for projects based on autotools, where it usually reads something like: ./configure make make install But sadly compared to Windows tools, where its just a case of "double click" this sounds a bit too complex. I am hoping that I can register Cabal with Windows in some way to automate this down to "double click" once more. It's strange that with the most advanced programming language in existence we're still unable to automate the task of having to manually type a sequence of 3 commands at an ancient UNIX command prompt!!! :-) Regards, Brian. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Ambiguous type variable when using Data.Generic
Bas, There is a really easy (and intended) way to make this work. See Sec. 6.4 SYB1 paper (TLDI 2003). - You compose things as follows: simplify = id `extT` simplifyRhs `extT` simplifyExp `extT` ... - You apply everything right away to simplify. There is no need to use a class in your case. However, if you really want to you need to apply the pattern from the SYB3 paper. BTW, simplifications are often not of the kind that non-descending step functions and recursion by everything does the right thing. Often you need a more powerful schemes such as bottom-up innermost normalization (some variation thereof). Please see the Stratego and Strafunski literature for this purpose. Best, Ralf > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Bas van Dijk > Sent: Saturday, May 20, 2006 7:50 AM > To: haskell@haskell.org > Subject: [Haskell] Ambiguous type variable when using Data.Generic > > Hello, > > I'm writing a function 'preProcess' that simplifies the AST that comes out > of > Language.Haskell.Parser.parseModule. Simplifying means rewriting infix > applications to normal prefix applications (in both patterns and > expressions), removing parentheses, rewriting guards to if-then-else > expressions, etc.. > > At the moment I use Data.Generic to traverse the AST and apply > simplification > functions to the different values. Like this: > > -- > - > preProcess :: HsModule -> HsModule > preProcess = em simplifyRhs . em simplifyPat . em simplifyExp > where > em f = everywhere (mkT f) > > simplifyExp :: HsExp -> HsExp > simplifyExp (HsInfixApp e1 op e2) = HsApp (HsApp (opToExp op) e1) e2 > simplifyExp (HsLeftSection e op)= HsApp (opToExp op) e > simplifyExp (HsRightSection op e) = HsApp (opToExp op) e > simplifyExp (HsParen e) = e > simplifyExp e = e > > opToExp (HsQVarOp name) = HsVar name > opToExp (HsQConOp name) = HsCon name > > simplifyPat :: HsPat -> HsPat > simplifyPat (HsPInfixApp p1 consName p2) = HsPApp consName [p1, p2] > simplifyPat (HsPParen p) = p > simplifyPat p = p > > simplifyRhs :: HsRhs -> HsRhs > simplifyRhs (HsGuardedRhss rhss) = HsUnGuardedRhs $ makeIf rhss > where > makeIf :: [HsGuardedRhs] -> HsExp > makeIf [] = nonExhaustivePatternError > makeIf (HsGuardedRhs _ con exp : rhss) = > HsIf con exp $ makeIf rhss > > nonExhaustivePatternError = > HsApp (HsVar (UnQual (HsIdent "error"))) > (HsLit (HsString "Non-exhaustive patterns")) > > simplifyRhs rhs = rhs > -- > - > > This works, however I would like to have a single function 'simplify' that > can > be applied to different values in the AST. This calls for a class Simplify > with instances for expressions, patterns, etc.: > > -- > - > preProcess :: HsModule -> HsModule > preProcess = everywhere (mkT simplify) > > class Simplify a where > simplify :: a -> a > > instance Simplify HsExp where > simplify (HsInfixApp e1 op e2) = HsApp (HsApp (opToExp op) e1) e2 > simplify (HsLeftSection e op)= HsApp (opToExp op) e > simplify (HsRightSection op e) = HsApp (opToExp op) e > simplify (HsParen e) = e > simplify e = e > > instance Simplify HsPat where > simplify (HsPInfixApp p1 consName p2) = HsPApp consName [p1, p2] > simplify (HsPParen p) = p > simplify p = p > > instance Simplify HsRhs where > simplify (HsGuardedRhss rhss) = HsUnGuardedRhs $ makeIf rhss > where > makeIf :: [HsGuardedRhs] -> HsExp > makeIf [] = nonExhaustivePatternError > makeIf (HsGuardedRhs _ con exp : rhss) = > HsIf con exp $ makeIf rhss > > nonExhaustivePatternError = > HsApp (HsVar (UnQual (HsIdent "error"))) > (HsLit (HsString "Non-exhaustive patterns")) > > simplify rhs = rhs > > opToExp (HsQVarOp name) = HsVar name > opToExp (HsQConOp name) = HsCon name > -- > - > > However, compiling the above gives the following type error: > > Ambiguous type variable `b' in the constraints: > `Typeable b' arising from use of `mkT' at Special.hs:145:25-27 > `Simplify b' arising from use of `simplify' at Special.hs:145:29-36 > Probable fix: add a type signature that fixes these type variable(s) > > How can I make this work? > > Greetings, > > Bas van Dijk > __
