[Haskell-cafe] Re: Getting my feet wet - not in Haskell though

[Joachim Durchholz]

Neil Mitchell schrieb:

Hi


(There's still no good introduction to Monads, for example. One that's
understandable for a programmer who knows his Dijkstra well but no
category theory. And a few other things.)


I grasped this one first time round:
http://haskell.org/haskellwiki/Monads_as_containers


That one escaped me.
Thanks.


And Haskell let's you serialise thunks just fine (use Yhc),


Yhc explicitly say "not production-ready" on the main page.
I hope to return to it when that notice is gone.

> but really

if thats what you want to do, I think you are going to suffer a lot in
the long run... I have written client/server app's before, the whole
point is you want to decide what computation gets performed on which
side, not leave it up to the vagaries of lazy evaluation to come up
with a random solution.


I'll indeed want to keep quite a strict tab on what gets computed where. 
However, I can foresee the time when I explicitly want a thunk passed 
around. And I need it now already for making snapshots of the 
simulation's state, which will most likely contain thunks (e.g. I like 
to work in infinite game universes, where the data "springs into 
existence" at the time when it's being looked at; with lazy evaluation, 
I could express that in a straightforward fashion as an infinite map 
from coordinates to game data, and without it, I have to use other 
techniques).



Haskell is fun, Haskell is good, but its not the right answer to every
question. Just have fun doing whatever you do :)


Thanks - I hope it will work out that way.
I have seen far too many fun projects turn into bad ones... (might as 
well have been my own fault, of course - we'll see).



If at the end you wrote up a little summary of your project, what you
used, how it went, what issues you ran into - then perhaps people can
tell you (with the benefit of hindsight) how Haskell might have been.


Um... I think you'll be able to tell which problems would have been 
non-problems in Haskell, but you probably won't be able to tell which 
non-problems would have been problems in Haskell. (I tend to do things 
differently than what's the established standard way of doing things. 
Which means I'm usually both very innovative and very frustrated...)


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Getting my feet wet - not in Haskell though

[Joachim Durchholz]

[EMAIL PROTECTED] schrieb:

Joachim Durchholz wrote:
I'll move on to the alternatives - Alice ML and/or Clean. Both can 
serialize without forcing lazy subexpressions.


I don't know about Clean, but with respect to Alice ML this is not 
correct: Alice ML uniformly blocks on futures upon pickling,

including lazy ones.


Bad enough, but not necessarily a showstopper: lazy data structures 
aren't idiomatic in ML (I just hope they aren't in Alice ML either).



Sometimes you may want to pickle lazy suspensions as such, but more
often it is not what you want. In particular, the suspension can
easily be larger than its result,


I'd say that in this case, the suspension should have been forced 
earlier. I.e. the problem is not in the pickling but in the suspension 
being larger than its result.
I'm entirely unsure how to determine when a suspension should be forced 
anway. The programmer could give hints, but that would probably break 
all kinds of abstraction barrier; and the system usually doesn't have 
enough information to decide when it should do it. Seems like one of 
those problems that generate lots of PhD papers...



and the closure may contain resources which cannot be pickled. If
such a suspension was produced by an abstraction you may even argue
that making contained resources observable partially breaks the 
abstraction.


Well, Alice ML doesn't serialize things that don't make sense outside 
the originating process (i.e. resources).
That's better than silently serializing a file handle and being 
surprised by that handle meaning an entirely different file after 
unpickling.
OTOH one could do even better. Simply unpickle a resource as a proxy for 
the original resource in the originating process. (If the process has 
died, assume that the resource was closed - the vast majority of 
resource types has a "closed/unusable" state anyway.)



To adhere to uniformity, strong abstraction, and the Principle of
Least Surprise, we thus chose to force lazy futures in Alice ML.


Well, I wouldn't have expected that pickling has an effect (other than 
wrapping the value up for transfer), so at least I would have been 
greatly surprised.
I even dislike to see something like that in a language that has side 
effects.

But you can't have everything anyway ;-)

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Getting my feet wet - not in Haskell though

[Joachim Durchholz]

Tomasz Zielonka schrieb:

On Fri, Dec 22, 2006 at 06:16:03PM +0100, Joachim Durchholz wrote:
* Forcing the expressions that get written out means that I cannot use 
lazy evaluation freely. In particular, if some library code returns a 
data structure that contains a lazy-infinite subexpression, serializing 
it would not terminate, and I'd have little chance of fixing that.


I fear that you may not have a good intuition about laziness and how it
is used in practical programming at this moment. Why not try and see if
there really is a problem?


Because I might end up having sunk several weeks of my time, just to 
find that there is a problem anyway.


Second reason: the restriction will warp my design style. I'll avoid 
putting infinite data structures in the game data - and that means I 
can't explore open-end strategies, I'll have to "program around" the issue.
For this reason, I'd rather wait until Haskell serializes thunks as a 
matter of course, and explore lazy programming fully, rather than trying 
it out now and have my style warped.


Now that the first serialization will destroy many of the advantages of 
laziness, I don't think I should try to wrestle with its disadvantages.


A common problem with laziness is the possibility of introducing space
leaks. That's when the program accumulates a big thunk which, if forced,
would reduce to a small and simple value. "Nobody" is interested in this
value now, so it is kept in a lazy, space inefficient form. A classic
example is a thunk like this (1+1+1+1+1+1+...)

