On the record pattern synonyms patch

[Edward Z. Yang]

Hello Matthew,

I have a question about the record pattern synonyms patch
which you landed in the last month (2a74a64e8329ab9e0c74bec47198cb492d25affb).

In IfaceSyn, you made the following change:

 data IfaceIdDetails
   = IfVanillaId
-  | IfRecSelId IfaceTyCon Bool
+  | IfRecSelId (Either IfaceTyCon IfaceDecl) Bool
   | IfDFunId

I don't understand why IfRecSelIds can now store IfaceDecls.  Why aren't
these declarations stored at the *top level* list of declarations in an
interface file?  If they are, you shouldn't be storing the entire
IfaceDecl structure when serializing to disk.  If they are not, I
am afraid I don't understand this code.

I also noticed that the commit message is quite long, and many of the
comments I see are not replicated anywhere in the source.  Is there any
reason why they should not be written down as proper notes, with
cross-references from the appropriate code?

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Questions on the RTS C API regarding threads and tasks

[Simon Marlow]

On 04/11/2015 19:12, Nicola Gigante wrote:

I’m new on this list, congratulations to everyone for
the great work that you’re doing on GHC!

I apologize if this is not the right list where to ask the following
questions. Please point me to the correct list or IRC channel
otherwise.

I’m part of a small group of people who is going to work
on a project that seems to need low-level handling of haskell
threads.

I’ve started delving into the ghc runtime API to understand
if everything we need is exposed to the world or if we
have to modify the runtime itself (which I would avoid if possible).

I have a few questions about the functions that the runtime
exports to the C world regarding the manipulation of tasks:

- Fundamentally, is there a way for a C function called by a foreign call
   to suspend the haskell thread that called it, to be resumed later
   when appropriate? I see that the runtime has a concept of
   “blocking queue”, but I also see that the functions that work on
   blocking queues are not exported. I can manage a queue of TSOs myself,
   but then I need a way to put in sleep the task indefinitely up to a wake 
signal.
   In other words, can I sleep and awake haskell threads from a C function
   called by a foreign call?


When you call a C function from Haskell, the Haskell thread that called 
it *is* suspended, until the C call returns.  So I'm not sure exactly 
what it is you want to do - maybe you could describe in more detail?


Cheers,
Simon




- I see the “suspendThread” and “resumeThread” functions exist in 
include/rts/Threads.h
   Are these the functions that I need for the point above? My main concern is
   that the comments in the source code for suspendThread say that these
   functions are used in case of a CCall, and put the thread in a specific 
queue,
   so they seems to have more specific role than what the name might suggest.

- Also, I’m unable to find what a StgRegTable is
   (which is taken as argument by suspendThread).


Thank you in advance for your help,

Greetings,
Nicola
___
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: Questions on the RTS C API regarding threads and tasks

[Nicola Gigante]

> Il giorno 12 nov 2015, alle ore 12:24, Simon Marlow  ha 
> scritto:
> 
> When you call a C function from Haskell, the Haskell thread that called it 
> *is* suspended, until the C call returns.  So I'm not sure exactly what it is 
> you want to do - maybe you could describe in more detail?
> 

Yes, the haskell thread is suspended but it will be resumed when the C code 
returns.
If you see the haskell + C code as a single computation, nothing gets suspended,
you just switch environment and language.

I’m sorry for the vagueness in my question. At the time we had a blind review 
of 
a paper pending so I couldn’t give more details because some reviewer could be
a member of mailing lists like this.

Now I can explain at a little bit higher level what I was talking about.
There are a few places in the haskell concurrency libraries where
haskell threads gets suspended until something happens.
MVars suspend on reads, STM transactions block after a retry to wait for
the change of some TVar, and so on…
Each case is internally treated explicitly by the runtime. By looking at the
implementation I see that there is a concept of “Blocking Queue”, and
each TSO can be added to one of these queues. Each TSO also has
a why_blocked flag that tells why it is blocked, with all these cases explicitly
enumerated (e.g. BlockedOnCCall and BlockedOnSTM).

