The Beginning Elm - Let Expression page builds on the previous page, but it doesn't cover how to update the main function, written in forward function notation, which was:
main =
time 2 3
|> speed 7.67
|> escapeEarth 11
|> Html.text
to include the new fuelStatus parameter.
The compiler complains about a type mismatch, which is correct, as escapeEarth now has a third argument, which is a string.
As stated on that site "The forward function application operator takes the result from the previous expression and passes it as the last argument to the next function application."
In other words, how do I write this:
Html.text (escapeEarth 11 (speed 7.67 (time 2 3)) "low")
using forward notation?
Also, why doesn't this print "Land on droneship", along with "Stay in orbit"? It only prints "Stay in orbit":
module Playground exposing (..)
import Html
escapeEarth velocity speed fuelStatus =
let
escapeVelocityInKmPerSec =
11.186
orbitalSpeedInKmPerSec =
7.67
whereToLand fuelStatus =
if fuelStatus == "low" then
"Land on droneship"
else
"Land on launchpad"
in
if velocity > escapeVelocityInKmPerSec then
"Godspeed"
else if speed == orbitalSpeedInKmPerSec then
"Stay in orbit"
else
"Come back"
speed distance time =
distance / time
time startTime endTime =
endTime - startTime
main =
Html.text (escapeEarth 11 (speed 7.67 (time 2 3)) "low")
I think what you need is
main =
time 2 3
|> speed 7.67
|> \spd -> escapeEarth 11 spd "low"
|> Html.text
In other words you define a little anonymous function to insert the value correctly. You may want to look at whether the escapeEarth function should be defined with a different order.
An alternative if you love 'point free' would be
main =
time 2 3
|> speed 7.67
|> flip (escapeEarth 11) "low"
|> Html.text
Some would argue that this is less clear though
As for your second question you have defined functions in your let statement but never actually used it
Related
This question already has an answer here:
Haskell: What is immutable data?
(1 answer)
Closed 4 years ago.
I heard that Haskell variables are immutable but i am able to reassign and update variable values
First, note that GHCi syntax is not quite the same as Haskell source-file syntax. In particular, x = 3 actually used to be illegal as such:
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> x = 3
<interactive>:2:3: parse error on input ‘=’
Newer versions have made this possible by simply rewriting any such expression to let x = 3, which has always been ok:
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> let x = 3
Prelude> x
3
By contrast, in a Haskell source file, let x = 3 has never been legal by itself. This only works in a particular environment, namely a monadic do block.
main :: IO ()
main = do
let x = 3
print x
3
And the GHCi prompt by design actually works like the lines in a do block, so let's in the following discuss that. Note that I can also write
main = do
let x = 1
let x = 3
print x
3
And that's basically what's also going on in your GHCi session. However, as the others have remarked, this is not mutation but shadowing. To understand how this works, note that the above is essentially a shorthand way of writing
main =
let x = 1
in let x = 3
in print x
So, you have two nested scopes. When you look up a variable in some expression, Haskell always picks the “nearest one”, i.e. in the inner scope:
main =
let x = 1
┌──
in│let x = 3
│in print x
└─
The outer x isn't touched at all, it's basically unrelated to anything going on in the inner scope. The compiler will actually warn you about this, if asked if there's anything fishy in your file:
$ ghc -Wall wtmpf-file16485.hs
[1 of 1] Compiling Main ( wtmpf-file16485.hs, wtmpf-file16485.o )
wtmpf-file16485.hs:3:8: warning: [-Wunused-local-binds]
Defined but not used: ‘x’
|
3 | let x = 1
| ^
wtmpf-file16485.hs:3:12: warning: [-Wtype-defaults]
• Defaulting the following constraint to type ‘Integer’
Num p0 arising from the literal ‘3’
• In the expression: 3
In an equation for ‘x’: x = 3
In the expression:
do let x = 1
let x = 3
print x
|
3 | let x = 1
| ^
wtmpf-file16485.hs:4:8: warning: [-Wname-shadowing]
This binding for ‘x’ shadows the existing binding
bound at wtmpf-file16485.hs:3:8
|
4 | let x = 3
| ^
There: the second definition simply introduces a new, more local variable which also happens to be called x, but is unrelated to the outer variable. I.e. we might as well rename them:
main = do
let xOuter = 1
let xInner = 3
print xInner
A consequence of all this is that a variable that's “mutated” in this way has no influence on other functions which use the original variable. Example:
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/sagemuej/.ghci
Loaded GHCi configuration from /home/sagemuej/.ghc/ghci.conf
Prelude> let x = 1
Prelude> let info = putStrLn ("x is ="++show x++" right now")
Prelude> x = 3
Prelude> info
x is =1 right now
Another consequence is that “updates” which try to use the old value behave in a funny way:
Prelude> let s = "World"
Prelude> s = "Hello"++s
Prelude> s
"HelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHelloHell^C
Here, the new binding does not just prepend "Hello" to the old s="World". Instead, it prepends "Hello" to its own result value, which is in turn defined by "Hello" prepended to... and so on, recursively.
You're shadowing, not mutating.
I need to rely on the fact that two Z3 variables
can not have the same name.
To be sure of that,
I've used tuple_example1() from test_capi.c in z3/examples/c and changed the original code from:
// some code before that ...
x = mk_real_var(ctx, "x");
y = mk_real_var(ctx, "y"); // originally y is called "y"
// some code after that ...
to:
// some code before that ...
x = mk_real_var(ctx, "x");
y = mk_real_var(ctx, "x"); // but now both x and y are called "x"
// some code after that ...
And (as expected) the output changed from:
tuple_example1
tuple_sort: (real, real)
prove: get_x(mk_pair(x, y)) = 1 implies x = 1
valid
disprove: get_x(mk_pair(x, y)) = 1 implies y = 1
invalid
counterexample:
y -> 0.0
x -> 1.0
to:
tuple_example1
tuple_sort: (real, real)
prove: get_x(mk_pair(x, y)) = 1 implies x = 1
valid
disprove: get_x(mk_pair(x, y)) = 1 implies y = 1
valid
BUG: unexpected result.
However, when I looked closer, I found out that Z3 did not really fail or anything, it is just a naive (driver) print out to console.
So I went ahead and wrote the exact same test with y being an int sort called "x".
To my surprise, Z3 could handle two variables with the same name when they have different sorts:
tuple_example1
tuple_sort: (real, real)
prove: get_x(mk_pair(x, y)) = 1 implies x = 1
valid
disprove: get_x(mk_pair(x, y)) = 1 implies y = 1
invalid
counterexample:
x -> 1.0
x -> 0
Is that really what's going on? or is it just a coincidence??
Any help is very much appreciated, thanks!
In general, SMT-Lib does allow repeated variable names, so long as they have different sorts. See page 27 of the standard. In particular, it says:
Concretely, a variable can be any symbol, while a function symbol
can be any identifier (i.e., a symbol or an indexed symbol). As a
consequence, contextual information is needed during parsing to know
whether an identifier is to be treated as a variable or a function
symbol. For variables, this information is provided by the three
binders which are the only mechanism to introduce variables. Function
symbols, in contrast, are predefined, as explained later. Recall that
every function symbol f is separately associated with one or more
ranks, each specifying the sorts of f’s arguments and result. To
simplify sort checking, a function symbol in a term can be annotated
with one of its result sorts σ. Such an annotated function symbol is a
qualified identifier of the form (as f σ).
Also on page 31 of the same document, it further clarifies "ambiguity" thusly:
Except for patterns in match expressions, every occurrence of an
ambiguous function symbol f in a term must occur as a qualified
identifier of the form (as f σ) where σ is the intended output sort of
that occurrence
So, in SMT-Lib lingo, you'd write like this:
(declare-fun x () Int)
(declare-fun x () Real)
(assert (= (as x Real) 2.5))
(assert (= (as x Int) 2))
(check-sat)
(get-model)
This produces:
sat
(model
(define-fun x () Int
2)
(define-fun x () Real
(/ 5.0 2.0))
)
What you are observing in the C-interface is essentially a rendering of the same. Of course, how much "checking" is enforced by the interface is totally solver specific as SMT-Lib says nothing about C API's or API's for other languages. That actually explains the BUG line you see in the output there. At this point, the behavior is entirely solver specific.
But long story short, SMT-Lib does indeed allow two variables have the same name used so long as they have different sorts.
I need to unwrap a Maybe -value in one of my update functions:
update msg model =
case msg of
UpdateMainContent val ->
Maybe.withDefault 100 (Just 42)
model
This of course is dummy code and the
Maybe.withDefault 100 (Just 42)
is taken straight out of the documentation for Maybe and not supposed to actually do anything. The compiler is complaining and saying:
Detected errors in 1 module.
-- TYPE MISMATCH ----------------------------------- ./src/Review/Form/State.elm
The 1st argument to function `withDefault` is causing a mismatch.
15|> Maybe.withDefault 100 (Just 42))
16| -- Maybe.withDefault 100 (model.activeItem)
17| model
Function `withDefault` is expecting the 1st argument to be:
a -> b
But it is:
number
Why is it saying that "withDefault" is expecting the first argument to be
a -> b
when it is defined as
a -> Maybe a -> a
in the documentation?
You accidentally left in model:
UpdateMainContent val ->
Maybe.withDefault 100 (Just 42)
model -- <-- here
This makes the type inference algorithm think that Maybe.withDefault 100 (Just 42) should evaluate to a function that can take this model argument. For that to make sense, it expects 100 and 42 to be functions, but they aren't, and so it tells you.
It might help to see an example where this works:
f : Int -> Int
f x = x + 1
Maybe.withDefault identity (Just f) 0
This will evaluate to 1.
The following method determines how many numbers can be added up starting from the beginning of the list without adding up to 4:
number_before_Reaching_sum (4, [1,2,3,4,6]);
should return : val it = 2 : int
fun number_before_reaching_sum (sum : int * int list) =
let val len_orig_list = length (#2 sum)
in fun num_bef_reach_sum (sum) =
if #1 sum <= 0
then len_orig_list - (length (#2 sum)) - 1
else num_bef_reach_sum (#1 sum - hd (#2 sum), tl (#2 sum))
end
syntax error: inserting LOCAL
syntax error found at EOF
I can't seem to find the errors in this code. I have some experience with Python, but just starting to learn sml. I'm loving it, but I don't understand all the error messages. I have really spent hours on this, but I think I don't know enough to solve my problem. I tried exchanging let with local, but i still got a syntax error (equalop). I think that the function between in and end is an expression and not a declaration. But I would appreciate any comments on this. If you come up with alternative code, it would be great if you did it without using more advanced features, since I'm just trying to get the basics down :-)
You probably meant this:
fun number_before_reaching_sum (sum : int * int list) =
let
val len_orig_list = length (#2 sum)
fun num_bef_reach_sum (sum) =
if #1 sum <= 0
then len_orig_list - (length (#2 sum)) - 1
else num_bef_reach_sum (#1 sum - hd (#2 sum), tl (#2 sum))
in
num_bef_reach_sum (sum)
end
With let … in … end, the part between let and in is for the local definitions; the part between in and end is for the expression which will be the evaluation of the let … in … end expression (this construct is indeed an expression).
Think of let … in … end as a possibly complex expression. You hoist parts of the expression as definitions, then rewrite the complex expression using references to these definitions. This help write shorter expressions by folding some of its sub‑expressions. This construct is also required when recursion is needed (a recursion requires a defining name).
Another way to understand it, is as the application of an anonymous function whose arguments bindings are these definitions.
Ex.
let
val x = 1
val y = 2
in
x + y
end
is the same as writing
(fn (x, y) => x + y) (1, 2)
which is the same as writing
1 + 2
You erroneously put a definition at the place of the expression the whole evaluates to.
(note I did not check the function's logic, as the question was about syntax)
As title says, I don't understand why f^:proposition^:_ y is a while loop. I have actually used it a couple times, but I don't understand how it works. I get that ^: repeats functions, but I'm confused by its double use in that statement.
I also can't understand why f^:proposition^:a: y works. This is the same as the previous one but returns the values from all the iterations, instead of only the last one as did the one above.
a: is an empty box and I get that has a special meaning used with ^: but even after having looked into the dictionary I couldn't understand it.
Thanks.
Excerpted and adapted from a longer writeup I posted to the J forums in 2009:
while =: ^:break_clause^:_
Here's an adverb you can apply to any code (which would equivalent of the
loop body) to create a while loop. In case you haven't seen it before, ^: is the power conjunction. More specifically, the phrase f^:n y applies the function f to the argument y exactly n times. The count n maybe be an integer or a function which applied to y produces an integer¹.
In the adverb above, we see the power conjunction twice, once in ^:break_clause and again in ^:_ . Let's first discuss the latter. That _ is J's notation for infinity. So, read literally, ^:_ is "apply the function an infinite number of times" or "keep reapplying forever". This is related to a while-loop's function, but it's not very useful if applied literally.
So, instead, ^:_ and its kin were defined to mean "apply a function to its limit", that is, "keep applying the function until its output matches its input". In that case, applying the function again would have no effect, because the next iteration would have the same input as the previous (remember that J is a functional language). So there's
no point in applying the function even once more: it has reached its limit.
For example:
cos=: 2&o. NB. Cosine function
pi =: 1p1 NB. J's notation for 1*pi^1 analogous to scientific notation 1e1
cos pi
_1
cos cos cos pi
0.857553
cos^:3 pi
0.857553
cos^:10 pi
0.731404
cos^:_ pi NB. Fixed point of cosine
0.739085
Here, we keep applying cosine until the answer stops changing: cosine has reached its fixed point, and more applications are superfluous. We can visualize this by showing the
intermediate steps:
cos^:a: pi
3.1415926535897 _1 0.54030230586813 ...73 more... 0.73908513321512 0.73908513321
So ^:_ applies a function to its limit. OK, what about ^:break_condition? Again, it's the same concept: apply the function on the left the number of times specified by the function on the right. In the case of _ (or its function-equivalent, _: ) the output is "infinity", in the case of break_condition the output will be 0 or 1 depending on the input (a break condition is boolean).
So if the input is "right" (i.e. processing is done), then the break_condition will be 0, whence loop_body^:break_condition^:_ will become loop_body^:0^:_ . Obviously, loop_body^:0 applies the loop_body zero times, which has no effect.
To "have no effect" is to leave the input untouched; put another way, it copies the input to the output ... but if the input matches the output, then the function has reached its limit! Obviously ^:_: detects this fact and terminates. Voila, a while loop!
¹ Yes, including zero and negative integers, and "an integer" should be more properly read as "an arbitrary array of integers" (so the function can be applied at more than one power simultaneously).
f^:proposition^:_ is not a while loop. It's (almost) a while loop when proposition returns 1 or 0. It's some strange kind of while loop when proposition returns other results.
Let's take a simple monadic case.
f =: +: NB. Double
v =: 20 > ] NB. y less than 20
(f^:v^:_) 0 NB. steady case
0
(f^:v^:_) 1 NB. (f^:1) y, until (v y) = 0
32
(f^:v^:_) 2
32
(f^:v^:_) 5
20
(f^:v^:_) 21 NB. (f^:0) y
21
This is what's happening: every time that v y is 1, (f^:1) y is executed. The result of (f^:1) y is the new y and so on.
If y stays the same for two times in a row → output y and stop.
If v y is 0→ output y and stop.
So f^:v^:_ here, works like double while less than 20 (or until the result doesn't change)
Let's see what happens when v returns 2/0 instead of 1/0.
v =: 2 * 20 > ]
(f^:v^:_) 0 NB. steady state
0
(f^:v^:_) 1 NB. (f^:2) 1 = 4 -> (f^:2) 4 = 16 -> (f^:2) 16 = 64 [ -> (f^:0) 64 ]
64
(f^:v^:_) 2 NB. (f^:2) 2 = 8 -> (f^:2) 8 = 32 [ -> (f^:0) 32 ]
32
(f^:v^:_) 5 NB. (f^:2) 5 = 20 [ -> (f^:0) 20 ]
20
(f^:v^:_) 21 NB. [ (f^:0) 21 ]
21
You can have many kinds of "strange" loops by playing with v. (It can even return negative integers, to use the inverse of f).