mainland / language-c-quote Goto Github PK
View Code? Open in Web Editor NEWLicense: Other
License: Other
syb >= 0.3 && < 0.5
where before it was >= 0.3 && < 0.4
, seems to work for me.
awesome lib, i'm using a wee script that @maxpow4h wrote to auto generate some blas and lapack bindings a bit more sanely than i'd otherwise be able to
Language/C/Parser/Lexer.x:604:17: error:
• Couldn't match type ‘PState’ with ‘()’
arising from a functional dependency between:
constraint ‘MonadState () P’ arising from a use of ‘get’
instance ‘MonadState PState P’
at Language/C/Parser/Monad.hs:167:10-28
• In a stmt of a 'do' block: st <- get
In the expression:
do { beg <- getInput;
sc <- getLexState;
st <- get;
case alexScanUser st beg sc of {
AlexEOF -> return $ L (alexLoc beg beg) Teof
AlexError end
-> lexerError end (text rest)
where
rest :: String
....
AlexSkip end _ -> setInput end >> lexToken
AlexToken end len t -> setInput end >> t beg end } }
In an equation for ‘nextToken’:
nextToken
= do { beg <- getInput;
sc <- getLexState;
st <- get;
.... }
Hi,
Thanks for the great library. In using language-c-quote, I've found it useful to parse C to see what syntax tree is generated to figure out how to generate an appropriate syntax tree myself. However, this is difficult to do, since you don't have default Show instances on your Syntax datatypes.
As a hack, I've commented out the show instances in Pretty.hs and derived Show on the Syntax.hs datatypes. Essentially, I'm advocating decomposing PrettyShow with Show.
I could send a patch, but you might want to refactor things differently, so I wanted to open an issue first.
When creating a block whose only member is a statements (plural) antiquote, the antiquote is not processed. For example:
[cstm|if (!initialized) { $stms:init_stms }|]
The information about the return type of functions in arrays seems to be spread out into very distant parts of AST -- so much so it appears.. not really rationalizable for a bystander armed with a general knowledge of C.
This can be illustrated with two cases -- functions returning "void" and "void *" -- note how the "void" piece is part of the outer DeclSpec
and the "pointer to" piece is buried within Array->Ptr->OldProto
:
(Note: the outer DecDef has been dropped for posterity. The examples were obtained using GHCi with language-c-quote
version 0.11.4
)
[cedecl|void *(*foo[2])();|]
InitGroup (DeclSpec [] [] (Tvoid noLoc) noLoc)
[]
[Init (Id "foo" noLoc)
(Array []
(ArraySize False (Const (IntConst "2" Signed 2 noLoc) noLoc) noLoc)
(Ptr [] (OldProto (Ptr [] (DeclRoot noLoc) noLoc) [] noLoc) noLoc)
noLoc)
Nothing Nothing [] noLoc] noLoc
[cedecl|void (*foo[2])();|]
InitGroup (DeclSpec [] [] (Tvoid noLoc) noLoc)
[]
[Init (Id "foo" noLoc)
(Array []
(ArraySize False (Const (IntConst "2" Signed 2 noLoc) noLoc) noLoc)
(Ptr [] (OldProto (DeclRoot noLoc) [] noLoc) noLoc)
noLoc)
Nothing Nothing [] noLoc] noLoc) noLoc
This is useful when generating OpenCL kernels and you want to indicate the address space of a pointer.
Parsing the following errors with: "expected ';' but got `='"
- (int)compile {
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
}
The follow errors with: "parse error on `CGRect'".
[self.codeText addKeyboardPanningWithActionHandler:^(CGRect keyboardFrameInView) {
/*
*/
}];
I think it is just a missing case.
If I parse a piece of C code consisting of $ty:(something)
, then there're chances that the AST has AntiTypeDecl "something" loc
in it. But I don't see a way to ppr
it. It leads to non-termination because the only base case in the recursive pprDecl
function is `DeclRoot loc'. Though I'm not clear what's the rationale behind it, printing out the antiquotation as-is seems to be a natural treatment. If there are reasons indeed, it'd be better documented, and provide another function that does it. Please correct me if I'm mistaken. Thanks.
It would be really nice to have a way to generate comments from the quasi-quoter. Have you thought much about how this might be implemented? As a first pass, having them at the statement block level would take care of my needs, but I'm sure that they could be useful at other levels of the AST as well :)
I got this while kicking off the latest LTS Haskell build (11.4):
[ 6 of 16] Compiling Language.C.Parser.Parser ( dist/build/Language/C/Parser/Parser.hs, dist/build/Language/C/Parser/Parser.o )
dist/build/Language/C/Parser/Parser.hs:12200:19: error:
Ambiguous occurrence ‘<>’
It could refer to either ‘Data.Monoid.<>’,
imported from ‘Data.Monoid’ at dist/build/Language/C/Parser/Parser.hs:27:1-18
or ‘Text.PrettyPrint.Mainland.<>’,
imported from ‘Text.PrettyPrint.Mainland’ at dist/build/Language/C/Parser/Parser.hs:28:1-32
(and originally defined in ‘Data.Semigroup’)
|
12200 | ppr ident <> if null ps then empty else angles (commasep (map ppr ps))
| ^^
dist/build/Language/C/Parser/Parser.hs:12208:49: error:
Ambiguous occurrence ‘<>’
It could refer to either ‘Data.Monoid.<>’,
imported from ‘Data.Monoid’ at dist/build/Language/C/Parser/Parser.hs:27:1-18
or ‘Text.PrettyPrint.Mainland.<>’,
imported from ‘Text.PrettyPrint.Mainland’ at dist/build/Language/C/Parser/Parser.hs:28:1-32
(and originally defined in ‘Data.Semigroup’)
|
12208 | ppr (TStypeofExp e _) = text "__typeof__" <> parens (ppr e)
| ^^
The language-c-quote
package seems to exist in an old-ish LTS and a nightly snapshot from December:
https://www.stackage.org/package/language-c-quote
Since this package is a really wonderful way to generate C ASTs, it would be nice if it was included in new nightly and LTS snapshots. Was there a reason it was removed? I don't much know how Stackage is managed.
I think it is inconsistent that in $id:x
, x
must be of type String
. To be uniform with the other anti-quotation forms, x
ought to be of type Id
.
Then, in addition, we ought to have $idname:x
, where x
is of type Name
(this is TH's Name
type).
Objective-C's parser seems to be only able to parse 1 property "annotation" instead of a list.
This parsers correctly:
@property (strong) typename RACSignal *verticalPadding;
This does not:
@property (nonatomic, strong, readonly) typename RACSignal *verticalPadding;
AppDelegate.hs:48:52: AppDelegate.hs:52:20:
parse error on `,'
Are generics and type annotations something you are thinking of adding to this package for Obj-C?
For example, it's now legal to do something like NSDictionary<ClassA*,ClassB*>*
in Obj-C to annotate that the NSDictionary is parametrized over ClassA
and ClassB
. From my cursory look at the code it appears this is not supported.
I'm trying to use quasi-quotes to generate OpenMP. But I get a lexer error in some cases. Here's a small test case:
[cstm| #pragma omp sections
{
#pragma omp section
a = 1;
}|]
I get the following error:
lexer error on
a = 1;
}
Could you release the relevant upper bound? Stackage issue commercialhaskell/stackage#615
Not sure if this problem is in language-c-quote itself or mainland-pretty, but no parenthesis get placed around the argument to a negation, which so negate (negate x)
turns into --x
and is incorrect.
{-# LANGUAGE QuasiQuotes #-}
import Language.C
import Language.C.Quote.CUDA
import Text.PrettyPrint.Mainland
neg :: Exp -> Exp
neg x = [cexp| ( - ($exp:x) ) |]
main :: IO ()
main =
print $ ppr $ neg (neg [cexp| 42 |])
ghci> :main
--42
I badly want nested quotations, but still I have no luck using \|\]
from the README. Could you please clarify the status of this feature?
It would be useful if the anti quoters were available for ObjCIfaceDecl
.
Hi Geoff,
I was building Ziria today and found two places where the new comments parser broke existing code.
pchickey/Ziria@e2bb98e
They were easy for me to fix because I was already familiar with the changes to comments. However, I suspect these bugs would be quite tricky otherwise.
src/Codegen/CgOpt.hs:714:39:
src/Codegen/CgOpt.hs:723:30:
parse error on `EOF'
src/Codegen/CgSetupThreads.hs:57:32:
src/Codegen/CgSetupThreads.hs:63:33:
parse error on `$stms:(my_sizes_inits (zip [0..] buf_tys))'
Is there any way around the empty statement restriction? If not, is there a better way to report these errors?
Pat
In order to work around #32 I wrote this:
return [cstm| #pragma omp parallel sections
{
$stm:( [cstm| #pragma omp section
$stm:s1 \|\]
)
} |]
But that code produces the following error:
Exception when trying to run compile-time code:
Language.Haskell.Meta.Syntax.Translate.toExp: not implemented: QuasiQuote "cstm" " #pragma omp section\n $stm:s1 "
Code: Language.Haskell.TH.Quote.quoteExp
cstm
" #pragma omp parallel sections\
\ {\
\ $stm:( [cstm| #pragma omp section\
\ $stm:s1 \\|\\]\
\ )\
\ } "
The build-tools
stanza in .cabal files has been deprecated and should be replaced with build-tool-depends, perhaps guarded by an if-statement?
If you antiquote a positive infinite value, you will get the expression Infinity
(I think it just calls show on the float). There may not be a sensible thing to do here (you can always just define a constant Infinity
yourself). C99 does define INFINITY
in math.h
, which may be slightly better than the current behaviour.
It is likely that a similar issue exists for NaNs.
Hi Geoffrey.
I made a script to install Haskell from scratch on Linux Debian systems. The script seems for now solid.
While installing language-c-quote v.0.3.1.2, cabal hangs at:
[13 of 15] Compiling Language.C.Smart ( Language/C/Smart.hs, dist/build/Language/C/Smart.o )
With a direct "cabal build --verbose=3", the process hangs after the line
"Loading package exception-mtl-0.3.0.2 ... linking ... done.".
The last ghc message was:
'/usr/bin/gcc' '-fno-stack-protector' '-L/home/chrandr/prj/tools/haskell_repository/ghc-7.4.1/usr/lib/ghc-7.4.1/unix-2.5.1.0' '--print-file-name' 'libdl.so'
The script can be found at: https://github.com/chrand/haskell_install
The set of installed packages are the ones brought in by the script (fresh install).
Thanks,
Christian
It doesn't seem possible at all to generate C code referring to macro calls.
Not even through the supposedly almighty dirty escape hatch:
[citems|
struct cap *cap;
$esc:("list_for_each (cap, list, &acl->list)")
printf ("cap: %s\n", cap->name);
|]
yields:
parse error on `$esc:("list_for_each (cap, list, &acl->list)")'
Hi, would it be possible to have an antiquote specifier for the Initializer type? There doesn't seem to be one, and it would be quite useful.
Negated negative constants are not correctly printed.
For example, this:
[cexp|-$int:(-42)|]
is pretty-printed as --42
.
Consider this code fragment:
let values :: [C.Initializer]
values = [[C.cinit|2|]]
def = [C.cedecl|int $id:name[] = {$inits:values};|]
in ...
This leaves an AntiInits node in the resulting syntax tree. The most likely cause is that qqInitializerListE
is defined for arguments of type [C.Initializer]
, but that type does not ever actually appear; rather the syntax tree contains [(Maybe C.Designation, C.Initializer)]
.
Consider the following module:
{-# LANGUAGE QuasiQuotes #-}
module DanglingElse where
import Language.C.Quote.C
import Text.PrettyPrint.Mainland
import Text.PrettyPrint.Mainland.Class
import System.IO
mainProg = [cunit|
$esc:("#include <stdio.h>")
int main() {
int x = 1;
if (x > 1) {
// This comment is needed to trigger the dangling-else problem
if (x > 2) {
printf("a\n");
}
} else {
printf("b\n");
}
}|]
main = do
withFile "dangling.c" WriteMode $ \h -> do
hPutDocLn h $ ppr mainProg
Running main
will create dangling.c
with the following contents:
#include <stdio.h>
int main()
{
int x = 1;
if (x > 1)
// This comment is needed to trigger the dangling-else problem
if (x > 2)
printf("a\n");
else
printf("b\n");
}
As you can see, the braces around the body of the outer if
are missing. As a result, we have a dangling-else clause, which can be attributed to any of the if
s. Compiling the file with clang 4.0.1 yields the following warning:
$ clang -o dangling dangling.c
dangling.c:10:5: warning: add explicit braces to avoid dangling else [-Wdangling-else]
else
^
1 warning generated.
Running the resulting executable produces no output, from which we conclude that the else
clause is interpreted as belonging to the inner if
, contrary to our intention. We believe that it is a bug.
Interestingly, the problem goes away when we remove the C comment line from the quoted C fragment, which results in the braces being present.
As a workaround, we may insert a dummy statement (a ;
) before the comment line, which also makes the problem go away.
Macros in the input should be preserved in the output.
Ideally, they would be evaluated for type names (i.e. the BOOL macro), but that is a problem for later.
Once one gets to generating array/structure initializers, the picture quickly gets ugly, forcing one to get down to the AST level and build an array of helper functions increasing in sophistication.
Having an antiquoter for designated/undesignated initializers for arrays and structures would have helped a lot.
Citing from http://hydra.cryp.to/build/1392350/log/raw:
Language/C/Parser/Lexer.x:508:38:
Not in scope: ‘ord’
Perhaps you meant one of these:
‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
‘ord#’ (imported from GHC.Exts)
Language/C/Parser/Lexer.x:508:46:
Not in scope: ‘ord’
Perhaps you meant one of these:
‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
‘ord#’ (imported from GHC.Exts)
Language/C/Parser/Lexer.x:512:38:
Not in scope: ‘ord’
Perhaps you meant one of these:
‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
‘ord#’ (imported from GHC.Exts)
Language/C/Parser/Lexer.x:512:46:
Not in scope: ‘ord’
Perhaps you meant one of these:
‘or’ (imported from Prelude), ‘odd’ (imported from Prelude),
‘ord#’ (imported from GHC.Exts)
λ> putDocLn (ppr [cexp| $char:('\0') |])
'\NUL'
GCC:
error: unknown escape sequence: '\N' [-Werror]
error: multi-character character constant [-Werror=multichar]
error: overflow in implicit constant conversion [-Werror=overflow]
intPtr = [cty| int * |]
addConst t = [cty| const $ty:t |]
result = addConst intPtr
The result is supposed to be int * const
, but it is const int *
.
UPD.
All I want is equational reasoning, for example (in pseudo-C):
x =
int *
const $x
==const (int *)
when current implementation gives:
const $x
==(const int) *
It would be nice to be able to manipulate #line
directives with language-c-quote. I'm particularly interested in setting source locations for statements.
I can imagine two approaches to implement this:
#line
directives and set SrcLoc
s accordingly. When pretty-printing, if an element of the AST has a Loc
, use the file and line from its starting Pos
to emit a #line
directive. As an optimization, it might be nice to suppress any #line
directive with the same filename as the previous directive, and where the difference in line numbers between the two Loc
s is the same as the number of lines pretty-printed since the last #line
. If you don't want these directives you can rewrite all SrcLoc
s to NoLoc
before pretty-printing.Line
constructor to Stm
, like Pragma
.Which would you prefer?
Hi. The XXX
comment in the following code triggers compiler error:
someGenerator =
let
...
in
[cunit|
$edecls:(cdefs serverRpcReq)
$edecls:(cdefs serverRpcRes)
/* Some comment */
struct $id:srv_name {
/* Input arena buffer */
nk_uint8_t *inp_arena_buf;
nk_size_t inp_arena_buf_sz;
};
/* XXX */
struct $id:ops_name {
$sdecls:(map methodSDecl methods)
};
|]
The error looks like the following:
.../src/Compile/Server2.hs:320:17:
.../src/Compile/Server2.hs:344:13:
parse error on `/* XXX */
I'm using 0.11.7 version. According to the Changelog, later versions also should be affected.
I know, I'm late to the party, but I just noticed that the changes between version 0.9 and 0.10.0 made to Objective-C anti-quotations are broken. Specifically, language-c-inline
has got a binding like this
iface = [cunit|
@interface $id:prefixedClassName : NSObject
$ifdecls:propertyDecls
$ifdecls:updateMethodDecls
$ifdecls:ifaceDecls
@end
|]
Unfortunately, this pretty prints without expanding the anti-quotations; so, I get
@interface Particle : NSObject
$ifdecls:propertyDecls
$ifdecls:updateMethodDecls
$ifdecls:ifaceDecls
@end
From what I can see, it must have been the changes between 1627e25 and fa98219 (which clang really doesn't like).
Here's a simple module illustrating the trouble.
{-# LANGUAGE QuasiQuotes #-}
module Test where
import qualified Language.C.Syntax as CS
import qualified Language.C.Quote.C as CQ
test :: [CS.Definition]
test = [CQ.cunit|
int f() {
// Breaking comment..
int x;
}
|]
Here's my GHC version and attempt at compiling this module.
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.2
$ ghc Test.hs
[1 of 1] Compiling Test ( Test.hs, Test.o )
Test.hs:9:18: Test.hs:12:5:
parse error on `int'
Putting variable declaration before the comment seems to work as intended.
case start...end:
is a GNU extension, but is well-supported by both GCC and Clang.
I would like to try to implement this feature, and I'd appreciate any pointers you might have about what all needs to be updated in order to support it.
Hi,
would it be possible to add support for lambda-expressions from C++11? It is needed for the accelerate-cuda
package in order to work on Windows (AccelerateHS/accelerate#234) or take advatange of the new runtime compilation library (AccelerateHS/accelerate#258).
Currently accelerate-cuda
uses expression statements that are non-portable GNU extension. It can be and needs to be replaced with lambda-expressions. I did a quick hack (mwu-tow/language-c-quote@e670cfd) to pretty printer, so the expression statements are translated to lambda-expressions — and it was confirmed to solve the issues.
Ideally, the lambda-expressions support should be added to language-c-quote
— that includes defining new AST structures, parsing and code pretty printing.
However, I'm not sure how it fits in. Lambdas are C++ feature, they are not part of C language. Should they only work in CUDA extensions mode? Is this an acceptable extension fitting the purpose of this package?
Please, let me know what is your view on this issue and how we should proceed from here.
I can't get C99 complex numbers to work:
[cty| float complex |]
silently ignores the complex
keyword.
[cty| float _Complex |]
results in a parser error:
bad type: float _Complex
However, the parser accepts
[cty| _Complex |]
but that is not a C99 type.
Are complex number types broken or am I missing something?
Currently language-c-quote-0.7.7 requires mtl-2.1.3.1 (current is mtl-2.2.0.1), which breaks e.g. accelerate-cuda installation on ghc 7.8.2.
Travis is going down the tubes, so this repository should probably use GA instead.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.