Is there any hope for a 6.4.1 installer (like there was for 6.4)? Right
now the downloads page has a link to darwinports, but that site only has
versions 6.2.2 and 6.3.
Thanks, John
___
Glasgow-haskell-bugs mailing list
aha! most probably it just takes much longer than i ever expected.
now i don't feel so bad about how long it takes to build tilt
fyi, i'm on a g5 with 2gb ram.
bob
On Oct 10, 2005, at 11:04 AM, Gregory Wright wrote:
On Oct 10, 2005, at 5:05 AM, Simon Peyton-Jones wrote:
Can
On 10 October 2005 14:22, John Reppy wrote:
Is there any hope for a 6.4.1 installer (like there was for 6.4)?
Right now the downloads page has a link to darwinports, but that site
only has versions 6.2.2 and 6.3.
Wolfgang posted packages a couple of weeks ago, I've just linked them
from the
Simon Marlow [EMAIL PROTECTED] writes:
I'm slightly inclined not to make this change, but I could be swayed if
there was enough interest in it. What I'm seeing so far is not
overwhelming support for the change. Simon PJ is in favour, though.
a.out is tradition, of course, but OTOH, I don't
Simon Marlow wrote:
On 11 October 2005 06:29, Tomasz Zielonka wrote:
[..]
Would you accept the patch?
I'm slightly inclined not to make this change, but I could be swayed if
there was enough interest in it. What I'm seeing so far is not
overwhelming support for the change. Simon PJ is in
On 11 October 2005 09:58, Ketil Malde wrote:
Simon Marlow [EMAIL PROTECTED] writes:
I'm slightly inclined not to make this change, but I could be swayed
if there was enough interest in it. What I'm seeing so far is not
overwhelming support for the change. Simon PJ is in favour, though.
On 11 October 2005 10:04, Christian Maeder wrote:
Simon Marlow wrote:
You can always use Cabal, BTW :)
ghc should supply it, too.
GHC does come with Cabal. ?
Cheers,
Simon
___
Glasgow-haskell-users mailing list
I'm afraid that GHC does not treat the interaction of type classes and
GADTs properly. Your example shows this up even more starkly than
usual: why should the IsZ thing work, but the Div one not work?
The right fix is alas not very simple, which is why I have not done it.
(It involves what
On 2005-10-11 at 09:49BST Simon Marlow wrote:
On 11 October 2005 06:29, Tomasz Zielonka wrote:
It wasn't meant to be a bug report, only a feature request ;-)
Actually, I was mostly interested if anyone would mind if GHC
chose the name based on the top-level module.
Would you accept
Hi,
SPJ wrote:
The right fix is alas not very simple, which is why I have not done
it. (It involves what Martin Sulzmann calls implication
constraints.) However, GADTs and type classes ought to be fine
together, and the fact that many people have reported bugs suggests
that the interaction
On Tue, 2005-10-11 at 10:45 +0100, Jon Fairbairn wrote:
On 2005-10-11 at 09:49BST Simon Marlow wrote:
On 11 October 2005 06:29, Tomasz Zielonka wrote:
It wasn't meant to be a bug report, only a feature request ;-)
Actually, I was mostly interested if anyone would mind if GHC
chose
On 11 October 2005 11:04, Duncan Coutts wrote:
I'd tend to agree.
It'd mean one less magic incantation to tell students when teaching
practicals (and one less thing for them to get wrong) if they can do:
ghc --make Main.hs
rather than
ghc --make Main.hs -o Main
(that's one
On 10/11/05, Simon Marlow [EMAIL PROTECTED] wrote:
Ok, let's close this bikeshed. Someone want to send us a patch?
I will try to do this, but I don't have a working PC at home at the moment.
Best regards
Tomasz
___
Glasgow-haskell-users mailing list
| I plan to tackle it in the next couple of months.
|
| Would this also address how plain old Algebraic Data Types and type
| classes work together? The issues seems related.
Well that's specified by Haskell 98, so I don't want to change it.
Instead, I propose to behave sensibly (i.e.
Hi,
While working on a toy compiler I realized that Data.Set.Set (Set) is not
an instance of the Functor class. In other words: 'fmap' is not defined
on it. I tried various ways of defining an instance but I failed. The
reason is quite interesting: Set is a type constructor (* - *) so it
On Tuesday 11 October 2005 18:16, Lajos Nagy wrote:
While working on a toy compiler I realized that Data.Set.Set (Set) is
not an instance of the Functor class. In other words: 'fmap' is not
defined on it. I tried various ways of defining an instance but I
failed. The reason is quite
On Mon, Oct 10, 2005 at 04:52:13PM +0100, Simon Marlow wrote:
There's no really deep reason for this choice, other than it being what
GHC does normally - i.e. the default binary has always been a.out
(main.exe on Windows) unless -o is given.
I don't see enough of a compelling reason to
Haskell Weekly News: October 11, 2005
Greetings, and thanks for reading the 11th issue of HWN, a weekly
newsletter for the Haskell community. Each Tuesday, new editions will be
posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The
Haskell
We show how to merge two folds into another fold
`elementwise'. Furthermore, we present a library of (potentially
infinite) ``lists'' represented as folds (aka streams, aka
success-failure-continuation--based generators). Whereas the standard
Prelude functions such as |map| and |take| transform
[EMAIL PROTECTED] writes:
Regarding argument 1: the value of |maxBound :: Int| is also the
function of the environment. Haskell98 Report says [p82, Section
6.4]
The finite-precision integer type Int covers at least the range
[ - 2^29 , 2^29 - 1 ]. As Int is an instance of the
On Wed, Oct 12, 2005 at 12:05:39AM -0400, David Menendez wrote:
In principle, you could use seperate types to distinguish floats with
different rounding modes, but I imagine this would be difficult or
annoying to implement.
I think it would make more sense to have different operations for each
-
Please accept our apologies if you have received multiple copies.
Please feel free to distribute it to those who might be interested.
-
Our apologies if you receive multiple copies of this e-mail.
** SECOND CALL FOR PARTICIPATION
Fourth International Symposium on
Formal Methods for Components and Objects
(FMCO 2005)
DATES 1 - 4
On Oct 9, 2005, at 11:32 PM, Ben Lippmeier wrote:
This sounds like a text-book space-leak caused by lazy evaluation.
In a lazy language, function evaluation is driven by the need to
perform IO. Because the first version of your program never prints
the parsed structure, the parser doesn't
On 11 October 2005 07:34, Young Hyun wrote:
What intuition should be my guide about the proper way of employing
lazy evaluation? It's not yet clear to me what you mean by the
system needs to hang onto all the input data It seems
counterintuitive for the evaluator to hang onto partially
Young Hyun wrote:
Here's what the program does. It reads a binary file containing a
large number of varying-length structured records. [...]
Unless I'm badly mistaken, nothing about fixArts suggests that it
would leak memory. So, it would appear parseArts is somehow to blame
for
Hi Young,
Just to give a somewhat different perspective, sometimes increasing
laziness is helpful for avoiding space problems--not really so much space
leaks as space wastage.
In this case, you probably can't afford to hold contents in memory at any
given time. So you need to be certain both
On Wed, Oct 05, 2005 at 10:53:01PM +0200, Nils Anders Danielsson wrote:
Most authors do put their papers on their web pages nowadays.
On a side note, it is a little strange that the research community
does the research, writes and typesets the papers, and does most (?)
of the arrangements
On 10/12/05, John Meacham [EMAIL PROTECTED] wrote:
I certainly think we should somehow centralize an index to papers onhaskell. I have found it extremely difficult to track down papers forauthors that have since moved out of academia or have passed on anddon't have their personal homepages with
29 matches
Mail list logo
