In Haskell, why do you not use 'in' with 'let' inside of a do-block, but you must otherwise?
For example, in the somewhat contrived examples below:
afunc :: Int -> Int
afunc a =
let x = 9 in
a * x
amfunc :: IO Int -> IO Int
amfunc a = do
let x = 9
a' <- a
return (a' * x)
It's an easy enough rule to remember, but I just don't understand the reason for it.
You are providing expressions to define both afunc and amfunc. Let-expressions and do-blocks are both expressions. However, while a let-expression introduces a new binding that scopes around the expression given after the 'in' keyword, a do-block isn't made of expressions: it is a sequence of statements. There are three forms of statements in a do-block:
a computation whose result is bound to some variable x, as in
x <- getChar
a computation whose result is ignored, as in
putStrLn "hello"
A let-statement, as in
let x = 3 + 5
A let-statement introduces a new binding, just as let-expressions do. The scope of this new binding extends over all the remaining statements in the do-block.
In short, what comes after the 'in' in a let-expression is an expression, whereas what comes after a let expression is a sequence of statements. I can of course express a computation of a particular statement using a let-expression, but then the scope of the binding would not extend beyond that statement to statements that follow. Consider:
do putStrLn "hello"
let x = 3 + 5 in putStrLn "eight"
putStrLn (show x)
The above code causes the following error message in GHC:
Not in scope: `x'
whereas
do putStrLn "hello"
let x = 3 + 5
putStrLn "eight"
putStrLn (show x)
works fine.
You can indeed use let .. in in do-notation. In fact, according to the Haskell Report, the following
do{let decls; stmts}
desugars into
let decls in do {stmts}
I imagine that it is useful because you might otherwise have to have some deep indentation or delimiting of the "in"-block, going from your in .. to the very end of the do-block.
The short answer is that Haskell do blocks are funny. Haskell is an expression-based language—except in do blocks, because the point of do blocks is to provide for a "statement" syntax of sorts. Most "statements" are just expressions of type Monad m => m a, but there are two syntaxes that don't correspond to anything else in the language:
Binding the result of an action with <-: x <- action is a "statement" but not an expression. This syntax requires x :: a and action :: Monad m => m a.
The in-less variant of let, which is like an assignment statement (but for pure code on the right hand side). In let x = expr, it must be the case that x :: a and expr :: a.
Note that just like uses of <- can be desugared (in that case, into >>= and lambda), the in-less let can always be desugared into the regular let ... in ...:
do { let x = blah; ... }
=> let x = blah in do { ... }
Related
I followed this tutorial to implement a quasi quoted DSL, and I now want to support non-linear patterns in a quoted pattern. That will allow a repeated binder in a pattern to assert the equality of the matched data. For example, one can then write eval [expr| $a + $a|] = 2 * eval a. I modified antiExprPat as follows:
antiExpPat (MetaExp s) =
Just (do b <- lookupValueName s
let n = mkName s
p0 = VarP n
p1 <- (viewP [|(== $(varE n))|] [p|True|])
let res = case b of Nothing -> p0
_ -> p1
return res)
antiExpPat _ = Nothing
The idea is to use lookupValueName to check if the anti-quoted name s is in scope. If not, then just create a binder with the same name. Otherwise, create a view pattern (== s) -> True that asserts the matched data equals to the data already bound to s. Essentially, I want to convert the quoted pattern [expr| $a + $a |] to the Haskell pattern (Add a ((== a) -> True)).
But that didn't work. The resulting Haskell pattern is Add a a, which means lookupValueName never thinks a is in scope. Am I misunderstanding how lookupValueName works? Or is there a better way to implement non linear patterns here?
The full code is here if you want to play with it. In short, I'm making a quasi quoter to match on Java source.
Update 1:
As #chi pointed out, lookupValueName only checks for the splice's context, whereas I need to check for the splice's content. Any idea how to proceed with that?
Update 2:
So I bit the bullet and threaded the set of in-scope names with a state monad, and traversed the parse tree with transformM which replaces every in-scope meta-variable x with ((== x) -> True):
dataToPatQ (const Nothing `extQ` ...) (evalState (rename s) DS.empty)
...
rename :: Language.Java.Syntax.Stmt -> State (DS.Set String) Language.Java.Syntax.Stmt
rename p = transformM rnvar p
where rnvar (MetaStmt n) = do s <- get
let res = if DS.member n s
then (SAssertEq n)
else (MetaStmt n)
put (DS.insert n s)
return res
rnvar x = return x
It got the right result on the inputs I have, but I have no idea if it is correct, especially given transformM traverses the tree bottom-up so inner meta-variables may be added to the set first.
When I try to pattern-match a GADT in an proc syntax (with Netwire and Vinyl):
sceneRoot = proc inputs -> do
let (Identity camera :& Identity children) = inputs
returnA -< (<*>) (map (rGet draw) children) . pure
I get the (rather odd) compiler error, from ghc-7.6.3
My brain just exploded
I can't handle pattern bindings for existential or GADT data constructors.
Instead, use a case-expression, or do-notation, to unpack the constructor.
In the pattern: Identity cam :& Identity childs
I get a similar error when I put the pattern in the proc (...) pattern. Why is this? Is it unsound, or just unimplemented?
Consider the GADT
data S a where
S :: Show a => S a
and the execution of the code
foo :: S a -> a -> String
foo s x = case s of
S -> show x
In a dictionary-based Haskell implementation, one would expect that the value s is carrying a class dictionary, and that the case extracts the show function from said dictionary so that show x can be performed.
If we execute
foo undefined (\x::Int -> 4::Int)
we get an exception. Operationally, this is expected, because we can not access the dictionary.
More in general, case (undefined :: T) of K -> ... is going to produce an error because it forces the evaluation of undefined (provided that T is not a newtype).
Consider now the code (let's pretend that this compiles)
bar :: S a -> a -> String
bar s x = let S = s in show x
and the execution of
bar undefined (\x::Int -> 4::Int)
What should this do? One might argue that it should generate the same exception as with foo. If this were the case, referential transparency would imply that
let S = undefined :: S (Int->Int) in show (\x::Int -> 4::Int)
fails as well with the same exception. This would mean that the let is evaluating the undefined expression, very unlike e.g.
let [] = undefined :: [Int] in 5
which evaluates to 5.
Indeed, the patterns in a let are lazy: they do not force the evaluation of the expression, unlike case. This is why e.g.
let (x,y) = undefined :: (Int,Char) in 5
successfully evaluates to 5.
One might want to make let S = e in e' evaluate e if a show is needed in e', but it feels rather weird. Also, when evaluating let S = e1 ; S = e2 in show ... it would be unclear whether to evaluate e1, e2, or both.
GHC at the moment chooses to forbid all these cases with a simple rule: no lazy patterns when eliminating a GADT.
As a beginner at Haskell I've found it difficult to visually recognize some examples of pattern matching.
It seems that in let bindings sometimes the pattern matching occurs on the lhs when a function is called and the values are bound to variables in the equation on the rhs like in the following code example:
let boot x y z = x * y + z in boot 3 4 2
Sometimes however a function will be run in the rhs and the return values of that function will be bound to values in the lhs of the equation as in the definition of the State Monad from "Learn you a Haskell":
instance Monad (State s) where
return x = State $ \s -> (x,s)
(State h) >>= f = State $ \s -> let (a, newState) = h s
(State g) = f a
in g newState
where the function h is run with the lambda argument s and the return values are bound to (a, newState).
To a new Haskell programmer, this is slightly confusing. I could imagine a scenario where you might have:
let f a b = g c d in ...
where the function g would return a function and two arguments as it's return values. In this case would the "f a b" need to be wrapped in parenthesis for the pattern match to occur? I'm trying to find a definitive explanation of how the pattern matching occurs.
I have read most of "Learn You A Haskell For Great Good", as well as snippets from "Real World Haskell" and "A Gentle Introduction to Haskell" and I have not found a clear explanation of how to determine if the pattern matching should be occuring on arguments to a function or on the return values of a function. Any help in clearing this up would be appreciated.
I believe you're stumbling over the difference between function and pattern bindings.
In short, if you have something like "variable pat1 pat2 ... =" (where pat1 pat2 ... are one or more patterns), it's a function binding; otherwise it's a pattern binding. In the most simple case, x y z = ..., a function binding is just syntactic sugar for a lambda: x = \y z -> ....
If it starts with a (, it's not a variable, so the whole thing must be a pattern binding. But even without parens State x is still a pattern binding because State is not a variable (it starts with an uppercase letter so it must be a constructor).
When I use JS, I have two options to handle a function.
var a = function() {};
var b = a; // b is the function a itself.
var c = a(); // c is result of the evaluation of function a.
AFAIK, Haskell is lazy by default, so I always get b by default. But if I want to get c, how can I do?
Update
I think I should put a word explicitly.
I was doing something like this in ghci.
let a = getLine
a
I wanted to let a result of getLine into a.
Update2
I note this code for later reference for people like me.
I could correct translation to Haskell with #Ankur's help.
With above code example is not a good one because function a doesn't return anything.
If I change it like this;
var a = function(x,y) { return x * y; };
var b = a; // b is the function a itself.
var c = a(); // c is result of the evaluation of function a.
Translation into Haskell will become like this.
let a = \ x y -> x* y // Anonymous lambda function.
let b = a
let c = a 100 200
Your JS code would translate to Haskell as:
Prelude> let a = (\() -> ())
Prelude> let b = a
Prelude> let c = a()
Your JS function was taking Nothing (which you can model as () type) and returning nothing i.e again ()
getLine is a value of type IO String so if you say let a = getLine, a becomes value of type IO String. What you want is extract String from this IO String, which can be done as:
a <- getLine
Note that the parallel to Javascript isn't quite correct -- for instance, assuming a returns a number, b + b makes sense in Haskell but not in your example Javascript. In principle functions in Haskell are functions of exactly one argument -- what appears to be a function of two arguments is a function of one argument, which returns a function of one argument, which returns a value. b in Haskell would not be an unevaluated "zero-argument function", but an unevaluated value.
To introduce strictness you can use seq, which takes two arguments, the first of which is strictly evaluated and the second of which is returned. Read more.
Here is an example from that page where seq is used to force immediate evaluation of z':
foldl' :: (a -> b -> a) -> a -> [b] -> a
foldl' _ z [] = z
foldl' f z (x:xs) = let z' = f z x in z' `seq` foldl' f z' xs
Note the way z' is used again later as the second argument to foldl', since seq just discards the value of its first argument.
Haskell is non-strict, not lazy.
Many expressions will be evaluated strictly, see here, so you can often force strictness simply with the structure of your code.
In Haskell, if c has a type which matches the return type - the value - of a() then that is what will be assigned to it (never the function itself).
Haskell may put off the calculation until your code actually needs the value of c but in most cases you should not care.
Why do you want to force the evaluation early? Usually, the only reason to do this in Haskell is performance. In less pure languages, you might be depending on a side effect but that will not be the case in Haskell - unless you're working with, say, the IO monad and that gives you all you need to force sequential evaluation.
UPDATE Ah, so you are working with IO.
Since the following do block:
do
x <- foo
y <- bar
return x + y
is desugared to the following form:
foo >>= (\x -> bar >>= (\y -> return x + y))
aren't \x -> ... and y -> ... actually continuations here?
I was wondering if there is a way to capture the continuations in the definition of bind, but I can't get the types right. I.e:
data Pause a = Pause a | Stop
instance Monad Pause where
return x = Stop
m >>= k = Pause k -- this doesn't work of course
Now I tried muddling around with the types:
data Pause a = Pause a (a -> Pause ???) | Stop
------- k ------
But this doesn't work either. Is there no way to capture these implicit continuations?
Btw, I know about the Cont monad, I'm just experimenting and trying out stuff.
OK I'm not really sure, but let me put a few thoughts. I'm not quite sure what it
ought to mean to capture the continuation. You could, for example, capture the whole
do block in a structure:
{-# LANGUAGE ExistentialQuantification #-}
import Control.Monad
data MonadExp b = Return b | forall a. Bind (MonadExp a) (a -> MonadExp b)
instance Monad MonadExp where
return x = Return x
f >>= g = Bind f g
For example:
block :: MonadExp Int
block = do
x <- return 1
y <- return 2
return $ x + y
instance Show (MonadExp a) where
show (Return _) = "Return _"
show (Bind _ _) = "Bind _ _"
print block
>> Bind _ _
And then evaluate the whole thing:
finish :: MonadExp a -> a
finish (Return x) = x
finish (Bind f g) = finish $ g (finish f)
print $ finish block
>> 3
Or step through it and see the parts
step :: MonadExp a -> MonadExp a
step (Return _) = error "At the end"
step (Bind f g) = g $ finish f
print $ step block
>> Bind _ _
print $ step $ step block
>> Return _
Well, now that I think about it more, that's probably not what you're asking. But
maybe it'll help you think.
Well, I don't know if your lambdas are continuations in the strictest sense of the term, but they also look similar to this concept in my eye.
But note that if they are continuations, then the desugared monadic code is already written in continuation passing style (CPS). The usual notion of a control operator that "captures" a continuation is based on direct-style programs; the "captured" continuation is only implicit in the direct-style program, but the CPS transformation makes it explicit.
Since the desugared monadic code is already in CPS or something like it, well, maybe a way to frame your question is whether monadic code can express some of the control flow tricks that CPS code can. Typically, those tricks boil down to the idea that while under the CPS regime it is conventional for a function to finish by invoking its continuation, a function can choose to replace its continuation with another of its choosing. This replacement continuation can be constructed with a reference to the original continuation, so that it can in turn "restore" that original one if it chooses. So for example, coroutines are implemented as a mutual "replace/restore" cycle.
And looked at in this light, I think your answer is mostly no; CPS requires that in foo >>= bar, foo must be able to choose whether bar will be invoked at all, and foo must be abble to supply a substitute for bar, but (>>=) by itself does not offer a mechanism for foo to do this, and more importantly, (>>=) is in control of the execution flow, not foo. Some specific monads implement parts or all of it (for example, the Maybe monad allows foo to forego execution of bar by producing a Nothing result), but others don't.
Closest I could get is to forego (>>=) and use this instead:
-- | Execute action #foo# with its "continuation" #bar#.
callCC :: Monad m => ((a -> m b) -> m b) -> (a -> m b) -> m b
foo `callCC` bar = foo bar
Here foo can choose whether bar will be used at all. But notice that this callCC is really just ($)!