Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.haskell > #180 > unrolled thread

sell me on strong typing, type safety, etc.

Back to article view | Back to comp.lang.haskell

Contents

  sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-03-30 09:53 -0700
    Re: sell me on strong typing, type safety, etc. John Coleman <jcoleman@franciscan.edu> - 2012-03-31 06:25 -0700
      Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-03-31 11:57 -0700
    Re: sell me on strong typing, type safety, etc. ingo.wechsung@googlemail.com - 2012-04-01 08:23 -0700
      Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-01 13:35 -0700
        Re: sell me on strong typing, type safety, etc. ingo.wechsung@googlemail.com - 2012-04-02 03:51 -0700
          Re: sell me on strong typing, type safety, etc. Roman W <bloody_rabbit@gazeta.pl> - 2012-04-02 04:31 -0700
      Re: sell me on strong typing, type safety, etc. dvandeun@wilma.vub.ac.be (Dirk van Deun) - 2012-04-03 09:13 +0000
        Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-03 11:00 -0700
    Re: sell me on strong typing, type safety, etc. Roman W <bloody_rabbit@gazeta.pl> - 2012-04-02 02:03 -0700
      Re: sell me on strong typing, type safety, etc. ingo.wechsung@googlemail.com - 2012-04-02 03:30 -0700
        Re: sell me on strong typing, type safety, etc. Roman W <bloody_rabbit@gazeta.pl> - 2012-04-02 04:28 -0700
          Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-02 12:17 -0700
            Re: sell me on strong typing, type safety, etc. Roman W <bloody_rabbit@gazeta.pl> - 2012-04-03 06:58 -0700
              Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-03 10:58 -0700
                Re: sell me on strong typing, type safety, etc. Paul Rubin <no.email@nospam.invalid> - 2012-04-03 12:07 -0700
                  Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-03 13:44 -0700
                  Re: sell me on strong typing, type safety, etc. Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-03 20:01 -0300
                    Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-04 12:10 -0700
                Re: sell me on strong typing, type safety, etc. Roman W <bloody_rabbit@gazeta.pl> - 2012-04-04 03:32 -0700
                  Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-04 09:37 -0700
                    Re: sell me on strong typing, type safety, etc. Roman W <bloody_rabbit@gazeta.pl> - 2012-04-04 09:43 -0700
                      Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-04 11:11 -0700
                        Re: sell me on strong typing, type safety, etc. Roman W <bloody_rabbit@gazeta.pl> - 2012-04-05 01:42 -0700
                          Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-06 08:22 -0700
                            Re: sell me on strong typing, type safety, etc. ingo.wechsung@googlemail.com - 2012-04-06 08:32 -0700
                              Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-06 18:29 -0700
                                Re: sell me on strong typing, type safety, etc. Paul Rubin <no.email@nospam.invalid> - 2012-04-06 18:44 -0700
                              Re: sell me on strong typing, type safety, etc. ultranewb <pineapple.link@yahoo.com> - 2012-04-06 18:32 -0700
                                Re: sell me on strong typing, type safety, etc. "Mark T. B. Carroll" <mtbc@bcs.org> - 2012-04-06 22:17 -0400

Page 1 of 2  [1] 2  Next page →

#180 — sell me on strong typing, type safety, etc.

hello all.

i have always coded in what i will loosely call "dynamic" languages
where i didn't have to worry about type.  i have built large, complex
systems with such languages.  nothing ever "blew up."  any bugs were
always relatively minor, relatively easy to find and fix, etc.  the
systems i have built have always been successful.

in giving haskell a look, i noticed the strong emphasis on "strong
typing," "type safety," etc.  in fact, in looking at some propaganda
for one of the web frameworks available for haskell, it seemed every
other word out of the mouth of the developer was "strong SAFE typing,"
even going so far as to emphasize one selling point being "type safe
urls."

i'll bite.  what's the big deal with all this emphasis on type?  if
someone cares to address it, convince me that i need to be a lot more
worried about type than i ever needed to be before.  you have my
attention.

