- Haskell-Cafe - Haskell.org

Genetic programming Haskell
by Maurício 17 Aug '06

17 Aug '06

Hi, Does anyone know of a package for genetic programming for Haskell? I tried some links from Haskell wiki and some I found on google, and found many interesting papers, but none of them pointed to downloadable code. Does anyone know where can I find a good implementation (even an experimental one)? Thanks, Maurício

6 5

Re: map and fmap
by Duncan Coutts 15 Aug '06

15 Aug '06

On Tue, 2006-08-15 at 12:38 +0200, John Hughes wrote: > One thing I've observed repeatedly is that many students in later > years, who learned functional programming early, have a strong > impression that functional languages are only suitable for toy > programs. Of course, that's because in their first courses they only > SAW toy programs. But perhaps, they also moved on to Java as soon as > they started to build GUIs, and as a result have the impression that > you CAN'T build a GUI in the functional language they learned first. Yes, this was the same impression my colleagues had as undergraduates and it's the same thing I see in the students I now teach. > This is a very negative impression for students to have, and one that > is hard to combat because beginning undergraduates are sceptical to > functional languages from the word go: they "know" they really want to > learn C++ or Java, and wonder initially what we're playing at. > > I combat that--successfully--by showing them early on that Haskell > *is* a "real" programming language, in which one can build real > applications. I tell them about darcs, or whatever new application is > hot at the time. I show them how to build a GUI in wxHaskell--in the > fifth week of their university studies. Yay! I'm doing the same thing, the fifth week in their first term in their first year. Though I'm using Gtk2Hs of course :-) I don't make them build the GUI directly of course. I've got a practical where they do some list processing functions and we provide a GUI module which visualises what they've done. So while still teaching the basics I try to make it clear that that can do GUIs and do them easily and make them look attractive. This year I want to add an optional extension to go 3D, to visualise their stuff with singing dancing rotatey things. I managed to get the Gtk2Hs+HOpenGL stuff working by the end of the practical last year and had lots of students come over to say "wow!". So I'm looking forward to using it this year to motivate the students to do the optional sections of the practical. > I want them to be frustrated at how difficult GUI programming is when > they do it in Java (:-)! It works--some find it very hard, but many of > the good students go much further than my lectures and exercises, and > reappear in the third and fourth years as very expert and enthusiastic > Haskell programmers. This is the first year when people who did my Haskell GUI practical will go on to the OOP course which involves building a GUI in Java. I'll be interested to see how they think it compares. Duncan

1 0

Re: [Haskell-cafe] Re: Why Haskell?
by Johan Tibell 15 Aug '06

15 Aug '06

For me library support, for networking in particular, has been the major hurdle. It gets problematic when too many libraries are still marked as experimental and only partially implements the specification (e.g. protocol) that they are supposed to handle. Also after a quick look at the source for some common (networking) libraries I found a few too many calls to error to feel comfortable. It's not okay for a library to bring down my application behind my back, error should be reported even if this uglifies the code and interfaces. Furthermore I think that Haskell would benefit from moving some commonly used functionality such as HTTP, SQL and XML support into the standard libraries. I haven't seen any news about the progress of HaskellNet but I guess it could solve my problems. I really don't have much problems with tool support, speed and the like. I'm convinced it's a library (and library documentation!) thing. > As for the 'popularity' of Haskell, someone made the very common sense > remark that all successful languages have been promoted by some large > corporation. (Please note 'successful' stands for 'spread of use', not > 'quality' here.) If fp is to reach the mainstream, it will probably be > because of some centralized support from outside the academic world. > Maybe something like a 'Haskell Consortium' or 'Haskell Initiative' to > promote Haskell should be set up. An example could be the promotion of > SystemC for hardware and software co-design by the Open SystemC > Initiative www.systemc.org . Availability of an IEEE standard for > Haskell would also be a good thing for its acceptance, I think. Having someone pay a group of people to hack on Haskell implementations would indeed be desirable. Without knowing the details Ubuntu looks like a promising model. If we could just find a willing billionaire out there... Cheers, Johan

4 8

Where is "Typing Haskell in Haskell"?
by Ralf Lammel 15 Aug '06

15 Aug '06

Hi Mark, Cc Haskell-café, It seems the OGI links for THIH have gone dead. Is there any preferred download location for THIH these days? I couldn't spot anything. Thanks, Ralf

1 0

Why Exotic Languages Are Not Mainstream
by Johan Tibell 15 Aug '06

15 Aug '06

Haskell was mentioned in an article called "Why Exotic Languages Are Not Mainstream" on the blog defmacro.org the other day and I thought maybe someone would be interested (i.e. is procrastinating at work and need an excuse to do something else). Any comments? http://www.defmacro.org/ramblings/not-ready.html

12 20

Re: [Haskell-cafe] Compiling To C And Why Not Compiling To Java Or C#?
by Kaveh Shahbazian 15 Aug '06

15 Aug '06

I do not meant to compile Haskell to MSIL/JVM. I meant to compile Haskell to the Java or C# itself! And GHC will be there for a high performance language (but still O'Caml is better by the time). But Java proves that in enterprise solution, performance is a complex factor of many thing other than speed alone. I love high performance implementation like Haskell. But there must be a way to populize Haskell! Thanks

