Re: [Haskell-cafe] Compiling an extremely large Haskell file (in GHC)
On 6/27/05, Arjun Guha [EMAIL PROTECTED] wrote: It's the all-pairs shortest paths data for a map of the Hyde Park area of Chicago (no real reason, really). I wonder: is there really no way to do Floyd-Warshall in Haskell? -- regards, radu http://rgrig.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why I Love Haskell In One Simple Example
Hi Mads, Since ghc-6.4 there's another feature that is enabled by such explicit foralls in type signatures, namely scoped type variables. Consider foo :: Num a = a - a - a foo x y = x + z where z = 2 * y Now since adding type signatures is a good thing, you want to give z an explicit type signature. But |z :: a| fails with an Inferred type is less polymorphic than expected error because the |a| actually means |forall a. a| and not the |a| from foo's type signature. The classical way (still, it's an extension implemented in hugs and all versions of ghc i'm aware of) to bring the in scope by binding it like this: foo (x :: a) y = x + y where This is fine in such simple examples, but often gets tedious and clutters up the definition by weird type annotations. Therefore ghc-6.4 implements the great feature that the |a| from foo's type signature is automatically brought into scope if you explicitely quantify it with a forall. Aside: A small disadvantage seems to be that you can only scope over either all or none of the type variables in your signature. However, foo :: forall a. Num a = (forall b. ...) will bring the variable a into scope, but not b and is otherwise equivalent to foo :: forall a b. Num a = ... On 6/27/05, Mads Lindstrøm [EMAIL PROTECTED] wrote: snip I had newer seen anybody use forall a. in function signatures before, and therefore was curious about its effect. This is probably do to my inexperience regarding Haskell. However, I tried to remove it and wrote this instead: test :: (Num a) = a and the code still compiled and seems to run fine. Also using the prettyShow and rpnShow functions. So, why are you using the forall keyword? (this is not meant as a critique, i am just curious) I tried to find documentation about the use of the forall keyword in respect to functions (I do know about it in with respect to existentially quantified types), but with no luck. So, if anybody has some good pointers, please let med know about it. A great recource is http://haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html Bookmark this page and come back to it every once in a while - there are just so many treasures in it - one of my favorites is 7.4.12. Generalised derived instances for newtypes Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New to Haskell, suggestions on code
Flavio Botelho wrote: At many places i have put a Char type instead of an abstract one because some funcations were not working properly before and i wanted to be able to output things and so be able to see what was the problem. (Haskell doesnt seem a 'magic' function to output arbitrary structures? That would be quite helpful for debugging) The show method in the Show class generates a string representation of an instance. The print function can be used to print the string representation of any instance of Show to stdout. All standard types except for functions are instances of Show, and Haskell can automatically derive Show instances for user defined types, provided that all of the constituent types are instances of Show. -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: GHC survey results
Re: Bulat's comments
1) adding OO-like features in O'Haskell style. for readers that don't
know it's about adding new variants to ADT types:
type Figure = Circle ...
type Figure |= Box ...
With ADTs you do pattern match on the constructor,
but in OO style guides (see Fowler: Refactoring)
you find that switch statements are considered bad design.
Instead you would use the Composite design pattern
interface Figure
class Circle implements Figure
class Box implements Figure
this lets you add classes easily. Sure this is more verbose
but it might be easier to maintain and extend.
(Yes I know that mathematically a free algebra is a nice thing.)
and adding new fields to existing records:
type Point = {x,y::Int}
type ColoredPoint = Point extended with {c::Color}
well I never would want to do that - and OO gurus do not recommend
it either. See Gamma et al, Design patterns, Introduction,
where they advise to use interface inheritance, but to avoid
implementation inheritance. This is exactly the situation
we have in Haskell.
Best regards,
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: GHC survey results
Bulat Ziganshin wrote: JW interface Figure JW class Circle implements Figure JW class Box implements Figure this don't give ability to create polymorphic collections You mean in Haskell? I would probably use existential types then. Something like data EFigure = forall f . Figure f = EFigure f and - as Georg Martius once pointed out - with an additional instance Figure EFigure ... to avoid at least some of the (un)boxing code. As a whole, this *does* look messy - Java programmers can nicely write the name of the interface when they mean some unspecified instance: Figure f = new Circle () ... Of course that's only so because their interfaces (type classes) are always unary predicates. I definitely would not give up multi parameter type classes from Haskell. But still the Java notation looks neat and concise. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: GHC survey results
On Tue, 28 Jun 2005, Bulat Ziganshin wrote: you are completely skipped the point that these is just for C++ programmers wanting to program in Haskell and aimed to give them faster learning path and easy to use instruments Not to forget to make learning easier for programmers of Perl, Ruby, Python, Rexx, Tcl, APL, C#, Java, Bash, Fortran, Pascal and so on by adding their most beloved features from their currently most beloved language ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: GHC survey results
you are completely skipped the point that these is just for C++ programmers wanting to program in Haskell and aimed to give them faster learning path and easy to use instruments Not to forget to make learning easier for programmers of Perl, Ruby, Python, Rexx, Tcl, APL, C#, Java, Bash, Fortran, Pascal and so on by adding their most beloved features from their currently most beloved language ... Please insert straight-face or sarcasm tags when making statements like this so we can know if you are joking or not ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: GHC survey results
On Tue, 28 Jun 2005, robert dockins wrote: you are completely skipped the point that these is just for C++ programmers wanting to program in Haskell and aimed to give them faster learning path and easy to use instruments Not to forget to make learning easier for programmers of Perl, Ruby, Python, Rexx, Tcl, APL, C#, Java, Bash, Fortran, Pascal and so on by adding their most beloved features from their currently most beloved language ... Please insert straight-face or sarcasm tags when making statements like this so we can know if you are joking or not ;) B-] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling an extremely large Haskell file (in GHC)
On Tue, 2005-06-28 at 12:11 +0300, Radu Grigore wrote: On 6/27/05, Arjun Guha [EMAIL PROTECTED] wrote: It's the all-pairs shortest paths data for a map of the Hyde Park area of Chicago (no real reason, really). I wonder: is there really no way to do Floyd-Warshall in Haskell? Indeed I understand from a colleague who implemented an all-pairs shortest paths algorithm in Haskell over the weekend for a map of the Hyde Park area of Chicago (no real reason, really!), that it takes about 0.1 seconds to execute (if you compile with -O), which is well within the 5 second limit... I wonder why everyone is so interested in the distances between intersections in the Hyde Park area of Chicago all of a sudden... http://icfpc.plt-scheme.org/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Yet Another Tool to Generate FFI Bindings: hsffig
On Sat, 2005-06-25 at 03:39 -0400, Dimitry Golubovsky wrote: I am pleased to announce the very first alpha release of the (yet another) FFI binding autogeneration tool. [...] http://www.golubovsky.org/repos/hsffig/ I will appreciate any feedback. You may be interested to know that there is a new C lexer and parser for c2hs (which is another excelent Haskell FFI preprocessor). The new lexer and parser were written to improve the parsing performance on large C headder files. It uses Alex and Happy and parses about 1Mb of C headers in two seconds (on a fast machine) using reasonably little heap space. If a GPL license is ok for you, you might be able to borrow/share the implementation. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling an extremely large Haskell file (in GHC)
Hi, On Wednesday 29 June 2005 10:05, Duncan Coutts wrote: On Tue, 2005-06-28 at 12:11 +0300, Radu Grigore wrote: On 6/27/05, Arjun Guha [EMAIL PROTECTED] wrote: It's the all-pairs shortest paths data for a map of the Hyde Park area of Chicago (no real reason, really). I wonder: is there really no way to do Floyd-Warshall in Haskell? Indeed I understand from a colleague who implemented an all-pairs shortest paths algorithm in Haskell over the weekend for a map of the Hyde Park area of Chicago (no real reason, really!), that it takes about 0.1 seconds to execute (if you compile with -O), which is well within the 5 second limit... you can just use dijkstra from the fgl (http://www.haskell.org/ghc/docs/latest/html/libraries/fgl/Data.Graph.Inductive.Query.SP.html) for the paths you are interested. We used it *a lot* and we didn't have any performance problems. There is really no need to precompute all-pairs shortest path! Cheers, Stefan -- Stefan Wehr Web: http://www.stefanwehr.de PGP: Key is available from pgp.mit.edu, ID 0B9F5CE4 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling an extremely large Haskell file (in GHC)
On Tue, 2005-06-28 at 20:13 -0400, Arjun Guha wrote: As a self-taught Haskell programmer of about a year, I'm really interested in seeing your colleague's code. I'd like to know what I did wrong. How about after two weeks? I think that's reasonable! I'm sure we'll publish our entry after the end of the second round, we did last year (http://urchin.earth.li/icfpcontest/2004/). However I would not expect it to be something beautiful to behold; code written in haste seldom is. In the meantime, try looking up the standard algorithms for all-pairs shortest paths. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling an extremely large Haskell file (in GHC)
On 6/29/05, Duncan Coutts [EMAIL PROTECTED] wrote: Indeed I understand from a colleague who implemented an all-pairs shortest paths algorithm in Haskell over the weekend for a map of the Hyde Park area of Chicago (no real reason, really!), that it takes about 0.1 seconds to execute (if you compile with -O), which is well within the 5 second limit... Well, that is about two times slower than c++ code :p ... I mean: it's way faster that what I would have expected :) Anyway, I am interested in how DP-like algorithms are implemented in Haskell (with the same complexities), not in this particular problem. A week ago I tried LCS, now the ICFP contest fed me with another algorithm that isn't trivial to implement in this language. For ICFPC you could use some other solution than Floyd-Warshall but, again, I am asking about _this_ particular algorithm. I wonder why everyone is so interested in the distances between intersections in the Hyde Park area of Chicago all of a sudden... You are right: I'll ask again in 2 weeks. So please don't answer to this post :) -- regards, radu http://rgrig.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