(fwiw, i do appreciate that haskell seems to infer most types so that
i don't have to declare them.  the bigger issue for me would be not
allowing things like lists to contain mixed types.)

thanks.

[toc] | [next] | [standalone]

#181

On Friday, March 30, 2012 12:53:19 PM UTC-4, ultranewb wrote:
> hello all.
> 
> i have always coded in what i will loosely call "dynamic" languages
> where i didn't have to worry about type.  i have built large, complex
> systems with such languages.  nothing ever "blew up."  any bugs were
> always relatively minor, relatively easy to find and fix, etc.  the
> systems i have built have always been successful.
> 
> in giving haskell a look, i noticed the strong emphasis on "strong
> typing," "type safety," etc.  in fact, in looking at some propaganda
> for one of the web frameworks available for haskell, it seemed every
> other word out of the mouth of the developer was "strong SAFE typing,"
> even going so far as to emphasize one selling point being "type safe
> urls."
> 
> i'll bite.  what's the big deal with all this emphasis on type?  if
> someone cares to address it, convince me that i need to be a lot more
> worried about type than i ever needed to be before.  you have my
> attention.
> 
> (fwiw, i do appreciate that haskell seems to infer most types so that
> i don't have to declare them.  the bigger issue for me would be not
> allowing things like lists to contain mixed types.)
> 
> thanks.

Hi, The following article is about the somewhat similar language ML rather than
Haskell, but has an interesting example about how ML's type system was able
to detect that a sort algorithm was buggy:

http://static.usenix.org/publications/library/proceedings/vhll/full_papers/koenig.a

[toc] | [prev] | [next] | [standalone]

#182

On Mar 31, 8:25 pm, John Coleman <jcole...@franciscan.edu> wrote:
> Hi, The following article is about the somewhat similar language ML rather than
> Haskell, but has an interesting example about how ML's type system was able
> to detect that a sort algorithm was buggy:
>
> http://static.usenix.org/publications/library/proceedings/vhll/full_p...

Thanks - will have a look.

[toc] | [prev] | [next] | [standalone]

#183

Am Freitag, 30. März 2012 18:53:19 UTC+2 schrieb ultranewb:
> hello all.
> 
> i have always coded in what i will loosely call "dynamic" languages
> where i didn't have to worry about type.  i have built large, complex
> systems with such languages.  nothing ever "blew up."  any bugs were
> always relatively minor, relatively easy to find and fix, etc.  the
> systems i have built have always been successful.

Very good. It looks like you are one of those people who do it right intuitively.
This means you should never get a complaint from the Haskell type checker.
Hence, as far as it concerns you, the type system will not get in your way and you'll not notice it even exists.
It may be comforting for other people (such as your clients or those who must maintain your code later), though, to know with mathematical certainty that your code is correct as far as the types are concerned.

> i'll bite.  what's the big deal with all this emphasis on type?

Not all people are geniuses and something get it wrong.
Better to tell them it's wrong before they run it.

> (fwiw, i do appreciate that haskell seems to infer most types so that
> i don't have to declare them.  the bigger issue for me would be not
> allowing things like lists to contain mixed types.)

What would you do with such a list if you don't know what is in there?
In every case, you'll have some mechanism that does type discrimination at run time.
You can, of course, do that in Haskell as well though it may be somewhat more explicit than in, say, javascript.

[toc] | [prev] | [next] | [standalone]

#184

On Apr 1, 10:23 pm, ingo.wechs...@googlemail.com wrote:

> Not all people are geniuses and something get it wrong.
> Better to tell them it's wrong before they run it.

i'm not bad by any means, but i don't believe i'm God's gift to the
programming world
either :-)  i think most of what we untyped folks do is less "writing
code 100%
mathematically correct" and more simply structuring code and
circumstances so that it
doesn't need to be.

i read the article the previous poster posted.  i'm impressed that the
type checker
was able to catch that particular bug the way it did.  whether it
actually does
flow analysis, or the type checking is so good that it seems to do it,
it's
impressive enough, i guess.  assuming the thing can catch serious,
hard-to-find bugs
from non-trivial non-toy problems, i guess that's of value.  and of
course i see
the value of mathematical proofs of correctness.

