Re: [Haskell-cafe] ordNub

[Francesco Mazzoli]

At Sun, 14 Jul 2013 07:31:05 -0400,
Clark Gaebel wrote:
> Similarly, I've always used:
> 
> import qualified Data.HashSet as S
> 
> nub :: Hashable a => [a] -> [a]
> nub = S.toList . S.fromList
> 
> And i can't think of any type which i can't write a Hashable instance, so
> this is extremely practical.

Well, the above is not stable while Niklas’ is.  But I guess that’s not
the point of your message :).

I’ve always avoided “nub” too, and FWIW I’d like a constrained version
too—maybe avoiding Data.Set so that it could live in Data.List.  I think
Ord would be much better than Hashable, since it is 1. in “base” 2. much
more established and understood.

Although if you find yourself using “nub” too much you’re probably doing
something wrong...

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GADTs and pattern matching

[Francesco Mazzoli]

At Wed, 19 Jun 2013 06:59:00 -0400,
Brent Yorgey wrote:
> Yes, I was going to suggest switching the argument order before
> reading your message.  This is an interesting way in which you can
> observe that Haskell does not really have "multi-argument functions".
> All multi-argument functions are really one-argument functions which
> return functions.  So a function of type
> 
>   foo1 :: a -> (Foo a -> Int)
> 
> must take something of type a (for *any* choice of a, which the caller
> gets to choose) and return a function of type (Foo a -> Int).  *Which*
> function is returned (e.g. one that tries to pattern match on the Foo)
> makes no difference to whether foo1 typechecks.
> 
> On the other hand, a function of type
> 
>   foo2 :: Foo a -> (a -> Int)
> 
> receives something of type Foo a as an argument.  It may pattern-match
> on the Foo a, thus bringing into scope the fact that (a ~ Maybe v).
> Now when constructing the output function of type (a -> Int) it may
> make use of this fact.

Hi Brent,

Thanks for your answer.

I was reminded by shachaf on Haskell a few moments ago about the details
of pattern matching in GHC
.

However, I’d argue that the issue doesn’t have much to do with the fact
that Haskell has only ‘1 argument functions’, at least at the type
level.  It’s more about how Haskell treats pattern matching.

In Agda/Epigram/Idris pattern matching works the other way around: they
allow it only in top-level definitions, and every other kind of match
get desugared to a new top level definition.  Thus you can reason about
the constraints on all the arguments in a better way.  Lately I’ve grown
used to that kind of pattern matching :).

In Haskell however where you expect _|_ and diverging matches, so it
probably makes more sense to have matching like is is now, otherwise
you’d have to force arguments to get equalities concerning earlier
arguments and things would probably get really messy.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GADTs and pattern matching

[Francesco Mazzoli]

At Wed, 19 Jun 2013 10:03:27 + (UTC),
AntC wrote:
> Hi Francesco, I think you'll find that the 'annoyance' is nothing to do 
> with GADTs. I suggest you take the type signature off of foo1, and see 
> what type ghc infers for it. It isn't :: a -> Foo a -> Int.
> 
> [...]
>
> Yep, that message explains what's going on well enough for me.

Did you read the rest of the code?  That ought to work, because GHC
infers and uses the type equality (something like ‘v ~ Var v1’) and uses
it to coerce the ‘x’.

And, surprise surprise, if the argument order is switched, it works!

data Foo v where
Foo :: forall v. Foo (Maybe v)

foo1 :: Foo a -> a -> Int
foo1 Foo Nothing  = undefined
foo1 Foo (Just x) = undefined

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GADTs and pattern matching

[Francesco Mazzoli]

Hi list,

I have stumbled upon a strange annoyance:

