I´m wondering about how the search engine and the transactional cache can be used together in new ways. The transactional cache has only access by unique index, there is no freedom to access objects by arbitrary expressións with boolean conditions and field values a la SQL.
In the other side, the search engine has no relevance and is not enough flexible for some needs. Can I inprove the search engine to provide both functionalities?.
I found that it is possible:
more
- To improve the relevance of the search engine results
- Search queries with arbitrary boolean expressions
- Query for haskell objects with certain field values.
- To use the query language to retrieve sets of haskell registers and perform atomic operations with these registers.
2 comments:
Hi, Alberto.
You didn't put your address here.
You are good at Haskell, and I'm just starting out, so ... only one question. You can reply to :
putStrLn ((reverse "72ecnever") ++ "at gmail dot com")
I am writing this kind of function:
some_func = do
got <- getLine
read got
But it won't work, because in that case got ends up as IO String and not String as I expected.
Why? Help?
hi Comrade:
Sorry for the delay. I don´t visit my blog very often !
The haskell type system can be tricky when combined with monads (IO) and polimorphic (read) functions. This example has it all.
For a matter of nemotechnic explanation, be aware that everything that contains a do is a monad, if getLine appears, it is a IO monad, so everything that goes out of the function is IO something. therefore, The last statement of a do must generate this kind of data. the read type is String-> a, that is not good. we need to combine it with return. the type of return is a -> IO a. Combining both return (read got) generate IO a. That is the intended output
some_func = do
got <- getLine
return (read got)
And now enters the polimorphism: This is not enough because some_func does not know what kind of "a" to produce. read is polimorphic and its type (Read a) => String -> a means that it can produce any a that is instance of the Read class.
To inform read and some_func about what to produce can be done implicity, for example if I write:
main1= do
c <- some_func
print (c + 5)
then read assume at compile time that a Int must be returned because the +5 appearx summing up to the result of some_func
alternatively, the type can be stablished explicitly, for example, explicity denotating the type:
some_func :: Int
some_func = do
got <- getLine
return (read got)
other possibility: saying it directly to read:
some func :: Int
some_func = do
got <- getLine
return (read got :: Int)
Best Regards.
Post a Comment