i'd normally say that it would be up to the individual at this point
to decide
whether the value of the strong-typing justifies what you give up in
terms of
hassle and "pain in the ass" factor, except that here the type
inferencing
apparently doesn't force you to give up too much, except perhaps in
the way of
mixed-type structures and what not.

> What would you do with such a list if you don't know what is in there?

sure, you normally need to know what's in there (although the compiler
or
interpreter or whatever you're running might not).

seems like an impressive language.  assuming you static guys would
allow one of us
dynamic guys to get anywhere near it, i'll download a compiler/
interpreter and play
around with it.  just hope a hole doesn't appear in the space-time
continuum :-)

regards.

[toc] | [prev] | [next] | [standalone]

#187

Am Sonntag, 1. April 2012 22:35:21 UTC+2 schrieb ultranewb:
> On Apr 1, 10:23 pm, ingo.wechs...@googlemail.com wrote:
> 
> i'd normally say that it would be up to the individual at this point to decide
> whether the value of the strong-typing justifies what you give up in terms of
> hassle and "pain in the ass" factor, except that here the type inferencing
> apparently doesn't force you to give up too much, except perhaps in the way of
> mixed-type structures and what not.

Yes, this is a point worth noting.

For example, Simon Peyton Jones, the main author of the Glasgow Haskell Compiler is of the opinion that a type system you have to fight with is not good enough.

Hence, Haskell (and related languages with very similar type systems) may be a bit better than you expect. An indication may be that there is really no way to cheat (with regards to types) in Haskell, whereas in Java, for example, you have a cast operation. They need it, because the type system is not powerful enough from the outset.

Another way to put this: There is the set of all correct (i.e. free of bugs) programs in language X. Then there is the set of all correct programs that can be written without having to cheat with the type system of X. The objective is to have the difference, i.e. the set of correct programs that can only be written by cheating the type system as small as possible. And in this regard, Haskell is far better than conventionally statically typed languages.

Hence, static typing is not always the same. When it gets a "pain in the ass" the type system is no good. But in Haskell, every active programmer can tell you stories of how the type system uncovered errors early. And in almost all cases, going back and thinking about it makes it clear that one's design was bad (if it was not just a stupid, easy to fix error). 
Complaints of the form "The type system does not let me do X, lest X is completely legitimate." are almost unheard of. Hence, Haskell programmers actually regard the type system as their best friend, not as their enemy that gets in their way.

[toc] | [prev] | [next] | [standalone]

#189

On Monday, April 2, 2012 11:51:54 AM UTC+1, ingo.w...@googlemail.com wrote:

> For example, Simon Peyton Jones, the main author of the Glasgow Haskell Compiler is of the opinion that a type system you have to fight with is not good enough.

"Fight with" is subjective. Often I think that I'm fighting the language, when in reality I'm suffering from my ignorance.

RW

[toc] | [prev] | [next] | [standalone]

#191

: > i have always coded in what i will loosely call "dynamic" languages
: > where i didn't have to worry about type.  i have built large, complex
: > systems with such languages.  nothing ever "blew up."  any bugs were
: > always relatively minor, relatively easy to find and fix, etc.  the
: > systems i have built have always been successful.

: Very good. It looks like you are one of those people who do it right intuitively.

I'd rather suppose that the original poster is used to writing in a
style in which you make fewer errors of the kind which are hard to
find without a type checker.  Imagine clean, short, imperative
statements; not a lot of higher order functions; rarely if ever any
partially applied functions or complex function compositions; global
variables instead of threading values through your code; loops and
counters; and strange as it may sound, no abstractions pilfered from
category theory.  Haskell needs a good type checker, because the
language invites us to write in a style in which you may need it a
lot.  Other languages and other styles less so.  You could say that
the Haskell type checker is an enabler for the Haskell style of
programming.

Dirk van Deun
-- 
Licensed to (kill -9)