One solution to this problem is "deepSeq" - forcing full evaluation of a
data structure. Naive serialisation performs this as a side-effect.

What I want to tell is that the "problem" you see here could just as well
be a *solution* to a different problem that you haven't considered yet -
space leaks!


I'm aware of this kind of problem.
However, hailing deepSeq as a solution before I even encounter the 
problem is just constraining the design space.
Besides, why use a lazy language at all if I can't use laziness anyway? 
Most of the data will be in the server, which will get serialized at 
some time.


I'll move on to the alternatives - Alice ML and/or Clean. Both can 
serialize without forcing lazy subexpressions.


I am pretty sure that with those solutions you will meet other problems
of the same caliber.


No FUD, please ;-)

And yes I know there are devils lurking in every language and 
environment. I'm pretty sure that Haskell has a few others to offer, too.
(There's still no good introduction to Monads, for example. One that's 
understandable for a programmer who knows his Dijkstra well but no 
category theory. And a few other things.)



What I propose is the following: keep Haskell as a possibility (with
one discovered problem), consider problems with those other
languages, then decide.


Exactly. The decision I made right now is just to explore another 
language. I'll be back and trying out Haskell after a while - though 
that probably won't before serialization didn't get serious.



There doesn't seem to be a perfect programming language.

This all said, I still don't think that Haskell or its execution 
environments are bad. They just don't fit my requirements, which are

A) I want to get my feet wet with an FPL (seriously, this time), and
B) I want to do a webserver application (I know the domain).


Haskell would play well with those requirements. I've created some web
applications in it, and I was delighted with the things I learned in the
process.

I am starting to suspect that you have a third requirement you haven't
told us about, like: C) I want to make profit ;-)


I won't deny that profit is on the agenda, but it's taking a back seat 
during the evaluation phase.
The situation is slightly different: I'm sick of PHP and want to make 
profit with something better ;-)


However, I admit there are additional requirements, too. I just didn't 
want to add too much noise explaining why I chose exactly that project 
for exactly this language.


The real hidden agenda is that I'd like to have to option to move away 
from browser-based stuff, toward client-server stuff. The ability to 
serialize arbitrary data between applications would be almost 
indispensable - you can program around the restriction, but then you get 
impedance mismatches *between Haskell applications*.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Getting my feet wet - not in Haskell though

[Joachim Durchholz]

OK, just to let everybody know why I'm dropping Haskell.

Basically, the reasoning is this:

* I want to write a process that doesn't terminate.
* Since the environment can and will enforce termination occasionally, 
the process must be able to write its state to some external storage 
("serialize it"; flat file or database doesn't make much of a difference).
In fact I'll want to serialize most of the program's state on a regular 
basis (say, once per day), just to safeguard against bugs and hardware 
crashes.
* In all Haskell implementations (with the exception of Yhc), there is 
no way to write out data without forcing unevaluated expressions inside. 
(Yhc isn't mature yet, so it's not an option currently.)
* Forcing the expressions that get written out means that I cannot use 
lazy evaluation freely. In particular, if some library code returns a 
data structure that contains a lazy-infinite subexpression, serializing 
it would not terminate, and I'd have little chance of fixing that.


Now that the first serialization will destroy many of the advantages of 
laziness, I don't think I should try to wrestle with its disadvantages.


I'll move on to the alternatives - Alice ML and/or Clean. Both can 
serialize without forcing lazy subexpressions.



This all said, I still don't think that Haskell or its execution 
environments are bad. They just don't fit my requirements, which are

A) I want to get my feet wet with an FPL (seriously, this time), and
B) I want to do a webserver application (I know the domain).

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: How to serialize thunks?

[Joachim Durchholz]

Tomasz Zielonka schrieb:

On Wed, Dec 20, 2006 at 11:03:42PM +0100, Joachim Durchholz wrote:
If yes: are there workarounds? I'd really like to be able to use 
infinite data structures in the data that I serialize.


There is an interesting technique thay allows you to serialize infinite,
lazy or functional values: don't try to describe how those values look,
but how they came to be.


Ah, that's an interesting approach that I haven't thought of.

What are its limits? Does it impose design constraints?

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Simon Peyton-Jones schrieb:

| One thing that might become a problem is that the "Scrap your
| boilerplate" approach seems to work only in GHC.

I don't think so. Other compilers might not support "deriving Data",
but you can always write the instance by hand.


How much boilerplate would be needed in that case?
As far as I understood the web site, it would be around a line of code 
per data type, independently of the number of HOFs that need to iterate 
over the data structures - is that correct?


I understand that Drift is a kind of preprocessor / code generator. 
Could it be used to generate the necessary boilerplate?


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: How to serialize thunks?

[Joachim Durchholz]

Krasimir Angelov schrieb:

All those libraries really force the data because they all are written
in Haskell. If you want to serialize thunks then you will need some
support from RTS.


Good to hear that my conjectures aren't too far from reality.

Does any Haskell implementation have that kind of RTS support?


The serialization of thunk requires to store a reference to procedure
for thunk evaluation. After that it is tricky to do the deseriazation
because you will have to dynamically link the thunk evaluation code.


