#13478: Data.List.NonEmpty.{unfold,unfoldr} differences
-------------------------------------+-------------------------------------
Reporter: Iceland_jack | Owner: (none)
Type: feature | Status: new
request |
Priority: normal | Milestone:
Component: | Version: 8.0.1
libraries/base |
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Is there a difference between
[https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List-
NonEmpty.html#v:unfoldr Data.List.NonEmpty.unfoldr] and
[https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List-
NonEmpty.html#v:unfold Data.List.NonEmpty.unfold]?
If there is a difference it would be nice to have that clarified in the
docs
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13478>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8025: -fno-code and Template Haskell are incompatible
-------------------------------------+-------------------------------------
Reporter: mojojojo | Owner: (none)
Type: bug | Status: patch
Priority: normal | Milestone:
Component: Compiler (Type | Version: 7.6.3
checker) |
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: x86
Type of failure: Incorrect | Test Case:
warning at compile-time |
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Changes (by bgamari):
* status: new => patch
Old description:
> Building the included project with
> {{{
> cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno-
> code"
> }}}
> results in the following typechecker error:
> {{{
> ByteCodeLink.lookupCE
> During interactive linking, GHCi couldn't find the following symbol:
> supabugzm0zi1zi0_A_makeLenseszq_closure
> This may be due to you not asking GHCi to load extra object files,
> archives or DLLs needed by your current session. Restart GHCi,
> specifying
> the missing library using the -L/path/to/object/dir and -lmissinglibname
> flags, or simply by naming the relevant files on the GHCi command line.
> Alternatively, this link failure might indicate a bug in GHCi.
> If you suspect the latter, please send a bug report to:
> glasgow-haskell-bugs(a)haskell.org
> }}}
New description:
Building the included project with
{{{
cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno-
code"
}}}
results in the following typechecker error:
{{{
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
supabugzm0zi1zi0_A_makeLenseszq_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs(a)haskell.org
}}}
The problem here is that GHC goes looking for the code of modules needed
for TemplateHaskell splices, which was not produced due to `-fno-code`.
--
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8025: "During interactive linking, GHCi couldn't find the following symbol"
typechecker error with TemplateHaskell involved
-------------------------------------+-------------------------------------
Reporter: mojojojo | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 7.6.3
checker) |
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: x86
Type of failure: Incorrect | Test Case:
warning at compile-time |
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by bgamari):
Duog, your approach seems like a very interesting compromise that I had
not considered. Great work!
There is the question of which `HscTarget` we want to use here. Arguably
`HscInterpreted` is more appropriate as it is faster to generate, faster
to link, and doesn't unexpected leave object files lying around. However,
it unfortunately lacks support for unboxed tuples and sums, which may
break some (I suspect quite small) fraction of programs. It would be
interesting to characterize the difference.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#11425: The GHC API doesn't provide a good hscTarget option for tooling
-------------------------------------+-------------------------------------
Reporter: bgamari | Owner:
Type: feature | Status: new
request |
Priority: high | Milestone: 8.2.1
Component: GHC API | Version: 7.10.3
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: Other
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Tools like ghc-mod typically just want `TypecheckedModule`s. Sadly, the
GHC API currently doesn't provide a good way to get at these in all cases
(see this [https://github.com/DanielG/ghc-mod/issues/205|ghc-mod ticket]).
Each of the options we offer are cursed with their own limitations
(largely quoting from the ghc-mod ticket),
== HscNothing ==
At first glance this looks like what you would want. But...
* Pros
* Doesn't generate code of any sort and is therefore rather lightweight
* Cons
* It lacks support for Template Haskell
* Has trouble with `foreign export`s
* [https://github.com/DanielG/ghc-mod/pull/145|Fails} to issue pattern
match checker warnings
== HscInterpreted ==
Okay, so `HscNothing` doesn't work. Maybe `HscInterpreted` is better?
* Pros
* Supports Template Haskell
* Cons
* Can't deal with unboxed tuples (#1257)
* Slower as we need to produce unnecessary bytecode
* Large memory footprint
* Also can't deal with `foreign export`s
== HscAsm ==
* Pros
* Supports all compilable code
* Cons
* Slow
* Produces `.o` files
This is quite unfortunate. It seems like we need something in between
`HscNothing` and `HscInterpreted` which is willing to use the interpreter
to evaluate Template Haskell splices when necessary, but doesn't produce
bytecode. Unfortunately it's unclear what to do about `foreign export`
(but arguably most tools would be fine with some approximate
representation).
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11425>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8025: "During interactive linking, GHCi couldn't find the following symbol"
typechecker error with TemplateHaskell involved
-------------------------------------+-------------------------------------
Reporter: mojojojo | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 7.6.3
checker) |
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture: x86
Type of failure: Incorrect | Test Case:
warning at compile-time |
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by bgamari):
Hi Duog, thanks for your work on this and sorry for the delayed response;
I unfortunately missed the notification for this. It would be great if you
could put this up on Phabricator. See [wiki:Phabricator] to get started
and don't hesitate to reach out to me via email or IRC if you need help.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13521: Remove comments about API annotations
-------------------------------------+-------------------------------------
Reporter: mpickering | Owner: (none)
Type: task | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
ApiAnnotations |
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
There are lots of comments scattered around the code which look like
{{{
-- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen',
-- 'ApiAnnotation.AnnClose',
-- 'ApiAnnotation.AnnComma',
-- 'ApiAnnotation.AnnType'
-- For details on above see note [Api annotations] in
ApiAnnotation
}}}
these are meant to tell you which annotations are associated with each
syntax element.
They were added in an heroic effort by alanz but are very hard to keep up
to date and verify the correctness of.
It would be much better if we had a programatic description of which
annotations could be attached to which syntax elements and thankfully one
already exists in `ghc-exactprint`. This library isn't in the source tree
but I don't think this really matters, users can just depend on it if they
want to use them.
I think we should remove all these comments to clean up the source a bit
and point users to `ghc-exactprint` from the `ApiAnnotations` page.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13521>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13470: Pattern synonyms bind variables out of scope
-------------------------------------+-------------------------------------
Reporter: Iceland_jack | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.1
Keywords: | Operating System: Unknown/Multiple
PatternSynonyms |
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Wasn't sure what to call this ticket:
{{{#!hs
{-# Language PatternSynonyms #-}
pattern XInstrProxy :: (Bool -> Bool) -> a
pattern XInstrProxy not <- _
}}}
This works fine, is it intended? It came as some surprise to me when I was
renaming type variables only to find it still working even though I hadn't
changed the variable in the `ViewPattern`
{{{#!hs
import Data.Tagged
pattern XInstrProxy proxy <- ((\(Proxy::Proxy descr) -> Proxy::Proxy
(XInstr descr)) -> ty)
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13470>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#13519: hWaitForInput does not work on linux.
-------------------------------------+-------------------------------------
Reporter: | Owner: (none)
junji.hashimoto |
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 8.0.2
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
hWaitForInput does not work on linux.
When hWaitForInput has non-zero waiting time, it always fails.
The code is following ghci-code.
This is because inputReady.c
(https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/cbits/inputReady.c#L…)
does not allow 'msecs != 0'.
{{{
$ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m + System.IO
Prelude System.IO> f <-openFile "stack.yaml" ReadMode
Prelude System.IO> hWaitForInput f 10
fdReady: msecs != 0, this shouldn't happenAborted (core dumped)
}}}
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13519>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