[toc] | [prev] | [next] | [standalone]

#193

On Apr 3, 4:13 pm, dvand...@wilma.vub.ac.be (Dirk van Deun) wrote:
> : > i have always coded in what i will loosely call "dynamic" languages
> : > where i didn't have to worry about type.  i have built large, complex
> : > systems with such languages.  nothing ever "blew up."  any bugs were
> : > always relatively minor, relatively easy to find and fix, etc.  the
> : > systems i have built have always been successful.
>
> : Very good. It looks like you are one of those people who do it right intuitively.
>
> I'd rather suppose that the original poster is used to writing in a
> style in which you make fewer errors of the kind which are hard to
> find without a type checker.  Imagine clean, short, imperative
> statements; not a lot of higher order functions; rarely if ever any
> partially applied functions or complex function compositions; global
> variables instead of threading values through your code; loops and
> counters; and strange as it may sound, no abstractions pilfered from
> category theory.  Haskell needs a good type checker, because the
> language invites us to write in a style in which you may need it a
> lot.  Other languages and other styles less so.  You could say that
> the Haskell type checker is an enabler for the Haskell style of
> programming.
>
> Dirk van Deun
> --
> Licensed to (kill -9)

[toc] | [prev] | [next] | [standalone]

#185

On Friday, March 30, 2012 5:53:19 PM UTC+1, ultranewb wrote:
> i'll bite.  what's the big deal with all this emphasis on type?  if
> someone cares to address it, convince me that i need to be a lot more
> worried about type than i ever needed to be before.  you have my
> attention.

You say that you've always built correctly working systems with few bugs using
dynamic typing. You don't say how much excess (as compared to systems built
using static typing) testing code you have to put in just to make sure that
your types are correct. For example, if adhering to "100% unit test coverage" credo,
you'd have to check the return type of every function for at least most typical
inputs, to make sure it returns the correct type. That's a lot of effort not needed
in static-typed languages.

Another aspect of this is run-time performance. Dynamic typing comes at a cost, 
since the type information must be carried around together with the object.

RW

[toc] | [prev] | [next] | [standalone]

#186

Am Montag, 2. April 2012 11:03:22 UTC+2 schrieb Roman W:
> On Friday, March 30, 2012 5:53:19 PM UTC+1, ultranewb wrote:
> > i'll bite.  what's the big deal with all this emphasis on type?  if
> > someone cares to address it, convince me that i need to be a lot more
> > worried about type than i ever needed to be before.  you have my
> > attention.
> 
> You say that you've always built correctly working systems with few bugs using
> dynamic typing. You don't say how much excess (as compared to systems built
> using static typing) testing code you have to put in just to make sure that
> your types are correct. For example, if adhering to "100% unit test coverage" credo,
> you'd have to check the return type of every function for at least most typical
> inputs, to make sure it returns the correct type. That's a lot of effort not needed
> in static-typed languages.

Indeed.
The 100% coverage of the type checker is especially useful when it comes to refactoring, modifications, etc.
For example, the type checker answers the question "What needs to be changed if I redesign this type, piece of code or what not?" very quickly and comprehensively. 

[toc] | [prev] | [next] | [standalone]

#188

On Monday, April 2, 2012 11:30:56 AM UTC+1, ingo.w...@googlemail.com wrote:
> Am Montag, 2. April 2012 11:03:22 UTC+2 schrieb Roman W:
> > On Friday, March 30, 2012 5:53:19 PM UTC+1, ultranewb wrote:
> > > i'll bite.  what's the big deal with all this emphasis on type?  if
> > > someone cares to address it, convince me that i need to be a lot more
> > > worried about type than i ever needed to be before.  you have my
> > > attention.
> > 
> > You say that you've always built correctly working systems with few bugs using
> > dynamic typing. You don't say how much excess (as compared to systems built
> > using static typing) testing code you have to put in just to make sure that
> > your types are correct. For example, if adhering to "100% unit test coverage" credo,
> > you'd have to check the return type of every function for at least most typical
> > inputs, to make sure it returns the correct type. That's a lot of effort not needed
> > in static-typed languages.
> 
> Indeed.
> The 100% coverage of the type checker is especially useful when it comes to refactoring, modifications, etc.
> For example, the type checker answers the question "What needs to be changed if I redesign this type, piece of code or what not?" very quickly and comprehensively.