{-# LANGUAGE GADTs #-}

data Foo v where
Foo :: Foo (Maybe v)

-- This doesn't work
foo1 :: a -> Foo a -> Int
foo1 Nothing  Foo = undefined
foo1 (Just x) Foo = undefined

-- This does
foo2 :: a -> Foo a -> Int
foo2 x Foo = foo2' x

foo2' :: Maybe a -> Int
foo2' Nothing  = undefined
foo2' (Just x) = undefined

The first definition fails with the error

Couldn't match expected type `a' with actual type `Maybe t0'
  `a' is a rigid type variable bound by
  the type signature for foo1 :: a -> Foo a -> Int
  at /tmp/foo_flymake.hs:8:9
In the pattern: Nothing
In an equation for `foo1': foo1 Nothing Foo = undefined

Now, GHC can clearly derive and use the type equalities correctly, given
that the second definition works, but why can’t I pattern match
directly?

Thanks,
Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Mutually recursive modules

[Francesco Mazzoli]

At Wed, 8 May 2013 09:46:08 +0300,
Roman Cheplyaka wrote:
> 
> I wonder whether it's always possible to break cycles using GHC's
> .hs-boot files.
> 
> Consider the following schematic example:
> 
>   module A where
> 
>   import B
> 
>   data A
> 
>   f :: B -> A
>   f = undefined B.g
> 
>   module B where
> 
>   import A
> 
>   data B
> 
>   g :: A -> B
>   g = undefined A.f
> 
> A.hs-boot must give a type signature for f, and since the signature
> contains 'B', it must import 'B'. Ditto for B.hs-boot — it must import
> 'A'.
> 
> Even if we treat all imports as {-# SOURCE #-}, there is still a cycle
> between the hs-boot files.
> 
> So, am I right in understanding that these recursive modules cannot be
> compiled by GHC at all?

This configuration works for me:

A.hs:

module A where
import B

data A

f :: B -> A
f = undefined B.g

A.hs-boot:

module A where

import {-# SOURCE #-} B

data A

f :: B -> A

B.hs:

module B where
import {-# SOURCE #-} A

data B

g :: A -> B
g = undefined A.f

B.hs-boot:

module B where
data B

Then I can compile them:

bitonic@clay /tmp % ghc -c B.hs-boot
bitonic@clay /tmp % ghc -c A.hs-boot
bitonic@clay /tmp % ghc -c B.hs 
bitonic@clay /tmp % ghc -c A.hs 

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Lambda Calculus question on equivalence

[Francesco Mazzoli]

At Sat, 04 May 2013 09:34:01 +0100,
Jon Fairbairn wrote:
> α-equivalence on the Böhm trees — normal forms extended to
> infinity. I suppose that counts as “some semantics” but its very
> direct.

Ah yes, that makes sense.  Thanks!

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Lambda Calculus question on equivalence

[Francesco Mazzoli]

At Fri, 03 May 2013 16:34:28 +0200,
Andreas Abel wrote:
> The answer to your question is given in Boehm's theorem, and the answer 
> is "no", as you suspect.
> 
> For the untyped lambda-calculus, alpha-equivalence of beta-eta normal 
> forms is the same as observational equivalence.  Or put the other way 
> round, two normal forms which are not alpha-equivalent can be separated 
> by an observation L.

Thanks for the reference, and sorry to Ian for the confusion given by the fact
that I was thinking in types...

However, what is the notion of ‘telling apart’ here exactly?  Is it simply that
the resulting terms will have different denotations in some semantics?  My
initial (wrong) assumption about termination was due to the fact that I thought
that the ultimate test of equivalence was to be done with α-equivalence itself,
on the normal forms.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Lambda Calculus question on equivalence

[Francesco Mazzoli]

At Fri, 03 May 2013 00:44:09 +0200,
Timon Gehr wrote:
> 
> On 05/02/2013 11:33 PM, Francesco Mazzoli wrote:
> > At Thu, 02 May 2013 23:16:45 +0200,
> > Timon Gehr wrote:
> >>> Yes, they can.  Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’.
> >> Those are not lambda terms.
> >
> > How are they not lambda terms?
> >
> 
> I guess if + and * are interpreted as syntax sugar then they are lambda 
> terms with free variables. In this case, they are not equivalent.

+ and * should be interpreted as term definitions, that can be replaced with the
actual body, whatever that might be.  I’m not sure about the ‘sugar’ you are
talking about... but again these details don’t really matter.

> > You are assume things about the implementation of natural numbers, of *, 
> > and +
> > (admittedly they were underspecified on my side :).  They could be 
> > implemented
> > in different way, or I could simply change the second definition to ‘λ x → 
> > x *
> > 2’, in which case execution would be stuck on the abstract variable.
> >
> 
> AFAICS this does not show anything either, as the terms λλλ 3 2 (3 2 1) 
> and λλ 2 (λ 2 (2 1)) are not extensionally equivalent. (since their 
> domain is not restricted to terms corresponding to church numerals. Eg. 
> feed them λλ 2.)

That’s a good point, but I was talking about typed terms.  I guess the
discussion does change if you go into the untyped lambda calculus but then you
are opening a big can of worms regarding to termination (see below).

> > I don’t think so, since Ian talked about ‘terminating’ λ-calculus, while
> > the untyped λ-calculus isn’t...
> 
> 'terminating' does not occur in the original post.

‘normal form’ does, which is what I was referring to.

> > otherwise you can’t normalise and compare.
> >...
> 
> The terms in question are already normalised.

‘(L A)’ and ‘(L B)’ are clearly not normalised (if L is a function).  If the
calculus is not terminating you need to explain what’s your strategy when
comparing things that are not in a normal form already.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Lambda Calculus question on equivalence

[Francesco Mazzoli]

At Thu, 02 May 2013 23:16:45 +0200,
Timon Gehr wrote:
> > Yes, they can.  Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’.
> Those are not lambda terms.

How are they not lambda terms?

> Furthermore, if those terms are rewritten to operate on church numerals,
> they have the same unique normal form, namely λλλ 3 2 (3 2 1).

You are assume things about the implementation of natural numbers, of *, and +
(admittedly they were underspecified on my side :).  They could be implemented
in different way, or I could simply change the second definition to ‘λ x → x *
2’, in which case execution would be stuck on the abstract variable.

In any case, definitionally different functions can be extensionally equal,
there is little doubt on that.

> > These terms are not ‘definitionally’ equal (which could be the 
> > α-equivalence you cite
> > but can be extended to fancier checks on the term structure).  However, for 
> > all
> > (well typed)  inputs the result of those two functions are the same: they 
> > are
> > ‘extensionally’ equal [1].  The first part (...(L A) is equivalent to (L 
> > B)...)
> > holds: the same function will always produce the same output given
> > definitionally equal arguments.
> > ...
> 
> (I guess the question is about untyped lambda calculus.)

I don’t think so, since Ian talked about ‘terminating’ λ-calculus, while
the untyped λ-calculus isn’t... otherwise you can’t normalise and compare.

Besides that, the typed calculi I cited are interesting because they internalise
some notion of equality, but the observation about function extensionality holds
with or without types.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Lambda Calculus question on equivalence

[Francesco Mazzoli]

At Thu, 02 May 2013 20:47:07 +0100,
Ian Price wrote:
> I know this isn't perhaps the best forum for this, but maybe you can
> give me some pointers.
> 
> Earlier today I was thinking about De Bruijn Indices, and they have the
> property that two lambda terms that are alpha-equivalent, are expressed
> in the same way, and I got to wondering if it was possible to find a
> useful notion of function equality, such that it would be equivalent to
> structural equality (aside from just defining it this way), though
> obviously we cannot do this in general.
> 
> So the question I came up with was:
> 
> Can two normalised (i.e. no subterm can be beta or eta reduced) lambda
> terms be "observationally equivalent", but not alpha equivalent?
> 
> By observationally equivalent, I mean A and B are observationally
> equivalent if for all lambda terms L: (L A) is equivalent to (L B) and
> (A L) is equivalent to (B L). The definition is admittedly circular, but
> I hope it conveys enough to understand what I'm after.
> 
> My intuition is no, but I am not sure how to prove it, and it seems to
> me this sort of question has likely been answered before.

Yes, they can.  Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’.  These
terms are not ‘definitionally’ equal (which could be the α-equivalence you cite
but can be extended to fancier checks on the term structure).  However, for all
(well typed) inputs the result of those two functions are the same: they are
‘extensionally’ equal [1].  The first part (...(L A) is equivalent to (L B)...)
holds: the same function will always produce the same output given
definitionally equal arguments.

You stumbled upon a subject that generated a great deal of research in the field
of type theory [2].  There are various developments focusing on having a
‘better’ equality that identifies more things are equal.  Your intuition of
‘observationally’ equal will probably be close to the notion of isomorphism
between two sets, and in fact one of the more exciting developments right now
concerns a type theory where equality is based on isomorphism [3]—however the
computational ‘details’ haven’t been worked out yet :).  There are other
attempts [4] that fix the instance above (function extensionality) but don’t
quite go all the way (not without reasons, since the isomorphism business has
far reaching consequences that could be seen as impractical).

Francesco

[1]: https://en.wikipedia.org/wiki/Extensionality
[2]: 
https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Extensional_versus_intensional
[3]: https://en.wikipedia.org/wiki/Homotopy_type_theory
[4]: http://www.cs.nott.ac.uk/~txa/publ/obseqnow.pdf

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Operations on functional graphs

[Francesco Mazzoli]

At Wed, 24 Apr 2013 13:02:39 +0100,
Francesco Mazzoli wrote:
> Hi list,
> 
> I’ve been lately thinking about how to implement an algorithm efficiently, 
> and I
> need a directed graph that can perform the following tasks:
> 
>   1. Finding the strongly connected components
>   2. Condensing strongly connected components
>   3. Contract single edges
> 
> The condensing shouldn’t prevent successive operations to work with the
> condensed vertices (treating them all as the same), but should get rid of the
> edges.
> 
> Point one is easy, for example as described in [1].  I’m wondering if a nice 
> way
> to implement the other two with functional structures has been described.  I’d
> guess it would be a mix of a graph and disjoint sets data structure...

In the end I solved point 2 the ‘stupid’ way: I have a ‘representative’ node for
each condensed SCC, and when I condense I chose a new representative for all the
members of the SCC in question and then I traverse the all the successors list
updating and merging stale representatives.  The code is here, in case anyone’s
interested: <https://github.com/bitonic/kant/blob/master/src/Data/LGraph.hs>.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for portable Haskell or Haskell like language

[Francesco Mazzoli]

At Fri, 26 Apr 2013 21:21:48 -0800,
Christopher Howard wrote:
> Hi. I've got this work situation where I've got to do all my work on
> /ancient/ RHEL5 systems, with funky software configurations, and no root
> privileges. I wanted to install GHC in my local account, but the gnu
> libc version is so old (2.5!) that I can't even get the binary packages
> to install.
> 
> I've had success installing some other simple functional languages (like
> CLISP) on these same systems, so I was wondering if there was perhaps
> another language very similar to Haskell (but presumably simpler) with a
> super portable compiler easily built from source, which I could try.
> 
> I'll admit -- I haven't tried the HUGS compiler for Haskell. The quick
> description didn't make it sound much more portable than GHC, but I
> guess I could try it if I heard some good reasons to think it would be
> more portable.

Hugs is ANSI C, and it doesn’t really get more portable than that.  However it
is only an interpreter, if you want a compiler you might might want to try
nhc98, which aims to be very portable as well .

The problem with both of these solutions (Hugs a bit less than nhc98) is that
you won’t be able to enjoy the ecosystems that has grown in the recent years
around GHC.  But if you just want to write some standard Haskell programs, they
should be OK.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] pattern matching on data families constructors

[Francesco Mazzoli]

At Fri, 26 Apr 2013 00:20:36 +0400,
Alexey Egorov wrote:
> Yes, my question is about why different instances are different types even if
> they have the same type constructor (D).
> I'm just find it confusing that using GADTs trick it is possible to match on
> different constructors.

See it this way: the two ‘D’s (the GADTs and the data family one) are both type
functions, taking a type and giving you back another type.

In standard Haskell all such type functions return instances of the same data
type (with a set of data constructors you can pattern match on), much like the
‘D’ of the GADTs.  With type/data families the situation changes, and the
returned type can be different depending on the provided type, which is what’s
happening here.

Now the thing you want to do is ultimately write your ‘a’, which as you said
relies on type coercions, but this fact (the ‘GADTs trick’) has nothing to do
with the fact that type families will relate types to different data types.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] pattern matching on data families constructors

[Francesco Mazzoli]

At Thu, 25 Apr 2013 19:08:17 +0100,
Francesco Mazzoli wrote:
> Would you expect this to work?
> 
> > newtype DInt a = DInt a
> > newtype DBool a = DBool a
> > 
> > type family D a
> > type instance D Int = DInt Int
> > type instance D Bool = DBool Bool
> > 
> > a :: D a -> a
> > a (DInt x) = x
> > a (DBool x) = x

Or even better:

> data family D a
> data instance D Int = DInt1 Int | DInt2 Int
> data instance D Bool = DBool Bool
> 
> a :: D a -> a
> a (DInt1 x) = x
> a (DInt2 x) = x
> a (DBool x) = x

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] pattern matching on data families constructors

[Francesco Mazzoli]

At Thu, 25 Apr 2013 19:08:17 +0100,
Francesco Mazzoli wrote:
> ... ‘DInt :: DInt -> D Int’ and ‘DBool :: DBool -> D Bool’ ...

This should read ‘DInt :: Int -> D Int’ and ‘DBool :: Bool -> D Bool’.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] pattern matching on data families constructors

[Francesco Mazzoli]

At Thu, 25 Apr 2013 20:29:16 +0400,
Alexey Egorov wrote:
> I'm curious - why data families constructors (such as DInt and DBool) doesn't
> imply such constraints while typechecking pattern matching?

I think you are misunderstanding what data families do.  ‘DInt :: DInt -> D Int’
and ‘DBool :: DBool -> D Bool’ are two data constructors for *different* data
types (namely, ‘D Int’ and ‘D Bool’).  The type family ‘D :: * -> *’ relates
types to said distinct data types.

On the other hand the type constructor ‘D :: * -> *’ parametrises a *single*
data type over another type—the fact that the parameter can be constrained
depending on the data constructor doesn’t really matter here.

Would you expect this to work?

> newtype DInt a = DInt a
> newtype DBool a = DBool a
> 
> type family D a
> type instance D Int = DInt Int
> type instance D Bool = DBool Bool
> 
> a :: D a -> a
> a (DInt x) = x
> a (DBool x) = x

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Operations on functional graphs

[Francesco Mazzoli]

Hi list,

I’ve been lately thinking about how to implement an algorithm efficiently, and I
need a directed graph that can perform the following tasks:

  1. Finding the strongly connected components
  2. Condensing strongly connected components
  3. Contract single edges

The condensing shouldn’t prevent successive operations to work with the
condensed vertices (treating them all as the same), but should get rid of the
edges.

Point one is easy, for example as described in [1].  I’m wondering if a nice way
to implement the other two with functional structures has been described.  I’d
guess it would be a mix of a graph and disjoint sets data structure...

Thanks,
Francesco


[1]: Structuring Depth-First Search Algorithms in Haskell, by David King and
John Launchbury.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Word8 literals in ByteString haddock?

[Francesco Mazzoli]

At Wed, 27 Mar 2013 00:50:21 +,
Niklas Hambüchen wrote:
> Hey,
> 
> according to
> http://hackage.haskell.org/packages/archive/bytestring/0.10.2.0/doc/html/Data-ByteString.html#v:split
> I can write:
> 
> split '\n' "a\nb\nd\ne"
> 
> Can I really do that? I don't know of a way to make a '\n' literal be a
> Word8, so maybe these Haddocks are wrong? I guess they would apply for
> Data.ByteString.Char8, but this is Data.ByteString. Or is there a way?

No, there is no way—you’d need an ‘OverloadedChars’ extension that does not
exist.  I think that text is meant to show the semantics of ‘split’ rather than
being actual code.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type checking the content of a string

[Francesco Mazzoli]

At Fri, 22 Feb 2013 19:43:51 +0100,
Corentin Dupont wrote:
> Hi Adam,
> that looks interresting. I'm totally new to TH and QuasiQuotes, though.
> Can I run IO in a QuasiQuoter? I can run my own interpreter.

Yes, you can:
.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Wed, 13 Feb 2013 13:24:48 +,
Francesco Mazzoli wrote:
> 
> At Wed, 13 Feb 2013 22:01:35 +0900 (JST),
> Kazu Yamamoto (山本和彦) wrote:
> > 
> > > Nope :).  I have one ‘ghc’, and this is my ‘ghc-pkg list’:
> > > <http://hpaste.org/82293>.  ‘ghci -package wl-pprint’ runs just fine.
> > 
> > Uhhhm. Are you using sandbox?
> 
> Actually it turns out that I have a ‘cabal-dev’ directory both in / and /src 
> in
> the project folder, which is weird - could it be that ghc-mod invoked it?
> 
> In any case, if I delete those, I get:
> 
> [...]
> 
> Francesco

...but if I try it in Emacs it seems to work.  So I guess that’s fine by me :).

Thanks,
Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Wed, 13 Feb 2013 22:01:35 +0900 (JST),
Kazu Yamamoto (山本和彦) wrote:
> 
> > Nope :).  I have one ‘ghc’, and this is my ‘ghc-pkg list’:
> > .  ‘ghci -package wl-pprint’ runs just fine.
> 
> Uhhhm. Are you using sandbox?

Actually it turns out that I have a ‘cabal-dev’ directory both in / and /src in
the project folder, which is weird - could it be that ghc-mod invoked it?

In any case, if I delete those, I get:

bitonic@clay ~/src/kant (git)-[master] % ghc-mod check -g-v 
src/Kant/Syntax.hs
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package semigroups-0.8.4.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package comonad-3.0.0.2 ... linking ... done.
Loading package contravariant-0.2.0.2 ... linking ... done.
Loading package semigroupoids-3.0.0.1 ... linking ... done.
Loading package bifunctors-3.0 ... linking ... done.
Loading package prelude-extras-0.2 ... linking ... done.
Loading package bound-0.5.0.2 ... linking ... done.
Loading package prelude-extras-0.3 ... linking ... done.
Loading package bound-0.6 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package filepath-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package old-time-1.1.0.0 ... linking ... done.
Loading package unix-2.5.1.0 ... linking ... done.
Loading package directory-1.1.0.2 ... linking ... done.
Loading package terminfo-0.3.2.5 ... linking ... done.
Loading package haskeline-0.7.0.3 ... linking ... done.
Loading package mtl-2.1.1 ... linking ... done.
Loading package text-0.11.2.0 ... linking ... done.
Loading package parsec-3.1.2 ... linking ... done.
Loading package transformers-0.2.2.0 ... linking ... done.
Loading package mtl-2.0.1.0 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package wl-pprint-1.1 ... linking ... done.
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module import occurred
ghc-mod:0:0:Probably mutual module impo

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Wed, 13 Feb 2013 19:51:15 +0900 (JST),
Kazu Yamamoto (山本和彦) wrote:
> 
> > Now I get another error:
> > 
> >Error:: cannot satisfy -package wl-pprint
> > 
> > even if ‘wl-pprint’ is installed, and ‘cabal configure; cabal build’ runs 
> > fine.
> 
> It seems to me that you installed multiple GHCs and wl-pprint is not
> installed for one of them. Is my guess corrent?

Nope :).  I have one ‘ghc’, and this is my ‘ghc-pkg list’:
.  ‘ghci -package wl-pprint’ runs just fine.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Wed, 13 Feb 2013 15:32:57 +0900 (JST),
Kazu Yamamoto (山本和彦) wrote:
> 
> Francesco,
> 
> > I can confirm that 1.11.1 works.
> 
> I think I fixed this problem.
> Would you try the master branch?
> 
>   https://github.com/kazu-yamamoto/ghc-mod

Hi Kazu,

Now I get another error:

   Error:: cannot satisfy -package wl-pprint

even if ‘wl-pprint’ is installed, and ‘cabal configure; cabal build’ runs fine.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Fri, 08 Feb 2013 13:43:12 +,
Francesco Mazzoli wrote:
> 
> At Fri, 08 Feb 2013 22:39:07 +0900 (JST),
> Kazu Yamamoto (山本和彦) wrote:
> > 
> > > Well installing it has the big problem that each time I make a
> > > change to the interface I have to manually re-install, and this
> > > happens often since I’m in an early stage...
> > 
> > I'm not saying that you should install it. But I just want to know
> > your situation.
> 
> Oh OK, I took it as an advice.  Yes, it works if I install it.
> 
> > > Right, but this is surely doable since cabal handles the situation fine.  
> > > In
> > > general it seems that ghc-mod should work with cabal when it can.
> > 
> > Yes. This is a bug of the current ghc-mod. This behavior change was
> > introduced by another guy, I guess. I need to look into his code.
> 
> Thanks a lot, I’ll downgrade and wait for a fix.
> 
> Francesco

I can confirm that 1.11.1 works.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Fri, 08 Feb 2013 22:39:07 +0900 (JST),
Kazu Yamamoto (山本和彦) wrote:
> 
> > Well installing it has the big problem that each time I make a
> > change to the interface I have to manually re-install, and this
> > happens often since I’m in an early stage...
> 
> I'm not saying that you should install it. But I just want to know
> your situation.

Oh OK, I took it as an advice.  Yes, it works if I install it.

> > Right, but this is surely doable since cabal handles the situation fine.  In
> > general it seems that ghc-mod should work with cabal when it can.
> 
> Yes. This is a bug of the current ghc-mod. This behavior change was
> introduced by another guy, I guess. I need to look into his code.

Thanks a lot, I’ll downgrade and wait for a fix.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Fri, 08 Feb 2013 22:18:20 +0900 (JST),
Kazu Yamamoto (山本和彦) wrote:
> 
> > The ‘kant’ package is the package I’m developing and using ghc-mod on. 
> 
> Yes. I understand it.
> 
> > It includes both a library and an executable.  The executable target
> > has ‘kant’ as a dependency.
> 
> What I asked is whether or not the "kant" library is installed by
> cabal.

Well installing it has the big problem that each time I make a change to the
interface I have to manually re-install, and this happens often since I’m in an
early stage...

> To edit a Haskell file for the "kant" executable, the current ghc-mod
> needs to find the "kant" library in global or user.

Right, but this is surely doable since cabal handles the situation fine.  In
general it seems that ghc-mod should work with cabal when it can.

> I guess this bug does not exist in ghc-mod v1.11.1.

I’ll try with that.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Fri, 08 Feb 2013 12:50:47 +0100,
CJ van den Berg wrote:
> 
> On 08/02/13 12:25, Francesco Mazzoli wrote:
> > At Fri, 08 Feb 2013 11:39:19 +0100,
> > CJ van den Berg wrote:
> >> I downloaded your package and tried it. It does work.
> > 
> > So, what I have is
> > 
> >bitonic@clay ~/src/kant (git)-[master] % cat .ghci
> >:set -isrc
> > 
> > And I still get the mentioned error.  Did you take any other measures to 
> > make
> > things work?  I’m using ghc-mod version 1.11.3.
> 
> Ah, I only just realised that you’re talking about the flymake error,
> not the inferior-mode error. The problem is pretty much the same though.
> flymake uses ghc --make, which can’t import the Kant module because it
> doesn’t know how to build Parser.y.

No, that is not the problem, I have a manually preprocessed Parser.hs in place.

> ghc-ghc-options is the right place for flymake options to ghc.

Tried setting ‘ghc-ghc-options’, still no luck.  And by the way, running
‘ghc-mod’ manually doesn’t help either:

bitonic@clay ~/src/kant (git)-[master] % cat .ghci
:set -isrc
bitonic@clay ~/src/kant (git)-[master] % ghc-mod check src/Kant/REPL.hs
src/Kant/REPL.hs:0:0:Error:: cannot satisfy -package kant
(use -v for more information)

> Options in .ghci won’t fix flymake, only inferior-mode. ghc-ghc-options
> is the place to fix flymake, although it won’t help if the import fails
> anyway.
> 
> Can’t you manually preprocess Parser.y so that ghc --make has a .hs file
> it can use?

Well yes I can, but it’s a bit annoying.  I think things would be easier if
‘ghc-mod’ just used cabal commands (e.g. ‘cabal build’) to check things.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Fri, 08 Feb 2013 21:22:23 +0900 (JST),
Kazu Yamamoto (山本和彦) wrote:
> I guess you don't install the "kant" library, right?
> 
> If so, I will think how to treat this kind problem.

The ‘kant’ package is the package I’m developing and using ghc-mod on.  It
includes both a library and an executable.  The executable target has ‘kant’ as
a dependency.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Fri, 08 Feb 2013 11:39:19 +0100,
CJ van den Berg wrote:
> I downloaded your package and tried it. It does work.

So, what I have is

   bitonic@clay ~/src/kant (git)-[master] % cat .ghci
   :set -isrc

And I still get the mentioned error.  Did you take any other measures to make
things work?  I’m using ghc-mod version 1.11.3.
 
> Kant.REPL, which it is trying to load, is in the kant package. So it is
> looking for either the installed kant package, or the source files for
> the kant package modules.
> 
> How is that not a package dependency? Telling it where to find the
> source files will remove the need to find an installed kant package.

OK, now I understand what you are doing: instead of making ghc-mod rely on
cabal, you simply make it load the files directly.  Which is a bit annoying in
my case because I have some files that need to be preprocessed (alex/happy), but
it would still be better than nothing.  I can achieve the same result by simply
moving the ‘cabal’ file, or by deleting the target.  I guess that the ‘.ghci’
has (or should have) the same effect.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

At Fri, 08 Feb 2013 11:11:06 +0100,
CJ van den Berg wrote:
> Hi Francesco,
> 
> To keep ghc-mod happy, you also have to keep ghci happy. What you
> probably need is a .ghci file in the directory with a ":set -isrc" line
> in it. You may also need to add other stuff to .ghci such as language
> extensions and whatever else is needed to load your project with ghci.

Hi CJ,

Thanks for your answer.

I had tried to do that (actually I had modified ‘ghc-ghc-options’, but the
result should be the same), but it doesn’t fix the issue - and I don’t see why
it should, since the problem here is about not satisfying a package dependency.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ghc-mod and cabal targets

[Francesco Mazzoli]

Hi,

I have been using ghc-mod for a long time and I can’t give it up now, but I have
an annoying problem.

When I have a cabal file with a library and an executable depending on the
library (for example here
), ghc-mod is not happy,
complaining in every file that

Error:: cannot satisfy -package kant

Where ‘kant’ is the package that the cabal file defines with the library that
the executable needs.  Note that if I issue ‘cabal configure; cabal build’,
everything goes smoothly.

Did anybody stumble on the same problem?

Thanks,
Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inference for RankNTypes

[Francesco Mazzoli]

At Wed, 2 Jan 2013 13:35:24 -0500,
Dan Doel wrote:
> If you want to know the inner workings, you probably need to read the
> OutsideIn(X) paper.*
> 
> I'm not that familiar with the algorithm. But what happens is something
> like this When GHC goes to infer the type of 'f x' where it knows that
> f's argument is expected to be polymorphic, this triggers a different code
> path that will check that x can be given a type that is at least as general
> as is necessary for the argument.
> 
> However, "flip one 'x' id" gives flip a type like (alpha -> beta -> gamma)
> -> beta -> alpha -> gamma. Then, we probably get some constraints collected
> up like:
> 
> alpha ~ (forall a. a -> a)
> alpha ~ (delta -> delta)
> 
> That is, it does not compute the higher-rank type of "flip one 'x'" and
> then decide how the application of that to id should be checked; it decides
> how all the arguments should be checked based only on flip's type, and flip
> does not have a higher-rank type on its own. And solving the above
> constraints cannot trigger the alternate path.
> 
> However, when you factor out or annotate "flip one 'x'", it knows that it's
> applying something with a higher-rank type (whether because it inferred it
> separately, or you gave it), and that does trigger the alternate code path.
> 
> If that's still too vague, you'll have to refer to the paper.
> 
> -- Dan
> 
> *
> http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/jfp-outsidein.pdf

Thanks again for the answer.  I understood more or less what was going on with
the constraints - what I was wondering is how that alternate code path you cite
works.  I guess I’ll have to attack that epic paper sooner or later :).

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inference for RankNTypes

[Francesco Mazzoli]

At Wed, 2 Jan 2013 11:20:46 -0500,
Dan Doel wrote:
> Your example doesn't work for the same reason the following doesn't work:
> 
> id runST ()
> 
> It requires the inferencer to instantiate certain variables of id's type to
> polymorphic types based on runST (or flip's based on one), and then use
> that information to check  (id in your example) as a
> polymorphic type. At various times, GHC has had ad-hoc left-to-right
> behavior that made this work, but it no longer does. Right now, I believe
> it only has an ad-hoc check to make sure that:
> 
> runST $ 
> 
> works, and not much else. Note that even left-to-right behavior covers all
> cases, as you might have:
> 
> f x y
> 
> such that y requires x to be checked polymorphically in the same way. There
> are algorithms that can get this right in general, but it's a little
> tricky, and they're rather different than GHC's algorithm, so I don't know
> whether it's possible to make GHC behave correctly.
> 
> The reason it works when you factor out or annotate "flip one 'x'" is that
> that is the eventual inferred type of the expression, and then it knows to
> expect the id to be polymorphic. But when it's all at once, we just have a
> chain of unifications relating things like: (forall a. a -> a) ~ beta ~
> (alpha -> alpha), where beta is part of type checking flip, and alpha ->
> alpha is the instantiation of id's type with unification variables, because
> we didn't know that it was supposed to be a fully polymorphic use. And that
> unification fails.

Hi Dan,

Thanks a lot for the answer, one forgets that with HM you always replace the
quantified variables immediately.

However I am still confused on how GHC makes it work when I annotate or put
things in separate variables.  In other words, can you provide links or clarify
how this procedure works:

The reason it works when you factor out or annotate "flip one 'x'" is that
that is the eventual inferred type of the expression, and then it knows to
expect the id to be polymorphic.

Thanks,
Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inference for RankNTypes

[Francesco Mazzoli]

At Wed, 2 Jan 2013 14:49:51 +0200,
Roman Cheplyaka wrote:
> I don't see how this is relevant.

Well, moving `flip one' in a let solves the problem, and The fact that let-bound
variables are treated differently probably has a play here.  I originally
thought that this was because the quantifications will be all to the left in the
let-bound variable while without a let-bound variable the types are used
directly.  However this doesn’t explain the behaviour I’m seeing.

> GHC correctly infers the type of "flip one 'x'":
> 
>   *Main> :t flip one 'x'
>   flip one 'x' :: (forall a. a -> a) -> Char
> 
> But then somehow it fails to apply this to id. And there are no bound
> variables here that we should need to annotate.

Right.  The weirdest thing is that annotating `flip one' (as in `three' in my
code) or indeed `flip one 'x'' with the type that shows up in ghci makes
things work:

five = (flip one 'x' :: (forall a. a -> a) -> Char) id

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inference for RankNTypes

[Francesco Mazzoli]

At Wed, 02 Jan 2013 12:32:53 +0100,
Francesco Mazzoli wrote:
> 
> Hi list,
> 
> I am a bit puzzled by the behaviour exemplified by this code:
> 
> {-# LANGUAGE RankNTypes #-}
> 
> one :: (forall a. a -> a) -> b -> b
> one f = f
> 
> two = let f = flip one in f 'x' id
> three = (flip one :: b -> (forall a. a -> a) -> b) 'x' id
> four = flip one 'x' id
> 
> Try to guess if this code typechecks, and if not what’s the error.
> 
> While `two' and `three' are fine, GHC (7.4.1 and 7.6.1) complains about 
> `four':
> 
> Line 8: 1 error(s), 0 warning(s)
> 
> Couldn't match expected type `forall a. a -> a'
> with actual type `a0 -> a0'
> In the third argument of `flip', namely `id'
> In the expression: flip one 'x' id
> In an equation for `four': four = flip one 'x' id
> 
> So for some reason the quantified variable in `id' gets instantiated before it
> should, and I have no idea why.
> 
> Any ideas?
> 
> Francesco

