Bad number of arguments for type constructor in Isabelle/hol - record

I am a newbie in Isabelle/hol and I have this record declaration:
record ('v,'w) fca = object_set :: "'v set" attribute_set :: "'w set" inc_set :: "('v×'w) set"
and I want to instantiate to obtain a concrete record like:
definition Concrete_fca :: fca where "pt1 ≡ (| object_set ={''a'',''b'',''c''}, attribute_set = {1::nat,2,3},inc_set = {(''a'', 1),(''a'',3)} |)"
But, I am getting an error: Bad number of arguments for type constructor: tuto2.fca
NB: tuto2 is the name of my theory and fca is the name of the record
Please can someone help me resolve this issue.
Thanks
I searched online for the same type of errors.

There are two problems with your definition. First, fca is a type constructor, not a type, so you must apply it to some type arguments to get a type (this is what the error tells you). In your case this is (string, nat).
The other problem is that you want to define Concrete_fca but then give an equation for pt1. Giving the same name in both places gives you something like this:
definition Concrete_fca :: "(string, nat) fca" where
"Concrete_fca ≡ (| object_set ={''a'',''b'',''c''}, attribute_set = {1::nat,2,3},inc_set = {(''a'', 1),(''a'',3)} |)"

Related

SYNTAX ERROR (change nameclass on assignment) in APL

When I try to assign to a name in Dyalog APL, I get one of these error messages:
SYNTAX ERROR: Can't change nameclass on assignment
SYNTAX ERROR: Invalid modified assignment, or an attempt was made to change nameclass on assignment
What exactly does it mean to "change nameclass on assignment", why isn't it allowed, and how can I work around this issue?
What exactly does it mean to "change nameclass on assignment"?
APL distinguishes between syntactic roles, and each role is identified by a number. The ⎕NC function takes one or more names, and returns their Name Class, for example 2 for variable and 3 for function, 4 for operator, and 9 for ref.
As per the assignment documentation:
Re-Assignment
A name that already exists may be assigned a new value if the assignment will not alter its name class, or will change it from 2 to 9 or vice versa. The table of permitted re-assignments is as follows:
Ref
Variable
Function
Operator
Ref
Yes
Yes
Variable
Yes
Yes
Function
Yes
Yes
Operator
Yes
Yes
Why isn't it allowed?
The prohibition against certain re-assignments is necessary to disambiguate when an augmented assignment is performed, or when the value of an assignment is used (whatever is on the right of the assignment arrow is returned as result). For example:
Plus←+
a←100
a Plus←10
a
110
Double←{2×⍵}
Double b←10
20
Without this restriction, it would be impossible to distinguish these cases from parallel assignment:
c d←10
c
10
d
10
How can I work around this issue?
Reusing a name for something entirely different is probably a bad idea in production code, and adoption of a strict naming convention (e.g. mine) is recommended. However, when experimenting in an interactive session (REPL), simply removing the definition of an existing name, opens up its usage for all purposes. The ⎕EX (expunge) system function and the )ERASE system command both do this:
a←10
a←+
SYNTAX ERROR: Can't change nameclass on assignment
a←+
∧
⎕EX'a'
a←+
a←10
SYNTAX ERROR: Invalid modified assignment, or an attempt was made to change nameclass on assignment
a←10
∧
)erase a
a←10

Recursive type aliases with Pyright

Checking the following code with Pyright:
from typing import Union, TypeVar
T = TypeVar('T')
X_or_RecurListOf = Union[T, list['X_or_RecurListOf']]
x: X_or_RecurListOf[str] = ['asd']
produces the error:
5:28 - error: Expression of type "list[str]" cannot be assigned to declared type "X_or_RecurListOf[str]"
  Type "list[str]" cannot be assigned to type "X_or_RecurListOf[str]"
    "list[str]" is incompatible with "str"
      TypeVar "_T#list" is invariant
        Type "str" cannot be assigned to type "X_or_RecurListOf[Type[T#X_or_RecurListOf]]"
          Type "str" cannot be assigned to type "T#X_or_RecurListOf"
          "str" is incompatible with "list[X_or_RecurListOf]" (reportGeneralTypeIssues)
1 error, 0 warnings, 0 infos
Completed in 0.677sec
Am I doing something wrong?
Or have I misunderstood the announcement for support of recursive types in Pyright?
Oh, I've found what Pyright stumbles over!
It wants to have the type parameter in the recursive definition:
X_or_RecurListOf = Union[T, list['X_or_RecurListOf[T]']] - pay attention to the [T]!
I don't see why this is necessary but it works for me, especially as I really meant X_or_RecurListOf[T] and not X_or_RecurListOf[Any].

Error: Kotlin: The floating-point literal does not conform to the expected type Float

