What's the deal with Clean?

[Artyom Shalkhakov]

Hello,

2009/11/4 Alberto G. Corona <agocorona@...>:
> The code executed by uniqueness types is somehow similar to the internal
> code executed in a state monad (or in the case of IO, the IO monad). The
> main difference is that the pairs of results  (state, value) are explicitly
> written in Clean by the programmer and the  type sytem assures that the
> order of executions makes sense at compile time, whereas in the case of the
> state monad the sequence of instructions is lazily assembled at runtime in
> the first step and executed in a second step. So there is a little more
> overhead in haskell but the code is higher level.
> Am I right?

I would rather say: code with uniqueness types allows for safe
destructive updates.

In Clean, a variable of unique type is ensured to have only one
reference to it, at any time (that's why it's called "uniqueness
typing"). So you can't write the code like this

> f(x) + f(x)

where f : *a -> int (x is of unique type), because x is clearly
referenced two times here. What to do? Let f yield another reference
to x! That also means that the old reference is not usable any more,
since you have new one. f becomes:

> f : *a -> (int, *a)

and the code looks very familiar:

> let (a, x') = f(x)
>     (b, x'') = f(x')
> in a + b

The function f can use destructive updates under the hood though it
doesn't violate referential transparency. I bet you can you see why.

I'd say that call-by-need is orthogonal to uniqueness typing.

Cheers,
Artyom Shalkhakov.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Philippos Apolinarius]

Brian wrote:

> However if I had to guess, it seems to me that you want to read the data into
> a list and then find some ST function which can initialize an array using a list (maybe ?)

It is the other way around. I want to avoit lists. I would like to read the array elements from a file, and store then directly into the array. This approach would spare me from writing using a possibly expensive heap hungry intermediate structure.

--- On Tue, 11/3/09, brian <briand@...> wrote:

From: brian <briand@...>
Subject: Re: [Haskell-cafe] Arrays in Clean and Haskell
To: "Philippos Apolinarius" <phi500ac@...>
Cc: haskell-cafe@...
Received: Tuesday, November 3, 2009, 9:34 PM

On Nov 3, 2009, at 7:38 PM, Philippos Apolinarius wrote:

> Brian wrote:
> > Really, arrays in Haskell are the most @#!$! confusing thing in the world.
>
> Hi, Brian.
> I am having a great difficulty with arrays in Haskell.  In the university where I study, functional programming is taught in Clean or in

me too :-)

> And here comes the reason for writing this article. In the previous version of the Gauss elimination algorithm, I have imported

you're asking me ??  I have no idea.  I can't even figure out which package to use.

However if I had to guess, it seems to me that you want to read the data into a list and then find some ST function which can initialize an array using a list (maybe ?)

Brian

[Philippos Apolinarius]

Jason Dusek wrote:

> How do you read in the IOUArray? By parsing a character string
> or do you treat the file as binary numbers or ... ?

I always pare the file. Parsing the file has the advantage of alowing me to have files of any format. In general, in homeworks, TA generate files using different tools.  For instance, a professor of electrical protection of hardware made a lot of measurements of transient currents due to lightning. The file has thousands of three column lines, each one containing time, voltage and current.  Students are supposed to read the file, and plot voltage and current time series. Even the numbers are in a strange format... So, one needs to parse the file.

--- On Tue, 11/3/09, Jason Dusek <jason.dusek@...> wrote:

From: Jason Dusek <jason.dusek@...>
Subject: Re: [Haskell-cafe] Arrays in Clean and Haskell
To: "Philippos Apolinarius" <phi500ac@...>
Cc: haskell-cafe@...
Received: Tuesday, November 3, 2009, 9:31 PM

  How do you read in the IOUArray? By parsing a character string
  or do you treat the file as binary numbers or ... ?

--
Jason Dusek

---

The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free!
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Bulat Ziganshin-2]

Hello Don,

> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=clean&box=1
> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=ocaml&box=1

> The Haskell compiler isn't the bottleneck. Use it when performance matters. I do.

Don, shootout times may be used to measure how many people was
contributed solutions for each language, but nothing more. these tests
depends mainly on libraries bundled with each compiler and, secondary,
on enthusiasts writing low-level code

--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

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

[Ketil Malde-5]

Bulat Ziganshin <bulat.ziganshin@...> writes:

>> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=clean&box=1
>> http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=ocaml&box=1

