Re: Strange behavior when using stable names inside ghci?
Hi Facundo,
The program below when loaded in ghci prints always False, and when
compiled with ghc it prints True
From above, I guess the code is not compiled in ghci, which means
byte-code is used insted of object-code.
If what matter here is to get same result in ghci and compiled code,
invoking ghci with object code compilation option[1] may help. E.g.
start ghci with:
$ ghci -fobject-code
Below is a sample session with your code. I saved it as UCSN.hs.
$ ls
UCSN.hs
$ ghc-7.4.1 --interactive UCSN.hs
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling UCSN ( UCSN.hs, interpreted )
Ok, modules loaded: UCSN.
ghci :main
type enter
False
ghci :q
Leaving GHCi.
Invoking again, with -fobject-code. Note the absense of interpreted message:
$ ghc-7.4.1 --interactive -fobject-code UCSN.hs
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling UCSN ( UCSN.hs, UCSN.o )
Ok, modules loaded: UCSN.
ghci :main
type enter
True
ghci :q
Leaving GHCi.
Now we have UCSN.hi and UCSN.o.
$ ls
UCSN.hi UCSN.hs UCSN.o
Invoking ghci again, without -fobject-code.
No interpreted message. Showing 'True' with main.
$ ghc-7.4.1 --interactive UCSN.hs
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Ok, modules loaded: UCSN.
ghci :main
type enter
True
ghci :q
Leaving GHCi.
Hope these help.
[1]:
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-codegen
Regards,
--
Atsuro
On Thu, Jun 28, 2012 at 6:41 AM, Facundo Domínguez
facundoming...@gmail.com wrote:
Hi,
The program below when loaded in ghci prints always False, and when
compiled with ghc it prints True. I'm using ghc-7.4.1 and I cannot
quite explain such behavior. Any hints?
Thanks in advance,
Facundo
{-# LANGUAGE GADTs #-}
import System.Mem.StableName
import Unsafe.Coerce
import GHC.Conc
data D where
D :: a - b - D
main = do
putStr type enter
s - getLine
let i = fromEnum$ head$ s++0
d = D i i
case d of
D a b - do
let a' = a
sn0 - pseq a'$ makeStableName a'
sn1 - pseq b$ makeStableName b
print (sn0==unsafeCoerce sn1)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: API function to check whether one type fits in another
Philip
| What I'm looking for is a function
|
| fitsInto :: TermType - HoleType - Maybe [(TyVar,Type)]
Happily there is such a function, but you will need to become quite familiar
with GHC's type inference engine.
We need to tighten up the specification first. I believe that you have
function and argument, whose *most general types* are
fun :: forall a b c. fun_ty
arg :: forall p q. arg_ty
You want to ask whether 'arg' could possibly be 'fun's second (say) argument.
To answer this you must first instantiate 'fun' correctly. For example, suppose
fun :: forall a. [a] - Int
arg :: [Bool]
Then we can indeed pass 'arg' to 'fun' but only if we instantiate 'fun' at
Bool, thus:
fun Bool :: [Bool] - Int
Now indeed the first argument of (fun Bool) has precisely type [Bool] and we
are done.
This business of instantiating a polymorphic function with a type, using a type
application (f Bool) is a fundamental part of how GHC works (and indeed type
inference in general). If you aren't familiar with it, maybe try reading a
couple of papers about GHC's intermediate language, System F or FC.
To play this game we have to correctly guess the type at which to instantiate
'fun'. This is what type inference does: we instantiate 'fun' with a
unification variable 'alpha' meaning I'm not sure and then accumulate
equality constraints that tell us what type 'alpha' stands for.
The other complication is that 'arg' might also need instantiation to fit, but
I'll ignore that for now. It'll only show up in more complicated programs.
So you want a function something like this:
fits :: Type -- The type of the function
- Int-- Which argument position we are testing
- Type -- The argument
- TcM Bool-- Whether it fits
fits fun_ty arg_no arg_ty
= do { inst_fun_ty - deeplyInstantiate fun_ty
; llet (fun_arg_tys, fun_res_ty) = splitFunTys inst_fun_ty
the_arg_ty = fun_arg_tys !! arg_no
; unifyType the_arg_ty arg_ty }
The first step instantiates the function type (deeplyInstantiate is in
Inst.lhs) with fresh unification variables. The second extracts the
appropriate argument. Then we unify the argument type the function expects
with that of the supplied argument.
Even then you aren't done. Unification collects constraints, and we need to
check they are solutle. So we'll really need something like
do { constraints - captureConstriaints (fits fun_ty arg_no arg_ty)
; tcSimplifyTop constraints }
And the final thing you need to do is intiate the type checker monad with
initTc, and check whether any errors occurred.
It occurs to me that a simpler way to do this might be to piggy back on the
work of Thijs Alkemade [thijsalkem...@gmail.com] at Chalmers on holes. He's
going to make it possible to make an expression
fun _ arg
where the underscore means hole. Then you can give this entire expression to
the type checker and have it figure out whether it is typeable, and if so what
the type the _ is. This would mean you didn't need to do any of the above
stuff (and I have simplified considerably in writing the above). Maybe look at
the ticket http://hackage.haskell.org/trac/ghc/ticket/5910 and wiki page
http://hackage.haskell.org/trac/ghc/wiki/Holes
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Strange behavior when using stable names inside ghci?
You are, in effect, doing pointer equality here, which is certain to be
fragile, ESPECIALLY if you are not optimising the code (as is the case in
GHCi). I'd be inclined to seek a more robust way to solve whatever problem you
started with
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Facundo Domínguez
| Sent: 27 June 2012 22:41
| To: glasgow-haskell-users@haskell.org
| Subject: Strange behavior when using stable names inside ghci?
|
| Hi,
|The program below when loaded in ghci prints always False, and when
| compiled with ghc it prints True. I'm using ghc-7.4.1 and I cannot
| quite explain such behavior. Any hints?
|
| Thanks in advance,
| Facundo
|
| {-# LANGUAGE GADTs #-}
| import System.Mem.StableName
| import Unsafe.Coerce
| import GHC.Conc
|
| data D where
| D :: a - b - D
|
| main = do
|putStr type enter
|s - getLine
|let i = fromEnum$ head$ s++0
|d = D i i
|case d of
| D a b - do
| let a' = a
| sn0 - pseq a'$ makeStableName a'
| sn1 - pseq b$ makeStableName b
| print (sn0==unsafeCoerce sn1)
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: API function to check whether one type fits in another
Dear Simon, et al, Thank you very much for your reply. Some of the pointers you gave, I wouldn't have come across, for not knowing to have to browse through the module Inst, for example. I read the OutsideIn paper (JFP), but that's a fair while back. I was pointed to Thijs's work in progress at an Agda talk recently. The front-end we're working on should be portable to any lambda-language with strong types, so the availability of holes in Agda and Idris makes the implementation for those back-ends a breeze. There is one limiting consideration, however: We want to get this up and running the next few weeks and we would like to keep things in-sync with the developments on the different back-ends. This is why I'm trying to stay as close as possible to the more public API parts (the things that are documented and haven't changed significantly since at least 7.0.4). In this light, I was wondering whether it's not worth having a function that does all this plumbing in the API that is persistent through future versions, much like pure interface to the parser (GHC.parser). Preferably it would look something like: typeCheck :: DynFlags -- the flags - FilePath -- for source locations - Type -- expected - Type -- actual - Either SomeSortOfErrorStructure SomeSubstitutionAndOrConstraintTable The implementation would have to make sure the pre-conditions of the type arguments are met. Is this worth pursuing? Would be a significant amount of work? Am I being pushy if I make this a feature-request? Regards, Philip PS. I'm going to study the Trac you pointed to in more detail; browsing it was already a learning experience about the whats and wheres of the GHC API. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
Hi Johan, On Wed, Jun 27, 2012 at 03:06:39PM -0700, Johan Tibell wrote: On Wed, Jun 27, 2012 at 12:53 PM, Ian Lynagh ig...@earth.li wrote: If a GHC release needs an unreleased change in one of the libraries, and the maintainer (for whatever reason) is not responding to e-mails, should the GHC release be held up indefinitely? You didn't give a clear answer to my question. Am I right in thinking that your answer would be Yes, the GHC release should be delayed indefinitely? (or at least, for long enough for the maintainer to be declared MIA) Again, note that GHC is no different from any other package here. I think the problem is one of misunderstanding how the process of managing dependencies ought to work (and how it works elsewhere.) We must release a new version of so-and-so lib because we made such-and-such change is wrong. Upstream changes (i.e. to GHC deps) ought to happen before downstream releases of dependent code (i.e. GHC.) This is actually the main reason that the situation between GHC and the libraries it uses is different to most other packages, both within Haskell and without: It is true that ghc depends on (for example) containers; but containers also depends on base, and base/ghc are so intertwined that they are essentially the same package (at least, I don't think you're suggesting that we should make separate base and ghc releases). That is what I mean by them being part of the same system. For example, I recently removed the 'catch' export from Prelude, and this required corresponding changes in Cabal, Win32 and haskeline. It's not possible to make the change in the base library without making the corresponding changes, or the GHC build would break, and there's no reason the maintainers of the other packages would make the change if I didn't ask them to. A more mundane example is library dependencies. If we make a change in filepath that requires bumping its major version, then we need libraries such as Cabal to relax their dependency on filepath or, again, the GHC build would break. Has maintainer's not being responsive been a problem for GHC in the past? Yes. Some of the upstreams respond so fast that it makes my head spin, while others often either don't respond or continually promise to get to things soon. (again, these are good, well-meaning people, who do a lot for the community). I believe this is the first time I've seen an email of this kind from GHC HQ. Generally these mails are all directly to maintainers. They're generally longer than this, but in essence it normally goes something like mail 1: Could you take a look at this patch please? mail 2: Did you have a minute to look at that patch? mail 3: I think the patch is good. Would it help if I pushed it for you? mail 4: This is blocking other things, so I'd like to push it. Please let me know within a week if you object (there may be multiple mail 2s, and mail 3 sometimes gets an affirmative response). Once this has happened a few times, we tend to suggest switching to a system where we just push by default, without the need for the mails and the delay (in fact, more-or-less what Gershom suggested). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Strange behavior when using stable names inside ghci?
I'm using StableNames to recover sharing in abstract syntax trees of an embedded DSL, and I'm kind of following the approach of accelerate [1]. I was expecting the stable name comparison to be slightly more reliable. I'm pondering the alternatives. Many thanks for the replies. Facundo [1] http://hackage.haskell.org/package/accelerate On Thu, Jun 28, 2012 at 7:00 AM, glasgow-haskell-users-requ...@haskell.org wrote: Send Glasgow-haskell-users mailing list submissions to glasgow-haskell-users@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/glasgow-haskell-users or, via email, send a message with subject or body 'help' to glasgow-haskell-users-requ...@haskell.org You can reach the person managing the list at glasgow-haskell-users-ow...@haskell.org When replying, please edit your Subject line so it is more specific than Re: Contents of Glasgow-haskell-users digest... Today's Topics: 1. Re: Fwd: ghc-7.6 branch (Gershom Bazerman) 2. Re: Strange behavior when using stable names inside ghci? (Atsuro Hoshino) 3. RE: API function to check whether one type fits in another (Simon Peyton-Jones) 4. RE: Strange behavior when using stable names inside ghci? (Simon Peyton-Jones) -- Message: 1 Date: Wed, 27 Jun 2012 19:22:55 -0400 From: Gershom Bazerman gersh...@gmail.com Subject: Re: Fwd: ghc-7.6 branch To: glasgow-haskell-users@haskell.org Message-ID: 4feb95cf.9090...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 6/27/12 6:06 PM, Johan Tibell wrote: This is not a theoretical issue. We have had all of the following problems happen in the past due to the current process: * patches never making it upstream * releases of libraries without knowledge of the maintainer (who finds out by finding a new version of his/her package on Hackage.) * packages being released by GHC never ending up on Hackage, causing build breakages for people who use older GHCs and can't install the packages as they aren't available on Hackage. At the almost certain risk of stepping into a discussion I don't fully understand, let me step into a discussion I almost certainly don't fully understand :-) It seems to me that all these issues could be solved by having a member of the GHC team an assistant co-maintainer on packages that GHC depends on, and acting as such in a responsible manner, and in addition, having all packages bundled with GHC releases drawn from hackage releases. This is to say, that ghc-originated patches necessarily get committed to the upstream repo, because they must be there to be released on hackage, that ghc-originated patches necessarily get released to hackage because they must be there for GHC releases to draw on them, and maintainers necessarily know what gets released to hackage because they communicate well with co-maintainers. This is different than community ownership -- packages are still owned and maintained by individuals. However, by having a ghc assistant co-maintainer, there's a specified conduit for collaboration. This is also different from the current situation, because a co-maintainer may only work on issues for GHC release compatibility, but they are acting as someone with direct responsibility for the package and as part of the team that owns the package. Problems of collaboration aren't magiced away by this sort of change of titles, of course, but when there are problems of communication and collaboration, they can now be understood as and treated as problems between primary and secondary package maintainers. I hope this makes some semblance of sense. Cheers, Gershom -- Message: 2 Date: Thu, 28 Jun 2012 15:49:27 +0900 From: Atsuro Hoshino hoshinoats...@gmail.com Subject: Re: Strange behavior when using stable names inside ghci? To: Facundo Dom?nguez facundoming...@gmail.com Cc: glasgow-haskell-users@haskell.org Message-ID: CAN1AF6JfDhgqHkcvGLnxYD9=ixhwh0oqdidwoqqks_goewe...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Facundo, The program below when loaded in ghci prints always False, and when compiled with ghc it prints True From above, I guess the code is not compiled in ghci, which means byte-code is used insted of object-code. If what matter here is to get same result in ghci and compiled code, invoking ghci with object code compilation option[1] may help. E.g. start ghci with: $ ghci -fobject-code Below is a sample session with your code. I saved it as UCSN.hs. $ ls UCSN.hs $ ghc-7.4.1 --interactive UCSN.hs GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of
RE: Fwd: ghc-7.6 branch
| Has maintainer's not being responsive been a problem for GHC in the | past? | | Yes. Some of the upstreams respond so fast that it makes my head spin, | while others often either don't respond or continually promise to get to | things soon. (again, these are good, well-meaning people, who do a lot | for the community). The obvious solution, as someone else pointed out, is for someone at GHC HQ (perhaps Ian) to be a co-maintainer of these critical dependencies -- except perhaps for libraries whose maintainers are the make your head spin responsive kind. This would of course need the maintainer to trust the GHC person to push patches and make releases in sync with GHC. But my guess is they'd be willing. After all, we're all on the same side here! Would that cut the Geordian knot? Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
Hi Ian, On Thu, Jun 28, 2012 at 6:26 AM, Ian Lynagh ig...@earth.li wrote: You didn't give a clear answer to my question. Am I right in thinking that your answer would be Yes, the GHC release should be delayed indefinitely? I did answer it, just not with a yes or no as it's a false dichotomy. I gave you the 4 options that I think are reasonable. Perhaps someone could think of others, but those are the standard ones typically used by open source communities. (or at least, for long enough for the maintainer to be declared MIA) Something reasonable. Perhaps a few weeks to a month. Since this hasn't actually ever been a problem from what I can tell it doesn't matter much at this point. I had a quick look at the list of packages in question (http://hackage.haskell.org/trac/ghc/wiki/Repositories) and to my knowledge all these maintainers are around (and typically well-known contributors in the community.) I think the problem is one of misunderstanding how the process of managing dependencies ought to work (and how it works elsewhere.) We must release a new version of so-and-so lib because we made such-and-such change is wrong. Upstream changes (i.e. to GHC deps) ought to happen before downstream releases of dependent code (i.e. GHC.) This is actually the main reason that the situation between GHC and the libraries it uses is different to most other packages, both within Haskell and without: It is true that ghc depends on (for example) containers; but containers also depends on base, and base/ghc are so intertwined that they are essentially the same package (at least, I don't think you're suggesting that we should make separate base and ghc releases). That is what I mean by them being part of the same system. For example, I recently removed the 'catch' export from Prelude, and this required corresponding changes in Cabal, Win32 and haskeline. It's not possible to make the change in the base library without making the corresponding changes, or the GHC build would break, and there's no reason the maintainers of the other packages would make the change if I didn't ask them to. A more mundane example is library dependencies. If we make a change in filepath that requires bumping its major version, then we need libraries such as Cabal to relax their dependency on filepath or, again, the GHC build would break. Go ahead and make those changes to your local clones. That's reasonable. That in no way forces you to make releases of those packages. You have the time from you make the changes to the next GHC release to get the changes pushed upstream and released. Yes. Some of the upstreams respond so fast that it makes my head spin, while others often either don't respond or continually promise to get to things soon. (again, these are good, well-meaning people, who do a lot for the community). Have you tried pointing out that this is a problem for GHC and perhaps suggest that they let you make a release on their behalf? I believe this is the first time I've seen an email of this kind from GHC HQ. Generally these mails are all directly to maintainers. They're generally longer than this, but in essence it normally goes something like mail 1: Could you take a look at this patch please? mail 2: Did you have a minute to look at that patch? mail 3: I think the patch is good. Would it help if I pushed it for you? mail 4: This is blocking other things, so I'd like to push it. Please let me know within a week if you object (there may be multiple mail 2s, and mail 3 sometimes gets an affirmative response). Once this has happened a few times, we tend to suggest switching to a system where we just push by default, without the need for the mails and the delay (in fact, more-or-less what Gershom suggested). If the maintainer is fine with such a solution this is of course fine. But what if they're not? Note that this has nothing to do with releasing from HEAD, which GHC has typically done in the past. Such patches typically only require a patch release. P.S. The Haskell Platform is most likely moving to the complete opposite approach of what GHC uses; a call for version bumps will go out some time before the release and if maintainers don't ask to have their package version bumped, it will stay at the same version used for the last release. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fwd: ghc-7.6 branch
On Thu, Jun 28, 2012 at 10:47 AM, Simon Peyton-Jones simo...@microsoft.com wrote: | Has maintainer's not being responsive been a problem for GHC in the | past? | | Yes. Some of the upstreams respond so fast that it makes my head spin, | while others often either don't respond or continually promise to get to | things soon. (again, these are good, well-meaning people, who do a lot | for the community). The obvious solution, as someone else pointed out, is for someone at GHC HQ (perhaps Ian) to be a co-maintainer of these critical dependencies -- except perhaps for libraries whose maintainers are the make your head spin responsive kind. This would of course need the maintainer to trust the GHC person to push patches and make releases in sync with GHC. But my guess is they'd be willing. After all, we're all on the same side here! That works for me. If maintainers want to delegate to GHC HQ (and GHC HQ has the bandwidth to deal with these releases) that is of course fine. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
