Re: How do I use CallStack?
Hi Richard, Sorry for all of the confusion, it seems the docs do indeed need some love! On Sun, Dec 6, 2015, at 20:56, Richard Eisenberg wrote: > That looks like exactly what I want. Thanks. > > There remain two mysteries: > - I thought that CallStacks were a new feature that would come with GHC > 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the > docs even say (wrongly, evidently) that it's in base since 4.9. They were originally merged into 7.11, but were backported to the official 7.10.2 release due to popular demand. It appears the @since annotation wasn't updated correspondingly. > - That function seems missing in HEAD. Or maybe it moved. A little > searching says it *did* move, to GHC.Exception. In HEAD we are now using CallStacks for error and undefined, which was not the case for the 7.10.2 release. This means the type needs to be defined much earlier in base, before we even have enough functionality to write a sensible formatter. showCallStack currently lives in GHC.Exception because that's where it's used, but that's not a good reason... I'll take another look at moving it back to GHC.Stack. > Well, my problem is solved. But I think the documentation needs a pass > here. And is there a reason not to have a Show instance? I usually only use compiler-derived Show instances so that Read automatically works, as well as some nice formatting libraries like http://hackage.haskell.org/package/pretty-show for debugging. For pretty-printing like showCallStack I prefer a standalone function or a separate type-class. If the name "showCallStack" suggests the compiler-derived output, we could change it to something like "prettyCallStack" or "formatCallStack", I don't have a strong opinion there. Thanks for the comments! Eric ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How do I use CallStack?
On Sun, Dec 6, 2015 at 11:56 PM, Richard Eisenberg wrote: > That looks like exactly what I want. Thanks. > > There remain two mysteries: > - I thought that CallStacks were a new feature that would come with GHC > 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the > docs even say (wrongly, evidently) that it's in base since 4.9. > Somehow some CallStack-related things snuck in between 7.10.1 and 7.10.2. Compare https://hackage.haskell.org/package/base-4.8.0.0/docs/GHC-Stack.html and https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html. Regards, Reid Barton ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How do I use CallStack?
Also, a call stack frame is just a (name, srcloc) pair, so you can format it yourself. I use: show_stack :: CallStack -> String show_stack = maybe "" show_frame . Seq.last . Stack.getCallStack where show_frame (name, srcloc) = SrcLoc.srcLocFile srcloc ++ ":" ++ show (SrcLoc.srcLocStartLine srcloc) ++ " [" ++ name ++ "]" On Sun, Dec 6, 2015 at 8:56 PM, Richard Eisenberg wrote: > That looks like exactly what I want. Thanks. > > There remain two mysteries: > - I thought that CallStacks were a new feature that would come with GHC 8.0. > Yet it seems the datatype is present in base-4.8.x. Even though the docs > even say (wrongly, evidently) that it's in base since 4.9. I've been using it since 7.10, with base 4.8. There's also a back port to 7.8, but it's not in the official distribution. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How do I use CallStack?
That looks like exactly what I want. Thanks. There remain two mysteries: - I thought that CallStacks were a new feature that would come with GHC 8.0. Yet it seems the datatype is present in base-4.8.x. Even though the docs even say (wrongly, evidently) that it's in base since 4.9. - That function seems missing in HEAD. Or maybe it moved. A little searching says it *did* move, to GHC.Exception. Well, my problem is solved. But I think the documentation needs a pass here. And is there a reason not to have a Show instance? Thanks! Richard On Dec 6, 2015, at 11:48 PM, Levent Erkok wrote: > There's a function for that: > https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html#v:showCallStack > > > > On Sun, Dec 6, 2015 at 8:43 PM, Richard Eisenberg wrote: > Hi devs, > > I wish to use the new CallStack feature to track call sites of a function. I > want my function to print out where it was called from. I do not want to call > `error`. How do I do this? > > I looked in the release notes. They describe the CallStack feature at an > overview, and the docs suggest that it has a Show instance. But the notes > don't say where to import CallStack from. I found it in GHC.Stack, but I'm > unsure this is the right place to take it from. The GHC release notes also > refer me to the ghc-prim release notes. These (which I assume are > ghc-prim/changelog.md) don't discuss CallStack. In any case, when I try to > `show ?callstack`, I learn that CallStack is not an instance of Show, or I > somehow haven't imported the instance. > > Help? > > Thanks! > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How do I use CallStack?
There's a function for that: https://hackage.haskell.org/package/base-4.8.1.0/docs/GHC-Stack.html#v:showCallStack On Sun, Dec 6, 2015 at 8:43 PM, Richard Eisenberg wrote: > Hi devs, > > I wish to use the new CallStack feature to track call sites of a function. > I want my function to print out where it was called from. I do not want to > call `error`. How do I do this? > > I looked in the release notes. They describe the CallStack feature at an > overview, and the docs suggest that it has a Show instance. But the notes > don't say where to import CallStack from. I found it in GHC.Stack, but I'm > unsure this is the right place to take it from. The GHC release notes also > refer me to the ghc-prim release notes. These (which I assume are ghc-prim/ > changelog.md) don't discuss CallStack. In any case, when I try to `show > ?callstack`, I learn that CallStack is not an instance of Show, or I > somehow haven't imported the instance. > > Help? > > Thanks! > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
How do I use CallStack?
Hi devs, I wish to use the new CallStack feature to track call sites of a function. I want my function to print out where it was called from. I do not want to call `error`. How do I do this? I looked in the release notes. They describe the CallStack feature at an overview, and the docs suggest that it has a Show instance. But the notes don't say where to import CallStack from. I found it in GHC.Stack, but I'm unsure this is the right place to take it from. The GHC release notes also refer me to the ghc-prim release notes. These (which I assume are ghc-prim/changelog.md) don't discuss CallStack. In any case, when I try to `show ?callstack`, I learn that CallStack is not an instance of Show, or I somehow haven't imported the instance. Help? Thanks! Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Kinds of type synonym arguments
I think this is a consequence of the rule that we never abstract over types of
kind #. But I believe this should work with my branch:
> type Tuple (a :: TYPE v1) (b :: TYPE v2) = (# a, b #)
The user would have to request that the synonym be used over both * and #, but
the synonym should work. The need to request the special treatment might be
lifted, but we'd have to think hard about where we want the generality by
default and where we want simpler behavior by default.
Richard
On Dec 6, 2015, at 1:55 PM, Ömer Sinan Ağacan wrote:
> In this program:
>
>{-# LANGUAGE MagicHash, UnboxedTuples #-}
>
>module Main where
>
>import GHC.Prim
>import GHC.Types
>
>type Tuple a b = (# a, b #)
>
>main = do
> let -- x :: Tuple Int# Float#
> x :: (# Int#, Float# #)
> x = (# 1#, 0.0# #)
>
> return ()
>
> If I use the first type declaration for 'x' I'm getting this error message:
>
>Expecting a lifted type, but ‘Int#’ is unlifted
>
> Indeed, if I look at the kinds of arguments of 'Tuple':
>
>λ:7> :k Tuple
>Tuple :: * -> * -> #
>
> It's star. I was wondering why is this not 'OpenKind'(or whatever the
> super-kind of star and hash). Is there a problem with this? Is this a bug?
> Or is this simply because type synonyms are implemented before OpenKinds?
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Allow ambiguous types (with warning) by default
That gets into making the whole parser / renamer / type checker a bit more incremental, and while that would be awesome, and an excellent example of that user experience can be seen in the lean theorem prover, its certainly trickier to see how to realize it in Haskell because the order in the module of top level decls has no bearing on what may be a mutually recursive knot of definitions. Likewise, while I definitely think that it's good to have the maximal set of independent type errors reported back, this is the same type error just deferred to a new location. Likewise, as ed notes, this would push a lot of errors out of libraries and into library clients , which just seems bad On Dec 6, 2015 12:15 AM, "David Feuer" wrote: > OK, fine. Is there a way to make it an error, but keep checking the > rest of the module? My goal is *get both messages if possible*, within > a module. I'm not tied to any particular mechanism of doing so. > > On Sun, Dec 6, 2015 at 12:13 AM, Edward Kmett wrote: > > If you aren't the one writing the code that can't be called you may never > > see the warning. It'll be tucked away in a cabal or stack build log > > somewhere. > > > > -Edward > > > > On Sun, Dec 6, 2015 at 12:06 AM, David Feuer > wrote: > >> > >> No, I want it to *warn* by default. If I write > >> > >> foo :: something that will fail the ambiguity check > >> bar = something that uses foo in a (necessarily) ambiguous way > >> > >> the current default leads me to do this: > >> > >> 1. Attempt to compile. Get an ambiguity error on foo whose exact cause > >> is hard for me to see. > >> 2. Enable AllowAmbiguousTypes and recompile. Get an error on bar whose > >> exact cause is completely obvious, and that makes it perfectly clear > >> what I need to do to fix foo. > >> 3. Fix foo, and disable AllowAmbiguousTypes. > >> > >> I'd much rather go with > >> > >> 1. Attempt to compile. Get an ambiguity *warning* on foo whose exact > >> cause is hard for me to see, but also an error on bar whose exact > >> cause is completely obvious, and that makes it perfectly clear what I > >> need to do to fix foo. > >> 2. Fix foo. > >> > >> Simple example of how it is currently: > >> > >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo > >> > >> :14:12: > >> Couldn't match expected type ‘F a’ with actual type ‘F a0’ > >> NB: ‘F’ is a type function, and may not be injective > >> The type variable ‘a0’ is ambiguous > >> In the ambiguity check for the type signature for ‘foo’: > >> foo :: forall a. Num a => F a > >> To defer the ambiguity check to use sites, enable > AllowAmbiguousTypes > >> In the type signature for ‘foo’: foo :: Num a => F a > >> > >> Couldn't match what with what? Huh? Where did a0 come from? > >> > >> > :set -XAllowAmbiguousTypes > >> > let foo :: Num a => F a; foo = undefined; bar :: Int; bar = foo > >> > >> :16:61: > >> Couldn't match expected type ‘Int’ with actual type ‘F a0’ > >> The type variable ‘a0’ is ambiguous > >> In the expression: foo > >> In an equation for ‘bar’: bar = foo > >> > >> Aha! That's the problem! It doesn't know what a0 is! How can I tell it > >> what a0 is? Oh! I can't, because foo doesn't give me a handle on it. > >> Guess I have to fix foo. > >> > >> I'd really, really like to get *both* of those messages in one go, > >> with the first one preferably explaining itself a bit better. > >> > >> On Sat, Dec 5, 2015 at 11:51 PM, Edward Kmett wrote: > >> > So you are saying you want users to write a ton of code that happens > to > >> > have > >> > signatures that can never be called and only catch it when they go to > >> > try to > >> > actually use it in a concrete situation much later? > >> > > >> > I don't really show how this would be a better default. > >> > > >> > When and if users see the problem later they have to worry about if > they > >> > are > >> > doing something wrong at the definition site or the call site. With > the > >> > status quo it complains at the right time that you aren't going to sit > >> > there > >> > flailing around trying to fix a call site that can never be fixed. > >> > > >> > -Edward > >> > > >> > On Sat, Dec 5, 2015 at 5:38 PM, David Feuer > >> > wrote: > >> >> > >> >> The ambiguity check produces errors that are quite surprising to the > >> >> uninitiated. When the check is suppressed, the errors at use sites > are > >> >> typically much easier to grasp. On the other hand, there's obviously > a > >> >> lot > >> >> of value to catching mistakes as soon as possible. Would it be > possible > >> >> to > >> >> turn that into a warning by default? > >> >> > >> >> > >> >> ___ > >> >> ghc-devs mailing list > >> >> ghc-devs@haskell.org > >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> >> > >> > > > > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/list
Re: Plugins: Accessing unexported bindings
Omer, Eric, Ed: Thanks for the comments. Omer: I think Eric's observation is at play here. We're talking about "dead-code," i.e., a binding that is neither exported, nor used by any binding inside the module. Those seem to be getting dropped by the time user-plugins are run. Unfortunately, this is precisely what one would do with "properties" embedded in code. They serve as documentation perhaps, but are otherwise not needed by any other binding nor it makes sense to export them. Edward: Can you provide some more info into your solution? Sounds like a chicken-egg issue to me: As a plugin author, I need the bindings to access the Ids, and looks like I need the Ids to access the binders? A simple solution would be to simply keep all top-level bindings around while the plugin are running, but that obviously can lead to unnecessary work if the code is truly dead. A compromise could be that the annotations can serve as entry points as well: I.e., if there's an annotation on a top-level binder, then it should *not* be considered dead-code at least until after all the plugins are run. That would definitely simplify life. Would that be an acceptable alternative? In the mean time, I'm still looking for a solution that doesn't involve exporting such identifiers from modules. As Eric pointed out, that seems to be the only current work-around for the time being. Thanks, -Levent. On Sun, Dec 6, 2015 at 11:08 AM, Eric Seidel wrote: > GHC should only drop un-exported bindings from the ModGuts if they're > also unused, ie *dead code*. > > The only way I know to get around this is to use the bindings somewhere, > or just export them. > > On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote: > > Hello, > > > > The mg_binds field of the ModGuts seem to only contain the bindings that > > are exported from the module being compiled. > > > > I guess GHC must be running user-plugins after it drops the bindings that > > are not exported, which makes perfect sense for most use cases. However, > > I'm working on a plugin where the end-programmer embeds "properties" in > > the > > form of functions inside his/her code, which are not necessarily exported > > from the module under consideration. > > > > Is there a way to access all top-level bindings in a module from a > > plugin, > > even if those bindings are not exported? > > > > Thanks, > > > > -Levent. > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Plugins: Accessing unexported bindings
GHC should only drop un-exported bindings from the ModGuts if they're also unused, ie *dead code*. The only way I know to get around this is to use the bindings somewhere, or just export them. On Sat, Dec 5, 2015, at 23:01, Levent Erkok wrote: > Hello, > > The mg_binds field of the ModGuts seem to only contain the bindings that > are exported from the module being compiled. > > I guess GHC must be running user-plugins after it drops the bindings that > are not exported, which makes perfect sense for most use cases. However, > I'm working on a plugin where the end-programmer embeds "properties" in > the > form of functions inside his/her code, which are not necessarily exported > from the module under consideration. > > Is there a way to access all top-level bindings in a module from a > plugin, > even if those bindings are not exported? > > Thanks, > > -Levent. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Kinds of type synonym arguments
In this program:
{-# LANGUAGE MagicHash, UnboxedTuples #-}
module Main where
import GHC.Prim
import GHC.Types
type Tuple a b = (# a, b #)
main = do
let -- x :: Tuple Int# Float#
x :: (# Int#, Float# #)
x = (# 1#, 0.0# #)
return ()
If I use the first type declaration for 'x' I'm getting this error message:
Expecting a lifted type, but ‘Int#’ is unlifted
Indeed, if I look at the kinds of arguments of 'Tuple':
λ:7> :k Tuple
Tuple :: * -> * -> #
It's star. I was wondering why is this not 'OpenKind'(or whatever the
super-kind of star and hash). Is there a problem with this? Is this a bug?
Or is this simply because type synonyms are implemented before OpenKinds?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
question about coercions between primitive types in STG level
Hi all, In my compiler pass(D1559, see ElimUbxSums.hs) I'm doing some unsafe coercions at the STG level. It works fine for lifted types, but for unlifted ones I'm having some problems. What I'm trying to do is given a number of primitive types I'm finding the one with biggest size, and then generating a constructor that takes this biggest primitive type as argument. The problem is that this is not working very well - GHC is generating illegal instructions that try to load a F32 value to a register allocated for I64, using movss instruction. CoreLint is catching this error and printing this: Cmm lint error: in basic block c1hF in assignment: _g16W::I64 = 4.5 :: W32; // CmmAssign Reg ty: I64 Rhs ty: F32 So I have two questions about this: 1. Is there a way to safely do this? What are my options here? What I'm trying to do is to use a single data constructor field for different primitive types. The field is guaranteed to be as big as necessary. 2. In the Cmm code shown above, the type annotation is showing `W32` but in the error message it says `F32`. I'm confused about this, is this error message given because the sizes don't match? (64bits vs 32bits) Why the type annotation says W32 while the value has type F32? Thanks.. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Plugins: Accessing unexported bindings
2015-12-06 2:01 GMT-05:00 Levent Erkok : > The mg_binds field of the ModGuts seem to only contain the bindings that are > exported from the module being compiled. This is not true, it contains all the definitions in the module and I'm relying on this all the time. I just tested again and it definitely has all the definitions in the module, exported or not. If it doesn't export everything in the module some optimizers couldn't really work. At least in my case the plugin API would be basically useless. May I ask how are you testing this? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Plugins: Accessing unexported bindings
If you have control over the Ids for the properties, if you can arrange for them to be marked "local exported" that should solve your problem. Edward Excerpts from Levent Erkok's message of 2015-12-05 23:01:29 -0800: > Hello, > > The mg_binds field of the ModGuts seem to only contain the bindings that > are exported from the module being compiled. > > I guess GHC must be running user-plugins after it drops the bindings that > are not exported, which makes perfect sense for most use cases. However, > I'm working on a plugin where the end-programmer embeds "properties" in the > form of functions inside his/her code, which are not necessarily exported > from the module under consideration. > > Is there a way to access all top-level bindings in a module from a plugin, > even if those bindings are not exported? > > Thanks, > > -Levent. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