Actually, I'd be happy if the deserializing program were required to 
contain the same code that serialized the thunk.
Technically, I think that could be achieved by generating checksums over 
a suitably normalized version of the source code. Or, for a 
bytecode-based RTS, one could simply store the bytecode for each thunk 
(with proper sharing, of course).



The program that do the serialization and the program that have to
read it aren't necessary one and the same program.


Indeed. There is little need to change data structures and have 
versioning unless the code that uses the data changes.



In this case the reading application should have some way to call
code from the writing application.


Yup. It may be kept in the old executable, or stored in the marshalled 
data (I think that's what Mozart/Oz is doing).



Another problem arises when you have to recompile the writing
application. After the recompilation the evaluation code for some
thunk may not exist any more. The solution that Clean is using is to
keep a copy of each executable after each compilation.


I wouldn't mind if I had to explicitly manage old versions of the code. 
I'll never have data that's more than one version old, and that can be 
managed using a simple script.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] How to serialize thunks?

[Joachim Durchholz]

I have skimmed the serialization libraries on haskell.org (NewBinary, 
SerTH, AltBinary, HsSyck, GenericSerialize).


I'm under the impression that these all force the data that they serialize.
Is that correct?
If yes: are there workarounds? I'd really like to be able to use 
infinite data structures in the data that I serialize.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Robert Dockins schrieb:


Let me just say here that what you are attempting to do sounds very 
difficult.  As I understand, you want to be able to serialize an entire 
application at some (predetermined / arbitrary?) point, change some of 
its code and/or data structures, de-serialize and run the thing 
afterwards.


Right.

Though it's not too far out of the ordinary. Haskell being a rather 
orthogonal language, I had hoped that I can "simply serialize" any data 
structure.


> Doing something like this without explicit language support

is going to be hard, especially in a fairly static language like Haskell.


Exactly.
I was intrigued when I found that libraries can do quite a lot 
serialization in Haskell - that gives Haskell an excellent rating in 
what could be called "aspect-orientedness".

It doesn't help to serialize functions values or thunks, though.

I would think Smalltalk, Erlang, or something from the Lisp/Scheme 
family would be more suitable for this sort of work (caveat, I have 
little experience with any of these languages). 


Erlang is actually on my list of potential alternatives. It has 
different advantages than Haskell, though, and right now, I'm willing to 
try Haskell.



