#4372: Extending quasiquotation support
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Template Haskell | Version: 6.12.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by gershomb):
At this point I consider this a "nice idea" but I'm not sure how to modify
the parser to handle it within the many grammatical constraints we already
have. The somewhat clunky syntax that was pointed out by Simon upthread is
actually adequate for this. This, for example is the style adopted by
Manuel's language-c-inline:
{{{
nslog msg = $(objc ['msg :> ''String] (void [cexp| NSLog(@"Here is a
message from Haskell: %@", msg) |]))
}}}
Here, we use the quasiquoter to capture the expression, and then embed
that quasiquoted expression itself within a TH block, in order to pass in
additional information during codegen.
If a lighter-weight syntax was possible, I'd remain all for it. But, I
honestly can't think how to provide it given the constraints we have -- my
patch at the time didn't really solve the problem, and I haven't had any
better ideas since :-)
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4372#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4372: Extending quasiquotation support
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Template Haskell | Version: 6.12.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by simonpj):
I'm not against this if someone wants to
* Write a wiki page explaining the feature
* Drive a discussion to refine any corners of the design; it's mainly a
syntax question I think.
* Implement a patch on Phabricator; including user manual documentation
and some tests.
> Another problem is that I suppose that the 4 quoters t, p, e, d are
implemented in the layer of syntax
I'm afraid I did not understand this part of your comment. Maybe it's a
separate issue?
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4372#comment:18>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7854: Constrained method type accepted in Haskell 98 mode
-------------------------------------+-------------------------------------
Reporter: refold | Owner: thomie
Type: bug | Status: new
Priority: normal | Milestone: 7.12.1
Component: Compiler (Type | Version: 7.6.3
checker) | Keywords: newcomer
Resolution: | Architecture:
Operating System: Unknown/Multiple | Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by thomie):
* owner: => thomie
* component: Compiler => Compiler (Type checker)
* milestone: => 7.12.1
Comment:
More bugs. GHC only rejects the following program when
`-XConstrainedClassMethods` is turned on. It should however always reject
it, because `op` doesn't mention any type variables of `Foo`.
{{{#!hs
module ShouldFail where
class Foo a where
op :: Eq a => Int
}}}
I'm working on this.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#4861: Documentation for base does not include special items
-------------------------------------+-------------------------------------
Reporter: NeilMitchell | Owner: ekmett
Type: bug | Status: upstream
Priority: low | Milestone: ⊥
Component: Core Libraries | Version: 7.0.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Documentation | Unknown/Multiple
bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Changes (by ekmett):
* milestone: 7.12.1 => ⊥
Comment:
Deferring to _|_ as there doesn't appear to be any great desire on the
part of the `haddock` folks to change this behavior.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4861#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#8189: Default to infinite stack size?
------------------------------------+-------------------------------------
Reporter: nh2 | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.6.3
Keywords: | Operating System: Unknown/Multiple
Architecture: Unknown/Multiple | Type of failure: Runtime crash
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
------------------------------------+-------------------------------------
http://www.haskell.org/pipermail/haskell-cafe/2013-August/108570.html
It looks like any code of the form
{{{
... = do
x1 <- m1
x2 <- m2
[do something with x1 and m2]
}}}
will stack overflow when used with a strict monad (like IO) and
sufficiently large data to deal with (a 1m element list is enough to
exceed the default 8MB stack size limit).
Other examples include:
{{{
sequence (m:ms) = do x <- m
xs <- sequence ms
return (x:xs)
}}}
and
{{{
liftM2, liftM3, ...
}}}
By slightly modifying your program to do the same thing via heap
allocation (e.g. using a difference list in sequence), a stack-overflow
rejected program turns into a valid program.
This means that valid and idiomatic code like
{{{
xs <- replicateM n someIOAction
xs <- mapM someIOAction [1..n]
}}}
will eventually crash, which has an impact on practically all Haskell
software and libraries out there.
For examples, see
https://github.com/ndmitchell/shake/blob/e0e0a43/Development/Shake/Database…https://github.com/haskell-suite/haskell-src-exts/issues/27
as well as the mapM usages in cabal, haddock, any database binding that
allows querying a lists of results, etc.
While some argue that ''"you shouldn't use lists of that size"'',
''"allocating a 150 MB list is wrong"'' or that they ''"carefully avoid
any use of sequence/mapM due to the problem"'' pointed out above, I think
that collecting a million results of a strict monadic action into a linked
list using standard functions like mapM is a common pattern and valid use
case. The stack based evaluation that GHC performs is an optimization and
should be transparent to the user; it should not re-define some data to
live in a fixed-size memory region, and it should work just as well as it
does in GHCi.
It seems that a default infinite stack size would mitigate this.
A drawback might be that the stack space overflows we get so far to
quickly spot a "wrong" program would not indicate certain errors any more.
I currently doubt the usefulness of this debugging method, since it does
not work reliably in the presence of optimization, doing the same thing
via heap allocation makes the programs "correct", and it rejects valid
programs if the input data is large enough.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8189>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7634: MD5 collision could lead to SafeHaskell violation
-------------------------------------+-------------------------------------
Reporter: shachaf | Owner: ekmett
Type: bug | Status: new
Priority: normal | Milestone: ⊥
Component: Core Libraries | Version: 7.6.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Other | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by ekmett):
Pretty much.
There are also dozens if not hundreds of SHA-256 implementations out there
in C we could take in more or less unmodified.
Heck, I've even written one before, back in my crypto days.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7634#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7634: MD5 collision could lead to SafeHaskell violation
-------------------------------------+-------------------------------------
Reporter: shachaf | Owner: ekmett
Type: bug | Status: new
Priority: normal | Milestone: ⊥
Component: Core Libraries | Version: 7.6.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Other | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by bananu7):
A quick investigation shows that there are two parts of the problem:
* `Fingerprint` is made of two `Word64`s; would need to change to four,
and all the functions that manipulate on it to take four parts into
account; that's an easy part
* MD5 implementation used internally for hashing is written in C. I
suppose the SHA-256 implementation that's necessary for the patch
''could'' be taken from `cryptohash` library, which seems pretty mature
already. It would need to be integrated as a C source similarly to MD5;
It's probably not feasible to drag the whole library as a GHC dependency;
maybe I'm wrong here.
Then the functions that have to be altered are `fingerprintData` and
`fingerprintString`, the latter needing just to take the larger size of
the fingerprint into the account, and the former actually being changed to
use the SHA-256 context and hashing function.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7634#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