>> The Haskell compiler isn't the bottleneck. Use it when performance matters. I do.

> Don, shootout times may be used to measure how many people was
> contributed solutions for each language, but nothing more.

Well, it clearly demonstrates that it is possible to write fast code in
Haskell.

Last time I looked, much of the shootout code was overly complicated
(i.e. "enthusiasts writing low-level code").  And I can't help but notice
that Clean beats Haskell on code compactness.  It'd be interesting to
see how well more naïve/idiomatic code fares.  While it's nice to be
able to write fast programs, the main reason to use Haskell is to write
succinct and correct programs.  (Is it possible to have an alternative
Haskell "track" in the shootouts?)

Since this was done, there has been great strides in available libraries
and GHC optimizations, and it'd also be interesting to see whether we
now are able to optimize ourselves away from much of the overhead.

-k
--
If I haven't seen further, it is by standing in the footprints of giants
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Alberto G. Corona]

Artyom.

I know what uniqueness means. What I meant is that the context in which uniqueness is used, for imperative sequences:

(y, s')= proc1 s x

(z, s'')= proc2 s' y

.....

is essentially the same sequence as if we rewrite an state monad to make the state  explicit. When the state is the "world" state, then it is similar to the IO monad.

 An state monad forces a single use of the  implicit state variable too (unless you pass it trough the next step without changes. That can be done in Clean too.

2009/11/4 Artyom Shalkhakov <artyom.shalkhakov@...>

Hello,

2009/11/4 Alberto G. Corona <agocorona@...>:

> The code executed by uniqueness types is somehow similar to the internal
> code executed in a state monad (or in the case of IO, the IO monad). The
> main difference is that the pairs of results  (state, value) are explicitly
> written in Clean by the programmer and the  type sytem assures that the
> order of executions makes sense at compile time, whereas in the case of the
> state monad the sequence of instructions is lazily assembled at runtime in
> the first step and executed in a second step. So there is a little more
> overhead in haskell but the code is higher level.
> Am I right?

I would rather say: code with uniqueness types allows for safe
destructive updates.

In Clean, a variable of unique type is ensured to have only one
reference to it, at any time (that's why it's called "uniqueness
typing"). So you can't write the code like this

> f(x) + f(x)

where f : *a -> int (x is of unique type), because x is clearly
referenced two times here. What to do? Let f yield another reference
to x! That also means that the old reference is not usable any more,
since you have new one. f becomes:

> f : *a -> (int, *a)

and the code looks very familiar:

> let (a, x') = f(x)
>     (b, x'') = f(x')
> in a + b

The function f can use destructive updates under the hood though it
doesn't violate referential transparency. I bet you can you see why.

I'd say that call-by-need is orthogonal to uniqueness typing.

Cheers,
Artyom Shalkhakov.

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

[Bulat Ziganshin-2]

Hello Ketil,

Wednesday, November 4, 2009, 4:31:20 PM, you wrote:

> Well, it clearly demonstrates that it is possible to write fast code in
> Haskell.

my measures says that by psending 3x more time than for C you can
optimize haskell code to be only 3x slower than C one

> succinct and correct programs.  (Is it possible to have an alternative
> Haskell "track" in the shootouts?)

even w/o enthusiasts Shootout mainly measure speed of libraries

> Since this was done, there has been great strides in available libraries
> and GHC optimizations, and it'd also be interesting to see whether we
> now are able to optimize ourselves away from much of the overhead.

eh, if it was possible, we have seen this. both on shootout and here
when people are crying that their code isn't as fast as those ads say.
haskell compilation can't yet automatically avoid laziness and convert
pure high-level code into equivalent of C one. libraries doesn't
change anything - they provide low-level optimized solutions for
particular tasks but can't optimize your own code once you started to
write it


--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

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

[Alberto G. Corona]

I personally don´t care about raw performance. Haskell is in the top of the list of language performance. It has all the ingredients for improving performance in the coming years: A core language, clear execution strategy, analysis and parsing, transformations based on math rules. So my code will improve with each new compiler version at the same or better pace than any other language. Moreover I can not care less about how fast is C, when I simply can not program many things I need in C or C++ or Java  and in general any of the language of the performance list that are above... or below, because they lack the necessary type safety, expressiveness, abstraction.etc. Not to mention time. Not to mention the growing community etc.

Regards.

2009/11/4 Bulat Ziganshin <bulat.ziganshin@...>

Hello Ketil,

Wednesday, November 4, 2009, 4:31:20 PM, you wrote:

> Well, it clearly demonstrates that it is possible to write fast code in
> Haskell.

my measures says that by psending 3x more time than for C you can
optimize haskell code to be only 3x slower than C one

> succinct and correct programs.  (Is it possible to have an alternative
> Haskell "track" in the shootouts?)

even w/o enthusiasts Shootout mainly measure speed of libraries

> Since this was done, there has been great strides in available libraries
> and GHC optimizations, and it'd also be interesting to see whether we
> now are able to optimize ourselves away from much of the overhead.

eh, if it was possible, we have seen this. both on shootout and here
when people are crying that their code isn't as fast as those ads say.
haskell compilation can't yet automatically avoid laziness and convert
pure high-level code into equivalent of C one. libraries doesn't
change anything - they provide low-level optimized solutions for
particular tasks but can't optimize your own code once you started to
write it

--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

_______________________________________________

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

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

[Edsko de Vries-4]

On 4 Nov 2009, at 13:36, Alberto G. Corona wrote:

> Artyom.
>
> I know what uniqueness means. What I meant is that the context in  
> which uniqueness is used, for imperative sequences:
>
> (y, s')= proc1 s x
> (z, s'')= proc2 s' y
> .....
>
> is essentially the same sequence as if we rewrite an state monad to  
> make the state  explicit. When the state is the "world" state, then  
> it is similar to the IO monad.

Yes, as long as there is a single thing that is being updated there's  
little difference between the state monad and a unique type. But  
uniqueness typing is more general. For instance, a function which  
updates two arrays

f (arr1, arr2) = (update arr1 0 'x', update arr2 0 'y')

is easily written in functional style in Clean, whereas in Haskell we  
need to sequentialize the two updates:

f (arr1, arr2)
   = do writeArray arr1 0 'x'
            writeArray arr2 0 'y'

You can find a more detailed comparison in my thesis (https://www.cs.tcd.ie/Edsko.de.Vries/pub/MakingUniquenessTypingLessUnique-screen.pdf 
, Section 2.8.7).

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

[David Leimbach]

On Tue, Nov 3, 2009 at 10:44 PM, Ben Lippmeier <Ben.Lippmeier@...> wrote:

David Leimbach wrote:

I have to admit, the first time I hit the wiki page for DDC I said to myself "Self, this sounds crazy complicated".  Then I read part of the PDF (your thesis I believe) about Region Types on the bus ride to work and thought.  "Gee I think I scared myself off too quickly".

Uniqueness typing is quite interesting in Clean, but to control aliasing, like really *control* aliasing, that's just far out man.

So I still have to wrap my head around "why this isn't going to get completely out of control" and see why it's all safer than just writing C code but I must say the attention I will be paying to DDC has just gone quite a bit up.

:) A correct C program is just as safe as a correct Haskell/Disciple program.

Well, of course, the question is in what sort of guarantees a language or compiler provides I guess.

 

If you're using destructive update then aliasing, side effects and mutability all start to matter. It might look complicated when you reflect all these things in the type system, but you're really just getting a handle on the inherent complications of the underlying program.

So it's just really more notation to let you know which tools are being used when you use them?  

Does Disciple completely avoid the need for such things as unsafePerformIO? 

(a perhaps overly paranoid comment but...)

I realize we're probably not supposed to worry about the existence of unsafePerformIO, and that library authors "know what they're doing".  But doesn't it automatically mean that there's a bit of implicit trust whenever I see a function that's  of type (a -> a) that there *isn't* IO going on in there? :-)

If Disciple can guarantee that no one is allowed to cheat, is that not a better approach?

I suppose the trick is to be able to ignore said complications when you just don't care, or they're not relevant for your particular problem...

Yes, the Disciple documentation says that this stuff can be inferred, but I don't even let Haskell infer my types for *any* functions I write in any code.  I like to restrict what can go in and out of the function even if it's more general.  Perhaps this is the knee-jerk reaction of an angry Erlang programmer who really wanted some types to reign in the overly-dynamic evaluations that are allowed in that environment, but that's how I roll baby!  I will admit that on occasion I will write and expression that I think does what I want, and look at in in ghci, having it tell me the type because sometimes I've not had enough coffee to do it in my head, but I either look at the inferred type and realize that it's what I originally wanted, or add further restrictions.

Dave

 

Ben.

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

[David Leimbach]

On Wed, Nov 4, 2009 at 7:11 AM, Edsko de Vries <edskodevries@...> wrote:

On 4 Nov 2009, at 13:36, Alberto G. Corona wrote:

Artyom.

I know what uniqueness means. What I meant is that the context in which uniqueness is used, for imperative sequences:

(y, s')= proc1 s x
(z, s'')= proc2 s' y
.....

is essentially the same sequence as if we rewrite an state monad to make the state  explicit. When the state is the "world" state, then it is similar to the IO monad.

Yes, as long as there is a single thing that is being updated there's little difference between the state monad and a unique type. But uniqueness typing is more general. For instance, a function which updates two arrays

f (arr1, arr2) = (update arr1 0 'x', update arr2 0 'y')

is easily written in functional style in Clean, whereas in Haskell we need to sequentialize the two updates:

f (arr1, arr2)
 = do writeArray arr1 0 'x'
          writeArray arr2 0 'y'

Those sequential updates can be run concurrently on both, just with different syntax though right?

 

You can find a more detailed comparison in my thesis (https://www.cs.tcd.ie/Edsko.de.Vries/pub/MakingUniquenessTypingLessUnique-screen.pdf, Section 2.8.7).

-Edsko

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

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

[Bulat Ziganshin-2]

Hello Alberto,

Wednesday, November 4, 2009, 5:58:31 PM, you wrote:

> I personally don´t care about raw performance.

me too. actually, i write time-critical parts of my app in c++

> Haskell is in the
> top of the list of language performance.

this list is meaningless, as i said before

> It has all the ingredients
> for improving performance in the coming years:

that's different question. i think that at the last end lazy languages
will become as efficient as assembler, it just may happen not in my
lifespan :)

> I can not care less about how fast is C, when I simply can not
> program many things I need in C or C++ or Java  and in general any
> of the language of the performance list that are above...

if you don't know how to implement things in C, you cannot do it
efficiently in Haskell too. when i write efficient code in Haskell, i
actually use Haskell as obscure assembler (the same holds for C)

> or below,
> because they lack the necessary type safety, expressiveness,
> abstraction.etc.

they also can't make you coffee but it's is different story. i use
Haskell too. i just know that it is slow and use other languages when
i really need speed. it's why my archiver is world's fastest one :)

--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

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

[Ketil Malde-5]

Bulat Ziganshin <bulat.ziganshin@...> writes:

>> Well, it clearly demonstrates that it is possible to write fast code
>> in Haskell.

> my measures says that by psending 3x more time than for C you can
> optimize haskell code to be only 3x slower than C one

Right¹, the interesting thing is not how fast I can get with N times the
effort, but if I can get fast enough with 1/N.

> when people are crying that their code isn't as fast as those ads say.
> haskell compilation can't yet automatically avoid laziness and convert
> pure high-level code into equivalent of C one.

Many of those people are making fairly simple mistakes.  I think a
somewhat seasoned programmer using good libraries can write declarative,
concise, and readable code that still is reasonably fast.

-k

¹) At least for some approximation of the word. Only one benchmark on
the shootout has C at a 3x advantage.
--
If I haven't seen further, it is by standing in the footprints of giants
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@...
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Bulat Ziganshin-2]

Hello Ketil,

Wednesday, November 4, 2009, 7:43:38 PM, you wrote:

> Right?, the interesting thing is not how fast I can get with N times the
> effort, but if I can get fast enough with 1/N.

it depends entirely on how fast you need. so it's again changing the
topic - while i say that haskell is slow compared to other languages,
i don't say that it is slow for you or that you need sped at all. why
it's repeated again and again? why you don't write to Don what you
don't need speed when he wrote that haslkell is fast but wrote this to
me? :(

>> when people are crying that their code isn't as fast as those ads say.
>> haskell compilation can't yet automatically avoid laziness and convert
>> pure high-level code into equivalent of C one.

> Many of those people are making fairly simple mistakes.  I think a
> somewhat seasoned programmer using good libraries can write declarative,
> concise, and readable code that still is reasonably fast.

i don't think that omitting strictness declarations is a mistake :)

> ?) At least for some approximation of the word. Only one benchmark on
> the shootout has C at a 3x advantage.

oh, can we stop saying about shootout? if you want to see speed of
pure haskell code, look at papers about fast arrays/strings - their
authors have measured that lazy lists are hundreds times slower than
idiomatic C code. is use of lazy lists counted as mistake too and
paper authors had too small haskell experience?

--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

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

[Edsko de Vries-4]

I'm not sure I follow you? The compiler can't reorder the two updates or do them in parallel (IO is not a commutative monad). You might tell the compiler this explicitly, but then are you writing lower and lower level code, further removed from the functional paradigm.

Edsko

On 4 Nov 2009, at 15:27, David Leimbach wrote:

On Wed, Nov 4, 2009 at 7:11 AM, Edsko de Vries <edskodevries@...> wrote:

On 4 Nov 2009, at 13:36, Alberto G. Corona wrote:

Artyom.

I know what uniqueness means. What I meant is that the context in which uniqueness is used, for imperative sequences:

(y, s')= proc1 s x
(z, s'')= proc2 s' y
.....

is essentially the same sequence as if we rewrite an state monad to make the state  explicit. When the state is the "world" state, then it is similar to the IO monad.

Yes, as long as there is a single thing that is being updated there's little difference between the state monad and a unique type. But uniqueness typing is more general. For instance, a function which updates two arrays

f (arr1, arr2) = (update arr1 0 'x', update arr2 0 'y')

is easily written in functional style in Clean, whereas in Haskell we need to sequentialize the two updates:

f (arr1, arr2)
 = do writeArray arr1 0 'x'
          writeArray arr2 0 'y'

Those sequential updates can be run concurrently on both, just with different syntax though right?

 

You can find a more detailed comparison in my thesis (https://www.cs.tcd.ie/Edsko.de.Vries/pub/MakingUniquenessTypingLessUnique-screen.pdf, Section 2.8.7).

-Edsko

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

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

[Don Stewart-2]

bulat.ziganshin:
> oh, can we stop saying about shootout? if you want to see speed of
> pure haskell code, look at papers about fast arrays/strings - their
> authors have measured that lazy lists are hundreds times slower than
> idiomatic C code. is use of lazy lists counted as mistake too and
> paper authors had too small haskell experience?

Comparing apples against oranges is a mistake, yes.

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

[Richard O'Keefe]

On Nov 4, 2009, at 9:56 PM, Martin DeMello wrote [about Clean]:
> And a well-integrated GUI toolkit. If it weren't for the Windows bias
> I'd have definitely taken the time to learn the language.

The GUI toolkit was originally available on the Mac.
But now, ah, now!
"The Object I/O Library 1.2 is currently
  only available for the Wintel platform. "

The last time I tried Clean on a SPARC, using even the old
GUI toolkit required you to locate and install a graphics
library (XView) that Sun abandoned a _long_ time ago.

They have some _really_ interesting ideas about building web sites
using generics.

I paid for the Intel C compiler.  I'd pay for Clean, if only I
_could_ use it.

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

[Jason Dusek]

2009/11/4 Philippos Apolinarius <phi500ac@...>
> Jason Dusek wrote:
> > How do you read in the IOUArray? By parsing a character
> > string or do you treat the file as binary numbers or ... ?
>
> I always pare the file. Parsing the file has the advantage of
> alowing me to have files of any format.

  From this description, it's hard for me to see what is hard
  for you. When you "parse the file" I imagine you in face
  "parse a String" or "parse a lazy ByteString" (a much better
  idea). Take that `String` or `ByteString` and pass it to an
  `ST` computation that parses it to make an `ST` array and then
  operates on the array.

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

[Roman Leshchinskiy]

On 05/11/2009, at 04:01, Bulat Ziganshin wrote:

> oh, can we stop saying about shootout? if you want to see speed of
> pure haskell code, look at papers about fast arrays/strings - their
> authors have measured that lazy lists are hundreds times slower than
> idiomatic C code. is use of lazy lists counted as mistake too and
> paper authors had too small haskell experience?

In the papers I coauthored, I don't think we measured any such thing.  
What we measured was that in algorithms that are best implemented with  
(unboxed) arrays, using boxed lists is going to cost you. That's not a  
very surprising conclusion and it's by no means specific to Haskell.  
The problem was/is the lack of nice purely declarative array libraries  
but that changing, albeit slowly. It's a question of using the right  
data structure for the algorithm, not a C vs. Haskell thing.

Roman


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

[Jason Dusek]

2009/11/04 Jason Dusek <jason.dusek@...>:
>  ...you "parse the file" I imagine you in face...

   in face -> in fact

   Sorry.

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