OK, I should have looked at the manual first. From
<http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#id623016>:
“For a lambda-bound or case-bound variable, x, either the programmer provides an
explicit polymorphic type for x, or GHC's type inference will assume that x's
type has no foralls in it.”.  So there is a difference between let-bound things
and the rest.

I still don’t get exactly what’s going on there.  What’s the inferred type for
`flip one', and why is it causing that error?  Since there really isn’t much to
infer here.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Inference for RankNTypes

[Francesco Mazzoli]

Hi list,

I am a bit puzzled by the behaviour exemplified by this code:

{-# LANGUAGE RankNTypes #-}

one :: (forall a. a -> a) -> b -> b
one f = f

two = let f = flip one in f 'x' id
three = (flip one :: b -> (forall a. a -> a) -> b) 'x' id
four = flip one 'x' id

Try to guess if this code typechecks, and if not what’s the error.

While `two' and `three' are fine, GHC (7.4.1 and 7.6.1) complains about `four':

Line 8: 1 error(s), 0 warning(s)

Couldn't match expected type `forall a. a -> a'
with actual type `a0 -> a0'
In the third argument of `flip', namely `id'
In the expression: flip one 'x' id
In an equation for `four': four = flip one 'x' id

So for some reason the quantified variable in `id' gets instantiated before it
should, and I have no idea why.