Also, take a look here (http://lambda-the-ultimate.org/node/526) for
some related discussion.


I'm not sure whether that relates to my project. I let network 
connections be handled by Apache and FastCGI, so I'm leaving out a whole 
lot of library issues that hit that reported project really hard.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Ross Paterson schrieb:
It might be not feasible though. The papers mention that you can't 
serialize (well, actually unserialize) function values with it. For the 
envisioned update-through-marshalling process, this would prevent me 
from ever using function values in data that needs to be persistent, and 
that's quite a harsh restriction.


That's hard to avoid, unless you have a data representation of the
functions you're interested in.


I could encode functions by their name. I don't think that would scale 
to a large application with multiple developers, but it's not this kind 
of project anyway.
I'd be reluctant to accept that way if it means adding boilerplate code 
for every function that might ever be serialized. Since I'm planning to 
serialize an entire application, I fear that I'd need that boilerplate 
code for 90% of all functions, so even a single line of boilerplate 
might be too much.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Versioning

[Joachim Durchholz]

Neil Mitchell schrieb:

You seem to be describing SYB and not knowing it:
http://homepages.cwi.nl/~ralf/syb1/

That basically does exactly what you've requested, in terms of
traversing all items when only one matters.


Yup, that's exactly what I was looking for. Actually I had seen it a 
while ago, but didn't remember it now. Thanks.


One thing that might become a problem is that the "Scrap your 
boilerplate" approach seems to work only in GHC.
There's nothing wrong with GHC, but it sounds like I'm committing to a 
specific compiler right from the start. I'd like to keep the number of 
choices as high as possible... and besides, if the compiler gives me an 
error message, or the generated code does unexpected things, I'd like to 
have the possibility to cross-check with a different compiler.


So have other compilers picked up SYB support yet?

It might be not feasible though. The papers mention that you can't 
serialize (well, actually unserialize) function values with it. For the 
envisioned update-through-marshalling process, this would prevent me 
from ever using function values in data that needs to be persistent, and 
that's quite a harsh restriction.



That said, serialisation is still a hard problem - think long and
hard before picking a data format.


What would be the problems of choosing the wrong one?


With Yhc.Core I used Drift to derve Binary instances, keep a version
tag, and if the version tags mismatch refuse to load the data.


Links?

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Versioning

[Joachim Durchholz]

As written in my other post, I will need to update data structures that 
were marshalled to disk.


Now I'm wondering how to best prepare for the situation. E.g. one of the 
common situations is that a single data item gets replaced by a list of 
items.


Now assume that there's a SomeData type that's used across the game, and 
which gets incompatibly updated SomeData1 (say, instead of containing 
just a string it turns into a list of strings).
The update code would now have to unmarshall a blob of game data, 
traverse it to find all instances of SomeData, wrap them in a 
one-element list to turn them into SomeData1s, reconstruct the blob of 
game data with the SomeData1 items, and marshall the result back out to 
disk.
This sounds as if I'd have to write code for every single data type in 
the update program just to update a single data type. Is that true, or 
is there a way around this?


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Getting my feet wet - small browser game

[Joachim Durchholz]

Marc A. Ziegert schrieb:

software upgrades:
use Read/Show classes instead of Foreign.Marshal,


I'm having second thoughts here.
Wouldn't Show evaluate all thunks of the data Shown?
That would mean I couldn't use infinite data structures in data that 
goes out to disk.


I don't think this would be a strong restriction for the communication 
between simulation and satellites, but I'm pretty sure it would be for 
doing backups of the simulation. Unfortunately, doing simulation backups 
is also the area where versioning is probably the harder problem.


But I think I can work around that. I'd simply have to write a small 
upgrade program whenever data structures change, which unmarshalls using 
the old code and marshalls using the new code.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A suggestion for the next high profile Haskell project [Was: Re: What is a hacker?]

[Joachim Durchholz]

Seth Gordon schrieb:

Joachim Durchholz wrote:

Trying to fully evaluate an infinite data structure will result in
looping or memory exhaustion, and you have that possibilities in almost
all languages.

Yes, but I suspect that Haskell makes it easier to make that kind of bug.
Worse, it's easy to introduce this kind of bug: just pass a list
returned from function a to function b, not being aware that a may
return an infinite list and that b may do something with it that
requires that it's evaluated. In other words, this kind of bug can come
into existence during code integration... and the type system doesn't
warn you when you do it.


If you're worrying about some unexpected input causing a function never
to terminate, don't you also have to worry about some unexpected input
causing a function to become so glacially slow that from the user's
perspective, it *might as well* never terminate?


I'm not really talking about bad algorithms. I'd talking about 
integrating two innocent functions and getting a result that doesn't 
terminate.
That's a problem that doesn't exist in strict languages: feeding the 
output of one function into another function won't turn terminating 
functions into nonterminating ones.


However, you're right that composing functions might drastically change 
their performance - simply because the inner function may return data 
structures that are expensive to evaluate, and the outer function 
insists on evaluating them.
So, for a lazy language, nontermination is just one side of the coin, 
the other is unexpected performance effects.


OT3H this kind of problem may occur whenever you're passing around 
executable stuff, whether it's in the form of unevaluated lazy thunks, 
strict-language streams, or (to add the perspective from a non-FPL camp) 
passing around polymorphic objects that carry functions of unknown space 
and time complexity.

It's probably a question of how idiomatic code behaves.

OT4H I know how to annotate code with space and time complexities in a 
strict language.
I.e. a Sort typeclass should impose an O(N log N) complexity on the sort 
function, slower sorts don't really do what the programmer expects - and 
that's then a guarantee that callers of the sort function can build upon.
And while I have an in-principle approach for strict languages, I don't 
have one for lazy languages. Is there any literature on the subject?


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A suggestion for the next high profile Haskell project [Was: Re: What is a hacker?]

[Joachim Durchholz]

Tomasz Zielonka schrieb:

On Tue, Dec 19, 2006 at 12:52:17PM +0100, Joachim Durchholz wrote:

Tomasz Zielonka schrieb:

On Mon, Dec 18, 2006 at 12:14:36AM +0100, Joachim Durchholz wrote:
Haskell might be prone to denial-of-service attacks. E.g. sending it 
data that cause it to evaluate an infinite data structure.

That would be a bug in the implementation of an algorithm, not an
inherent Haskell problem.
In the same way one could argue that running over the end of an array in 
C is a bug in the implementation of an algorithm, not an inherent C problem.


But the C bug can cause vastly more unexpected things, and can often
be used by an attacker to run arbitrary code in your program.


I was purposefully saying "denial-of-service bugs". By their nature, 
bugs of this type are far less dangerous than code injection bugs. (They 
are also much more visible, of course.)


IOW it's the same kind of problem: a kind of bug that the language, by 
its very nature, allows.


Trying to fully evaluate an infinite data structure will result in
looping or memory exhaustion, and you have that possibilities in almost
all languages.


Yes, but I suspect that Haskell makes it easier to make that kind of bug.
Worse, it's easy to introduce this kind of bug: just pass a list 
returned from function a to function b, not being aware that a may 
return an infinite list and that b may do something with it that 
requires that it's evaluated. In other words, this kind of bug can come 
into existence during code integration... and the type system doesn't 
warn you when you do it.


potential for driving Haskell programs into nontermination by feeding 
them cleverly constructed inputs


But you agree that not all Haskell programs have this caveat? For
correct programs you would have to actually feed them an infinitely big
input to get nontermination.


No, not at all. You just need to construct an input that makes the first 
function return an infinite list and makes the second function force its 
evaluation.


It may be more difficult to construct such inputs.
Or code that has this kind of problem may be rare.

So this may be irrelevant, or highly relevant, depending on how often 
this happens in practice.
However, to find out how relevant this is, it's probably best to get 
some qualified feedback. E.g. by doing termination analysis on a 
reasonable sample of Haskell software and seeing how many of these 
return "will always terminate", "may not always terminate", "will not 
always terminate".



Some propose a variant of Haskell built on a strongly normalising
calculus to reduce the risk of inadvertent nontermination.


I don't know how restrictive that would be.
If it introduces restrictions, it may be more helpful to have code 
annotations (assertions in the form of preconditions and postconditions).


I'm not sure that this problem really exists. It's just a potential 
problem that's difficult to diagnose. In other words, this kind of 
problem won't get much notice until people start attacking Haskell code 
in earnest.


I think it's a similar kind of problem as the possibility of making an
imperative program enter an infinite loop.


Well, an infinite loop is usually a local thing.
Nontermination from laziness can be introduced by nonlocal interaction, 
and that's far more difficult to diagnose.
(Note that this is not an imperative-vs-functional issue, but a 
strict-vs-lazy issue.)


Still, I'd want to have the results of a strictness analysis attached to 
Haskell software.

Why? In case the strictness analyzer was buggy?
I'd be perfectly happy if that analysis were just a note saying "run ghc 
with such-and-these options and inspect the intermediate code for 
function foo to see that the strictness analyzer determined it will 
always terminate".


I think you are asking too much from the strictness analyzer.


Actually I was typing too quickly there - it would have to be a 
termination checker.
I know these things aren't easy. I'd like to have all sorts of 
properties checked for code - I'm hopelessly infected by my experience 
with preconditions and postconditions during my Eiffel years. They are 
an invaluable documentation tool, and they could be an invaluable 
verification tool.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Getting my feet wet - small browser game

[Joachim Durchholz]

Marc A. Ziegert schrieb:

Comments and suggestions welcome :-)

