Re: Removing -fext-core

2014-04-30 Thread Johan Tibell
+1
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Removing -fext-core

2014-04-30 Thread Austin Seipp
For people keeping score, I created a branch with this already done
the other day:

https://github.com/ghc/ghc/tree/wip/kill-extcore

Again, unless someone speaks up *real* soon, I'm probably going to get
rid of it before the end of the week - so your timeframe is something
like 72 hours to make a peep before it goes away

On Mon, Apr 28, 2014 at 4:09 AM, Simon Peyton Jones
 wrote:
> In principle I think it's a pity to lose External Core.  It provides an 
> interface to GHC that is based on the simplest possibly connector (a text 
> file), and allows GHC's front end or back end to be used by other systems 
> written in different languages.
>
> However, as you say, it has received no love for many years. I have 
> repeatedly sought someone to support and maintain External Core, but no one 
> has stepped forward.  That doesn't mean that no one is using it!  But the 
> absence of bug reports, given how much it has bit-rotted, is a strong 
> indicator that no one is.
>
> So I'd like hear from our users, but I won't stand in the way of removing it.
>
> Simon
>
>
> | -Original Message-
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Austin Seipp
> | Sent: 27 April 2014 14:14
> | To: ghc-d...@haskell.org; glasgow-haskell-users@haskell.org
> | Subject: Removing -fext-core
> |
> | Hello all,
> |
> | Recently I was wondering something: is there any reason to keep -fext-
> | core around? In particular, it's been broken for a while at this point,
> | see GHC bug #5630[1]
> |
> | As far as I'm aware there really aren't any users of it still around
> | these days, at least none working with a modern GHC. And it seems like
> | if people were to need access to Core, they could use a plugin or some
> | such to get direct access to what they want.
> |
> | Simon mentioned removing ExtCore in face of replacing it with IfaceSyn
> | in the compiler. I'm not entirely sure how much work that would be to
> | bring it all up to scratch if people needed it, but maybe it's worth
> | thinking about.
> |
> | One other issue is a notion of semantics which is present in External
> | Core, but we also now have a documented semantics for GHC's core
> | language as well (which has evolved quite a bit), so I don't know how
> | much that matters.
> |
> | So long story short: I don't think anyone is using it, maintaining it,
> | and it seems subsumed by more recent events.
> |
> | Therefore, if nobody objects, I'd vote to remove -fext-core from GHC,
> | unless someone is willing to step up and really maintain it. If you're
> | using it, you should probably speak up soon I'd imagine...
> |
> | [1] https://ghc.haskell.org/trac/ghc/ticket/5630
> |
> | --
> | Regards,
> |
> | Austin Seipp, Haskell Consultant
> | Well-Typed LLP, http://www.well-typed.com/
> | ___
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users@haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: how to compile non-dynamic ghc-7.8.2 ?

2014-04-30 Thread harry
John Lato-2 wrote
> I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled

Are you able to use template haskell (and qusiquoting) with this? Don't they
need dynamic libs?



--
View this message in context: 
http://haskell.1045720.n5.nabble.com/how-to-compile-non-dynamic-ghc-7-8-2-tp5748418p5748865.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at 
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: [core libraries] Re: Tightening up on inferred type signatures

2014-04-30 Thread Edward Kmett
Er.. my mistake. Control.Applicative.

That is what it is we don't re-export that is used in Traversal. =)


On Wed, Apr 30, 2014 at 2:47 AM, Edward Kmett  wrote:

> Not sure.
>
> An even simpler case is something like exporting a Traversal but not
> exporting Data.Traversable, which appears in the expansion, etc.
>
> These sorts of things happen in code using lens. Older versions of lens
> didn't export all of the types needed to write out the type signature long
> hand without extra imports, just to avoid cluttering the namespace.
>
> -Edward
>
>
> On Wed, Apr 30, 2014 at 2:10 AM, Ganesh Sittampalam wrote:
>
>> On 23/04/2014 20:04, dm-list-haskell-librar...@scs.stanford.edu wrote:
>> > Edward Kmett  writes:
>> >
>> >> You can wind up in perfectly legitimate situations where the name for
>> the
>> >> type you are working with isn't in scope, but where you can write a
>> >> combinator that would infer to have that type. I'd hate to lose that.
>> >>
>> >> It is admittedly of marginal utility at first glance, but there are
>> some
>> >> tricks that actually need it, and it can also arise if a type synonym
>> >> expands to a type that isn't exported or brought into scope, so trying
>> to
>> >> push this line of reasoning too far I is possibly not too productive.
>> >
>> > Good point.  In particular, it's not weird at all want to export type
>> > synonyms on their own, particularly where ghost type parameters are used
>> > to select between only a few cases.  Consider something like this
>> > (inspired by postgresql-orm):
>>
>> Is there an abstraction being protected by only exporting the type
>> synonym in cases like this?
>>
>> Cheers,
>>
>> Ganesh
>>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users