I agree. For example, you can track the usage of your class by simply searching for the class name in the code. If you don't declare your types, you have no way of knowing what part of the code will be affected.

BTW, initially I read your post as sarcastic ;-)

RW

[toc] | [prev] | [next] | [standalone]

#190

> You say that you've always built correctly working systems with few bugs using
> dynamic typing. You don't say how much excess (as compared to systems built
> using static typing) testing code you have to put in just to make sure that
> your types are correct.

Normally it's minimal.  If i do anything, it's normally user-input
scrubbing/filtering vs. type checking, but not too much beyond that.

Just so i can see where a static guy is coming from, give me a
reasonable, "non-exotic" situation where you think there would need to
be a lot of testing code for typing.

> For example, Simon Peyton Jones, the main author of the Glasgow Haskell Compiler
> is of the opinion that a type system you have to fight with is not good enough.

I like this guy!  (I once walked out on a project when I saw what I'd
have to do to declare the type of a particular template in C++.  The
declaration literally went beyond 80 characters and scrolled to the
next line.)

[toc] | [prev] | [next] | [standalone]

#192

On Monday, April 2, 2012 8:17:06 PM UTC+1, ultranewb wrote:
> Just so i can see where a static guy is coming from, give me a
> reasonable, "non-exotic" situation where you think there would need to
> be a lot of testing code for typing.

Using the OOP paradigm: let's say you have a Factory producing Widgets. In a
static-typed language, you'll declare the buildWidget method with return type IWidget.
You know at compile time that the object returned by this method has a given interface.
In a dynamic-typed language, you can only test this at runtime, by testing the objects
returned by the factory method.

RW

[toc] | [prev] | [next] | [standalone]

#194

> I'd rather suppose that the original poster is used to writing in a
> style in which you make fewer errors of the kind which are hard to
> find without a type checker.  Imagine clean, short, imperative
> statements; not a lot of higher order functions; rarely if ever any
> partially applied functions or complex function compositions; global
> variables instead of threading values through your code; loops and
> counters; and strange as it may sound, no abstractions pilfered from
> category theory.  Haskell needs a good type checker, because the
> language invites us to write in a style in which you may need it a
> lot.

There's a good bit of truth here as far as coding style for past
projects.  And I hadn't considered that writing in a "Haskell-esque
style" might justify more of a need for something like static type
checking.  Good insight.

By the way, have you heard of a language called "Pure" (used to be
called "Q") which seems to be very similar in syntax to a dynamically-
typed Haskell?

> Using the OOP paradigm: let's say you have a Factory producing Widgets. In a
> static-typed language, you'll declare the buildWidget method with return type
> IWidget. You know at compile time that the object returned by this method has
> a given interface. In a dynamic-typed language, you can only test this at
> runtime, by testing the objects returned by the factory method.

Not trying to be difficult here, I just honestly still don't "get
it."  Why do I need to test what type of stuff is coming out of the
factory?  I mean, if I designed the factory to pump out objects of a
specific type, why can't I just assume that that's what it will do at
runtime?

[toc] | [prev] | [next] | [standalone]

#195

ultranewb <pineapple.link@yahoo.com> writes:

> Not trying to be difficult here, I just honestly still don't "get
> it."  Why do I need to test what type of stuff is coming out of the
> factory?  I mean, if I designed the factory to pump out objects of a
> specific type, why can't I just assume that that's what it will do at
> runtime?

The Factory might make the wrong type by accident, or there might be
some buggy plumbing in your program between the factory and where the
produced widget is actually used.

You should read Chris Smith's article:

http://web.archive.org/web/20080822101209/http://www.pphsg.org/cdsmith/types.html

[toc] | [prev] | [next] | [standalone]

#196

> You should read Chris Smith's article:

