, I happen to know that SDL suffers from the initialisation
issue and IIRC it needs at least 1 global to stop user using an unsafe
(possibly segfault inducing) calling sequence.
Anyway, that's all from me because I'm bored with this thread now.
Regards
--
Adrian hey
where
glob2 :: IORef Int
glob2 - mod1 = newIORef
mod2 :: IO Int
mod2 = readIORef glob2
Immediatly breaking my promise to shut up..
This is illegal because you're only allowed to use ACIO in top level -
bindings and readIORef isn't (and clearly could not be) ACIO.
Regards
--
Adrian Hey
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Eh? Please illustrate your point with Data.Unique. What requirements
does it place on it's context? (whatever that might mean :-)
It requires that its context initialises it precisely once.
It's context being main? If so
Adrian Hey wrote:
We have to have something concrete to discuss and this is the simplest.
Like I said there are a dozen or so other examples in the base package
last time I counted and plenty of people have found that other libs/ffi
bindings need them for safety reasons. Or at least they need
going to like it, but I think folk *will* be using real
global variables in I/O libs for the forseeable future. Seems a shame
that they'll have to do this with unsafePerformIO hack though :-(
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety
requirement has been met, but I think it fails on the improved API.
The main complaint would be what I see as loss of modularity, in that
somehow what should
talking about standardising the current hack. This the whole
point of the top level - proposal, which JM seems to think is sound
enough for incorporation into JHC (correctly IMO). Nobody's found
fault with it, other than the usual global variables are evil mantra
:-)
Regards
--
Adrian Hey
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Adrian Hey wrote:
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
Well, yes, but if I implemented a library in standard Haskell it would
always be safely serialisable
Adrian Hey wrote:
Global variables are needed to ensure important safety properties,
but the only reasons I've seen people give for thread local variables
is that explicit state threading is just so tiresome and ugly. Well
that may be (wouldn't disagree), but I'm not aware of any library
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today. It would be Perl, ML, or Java
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 29, at 4:22, Adrian Hey wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative
figure it out :-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
, if this is a problem
with top level - ACIO monad bindings it's still going to be
a problem (probably much worse) with unsafePerformIO hack IO
monad bindings.
This problem isn't just going to go away, no matter how long
it's ignored :-)
Regards
--
Adrian Hey
Jonathan Cast wrote:
On Wed, 2008-08-27 at 11:53 +0100, Adrian Hey wrote:
John Meacham wrote:
As with all design decisions, it is sometimes the right thing and
sometimes the wrong one. And sometimes the most expedient. (which,
occasionally, is a perfectly valid driving force behind a certain
this stuff up in my
own custom augmented IO monad right at the start of main. But this
solution still lacks modularity. The top level - bindings are just
a modular and extensible way to achieve the same thing AFAICS
(augmenting real world state with my own custom state).
Regards
--
Adrian Hey
Johannes Waldmann wrote:
Adrian Hey wrote:
There are plenty situations where it makes no semantic sense to allow
2 or more or some thing. A list of all active processes for example.
all referring to what scope? perhaps there occurs a situation
with several process (thread) pools, severals
Jonathan Cast wrote:
On Thu, 2008-08-28 at 10:00 +0100, Adrian Hey wrote:
Lennart Augustsson wrote:
I don't don't think global variables should be banned, I just think
they should be severly discouraged.
If you're saying a language should not provide a sound way to do
this (as I believe
? There's no semantic difficulty with the proposed language
extension, and it should be very simple to implement (John seems
to have done it already).
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman
Ganesh Sittampalam wrote:
On Thu, 28 Aug 2008, Adrian Hey wrote:
implicit parameters (a highly dubious language feature IMO).
How can you say that with a straight face at the same time as advocating
global variables? :-)
Quite easily, what's the problem? IORefs, Chans etc are perfectly
expressing any opinion about how stdin should be
implemented so I don't know what your on about here.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ganesh Sittampalam wrote:
On Thu, 28 Aug 2008, Adrian Hey wrote:
There's no semantic difficulty with the proposed language extension,
How does it behave in the presence of dynamic loading?
To answer this you need to be precise about the semantics of what
is being dynamically loaded
proper code, in Haskell or C
:-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
with the right solution to a problem rather than picking some
easy way out.
BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's
not get too snobby about this. (Sorry, I couldn't resist.)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing
with interfacing with legacy code, it's a semantic
necessity and there's no legacy code involved.
If you want to dispute that then please show some real Haskell code that
does as good or better job without it (or point me too the relevant
legacy code that makes it necessary).
Regards
--
Adrian Hey
as you've introduced a very complex and
mysterious black box that itself cannot be implemented without making
use of global variables. You can find them easily enough in the Linux
kernel source. I'm sure they'll be there in NetBSD too (never looked
though).
Regards
--
Adrian Hey
, for example.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ashley Yakeley wrote:
Adrian Hey wrote:
Maybe it would be safest to just say anything with a finaliser can't be
created at the top level.
Do you have an example of something that is correctly ACIO to create,
but has a problematic finaliser?
Sorry for the delay in getting my attention. I've
,
rather then have an exported thing dissappear from the API at some
point.
My 2p..
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
in handy
if the user code decides it doesn't like the old ones for some
reason :-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
. We can always define an appropriate top level
get IO action using runOnce or whatever.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
does top level - declarations take us away from it?
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
hack might be a good place to start. I'll even let you change the API
of these libs if you must, provided you can give a sensible explanation
why the revised API is better, safer, more convenient or whatever.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing
think about how finalisers
get run I'm inclined to think we should insist that they are ACIO too.
Regards
--
Adrian Hey
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
think about how finalisers
get run I'm inclined to think we should insist that they are ACIO too.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
too IMO).
I also think Neils idea of breaking darcs up from 1 monolithic prog
to a darcs lib suite is a good idea. This would give decent haddock
documentation for most of the code base and an easy way to have
multiple user interfaces (gui/web/command line based).
Regards
--
Adrian Hey
the register allocation right (which is not hard on the ARM) you
could construct the overwhelming majority of heap records using a single
STMIA instruction. Almost seemed like it's instruction set was
designed for efficient FPL implementation :-)
Regards
--
Adrian Hey
, provided not too much
has happened in between, they should be very fast as the nodes on
the path are probably still in cache. The important thing is that
in the case where Nothing is returned you'll have burned very little
heap.
Regards
--
Adrian Hey
ccing Haskell Cafe in case anyone else is interested in my answer..
Bryan O'Sullivan wrote:
Adrian Hey wrote:
I don't think anyone is interested in working on this or maintaining
it, so it's probably best not to use it for new stuff.
If nobody has stepped up yet, I'll take it over
to minimise
comparison counts (not execution times), which is the right thing to
do for polymorphic implementations.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
is interested in working on this or maintaining
it, so it's probably best not to use it for new stuff.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Jan-Willem Maessen wrote:
On Apr 24, 2008, at 11:33 AM, Adrian Hey wrote:
Also, if you're likely to be using union/intersection a lot you should
know that Data.Map/Set are very slow for this because they use the
not efficient hedge algorithm :-)
OK, I'm going to bite here: What's
suspect) AVL trees of unboxed Ints for simple keys (serialisable
as 1 machine word). This is what that GSoC project is all about.
At the moment we have the exact opposite, Tries for Ints and balanced
trees for non-trivial keys. Oh well..
Regards
--
Adrian Hey
and there are ghc extensions we'd
probably want to use for performance reasons (like unboxed Ints and
unboxed tuples).
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
to
install cygwin and learn how to use it just so they can build GH.
Thanks
--
Adrian Hey
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
are good/ok/bad? Not me I assume :-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
this is something for next years SOC?
That said, I know that type families are provisionally available, so
maybe doing something with generalised tries might be possible.
I don't mind mentoring anyone who wants to do something with any of
this.
Regards
--
Adrian Hey
in Hackage and propose
them for Haskell-prime (if that's still happening?)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
see nothing in the report to
indicate to me that Eq/Ord are those classes and consequently that
the naive programmers interpretation of (==) is incorrect. Rather
the contrary in fact.
Regards
--
Adrian Hey
Aaron Denney wrote:
On 2008-03-12, Adrian Hey [EMAIL PROTECTED] wrote:
Aaron Denney wrote
[EMAIL PROTECTED] wrote:
G'day all.
Adrian Hey wrote:
This might be a reasonable thing to say about *sortBy*, but not sort
as the ordering of equal elements should not be observable (for any
correct instance of Ord). It should be impossible to implement a
function which can discriminate
see nothing in the report to
indicate to me that Eq/Ord are those classes and consequently that
the naive programmers interpretation of (==) is incorrect. Rather
the contrary in fact.
Regards
--
Adrian Hey
Aaron Denney wrote:
On 2008-03-12, Adrian Hey [EMAIL PROTECTED] wrote:
Aaron Denney wrote
Luke Palmer wrote:
On Thu, Mar 13, 2008 at 1:00 AM, Adrian Hey [EMAIL PROTECTED] wrote:
AFAICT the report is ambiguous about this, or at least the non-intutive
equality semantics are not at all clear to me from what I can see in
the Eq class definition (para 6.3.1). I think an the absence
Luke Palmer wrote:
On Thu, Mar 13, 2008 at 3:02 AM, Adrian Hey [EMAIL PROTECTED] wrote:
The report doesn't state that for all Ints, (x==y = True) implies that
x=y. There's no reason to suppose the Int instance is in any way
special, so do you really seriously consider the possibility
, the report doesn't make this clear 1 way or another AFAICS.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
. But please don't insist that class must be Eq.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Denis Bueno wrote:
On Tue, Mar 11, 2008 at 4:01 AM, Adrian Hey [EMAIL PROTECTED] wrote:
and sorting is
meant to be a permutation, so we happily have the situation where this
has a correct answer: 2.
Anything else is incorrect.
Isn't 3 also a permutation? Why is it incorrect
Ketil Malde wrote:
Adrian Hey [EMAIL PROTECTED] writes:
So really I think the docs have this backwards. It's sortBy that
implements a stable sort (assuming a suitably sane comparison function
I guess) and apparently sort is whatever you get from (sortBy compare).
But this is unduly restrictive
Jules Bean wrote:
Adrian Hey wrote:
This might be a reasonable thing to say about *sortBy*, but not sort
as the ordering of equal elements should not be observable (for any
correct instance of Ord). It should be impossible to implement a
function which can discriminate between [a,a],[a,b],[b
conclusion from this that all (polymorphic) code
that assumes (x == y) = True implies x=y is inherently broken,
or is just this particular Eq instance that's broken?
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
Aaron Denney wrote:
On 2008-03-11, Adrian Hey [EMAIL PROTECTED] wrote:
Having tried this approach myself too (with the clone) I can confirm
that *this way lies madness*, so in future I will not be making
any effort to define or respect sane, unambiguous and stable behaviour
for insane Eq/Ord
Jonathan Cast wrote:
On 10 Mar 2008, at 4:00 AM, Adrian Hey wrote:
Neil Mitchell wrote:
2) What does it do with duplicate elements in the list? I expect it
deletes
them. To avoid this, you'd need to use something like fromListWith,
keeping
track of how many duplicates
is an instance of Ord tells me nothing that I can rely on.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Adrian Hey wrote:
or specify and control the behaviour of their behaviour for such
instances.
Urk, sorry for the gibberish. I guess I should get into the habit of
reading what I write before posting :-)
Regards
--
Adrian Hey
___
Haskell-Cafe
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
recently some
function implementations in Data.Map we're actually broken wrt the
stated biasing policy (though few actually noticed this for obvious
reasons). Perhaps some still are? Who knows..
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell
or date
In such cases you should be using sortBy, not the overloaded sort
(you have several reasonable orderings for the same record type say).
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org
Ketil Malde wrote:
Adrian Hey [EMAIL PROTECTED] writes:
But seriously, once you admit the possibility that even if x == y it
still matters which of x or y is used in expressions than all hell
breaks loose. I shudder to think just how much Haskell code there must
be out there that is (at best
Denis Bueno wrote:
On Mon, Mar 10, 2008 at 10:10 AM, Adrian Hey [EMAIL PROTECTED] wrote:
The Eq instance you've given violates the law that (x == y) = True
implies x = y. Of course the Haskell standard doesn't specify this law,
but it should.
Unless I'm missing something obvious
not be an instance or
either class IMO.
If this was intended to be the case but in fact isn't the case, then
that's a bug.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
should be faster for
complex data types). We should only use sort = sortBy compare as
the default.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
-May/012470.html
The other big problem with stackgobbler in practice is the risk of
stack overflow. For p=15 it would not work at all for ghc default
stack limit.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
Philip Armstrong wrote:
On Mon, Feb 18, 2008 at 05:56:41PM +, Adrian Hey wrote:
Philip Armstrong wrote:
On Sun, Feb 17, 2008 at 10:01:14PM +, Adrian Hey wrote:
BTW, I find this especially ironic as fromDistinctAscList is the
perfect
example what I was talking about in another thread
the bug is in the ghc rts, not the
users source code most of the time :-(
I think at the minimum, the stack shrinking mod you suggested should
be implemented before the limit is removed.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing
Philip Armstrong wrote:
On Sun, Feb 17, 2008 at 10:01:14PM +, Adrian Hey wrote:
BTW, I find this especially ironic as fromDistinctAscList is the perfect
example what I was talking about in another thread (continuation passing
madness caused by an irrational fear of stack use).
In *some
as fromDistinctAscList is the perfect
example what I was talking about in another thread (continuation passing
madness caused by an irrational fear of stack use).
As to what's really going on here, I haven't figured it out and I'm not
really inclined to try :-)
Regards
--
Adrian Hey
should be designed so
that as far as is practical (given finite memory), any expression
that can be built on the heap can also be evaluated without causing
a stack overflow.
But I guess this rant is not much help to the OP :-)
Regards
--
Adrian Hey
Adrian Hey wrote:
AFAICT neilGobbler isn't even entirely safe as an implementation of
an eager take. There's nothing the Haskell standard to stop it being
transformed into..
neilGobbler :: Int - [x] - [x]
neilGobbler n xs = length (take n xs) `seq` take n xs
Whoops, I see stackGobbler has
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
as stackGobbler,
which would be the implementation of choice for both simplicity and
performance if it wasn't for this stack management problem.
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo
.
:-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Stefan O'Rear wrote:
On Mon, Feb 04, 2008 at 10:13:12PM +, Adrian Hey wrote:
Also
remember that this behaviour never wastes more than 50% of the stack,
which is a relatively small amount.
Only if the stack is relatively small. Would you say the same about
heap, or about a stack that only
of the compiler to do this :-(
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
?
Actually I think the latter option above might be good way to discover
how many bug free Haskell progs there really are out there. Precious
few I suspect :-(
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
way of doing it than deliberately inducing a crash in any
program that exceeds 8M of stack.
Thanks for the answer though. I think I'll write a ticket about this :-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
argue that
it has a bug if it uses a lot of memory with any plausible Haskell
implementation (one way or another) *and* you can show that there is
an alternative implementation which uses asymptotically less memory.
Regards
--
Adrian Hey
___
Haskell
enough to make use of the stack.
So perhaps the current ghc defaults are too generous. What limit do you
think should be placed on the stack size that a non buggy program can
use?
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe
:-)
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
implements the stack as a reversed list accumulator, which then
has to be reversed at the end, so will burn twice as much heap
to get a result as stackGobbler (at least if we already know the
list has evaluated at least up to the point where it's tail get
chopped off).
Regards
--
Adrian Hey
rare. At least, far more common than whatever error
message you get from heap exhaustion (can't even remember the last
time I saw one of those).
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman
Wolfgang Jeltsch wrote:
Am Sonntag, 6. Januar 2008 13:37 schrieb Adrian Hey:
It's the GT class here..
Short remark: Wouldn’t a longer, more descriptive identifier be better?
Like GeeTee maybe? or even GeneralisedTrie?
I like short names myself. But as I have stopped work on this particular
of an easy workaround?
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
- Write a comprehensive test/benchmarking suite for GT instances.
3 - Provide some way to automatically generate the instances for
arbitrary user defined types.
Which is all rather a lot of work that nobody seems very interested
in :-(
Regards
--
Adrian Hey
Hello,
Why is it that the haddock docs supplied with GHC omit this module and
its exports? Is it because we're not supposed to use them? I'm thinking
of the compareInt# function in particular, which I use quite a lot.
Thanks
--
Adrian Hey
, unless you want a
pre-compiled windows version in which case you're stuck with 1.3 :-)
Anyone know what's going on?
Thanks
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
just doing more work!) then I'd love
to see a test case.
I wonder if this could be related to what I observed with AVL trees and
mentioned a while back (using a strict data type is slower than using
explicit seqs to get the same strictness).
Regards
--
Adrian Hey
Hello Folks,
Adrian Hey wrote:
If anyone is interested in the job then I
suggest they contact myself or Jean-Philippe Bernardy.
Sigh..no sooner than I go and write something like that than the IEE (or
I should say IET) go and break my mail alias. So sorry if anyone did
actually try to contact
these libs may feel they need from me. I might even contribute a
few patches from time to time myself :-)
Thanks
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
/012467.html
Regards
--
Adrian Hey
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
1 - 100 of 365 matches
Mail list logo