hi Joachim.

i have some suggestions:

apache:
use fastcgi instead of hacking an own http-server.




Ah, that's excellent. The server in question will have FastCGI installed 
anyway (actually fcgid, so I'll see what the incompatibilities are).



server: there are virtual linux servers out there, free to rent. some
of them are even cheaper than the power-usage of one's old pc (at
least compared to speed). if you intend to write a game for thousands
of users, who play it 24/7, then it may be comfortable to rent one. 
(friends of me rented one.)


I'm with a small webhosting company, so the server is there already :-)

Of course, if the game ever attracts thousands of players and CPU and 
RAM usage start to affect other web presences, it should move to its own 
dedicated server.



software upgrades:
use Read/Show classes instead of Foreign.Marshal,
and combine them with version counting data-structures:

[code]
data MyData = V1 String deriving (Show,Read)
read_v1 :: MyData -> String
-
data MyData = V1 String
| V2 [String] deriving (Show,Read) 
read_v1 :: MyData -> String

read_v2 :: MyData -> [String]
-
data MyData = V1 String
| V2 [String]
| V3 [(String,Int)] deriving (Show,Read) 
-- obsolete: read_v1 :: MyData -> String

read_v2 :: MyData -> [String]
read_v3 :: MyData -> [(String,Int)]
[/code]


I'll try that out and let everybody know how well that worked. Thanks.


i've thought about writing a browsergame in haskel, too;
but atm, i have no time for (writing) games.


I've known that feeling for quite a while :-)

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A suggestion for the next high profile Haskell project [Was: Re: What is a hacker?]

[Joachim Durchholz]

Tomasz Zielonka schrieb:

On Mon, Dec 18, 2006 at 12:14:36AM +0100, Joachim Durchholz wrote:

Magnus Therning schrieb:

There is of course the possibility that Haskell would bring a whole slew
of yet-to-be-determined security issues.  I doubt it will be worse than
C though.
Haskell might be prone to denial-of-service attacks. E.g. sending it 
data that cause it to evaluate an infinite data structure.


That would be a bug in the implementation of an algorithm, not an
inherent Haskell problem.


In the same way one could argue that running over the end of an array in 
C is a bug in the implementation of an algorithm, not an inherent C problem.
IOW it's the same kind of problem: a kind of bug that the language, by 
its very nature, allows.
The Haskell designers decided that the advantages (more flexibility in 
code reuse) outweighs the disadvantages (having bottom in every domain, 
potential for driving Haskell programs into nontermination by feeding 
them cleverly constructed inputs).


I'm not sure that this problem really exists. It's just a potential 
problem that's difficult to diagnose. In other words, this kind of 
problem won't get much notice until people start attacking Haskell code 
in earnest.
That's the reason why I'd like to see this kind of problem addressed 
before Haskell systems become both large and widely-used.


Still, I'd want to have the results of a strictness analysis attached to 
Haskell software.


Why? In case the strictness analyzer was buggy?


I'd be perfectly happy if that analysis were just a note saying "run ghc 
with such-and-these options and inspect the intermediate code for 
function foo to see that the strictness analyzer determined it will 
always terminate".

I'm after checkability, not after making life miserable for programmers :-)

Then again, avoiding global state and using a language with garbage 
collection, a strong type discipline and checked pointer dereferencing 
(say: Java, Ruby, Python, whatever) would probably go a far way towards 
safer software, even if it's not an FPL.


But implementing deeply mathematical concepts in a mathematically
oriented language (like Haskell) seems to be a better idea, if
only to make the implementation closer to specification.


The equational properties of Haskell expressions make programming easier.
I wouldn't expect them to help particularly for expressing mathematical 
concepts: for once, the bulk of GPG code is still about moving around 
and transforming data, not about mathematics; second, I'd expect that 
non-mathematical concepts benefit from equational reasoning just as much.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Getting my feet wet - small browser game

[Joachim Durchholz]

OK, after years of looking and discussing and doing HSoE exercises, I
have finally decided that Haskell is far enough into practical
usefulness that I should give it a try in a "real" project.

