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
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
Lennart == Lennart Augustsson lenn...@augustsson.net 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
Jon Fairbairn wrote:
John A. De Goes j...@n-brain.net 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
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,
Colin Paul Adams co...@colina.demon.co.uk writes:
Lennart == Lennart Augustsson lenn...@augustsson.net 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
Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com 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
John A. De Goes j...@n-brain.net 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
On Thu, Apr 23, 2009 at 6:30 AM, Richard O'Keefe o...@cs.otago.ac.nz 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 +
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
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 you
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
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
On Thu, Apr 23, 2009 at 12:39 PM, Claus Reinke claus.rei...@talk21.com 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
Daniel Fischer daniel.is.fisc...@web.de 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.
On 23 Apr 2009, at 9:02 pm, Lennart Augustsson wrote:
On Thu, Apr 23, 2009 at 6:30 AM, Richard O'Keefe o...@cs.otago.ac.nz
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
On 22 Apr 2009, at 13:07, Jon Fairbairn wrote:
Miguel Mitrofanov miguelim...@yandex.ru 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
Miguel Mitrofanov miguelim...@yandex.ru 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
On Wed, Apr 22, 2009 at 12:32 AM, Duncan Coutts duncan.cou...@worc.ox.ac.uk
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
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
duncan.cou...@worc.ox.ac.ukwrote:
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
Richard O'Keefe o...@cs.otago.ac.nz wrote:
On 21 Apr 2009, at 11:36 pm, Achim Schneider wrote:
Richard O'Keefe o...@cs.otago.ac.nz wrote:
Some of the right questions are
- how many potential whatever users would need to have
whatever installed on _some_ machine they do NOT
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
Claus Reinke claus.rei...@talk21.com 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
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
2009/04/22 Miguel Mitrofanov miguelim...@yandex.ru:
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
On 22 Apr 2009, at 21:19, Jason Dusek wrote:
2009/04/22 Miguel Mitrofanov miguelim...@yandex.ru:
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
On Wed, Apr 22, 2009 at 10:19 AM, Jason Dusek jason.du...@gmail.com wrote:
2009/04/22 Miguel Mitrofanov miguelim...@yandex.ru:
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.
On Wed, 2009-04-22 at 13:20 +0200, david48 wrote:
On Wed, Apr 22, 2009 at 1:01 PM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
On Wed, 2009-04-22 at 12:21 +0200, david48 wrote:
Lines starting with -- are comments. You need to uncomment the
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
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
On Mon, Apr 20, 2009 at 10:21 PM, Richard O'Keefe o...@cs.otago.ac.nz 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
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, there
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 goodie
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.
Richard O'Keefe o...@cs.otago.ac.nz 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
Edward Middleton emiddle...@bebear.net 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
Achim Schneider wrote:
Edward Middleton emiddle...@bebear.net 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
Richard O'Keefe o...@cs.otago.ac.nz wrote:
Some of the right questions are
- how many potential whatever users would need to have
whatever installed on _some_ machine they do NOT have
administrator access to?
Irrelevant.
- if people find Mac and Windows installers that show you
Edward Middleton emiddle...@bebear.net wrote:
Achim Schneider wrote:
Edward Middleton emiddle...@bebear.net 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
Achim Schneider bars...@web.de writes:
Richard O'Keefe o...@cs.otago.ac.nz 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
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
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
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.
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 overlap
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
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
On 21 Apr 2009, at 11:36 pm, Achim Schneider wrote:
Richard O'Keefe o...@cs.otago.ac.nz wrote:
Some of the right questions are
- how many potential whatever users would need to have
whatever installed on _some_ machine they do NOT have
administrator access to?
Irrelevant.
How van
On Tue, Apr 21, 2009 at 8:34 PM, Richard O'Keefe o...@cs.otago.ac.nz 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
On Tue, Apr 21, 2009 at 8:34 PM, Richard O'Keefe o...@cs.otago.ac.nz 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
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
Miguel Mitrofanov wrote:
Jon Fairbairn wrote on 20.04.2009 13:59:
Achim Schneider bars...@web.de writes:
Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:
a...@cs.uu.nl writes:
Utrecht Haskell Compiler -- first release, version 1.0.0
Achim Schneider bars...@web.de writes:
Jon Fairbairn jon.fairba...@cl.cam.ac.uk wrote:
a...@cs.uu.nl writes:
Utrecht Haskell Compiler -- first release, version 1.0.0
The UHC team is happy to announce the first
Achim Schneider wrote:
Don Stewart d...@galois.com 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
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
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.
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
miguelim...@yandex.ru wrote:
Well, the problem is that every implementor does choose a subset of standart
to implement.
It's much worse in
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
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
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?
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 something that
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:
On Apr 20, 2009, at 5:44 PM, David Leimbach wrote:
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:
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,
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
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
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 what
Brandon S. Allbery KF8NH allb...@ece.cmu.edu 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
Edward Middleton emiddle...@bebear.net 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,
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
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
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,
On Mon, Apr 20, 2009 at 9:45 PM, Miguel Mitrofanov
miguelim...@yandex.ru 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
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
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
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 Haskell98
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 apparently it's
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
Don Stewart d...@galois.com 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
Jon Fairbairn jon.fairba...@cl.cam.ac.uk 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
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
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 ?)
Because
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
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
Antoine Latter aslat...@gmail.com wrote:
On Sat, Apr 18, 2009 at 4:38 PM, Thomas Davie tom.da...@gmail.com
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,
95 matches
Mail list logo
