It looks like the quasi quoter syntax has changed to now accept 4 arguments [ link ]. Has anyone used it yet? Thanks. I just want to build something really really simple, and the examples on the web won't work now.
Thanks in advance.
Each piece of the QuasiQuoter is just a function that takes a string (the content of the quasi-quote) and returns an appropriate value in the Q monad. If your quasiquoter doesn't support being used in some of those contexts, just return an error, e.g.:
someQuoter = QuasiQuoter { quoteType = const $ fail "type context unsupported"
, -- etc ...
}
The fail method calls report True, which produces a compiler error. This is pretty much the correct behavior.
Basically the changes are that you can now make quasiquoters for types and declarations (in addition to expressions and patterns).
It should be fine to set the type/declaration fields to error "This quasiquoter doesn't support splicing types/declarations" if you don't want to use them.
Related
Is it possible to instruct GHC compiler to require that a specific value in code has invalid type, without ever using this value?
A contrived example is:
data Box a = Num a => Box a
goodBoxSample :: Box Int
goodBoxSample = Box 1
-- below definition and binding are expected to fail compilation
badBoxSample :: Box String
badBoxSample = Box "foo"
Is there a way to inform the compiler that badBoxSample is expected to fail (e.g. with some pragma, rather than commenting it out as a known bad sample), so that the code compiles only if badBoxSample fails to type-check?
The motivation here is the same as for writing a test (in some other language) with the code that is required to throw exception for the test case to pass.
Not possible. You're basically asking for a way to prove that there's no instance Num String, but Haskell operates under the open-world assumption, which means that someone could always declare such an instance.
Somebody posted a very helpful answer here, but before I managed to accept it was removed... Thank you anyway, and here it is for the reference:
https://hackage.haskell.org/package/generic-lens-2.0.0.0/docs/Data-Generics-Product-Fields.html
In short, the goal of testing failing types can be achieved with doctest, in the way the linked library does it.
Since Name has a Show instance and strings can be used to generate a corresponding Name, I thought about using the following method:
\ name -> [e| mkName $(lift (show name)) |]
This works fine in ghci. But in compiled code, the actual compiled variables look like p_a4hEk, whereas the strings produced by Show look like p_6989586621680030942.
What is happening here? Is there a way to lift a Name into a Template Haskell ExpQ?
Use case: I am writing a TH API that can build complex and efficient Haskell functions based on human-readable user descriptions. I am attaching to the returned function a documentation that explains the purpose and type of each parameter in human readable terms. It would be nice if the documentation could also contain the Name used for that parameter in the code, so that the user can review the spliced code as needed and recognize which parameter is which.
I'm trying to make a Haskell datatype a bit like a python dictionary, a ruby hash or a javascript object, in which a string is linked to a value, like so:
data Entry t = Entry String t
type Dictionary t = [Entry t]
The above code works fine. However, I would like a slightly nicer constructor, so I tried defining it like this:
data Entry t = String ~> t
This failed. I tried this:
data Entry t = [Char] ~> t
Again, it failed. I know that ~ has special meaning in Haskell, and GHCi still permits the operator ~>, but I still tried one other way:
data Entry t = [Char] & t
And yet another failure due to parse error. I find this confusing because, for some inexplicable reason, this works:
data Entry t = String :> t
Does this mean that there are certain rules for what characters may occur in infix type constructors, or is it a cast of misinterpretation. I'm not a newbie in Haskell, and I'm aware that it would be more idiomatic to use the first constructor, but this one's stumping me, and it seems to be an important part of Haskell that I'm missing.
Any operator that starts with a colon : is a type constructor or a data constructor, with the exception of (->). If you want the tilde, you could use :~>, but you're not going to get away with using something that doesn't start with a colon. Source
I have just started learning Haskell using "Learn you a Haskell for Great Good".
I am currently reading "Types and Typeclasses" chapter, so my knowledge is pretty .. non-existent.
I am using Sublime Text 2 with SublimeHaskell package which builds/checks file on every save.
The problem: I'm trying to make function type declaration like this:
funcName :: [Char] -> [Char]
I'm getting this warning:
Warning: Use String
Found:
[Char] -> [Char]
Why not:
String -> String
Build FAILED
Can you explain to me why is it a bad idea to use Char array instead of String or give me a link to an explanation of possible repercussions etc. I've googled and found nothing.
P.S. I'm a C# developer, I understand the difference between char array and strings in c-like languages.
Somewhere in the base library you will find this definition:
type String = [Char]
which says that String and [Char] are exactly the same thing. Which of the two you choose is a documentation choice. I often define type aliases like this:
type Domain = ByteString
type UserName = Text
It's a good idea to use types for documentation.
Also as an important side note, [Char] is not the type for character arrays, but character lists. Since there are also actual array types, the distinction is important!
String is nothing more than a type alias for [Char], so there is no practical between the two - it's simply a matter of readability.
You seem to be running HLint on your code automatically, and treating any HLint warnings as fatal errors. As the HLint author says "Do not blindly apply the output of HLint". String and [Char] are exactly the same, as everyone says, it's a question of which looks nicer. I would tend to use String if I'm operating on contiguous lists of characters I want to treat as a block (most of the time), and explicitly use [Char] when the characters don't make sense combined in a run (far rarer). HLint divides all hints into error (fix) and warning (think), so perhaps it might be best only to build fail on error hints.
If I have a Name in TemplateHaskell and want to find out the value of the variable that it names, provided that the variable is declared as a literal, can this be done?
var = "foo"
-- Can `contentsOf` be defined?
$((contentsOf . mkName $ "var") >>= guard . (== "foo"))
In theory, yes. In practice, no.
Finding out stuff about existing names is done using reify :: Name -> Q Info, and for a definition like that you would get back a VarI value, which includes a Maybe Dec field. This would seem to suggest that you might in some cases be able to get the syntax tree for the declaration of the variable, which would allow you to extract the literal, however current versions of GHC always returns Nothing in this field, so you're out of luck for a pure TH solution.
However, TH does allow arbitrary IO actions to be run, so you could potentially work around this by loading and parsing the module yourself using something like haskell-src-exts, however I suspect that would be more trouble than it's worth.