Any ideas?

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Motion to unify all the string data types

[Francesco Mazzoli]

At Mon, 12 Nov 2012 10:26:01 +,
Francesco Mazzoli wrote:
> Interesting.  Are we sure that we can't convince GHC to inline the functions
> with enough pragmas?

Inline and SPECIALIZE :).

Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Motion to unify all the string data types

[Francesco Mazzoli]

At Mon, 12 Nov 2012 11:21:42 +0800,
John Lato wrote:
> Speaking as the ListLike maintainer, I'd like this too.  But it's difficult to
> do so without sacrificing performance.  In some cases, sacrificing *a lot* of
> performance.  So they have to be class members.
> 
> However, there's no reason ListLike has to remain a single monolithic class.
> I'd prefer an API that's split up into several classes, as was done in Edison.
> Then 'ListLike' itself would just be a type synonym, or possibly a small type
> class with the appropriate superclasses.

Interesting.  Are we sure that we can't convince GHC to inline the functions
with enough pragmas?

> However this seems like a lot of work for relatively little payoff, which
> makes it a low priority for me.

Fair enough.

> The community's view on newtypes is funny.  On the one hand, I see all the
> time the claim "Just use a newtype wrapper to write instances for ..."
> (e.g. the recent suggestion of 'instance Num a => Num (a,a)'.  On the other,
> nobody actually seems to want to use these newtype wrappers.  Maybe it
> clutters the code?  I don't know.
> 
> I couldn't think of a better way to implement this functionality, patches
> would be gratefully accepted.  Anyway, you really shouldn't use these wrappers
> unless you're using a ByteString to represent ASCII text.  Which you shouldn't
> be doing anyway.  If you're using a ByteString to represent a sequence of
> bytes, you needn't ever encounter CharString.

Well newtypes are good, the problem is that either you use well accepted ones
(e.g. the `Sum' and `Product' in base) or otherwise it's not worth it, because
people are going to unpack them and use their owns.  What I would do is simply
define those instances in separate modules.

> Given that text and vector are both in the Haskell Platform, I wouldn't object
> to these instances being rolled into the main ListLike package.  Any comments
> on this?

I think it's much better, especially for Text, since if you use ListLike you are
probably using it with Text (at least in my experience).  Not a big deal anyway.

Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Motion to unify all the string data types

[Francesco Mazzoli]

At Sat, 10 Nov 2012 15:16:30 +0100,
Alberto G. Corona  wrote:
> There is a ListLike package, which does this nice abstraction. but I don't
> know if it is ready for and/or enough complete for serious usage.  I´m
> thinking into using it for the same reasons.
> 
> Anyone has some experiences to share about it?

I've used it in the past and it's solid, it's been around for a while and the
original author knows his Haskell.

Things I don't like:

* The classes are huge:
  
.
  I'd much rater prefer to have all those utilities functions outside the type
  class, for no particular reason other then the ugliness of the type class.

* It defines its own wrappers for `ByteString':
  
.

* It doesn't have instances for `Text', you have to resort to the
  `listlike-instances' package.

In any case I think it's on the right track, I'd really like something like
that, but much simpler, to be in `base'.

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Security] Put haskell.org on https

[Francesco Mazzoli]

At Sun, 28 Oct 2012 14:59:00 +0400,
Dmitry Vyal wrote:
> Does hackage at least store the logs of packages uploads? What's the reason or
> such a security model? I guess it was appropriate in the past when hackage was
> an experimental service, but now it's a standard way of distributing Haskell
> code. If anyone can update any package, we are waiting for the disaster. I
> have some haskell code I wrote myself running as root and these thoughts make
> me shiver.

There is no good reason for it to be like that, it is truly bad.  Hackage2 has
been in the works for a while and will fix this "problem".  More information
here: .

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Security] Put haskell.org on https

[Francesco Mazzoli]

At Sun, 28 Oct 2012 00:20:16 +0100,
Niklas Hambüchen wrote:
> (I have mentioned this several times on #haskell, but nothing has
> happened so far.)
> 
> Are you aware that all haskell.org websites (hackage, HaskellWiki, ghc
> trac) allow unencrypted http connections only?
> 
> This means that everyone in the same Wifi can potentially
> 
> - read you passwords for all of these services
> 
> - abuse your hackage account and override arbitrary packages
>   (especially since hackage allows everybody to override everything)
> 
> 
> I propose we get an SSL certificate for haskell.org.
> I also offer to donate that SSL certificate (or directly create it using
> my Startcom account).

Agreed, I can chip in - but I think a certificate is pretty cheap nowadays :).

--
Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

At Sat, 29 Sep 2012 19:49:36 +0200,
Gábor Lehel wrote:
> I was browsing the GHC bug tracker and accidentally might have found a
> solution to your problem:
> 
> http://hackage.haskell.org/trac/ghc/ticket/7100

Thanks, this makes me feel better.  What interested me is not the workarounds,
that I had already partly explored, but why the limitation is there in the first
place.  It turns out that it's because it'd add complexity and type families do
it better.  Fair enough.

> Basically you have to make a type family to recapitulate the functional
> dependencies in the instances of Foo:
> 
> type family FooFD a
> 
> -- for each instance Foo A B, you have to write:
> -- type instance FooFD A = B
> 
> class Foo a (FooFD a) => Bar a where
> foo :: a -> FooFD a -> c
> 
> Anywhere you would use 'b', you use the type family instead.
> 
> The example in the ticket also had a 'b ~ FooFD a' superclass constraint on
> Foo itself, which you can't add if you don't control Foo, but I'm not sure
> what it's necessary for - in my brief tests removing it didn't cause problems.
> 
> A weakness of this approach is that you have to manually add a type instance
> for every instance of Foo, which may or may not be a problem in your
> situation.

I think this method, while useful to show the already shown relation between
fundeps and type families, is pointless in reality.  The most convenient method
in practice, by far, is just to add the dependent part of the fundep explicitly
to Bar.

Along to the awkwardness you already pointed out of having to declare the family
instance for each type, I'm introducing some unfamiliar and unnecessary type
family to the user.  It adds nothing but confusion.  Not to mention that if I
stick to fundeps I might hope to use my code with something else apart from GHC.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

At Sat, 29 Sep 2012 10:56:29 +0200,
Francesco Mazzoli wrote:
> 
> At Sat, 29 Sep 2012 10:30:07 +0200,
> Francesco Mazzoli wrote:
> > Then I'd also like to have
> > 
> > newtype TST sym algo = <...>
> > 
> > instance (Ord sym, ListLike full sym) => Search (TST sym algo) full algo
> > 
> > This one is a different problem - it requires UndecidableInstances and I 
> > don't
> > understand why.  It seems to me that the coverage condition
> > (<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html>,
> > point 7.6.3.2) is too strict in these cases.  But this is not that 
> > important.
> 
> This doesn't make sense with the code posted (which would require sensibly
> UndecidableInstances), I meant something like this (I don't have "actual" code
> to show the problem):
> 
> data Foo a
> 
> class Bar a b | a -> b
> 
> class Quux a b | a -> b
> 
> instance Bar a b => Quux (Foo a) b

Actually I know why this is the case - instances are picked without looking at
the constraints, and there is no backtracking.  I guess my brain just can't
resist from seeing Prolog in type classes...

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

At Sat, 29 Sep 2012 13:04:59 +0400,
MigMit wrote:
> Well, it seems that you can't do exactly what you want. So, the simplest way
> to do this would be not to make Foo a superclass for Bar:
> 
> class Bar a where
> foo :: Foo a b => a -> b -> c
> 
> Then you would have to mention Foo everywhere.

Just to clarify, I already worked my way around that problem.  I want to know
why I can't do it since it seems a useful feature to have.

In fact, I was doing something very similar to what you're proposing before, but
I think having the additional argument is better in my code, for various
reasons.  You can check the actual class here:
,
I've left the old version commented.

> If you really need, for some reason, to ensure that every Bar instance has a
> corresponding Foo instance, you can do some oleging this way:
> 
> data Void b = Void
> data FooEv a where FooEv :: Foo a b => Void b -> FooEv a
> class Bar a where
> barFoo :: FooEv a
> bar :: Foo a b => a -> b -> c
> 
> Then, whenever you need Foo methods, you can do pattern-matching:
> 
> case barFoo :: FooEv a of
>   FooEv (Void :: Void b) -> …
> 
> Now some "b" is in scope, and there is an instance of Foo a b.

Well, I'm sure there are endless ways to get around this, but in cases like this
the resulting mess far outweighs the advantages :).

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

At Sat, 29 Sep 2012 10:30:07 +0200,
Francesco Mazzoli wrote:
> Then I'd also like to have
> 
> newtype TST sym algo = <...>
> 
> instance (Ord sym, ListLike full sym) => Search (TST sym algo) full algo
> 
> This one is a different problem - it requires UndecidableInstances and I don't
> understand why.  It seems to me that the coverage condition
> (<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html>,
> point 7.6.3.2) is too strict in these cases.  But this is not that important.

This doesn't make sense with the code posted (which would require sensibly
UndecidableInstances), I meant something like this (I don't have "actual" code
to show the problem):

data Foo a

class Bar a b | a -> b

class Quux a b | a -> b

instance Bar a b => Quux (Foo a) b

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

At Fri, 28 Sep 2012 18:33:23 -0700,
Alexander Solla wrote:
> Only with respect to type inference.

I don't understand this comment.

> I wouldn't have replied with that line of thought if you had just told us
> what the problem was in the first place.  I /was/ saying that you can use
> explicit type annotations to disambiguate instances.
> 
> Most of us haven't memorized the Haskell 2010 report.  We let the compiler
> tell us what's wrong and either learn why, or how to fix it.  So post your
> errors.

Sorry, I posted in a hurry.  Besides, feeding those lines to a compiler before
replying takes 10 seconds.

> By the way, it is rather rude to publicly post a private email...

I thought that you had forgot to reply all, as often happens.  I also want the
discussion to stay on the list, so that people can read in the future.  I'm
sorry if that email was meant to be private, I saw nothing private about it.

> Now, on to your real problem.
> 
> Use TypeFamilies instead:
> 
> class Foo a where
>  type BarThing a :: *
> 
> class Foo a => Bar a where
>  foo :: a -> BarThing a -> b

As I mentioned in the original post, `Foo' is outside my control.

> This is pretty pointless, since you can just refactor into the nearly
> equivalent:
> 
> class Foo a
> 
> class Foo a => Bar a where
> type BarThing a :: *
> foo :: a -> BarThing a -> c
> 
> It may or may not matter to which family the type synonym belongs.

Mine was a contrived example to show the issue.  The whole point is to reduce
the number of arguments of a class by referring to another class and its
fundeps.

> What is the problem you are actually trying to solve?

What I actually (would like to) have is something like this:

class (EditDistance algo sym,  ListLike full sym) =>
  Search container full algo | container -> full, container -> algo 
where


This limitation is annoying even without referencing `sym' (which I can avoid to
do) since is prevents me from putting constraints that express what the purpose
of the class is and will have to be repeated in every instance.

Then I'd also like to have

newtype TST sym algo = <...>

instance (Ord sym, ListLike full sym) => Search (TST sym algo) full algo

This one is a different problem - it requires UndecidableInstances and I don't
understand why.  It seems to me that the coverage condition
(,
point 7.6.3.2) is too strict in these cases.  But this is not that important.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

At Fri, 28 Sep 2012 17:19:36 -0700,
Alexander Solla wrote:
> Well, then what exactly is the problem?  Are you getting an error?

...well yes.  The error I get with the posted class declarations is

   Not in scope: type variable `b'

at the line with

   class Foo a b => Bar a where

Which I get because all the type vars in the LHS must be referenced on the RHS
(or so it seems).

Now, in my case the problem does not stop there, because I also want to
reference the tyvar on the LHS in a type signature of a method, since in that
case there is a fundep on b (`a -> b'), which makes `b' decidable if you have
`a' and `Foo a b'.

> You don't need to bring 'b' into scope.  You will already have real types in
> scope.
>
> instance Foo A B
> instance Bar A where foo A B = C

Again, I'm not sure what you mean here.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

CCing the list back.

At Fri, 28 Sep 2012 13:30:52 -0700,
Alexander Solla wrote:
> What is the problem, exactly?  It looks to me like UndecidableInstances and
> ScopedTypeVariables (on foo, or its arguments) would be enough.

I'm not sure what you mean.  I don't see the need for UndecidableInstances, and
there is no way I can see to bring the `b' into scope in the type sig for foo,
ScopedTypeVariables or not - unless I'm missing something.

> Also note that as stated, foo's type "is a bottom" (more specifically, is a
> function onto bottom, since c is free in the class, and so foo must be
> parametrically polymorphic in its return type, and so is devoid of "real"
> Haskell values).  Hopefully that is just an artefact of the translation to
> Foo's and Bar's.

Yeah the type for `foo' is irrelevant, I just needed to put something there.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Class constraints with "free" type variables and fundeps

[Francesco Mazzoli]

I would expect this to work, maybe with some additional notation (a la
ScopedTypeVariables)

{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}

class Foo a b | a -> b

class Foo a b => Bar a where
foo :: a -> b -> c

The type family equivalent works as expected:

{-# LANGUAGE TypeFamilies #-}

class Foo a where
type T a :: *

class Bar a where
foo :: a -> T a -> c

I can't use type families because the `Foo' I'm using is in an external library.
Is there any way to achieve what I want without adding `b' to `Bar'?

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Either Monad and Laziness

[Francesco Mazzoli]

At Wed, 12 Sep 2012 12:04:31 -0300,
Eric Velten de Melo wrote:
> It would be really awesome, though, if it were possible to use a
> parser written in Parsec with this, in the spirit of avoiding code
> rewriting and enhancing expressivity and abstraction.

There is  and
, which turn
attoparsec parsers into enumerators/conduits, and
, which is a compatibility
layer between attoaparsec and parsec.  Good luck :).

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell master thesis project

[Francesco Mazzoli]

Hi list(s),

I've been hooked on Haskell for a while now (some of you might know me as
bitonic on #haskell), and I find myself to decide on a project for my masters
thesis.

Inspired by the David Terei's master thesis (he wrote the LLVM backend), I was
wondering if there were any projects requiring similar effort that will benefit
the Haskell community.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambdabot-4.2.3.3

[Francesco Mazzoli]

At Wed, 18 Jul 2012 11:04:17 -0400,
Cale Gibbard wrote:
> Lambdabot doesn't have a maintainer.

So is it just orphaned and anyone can upload? That does not sound right, also
considering that lambdabot is used on the IRC channel, it'd be nice to have a
more structured way to push fixes and improvements... Otherwise it'll eventually
just bitrot and die.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] lambdabot-4.2.3.3

[Francesco Mazzoli]

At Wed, 18 Jul 2012 15:14:47 +0400,
Dmitry Malikov wrote:
> A few days ago I tried to install lambdabot package from hackage
> (4.2.3.2). Cabal install failed.
> 
> Then I found DanBurton's github repo with some approaches to make lambdabot
> install fixed.
> 
> All dependency packages (IOSpec, numbers) was already fixed.
> 
> So I add FlexibleInstances extension to cabal file and upload package to
> hackage.
> 
> I hope that did everything right.

Did you ask the maintainer first? You should never just upload a package that
you are not maintaining before asking first the maintainer and then haskell-cafe
if you receive no response. If you did not ask, please do not do that again and
tell the maintainer - which in this case you should have no problem contacting,
since Cale is often online on IRC.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] arbitrary rank polymorphism and ghc language pragmas

[Francesco Mazzoli]

At Thu, 05 Jul 2012 11:18:00 -0400,
rickmurphy  wrote:
> data T = TC (forall a b. a -> b -> a)

The type of `TC' will be `(forall a b. a -> b -> a) -> T', a Rank-2
type.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Is there a GHC flag that will allow mutable top level state while you are debugging and then ...

[Francesco Mazzoli]

At Wed, 4 Jul 2012 09:06:32 -0700,
KC  wrote:
> you can turn the flag off when you are ready to do the computational
> heavy lifting so that you don't have to modify your code base?
> 
> That is, GHC can then apply its algebraic transformation
> optimizations to the "code algebra" of the pure functions.

What do you mean "allow mutable top level state"? As in

> import Foreign.Ptr
> import Foreign.StablePtr
> import Foreign.Storable
> import System.IO.Unsafe
> 
> destructiveUpdate :: Storable a => a -> a -> ()
> destructiveUpdate x y =
> unsafePerformIO $ do ptr <- newStablePtr x
>  poke (castPtr (castStablePtrToPtr ptr)) y
>  freeStablePtr ptr

? The only problem that the above function does not work - you can't
poke or peek off StablePtrs.

If that's what you mean, no. And I doubt it'll ever exist, since it
breaks the most important invariant in Haskell - that is, that values
don't change. An Haskell compiler will rely on this assumption quite
heavily, so changes to that are likely to disrupt things seriously.

Also, I don't see how destructive updates help debugging.

--
Francesco * Often in error, never in doubt

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why does Enum succ and pred functions throw exception

[Francesco Mazzoli]

At Thu, 21 Jun 2012 10:11:24 +0100 (BST),
Rouan van Dalen wrote:
> Hi everyone,
> 
> Can anyone shed some light on why the succ and pred functions of the Enum 
> typeclass throw
> exceptions if we go over the upper or lower boundary, and not return Maybe a?
> 
> I was hoping to have some functions like:
> 
>   safeSucc :: (Enum a) => a -> Maybe a
> 
> Because the succ and pred functions throw exceptions I can only catch them in
> the IO monad.  This makes it hard to deal with this situation in pure code.
> 
> Regards
> 
> Rouan.

That decision was most likely dictated by the convenience of now
having the Maybe - and remember that many Enum data types are not
bounded anyway, so they would never need that.

In any case, you can easily roll your own

safeSucc :: (Enum a, Bounded a) => a -> Maybe a
safeSucc x | x == maxBound = Nothing
   | otherwise = Just (succ x)

Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] darcs patch dependencies in dot format

[Francesco Mazzoli]

On 13/05/12 15:13, Francesco Mazzoli wrote:

On 13/05/12 14:55, Sönke Hahn wrote:

Somehow related questions are: What am I going to do with a dot-graph,
that has more than 500 vertices? Is there an intelligent way to reduce
the graph?


Setting the `concentrate' parameter to true helps, but dot does not work
well with massive graphs.


Actually, "neato" doesn't work well with massive graph - and neither do 
the other algorithms provided by GraphViz. dot is just the file format.


I found Gephi (https://gephi.org/) quite good when I had to visualize 
big graphs, and it supports dot files so you can try it out easily.


Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] darcs patch dependencies in dot format

[Francesco Mazzoli]

On 13/05/12 14:55, Sönke Hahn wrote:

Somehow related questions are: What am I going to do with a dot-graph,
that has more than 500 vertices? Is there an intelligent way to reduce
the graph?


Setting the `concentrate' parameter to true helps, but dot does not work 
well with massive graphs.


Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] bytestring, array and Safe Haskell

[Francesco Mazzoli]

On 08/05/12 21:45, Austin Seipp wrote:

The reasoning is outlined in the user manual here:

http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html#safe-inference


Yes, I was looking at that while writing that message.

Mine wasn't that much a complaint regarding the wrong inference (even if 
it looks like  it should be possible to fix the inference those instance 
- especially the bytestring one), but rather regarding the fact that 
those modules should be marked unsafe manually.


Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] bytestring, array and Safe Haskell

[Francesco Mazzoli]

Why are 
http://hackage.haskell.org/packages/archive/bytestring/0.9.2.1/doc/html/Data-ByteString-Unsafe.html 
and 
http://hackage.haskell.org/packages/archive/array/0.4.0.0/doc/html/Data-Array-Unsafe.html 
Safe-inferred?


The first one uses inlinePerformIO, so it clearly shouldn't be marked as 
Safe. Maybe Safe Haskell doesn't check that function?
The second is a bit messier since it uses unboxed types and primitive 
operations... But they clearly should be marked as Unsafe, and it 
surprises me that Safe Haskell is that relaxed when checking for safe 
functions.


Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fixed point newtype confusion

[Francesco Mazzoli]

Sorry, I think I misunderstood your question, if I understand correctly 
you want some function to convert nested Expr to Fix'ed Exprs.


You can do that with a typeclass, but you have to provide the Fix'ed 
type at the bottom:


--

{-# LANGUAGE FlexibleInstances #-}

data E e = Lit Int | Add e e
data Fix f = Fix {unFix :: f (Fix f)}
type Expr = Fix E

lit :: Int -> Expr
lit = Fix . Lit

add :: Expr -> Expr -> Expr
add e1 e2 = Fix (Add e1 e2)

term :: Expr
term = add (lit 1) (add (lit 2) (lit 3))

class FixE e where
fix :: e -> Expr

instance FixE Expr where
fix = id

instance FixE e => FixE (E e) where
fix (Lit i) = lit i
fix (Add e1 e2) = add (fix e1) (fix e2)



This is because your `term' works since you don't have any occurrence of 
`expr' at leaves of your Expr tree, and that works because the leaves 
are all literals. However, we can't guarantee this statically.


We can, of course, write an unsafe instance based on the assumption that 
the the values at the leaves of the expression tree will be literals:




instance FixE (E e) where
fix (Lit i) = lit i
fix _   = error "non-literal!"



Francesco.

On 06/05/12 13:59, Sebastien Zany wrote:

Hi,

Suppose I have the following types:

 > data Expr expr = Lit Nat | Add (expr, expr)
 > newtype Fix f = Fix {unFix :: f (Fix f)}

I can construct a sample term:

 > term :: Expr (Expr (Expr expr))
 > term = Add (Lit 1, Add (Lit 2, Lit 3))

But isn't quite what I need. What I really need is:

 > term' :: Fix Expr
 > term' = Fix . Add $ (Fix . Lit $ 1, Fix . Add $ (Fix . Lit $ 2, Fix .
Lit $ 3))

I feel like there's a stupidly simple way to automatically produce term'
from term, but I'm not seeing it.

Any ideas?

Best,
Sebastien


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fixed point newtype confusion

[Francesco Mazzoli]

Hi,

In these cases is good to define smart constructors, e.g.:

> data E e = Lit Int | Add e e
> data Fix f = Fix {unFix :: f (Fix f)}
>
> type Expr = Fix E
>
> lit :: Int -> Expr
> lit = Fix . Lit
>
> add :: Expr -> Expr -> Expr
> add e1 e2 = Fix (Add e1 e2)
>
> term :: Expr
> term = add (lit 1) (add (lit 2) (lit 3))

Francesco.

On 06/05/12 13:59, Sebastien Zany wrote:

Hi,

Suppose I have the following types:

 > data Expr expr = Lit Nat | Add (expr, expr)
 > newtype Fix f = Fix {unFix :: f (Fix f)}

I can construct a sample term:

 > term :: Expr (Expr (Expr expr))
 > term = Add (Lit 1, Add (Lit 2, Lit 3))