I was making a simple maths calculator in kotlin, an error appeared on my screen when I tried to initialize the value of one of the variables used as 0.00 for float integer.
var x:Float= readLine()!!.toFloat()
var y:Float= readLine()!!.toFloat()
var sum:Float=0.00// the error message is showcased in this line
sum=x+y
println("Addition " + sum)
This is a key difference between Java and Kotlin. Kotlin does not do numeric type promotion like Java does. The comments to your question are showing you how to deal with this, by either matching up the two types Double and/or Float to begin with, or by explicitly converting one or the other so that the two types match up.
Your problems goes away if you make use of Kotlin's ability to infer variable types by taking the type specifications off of your variable definitions. The fact that Kotlin infers types is one reason it does not promote numeric types. Mixing the two would lead to a lot of confusion.
Here's an example of how to fix and simplify your code's type mismatch issues using type inference:
var x = readLine()!!.toFloat()
var y = readLine()!!.toFloat()
var sum = x + y
println("Addition " + sum)
I understand that this may be just test code that you're using to understand Kotlin better. With that said, I'll point out that this code will crash if your user types in non-numeric input. You could fix this by putting a try/catch around your input lines, and providing an nice error message. You might want to put each input in a loop, continuing to ask for an input until the user does provide a response that is of the expected format.

error in elm-lang `(==) is expecting the right side to be a:`

New to elm here, and at first it's driving me absolutely crazy not knowing the ins and outs of this picky language (even after reading a sh**load about it because it's just so different and finicky... I guess that's the nature of a functional lang) so when you try doing a simple thing it's like pulling hair at first.
I am getting the following error:
The right side of (==) is causing a type mismatch.
29| get 0 arrayOfValues == 'X'
^^^
(==) is expecting the right side to be a:
Maybe Char
But the right side is:
Char
Hint: With operators like (==) I always check the left side first. If it seems
fine, I assume it is correct and check the right side. So the problem may be in
how the left and right arguments interact.
Test:
it "blah blah blah" <|
let
someArray =
[ 'P', ' ' ]
in
expect (MyModule.doSomething someArray 'P') to equal 1
MyModule
doSomething : List Char -> Char -> Int
doSomething arrayOfValues symbol =
let
grid =
fromList arrayOfValues
found =
get 0 arrayOfValues == symbol
in
if found then
1
else
0
Now I'm assuming but not sure, that it's getting Nothing or something when trying to pull the first value out of my array but not sure. Maybe Char I assume is returning Nothing? donno, probably have other issues going on with it too.
I'd like to get the code above working, then refactor..I'm sure there's probably a more elegant way to code what I've coded above but first thing's first, fixing this error and understanding it better with the existing code. The error message while nice isn't that obvious to me as to how and what to handle. I have assumptions but not fully sure how to handle the behavior here of whatever is causing the issue.
Unique feature of the elm is certainty. Any variable (which is not of type maybe) will have a value of the defined type for sure.
But when it comes to array or list, it becomes uncertain if the array has an element on index "i". There may be an element and there may not be.
Hence elm has concept of Maybe,
so conceptually
Maybe String = [ Just "string_value" | Nothing ]
the alias for the Array.get is
get : Int -> Array a -> Maybe a
it takes
Int - index and
Array a - array of data type of array element
as parameters and returns
Maybe a - again a is the data type of array element
consider an example
array =
fromList ["one", "two"]
val1 =
get 0 array -- will return 'Just "one"'
val2 =
get 3 array -- will return 'Nothing', since the element does not exists
this way you will always have to handle both the situations, when you have a value and when you don't
case val1 of
Nothing ->
-- Raise some error message
Just val ->
-- `val` is the actual element/value found
and if you always need a default value, you can use
Maybe.withDefault "default_string" val1
this will always return a string value and will return "default_string" when the value is nothing otherwise the actual found value

What does the type in the formatting types syntax do?

What does the ‘type’ in the formatting types syntax of format! do?
Of this, that is:
[[fill]align][sign]['#']['0'][width]['.' precision][type]
The rest appears to be well documented, but that particular one seems to have some information left out. Under its explanation it says:
type := identifier | ''
But what on Earth is it used for?
Edits
1.
Someone suggested that they be for named parameters, and that feels reasonable to assume. However, should the following code not work had that been the case?
println!("{:.2test}", test=32.432);
This generates me a rather depressing error:
error: unknown format trait `test`
--> src\main.rs:12:29
|
12 | println!("{:.2test}", test=32.432);
| ^^^^^^
What must be noted here is that the syntax above is for format_spec, which always follows a colon.
format := '{' [ argument ] [ ':' format_spec ] '}'
format_spec := [[fill]align][sign]['#']['0'][width]['.' precision][type]
With that in mind, the type part is used to specify formatting traits, which are documented as thus:
When requesting that an argument be formatted with a particular type, you are actually requesting that an argument ascribes to a particular trait. This allows multiple actual types to be formatted via {:x} (like i8 as well as isize).
[...]
If no format is specified (as in {} or {:6}), then the format trait used is the Display trait.
Here's an example (Playground):
println!("{:b}", 31); // prints 11111
println!("{:08b}", 31); // prints 00011111
Type formatting works for any data type that implements the corresponding formatting type, such as Binary or LowerHex.
At first I guessed it would be named parameters, but those actually go before the colon. Just for the record, this also works (Playground):
format!("{a:08b}", a = 31)