Haskell workshop?

I'd be interested.

Seconded.

I'd find a Haskell workshop very interesting.

I would be interested, too.

im 100% totally in. ill even send you cookies when the workshop is over.

I like the sound of it.

I'm pretty comfortable with Haskell... I'd be willing to help out in any way I can.

Quote:

Original post by Sneftel I'm pretty comfortable with Haskell... I'd be willing to help out in any way I can.

Have you ever written a game in Haskell? Because that's what this workshop should aim for in my opinion :)

I did. It wasn't a fun or interesting game, though.

Quote:

Original post by Sneftel I'm pretty comfortable with Haskell...

May I suggest you write the chapter about monads, then? ;)

Quote:

Original post by DevFred Quote: Original post by Sneftel I'm pretty comfortable with Haskell... I'd be willing to help out in any way I can. Have you ever written a game in Haskell? Because that's what this workshop should aim for in my opinion :)

I wrote most of the code for a game last semester called Raincat that was written in Haskell. Would you be interested if I put the sourcecode up somewhere?

Nice. A few comments on the solutions:

1) Haskell has very nice pattern matching; it's un-haskellic to manually destructure with car and cons where you can destructure by pattern match. For example, a more idiomatic version of the "second" function in the solutions would be:

second :: [a] -> asecond (_:b:_) = b

The nice thing about pattern matching is that the meaning jumps out immediately. Same point can be made about the other example functions: dispatch based on pattern match against arguments is preferred to manually writing conditionals that inspect the structure of the arguments.

2) Append: if a beginner is using append in a functional programming exercise, s/he's most probably doing something wrong. The myReverse function is an example of such wrongness: writing reverse in terms of append makes it run in O(n^2) time instead of O(n) time and requires an append function, when reverse can be expressed in terms of the primitive list operations (head and tail) to run in linear time.

Using append for reversing lists is the canonical 'bad way' of doing it, so I propose a different algorithm for the solutions pdf, and the exercise might expressly mention 'DON'T use append in your implementation of reverse'.

One simple way to reverse lists in linear time views them as stacks: the initially empty result stack and the initially full input stack. You just pop elements off the input stack and push them onto the result stack until the input stack is empty: then you return the result stack, which contains the elements in the input stack in reversed order.

Given that popping an element off a list and consing it onto a list are both constant time operations, this algorithm is linear in the number of elements in the list.

We use a helper function to keep the intermediate result stack hidden from the user, this is a very common pattern in functional programming:

myReverse :: [a] -> [a]myReverse l = myReverseHelper [] lmyReverseHelper stack [] = stackmyReverseHelper stack (x:xs) = myReverseHelper (x:stack) xs

Notice how convenient the pattern matching is for expressing (and understanding) the function.

Let's compare the two implementations: we can turn on timing and gc stats in ghci by running

:set +s

myReverse using append called on 1000 elements:

*Main> myReverse [1..1000]...(1.03 secs, 76339452 bytes)

myReverse without append:

*Main> myReverse [1..1000]...(0.02 secs, 1681708 bytes)

I would also be very interested in a Haskell workshop.

James Hague has a few articles on writing purely functional games. They aren't too long and are interesting to read. The first part is
http://prog21.dadgum.com/23.html

Why not use Yet Another Haskell Tutorial. It was the first haskell tutorial that made sense to me.

I'm quite comfortable with haskell, and I would like to help. The only games I developed in haskell was really small, but I used it in other programs and I have some experience in optimizing it.

Quote:

Original post by Daerax Why not use Yet Another Haskell Tutorial. It was the first haskell tutorial that made sense to me.

Yeah, writing my own introduction is probably overkill -- I just like doing it to gain a better understanding of Haskell and Latex :))

Quote:

Original post by DevFred The point of the PDF is not to show the best solutions from the start, but to begin with a very simple subset of the language and then show how other language features that are introduced later help to make programs more concise and efficient. The latest version already includes pattern matching, and I plan to introduce tail recursion in one of the next versions. Once again, thanks for the time you invested in reviewing my script, I appreciate it.

I read your tutorial and I think it's too superficial and chaotic. There are in fact several features used but not introduced (for example the if/then/else construct or functions of several variables) and some introduced but not used (for example type classes).

There are a lot of good haskell tutorials and I think it's probably better to use one of them.

I think the work you've put into the PDF document is wonderful, and it shows a lot of dedication. [smile] But unfortunately I too must cast my vote by saying that it's probably better to use something already written.

• Writing tutorials is a lot of work. It would distract heavily from actually running the workshop.


• First drafts of technical documents almost always have errors in them, often significant errors that could impede the understanding of one not familiar with the topic (i.e., the target audience in this case).


• There are many great sources available already on Haskell. You already mentioned Real World Haskell, which has been peer-reviewed by hundreds of people--in fact, their comments are all still viewable on the website. Daerax mentioned Yet Another Haskell Tutorial. There's my personal favorite Learn You a Haskell for Great Good!.

If you already had these written and peer-reviewed and thoroughly checked for errors, it would be different.

I guess you are right, let's use something that's already there.

So, what are the next steps? Is there a protocol for gamedev.net Workshops? :)