If the raw SPARQL is rdfs:label "D (programming language)"#en, what would the hsparql syntax be?
I'm the maintainer of the hsparql DSL that you are having trouble with. A `simpleSelectWithLiteral' function has been added as an example:
https://github.com/robstewart57/hsparql/blob/master/tests/DBPedia.hs#L51
Does this solve your problem?
Looking at the DSL definition (line 251) on the HSparql Github page it looks like the following DSL rule applies:
instance TermLike ([Char], [Char]) where
varOrTerm (s, lang') = Term . RDFLiteralTerm $ RDFLiteralLang s lang'
It's been far too long since I wrote any Haskell so I'm not 100% certain what that translates to into a term but I assume it means use a tuple of two strings:
("value", "en")
Related
Given a Haskell expression, I'd like to perform alpha conversion, ie. rename some of the non free variables.
I've started implementing my own function for this, which works on a haskell-src-exts Exp tree, however it turns out to be surprisingly nontrivial, so I can't help wondering - is there an established easy-to-use library solution for this kind of source conversion? Ideally, it should integrate with haskell-src-exts.
This is one of the problems where the "Scrap Your Boilerplate" style generic libraries shine!
The one I'm most familiar with is the uniplate package, but I don't actually have it installed at the moment, so I'll use the (very similar) functionality found in the lens package. The idea here is that it uses Data.Data.Data (which is the best qualified name ever) and related classes to perform generic operations in a polymorphic way.
Here's the simplest possible example:
alphaConvert :: Module -> Module
alphaConvert = template %~ changeName
changeName :: Name -> Name
changeName (Ident n) = Ident $ n ++ "_conv"
changeName n = n
The (%~) operator is from lens and just means to to apply the function changeName to everything selected by the generic traversal template. So what this does is find every alphanumeric identifier and append _conv to it. Running this program on its own source produces this:
module AlphaConv where
import Language.Haskell.Exts
import Control.Lens
import Control.Lens.Plated
import Data.Data.Lens
instance Plated_conv Module_conv
main_conv
= do ParseOk_conv md_conv <- parseFile_conv "AlphaConv.hs"
putStrLn_conv $ prettyPrint_conv md_conv
let md'_conv = alphaConvert_conv md_conv
putStrLn_conv $ prettyPrint_conv md'_conv
alphaConvert_conv :: Module_conv -> Module_conv
alphaConvert_conv = template_conv %~ changeName_conv
changeName_conv :: Name_conv -> Name_conv
changeName_conv (Ident_conv n_conv)
= Ident_conv $ n_conv ++ "_conv"
changeName_conv n_conv = n_conv
Not terribly useful since it doesn't distinguish between identifiers bound locally and those defined in an outside scope (such as being imported), but it demonstrates the basic idea.
lens may seem a bit intimidating (it has a lot more functionality than just this); you may find uniplate or another library more approachable.
The way you'd approach your actual problem would be a multi-part transformation that first selects the subexpressions you want to alpha-convert inside of, then uses a transformation on those to modify the names you want changed.
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.
I have some code that includes a menhir-based parser for a domain specific language (a logic). For the sake of my sanity while debugging, it would be great to be able to type instances of this language (formulas) directly in the toplevel like so:
# f = << P(x,y) & x!=y >>
Is campl4/5 my only option? If yes, I find the documentation rather intimidating. Is there an example/tutorial that is close-enough to my use case and that I could conceivably adapt? (For instance, syntax extensions that introduce new keywords do not seem relevant). Thanks!
If you're willing to call a function to do the parsing, you can use ocamlmktop to include your parser into the top level. Then you can install printers for your types using #install_printer. The sessions might look like this then:
# let x = parse ()
<< type your expression here >>
# x : type = <<formatted version>>
I have used specialed printers, and they definitely help a lot with complicated types. I've never gotten around to using ocamlmktop. I always just load in my code with #load and #use.
This is a lot easier than mastering camlp4/5 (IMHO). But maybe it's a bit too crude.
Yes, you can use camlp4 and it will work reasonably well (including in the toplevel), but no, it's not well-documented, and you will have to cope with that.
For an example that is close to your use-case, see the Lambda calculus quotation example of the Camlp4 wiki.
For the toplevel, it will work easily. You can dynamically load "camlp4o.cmo" then your syntactic extension in the toplevel, or use findlib which handles that: from the toplevel, #use "topfind";;, then #camlp4o;;, then #require "myfoo.syntax";; where myfoo.syntax is the name of the findlib package you've created to deploy your extension.
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.
How do I convert a Double to Data.Text?
In essence, I had the following code:
Data.Text.pack $ show 9.0
That code has some rather obvious silliness. So I dug around in the documentation and came up with this:
toStrict $ toLazyText $ realFloat 9.0
This seems better, but it seems like there should be a more direct method, but I can't find anything with type Double -> Data.Text. Is this the best way? It seems that if I switch to lazy Text I can avoid this, but I'm not quite ready to do that.
Any words of wisdom?
You can use the printf like package text-format.
ClassyPrelude provides a Show typeclass as mentioned in Thomas' previous answer.
See tshow and tlshow. The latter one produces a lazy text.
Note that the default implementation is just T.fromList . Prelude.show.
I recommend reading the Yesod blog on ClassyPrelude for general information about that package. Note that it is not a drop-in replacement for the standard prelude.
The tongue-in-cheek answer:
f :: Double -> Data.Text
f = Data.Text.pack . show
Then you simply use
f 9.0
Can't get much more terse than that, right? Don't be afraid to roll your own utility methods for convenience (though they should probably have more descriptive names than f). If you think it could be generally useful, then contact the maintainer.