The following code compiles okay in Idris2:
C : Nat
C = 2
claim : C = 2
claim = Refl
but it fails if C is not capitalized:
c : Nat
c = 2
claim : c = 2
claim = Refl
The error message is
Warning: We are about to implicitly bind the following lowercase names.
You may be unintentionally shadowing the associated global definitions:
c is shadowing Main.c
Error: While processing right hand side of claim. When unifying:
2 = 2
and:
c = 2
Mismatch between: 2 and c.
Is there a way to tell Idris compiler not to shadow lowercase global names in types?
I don't know if there's a compiler option or the like, but you can qualify c. If it's in module Foo, use
c : Nat
c = 2
claim : Foo.c = 2
claim = Refl
Related
The OCaml manual, Chapter 2, says
a structure and is introduced by the struct…end construct, which contains an arbitrary sequence of definitions. The structure is usually given a name with the module binding.
Is there any use case for the creating a struct and not giving it a module name.
If not, then we always use
module Name =
struct
...
end
and so the struct keyword seems a bit redundant.
It's possible and even common (in my code at least) to use nameless structures. One example:
module MyStrSet =
Set.Make(struct type t = string let compare a b = compare b a end)
To expand slightly on Jeffrey's answer, an OCaml functor maps a module to another module. It doesn't care about the module's name.
Consider the following trivial example.
module type SIG =
sig
val x : int
end
module A (B : SIG) =
struct
let y = B.x * 2
end
I've defined a functor A which takes a module B that fulfills the module type SIG. Now, I could define a module Twenty_one that supplies an x value of 21, and then give that to the functor A to create module C.
module Twenty_one =
struct
let x = 21
end
module C = A (Twenty_one)
Or I could directly use an anonymous structure.
module C = A (struct let x = 21 end)
We don't even need to name SIG.
module A (B : sig val x : int end) =
struct
let y = B.x * 2
end
module C = A (struct let x = 21 end)
Strongly into opinion territory, but you may want to give these things names in your code, if it aids with reuse and expressivess.
E.g.
module Int =
struct
type t = int
let compare = compare
end
module Int_map = Map.Make (Int)
Vs.
module Int_map = Map.Make (struct type t = int let compare = compare end)
Another thing you can do with an anonymous structure, that's more relevant to recent (as of 4.08.0) OCaml, is the ability to use open with it, for a syntactically-cheap way to hide names in your namespace (until you write an interface file anyway):
open struct
type hidden_type = string
let hidden_name = 42
end
This feature is called generalized-open, and the relevant manual page for it is here.
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.
In the documentation, it says:
Equality in Idris is heterogeneous, meaning that we can even propose
equalities between values in different types:
idris_not_php : 2 = "2"
That particular example compiles, but the hole is presented as being of type fromInteger 2 = "2". Given that fromInteger 2 can belong to any type that is an instance of Num, maybe the compiler isn't quite clever enough to deduce that the value of 2 is not a String?
In comparison, the following slightly different code fails to compile:
idris_not_php : S (S Z) = "2"
The compiler reports a type mismatch between Nat and String.
Also, the following does compile successfully:
Num String where
(+) x y = y
(*) x y = y
fromInteger n = "2"
idris_not_php : 2 = "2"
idris_not_php = the (the String 2 = "2") Refl
And these two compile:
idris_not_php : S (S Z) ~=~ "2"
idris_not_php = ?hole
two_is_two : 2 ~=~ 2
two_is_two = Refl
Is there any particular rule about when = can be used between things that are of different types, or is it just a matter of using ~=~ when = doesn't work? Are ~=~ and = semantically identical, and if so, why is ~=~ even necessary?
This answer have some theoretical notes about heterogeneous equality in Idris. And this answer has example of why you may need (~=~).
I just want to add a little about idris_not_php : 2 = "2" example. This can be type checked if you have Num instance for String type just as you did. Integral constants in Idris are polymorphic. Though, any reasonable program wouldn't have such instance for String because it doesn't make sense.
Just started Haskell, it's said that everything in Haskell is "immutable" except IO package. So when I bind a name to something, it's always something immutable? Question, like below:
Prelude> let removeLower x=[c|c<-x, c `elem` ['A'..'Z']]
Prelude> removeLower "aseruiiUIUIdkf"
"UIUI"
So here:
1. “removeLower" is an immutable? Even it's a function object?
But I can still use "let" to assign something else to this name.
2. inside the function "c<-x" seems that "c" is a variable.
It is assigned by list x's values.
I'm using the word "variable" from C language, not sure how Haskell name all its names?
Thanks.
If you're familiar with C, think of the distinction between declaring a variable and assigning a value to it. For example, you can declare a variable on its own and later assign to it:
int i;
i = 7;
Or you can declare a variable and assign initial value at the same time:
int i = 7;
And in either case, you can mutate the value of a variable by assigning to it once more after the first initialization or assignment:
int i = 7; // Declaration and initial assignment
i = 5; // Mutation
Assignment in Haskell works exclusively like the second example—declaration with initialization:
You declare a variable;
Haskell doesn't allow uninitialized variables, so you are required to supply a value in the declaration;
There's no mutation, so the value given in the declaration will be the only value for that variable throughout its scope.
I bolded and hyperlinked "scope" because it's the second critical component here. This goes one of your questions:
“removeLower" is an immutable? Even it's a function object? But I can still use "let" to assign something else to this name.
After you bind removeLower to the function you define in your example, the name removeLower will always refer to that function within the scope of that definition. This is easy to demonstrate in the interpreter. First, let's define a function foo:
Prelude> let foo x = x + 2
Prelude> foo 4
6
Now we define an bar that uses foo:
Prelude> let bar x = foo (foo x)
Prelude> bar 4
8
And now we "redefine" foo to something different:
Prelude> let foo x = x + 3
Prelude> foo 4
7
Now what do you think happens to bar?
Prelude> bar 4
8
It remains the same! Because the "redefinition" of foo doesn't mutate anything—it just says that, in the new scope created by the "redefinition", the name foo stands for the function that adds three. The definition of bar was made in the earlier scope where foo x = x + 2, so that's the meaning that the name foo has in that definition of bar. The original value of foo was not destroyed or mutated by the "redefinition."
In a Haskell program as much as in a C program, the same name can still refer to different values in different scopes of the program. This is what makes "variables" variable. The difference is that in Haskell you can never mutate the value of a variable within one scope. You can shadow a definition, however—uses of a variable will refer to the "nearest" definition of that name in some sense. (In the case of the interpreter, the most recent let declaration for that variable.)
Now, with that out of the way, here are the syntaxes that exist in Haskell for variable binding ("assignment"). First, there's top-level declarations in a module:
module MyLibrary (addTwo) where
addTwo :: Int -> Int
addTwo x = x + 2
Here the name addTwo is declared with the given function as its value. A top level declaration can have private, auxiliary declarations in a where block:
addSquares :: Integer -> Integer
addSquares x y = squareOfX + squareOfY
where square z = z * z
squareOfX = square x
squareOfY = square y
Then there's the let ... in ... expression, that allows you to declare a local variable for any expression:
addSquares :: Integer -> Integer
addSquares x y =
let square z = z * z
squareOfX = square x
squareOfY = square y
in squareOfX + squareOfY
Then there's the do-notation that has its own syntax for declaring variables:
example :: IO ()
example = do
putStrLn "Enter your first name:"
firstName <- getLine
putStrLn "Enter your lasst name:"
lastName <- getLine
let fullName = firstName ++ " " ++ lastName
putStrLn ("Hello, " ++ fullName ++ "!")
The var <- action assigns a value that is produced by an action (e.g., reading a line from standard input), while let var = expr assigns a value that is produced by a function (e.g., concatenating some strings). Note that the let in a do block is not the same thing as the let ... in ... from above!
And finally, in list comprehension you get the same assignment syntax as in do-notation.
It's referring to the monadic bind operator >>=. You just don't need to explicitly write a lambda as right hand side parameter. The list comprension will be compiled down to the monadic actions defined. And by that it means exactly the same as in a monadic environment.
In fact you can replace the list comprension with a simple call to filter:
filter (`elem` ['A' .. 'Z']) x
To answer your question regarding the <- syntactic structure a bit clearer:
[c| c <- x]
is the same as
do c <- x
return c
is the same as
x >>= \c -> return c
is the same as
x >>= return
Consider the official documentation of Haskell for further reading: https://hackage.haskell.org/package/base-4.8.2.0/docs/Control-Monad.html#v:-62--62--61-
[c|c<-x, c `elem` ['A'..'Z']]
is a list comprehension, and c <- x is a generator where c is a pattern to be matched from the elements of the list x. c is a pattern which is successively bound to the elements of the input list x which are a, s, e, u, ... when you evaluate removeLower "aseruiiUIUIdkf".
c `elem` ['A'..'Z']
is a predicate which is applied to each successive binding of c inside the comprehension and an element of the input only appears in the output list if it passes this predicate.
Suppose I have the following setup
module type FOO = sig type f val do_foo : f end
module type BAR = sig type b val do_bar : b end
module type FOOANDBAR =
sig
include FOO
include BAR
end
Now I want to (in a nice way, aka, without copying the interface and so that FOO and BAR are still subtypes) enforce the restriction that the type f and the type b are the same.
Is there a nice way to do this in OCaml, possibly using some different approach that the include keyword?
thanks!!
-Joseph
module type FOOANDBAR =
sig
include FOO
include (BAR with type b = f)
end