The basic idea is a browser game - this touches all the potentially hard
issues without miring me too deeply in target platform details.

I'd like to lay out my plans here and ask how they are going to work
out, and take advice.

THE PLAN

I'll start with
http://haskell.org/haskellwiki/How_to_write_a_Haskell_program and get a
toolchain together. I haven't decides which compiler (interpreter?) to
choose; I'll probably go for the one that give the least amount of trouble.

Next would be library selection. I'm willing to undergo some modest
amount of hassle here, since I don't expect all libraries that I need to 
be mature yet.


My preliminary plan is to split the application into a central world 
simulation process, and satellite processes that accept HTTP requests, 
feed them into the simulation, read back the results, and generate the 
response HTML.

The interface between simulation and satellite is:
* Satellites can read a snapshot of the game data.
* Satellites cannot directly write game data.
  What they can do is to post commands to a blackboard, which are marked
  as "no more updatable" as soon as the simulation starts executing
  them.

I expect the simulation and the satellites to be separate OS processes, 
so I'll need a way to marshall command and game data between processes.
The simulation will have to store its entire state to disk, too - in 
theory, it could run forever and never write to disk (and I don't need a 
database, too), but in practice, I have to plan for the occasional reboot.
Since the server will be running Apache for other purposes anyway, and I 
don't want to force the players to use a URL with a port number, I think 
I'll set up Apache so that it proxies game-related URLs to the Haskell 
software. I just hope that Apache doesn't incur much overhead in that mode.


I have no idea how to organize software upgrades. The satellites are 
easy, but how do I make sure that revision N+1 of the simulation can 
read the marshalled data from revision N?


The final software should be efficient. Ideally, the satellites are able 
to saturate the network card of today's typical cheap rootserver if the 
simulation is a no-op.

I have two data points for a "typical cheap rootserver":
* 100 MBit/s Ethernet, 256 MB RAM, 1.2 GHz Celeron (~3 years old)
* 1 GBit/s Ethernet, 1 GB RAM, 2.2 GHz Athlon (current)
Of course, not needing an RDBMS will give the system a head start 
efficiency-wise.



Comments and suggestions welcome :-)

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: A suggestion for the next high profile Haskell project [Was: Re: What is a hacker?]

[Joachim Durchholz]

Magnus Therning schrieb:

There is of course the possibility that Haskell would bring a whole slew
of yet-to-be-determined security issues.  I doubt it will be worse than
C though.


Haskell might be prone to denial-of-service attacks. E.g. sending it 
data that cause it to evaluate an infinite data structure.

Of course, any algorithm might run into an endless loop :-)
Still, I'd want to have the results of a strictness analysis attached to 
Haskell software.


That said, Haskell should be a *lot* more safe than C.
Denial-of-service is something that one should take active precautions 
against, but it's still a far cry from the code injection 
vulnerabilities that come with most C software...


Then again, avoiding global state and using a language with garbage 
collection, a strong type discipline and checked pointer dereferencing 
(say: Java, Ruby, Python, whatever) would probably go a far way towards 
safer software, even if it's not an FPL.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

John Meacham schrieb:

I think we need some sort of signal, to show that one means "I
understand why haskell doesn't allow this in general, but am interested
in a compiler specific trick or some theoretical background on the
issue" rather than "I am learning haskell and am somewhat confused due
to preconcieved notions fostered by my experience with other languages,
can someone help me?"


The usual answer to this kind of problem is splitting up the forums.
E.g. a haskell-learners list for those who should be saying "I'm 
learning Haskell", a haskell-tricks one for the more esoteric 
(high-level, whatyanameit) stuff. Possibly haskell-libraries for library 
announcements and questions of the form "where do I find the library for 
doing foobar".


Just my 2c. There may be better courses of action (or non-action).

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Re : Aim Of Haskell

[Joachim Durchholz]

minh thu schrieb:

With the arrival of Java, people get
used to have scores of libraries which are 'right there', just 'part'
of the java api.


Actually, the importance of libraries predates Java.
However, Java may have been the first language where writing the 
libraries was a conscious strategic decision.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Building the community

[Joachim Durchholz]

Cale Gibbard schrieb:

There are also lots of other reasons why growing too quickly and
gaining commercial users too quickly are double edged swords.
Personally, I'd like to see the Prelude undergo a few more iterations,
and it gets harder to change as more and more projects rely on it.
When it does change, the maintenance cost of old code goes up, and not
every project has an active maintainer.


This problem affects all libraries, not just the Prelude.
And it would be futile to hope that all of it will ever stabilize. There 
will always be new libraries that are too new to have stabilized yet, 
and that will always be an excuse for not "going commercial" (or, vice 
versa, not adopting Haskell in a commercial setting).


The only solution that I know is explicit version numbering: wxHaskell 
5.3.1 needs the Prelude 3.1.574, and there's a respository somewhere (on 
the net or locally or whatever) that will automatically deliver Prelude 
3.1.574 along with a requested wxHaskell 5.3.1.

Details can vary considerably, of course.

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Stack, Heap and GHC

[Joachim Durchholz]

Felix Breuer schrieb:

1) What precisely is a thunk?


That depends on the abstraction level.

At the evaluation level, it is an expression that has at least one 
unevaluated subexpression.


