RE: GHC Api
| Is this with a statically linked or dynamically linked GHC? I don't know. How would I find out? (It's the one built by validate.) You are asking about GHC, but I guess there's also the question of whether the test program itself is statically or dynamically linked. I don't know that either. I just said ~/5builds/HEAD-2/inplace/bin/ghc-stage2 -o T8628 T8628.hs -package ghc Why would static/dynamic linking make a difference? That's very confusing! | Does doing | runStmt hFlush stdout | afterwards make it appear? Yes, it does. Again, that's very confusing. Shouldn't we automatically do a hFlush, so that output is not silently discarded? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ian | Lynagh | Sent: 02 January 2014 18:29 | To: ghc-devs@haskell.org | Subject: Re: GHC Api | | On Thu, Jan 02, 2014 at 03:10:24PM +, Simon Marlow wrote: | On 02/01/14 07:06, Simon Peyton-Jones wrote: | | Happy new year! | | And to you :-) | | runStmt “print True” -- (4) | | 4.The runStmt should print something somewhere, but it doesn’t. Why | not? | | I've no idea! It does look like it should print something. | | Is this with a statically linked or dynamically linked GHC? | | Does doing | runStmt hFlush stdout | afterwards make it appear? | | | Thanks | Ian | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC head with clang on Mavericks
2014/1/2 Carter Schonwald carter.schonw...@gmail.com: it looks like their work around is using ## rather than /**/ Well, actually lens is bypassing the problem by using cpphs, not the C preprocessor. :-P OpenGLRaw is part of the Haskell Platform, and cpphs is not, so I can't simply depend on it. (Licensing issues IIRC?) Don't do that is not an option, either, at least not until the binding is auto-generated. If I see this correctly, I really have to do some preprocessor magic (slightly simplified output): - svenpanne@svenpanne:~$ cat preprocess.hs #define FOO(x) bla/**/x x #define BAR(x) bla##x #x FOO(baz) BAR(boo) svenpanne@svenpanne:~$ gcc -traditional -E -x c preprocess.hs blabaz baz bla##boo #boo svenpanne@svenpanne:~$ gcc -E -x c preprocess.hs bla baz x blaboo boo svenpanne@svenpanne:~$ clang -traditional -E -x c preprocess.hs bla baz x bla##boo #boo svenpanne@svenpanne:~$ clang -E -x c preprocess.hs bla baz x blaboo boo - If -traditional is not used, things are simple and consistent, and we can simply use ## and #. Alas, -traditional *is* used, so we can't use ## and # with gcc an we are out of luck with clang. This really sucks, and I consider the clang -traditional behavior a bug: How can you do concatenation/stringification with clang -traditional? One can detect clang via defined(__clang__) and the absence of -traditional via defined(__STDC__), but this doesn't really help here. Any suggestions? I am testing with a local clang 3.4 version (trunk 193323), but I am not sure if this matters. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: ticket for adding ARM backend to NCG?
| I've been tinkering with ARM NCG idea for quite some time now, but | honestly I've been always in doubts if it's the best way for GHC at all. | I've thought that the plan was to kind of move out of NCG to LLVM based | backends and I've though that although this plan may be kind of stuck | now, it's still on the table. I have not been following the ARM and LLVM threads very closely, but here's my take: * LLVM is (I hope) very much on the table. LLVM itself is a well-resourced project, and we can expect it to continue to exist. We should piggy-back on all the hard work that is going into it. * But using LLVM has some disadvantages. a) it imposes a dependency on LLVM b) it makes compilation slower c) we play some efficiency tricks (notably tables next to code) that LLVM can't play (yet). I think. So GHC currently aims to have a built-in NCG for popular platforms, and to rely on LLVM for more esoteric platforms and also for superior optimisation. Is this still a sensible policy? Maybe you can articulate your doubts on the ARM NCG? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel | Gardas | Sent: 03 January 2014 11:24 | To: Jens Petersen | Cc: ghc-devs@haskell.org | Subject: Re: ticket for adding ARM backend to NCG? | | | Guys, | | I've been tinkering with ARM NCG idea for quite some time now, but | honestly I've been always in doubts if it's the best way for GHC at all. | I've thought that the plan was to kind of move out of NCG to LLVM based | backends and I've though that although this plan may be kind of stuck | now, it's still on the table. | | Yes, I know that GHC is volunteering effort so if someone comes and asks | for an ARM NCG implementation merge it'll be probably done in some time, | but I'm not sure if it's what's the most welcome at the end. | | Just some of my doubts about it... | | I would really appreciate some authoritative word about the topic from | more involved GHC developers... I mean especially about NCG future... | | Thanks! | Karel | | On 01/ 3/14 09:35 AM, Jens Petersen wrote: | On 3 January 2014 03:10, Corey O'Connor coreyocon...@gmail.com | mailto:coreyocon...@gmail.com wrote: | | My interest is just to get involved somehow in the NCG. Starting a | new backend seemed reasonable only because I couldn't break | something that didn't exist. ;-) | | | Well a big +1 from me for armv7 NCG. | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHC Api
| setSessionDynFlags loads the package database and does the necessary | processing to make packages available. We don't do that automatically, | because the client might want to add their own package flags to the | DynFlags between the calls to getSessionDynFlags and setSessionDynFlags. So it would be *OK* for runGhc to call setSessionDynFlags; but it might be a bit inefficient in the case you describe where the user adds their own package flags (which is uncommon). Correct? In that case, couldn't runGhc do the package initialisation thing, and we can perhaps provide a super-efficient variant of runGhc that doesn't do so for the reason you state? That would make the common case simple. | I'm not all that familiar with the unsafeGlobalDynFlags stuff (that's | Ian's invention), but from looking at the code it looks like you | wouldn't need to call this if you were calling parseDynamicFlags. It | should be safe to call parseDynamicFlags with an empty set of flags to | parse. True but weird. The point is that, instead of parsing a string, runGhc creates a fresh empty DynFlags (in inigGhcMonad actually). Since this is an alternative to parsing a string, it should set the static thing too, just as the string-parsing route does (in parseDynamicFlagsFull, as you point out). I'll do this unless you or Ian object. | I think it's sensible to require a call to setContext to bring the | Prelude into scope. The client might want a different context, and | setContext isn't free, so we probably don't want to initialise a default | context. This is very similar to the first point above. Maybe runGhc can do common thing (initialise packages, import Prelude), with a variant that doesn't? What do others think? Simon | -Original Message- | From: Simon Marlow [mailto:marlo...@gmail.com] | Sent: 02 January 2014 15:10 | To: Simon Peyton-Jones | Cc: ghc-devs | Subject: Re: GHC Api | | On 02/01/14 07:06, Simon Peyton-Jones wrote: | Simon and othere | | Happy new year! | | When debugging Trac #8628 I wrote the following: | | main | | = do [libdir] - getArgs | | ok - runGhc (Just libdir) $ do | | dflags - getSessionDynFlags -- (1) | | setSessionDynFlags dflags | | liftIO (setUnsafeGlobalDynFlags dflags) -- (2) | | setContext [IIDecl (simpleImportDecl pRELUDE_NAME)] -- (3) | | runDecls data X = Y Int | | runStmt print True -- (4) | | return () | | There are several odd things here | | 1.Why do I have to do this getSessionDynFlags/setSessionDynFlags | thing. Seems bizarre. I just copied it from some other tests in | ghc-api/. Is it necessary? If not, can we remove it from all tests? | | It's a sensible question given the naming of the functions. The API is | definitely clunky here, but there is a purpose to these calls. | setSessionDynFlags loads the package database and does the necessary | processing to make packages available. We don't do that automatically, | because the client might want to add their own package flags to the | DynFlags between the calls to getSessionDynFlags and setSessionDynFlags. | Incidentally you can find out some of this stuff from the Haddock docs, | e.g. look at the docs for setSessionDynFlags. | | 2.Initially I didn't have that setUnsafeGlobalDynFlags call. But then | I got | | T8628.exe: T8628.exe: panic! (the 'impossible' happened) | | (GHC version 7.7.20131228 for i386-unknown-mingw32): | |v_unsafeGlobalDynFlags: not initialised | | which is a particularly unhelpful message. It arose because I was | using a GHC built with assertions on, and a warnPprTrace triggered. | Since this could happen to anyone, would it make sense to make this | part of runGhc and setSessionDynFlags? | | I'm not all that familiar with the unsafeGlobalDynFlags stuff (that's | Ian's invention), but from looking at the code it looks like you | wouldn't need to call this if you were calling parseDynamicFlags. It | should be safe to call parseDynamicFlags with an empty set of flags to | parse. | | 3.Initially I didn't have that setContext call, and got a complaint | that Int is not in scope. I was expecting the Prelude to be | implicitly in scope. But I'm not sure where to fix that. Possibly | part of the setup in runGhc? | | I think it's sensible to require a call to setContext to bring the | Prelude into scope. The client might want a different context, and | setContext isn't free, so we probably don't want to initialise a default | context. | | 4.The runStmt should print something somewhere, but it doesn't. Why | not? | | I've no idea! It does look like it should print something. | | Cheers, | Simon | | What do you think? | | Simon | ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Extending fold/build fusion
Hi,
I have been thinking about how foldl' can be turned into a good consumer,
and I came up with something that I thought would work. So I'd like to ask
for opinions from the ghc devs: if this idea looks good, if it is a known
bad idea, if there is a better way to do it, etc.
The main idea is to have an extended version of foldr:
-- | A mapping between @a@ and @b@.
data Wrap a b = Wrap (a - b) (b - a)
foldrW
:: (forall e. Wrap (f e) (e - b - b))
- (a - b - b) - b - [a] - b
foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0
where
go = unwrap $ \list z' - case list of
[] - z'
x:xs - f x $ wrap go xs z'
This allows the user to apply an arbitrary worker-wrapper transformation
to the loop.
Using this, foldl' can be defined as
newtype Simple b e = Simple { runSimple :: e - b - b }
foldl' :: (b - a - b) - b - [a] - b
foldl' f initial xs = foldrW (Wrap wrap unwrap) g id xs initial
where
wrap (Simple s) e k a = k $ s e a
unwrap u = Simple $ \e - u e id
g x next acc = next $! f acc x
The wrap and unwrap functions here ensure that foldl' gets compiled into a
loop that returns a value of 'b', rather than a function 'b - b',
effectively un-CPS-transforming the loop.
I put preliminary code and some more explanation on Github:
https://github.com/takano-akio/ww-fusion
Thank you,
Takano Akio
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Starting GHC development.
Thank you. We need lots of help! I can't expect to jump right in and just become one with 20 years of development, but I do plan on whacking away at the low hanging fruit until it all starts making sense. -Chris ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Type-level reasoning ability lost for TypeLits?
Hi Gabor, On Fri, Jan 3, 2014 at 9:33 AM, Gabor Greif ggr...@gmail.com wrote: Hi devs, with recent iterations of GHC.TypeLits (HEAD) I am struggling to get something simple working. I have data Number nat = KnownNat nat = Number !(Proxy nat) and want to write addNumbers :: Number a - Number b - Maybe (Number (a + b)) Unfortunately I cannot find a way to create the necessary KnownNat (a + b) constraint. Indeed, there is no way to construct `KnownNumber (a + b)` from `(Known a, Known b)`. This is not something that we lost, it was just never implemented. We could make something like it work, I think, but it'd make things a bit more complex: the representation of `KnownNumber` dictionaries would have to be expressions, rather than a simple constant. I'd be inclined to leave this as is for now---let's see what we can do with the current system, before we add more functionality. Declaring the function thus addNumbers :: KnownNat (a + b) = Number a - Number b - Maybe (Number (a + b)) only dodges the problem around. Dodging problems is good! :-) I don't fully understand from the type what the function is supposed to do, but I'd write something like this: addNumbers :: (KnownNat a, KnownNat b) = (Integer - Integer - Bool) -- ^ Some constraint? Proxy a - Proxy b - Maybe (Proxy (a + b)) addNumber p x y = do guard (p (natVal x) (natVal y)) return Proxy Also I am wondering where the ability to perform a type equality check went. I.e. I cannot find the relevant functionality to obtain sameNumber :: Number a - Number b - Maybe (a :~: b) I guess there should be some TestEquality instance (for Proxy Nat?, is this possible at all), but I cannot find it. Same applies for Symbols. Ah yes, I thought that this was supposed to be added to some other library, but I guess that never happened. It was implemented like this, if you need it right now. sameNumber :: (KnownNat a, KnownNat b) = Proxy a - Proxy b - Maybe (a :~: b) sameNumber x y | natVal x == natVal y = Just (unsafeCoerce Refl) | otherwise= Nothing This doesn't fit the pattern for the `TestEquality` class (due to the constraints on the parameters), so perhaps I'll add it back to GHC.TypeLits. -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ticket for adding ARM backend to NCG?
On 3 January 2014 12:37, Simon Peyton-Jones simo...@microsoft.com wrote: * But using LLVM has some disadvantages. c) we play some efficiency tricks (notably tables next to code) that LLVM can't play (yet). I think. In fact, this could well be implemented in the GHC 7.10, as this has been committed in LLVM on 15th September: http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html Implementing tables next to code in the LLVM IR generation may be something to get one's teeth into in time for 7.10 ? Carter: was this discussed further on #haskell-llvm ? -- Rob | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel | Gardas | Sent: 03 January 2014 11:24 | To: Jens Petersen | Cc: ghc-devs@haskell.org | Subject: Re: ticket for adding ARM backend to NCG? | | | Guys, | | I've been tinkering with ARM NCG idea for quite some time now, but | honestly I've been always in doubts if it's the best way for GHC at all. | I've thought that the plan was to kind of move out of NCG to LLVM based | backends and I've though that although this plan may be kind of stuck | now, it's still on the table. | | Yes, I know that GHC is volunteering effort so if someone comes and asks | for an ARM NCG implementation merge it'll be probably done in some time, | but I'm not sure if it's what's the most welcome at the end. | | Just some of my doubts about it... | | I would really appreciate some authoritative word about the topic from | more involved GHC developers... I mean especially about NCG future... | | Thanks! | Karel | | On 01/ 3/14 09:35 AM, Jens Petersen wrote: | On 3 January 2014 03:10, Corey O'Connor coreyocon...@gmail.com | mailto:coreyocon...@gmail.com wrote: | | My interest is just to get involved somehow in the NCG. Starting a | new backend seemed reasonable only because I couldn't break | something that didn't exist. ;-) | | | Well a big +1 from me for armv7 NCG. | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Starting GHC development.
On 03/01/14 18:50, Gabor Greif wrote: On 1/3/14, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 03/01/14 13:27, Simon Peyton-Jones wrote: [snip] Thank you. We need lots of help! [snip] While I hate to interrupt this thread, I think this is a good chance to mention something. I think the big issue for joining GHC development is the lack of communication on the mailing list. There are many topics where a person has a problem with GHC tree (can't validate/build, some tests are failing), posts to GHC devs seeking help and never gets a reply. This is very discouraging and often makes it outright impossible to contribute. An easy example is the failing tests one: unfortunately some tests are known to fail, but they are only known to fail to existing GHC devs. A new person tries to validate clean tree, gets test failures, asks for help on GHC devs, doesn't get any, gives up. We should explicitly say somewhere that pinging for an answer is okay. Sometimes the key persons (for a potential answer) are out of town or too busy, and the question gets buried. Repeating the answer a few days later raises awareness and has higher chance to succeed. This is how other technical lists (e.g. LLVM's) work. Cheers, Gabor While bumping the thread might help, I don't think people missing it is always the case. Refer to Carter's recent e-mail about something very important: when is 7.8 finally happening. It was pinged 9 days later by Kazu and still no replies! In the end he had to make another thread nearly half a month after his initial one and directly CC some people to get any output… I think it's more about ‘I'm not 100% sure here so I won't say anything’ which is terrible for newcomers because to them it seems like everyone ignored their thread. For a newcomer, even ‘did you try make maintainer-clean’ might be helpful. At least they don't feel ignored. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Api
On Fri, Jan 03, 2014 at 10:19:02AM +, Simon Peyton-Jones wrote: | Is this with a statically linked or dynamically linked GHC? I don't know. How would I find out? (It's the one built by validate.) You are asking about GHC, but I guess there's also the question of whether the test program itself is statically or dynamically linked. Oh, yes, sorry, I was thinking this was in ghci for some reason. You're right that it's the test program we need to know about. Why would static/dynamic linking make a difference? That's very confusing! With dynamic linking, there will be one shared copy of base, and in particular one shared stdout buffer. The runtime will flush that buffer when the program exits. With static linking, you'll be loading a second copy of base in which the statement is evalauted, and that base will have a separate stdout buffer. GHCi flushes this when appropriate by calling flushInterpBuffers. Thanks Ian ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Type-level reasoning ability lost for TypeLits?
On 1/3/14, Iavor Diatchki iavor.diatc...@gmail.com wrote:
Hi Gabor,
Hi Iavor, thanks for replying promptly!
On Fri, Jan 3, 2014 at 9:33 AM, Gabor Greif ggr...@gmail.com wrote:
Hi devs,
with recent iterations of GHC.TypeLits (HEAD) I am struggling to get
something simple working. I have
data Number nat = KnownNat nat = Number !(Proxy nat)
and want to write
addNumbers :: Number a - Number b - Maybe (Number (a + b))
Unfortunately I cannot find a way to create the necessary KnownNat (a
+ b) constraint.
Indeed, there is no way to construct `KnownNumber (a + b)` from `(Known a,
Known b)`. This is not something that we lost, it was just never
implemented. We could make something like it work, I think, but it'd make
things a bit more complex: the representation of `KnownNumber` dictionaries
would have to be expressions, rather than a simple constant.
Edwardkmettian dictionary-coercion tricks might help, but:
instance (KnownNat a, KnownNat b) = KnownNat (a + b)
testTypeNats.lhs:1:40:
Illegal type synonym family application in instance: a + b
In the instance declaration for 'KnownNat (a + b)'
So we have more fundamental problems here. Why is this illegal?
I'd be inclined to leave this as is for now---let's see what we can do with
the current system, before we add more functionality.
Okay, I'll ponder a bit how such a thing would look like.
Declaring the function thus
addNumbers :: KnownNat (a + b) = Number a - Number b - Maybe (Number
(a + b))
only dodges the problem around.
Dodging problems is good! :-) I don't fully understand from the type what
the function is supposed to do, but I'd write something like this:
addNumbers :: (KnownNat a, KnownNat b)
= (Integer - Integer - Bool) -- ^ Some constraint?
Proxy a - Proxy b - Maybe (Proxy (a + b))
addNumber p x y =
do guard (p (natVal x) (natVal y))
return Proxy
I souped this up thus:
{-# LANGUAGE TypeSynonymInstances, TypeOperators, GADTs #-}
import GHC.TypeLits
import Data.Proxy
import Control.Monad
data Number nat = KnownNat nat = Number !(Proxy nat)
addNumbers :: Number a - Number b - Maybe (Number (a + b))
(Number a@Proxy) `addNumbers` (Number b@Proxy)
= case addNumber (\_ _- True) a b of Just p - Just $ Number p
addNumber :: (KnownNat a, KnownNat b)
= (Integer - Integer - Bool) -- ^ Some constraint?
- Proxy a - Proxy b - Maybe (Proxy (a + b))
addNumber p x y =
do guard (p (natVal x) (natVal y))
return Proxy
And I get an error where I wrap the Number constructor around the
resulting proxy:
testTypeNats.lhs:11:60:
Could not deduce (KnownNat (a + b)) arising from a use of 'Number'
from the context (KnownNat a)
bound by a pattern with constructor
Number :: forall (nat :: Nat).
KnownNat nat =
Proxy nat - Number nat,
in an equation for 'addNumbers'
at testTypeNats.lhs:10:4-17
or from (KnownNat b)
bound by a pattern with constructor
Number :: forall (nat :: Nat).
KnownNat nat =
Proxy nat - Number nat,
in an equation for 'addNumbers'
at testTypeNats.lhs:10:34-47
In the second argument of '($)', namely 'Number p'
In the expression: Just $ Number p
In a case alternative: Just p - Just $ Number p
Getting the sum proxy is not the problem.
Also I am wondering where the ability to perform a type equality check
went. I.e. I cannot find the relevant functionality to obtain
sameNumber :: Number a - Number b - Maybe (a :~: b)
I guess there should be some TestEquality instance (for Proxy Nat?, is
this possible at all), but I cannot find it. Same applies for Symbols.
Ah yes, I thought that this was supposed to be added to some other library,
but I guess that never happened. It was implemented like this, if you need
it right now.
sameNumber :: (KnownNat a, KnownNat b)
= Proxy a - Proxy b - Maybe (a :~: b)
sameNumber x y
| natVal x == natVal y = Just (unsafeCoerce Refl)
| otherwise= Nothing
This doesn't fit the pattern for the `TestEquality` class (due to the
constraints on the parameters), so perhaps I'll add it back to
GHC.TypeLits.
Yeah, this would be helpful! It does not matter whether the TestEquality
interface is there, as I can define that for my Number data type.
But I don't want to sprinkle my code with unsafeCoerce!
(Btw, these functions should be named: sameNat, sameSymbol.)
Thanks again,
Gabor
-Iavor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Idea for improving communication between devs and potential devs
Hi, I'd like to get involved in developing, but I recognize the learning curve involved. To get started I'd like to improve the Trac wiki documentation. Part of this would include additional documentation of less-documented parts of the compiler and RTS. In addition, I'd like to start some sort of what's new that boils down the GHC Dev mailing list discussion as LWN does for the Linux kernel mailing list. I don't imagine that I can do this all by myself, but I hope this idea would resonate with others looking to get started as well. This is meant to be more frequent and more detailed than what HCAR does for GHC now, though I don't expect anyone can do it weekly. Please let me know what you think about this idea. I'm open to any suggestions for improving it also. Howard B. Golden Northridge, CA, USA ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Idea for improving communication between devs and potential devs
I think a weekly summary like what LWN provides would be very valuable. Perhaps there is an opportunity to piggy-back this on the work of the Haskell Weekly News project ( http://contemplatecode.blogspot.com/search/label/HWN). -Chris ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Idea for improving communication between devs and potential devs
Chris, Thanks for the pointer to HWN. I wasn't aware of it before. I can certainly send things to the author which may be of interest to readers. In addition I like incorporating the updates into the GHC Devs wiki to make it easier to find them that way. We each have our preferred way of keeping up-to-date. Howard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ticket for adding ARM backend to NCG?
yes, but the conclusion was its unclear if it makes sense, also thats orthogonal to whether or not someone decides to do an arm NCG :) On Fri, Jan 3, 2014 at 2:06 PM, Rob Stewart robstewar...@gmail.com wrote: On 3 January 2014 12:37, Simon Peyton-Jones simo...@microsoft.com wrote: * But using LLVM has some disadvantages. c) we play some efficiency tricks (notably tables next to code) that LLVM can't play (yet). I think. In fact, this could well be implemented in the GHC 7.10, as this has been committed in LLVM on 15th September: http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html Implementing tables next to code in the LLVM IR generation may be something to get one's teeth into in time for 7.10 ? Carter: was this discussed further on #haskell-llvm ? -- Rob | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel | Gardas | Sent: 03 January 2014 11:24 | To: Jens Petersen | Cc: ghc-devs@haskell.org | Subject: Re: ticket for adding ARM backend to NCG? | | | Guys, | | I've been tinkering with ARM NCG idea for quite some time now, but | honestly I've been always in doubts if it's the best way for GHC at all. | I've thought that the plan was to kind of move out of NCG to LLVM based | backends and I've though that although this plan may be kind of stuck | now, it's still on the table. | | Yes, I know that GHC is volunteering effort so if someone comes and asks | for an ARM NCG implementation merge it'll be probably done in some time, | but I'm not sure if it's what's the most welcome at the end. | | Just some of my doubts about it... | | I would really appreciate some authoritative word about the topic from | more involved GHC developers... I mean especially about NCG future... | | Thanks! | Karel | | On 01/ 3/14 09:35 AM, Jens Petersen wrote: | On 3 January 2014 03:10, Corey O'Connor coreyocon...@gmail.com | mailto:coreyocon...@gmail.com wrote: | | My interest is just to get involved somehow in the NCG. Starting a | new backend seemed reasonable only because I couldn't break | something that didn't exist. ;-) | | | Well a big +1 from me for armv7 NCG. | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Idea for improving communication between devs and potential devs
On 2014-01-03 at 21:57:18 +0100, Howard B. Golden wrote: In addition, I'd like to start some sort of what's new that boils down the GHC Dev mailing list discussion as LWN does for the Linux kernel mailing list. maybe https://ghc.haskell.org/trac/ghc/blog could be revived by that...? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Tuple predicates in Template Haskell
Hi,
I try to make my way through #7021 [1]. Unfortunately, there is nothing in
the ticket about what should be expected from the code given as example.
I came with an implementation and I would like feedback from you guys. So,
considering this snippet:
--
{-# LANGUAGE ConstraintKinds #-}
type IOable a = (Show a, Read a)
foo :: IOable a = a
foo = undefined
--
This is what I got now when pretty-printing TH.Info after reify foo call:
VarI Tuple.foo (ForallT [PlainTV a_1627398594] [TupleP 2 [AppT (ConT
GHC.Show.Show) (VarT a_1627398594),AppT (ConT GHC.Read.Read) (VarT
a_1627398594)]] (VarT a_1627398594)) Nothing (Fixity 9 InfixL)
Does that sound right to you ?
Thanks for your time
-- Yorick
[1] https://ghc.haskell.org/trac/ghc/ticket/7021
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Idea for improving communication between devs and potential devs
Herbert, A revived blog would be great as well, if the Simons and other devs have time to write it. I certainly don't know enough to write it myself, but I can collate what others are talking about and maybe agreeing about on the mailing list. I think what I can produce would work better as wiki entries, rather than a blog, so it can have both a topical and chronological access path, but I am open to the blog approach as well if others will write content too. Howard - Original Message - From: Herbert Valerio Riedel hvrie...@gmail.com To: Howard B. Golden howard_b_gol...@yahoo.com Cc: ghc-devs@haskell.org ghc-devs@haskell.org Sent: Friday, January 3, 2014 2:24 PM Subject: Re: Idea for improving communication between devs and potential devs On 2014-01-03 at 21:57:18 +0100, Howard B. Golden wrote: In addition, I'd like to start some sort of what's new that boils down the GHC Dev mailing list discussion as LWN does for the Linux kernel mailing list. maybe https://ghc.haskell.org/trac/ghc/blog could be revived by that...? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: packages/base] master: Add functions to compare Nat and Symbol types for equality. (c5c8c4d)
Iavor, this is great! Just out of curiosity, you import TestEquality but never reference it. Is this an oversight, should I nuke it? Cheers, Gabor On 1/4/14, g...@git.haskell.org g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/base On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a/base --- commit c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a Author: Iavor S. Diatchki diatc...@galois.com Date: Fri Jan 3 15:11:34 2014 -0800 Add functions to compare Nat and Symbol types for equality. --- c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a GHC/TypeLits.hs | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs index f3ba70e..129beb3 100644 --- a/GHC/TypeLits.hs +++ b/GHC/TypeLits.hs @@ -26,6 +26,8 @@ module GHC.TypeLits , KnownSymbol, symbolVal , SomeNat(..), SomeSymbol(..) , someNatVal, someSymbolVal + , sameNat, sameSymbol + -- * Functions on type nats , type (=), type (=?), type (+), type (*), type (^), type (-) @@ -40,7 +42,8 @@ import GHC.Read(Read(..)) import GHC.Prim(magicDict) import Data.Maybe(Maybe(..)) import Data.Proxy(Proxy(..)) -import Data.Type.Equality(type (==)) +import Data.Type.Equality(type (==), TestEquality(..), (:~:)(Refl)) +import Unsafe.Coerce(unsafeCoerce) -- | (Kind) This is the kind of type-level natural numbers. data Nat @@ -167,6 +170,23 @@ type family (m :: Nat) ^ (n :: Nat) :: Nat type family (m :: Nat) - (n :: Nat) :: Nat + + +-- | We either get evidence that this function was instantiated with the +-- same type-level numbers, or 'Nothing'. +sameNat :: (KnownNat a, KnownNat b) = + Proxy a - Proxy b - Maybe (a :~: b) +sameNat x y + | natVal x == natVal y = Just (unsafeCoerce Refl) + | otherwise= Nothing + +-- | We either get evidence that this function was instantiated with the +-- same type-level symbols, or 'Nothing'. +sameSymbol :: (KnownSymbol a, KnownSymbol b) = + Proxy a - Proxy b - Maybe (a :~: b) +sameSymbol x y + | symbolVal x == symbolVal y = Just (unsafeCoerce Refl) + | otherwise = Nothing -- PRIVATE: @@ -187,3 +207,4 @@ withSSymbol :: (KnownSymbol a = Proxy a - b) - SSymbol a - Proxy a - b withSSymbol f x y = magicDict (WrapS f) x y + ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Idea for improving communication between devs and potential devs
Great. We're open to ideas, and I think everyone will be happy to help make this work. One possible model worth emulating would be some sort of ghc and related projects analogue of this week In rust. http://cmr.github.io/blog/2013/10/28/this-week-in-rust/ eg summarizing what's been committed that week that may be interesting etc. On Friday, January 3, 2014, Howard B. Golden wrote: Herbert, A revived blog would be great as well, if the Simons and other devs have time to write it. I certainly don't know enough to write it myself, but I can collate what others are talking about and maybe agreeing about on the mailing list. I think what I can produce would work better as wiki entries, rather than a blog, so it can have both a topical and chronological access path, but I am open to the blog approach as well if others will write content too. Howard - Original Message - From: Herbert Valerio Riedel hvrie...@gmail.com javascript:; To: Howard B. Golden howard_b_gol...@yahoo.com javascript:; Cc: ghc-devs@haskell.org javascript:; ghc-devs@haskell.orgjavascript:; Sent: Friday, January 3, 2014 2:24 PM Subject: Re: Idea for improving communication between devs and potential devs On 2014-01-03 at 21:57:18 +0100, Howard B. Golden wrote: In addition, I'd like to start some sort of what's new that boils down the GHC Dev mailing list discussion as LWN does for the Linux kernel mailing list. maybe https://ghc.haskell.org/trac/ghc/blog could be revived by that...? ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: packages/base] master: Add functions to compare Nat and Symbol types for equality. (c5c8c4d)
Hi, oh yes, I was going to add the instance and then I realized it doesn't work. Please feel free to fix. Thanks! -Iavor On Fri, Jan 3, 2014 at 3:25 PM, Gabor Greif ggr...@gmail.com wrote: Iavor, this is great! Just out of curiosity, you import TestEquality but never reference it. Is this an oversight, should I nuke it? Cheers, Gabor On 1/4/14, g...@git.haskell.org g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/base On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a/base --- commit c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a Author: Iavor S. Diatchki diatc...@galois.com Date: Fri Jan 3 15:11:34 2014 -0800 Add functions to compare Nat and Symbol types for equality. --- c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a GHC/TypeLits.hs | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs index f3ba70e..129beb3 100644 --- a/GHC/TypeLits.hs +++ b/GHC/TypeLits.hs @@ -26,6 +26,8 @@ module GHC.TypeLits , KnownSymbol, symbolVal , SomeNat(..), SomeSymbol(..) , someNatVal, someSymbolVal + , sameNat, sameSymbol + -- * Functions on type nats , type (=), type (=?), type (+), type (*), type (^), type (-) @@ -40,7 +42,8 @@ import GHC.Read(Read(..)) import GHC.Prim(magicDict) import Data.Maybe(Maybe(..)) import Data.Proxy(Proxy(..)) -import Data.Type.Equality(type (==)) +import Data.Type.Equality(type (==), TestEquality(..), (:~:)(Refl)) +import Unsafe.Coerce(unsafeCoerce) -- | (Kind) This is the kind of type-level natural numbers. data Nat @@ -167,6 +170,23 @@ type family (m :: Nat) ^ (n :: Nat) :: Nat type family (m :: Nat) - (n :: Nat) :: Nat + + +-- | We either get evidence that this function was instantiated with the +-- same type-level numbers, or 'Nothing'. +sameNat :: (KnownNat a, KnownNat b) = + Proxy a - Proxy b - Maybe (a :~: b) +sameNat x y + | natVal x == natVal y = Just (unsafeCoerce Refl) + | otherwise= Nothing + +-- | We either get evidence that this function was instantiated with the +-- same type-level symbols, or 'Nothing'. +sameSymbol :: (KnownSymbol a, KnownSymbol b) = + Proxy a - Proxy b - Maybe (a :~: b) +sameSymbol x y + | symbolVal x == symbolVal y = Just (unsafeCoerce Refl) + | otherwise = Nothing -- PRIVATE: @@ -187,3 +207,4 @@ withSSymbol :: (KnownSymbol a = Proxy a - b) - SSymbol a - Proxy a - b withSSymbol f x y = magicDict (WrapS f) x y + ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: packages/base] master: Add functions to compare Nat and Symbol types for equality. (c5c8c4d)
On 1/4/14, Iavor Diatchki iavor.diatc...@gmail.com wrote: Hi, oh yes, I was going to add the instance and then I realized it doesn't work. Please feel free to fix. Thanks! Done: http://ghc.haskell.org/trac/ghc/changeset/b62f687e23d90c2ff4536e4e7788e5d9acb2b66c/base Cheers, Gabor -Iavor On Fri, Jan 3, 2014 at 3:25 PM, Gabor Greif ggr...@gmail.com wrote: Iavor, this is great! Just out of curiosity, you import TestEquality but never reference it. Is this an oversight, should I nuke it? Cheers, Gabor On 1/4/14, g...@git.haskell.org g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/base On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a/base --- commit c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a Author: Iavor S. Diatchki diatc...@galois.com Date: Fri Jan 3 15:11:34 2014 -0800 Add functions to compare Nat and Symbol types for equality. --- c5c8c4dfbdc8493bcfaa804751eff2a9a41cc07a GHC/TypeLits.hs | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs index f3ba70e..129beb3 100644 --- a/GHC/TypeLits.hs +++ b/GHC/TypeLits.hs @@ -26,6 +26,8 @@ module GHC.TypeLits , KnownSymbol, symbolVal , SomeNat(..), SomeSymbol(..) , someNatVal, someSymbolVal + , sameNat, sameSymbol + -- * Functions on type nats , type (=), type (=?), type (+), type (*), type (^), type (-) @@ -40,7 +42,8 @@ import GHC.Read(Read(..)) import GHC.Prim(magicDict) import Data.Maybe(Maybe(..)) import Data.Proxy(Proxy(..)) -import Data.Type.Equality(type (==)) +import Data.Type.Equality(type (==), TestEquality(..), (:~:)(Refl)) +import Unsafe.Coerce(unsafeCoerce) -- | (Kind) This is the kind of type-level natural numbers. data Nat @@ -167,6 +170,23 @@ type family (m :: Nat) ^ (n :: Nat) :: Nat type family (m :: Nat) - (n :: Nat) :: Nat + + +-- | We either get evidence that this function was instantiated with the +-- same type-level numbers, or 'Nothing'. +sameNat :: (KnownNat a, KnownNat b) = + Proxy a - Proxy b - Maybe (a :~: b) +sameNat x y + | natVal x == natVal y = Just (unsafeCoerce Refl) + | otherwise= Nothing + +-- | We either get evidence that this function was instantiated with the +-- same type-level symbols, or 'Nothing'. +sameSymbol :: (KnownSymbol a, KnownSymbol b) = + Proxy a - Proxy b - Maybe (a :~: b) +sameSymbol x y + | symbolVal x == symbolVal y = Just (unsafeCoerce Refl) + | otherwise = Nothing -- PRIVATE: @@ -187,3 +207,4 @@ withSSymbol :: (KnownSymbol a = Proxy a - b) - SSymbol a - Proxy a - b withSSymbol f x y = magicDict (WrapS f) x y + ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Changing GHC Error Message Wrapping
hey andrew, your image link isn't working (i'm using gmail) On Fri, Jan 3, 2014 at 11:06 PM, Andrew Gibiansky andrew.gibian...@gmail.com wrote: Hello, I'd like to change how the error messages from GHC get wrapped. I am using the following code: flip gcatch handler $ do runStmt let f (x, y, z, w, e, r, d , ax, b ,c,ex ,g ,h) = (x :: Int) + y + z RunToCompletion runStmt f (1, 2, 3) RunToCompletion return () where handler :: SomeException - Ghc () handler e = liftIO $ putStrLn $ Exception:\n ++ show e The output I am getting looks like this: [image: Inline image 1] I would like the types to not wrap at all, or wrap at some very long length along the lines of 200-300 characters. I have seen the `pprUserLength` and `pprCols` fields in DynFlags, but they don't seem to do anything. What should I do? Thanks! Andrew ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