We are implementing some kind of concurrency primitive, which is similar in 
spirit
to the STM but with a number of differences, and we’d need access to
a primitive to block the thread exactly as it happens with the readMVar function
or the retry action of the STM: simply put a thread to sleep until something 
happens.

We are implementing a concurrency primitive, so everything has to be fast and 
low-overhead.
As Edward pointed out, it sounds like premature optimization to a priori exclude
the possibility to implement our primitive on top of MVars. For this reason, 
that
is the way that we are exploring in the last days.

Nevertheless, it does seem strange to us that the GHC runtime doesn’t expose 
some generic way to do something that is needed by so many subsystems.
What do you think about this? Are we missing something?

Thank you for your help,

> Cheers,
> Simon

Greetings,
Nicola___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens

[Alan & Kim Zimmerman]

agree, as we discussed on IRC

On Thu, Nov 12, 2015 at 9:30 PM, GHC  wrote:

> #11018: ApiAnnotations: Add SourceText for unicode tokens
> -+-
> Reporter:  alanz |Owner:  alanz
> Type:  bug   |   Status:  new
> Priority:  normal|Milestone:  8.0.1
>Component:  Compiler  |  Version:  7.10.2
>   Resolution:| Keywords:
>  |  ApiAnnotations
> Operating System:  Unknown/Multiple  | Architecture:
>  |  Unknown/Multiple
>  Type of failure:  None/Unknown  |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:|  Differential Rev(s):
>Wiki Page:|
> -+-
>
> Comment (by mpickering):
>
>  No. Go for it.
>
>  For the purpose of this ticket, I will also add that I think adding a flag
>  `IsUnicodeSyntax` is better than adding `SourceText`.
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Haskell Platform Plans

[Gershom B]

Dear all,

As you know, Mark has passed on the Haskell Platform maintainer hat to me.

I wanted to give a heads-up on current plans to keep folks in the loop.
This message has three sections, first the 7.10.3 release, next the 8.0
release, and finally some general musings on fiddly details and future
plans.

1) 7.10.3

The 7.10.3 release candidates have been out for windows and unix for a bit.
As I understand it there is still work underway on the mac build, but that
will hopefully be coming shortly. The plan is to release a new platform
roughly simultaneously. This platform will work essentially as in the past,
for two reasons. First, because it is the last release in the 7.10 series
and should be seen like the 7.10.3 compiler as just incorporating some
necessary patches rather than any serious changes. Furthermore, the future
plans underway rely on a few patches to cabal which have been merged, but
are not yet in any existing cabal-install release. A few packages have
received minor version bumps, as follows:

PACKAGE   7.10.2-a   latest
---
case-insensitive  1.2.0.4   1.2.0.5
fgl   5.5.2.0   5.5.2.3
GLUT  2.7.0.1   2.7.0.3
GLURaw1.5.0.1   1.5.0.2
HUnit 1.2.5.2   1.3.0.0
OpenGL2.12.0.1  2.13.1.0
OpenGLRaw 2.5.1.0   2.6.0.0
primitive 0.6   0.6.1.0
syb   0.5.1 0.6
scientific0.3.3.8   0.3.4.2
StateVar  1.1.0.0   1.1.0.1

A few packages were held back due to dependency issues (notably zlib) and
additionally, packages shipped with ghc were held back to the versions that
will be shipped with 7.10.3.

2) 8.0

We also plan to ship a new platform concurrently with the ghc 8.0 that
should be released early next year.