At the implementation level, it could be a direct representation of an 
expression graph (partly evaluated).
Or it could be a record containing a function pointer and a possibly 
empty series of parameter values, some of which may be thunks again.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Steve Downey schrieb:

The STL, however, brings a very applicative programming model into an
otherwise imperative language. And, it turns out that the template
language is a turing complete pure functional language, making
possible some very interesting type based metaprogramming.


AFAIK there's some limitation built into the template language (nesting 
depth or something) that makes the template language Turing-incomplete.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Tomasz Zielonka schrieb:

On Thu, Dec 14, 2006 at 09:56:57PM +0100, Joachim Durchholz wrote:

OK, there's the option of replacing working tools with hype.
It worked for C++, and it worked for Java.
Pity I don't have the slightest idea how to work up a hype for Haskell.


Who would want such a hype?
Why not simply start picking up fruits before the mainstream notices?
;-)


Because a mainstream language has more tools, more libraries, and an 
easier job search.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Tomasz Zielonka schrieb:

On Wed, Dec 13, 2006 at 12:17:08AM +0100, Joachim Durchholz wrote:

Haskell needs... bullet-proof compilers, all of this working right out
of the box. (I see that this all is being worked on.)


Come on, C++ got popular in spite of having NO bullet-proof, let alone
complete compilers.


OK, there's the option of replacing working tools with hype.
It worked for C++, and it worked for Java.
Pity I don't have the slightest idea how to work up a hype for Haskell.

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"

[Joachim Durchholz]

Ketil Malde schrieb:

I generally manage to absorb just enough to get by, but I think there
is a niche for a book (coupled to practical problems and complete
with excercises etc) that is waiting to be filled.


Agreed.
Something along the lines of "The Art of Functional Programming".

HSoE is great as a starting textbook. However, it just scratches the 
surfaces - and after that, trying to grok monads keeps you occupied for 
a year or longer, keeping you distracted from developing other skills 
(such as writing and reading point-free code, or developing an intuition 
for curried code, or digging into a combinator library).


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"

[Joachim Durchholz]

Arie Peterson schrieb:

He wrote the manuscript and it
was 'aus einem Guss' (casted as one).


The literal meaning of "aus einem Guss" is "cast all at once".
This has overtones of "it is seamless, has no internal structural bounds 
which may cause the final product to fracture under stress".


This is one of the highest praises that you can sing for software in 
German, so it's not an uncommon idiom in the field over here.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Benjamin Franksen schrieb:

Joachim Durchholz wrote:

These activities are among the major reasons why I'm finally prepared to
get my feet wet with Haskell after years of interested watching.
I'll probably fire off a set of newbie questions for my project, though
it might still take a few days to get them organized well enough to do
that (and to find the time for setting up the text).


Hi Jo!

Welcome to the club.


It remains to be seen what proportion of my contributions belongs to 
problem space and what belongs to solution space ;-P


> (I think I did my share, now and then, on c.l.f to keep
> up your interest... ;-)

Actually, I found out about Haskell-cafe only after comp.lang.haskell 
was set up - else I might have joined far earlier.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Kirsten Chevalier schrieb:

I think that it would serve this
community well if somebody was able to achieve a better understanding
of the social reasons why some programming languages are adopted and
some aren't. I think all of us already know that the reason isn't
"because some are better than others," but it might be time for
someone to go beyond that.


Actually, it's quite simple: following the ideology de jour and 
teaching-relevant support.


Teachers will teach what's mainstream ideology (I'm using "ideology" in 
a strictly neutral sense here).
Pascal was popular because teachers felt that structured programming 
should be taught to the masses, and you couldn't abuse goto in Pascal to 
make a program unstructured.
Later, universities shifted more towards "economic usefulness". Which 
made C (and, later, Java) much more interesting ideologically.


Teaching-relevant support means: readily available tools. I.e. 
compilers, debuggers, editor support, and all of this with campus 
licenses or open sourced.



I don't think that Haskell can compete on the ideological front right 
now. That domain is firmly in the area of C/C++/Java. Erlang isn't 
really winning here either, but it does have the advantage of being 
connected to success stories from Ericsson.
To really compete, Haskell needs what people like to call 
"industrial-strength": industrial-strength compilers, 
industrial-strength libraries, industrial-strength IDEs. In other words, 
seamless Eclipse and Visual Studio integration, heaps and heaps of 
libraries, and bullet-proof compilers, all of this working right out of 
the box. (I see that this all is being worked on.)


Teaching-relevant support is already in place, I think - there are 
several open-source interpreters and compilers available, and Haskell 
doesn't place an special requirements on editors, nor does it require a 
specialized environment (the bane of Smalltalk and Lisp).


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Andreas Rossberg schrieb:

Claus Reinke wrote:


but on the Pascal note: is there anything in Pascal that Haskell doesn't
provide, and improves on (nested procedures, procedure parameters,
distinguishing in and out parameters, types, ..)?


Subrange types, maybe? But I'm sure Oleg will show us that Haskell 
already has them. :-)


Assigning to subrange types often requires a runtime check, so they 
can't be that easily mapped. (Unless you wrap them in Maybe or 
Exception, which I'd consider cheating.)


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Claus Reinke schrieb:


but on the Pascal note: is there anything in Pascal that Haskell doesn't
provide, and improves on (nested procedures, procedure parameters,
distinguishing in and out parameters, types, ..)? it has been too long 
since my Pascal days, I don't remember..