A good article.  In fact, because of this very thread, I had just
started to figure out on my own some of the points the article
addresses.  For instance, because of being forced to program in C, C+
+, Pascal, etc. in early years, I always had the notion that static
type systems only seem to be good for checking for typos that I will
catch easily enough anyway when I run my code, but at the huge cost of
cluttering up my code, turning what should be several lines into a
page or more, and giving me carpel-tunnel syndrome from all the typing
I am forced to do.  The best thing I ever did was get away from those
languages as quickly as humanly possible (which I did a long time
ago).  But the point is, until this very thread, I always associated
"static typing" with those languages, particularly utter crap
languages like Java and C++.

I think what I started to learn from this thread (correct me if I am
wrong) is that a type system like Haskell's is just a whole different
kettle of fish, not just because you aren't forced to clutter your
code with huge numbers of type annotations like "public static void
main blah blah..." over and over again, but because the type system is
really something more than just a glorified typo-catcher.

If you static guys happen to run into this topic with dynamic guys
very often, I think the best thing you can do is get them to
understand from the get-go that static typing DOES NOT necessarily
equal programming in a hellhole like C++ or Java or Pascal.

> The Factory might make the wrong type by accident, or there might be
> some buggy plumbing in your program between the factory and where the
> produced widget is actually used.

I don't think the article addressed this, or told me why I should be
concerned about it.  Either way, a lot of this stuff might boil down
to a "cultural" or "religious" thing.  I've seen what I will call
"defensive coding" written by colleagues that makes my eyes glaze over
(basically reams of code checking for type everywhere you can check
for it).  Me?  I don't do it, and nothing blows up, but far be it from
me to criticize someone else's "culture" or "religion."

At any rate, a successful thread.  What do you know, I actually
learned something.

[toc] | [prev] | [next] | [standalone]

#197

On 12-04-03 04:07 PM, Paul Rubin wrote:
> ultranewb <pineapple.link@yahoo.com> writes:
> 
>> Not trying to be difficult here, I just honestly still don't "get
>> it."  Why do I need to test what type of stuff is coming out of the
>> factory?  I mean, if I designed the factory to pump out objects of a
>> specific type, why can't I just assume that that's what it will do at
>> runtime?
> 
> The Factory might make the wrong type by accident, or there might be
> some buggy plumbing in your program between the factory and where the
> produced widget is actually used.
> 
> You should read Chris Smith's article:
> 
> http://web.archive.org/web/20080822101209/http://www.pphsg.org/cdsmith/types.html

Good article, thanks for pointing it out. I already went through the
phase quite a while back of thinking that "strong" and "weak" could be
clearly explained; now I'm casting around for lots of well-argued points
of view on typing so as to just start solidly understanding types. I
think it's probably the case that most of us programmers need a few
kicks at the can before we start understanding types and type systems.

There is still a small stubborn part of me that wants to use the
"strong" and "weak" characterizations. To use Smith's definition near
the end of the article, I like his initial description of a "weak"
system as one that "that worries [one], or makes [one] feel
uncomfortable." I think that this is what a lot of people mean when they
look at a system that permits a whole bunch of operations; it just feels
sloppy. "3" + 2.5 is no less defined than a type system that doesn't
permit this, it just can feel "weaker".

AHS

-- 
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#202

> "3" + 2.5 is no less defined than a type system that doesn't
> permit this, it just can feel "weaker".

Tcl:  your worst nightmare, heh:

# add string and number

> expr "3" + 2.5
5

# concat a string and number

> append x "string" 3
string3

[toc] | [prev] | [next] | [standalone]

#198

On Tuesday, April 3, 2012 6:58:03 PM UTC+1, ultranewb wrote:

> Not trying to be difficult here, I just honestly still don't "get
> it."  Why do I need to test what type of stuff is coming out of the
> factory?  I mean, if I designed the factory to pump out objects of a
> specific type, why can't I just assume that that's what it will do at
> runtime?

But that's a different question: "why test software?".

RW

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.haskell

csiph-web