Re: [Haskell-cafe] Web application framework comparison?
Hey Dave, You should check out this page (if you haven't already): http://haskell.org/haskellwiki/Web Cheers, Jasper On Sun, Sep 26, 2010 at 8:41 PM, Dave Hinton beaker...@googlemail.com wrote: There are 179 packages in the Web category on Hackage. It am finding it difficult, as someone who is not familiar with any of the Haskell web application frameworks on Hackage (and there seem to be at least 9), to determine which are good quality, which do things I would like a web framework to do for me, and which insist on doing things I would rather do myself. Is there a page comparing the major frameworks somewhere? I've been unable to find one via Google. ___ 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] A model theory question
Alexander Solla wrote: On 09/26/2010 01:32 PM, Patrick Browne wrote: Bigger how? Under logical implication and its computational analogue? That is to say, do you want the model to be more SPECIFIC, describing a smaller class of objects more richly (i.e, with more logical implications to be made) or do you want the model to be more GENERAL, and contain the less specific submodels? This is how forcing works. My idea of bigger is based on the import modes and parameterized modules of the Maude/CafeOBJ languages, where smaller theories are used to construct larger theories (and/or objects). In these languages I guess theories (loose specifications or interfaces) correspond to your *logical implication* and objects (or tight specification) correspond to *computation* at the ordinary programming level. The axioms of the theories must hold at the programming level. What does the term *forcing* mean? See: http://books.google.ie/books?id=Q0H-n4Wz2ssCpg=PA41lpg=PA41dq=model+expansion+cafeobjsource=blots=_vCFynLmcasig=07V6machOANGM0FTgPF5pcKRrrEhl=enei=YkSgTPn0OoqOjAfb0tWVDQsa=Xoi=book_resultct=resultresnum=1ved=0CBgQ6AEwAA#v=onepageq=model%20expansion%20cafeobjf=false Thanks, Pat This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Hackathon] BelHac: A Hackaton in Belgium, 5-7 November
I have just booked 5 beds in Hostel 47 in Ghent for our group. We will be staying in a 6-bed room, so there is still one bed available. If anyone is still looking for a bed in Ghent and wants to share a room with fellow Haskellers, that one bed might be an interesting choice. I told them we were there for BelHac, so if you mention that, they should be able to figure out which bed is meant. Groetjes, Martijn. On 7/20/10 15:44, Jasper Van der Jeugt wrote: We are very pleased to officially announce an international Hackaton/Get-together in Ghent, Belgium, on 5, 6 and 7 November 2010. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Candlestick charts
On 25/09/10 06:57, rgowka1 wrote: What are the libraries to use in Haskell to generate a stock candlestick chart like http://stockcharts.com/h-sc/ui?s=SPYp=Db=5g=5id=p05007254056 I will use Finance-Quote-Yahoo to get the quote data from Yahoo. The chart library: http://hackage.haskell.org/package/Chart doesn't currently have support for candlestick charts, but adding support would be straightforward - a patch would be most welcome (hint, hint!). Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help us test gtk2hs darcs!
Hi all, We have add many APIs in gtk2hs darcs, and ready to release gtk2hs-0.12.0 Please help us test gtk2hs darcs, we can fix it before release gtk2hs-0.12.0 You can get gtk2hs darcs with below command: darcs get code.haskell.org/gtk2hs Please send any bug report to gtk2hs-us...@lists.sourceforge.net Thanks! -- Gtk2hs Team ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
Alexander Solla schrieb: I used a modified version of the best practices described by the Perl people for Perl code. Like things go under like things is the most important rule to follow. This rule, in other words, is a convention to make your code as tabular as possible. Also, most expressions have an outermost connective. I tend to align them: Consider: data Foo a b = Fooa | Bar b | Foobar a b That's not so nice looking now, but consider what happens when you have four or five arguments: This indentation relies on Foo remaining Foo in the future. If you alter Foo then you have to move the block of constructors as well. This gives line changes in a versioning system where nothing actually has changed. The style data Foo a b = Fooa | Bar b | Foobar a b avoids this, at least for the type name Foo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
On Monday 27 September 2010 14:52:18, Henning Thielemann wrote: data Foo a b = Foo a | Bar b | Foobar a b avoids this, at least for the type name Foo. Tastes vary, but I find that ugly. I much rather have the '=' aligned with the '|'. data Foo a b = Foo a | Barb | Foobar a b deriving (Eq, Ord) There, that looks good. With the one exception that as a rule, in a multi-constructor type, none of the constructors should be identical to the type name (IMO). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Coding conventions for Haskell?
On 09/26/2010 09:41 PM, Alexander Solla wrote: Remember to treat values, functions, and monadic actions as servers that respond to your requests. This is the easiest way to maximize the value of Haskell's laziness. I haven't heard that one before. Could you give an example ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Coding conventions for Haskell?
On Mon, Sep 27, 2010 at 8:20 AM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On Sep 27, 2010, at 5:31 AM, Maciej Piechotka wrote: May I ask clarification about formatting (according to your convention) doSomething :: (a - a - a) - a - a - a doSomething f x = f y y where y = f x x i.e. single line function+where There is a meta-rule that I use for indentation in a wide range of languages: where the line breaks are may depend on identifier spelling, but what the indentation is should not. In Haskell I sometimes violate that, but I usually end up regretting it. +1 I use the same rule. My style looks like this. module Module where ( FancyType (..) , main ) data FancyType a b = FirstConstructor a | SecondConstructor b deriving (Show) f a b | a 0 = FisrtConstructor a | otherwise = SecondConstructor g where g = h b h = id main = do putStrLn hello putStrLn . concat [ hello , show (f 25 1) ] flip mapM_ [1..100] $ \n - do print n putStrLn hello where hello = Hello I allways use spaces without tabs and allways use camelCase. -- Victor Nazarov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
data Foo a b
= Foo a
| Bar b
| Foobar a b
deriving (Eq, Ord)
There, that looks good.
There is a trap if you do a similar thing with records:
data Foo = Foo
{ a :: Int
, b :: Int
}
If you use '-- |' style haddock it can't go on 'a'. Since I tend to
want to put '-- |' on every field, I have to put the '{' on the
previous line.
As for other stuff, I don't like the vertical lining up thing. It's
too much work to type in, causes too much realigning when the top line
changes, sometimes causes things to get too far right, and breaks
entirely with proportional fonts. A plain indent as advocated above
avoids all those problems.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HackageDB: Haddock parse failure
HackageDB reports a build failure for happy-meta-0.1.1 (http://hackage.haskell.org/package/happy-meta-0.1.1), but from the log it seems that the failure occurs when building the documentation. The error is src/LALR.lhs:230:2: parse error on input `numberSets' I'm guessing there is no syntax error in this file (it is taken from Happy), but rather an error in Haddock? Also, perhaps HackageDB should ignore errors in building the documentation? Currently the reported build failure propagates to the dependencies of the library... /J ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HackageDB: Haddock parse failure
On Mon, Sep 27, 2010 at 06:22:09PM +0200, Jonas Almström Duregård wrote: Also, perhaps HackageDB should ignore errors in building the documentation? Currently the reported build failure propagates to the dependencies of the library... The only reason it's building is to generate the documentation, and to do that you need the interface files haddock creates for the pre-requisite packages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why can't libraries/frameworks like wxHaskell/gtk2hs/... be used with newer versions of ghc/wxWidgets/GTK+/... ?
Why can't libraries/frameworks like wxHaskell/gtk2hs/... be used with newer versions of ghc/wxWidgets/GTK+/... ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
On Monday 27 September 2010 18:09:08, Evan Laforge wrote:
data Foo a b
= Foo a
| Bar b
| Foobar a b
deriving (Eq, Ord)
There, that looks good.
There is a trap if you do a similar thing with records:
data Foo = Foo
{ a :: Int
, b :: Int
}
If you use '-- |' style haddock it can't go on 'a'. Since I tend to
want to put '-- |' on every field, I have to put the '{' on the
previous line.
Hm, yes. I always use '-- ^' haddock comments for record fields, so that
didn't occur to me.
As for other stuff, I don't like the vertical lining up thing. It's
I haven't tried it yet. I think aligning corresponding fields has
advantages - it makes it rather obvious to see which constructor uses which
parameter types in many cases.
On the other hand, with many fields you get a very scattered picture if
some constructors only have few. That looks ugly and isn't easy to take in
at a glance.
I don't think I'll adopt it, but I plan to try it out.
too much work to type in, causes too much realigning when the top line
changes, sometimes causes things to get too far right,
Yep
and breaks entirely with proportional fonts.
Not relevant for me, when looking at Haskell or Python code, I value my
fixed-width font, it just looks too weird in proportional fonts.
A plain indent as advocated above avoids all those problems.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A model theory question
On 09/27/2010 12:25 AM, Patrick Browne wrote: Alexander Solla wrote: On 09/26/2010 01:32 PM, Patrick Browne wrote: / Bigger how? Under logical implication and its computational analogue? That is to say, do you want the model to be more SPECIFIC, describing a smaller class of objects more richly (i.e, with more logical implications to be made) or do you want the model to be more GENERAL, and contain the less specific submodels? This is how forcing works. My idea of bigger is based on the import modes and parameterized modules of the Maude/CafeOBJ languages, where smaller theories are used to construct larger theories (and/or objects). In these languages I guess theories (loose specifications or interfaces) correspond to your *logical implication* and objects (or tight specification) correspond to *computation* at the ordinary programming level. The axioms of the theories must hold at the programming level. Well, my question was more along the lines of do you want bigger (more specific) theories (and so more specific models to interpret them)? or do you want to generalize from a given theory? To do the latter with Haskell, you might create a module that allows exporting your axiom/interface functions. And maybe create a wrapper that drops axioms/interfaces/constraints. This is assuming you've organized your modules to embody specific theories (an assumption not usually true of my code, at least under this strict interpretation). To become more specific, you would just import the a module and add new axiom/interface functions. Doing similar constructions with type classes is possible. I think you might have to use witness types (or even a nice functorial wrapper around your target value in the original algebra, or both) to do generalizations of type classes. For example: class Uneditable obj where a :: a - obj b :: b - obj class Refactored obj witness where a' :: Maybe (a - obj) b' :: Maybe (a - obj) data EmptyFilter -- I think the name of the extension needed for this is 'EmptyDataDecls' data NoA data NoB instance Uneditable obj = Refactored obj EmptyFilter where a' = Just a; b' = Just b instance Uneditable obj = Refactored obj NoA where a' = Nothing; b' = Just b etc You would be using the Maybe part to switch functions/axioms on and off. The witness type links the obj type to the intended generalization of Uneditable. By the way, this is a decent example of forcing for types: given a type that satisfies a theory (that is, whose values are models for the theory), you generate a set of names which links the type to new theories that are related in a fairly obvious way (in this case, via Maybe). This represents an embedding of the new theory in the old theory. (And, dually, it represents an embedding of the old model in the new one) There's more to it than that, insofar as there is stuff to be proved. But Haskell does it for you. What does the term *forcing* mean? Forcing is a technique to create models from axiomatizations. It is the countable (and beyond) extension of creating a model by adding elements piecewise, assuming they satisfy the theory. Indeed, you end up using filters (the dual to an ideal) to ensure you get rid of all the elements that don't satisfy a model. The wikipedia page goes over some of this in term so of constructing a model in terms of a language over a theory for the model, and reinterpreting the new language in terms of the old one. http://en.wikipedia.org/wiki/Forcing_(mathematics) See: http://books.google.ie/books?id=Q0H-n4Wz2ssCpg=PA41lpg=PA41dq=model+expansion+cafeobjsource=blots=_vCFynLmcasig=07V6machOANGM0FTgPF5pcKRrrEhl=enei=YkSgTPn0OoqOjAfb0tWVDQsa=Xoi=book_resultct=resultresnum=1ved=0CBgQ6AEwAA#v=onepageq=model%20expansion%20cafeobjf=false From what I looked at, their logical notions/terminology are pretty standard. In general, if you want the class of models to decrease, you must make the class of theories for them increase (under inclusion order), and vice-versa. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why can't libraries/frameworks like wxHaskell/gtk2hs/... be used with newer versions of ghc/wxWidgets/GTK+/... ?
Hello caseyh, Monday, September 27, 2010, 9:55:14 PM, you wrote: Why can't libraries/frameworks like wxHaskell/gtk2hs/... be used with newer versions of ghc/wxWidgets/GTK+/... ? because you don't compile from source code. ghc does massive inlining so parts of old ghc libraries are compiled into gtk2hs object files -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
On 27/09/2010 02:44 PM, Daniel Fischer wrote: On Monday 27 September 2010 14:52:18, Henning Thielemann wrote: data Foo a b = Fooa | Bar b | Foobar a b avoids this, at least for the type name Foo. Tastes vary, but I find that ugly. I much rather have the '=' aligned with the '|'. data Foo a b = Foo a | Barb | Foobar a b deriving (Eq, Ord) There, that looks good. Tastes do indeed vary. To me, both of these are incorrect, and the correct way is data Foo a b = Fooa | Bar b | Foobar a b deriving (Eq, Ord) It honestly annoys me that Haddock disagrees with me on this point... (It also irritates me that almost all Haskell identifiers are camel-case, but with an inital lowercase letter. IMHO, the correct thing to do is use camel-case for identifiers that must begin with an uppercase letter, and underscores for identifiers that must begin with a lowercase letter. Of course, my opinion has no effect on the Prelude and so forth.) I generally try to structure my code so that all blocks indent by 2 spaces, and the size of indentation never depends on the length of an identifier. In other words, none of this: foo x y z = do thing1 x thing2 x y thing3 z ... Do that a few times and you rapidly end up with lines 300 characters wide. (!) Instead, I prefer foo x y z = do thing1 x thing2 x y thing3 z ... But, as they say, everybody has their own ideas about style. I think the most important point must surely be that any style is applied *consistently*... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
On Mon, Sep 27, 2010 at 22:57, Andrew Coppin andrewcop...@btinternet.com wrote: data Foo a b = Foo a | Bar b | Foobar a b deriving (Eq, Ord) It honestly annoys me that Haddock disagrees with me on this point... I disagree with you too, and so does your version control (if I'm wrong, please tell me, so I can switch). If you add a constructor, you have to make a change to the line containing the old last constructor, even though you didn't actually change that line. Also, either your pipes don't line up, or you violate your own rule I generally try to structure my code so that all blocks indent by 2 spaces, and the size of indentation never depends on the length of an identifier. ...except that the spaces here are not indentation. --Max (exhausted from real work, so taking some time out to paint the bikeshed) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
How do you guys indent long function arguments? I run into this all the time with the 'maybe' function which takes 3 arguments: maybe :: b - (a - b) - Maybe a - b I usually end up doing things like (pretend the arguments are aligned if you're not using a monospace font to view this): maybe do-if-Nothing (\x - do-if-Just x) maybe-value This gets a little unwieldly if the any of the arguments stretch over one line like: maybe do-if-Nothing (\x - ... ... something ) maybe-value Any advice on indentation? I could avoid the problem by adding a 'let' or 'where' but sometimes I like to show the entire function without the user having to scan another definition. -deech On Mon, Sep 27, 2010 at 3:57 PM, Andrew Coppin andrewcop...@btinternet.com wrote: On 27/09/2010 02:44 PM, Daniel Fischer wrote: On Monday 27 September 2010 14:52:18, Henning Thielemann wrote: data Foo a b = Foo a | Bar b | Foobar a b avoids this, at least for the type name Foo. Tastes vary, but I find that ugly. I much rather have the '=' aligned with the '|'. data Foo a b = Foo a | Bar b | Foobar a b deriving (Eq, Ord) There, that looks good. Tastes do indeed vary. To me, both of these are incorrect, and the correct way is data Foo a b = Foo a | Bar b | Foobar a b deriving (Eq, Ord) It honestly annoys me that Haddock disagrees with me on this point... (It also irritates me that almost all Haskell identifiers are camel-case, but with an inital lowercase letter. IMHO, the correct thing to do is use camel-case for identifiers that must begin with an uppercase letter, and underscores for identifiers that must begin with a lowercase letter. Of course, my opinion has no effect on the Prelude and so forth.) I generally try to structure my code so that all blocks indent by 2 spaces, and the size of indentation never depends on the length of an identifier. In other words, none of this: foo x y z = do thing1 x thing2 x y thing3 z ... Do that a few times and you rapidly end up with lines 300 characters wide. (!) Instead, I prefer foo x y z = do thing1 x thing2 x y thing3 z ... But, as they say, everybody has their own ideas about style. I think the most important point must surely be that any style is applied *consistently*... ___ 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] parsec manyTill documentation question
On Fri, Sep 24, 2010 at 9:28 PM, Evan Laforge qdun...@gmail.com wrote:
simpleComment = do{ string !--
; manyTill anyChar (try (string --))
}
Note the overlapping parsers anyChar and string !--, and
therefore the use of the try combinator.
First, I would have expected it to instead say:
Note the overlapping parsers anyChar and string --, ...
Yes, I think the doc just made a mistake there. In fact, it looks
like the same mistake is in the current doc at
http://hackage.haskell.org/packages/archive/parsec/3.1.0/doc/html/Text-Parsec-Combinator.html
Evan,
Thanks very much for the typo confirmation, the explanation about
backtracking below, and the tip about the source distribution for the
examples.
I need to remember that multiple char strings imply backtracking, and
that backtracking is not the default, hence try. Thanks.
-- Peter
Second, manyTill, by definition, keeps applying p (anyChar) until
end (string --) is satisfied, so I would expect one could just
write:
manyTill anyChar (string --)
The problem is that -- has multiple characters. So if you have
-not end comment, it will match the '-' against the (string --).
Since it doesn't backtrack by default, it's committed now and will
fail when it hits the 'n'. The 'try' will make it backtrack to
'anyChar' when the second '-' fails to match.
(If anyone knows of a collection of parsec demos or good examples, I
would appreciate a link; thanks)
I thought the parsec source included some example parsers for simple
languages? In any case, there is lots of material floating around,
though I found parsec so intuitive and the docs so good that I just
started hacking. I think the 'build scheme in haskell' tutorial uses
parsec for the parsing.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
I just see what Emacs Haskell mode suggests, and pick one of its suggestions. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
Evan Laforge qdun...@gmail.com writes: As for other stuff, I don't like the vertical lining up thing. It's too much work to type in, causes too much realigning when the top line changes, sometimes causes things to get too far right, and breaks entirely with proportional fonts. A plain indent as advocated above avoids all those problems. I'm going to go ahead and offer a contrary viewpoint -- lining up code vertically makes it so much easier to read that the extra work involved (trivial, if you have a half-decent text editor) is more than worth it. Also, if you're reading code in a proportional font, you're doing it wrong. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec manyTill documentation question
Stephen, Thanks much for the pointer to the examples in the sources; found them. (Its nice to learn from the coding style used by the authors.) -- Peter On Sat, Sep 25, 2010 at 12:34 AM, Stephen Tetley stephen.tet...@gmail.com wrote: On 25 September 2010 05:30, Evan Laforge qdun...@gmail.com wrote: I thought the parsec source included some example parsers for simple languages? In any case, there is lots of material floating around, [Snip] The best documentation is Daan Leijen's original manual, plus the original source distribution which has example parsers for Henk, Tiger and Mondrain. Both are available from here - the original poster was working with the HTML version of the manual - there is also a PDF version: http://legacy.cs.uu.nl/daan/parsec.html It would be nice if the Hackage package added the examples back into the distribution. The parser in the Scheme in 48 hours tutorial isn't a great example of Parsec as it doesn't use the Token module. Not using the Token module means the Scheme parser does hacky things such as parseNumber which uses /read/ - this is double work, Parsec already handles numbers, it doesn't need to call out to another parser (Haskell's builtin read). http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours/Parsing ___ 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] Coding conventions for Haskell?
On Mon, Sep 27, 2010 at 2:09 PM, aditya siram aditya.si...@gmail.com wrote: How do you guys indent long function arguments? I run into this all the time with the 'maybe' function which takes 3 arguments: maybe :: b - (a - b) - Maybe a - b I usually end up doing things like (pretend the arguments are aligned if you're not using a monospace font to view this): maybe do-if-Nothing (\x - do-if-Just x) maybe-value This gets a little unwieldly if the any of the arguments stretch over one line like: maybe do-if-Nothing (\x - ... ... something ) maybe-value I do basically like that only I don't try to line up vertically. One indent to continue a line, nested indent for a nested continued line. However, I tend to factor out the long values with let or where. I find it hard to read when everything is coming from some third argument which is a tiny nub at the end of a giant expression. And if you factor out the if just case, you can also more easily make the transition to monadic style if you find yourself with too many 'maybe's in sequence. If you can eta-reduce that last arg, though, it can be pretty: defaulted = maybe deflt $ \v - [ do ] stuff ... One place I do have difficulty is in pattern matching, because you can't factor that out as easily. I do use view patterns sometimes for that, but only when it's a common pattern. So I wind up with a nested indent: function too many arguments with (Complicated (Pattern matching)) = definition case x of Pattern (Match Is Way Too Long) - stuff It's ugly but rare. 'let' within a 'do' is a particular culprit because right off the bat you've got one indent for 'do' and then the 'let' forces two more indents. Sometimes the too many arguments can be factored into a single type, sometimes nasty nested pattern matches can be factored into view patterns or a data structure that reflects its access pattern rather than building pattern or whatever. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
On Mon, Sep 27, 2010 at 6:28 PM, Gregory Collins g...@gregorycollins.net wrote: Also, if you're reading code in a proportional font, you're doing it wrong. You may have nice codes using proportional fonts using LaTeX package 'listings'. Even in a proportional font it lines things up. Note, however, that you need to write *your* LaTeX source code in a fixed-width font for 'listings' to understand where things should be lined up. Unfortunately we don't have this mode in any editor as far as I know. And even if we did, I don't know how the same code would be viewed in another editor. Reading 'listings'-style LaTeX isn't funny, much less writing. Cheers! :) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
I'm going to go ahead and offer a contrary viewpoint -- lining up code vertically makes it so much easier to read that the extra work involved I haven't noticed it being easier to read, but I don't like syntax highlighting either, and lots of people seem to like that too. Taste is taste. (trivial, if you have a half-decent text editor) is more than worth it. Also, if you're reading code in a proportional font, you're doing it wrong. The editor is 'acme', which a programming editor. It has support for fixed fonts too, but proportional is often more pleasant. You can fit a lot more on a line, but of course that can inconvenience the 80-column people :) It's worth a try if you haven't already. I think it's more than just half-decent, but it doesn't have any fancy vertical line up type features either. Anyway, it's definitely a minority use case, but that's a position haskellers should be used to :) And I admit I use a lot more fixed-width vim nowadays, so it's not a super big issue to me. But I do like it how everything looks nice when I occasionally do open up my project in acme because I miss some of its features. Vim and fixed width is especially ugly with unicode, so I'd think haskellers or agda-ists who appreciate a good pageful of cryptic math symbols to scare off the plebes would enjoy a nice proportional font using editor. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/27/10 17:07 , Max Rabkin wrote: On Mon, Sep 27, 2010 at 22:57, Andrew Coppin andrewcop...@btinternet.com wrote: data Foo a b = Fooa | Bar b | Foobar a b deriving (Eq, Ord) Also, either your pipes don't line up, or you violate your own rule They line up fine in a fixed width font. Programming in any indentation-sensitive language in a proportional font leads inevitably to use of tabs to make things line up properly, which leads directly to pain. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyhHNcACgkQIn7hlCsL25XKjwCgjlxdAK1RTimZhFb0nzyYo5lu pXAAoLKdcuZ7foV+uM0s9QtvabFopuJl =WCR4 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why can't libraries/frameworks like wxHaskell/gtk2hs/... be used with newer versions of ghc/wxWidgets/GTK+/... ?
On Mon, Sep 27, 2010 at 10:55, cas...@istar.ca wrote: Why can't libraries/frameworks like wxHaskell/gtk2hs/... be used with newer versions of ghc/wxWidgets/GTK+/... ? Haskell libraries statically link many parts of the Haskell runtime; you can't combine two libraries compiled with different versions of GHC. Any bindings (like wxHaskell or gtk2hs) should work fine with new versions of their original libraries, assuming upstream has maintained backwards compatibility. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help to create a function to calculate a n element moving average ??
On 27/09/2010, at 5:20 AM, rgowka1 wrote: Type signature would be Int - [Double] - [(Double,Double)] Any thoughts or ideas on how to calculate a n-element moving average of a list of Doubles? Let's say [1..10]::[Double] what is the function to calculate the average of the 3 elements? [(1,0),(2,0),(3,2),(4,3)] :: [(Double,Double)] moving_average3 (xs0 @ (_ : (xs1 @ (_ : xs2 = zipWith3 (\x y z - (x+y+z)/3) xs0 xs1 xs2 *Main moving_average3 [1..10] [2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0] The result is two elements shorter than the original, but that _is_ the definition of moving average after all. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Coding conventions for Haskell?
Quoth Brandon S Allbery KF8NH allb...@ece.cmu.edu, ... They line up fine in a fixed width font. Programming in any indentation-sensitive language in a proportional font leads inevitably to use of tabs to make things line up properly, which leads directly to pain. I haven't noticed urgent problems with indentation, per se. I'm not programming in proportional fonts, but of course when I look at this stuff here it's email, not a programming editor, and the fonts are proportional. Maybe I'm lucky with the fonts on my platform, but the indentation is fine. All I expect is that indentation levels compare correctly to themselves: i.e., any two lines indented to the same level are indented the same distance and indented to different levels they are indented an appropriately lesser or greater distance. (That's slightly less rigorous than Haskell's layout requires, though, isn't it? I'm not sure. If it does, anyway my personal coding style is not to depend on alignment for structure, but only relative indentation.) The present problem involves alignments that are superfluous to Haskell's indentation requirement. Vertical alignment past the indentation does indeed dictate use of fixed width fonts, for editor and all display media. Not nearly worth it in my opinion, but obviously some would disagree. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can't make a derived instance of `Typeable (A B)': `A' has arguments of kind other than `*'
There is added complication because there are two possible extensions that can derive that instance: either GeneralizedNewtypeDeriving or DerivingDataTypeable. I think the latter always wins (which makes sense, it's probably what you want). -- ryan On Fri, Sep 24, 2010 at 1:41 PM, Christopher Done chrisd...@googlemail.com wrote: On 24 September 2010 22:18, Christopher Done chrisd...@googlemail.com wrote: Can't make a derived instance of `Typeable (A Maybe)': `A' has arguments of kind other than `*' In the stand-alone deriving instance for `Typeable (A Maybe)' Nevermind, I figured it out. The arguments refer to the type constructor A. I'll think some more before posting a thread next time. Ciao! ___ 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] Coding conventions for Haskell?
Also, either your pipes don't line up, or you violate your own rule They line up fine in a fixed width font. Programming in any indentation-sensitive language in a proportional font leads inevitably to use of tabs to make things line up properly, which leads directly to pain. I write haskell and python in a proportional font and it hasn't yet let to tabs, so no pain so far :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