Nothing that I'm aware of. You'd have to be careful which version of 
Pascal you mean, there were lots of dialects around.


In general, however, I'm not sure whether contrasting Haskell to Pascal 
is a fruitful exercise. Pascal and C are nearer to each other than 
Haskell is to either of them after all. (Type classes, anonymous 
functions, type inference, just to name the first three that occurred to 
me...)


apart from the communication problem of understanding Haskell as Pascal: 
if you're talking to someone who knows Pascal, it might not be

a bad idea to position Haskell as a drastically modernized version of
Pascal, to get the discussion of real merits going?


No, not at all.
IMHO.

I think that Haskell is a step ahead of OO. The connection is a bit 
tenuous, but if you carry the Liskov Substitution Principle to its 
logical consequence, you end up disallowing any semantic changes in 
subclasses... and that means you don't need interface subclassing at all.
And to implement those inhomogenous lists and iterators and whatnot, you 
show how you can do that in a functional language without the 
subclassing baggage.


... it might be useful to show how the design patterns from the 
Gang-of-Four book can be done in a functional language. And with less 
restrictions.
Such a side-by-side comparison might help convince library writers and 
system architects (and these are among the more important people to win 
over anyway).


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Joachim Durchholz schrieb:

Bulat Ziganshin schrieb:

Hello Joachim,

Monday, December 11, 2006, 12:01:42 PM, you wrote:


one particular thing that we still lack is something like book
"Haskell in real world"

We need a 'Dive into Haskell' book.



* It's easy to find the relevant information. [OPEN]


what i mean is to fix this problem. there is lot of Haskell information
that is spread over the air


Actually it's an overly difficult task,


Sorry, I meant to write "it's _not_ an overly difficult task".

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Bulat Ziganshin schrieb:

Hello Joachim,

Monday, December 11, 2006, 12:01:42 PM, you wrote:


one particular thing that we still lack is something like book
"Haskell in real world"

We need a 'Dive into Haskell' book.



* It's easy to find the relevant information. [OPEN]


what i mean is to fix this problem. there is lot of Haskell information
that is spread over the air


Actually it's an overly difficult task, and I see this being addressed. 
Now that the information is available - I'm under the impression that 
only recently the various bits and pieces have come into existence or at 
least got an audience.
I'm seeing a *lot* of "finishing touches" work in progress. (MissingH 
reorganisation, "How to write my first Haskell program" wiki page.)

What I find even more encouraging is that this work is welcomed.

These activities are among the major reasons why I'm finally prepared to 
get my feet wet with Haskell after years of interested watching.
I'll probably fire off a set of newbie questions for my project, though 
it might still take a few days to get them organized well enough to do 
that (and to find the time for setting up the text).


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Aim Of Haskell

[Joachim Durchholz]

Andy Georges schrieb:
one particular thing that we still lack is something like book 
"Haskell in

real world"


We need a 'Dive into Haskell' book.


That's for later.
Getting those little annoyances out of the way (like those described on 
defmacro) is far more important.


What you need so that non-experts can get their feet wet are:
* A compiler. [FIXED]
* Libraries for the application programmer. [MOSTLY FIXED]
* The relevant information is available. [FIXED, I think]
* Things work "out of the box". [MOSTLY FIXED]
* It's easy to find the relevant information. [OPEN]
* A "Haskell for Dummies" book.
Haskell is already 99% there. However, a dummies book would be premature 
- unless you really expect that the other items will be fully fixed by 
the time the book is out.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Type Error. Why!?

[Joachim Durchholz]

Neil Mitchell schrieb:
How is this an FAQ: 
http://www.haskell.org/haskellwiki/Why_Haskell_just_works


It's a nice piece of marketing, but I can't imagine anyone has ever
asked Why Haskell just works, unless they've already used it, in which
case they've moved past an FAQ.


Oh, but that kind of question regularly crops up after Haskell 
programmers have claimed that Haskell "just works".

So yes indeed that's a FAQ.

Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fractional/negative fixity?

[Joachim Durchholz]

David House schrieb:

Also, it provides an infinite space for fixities. I think the problem
'binds tighter than X but not as tight as Y', where X and Y are only
fixity integer apart is somewhat common, and this would fix it. It
would allow for extensibility into the future, where the operator
space will only become more dense, and maintaining a complete order
with only 10 integers to play will become more and more difficult.
Allowing an infinite amount of operators to come between any two
operators sounds like a solid design decision to me.


Yes, but allowing simply to specify some ordering relationship to 
existing operators is an even more solid one.


Fractional fixities are overspecification, and this can hurt in 
scenarios like this one:


Developer A creates an operator with this fixity declaration:
  infixl 6.25  +*
Developer B has this:
  infixl 6.75 *+
(They don't use 6.5 because each has another operator at 6.5 already.)

Now when some developer mixes +* and *+ in the same expression, the 
compiler will automatically assign a relative priority for the two 
operators, even though it's not at all clear whether the two operators 
have any relative precedence - it would be far preferable if the 
compiler simply declared nonpriority and emitted an error, forcing the 
programmer to clearly state what priorities he had in mind when writing 
down the expression.


I know the above example is a bit far-fetched. And it's not a really 
important issue anyway.


Regards,
Jo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe