[Haskell-cafe] Bad interface problem.

2012-07-03 Thread Magicloud Magiclouds
Hi,
  This had never happened to me. And I have no idea what to do.

$ cabal --upgrade-dependencies --enable-documentation
--force-reinstalls --solver=topdown QuickCheck-2.5
Test/QuickCheck/All.hs:15:1:
Bad interface file:
/home/magicloud/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.2/Language/Haskell/TH.hi
Something is amiss; requested module
template-haskell-2.6.0.0:Language.Haskell.TH differs from name found
in the interface file template-haskell:Language.Haskell.TH

$ cabal --version
cabal-install version 0.15.0
using version 1.15.0 of the Cabal library
-- 
竹密岂妨流水过
山高哪阻野云飞

And for G+, please use magiclouds#gmail.com.

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


[Haskell-cafe] Haskell Implementors' Workshop talk proposals due in one week!

2012-07-03 Thread Johan Tibell
 Call for Talks
   ACM SIGPLAN Haskell Implementors' Workshop

http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2012
   Copenhagen, Denmark, September 14th, 2012
The workshop will be held in conjunction with ICFP 2012
http://www.icfpconference.org/icfp2012/

Important dates

Proposal Deadline:  10th July  2012
Notification:   27th July  2012
Workshop:   14th September 2012

The Haskell Implementors' Workshop is to be held alongside ICFP 2012
this year in Copenhagen, Denmark. There will be no proceedings; it is an
informal gathering of people involved in the design and development of
Haskell implementations, tools, libraries, and supporting
infrastructure.

This relatively new workshop reflects the growth of the user community:
there is a clear need for a well-supported tool chain for the
development, distribution, deployment, and configuration of Haskell
software. The aim is for this workshop to give the people involved with
building the infrastructure behind this ecosystem an opportunity to bat
around ideas, share experiences, and ask for feedback from fellow
experts.

We intend the workshop to have an informal and interactive feel, with a
flexible timetable and plenty of room for ad-hoc discussion, demos, and
impromptu short talks.


Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2012. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment


Talks
-

At this stage we would like to invite proposals from potential speakers
for a relatively short talk. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 200 words to:
johan.tib...@gmail.com

We will also have a lightning talks session which will be organised on
the day. These talks will be 2-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.


Organisers
--

  * Lennart Augustsson (Standard Chartered Bank)
  * Manuel M T Chakravarty (University of New South Wales)
  * Gregory Collins - co-chair (Google)
  * Simon Marlow   (Microsoft Research)
  * David Terei(Stanford University)
  * Johan Tibell - co-chair(Google)

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


[Haskell-cafe] Using syntactic to implement the lambda calculus

2012-07-03 Thread Alex Rozenshteyn
(This is intended as a simplification of the problem I actually need to
solve.)

I'm trying to implement the lambda calculus (with CBV evaluation) using the
syntactic package, in such a way that a simple extension is also simple
to implement.

I am stuck on the fact that it seems that the Value type needs to be
parametrized over the Expr type and I can't seem to figure out how to do it.

I've read this 
posthttp://www.haskell.org/pipermail/haskell-cafe/2011-May/091770.htmlfrom
the archives, but I still seem to be missing something.

Does anyone have any suggestions?

 -- Lambda calculus
 type Ident = String
 data Value = VLam Ident Expr
 data Expr = Var Ident | Lam Ident Expr | App Expr Expr
 eval :: Expr - Value
 eval e =
   case e of
 Var _ - error not closed
 Lam i e' - VLam i e'
 App e1 e2 -
   case eval e1 of
 Lam i e' - subst e' (eval e2) i
 _ - error illegal application

 -- Lambda calculus with integers and addition
 data Value = VLam Ident Expr | VInt Integer
 data Expr = Var Ident | Lam Ident Expr | App Expr Expr | Plus Expr Expr
 eval e =
   case e of
 ...
 Plus e1 e2 -
   case (eval e1, eval e2) of
 (VInt x1, VInt x2) - VInt $ x1 + x2
 _ - error illegal addition

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


Re: [Haskell-cafe] existential types and cast

2012-07-03 Thread MigMit
Actually, using cast seems to be a perfect solution here. I can't see anything 
wrong with it.

Отправлено с iPad

03.07.2012, в 20:33, Corentin Dupont corentin.dup...@gmail.com написал(а):

 Hi all,
 I read somewhere (here: 
 http://stackoverflow.com/questions/2300275/how-to-unpack-a-haskell-existential-type)
  that it's bad to try to unbox an existential type using a cast. OK, but 
 without I really can't figure out how to do what I want:
 
 data NewPlayer = NewPlayer deriving (Typeable, Eq)
 data NewRule = NewRule deriving (Typeable, Eq)
 
 class (Eq e, Typeable e) = Event e where
 data EventData e
 
 instance Event NewPlayer where
 data EventData NewPlayer = P Int
 
 instance Event NewRule where
 data EventData NewRule = R Int
 
 instance Typeable1 EventData where 
 typeOf1 _ = mkTyConApp (mkTyCon EventData) []
 
 data EventHandler = forall e . (Event e) = EH e (EventData e - IO ())
 
 addEvent :: (Event e) = e - (EventData e - IO ()) - [EventHandler] - 
 [EventHandler] 
 addEvent e h ehs = (EH e h):ehs
 
 triggerEvent :: (Event e) = e - (EventData e) - [EventHandler] - IO ()
 triggerEvent e d ehs = do
 let r = find (\(EH myEvent _) - cast e == Just myEvent) ehs
 case r of
Nothing - return ()
Just (EH _ h) - case cast h of
 Just castedH - castedH d
 Nothing - return ()
 
 How to remove the casts from triggerEvent? All that I want is to apply the 
 handler found on the data passed in parameter.
 I tried to add a function apply in the class, without success:
 apply :: (EventData e - IO ()) - (EventData e) - IO ()
 apply = ($)
 
 
 Thanks!
 Corentin
 ___
 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] Martin Odersky on What's wrong with Monads

2012-07-03 Thread Alvaro Gutierrez
On Tue, Jun 26, 2012 at 6:19 PM, Tillmann Rendel
ren...@informatik.uni-marburg.de wrote:
 How would you implement this requirement in Haskell without changing the
 line amount (Leaf x) = x?

The hflags library [http://hackage.haskell.org/package/hflags] seems
to do that, however...

 (I actually see three ways of doing this in Haskell, but all have serious
 drawbacks and do not fully solve the problem).

...it uses the unsafe IO trick
[http://www.haskell.org/haskellwiki/Top_level_mutable_state], which
may be one of those three ways you aren't fond of.

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


Re: [Haskell-cafe] Martin Odersky on What's wrong with Monads

2012-07-03 Thread Alvaro Gutierrez
On Thu, Jun 28, 2012 at 2:53 PM, Dominique Devriese
dominique.devri...@cs.kuleuven.be wrote:
 2012/6/27 Tillmann Rendel ren...@informatik.uni-marburg.de:
 How would you implement this requirement in Haskell without changing the
 line amount (Leaf x) = x?

 I may be missing the point here, but having worked on large code bases
 with a wide variety contributors before, I find it very advantageous
 that programmers are prevented from writing an amount function whose
 behaviour depends on command line arguments without at least an
 indication in the type. The fact that the function can not perform
 stuff like that is precisely the guarantee that the Haskell type gives
 me...

I don't think there's an answer that's uniformly right; it depends on
whether you think of the input to the program, e.g. the environment,
command-line arguments, etc. as 'constant' and in some sense, pure.
The latter are constant in the sense that they never change, but they
are not fixed at compile-time. Other languages effectively treat them
as pure (by passing them directly to main), whereas Haskell chooses
not to, which is probably the reason why getArgs has IO in its type
(something that seems unintuitive at first.)

That precedent supports the view that e.g. a command-line flag
shouldn't affect behavior without the type reflecting it, e.g. by
doing IO, but the de facto use of the unsafe IO trick means not
everyone agrees.

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