4 12

Can someone explain this typing restriction?
by Tim Walkenhorst 15 Aug '06

15 Aug '06

I've stumbled over the following (code *extremely* simplified): f :: Bool f = g 1 g :: Num a => a -> Bool g _ = f This results in the following error message (on GHC): Contexts differ in length When matching the contexts of the signatures for f :: Bool g :: forall a. (Num a) => a -> Bool The signature contexts in a mutually recursive group should all be identical A similar problem is described in: darcs.haskell.org/haskore/docs/Tutorial.pdf on page 128. My first question is: 1) Is there a name for this restriction: I can't clearly identify it as some case of Let-Bound Polymorphism or the monomorphism restriction. [http://www.cs.auckland.ac.nz/references/haskell/haskell-intro-html/pitfalls…] 2) What exactly is the problem with it? 3) What's the best workaround? I've first tried to add an abundance of explicit type-annotations like f = (g::Int->Bool) 1 to it, but it doesn't work. Then, I found a solution, but it's awkward: f :: Bool f = g f 1 g :: Num a => Bool -> a -> Bool g f _ = f As you may have guessed, the actual code is a bit more complicated than this. Basically I interpret a symbol in a syntax-tree which can belong to different type-classes. When doing that, other more general symbols must be evaluated. An indirect recursion (potentially) occurs... I hope this hasn't been done to death yet. If it has, please just answer question one so that I can read up on it... Thank you, Tim

5 9

Re: [Haskell] AJAX applications in Haskell
by Joel Björnson 14 Aug '06

14 Aug '06

2006/8/9, Pasqualino 'Titto' Assini <tittoassini(a)gmail.com>: > > Hi, > > Those among you who have an interest in AJAX-style web development - that > is > to say the development of web applications that run entirely into the > browser environment, calling back to the server back-end only to get raw > data -- will probably have noticed the recent appearance of the Google Web > Toolkit (http://code.google.com/webtoolkit) ... > Is anyone working on anything similar or that might be interested in such a > project? I am currently working on a Google Summer of Code project relating to some of this... The project is more or less bound to Haskell Server Pages ( http://www.cs.chalmers.se/~d00nibro/hsp/) enabling JavaScript code generation. The main difference compared to the Google Web Toolkit approach is that there are no special compiler magic added for compiling directly into JavaScript. Instead the compiled program, e.g. a cgi program generates the code (JavaScript/HTML/XML) at runtime. However, type safety is gained via an embedded language (HJScript) and a typed abstract representation of JavaScript in Haskell. For more info see http://www.dtek.chalmers.se/~bjornson/soc/ Regards, Joel

2 1

Re: [Haskell-cafe] A lazy question
by Mario Blazevic 14 Aug '06

14 Aug '06

> > sourceToSinkTransducer :: SourceTransducer x y -> SinkTransducer x y > > > > I can't find any way to implement the sourceToSinkTransducer function > > Indeed that cannot be done because it breaks referential transparency. > Ok, thanks for clarifying the reason. > Food for thought: > > You need some sort of side effects (I'm not quite sure which), so > it'd be interesting to try > > newtype Source m x = Source (m (x, Source x)) > newtype Sink m x = Sink (x -> m (Sink x)) > > where m is an appropriate monad. Will the continuation monad work? I'm not sure. I'm trying to find the minimal data types that will let me implement the higher-level combinators. So far, the best I've found is the CPS and the following declarations: data Source i r = Source {get :: Sink i r -> r} data Monoid r => Sink i r = Sink {put :: i -> Source i r -> r, close :: r} newtype Filter x y = Filter { transduce :: forall r. Monoid r => Source x r -> Sink y r -> r } newtype Splitter i = Splitter { split :: forall r. Monoid r => Source i r -> Sink i r -> Sink i r -> r } The 'close' function and result type 'r' are there because the streams are usually finite. The 'Source' type should really be declared as data Source i = Source {get :: forall r. Sink i r -> r} because sources should not depend the result type, but that caused a lot of problems with type checking: the two 'r's in Source and Sink declaration are not unified. I don't see a way to express my intention. Anyway, thanks again for the explanation of why it has to be this complicated.

1 0

A lazy question
by Mario Blazevic 14 Aug '06

14 Aug '06

I was hoping to use Haskell's laziness to implement some of the stuff from "Continuation and Transducer Composition" (http://www-static.cc.gatech.edu/~shivers/papers/fcoro.pdf) a bit more elegantly, without manually coding the coroutine logic in continuation-passing style. Unfortunately, I'm beginning to think there is no workaround. Here's the challenge in a simplified form: newtype Source x = Source (x, Source x) newtype Sink x = Sink (x -> Sink x) type SourceTransducer x y = Source x -> Source y type SinkTransducer x y = Sink y -> Sink x sourceToSinkTransducer :: SourceTransducer x y -> SinkTransducer x y I can't find any way to implement the sourceToSinkTransducer function and its inverse. This is disappointing, because SourceTransducer and SinkTransducer are obviously isomorphic and there are languages like Oz that can accomplish this. Tell me I'm missing something obvious?

2 1