RE: Question about correct GHC-API use for type checking (or zonking, or tidying)

2013-09-11 Thread p.k.f.holzenspies
Well, my tcLocalBinds seems to have a different type then yours (this is from 
my copy of 7.6.3 and it's the same in the HEAD that I just synced):

tcLocalBinds :: HsLocalBinds Name - TcM thing - TcM (HsLocalBinds TcId, thing)

If I want to get a GblEnv out, I can use getGblEnv, but doing this:


mkId :: Maybe FreeVars - LHsExpr Name - Name - TcM Id
mkId fvs expr@(L l _) nm = do
  ((binds', gbl_env),lie) - captureConstraints $ tcLocalBinds binds getGblEnv
  setGblEnv gbl_env (tcLookupId nm)
where
binds= HsValBinds $ ValBindsOut [(NonRecursive, unitBag fixbnd)] []
the_bind = mkTopFunBind (L l nm) [mkMatch [] expr emptyLocalBinds]
fixbnd   = L l $ maybe the_bind (\vs - the_bind { bind_fvs = vs }) fvs


fails on the tcLookupId with a GHC internal error complaining that my name is 
not in scope during type checking, but it passed the renamer.

Ph.




From: Simon Peyton-Jones [mailto:simo...@microsoft.com]
Sent: dinsdag 10 september 2013 14:19
To: Holzenspies, P.K.F. (EWI)
Cc: glasgow-haskell-users@haskell.org
Subject: RE: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

What goes wrong if you follow my suggestion below?

tcLocalBinds takes a set of bindings, such as x=e
and returns a GblEnv whose type envt is extended with a binding for x with its 
generalised type.
This type wil indeed be closed, unless the current environment (in which 
tcLocalBinds runs) has bindings with open types. Which in your case it probably 
doesn't.

I feel that I am not being helpful but I'm not sure how to help more.

S

From: Philip K.F. Hölzenspies [mailto:p.k.f.holzensp...@utwente.nl]
Sent: 04 September 2013 21:25
To: Simon Peyton-Jones
Cc: glasgow-haskell-users@haskell.orgmailto:glasgow-haskell-users@haskell.org
Subject: Re: Question about correct GHC-API use for type checking (or zonking, 
or tidying)

Ah, this is good to know. What I really would like is a function:

mkId :: Name - LHsExpr Name - TcM Id

where that Id is something I can store in my own monad (IA). The meaning of 
this, is indeed let name = expression as a top-level binding. The 
behaviour should actually be the same as that statement at the ghci-prompt. My 
IA monad implements liftTcM as something that invokes a TcM-monad, i.e.

liftTcM :: TcM b - IA b
liftTcM thing_inside = do
hsc_env - getSession
stored_ids - getStoredIds :: IA [Id]-- this is the list of all Ids 
made through mkId mentioned above
ioMsgMaybe . initTcPrintErrors hsc_env iNTERACTIVE $
setInteractiveContext hsc_env (hsc_IC hsc_env) $
tcExtendGlobalValEnv stored_ids $ -- or tcExtendIdEnv??
thing_inside

In the example you give below, I'm curious which thing_inside you give to 
tcLocalBinds to get you the correct global environment. Also, if I do what you 
suggest, i.e.

poly_id - setGblEnv gbl_env (tcLookupId the_id_name)

is that poly_id self contained, in the sense that I can put it in a new 
instantiation as shown above?

Regards,
Philip









[cid:image001.jpg@01CEAEDB.407DA510]
Simon Peyton-Jonesmailto:simo...@microsoft.com
September 4, 2013 6:00 PM
The id you are getting is a monomorphic id, with a type like a-a, not the 
polymorphic forall a. a-a.  You don't want to go round arbitrarily creating a 
new Id with the same unique but a different type. I have no idea what would 
happen then.

It's hard for me to understand just what you code is trying to do.  I think you 
are making bindig
it = some expr

and then you want the type of it.  Maybe something like

   (binds', gbl_env) - tcLocalBinds (..your bindin..)
   poly_id - setGblEnv gbl_env (tcLooupId the_id_name)

But I'm not totally sure.

S
inline: image001.jpg___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: 7.8 Release Update

2013-09-11 Thread 山本和彦
Hi,

Now I understand what is right and why I misunderstood.

- GHC 7.8 provides three kinds of libraries:
 - static libraries
 - dynamic libraries
 - static libraries for profiling
- GHCi uses dynamic libraries.
- Programs complied with GHC 7.8 use static libraries.
- When a library package is complied, both static one and dynamic
  one are created.
- When -p or --enabling-executable-profiling are specified to
  cabal, static libraries for profiling are also created and used.

So, we don't have to specify --enable-shared/--disable-shared to
cabal in normal situation.

There is no bug. Just I misunderstood.

* Why did I misunderstand that programs are linked dynamically?

I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally.
At the beginning, doctest cannot pass many tests if --enable-shared
is not specified. This was fixed:

https://github.com/sol/doctest-haskell/issues/58

Now, --enable-shared is not necessary even for doctest.

* Why did I misunderstand that compiling programs for profiling fails?

I specified --ghc-options=-prof -fprof-auto. -prof lets GHC 7.8
to produce both static and dynamic libraries for profiling. This
resulted in build failure.

Right procedure for profiling are:

% cabal install -p --enable-executable-profiling --ghc-options=-fprof-auto -j3

or

% cabal install -p --ghc-options=-fprof-auto --only-dependencies -j3
% cabal configure --enable-executable-profiling
% cabal build

--Kazu

 On 09/09/13 08:14, Edward Z. Yang wrote:
 Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08
 19:36:19 -0700 2013:
 
 % make show VALUE=GhcLibWays
 make -r --no-print-directory -f ghc.mk show
 GhcLibWays=v p dyn
 

 Yes, it looks like you are missing p_dyn from this list. I think
 this is a bug in the build system.  When I look at ghc.mk
 it only verifies that the p way is present, not p_dyn; and I don't
 see any knobs which turn on p_dyn.

 However, I must admit to being a little confused; didn't we abandon
 dynamic by default and switch to only using dynamic for GHCi (in which
 case the profiling libraries ought not to matter)?
 
 I think Kazu is saying that when he builds something with profiling
 using cabal-install, it fails because cabal-install tries to build a
 dynamic version too.  We don't want dyanmic/profiled libraries
 (there's no point, you can't load them into GHCi).  Perhaps this is
 something that needs fixing in cabal-install?
 
 Cheers,
   Simon
 
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users