But isn't quite what I need. What I really need is:

 > term' :: Fix Expr
 > term' = Fix . Add $ (Fix . Lit $ 1, Fix . Add $ (Fix . Lit $ 2, Fix .
Lit $ 3))

I feel like there's a stupidly simple way to automatically produce term'
from term, but I'm not seeing it.

Any ideas?

Best,
Sebastien


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] building ghc on arch linux ARM?

[Francesco Mazzoli]

On 10/04/12 07:28, Karel Gardas wrote:

On 04/ 9/12 01:03 AM, Francesco Mazzoli wrote:

No, it is not possible to build GHC without GHC. Building GHC on ARM is
going to be extremely tricky (I'm not sure anyone has ever done it).


It's not that tricky at the end. Just install LLVM 3.0 and some OS
supplied unregisterised GHC. Grab 7.4.1. sources and attempt to compile.
This should produce even registerised build for you as a result of
project initiated last summer by Stephen Blackheath. If you are curious
about its history read some posts on http://ghcarm.wordpress.com/

Cheers,
Karel


Oh, I didn't notice that 7.4.1 shipped with this! Great stuff.

Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] building ghc on arch linux ARM?

[Francesco Mazzoli]

No, it is not possible to build GHC without GHC. Building GHC on ARM is 
going to be extremely tricky (I'm not sure anyone has ever done it).


What you should be able to do easily with the next release is 
cross-compile to ARM through the LLVM backend.


Francesco.

On 08/04/12 23:28, . wrote:

Hi Cafe,
I hope this is the right place to ask this kind of stuff.
I would like to try ghc on a panda board (armv7l) with arch linux.
There is apparently no pre-built package, so I was trying the
instructions to build, from here:
.

However, I still seem to need a ghc and ghc-pkg installed: I am getting
this error message:

checking for tar... /bin/tar
checking for gpatch... no
checking for patch... /usr/bin/patch
checking for dtrace... no
checking for HsColour... no
checking for xmllint... no
configure: WARNING: cannot find xmllint in your PATH, you will not be
able to validate your documentation
checking for xsltproc... no
configure: WARNING: cannot find xsltproc in your PATH, you will not be
able to build the HTML documentation
checking for dblatex... no
configure: WARNING: cannot find dblatex in your PATH, you will not be
able to build the PDF and PS documentation
checking for ghc-pkg matching ... configure: error: Cannot find matching
ghc-pkg

-

Does anyone know if it is possible to build ghc without ghc on this
platform?
I was using the tarball sources for ghc 7.4.1.


Thanks,
Christian



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The (!) operation

[Francesco Mazzoli]

Because Maybe is already a monad and it's nice to fail in the monad of
choice, e.g. if I'm in the list monad I get empty list instead, or if
I'm in the Result monad from JSON it'll fail in there. ‘Course "fail"
is suboptimal and MonadError might be better.


'fail' really shouldn't be in Monad. My brain ignores its existence by 
now :).



Grazie mille, a dopo… ;-)


A dopo!

Francesco

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The (!) operation

[Francesco Mazzoli]

(Though I seem to recall the monadic return value being frowned upon
but I don't recall why.)



The type signature that you wrote is very generic and doesn't help in 
introducing effects while retrieving the indexed value, which I imagine 
is what you wanted to do.


I guess you could define a type family for the monad type as well, e.g.:

type family Index f
type family IndexMonad f :: * -> *

class Functor f => Indexed f where
index :: Index f -> f a -> (IndexMonad f) (Maybe a)

Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The (!) operation

[Francesco Mazzoli]

Ok, this should suit your needs better, without functional dependencies 
as a bonus:


{-# LANGUAGE TypeFamilies, ScopedTypeVariables, FlexibleInstances #-}
module IxClass (IxClass(..)) where

import Data.Map (Map)
import qualified Data.Map as Map
import Data.Hashable (Hashable)
import Data.HashMap.Lazy (HashMap)
import qualified Data.HashMap.Lazy as HashMap

import qualified Data.List as List

class IxClass a where
type Ix a:: *
type Value a :: *

index  :: Ix a -> a -> Maybe (Value a)

(!) :: IxClass a => a -> Ix a -> (Value a)
a ! k = case index k a of
Just v  -> v
Nothing -> error "IxClass.(!): index not found"

instance IxClass [a] where
type Ix [a]= Int
type Value [a] = a

index _ []   = Nothing
index 0 (x : _)  = Just x
index n (_ : xs) = index (n - 1) xs

instance Ord k => IxClass (Map k v) where
type Ix (Map k v)= k
type Value (Map k v) = v

index = Map.lookup

instance (Hashable k, Eq k) => IxClass (HashMap k v) where
type Ix (HashMap k v)= k
type Value (HashMap k v) = v

index = HashMap.lookup

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The (!) operation

[Francesco Mazzoli]

Ops sorry, I had misunderstood, you don't want key-lookups but a simple 
indexing. In that case you might want an almost identical class but with 
different instances (e.g IxClass [a] Int a, etc.).


Also, I don't see why you need to throw monads in.

Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The (!) operation

[Francesco Mazzoli]

On 08/03/12 16:19, Christopher Done wrote:

‘Ello.

Is there a generalization of this operator? It's all over the place,
it's basically

 (!) :: (Monad m, Indexed collection index value) =>  index ->
container ->  m value

We have `(!!)` on lists, `(!)` on maps, vectors, json objects, …
(doesn't seem there's one for bytestring)

(Though I seem to recall the monadic return value being frowned upon
but I don't recall why.)

Thoughts?

Ciao!



Ciao!

It doesn't exist as far as I know, but a "Map" typeclass can be easily 
envisioned, e.g.:


{-# LANGUAGE MultiParamTypeClasses
   , FunctionalDependencies
   , FlexibleInstances
  #-}
module MapClass (MapClass(..)) where

import Data.Map (Map)
import qualified Data.Map as Map
import Data.Hashable (Hashable)
import Data.HashMap.Lazy (HashMap)
import qualified Data.HashMap.Lazy as HashMap

import qualified Data.List as List

class MapClass m k v | m -> k, m -> v where
empty  :: m
lookup :: k -> m -> Maybe v
insert :: k -> v -> m -> m

instance Ord k => MapClass [(k, v)] k v where
empty  = []
lookup = List.lookup
insert k v = ((k, v) :)

instance Ord k => MapClass (Map k v) k v where
empty  = Map.empty
lookup = Map.lookup
insert = Map.insert

instance (Hashable k, Eq k) => MapClass (HashMap k v) k v where
empty  = HashMap.empty
lookup = HashMap.lookup
insert = HashMap.insert

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data.Map: Values to keys and keys to values

[Francesco Mazzoli]

On 16/06/11 15:01, Dmitri O.Kondratiev wrote:

Hi,
Data.Map has many great functions, yet I could not find the one that
allows from one map create another map where keys are values and values
are keys of the first one.
Something like:
transMap:: (Ord k, Ord a) => Map k a -> Map a k

Does such function exist?
Thanks!



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


What about something like

transMap :: (Ord k, Ord a) => Map k a -> Map a k
transMap = M.fromList . map swap . M.toList

?

Francesco.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Loading bitmap with xlib

[Francesco Mazzoli]

Conrad Parker  metadecks.org> writes:

> 
> On 31 January 2011 21:40, Francesco Mazzoli  mazzo.li> wrote:
> > Francesco Mazzoli  mazzo.li> writes:
> >
> > At the end I gave up and I wrote the function myself:
> >
> > http://hpaste.org/43464/readbitmapfile
> >
> 
> cool ... the listed maintainer for the Xlib bindings is
> libraries  haskell.org. Perhaps you could prepare a patch and send it
> there? (does anyone know if there is an actual maintainer?)
> 
> Conrad.
> 
I will send a patch, but I'm sure there must be a reason behind the
fact that those functions were not included, even if I can't see it.

Francesco.




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Loading bitmap with xlib

[Francesco Mazzoli]

Francesco Mazzoli  mazzo.li> writes:

At the end I gave up and I wrote the function myself:

http://hpaste.org/43464/readbitmapfile


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Loading bitmap with xlib

[Francesco Mazzoli]

I am trying to load a bitmap and display it with the Xlib bindings, but I wasn't
able to find a way.
The C Xlib functions would be XReadBitmapFile() of XReadBitmapFileData() to read
the data, but it seems that those functions haven't been included in the haskell
bindings.
From
http://hackage.haskell.org/packages/archive/X11/latest/doc/html/src/Graphics-X11-Xlib-Misc.html:

-- XCreateBitmapFromData omitted (awkward looking type)
-- XReadBitmapFileData omitted (awkward looking type)

Does anybody know how to do that?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe