On 11-10-26 10:40 AM, Ben Millwood wrote:
I don't think this is foolproof, either. Correct me, anyone else, if
I'm wrong, but in some cases cabal will want to rebuild your packages
that came with GHC; sometimes this can involve breaking a package that
cannot be rebuilt (e.g. the ghc package depen
On Wed, Oct 26, 2011 at 1:26 AM, Claudio Nieder wrote:
> Hi,
>
> many thanks to all who answered my post, I learned a lot by reading them
> and the referenced web pages.
>
>> You probably have some packages of yours installed as user and some
>> others globally. Have a look at:
>>
>> http://www.h
Hi,
many thanks to all who answered my post, I learned a lot by reading them
and the referenced web pages.
> You probably have some packages of yours installed as user and some
> others globally. Have a look at:
>
> http://www.haskell.org/cabal/FAQ.html#dependencies-conflict
This explains wel
On 25 October 2011 09:34, Ben Millwood wrote:
> Here's the advice I use on when to use what to install cabal packages:
>
> http://www.vex.net/~trebla/haskell/sicp.xhtml
>
> I think it's a bit overcautious, but rather that than the alternative.
> It's worth a read even if you don't follow the advic
Here's the advice I use on when to use what to install cabal packages:
http://www.vex.net/~trebla/haskell/sicp.xhtml
I think it's a bit overcautious, but rather that than the alternative.
It's worth a read even if you don't follow the advice in the end.
On Mon, Oct 24, 2011 at 9:51 PM, Mike Meye
On Mon, Oct 24, 2011 at 2:17 AM, Thomas Friedrich wrote:
> You probably have some packages of yours installed as user and some
> others globally. Have a look at:
>
> http://www.haskell.org/cabal/FAQ.html#dependencies-conflict
>
> I recommend that as soon as you have a running Haskell Platform to
You probably have some packages of yours installed as user and some
others globally. Have a look at:
http://www.haskell.org/cabal/FAQ.html#dependencies-conflict
I recommend that as soon as you have a running Haskell Platform to
always install new packages with cabal install ... --user
Thomas
Hi,
I just get this output from cabal:
cabal install leksah
Resolving dependencies...
cabal: dependencies conflict: ghc-7.0.4 requires array ==0.3.0.3 however
array-0.3.0.3 was excluded because ghc-7.0.4 requires array ==0.3.0.2
How can it be that the same package (ghc-7.0.4) asks for two diff
What is the rationale for the requirement that, in order for
the ambiguous type of a numeric constant to be resolved by the
default declaration, all classes in the context must be in the
Standard Prelude or Standard Library (Revised Report 4.3.4)?
This makes it hard to introduce new polymorphic fun
please, whatever you do or even suggest doing to
layout rules, don't break the non-layout way.
--
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
The world has taken on a thickness of vulgarity that raises
a spiritual man'
> Can't we require that a local definition be more indented than the
> enclosing definition?
It is required in Haskell'98. You have stumbled on a bug in Hugs,
which you should report to the maintainers.
Regards,
Malcolm
___
Haskell mailing list
[E
Hi,
I have been a big fan of Haskell's layout rules, but was got by them
lately.
Here's what I was doing. I wrote something like:
> foo =
> ...
> where
> bar = ...
>
> ...
> -- 600 lines of Haskell code suppressed
>
> baz = ...
Unsurprisingly, w
Folks
Andrew Tolmach, Tony Hoare, and I are writing a paper about
rewrite rules in GHC -- the {-# RULES #-} stuff.
We'd like to report on practical experience of using rewrite rules.
Has anyone use them in practice? What's your experience?
Pls reply to me, to avoid clogging the list
r to think of this as straight-line
code with a `goto' jumping out part-way through. However much you
might want this Haskell source code to look like assembler, it's not
what the semantics of the language give you, and it's not what the
compiler is going to understand by your code
Malcolm writes:
> To be honest, I consider the first of these variants to be an ugly and
> confusing misuse of layout, and the second to be clear (if not the most
> beautiful way to code it). The first seems to be trying to simulate a
> C-style `return', which is in reality not at all like the t
#x27;98 rule.
Such is life.
Regards,
Malcolm
P.S. I think this is even clearer:
mcompare x y =
do i <- x ==~ y
if i then return EQ
else do i <- x <=~ y
return (if i then LT else GT)
Now if only the layout rules would allow the `else' to align
vertically with the `if'!
Malcolm Wallace wrote:
>
> | mcompare x y =
> | do i <- x ==~ y
> | if i then return EQ else do
> | i <- x <=~ y
> | if i then return LT else do
> | return GT
> | with strictly increasing indentation iut would have
ctly an extension to Haskell 98, but it
doesn't break any legal Haskell 98 programs (this is only for do
expressions, not for where etc.).
> P.S. I think this is even clearer:
> mcompare x y =
>do i <- x ==~ y
> if i then return EQ
>
Malcolm Wallace wrote:
> Mark P Jobes wrote:
>
> | Something like the following can be used in Hugs 98:
> |
> | f x = case x of
> | (a,b) -> case a of
> | (c,d) -> case b of
> | (e,f) -> [c,d,e,f]
>
> You can't be serious! This is a great example of mis-using layout t
Currently Hugs except the following piece of code but GHC does not:
mcompare x y =
do i <- x ==~ y
if i then return EQ else do
i <- x <=~ y
if i then return LT else do
return GT
However both except:
mcompar
uot; very often.
> Indeed. It can then simplify things further, using the rule
>
> x `seq` e ==> e if x is not _|_
How nice. Thank you.
To my mind, this consideration shows the wide applicability of rewrite
rules in compiling of functional programs. Just what i tried to prove.
--
Sergey Mechveliani
[EMAIL PROTECTED]
On 07-Jun-1999, S.D.Mechveliani <[EMAIL PROTECTED]> wrote:
> One more question on the program simplification and `bottom'.
>
> People say, that the transformations like x - x -> 0 :: Integer
> are hardly ever applicable, because x may occur `undefined'.
This issue was already resolved --
Concerning the simplification rules,
J|rgen Gustavsson <[EMAIL PROTECTED]> writes on 7 Jun 1999
> There is another problem lurking here as well. Namely space issues.
> Consider the following program. It runs in constant space.
>
> let { xs = 1..n; x = head xs } in x
One more question on the program simplification and `bottom'.
People say, that the transformations like x - x -> 0 :: Integer
are hardly ever applicable, because x may occur `undefined'.
Say,
(let n = -n in n - n :: Integer) = undefined
But consider the program
f,f' :: In
On Mon, 7 Jun 1999, S.D.Mechveliani wrote:
> One more question on the program simplification and `bottom'.
>
> People say, that the transformations like x - x -> 0 :: Integer
>
> are hardly ever applicable, because x may occur `undefined'.
There is another problem lurking here as well.
> There is another problem lurking here as well. Namely space issues.
> Consider the following program. It runs in constant space.
>
> let xs = 1..n
> x = head xs
> in x - x + last xs + x
>
> Now transforming it using
> M - M -> 0 and
> 0 + M -> M
> yields
>
> let xs = 1..n
> x = head
or example, different partial ordering rules for the
terms, one makes the equations to rewrite terms in different directions.
I suspect that adding to the user program equations the equations of
lambda calculus (substitution, abstraction, what else?) and setting
appropriate ordering, we obtain the re
To my
>> Another question on *rules*.
>> Could they help the implicit type casting?
>> For example, with
>> {rules Num a=> x::a, y::[a] ==> x+y = [x]+y}
>> instance Num a => Num [a] where ...
>> one
> >> {rules Num a=> x::a, y::[a] ==>
> x+y = [x]+y}
> >> instance Num a => Num [a] where ...
> >> one could expect for x :: Num b=>b the casting
> >>
Simon Peyton-Jones wrote:
>
> > Another question on *rules*.
> > Could they help the implicit type casting?
> > For example, with
> > {rules Num a=> x::a, y::[a] ==> x+y = [x]+y}
> > instance Num a =>
Another question on *rules*.
Could they help the implicit type casting?
For example, with
{rules Num a=> x::a, y::[a] ==> x+y = [x]+y}
instance Num a => Num [a] where ...
one could expect for x :: Num b=>b
> Another question on *rules*.
> Could they help the implicit type casting?
> For example, with
> {rules Num a=> x::a, y::[a] ==> x+y = [x]+y}
> instance Num a => Num [a] where ...
> one could expect for
Frank A. Christoph <[EMAIL PROTECTED]> writes
>> Sergey Mechveliani wrote:
>>
>> Adding *rules* to language would NOT cause scripting graphics via term
>> rewriting logic. I suppose, you know this.
>> If you do not set {rules..} in your program, you woul
aude when I first saw it, but I feel
Maude is less a programming language than it is an algebraic theorem
prover---its programs are not necessarily confluent.
> Sergey Mechveliani wrote:
>
> Adding *rules* to language would NOT cause scripting graphics via term
> rewriting logic. I suppo
I think that John Darlington's group at Imperial College were to first
to use rule driven program transformation in their various skelton/coordination
language parallelising compilers.
Here, Tore Bratvold used simple higher order function/composition
distribution transformation rules i
Thanks to everyone who has contributed to the discussion about
transformation rules. There is clearly something inteeresting
going on here!
There is clearly a huge spectrum of possibilities, ranging from
nothing at all to a full theorem-proving system. In adding rules
to GHC I'm tryi
Hello!
On Thu, May 06, 1999 at 09:26:15PM -0400, Arvind wrote:
> [...]
> The optimization " n+1 > n ==> True " is extremely useful in array
> subscript analysis, bounds checking etc. and is correct as long as n
> terminates (is not bottom). The cases where this optimization is used
> most often
Lennart Augustsson writes:
> Wolfram Kahl wrote:
>
> > In the end, my dreams even include a proof format
> > that can be checked by the compiler :-)
>
> Dependent types! That's all you need.
Absolutely!
I have read your Cayenne paper
( http://www.cs.chalmers.se/%7Eaugustss/cayenne/pape
Wolfram Kahl wrote:
> In the end, my dreams even include a proof format
> that can be checked by the compiler :-)
Dependent types! That's all you need.
--
-- Lennart
This is a reply to the notices by
David Barton <[EMAIL PROTECTED]>,
Jerzy Karczmarczuk <[EMAIL PROTECTED]>
on the (algebraic) *rules* in Haskell.
David Barton writes
> What began with a fairly limited, and practical, suggestion on Simon's
> part to a
When Simon P. Jones mentioned the *rules*,
i asked the list, why the examples deal only with transformations like
(map f).(map g) -> map (f.g),
why not deal with algebraic simplification, say,
(x^2+x+1)*(x-1) -> x^3-1.
And the language extens
ap addHaveANiceDay
> > [tip1,tip2,tip3,,tip_n]))
> >
> > will, if I understand correctly, transform given the rules
> > generally envisaged
> >
> > map f . map g ==> map (f.g)
> > map f (x:xs) ==> f x:map f xs
> >
> > into
> >
>
>The optimization " n+1 > n ==> True " is extremely useful in array
>subscript analysis, bounds checking etc. and is correct as long as n
>terminates (is not bottom). The cases where this optimization is used
>most often, n usually terminates. A more diligent compiler would use
>the optimization o
I am for sure going to read the paper of Ariola & Arvind, but
> Without optimizations this program will produce _|_ but
> with optimizations it will produce 3.
wouldn't such an optimisation be called "a bug in the compiler" ?
Bart Demoen
>On Thu, 6 May 1999 17:14:34 John Meacham wrote:
>On Thu, May 06, 1999 at 09:33:15PM +0200, Bart Demoen wrote:
>> > Without optimizations this program will produce _|_ but
>> > with optimizations it will produce 3.
>>
>> wouldn't such an optimisation be called "a bug in the compiler" ?
>or a b
On Thu, May 06, 1999 at 09:33:15PM +0200, Bart Demoen wrote:
> > Without optimizations this program will produce _|_ but
> > with optimizations it will produce 3.
>
> wouldn't such an optimisation be called "a bug in the compiler" ?
or a bug in the language design if it allows such things, It is
D. Tweed wrote:
>I'm as excited about the possibility of a limited form of compile time
>evaluation via rewrite rules but I'm a getting a bit worried that no-one
>has made any examples where there's an laziness to consider: I really
>wouldn't want semantic differ
I'm as excited about the possibility of a limited form of compile time
evaluation via rewrite rules but I'm a getting a bit worried that no-one
has made any examples where there's an laziness to consider: I really
wouldn't want semantic differences depending on the degr
More on rules and properties.
Imagine the improved language Haskell-2. I suggested for its library
(see "basic algebra proposal" on haskell.org)
the classes Additive (with +), Multiplicative (with *).
And it appears now, the implementors think of dealing with the rules.
This arrang
At 10:08 -0700 1999/05/04, peter <[EMAIL PROTECTED]> wrote:
>Hans aberg writes:
>When a group is expressed as a class G having operations e, *, and -1,
>then implicitly (via well defined semantics), a group is a quadruple,
>so I don't think the quadruple need be explicit in the Haskell program.
>T
At 11:02 + 1999/05/03, Wolfram Kahl wrote:
>With respect to the new RULES mechanism presented by
>Simon Peyton Jones (Thu, 22 Apr 1999),
>Carsten Schultz <[EMAIL PROTECTED]> writes
> > [...]
> > > And what about algebraic simplification? Say,
> > Th
Hans aberg writes:
>
> For expressing algebraic relations, I think one can use universal algebra
> by factoring through the free universal algebra of a particular set of
> relations. For example, if one wants to state that a binary operator is
> commutative, one can say that is should be defin
Mark P Jones <[EMAIL PROTECTED]> writes:
>
...
>
> [Aside: As a general comment to all readers of the Haskell mailing
> list, perhaps I can suggest: if you've posted something to the list
> within the last two weeks, and it hasn't received the kind of
> response that you were expecting, then
I've seen a couple of messages now about Simon's proposal for
a RULES mechanism in Haskell, but it's clear that I've missed
several of the messages, including the original proposal. I
suspect this is a result of recent changes in the way that the
list is handled, which shoul
With respect to the new RULES mechanism presented by
Simon Peyton Jones (Thu, 22 Apr 1999),
Carsten Schultz <[EMAIL PROTECTED]> writes
> [...]
> > And what about algebraic simplification? Say,
> The same applies to our beloved monads.
> The compiler could be told
Wolfram Kahl writes:
>
>
> One might even imagine extended instance declarations
> like the following:
>
> > instance Monad []
> > {-# PROOF
> > "Monad-rightId"
> > forall f.f >>= return
> > = concat (map return f)
> > = concat (map (:[]) f)
> > =
encourage
me to look one more time at the Hugs source code to see if I can
think of a way to support these rules.
All the best,
Mark
> Simon's latest report changes the relationship between monomorphism
> and defaulting. This issue was never discussed at length by the
> committee so I think I'll bring the discussion out here.
John objected quite strongly to changing the way top-level monomorphism
is resolved. I count the vo
On 14-Dec-1998, John C. Peterson <[EMAIL PROTECTED]> wrote:
> The old Hugs system implemented this new rule, rather by accident,
> so I think we can say that this new rule has been thoroughly "tested".
> My experience is that it is major pain in the ass, not an
> improvement.
By "The old Hugs s
> Simon's latest report changes the relationship between monomorphism
> and defaulting. This issue was never discussed at length by the
> committee so I think I'll bring the discussion out here.
>
...
>
> Please take the time look into this issue and voice your opinions.
Let me second John's r
I can't speak for Hugs 1.3c, but Hugs 1.4 and prior systems use the
proposed monomorphism rule, not the Haskell 1.4 rule.
John
rence on y, resulting in a type error. This
appears to be the case whether or not x is exported. In an inner
declaration group, though, the old Haskell 1.4 rules apply, so that
let x = 1.0
y :: Float
y = x + 1
in ...
remains valid. The current version of the report (3rd revision) is
incorre
62 matches
Mail list logo
