Antoine Latter wrote:
> On Sat, Apr 18, 2009 at 4:38 PM, Thomas Davie
> wrote:
> >
> > This looks like the same error I got ___ see bug report 1 in the bug
> > database ___ the configure script reports that you have uuagc even if
> > you don't ___ cabal install it, reconfigure, and you should be
a...@cs.uu.nl writes:
> Utrecht Haskell Compiler -- first release, version 1.0.0
>
>
>
> The UHC team is happy to announce the first public release of the
> Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell9
Thomas Davie schrieb:
>
> On 19 Apr 2009, at 00:31, Antoine Latter wrote:
>
>> ...
>> Apparently a "user" install of uuagc and fgl isn't good enough. Fun
>> to know.
>
> I've found user installs don't work at all on OS X, various people in
> #haskell were rather surprised to discover this, so app
a...@cs.uu.nl schrieb:
Utrecht Haskell Compiler -- first release, version 1.0.0
The UHC team is happy to announce the first public release of the
Utrecht Haskell Compiler (UHC).
Great to see another haskell compil
Don Stewart wrote:
> This means that 'cabal
> install' works out of the box on every system, without needing
> admin/root privs (esp. important for students).
>
...and people who were bitten by sanity and thus never, ever touch /usr
manually, only through their distribution's package manager.
Th
Jon Fairbairn wrote:
> a...@cs.uu.nl writes:
>
> > Utrecht Haskell Compiler -- first release, version 1.0.0
> >
> >
> >
> > The UHC team is happy to announce the first public release of the
> > Utrecht Haskell Compiler (UHC
Yes, it is bad that the runhaskell Setup interface has a different default. But, as Duncan
said, too late to change it now.
Why, especially as it seems something you would now rarely use directly ? (When
would you want it ?)
___
Haskell-Cafe mailing
I meant, why is it too late to change the Setup interface to match cabal's
--user by default behaviour ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Achim Schneider writes:
> Jon Fairbairn wrote:
>
>> a...@cs.uu.nl writes:
>>
>> >Utrecht Haskell Compiler -- first release, version 1.0.0
>> >
>> >
>> >
>> > The UHC team is happy to announce the first public release of the
I'm sorry, there is no such animal as "safe" global installation,
in the sense of "download this one package and do what it says."
Well I have been doing that for more then 10 years, it is one of the
functions any decent package management systems is designed to do.
Time to adopt another good
"Richard O'Keefe" wrote:
> > This is good advice (/usr/local is fine though).
>
> Actually, no, it isn't.
> To start with, these days it's chock full of stuff
> which is hardly less critical for system operation
> than anything you'll find in /bin.
>
More importantly, /usr/local is a bugger to
Edward Middleton wrote:
> > ghc 6.8.3 is /usr/bin/ghc on my office Mac, but nothing in the world
> > prevents there being some other program called ghc that would also
> > like to be there. Only by painstaking verification of a whole
> > bunch of applications together can one be confident of "sa
"Richard O'Keefe" wrote:
> Some of the right questions are
> - how many potential users would need to have
> installed on _some_ machine they do NOT have
> administrator access to?
>
Irrelevant.
> - if people find Mac and Windows installers that show you where
> something is go
Edward Middleton wrote:
> Achim Schneider wrote:
> > Edward Middleton wrote:
> >
> >
> >>> ghc 6.8.3 is /usr/bin/ghc on my office Mac, but nothing in the
> >>> world prevents there being some other program called ghc that
> >>> would also like to be there. Only by painstaking verification of
Miguel Mitrofanov writes:
> Well, the problem is that every implementor does choose a
> subset of standart to implement.
That's what I'm complaining about.
> It's much worse in JavaScript - essential features working
> differently in Internet Explorer, Firefox, Opera, and
> Safari, and sometime
"Richard O'Keefe" wrote:
> On 21 Apr 2009, at 11:36 pm, Achim Schneider wrote:
>
> > "Richard O'Keefe" wrote:
> >
> >> Some of the right questions are
> >> - how many potential users would need to have
> >> installed on _some_ machine they do NOT have
> >>administrator access to
"Claus Reinke" wrote:
> [...]
>
+1. That, and better error messages: A Verbose-Consequences flag in the
config (on by default), resulting in strings like "Binaries have been
installed to $HOME/.cabal/bin and _not_ symlinked. $HOME/.cabal/bin is
not in your $PATH: You will not be able to call them
"Richard O'Keefe" et all wrote:
> [n+k patterns]
>
I'd like to add my two cents: Assuming that UHC's roadmap strives to be
H'-compilant in the future, and n+k patterns aren't going to be in H',
why bother implementing them?
Also, assuming that current H98 code will be ported to H', shouldn't
n+k
Colin Paul Adams writes:
>> "Lennart" == Lennart Augustsson writes:
>
> Lennart> Of course, n+k will be missed by Haskell obfuscators. I
> Lennart> mean, what will we do without (+) + 1 + 1 = (+) ?
>
> I think what would be missed would you be having the opportunity to
> explain to
"Sittampalam, Ganesh" writes:
> Jon Fairbairn wrote:
>> But we can remove them in future language versions. The point I was
>> trying to make at the beginning of this subthread was that
>> implementations should follow the definition, because having a core
>> language (Haskell 98) that can be rel
"John A. De Goes" writes:
> That's absurd. You have no way to access private source
> code, so any decision on what features to exclude from
> future versions of Haskell must necessarily look at
> publicly accessible source code.
This is all entirely beside the point. The question is not
wheth
Daniel Fischer wrote:
> Well, if it doesn't implement the full standard, perhaps it should
> rather be called UVNABNQHC (Utrecht very nearly, almost but not quite
> Haskell compiler)?
Ha! Haskell™!
I said it first, and rule that...
I don't care what you use the name for. Everyone is free to ma
Am Sonntag 19 April 2009 18:28:18 schrieb Simon Michael:
> > Yes, it is bad that the runhaskell Setup interface has a different
> > default. But, as Duncan said, too late to change it now.
>
> Why, especially as it seems something you would now rarely use directly ?
> (When would you want it ?)
>
On Sun, 2009-04-19 at 11:47 -0700, Simon Michael wrote:
> I meant, why is it too late to change the Setup interface to match
> cabal's --user by default behaviour ?
All the distro packages etc use the Setup.hs interface without
explicitly specifying --global.
Duncan
_
On 20 Apr 2009, at 12:52 am, Achim Schneider wrote:
Why? Is there something about Haskell 98 that's hard to
implement?
Insanity. I doubt anyone is going to miss n+k patterns:
They are one of my favourite features.
They express briefly and neatly what would otherwise
take several separate ste
I disagree. First of all, UHC states explicitly that some features are not supported (and probably never would be). Secondly, it seems like
almost nobody uses (n+k)-patterns, and when they are used, they make the code less readable; so it's good NOT to support them, in order to make
programmers a
Miguel Mitrofanov wrote:
> Jon Fairbairn wrote on 20.04.2009 13:59:
>> Achim Schneider writes:
>>
>>> Jon Fairbairn wrote:
>>>
a...@cs.uu.nl writes:
> Utrecht Haskell Compiler -- first release, version 1.0.0
> ==
Achim Schneider wrote:
Don Stewart wrote:
This means that 'cabal
install' works out of the box on every system, without needing
admin/root privs (esp. important for students).
...and people who were bitten by sanity and thus never, ever touch /usr
manually, only through their distribution's
I agree in principle; you should really implement the full Haskell98
if you claim to be a Haskell implementation.
In the particular case of n+k I don't care, since I never use them and
they are slated for removal in Hakell'.
-- Lennart
On Mon, Apr 20, 2009 at 11:59 AM, Jon Fairbairn
wrote:
> A
Hello Jon,
Monday, April 20, 2009, 1:59:07 PM, you wrote:
> It's not an implementor's place to make such decisions --
> they can legitimately say "this feature sucks" and tell the
> next Haskell committee so. If they care enough about it,
> they can lobby or get on that next committee, but the
>
If every implementor got to choose what subset of the standard to
implement that all code would have have to written in the implemented
intersection. I think that's a terrible idea.
The Haskell98 standard was set so there would be a baseline that
people could rely on.
When I implemented Haskell (
Well, the problem is that every implementor does choose a subset of standart to
implement.
It's much worse in JavaScript - essential features working differently in Internet Explorer, Firefox, Opera, and Safari, and sometimes they even
differ between versions; Web programmers still manage. (n+k
I don't think that other languages failing should be an excuse for
Haskell to be equally bad.
On Mon, Apr 20, 2009 at 1:23 PM, Miguel Mitrofanov
wrote:
> Well, the problem is that every implementor does choose a subset of standart
> to implement.
>
> It's much worse in JavaScript - essential feat
Me neither; there were actually two points:
1) It's not bad; at least, it's not bad for reasons you provide.
2) It would be here whether we like it or not.
Lennart Augustsson wrote on 20.04.2009 15:31:
I don't think that other languages failing should be an excuse for
Haskell to be equally bad
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I always think
twice when I see something that isn't Haskell 98 in my stack.
Anything that doesn't conform completely to Haskell 98 can effectively be
considered not Hask
David Leimbach wrote:
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I always
think twice when I see something that isn't Haskell 98 in my stack.
Do you not use Hugs for the same reason?
http://cvs.haskell.org/H
> > Just refuse to use UHC until it conforms.
> Do you not use Hugs for the same reason?
Not to mention that GHC does not comply with the H'98 standard either:
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html#vs-Haskell-defn
Regards,
Malcolm
___
On Mon, Apr 20, 2009 at 8:19 AM, Martijn van Steenbergen <
mart...@van.steenbergen.nl> wrote:
> David Leimbach wrote:
>
>> Just refuse to use UHC until it conforms. One can refuse to use GHC
>> libraries that use extensions as well for similar reasons. I always think
>> twice when I see somethin
On Mon, Apr 20, 2009 at 8:38 AM, Malcolm Wallace <
malcolm.wall...@cs.york.ac.uk> wrote:
> > > Just refuse to use UHC until it conforms.
> > Do you not use Hugs for the same reason?
>
> Not to mention that GHC does not comply with the H'98 standard either:
>
>
> http://www.haskell.org/ghc/docs/lat
On Apr 20, 2009, at 5:44 PM, David Leimbach wrote:
On Mon, Apr 20, 2009 at 8:38 AM, Malcolm Wallace > wrote:
> > Just refuse to use UHC until it conforms.
> Do you not use Hugs for the same reason?
Not to mention that GHC does not comply with the H'98 standard either:
http://www.haskell.org
On 20 Apr 2009, at 10:12 pm, Miguel Mitrofanov wrote:
I disagree. First of all, UHC states explicitly that some features
are not supported (and probably never would be). Secondly, it seems
like almost nobody uses (n+k)-patterns,
How can you possibly know that?
and when they are used, the
On 20 Apr 2009, at 10:27 pm, Jules Bean wrote:
This is good advice (/usr/local is fine though).
Actually, no, it isn't.
To start with, these days it's chock full of stuff
which is hardly less critical for system operation
than anything you'll find in /bin.
More importantly, it's not a place t
On Apr 20, 2009, at 10:46 , David Leimbach wrote:
Just refuse to use UHC until it conforms. One can refuse to use GHC
libraries that use extensions as well for similar reasons. I
always think twice when I see something that isn't Haskell 98 in my
stack.
So you don't use hierarchical lib
Richard O'Keefe wrote:
> On 20 Apr 2009, at 10:27 pm, Jules Bean wrote:
>> However, the point here is surely that the de-facto default for all
>> other downloaded programs - standard makefile setups, automake,
>> autoconf, perl package, python packages, graphic installers like
>> firefox - is do to
"Brandon S. Allbery KF8NH" writes:
> On Apr 20, 2009, at 10:46 , David Leimbach wrote:
>
> Just refuse to use UHC until it conforms. One can refuse to use GHC
> libraries that use extensions as well for similar reasons. I always think
> twice when I see something that isn't Haskell
Edward Middleton writes:
> Richard O'Keefe wrote:
>> On 20 Apr 2009, at 10:27 pm, Jules Bean wrote:
>>> However, the point here is surely that the de-facto default for all
>>> other downloaded programs - standard makefile setups, automake,
>>> autoconf, perl package, python packages, graphic inst
On 21 Apr 2009, at 04:59, Richard O'Keefe wrote:
On 20 Apr 2009, at 10:12 pm, Miguel Mitrofanov wrote:
I disagree. First of all, UHC states explicitly that some features
are not supported (and probably never would be). Secondly, it seems
like almost nobody uses (n+k)-patterns,
How can y
Richard O'Keefe wrote:
However, the point here is surely that the de-facto default for all
other downloaded programs - standard makefile setups, automake,
autoconf, perl package, python packages, graphic installers like
firefox - is do to what cabal calls a 'global' install by default.
The as
On 21 Apr 2009, at 4:52 pm, Jules Bean wrote:
The point I was making, which is scarcely important enough to bother
explaining again, is that having the same *default* as other
software is a virtue.
That point is mistaken.
I have no idea how many people are unable to use that default,
but
On Mon, Apr 20, 2009 at 9:45 PM, Miguel Mitrofanov
wrote:
>
> On 21 Apr 2009, at 04:59, Richard O'Keefe wrote:
>
>>
>> On 20 Apr 2009, at 10:12 pm, Miguel Mitrofanov wrote:
>>
>>> I disagree. First of all, UHC states explicitly that some features are
>>> not supported (and probably never would be)
On 21 Apr 2009, at 2:10 pm, Edward Middleton wrote:
Richard O'Keefe wrote:
The assumption here seems to be that everyone owns their own machine
or has a system adminstrator with large amounts of free time on their
hands. Just because a lot of other people are doing something crazy
doesn't me
On 21 Apr 2009, at 5:10 pm, Jason Dagit wrote:
Plus, there was a movement to ban them:
And somehow this means people don't?
BUT, here is the real point of my reply:
To end this debate as to whether people really use them. We have this
huge collection of source code called Hackage. I bet th
On Mon, Apr 20, 2009 at 10:21 PM, Richard O'Keefe wrote:
>
> On 21 Apr 2009, at 5:10 pm, Jason Dagit wrote:
>>
>> Plus, there was a movement to ban them:
>
> And somehow this means people don't?
...see the humor.
>>
>> BUT, here is the real point of my reply:
>>
>> To end this debate as to wheth
Richard O'Keefe wrote:
> On 21 Apr 2009, at 2:10 pm, Edward Middleton wrote:
>> Using non-standard installation methods makes it harder for package
>> maintainers to package the application and suggests you haven't taken
>> any care / don't care about making global installation safe.
>
> I'm sorry,
For what it's worth, It's bothered me often enough that cabal doesn't
install globally by default that I had to reinstall ghc in order to solve
package issues.
So I'd prefer the default to be global.
But I don't care that much, I don't think arguing that point is leading
anywhere.
___
Achim Schneider wrote:
> Edward Middleton wrote:
>
>
>>> ghc 6.8.3 is /usr/bin/ghc on my office Mac, but nothing in the world
>>> prevents there being some other program called ghc that would also
>>> like to be there. Only by painstaking verification of a whole
>>> bunch of applications toget
Achim Schneider writes:
> "Richard O'Keefe" wrote:
>
>> > This is good advice (/usr/local is fine though).
>>
>> Actually, no, it isn't.
>> To start with, these days it's chock full of stuff
>> which is hardly less critical for system operation
>> than anything you'll find in /bin.
>>
> More
Maybe it has gone unnoticed, but the main reason we made the compiler
available, was to make it possible for others to experiment with its
type extensions, its Grin based back-end and to show the advantages
(and disadvantages?) of generating large part of the compiler from an
attribute gra
On Tue, 2009-04-21 at 12:31 +0200, david48 wrote:
> For what it's worth, It's bothered me often enough that cabal doesn't
> install globally by default that I had to reinstall ghc in order to
> solve package issues.
Do you know what the problem was exactly? It's possible to get problems
with overl
On 21 Apr 2009, at 7:39 pm, Jason Dagit wrote:
Not really. Obviously some programs use the feature, but let us
restrict to interesting programs that have been shared with the world
and have some potential to receive maintenance.
Why?
You are, in effect, saying that my code has no value at al
On 21 Apr 2009, at 8:20 pm, Edward Middleton wrote:
ghc 6.8.3 is /usr/bin/ghc on my office Mac, but nothing in the world
prevents there being some other program called ghc that would also
like to be there. Only by painstaking verification of a whole
bunch of applications together can one be con
On 21 Apr 2009, at 11:36 pm, Achim Schneider wrote:
"Richard O'Keefe" wrote:
Some of the right questions are
- how many potential users would need to have
installed on _some_ machine they do NOT have
administrator access to?
Irrelevant.
How van the question that is the very hear
On Tue, Apr 21, 2009 at 8:34 PM, Richard O'Keefe wrote:
>
> On 21 Apr 2009, at 7:39 pm, Jason Dagit wrote:
>>
>> Not really. Obviously some programs use the feature, but let us
>> restrict to interesting programs that have been shared with the world
>> and have some potential to receive maintenan
On Tue, Apr 21, 2009 at 8:34 PM, Richard O'Keefe wrote:
>
> On 21 Apr 2009, at 7:39 pm, Jason Dagit wrote:
>>
>> Not really. Obviously some programs use the feature, but let us
>> restrict to interesting programs that have been shared with the world
>> and have some potential to receive maintenan
On 22 Apr 2009, at 13:07, Jon Fairbairn wrote:
Miguel Mitrofanov writes:
Well, the problem is that every implementor does choose a
subset of standart to implement.
That's what I'm complaining about.
And that's exactly what you (or anybody else) can't do anything about
(thank God for th
On Wed, Apr 22, 2009 at 12:32 AM, Duncan Coutts wrote:
> On Tue, 2009-04-21 at 12:31 +0200, david48 wrote:
> > For what it's worth, It's bothered me often enough that cabal doesn't
> > install globally by default that I had to reinstall ghc in order to
> > solve package issues.
>
> Do you know wh
On Wed, 2009-04-22 at 12:21 +0200, david48 wrote:
> Do you know what the problem was exactly? It's possible to get
> problems with overlap between the user and global package dbs,
> but the exact same problems can also happen just within the
> global package db.
>
On Wed, Apr 22, 2009 at 1:01 PM, Duncan Coutts
wrote:
> On Wed, 2009-04-22 at 12:21 +0200, david48 wrote:
>
> Lines starting with -- are comments. You need to uncomment the prefix
> line for it to have an effect.
Man do I feel dumb now :)
David.
___
Installing executable(s) in /home/david/.cabal/bin
why the hell would cabal install binaries in a subdirectory of a
hidden directory. Why not /home/david/bin or /home/david/local/bin ?
Yes, this is clearly suboptimal but getting agreement on where to put it
has not proved easy. There are users t
That's absurd. You have no way to access private source code, so any
decision on what features to exclude from future versions of Haskell
must necessarily look at publicly accessible source code. The only
alternative is to continuously add, and never remove, features from
Haskell, even if
2009/04/22 Miguel Mitrofanov :
>> It's arrogant and disrespectful on the part of the
>> implementors to say that they know better than the committee
>> what features should be part of the language.
>
> It's arrogant and disrespectful on the part of the committee
> to say that they know better than
On 22 Apr 2009, at 21:19, Jason Dusek wrote:
2009/04/22 Miguel Mitrofanov :
It's arrogant and disrespectful on the part of the
implementors to say that they know better than the committee
what features should be part of the language.
It's arrogant and disrespectful on the part of the committ
On Wed, Apr 22, 2009 at 10:19 AM, Jason Dusek wrote:
> 2009/04/22 Miguel Mitrofanov :
> >> It's arrogant and disrespectful on the part of the
> >> implementors to say that they know better than the committee
> >> what features should be part of the language.
> >
> > It's arrogant and disrespectfu
On Wed, 2009-04-22 at 13:20 +0200, david48 wrote:
>
>
> On Wed, Apr 22, 2009 at 1:01 PM, Duncan Coutts
> wrote:
>
> On Wed, 2009-04-22 at 12:21 +0200, david48 wrote:
>
>
> Lines starting with -- are comments. You need to uncomment the
> prefix l
It's irrelevant, because I _do_ have root access to my machine,
How nice to be you.
Since the argument is entirely about people who _don't_,
your point it?
It is clear that the only sensible default is no default.
Someone else has said it recently and said it much better.
I think the right
On 23 Apr 2009, at 2:09 am, John A. De Goes wrote:
That's absurd. You have no way to access private source code,
Right.
so any decision on what features to exclude from future versions of
Haskell must necessarily look at publicly accessible source code.
Wrong. There is no "necessarily"
On 23 Apr 2009, at 2:24 am, Achim Schneider wrote:
"Richard O'Keefe" et all wrote:
[n+k patterns]
I'd like to add my two cents: Assuming that UHC's roadmap strives to
be
H'-compilant in the future, and n+k patterns aren't going to be in H',
why bother implementing them?
Haskell' is a mo
> "Lennart" == Lennart Augustsson writes:
Lennart> Of course, n+k will be missed by Haskell obfuscators. I
Lennart> mean, what will we do without (+) + 1 + 1 = (+) ?
I think what would be missed would you be having the opportunity to
explain to me what it means.
But as we still hav
Jon Fairbairn wrote:
> "John A. De Goes" writes:
>
>> That's absurd. You have no way to access private source code, so any
>> decision on what features to exclude from future versions of Haskell
>> must necessarily look at publicly accessible source code.
>
> This is all entirely beside the poin
Let me parenthesise and rename
(n + 1) +++ 1 = n
This defines a function +++, first argument is a n+1 pattern, second
argument is 1.
In the same way,
(+) + 1 + 1 = (+)
defines a function +, first argument is n+1 (but using (+) as n),
second argument is 1.
On Thu, Apr 23, 2009 at 10:27 AM, Col
On Thu, Apr 23, 2009 at 6:30 AM, Richard O'Keefe wrote:
> - a somewhat bogus claim about how much of the library you need to
> know how to use it (of COURSE you need to know about integers in
> order to use an integer operation, what's so bad about that?)
> - the claim that + doesn't mean +
On Apr 22, 2009, at 11:30 PM, Richard O'Keefe wrote:
so any decision on what features to exclude from future versions of
Haskell must necessarily look at publicly accessible source code.
Wrong. There is no "necessarily" about it. People made decisions
about what to deprecate in the Fortran
Let's turn this around. You invest 4 months of your life coming out
with your own experimental Haskell compiler designed to easily test
new language features. Then a bunch of ungrateful wretches on Haskell
Cafe demand that you stop distributing your compiler until you have
full support fo
Am Donnerstag 23 April 2009 16:13:36 schrieb John A. De Goes:
> Let's turn this around. You invest 4 months of your life coming out
> with your own experimental Haskell compiler designed to easily test
> new language features. Then a bunch of ungrateful wretches on Haskell
> Cafe demand that
On Thu, Apr 23, 2009 at 05:30:52PM +1200, Richard O'Keefe wrote:
> Is there a simple way to download everything from Hackage?
There's a link on the HackageDB introduction page.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org
Let's turn this around. You invest 4 months of your life coming out
with your own experimental Haskell compiler designed to easily test
new language features. Then a bunch of ungrateful wretches on Haskell
Cafe demand that you stop distributing your compiler until you have
full support for Hask
On Thu, Apr 23, 2009 at 12:39 PM, Claus Reinke wrote:
...
> joking and bikeshedding aside:
>
> - Haskell'98 is a fixed standard. Haskell'98 (revised) is a revised version
> of
> the same standard. The discussion on what is in either is over. Unless
> someone wants to start and edit a new revisio
On 23 Apr 2009, at 9:02 pm, Lennart Augustsson wrote:
On Thu, Apr 23, 2009 at 6:30 AM, Richard O'Keefe
wrote:
- a somewhat bogus claim about how much of the library you need to
know how to use it (of COURSE you need to know about integers in
order to use an integer operation, what's so
On 23 Apr 2009, at 9:45 pm, Lennart Augustsson wrote:
(+) + 1 + 1 = (+)
The thing that is bad about this is that it binds the
same identifier "+" twice in the head, to two different
things. It's not really any different from
(+) + 1 = (+)
which doesn't have anything to do with n+k
On 24 Apr 2009, at 2:13 am, John A. De Goes wrote:
Let's turn this around. You invest 4 months of your life coming out
with your own experimental Haskell compiler designed to easily test
new language features. Then a bunch of ungrateful wretches on
Haskell Cafe demand that you stop distr
On 24 Apr 2009, at 3:23 am, Ross Paterson wrote:
On Thu, Apr 23, 2009 at 05:30:52PM +1200, Richard O'Keefe wrote:
Is there a simple way to download everything from Hackage?
There's a link on the HackageDB introduction page.
Got it. Thanks!
___
Unfortunately I think 4 man years is definitely below the minimum of
the guesses I would get if I would ask the people in my group ;-}
Doaitse
On 23 apr 2009, at 16:13, John A. De Goes wrote:
Let's turn this around. You invest 4 months of your life coming out
with your own experimental H
Hello S.,
Tuesday, April 21, 2009, 5:42:15 PM, you wrote:
> If we had been interested in raising fierce discussions about n+k
> patterns or how and where cabal installs things, we could have easily
> achieved the same effect with much less effort.
you mean that we should shoot up? :)
--
Best
If we had been interested in raising fierce discussions about n+k
patterns or how and where cabal installs things, we could have easily
achieved the same effect with much less effort.
you mean that we should shoot up? :)
If the release of UHC contributes to whatever discussion regarding
Hask
I think the only way your release is going to get significant feedback
is when it's ready to compile substantial existing Haskell programs
unaltered.
I might try UHC on some toy example for a few minuts, but if it falls
over when I give it code that I've already written I'll soon give up
using it.
95 matches
Mail list logo