That platform will implement some long-discussed and requested changes.
First, the platform already ships with msys on windows. However, it does
not do so in a way that lets you, as with minGHC, install the network
library directly, or for that matter install directly other libraries that
use build-type configure. This is because the msys binaries don't get
placed into the path, by design. The new platform will ship with a newer
cabal, incorporating a patch (pull request #2480) that uses the
extra-prog-path setting for build-type: configure. This should allow
network and other things reliant on build-type: configure to directly cabal
install. The goal for the platform on windows will be that any packages
binding to msys libraries _should_ be cabal installable without hassle. If
you maintain a library that you think would be a good test-case for this,
please drop a line so we can work together towards this goal.

Second, the default platform will be _minimal_. That is to say that it will
_only_ install into the global package database those packages that are
directly shipped with ghc, and not any additional platform packages.

"Blessed" platform packages will however still be shipped as a "default
user cabal.config" file, so in a setting where users want to work
unsandboxed, their versions of platform libs will remain pegged to those
chosen by the platform, should they not choose to alter their settings. In
a sandboxed setting, or in the presence of a local cabal.config generated
by a freeze, those constraints will be disregarded.

Furthermore, it is likely but not certain that the "nix-like cabal" or
"no-reinstall cabal" will be available for the 8.0 release. If this is the
case, users will be able to operate in an unsandboxed environment without
conflicts, as multiple instances of the same version of a package, with
different dependency choices, will be able to live side-by-side.

Third, the platform will ship not only with cabal-install, but also with
the stack tool, so that users can choose either workflow, depending on
their project or preferences. A number of people have adopted the stack
tool, and many beginners have reported success with it as well, so it will
be good to provide that functionality out of the box with every platform
install.

Time and resources permitting we would also like to ship a platform version
_with_ the platform libraries prebuilt and included, as that is also a use
case that some people continue to like. However, this is a secondary
priority, and contingent on us getting our build infrastructure into a good
enough shape to make this not too much extra hassle.

I'm excited about these changes, and confident we can get their in a
timespan that matches the 8.0 release of ghc.

3) Generalities

As I mentioned, it would be good to have a more uniform build
infrastructure. Generally, I have put out some feelers and am working
towards extending the ghc nightly buildbot infrastructure to both cover
more platforms and also cover more tools -- not only ghc, but cabal, the
platform, perhaps haddock, ghcjs, etc. This way we can get an economy of
scale and many of our core tools will be able to all share regular
automated 

Re: Pre-Proposal: Introspective Template Haskell

[Richard Eisenberg]

Yes, that's right. But with a compatibility shim, no longer tied into GHC, that 
could provide stability and/or a simpler interface. This compatibility shim 
would likely be called template-haskell. (I retract the idea of deprecating the 
package. But we could democratize its maintenance rather easily after this 
change.)

Richard

On Nov 12, 2015, at 12:12 PM, Geoffrey Mainland  wrote:

> Hi Richard,
> 
> Please correct me if I misunderstand, but in summary, you propose to
> change Template Haskell so that GHC's internal AST is produced directly,
> instead of the current route where there is an intermediate TH AST?
> 
> Geoff
> 
> On 11/11/2015 11:26 AM, Richard Eisenberg wrote:
>> Hi devs,
>> 
>> There's a bunch of open tickets around Template Haskell. A great many of 
>> them are attempts to make TH more like what's already in GHC. Of course, 
>> when someone improves GHC, then TH also has to be updated. But this doesn't 
>> always happen, leading to several of these tickets.
>> 
>> I believe I have a solution to the problem: just eliminate Template Haskell 
>> and provide direct access to GHC's internal structures. The idea (still very 
>> sketchy; hence pre-proposal) is like this (numbered for easy reference, but 
>> no order is implied):
>> 
>> 1. TH quotes would remain. DsMeta would desugar quotes into Core code that 
>> produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). 
>> (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.)
>> 
>> 2. TH splices would remain, working much as they do now. The expression 
>> inside, say, an expression splice would have type (Q exp) where we can 
>> satisfy the constraint (SpliceExpr exp). There would be instances for 
>> (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as 
>> the non-located variants. Generalizing the type of expressions here allows 
>> users not to worry about un-renaming when roundtripping between quotes and 
>> splices.
>> 
>> 3. Reification would remain, using an Info structure much like we have now. 
>> Would we expose the real GHC TyCons as the result of reification? Or is it 
>> better to give the users HsDecls? This would need to be fleshed out.
>> 
>> 4. Lifting would remain, doing the obvious thing.
>> 
>> 5. The template-haskell package could even remain, as a 
>> backward-compatibility shim. It would declare gobs of pattern synonyms and 
>> type synonyms to wrap the new underlying interface. This re-imagined 
>> template-haskell package would not need to be a boot library, and could be 
>> upgraded separately from GHC. We could even maintain multiple versions of 
>> the library so that TH clients wouldn't have to change their code when GHC 
>> upgrades. Perhaps someday we could think about deprecating, if that's the 
>> way the wind blows.
>> 
>> So, the end result is a completely re-engineered TH, but I believe we could 
>> keep full backward compatibility. (I have not considered Typed TH in any 
>> depth yet. But my hope is that it's not too different from the above.) And, 
>> we're left with a significantly lower maintenance burden, especially if we 
>> eliminate template-haskell someday.
>> 
>> And, tantalizingly, the flexibility in splices might allow us to splice in 
>> *Core* code someday. Perhaps we could also reify Core code. Then clients 
>> could write their own custom, domain-aware optimizations. Like RULES on 
>> steroids. But that's all for the next phase. (Giving due credit, this last 
>> bit is inspired by work David Christiansen is doing in Idris.)
>> 
>> What's wrong with this idea? I feel like *something* has to be more 
>> complicated than I've made it seem!
>> 
>> 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: Pre-Proposal: Introspective Template Haskell

[Geoffrey Mainland]

Hi Richard,

Please correct me if I misunderstand, but in summary, you propose to
change Template Haskell so that GHC's internal AST is produced directly,
instead of the current route where there is an intermediate TH AST?

Geoff

On 11/11/2015 11:26 AM, Richard Eisenberg wrote:
> Hi devs,
>
> There's a bunch of open tickets around Template Haskell. A great many of them 
> are attempts to make TH more like what's already in GHC. Of course, when 
> someone improves GHC, then TH also has to be updated. But this doesn't always 
> happen, leading to several of these tickets.
>
> I believe I have a solution to the problem: just eliminate Template Haskell 
> and provide direct access to GHC's internal structures. The idea (still very 
> sketchy; hence pre-proposal) is like this (numbered for easy reference, but 
> no order is implied):
>
> 1. TH quotes would remain. DsMeta would desugar quotes into Core code that 
> produces HsExprs. For example, [| 1 |] would have type (Q (LHsExpr Name)). 
> (Or perhaps (Q (LHsExpr RdrName)) if that works out better for clients.)
>
> 2. TH splices would remain, working much as they do now. The expression 
> inside, say, an expression splice would have type (Q exp) where we can 
> satisfy the constraint (SpliceExpr exp). There would be instances for 
> (SpliceExpr (LHsExpr Name)) and (SpliceExpr (LHsExpr RdrName)) as well as the 
> non-located variants. Generalizing the type of expressions here allows users 
> not to worry about un-renaming when roundtripping between quotes and splices.
>
> 3. Reification would remain, using an Info structure much like we have now. 
> Would we expose the real GHC TyCons as the result of reification? Or is it 
> better to give the users HsDecls? This would need to be fleshed out.
>
> 4. Lifting would remain, doing the obvious thing.
>
> 5. The template-haskell package could even remain, as a 
> backward-compatibility shim. It would declare gobs of pattern synonyms and 
> type synonyms to wrap the new underlying interface. This re-imagined 
> template-haskell package would not need to be a boot library, and could be 
> upgraded separately from GHC. We could even maintain multiple versions of the 
> library so that TH clients wouldn't have to change their code when GHC 
> upgrades. Perhaps someday we could think about deprecating, if that's the way 
> the wind blows.
>
> So, the end result is a completely re-engineered TH, but I believe we could 
> keep full backward compatibility. (I have not considered Typed TH in any 
> depth yet. But my hope is that it's not too different from the above.) And, 
> we're left with a significantly lower maintenance burden, especially if we 
> eliminate template-haskell someday.
>
> And, tantalizingly, the flexibility in splices might allow us to splice in 
> *Core* code someday. Perhaps we could also reify Core code. Then clients 
> could write their own custom, domain-aware optimizations. Like RULES on 
> steroids. But that's all for the next phase. (Giving due credit, this last 
> bit is inspired by work David Christiansen is doing in Idris.)
>
> What's wrong with this idea? I feel like *something* has to be more 
> complicated than I've made it seem!
>
> 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