Equivalent of creating objects in Haskell - oop

I am trying to understand how the following are used:
data Maybe a = Nothing | Just a
data Either a b = Left a | Right b
From my understanding these are parameterized algebraic data types. Coming from an OO background, I would now like to create an instance of these objects. If I do something like:
x = Maybe 10
Is that now a subclass/sub-algebraic-data-type, or wondering what that object is called. I would assume it is a type of some sort. If so, then I am wondering how to create an instance of x. In OO land I would do:
myinstance = new x
This is where coming to Haskell gets me lost and I'm not sure where to search. A few questions to summarize:
What kind of object x is above. If Maybe is a parameterized data type, then x is ~something~ type, not sure.
How to create an instance of x.
What is the instance of x for Maybe, since we passed it 10. Wondering, if the instance value is 10 and has type Int.

There is no such thing as Maybe 10 in Haskell. There is Maybe Int, which is a type.
We create a value of a certain type, directly, as
x :: Maybe Int
x = Just 10
or
y :: Maybe Int
y = Nothing
Simple and direct.
edit: Maybe is a type constructor. Just and Nothing are data constructors. By writing Maybe Int we "create" a type. There can't be a definition z :: Maybe ; z = ......
This is known as "kind": the kind of Maybe is * -> *, while e.g. Int's is * and so is Maybe Int's. Try :k at GHCi prompt to see this:
~> :k Int
Int :: *
~> :k Maybe
Maybe :: * -> *
~> :k Maybe Int
Maybe Int :: *
Of course we don't actually create a new type when we write "Maybe Int, it's just that Maybe by itself is not a type of things yet (types of "things" have kind *).
The definition for Maybe is what creates the types Maybe a, for any a we might use. This is known as parametric polymorphism.
So in Haskell, we don't have objects (in the OOP sense). We have values and types.

What kind of object x is above. If Maybe is a parameterized data type, then x is ~something~ type, not sure.
You can not construct a Maybe 10, you can for example construct a Just 10. In case 10 is here an Int (well technically it can be any numerical type, but let us ignore that for now), then you constructed a Maybe Int.
Note that a in Maybe a, is one meta level higher: it works with types. Hence a is a type parameter. It thus does not take as value 10, but for example Int.
What you can do however is define a type alias for Maybe Int, for example:
type X = Maybe Int
Note that we here use type as a type alias, not data to construct a data type.
Types (and type aliasses) always start with an upper case, so we can not define a type x, only a type X. A type has no default constructor (which is typically the case in OO programming languages).
How to create an instance of x.
Haskell can derive the most generic type of an expression itself. We thus write an expression that has the type of Maybe Int, so for example
Just 10
In case the type would be too generic (here it will be Num a => Maybe a), we can give a hint to Haskell by using two consecutive colons (::), for eample:
Just 10 :: Maybe Int
or since we already introduced the type alias X:
Just 10 :: X
What is the instance of x for Maybe, since we passed it 10. Wondering, if the instance value is 10 and has type Int.
Welll as said before, types in Haskell have no default constructor. We here have two candidates: Just n with n an Int (in case we use type X), or Nothing. So we pick one of the two:
Just 10 :: X
Nothing :: X
Since you can not change the state of an object anymore after you constructed it (i.e. all objects in Haskell are immutable), that means that it would be strange that a default constructor sets some initial data, and then later methods would change that object.
You can therefore see a data constructor (here Just and Nothing) as a labelled container that holds a group of parameters together in a container, and labels it with what constructor was used. So a graphical view of the objects would be:
+------+ +---------+
| Just | | Nothing |
+------+ +---------+
| o |
+---|--+
|
v
+----+
| 10 |
+----+

When you write an algebraic type definition as
data Maybe a = Nothing | Just a
the LHS is a type construction expression (it states that Maybe has kind * -> *), and the RHS is a disjunction of alternatives each one being a value constructor, so for type Maybe a, Just is an unary constructor that creates an object of this type, and Nothing is the nullary one.

Related

Partial application of Printf.ksprintf

I'm trying to write a version of Printf.printf that always appends a newline character after writing its formatted output. My first attempt was
# let say fmt = Printf.ksprintf print_endline fmt;;
val say : ('a, unit, string, unit) format4 -> 'a = <fun>
The type signature looks right and say works as expected. I noticed that fmt is listed twice, and thought that partial application could eliminate it. So I tried this instead:
# let say = Printf.ksprintf print_endline;;
val say : ('_weak1, unit, string, unit) format4 -> '_weak1 = <fun>
The function definition looks cleaner, but the type signature looks wrong and say no longer works as expected. For example, say doesn't type check if the format string needs a variable number of arguments: I get an error that say "is applied to too many arguments".
I can use the let say fmt = … implementation, but why doesn't partial application work?
OCaml's type-checker loses polymorphism during partial application. That is, when you partially apply a function, the resulting function is no longer polymorphic. That's why you see '_weak1 in the second type signature.
When you include the fmt argument, you help the type-checker recognize that polymorphism is still present.
This process is called "eta conversion." Removing your fmt argument is "eta reduction" and adding it back in is called "eta expansion." You may encounter that terminology when working with other functional programming languages.
This is the value restriction at work: https://ocaml.org/manual/polymorphism.html#s:weak-polymorphism . In brief, only syntactic values can be safely generalized in let-binding in presence of mutable variables in the language.
In particular,
let f = fun x -> g y x
is a syntactic value that can be generalized, whereas
let f = g y
is a computation that cannot (always) be generalized.
A example works quite well to illustrate the issue, consider:
let fake_pair x =
let store = ref None in
fun y ->
match !store with
| None ->
store := Some y;
x, y
| Some s ->
x, s
then the type of fake_pair is 'a -> 'b -> 'a * 'b.
However, once partially applied
let p = fake_pair 0
we have initialized the store mutable value, and it is important that all subsequent call to p share the same type (because they must match the stored value). Thus the type of p is '_weak1 -> int * '_weak1 where '_weak1 is a weak type variable, aka a temporary placeholder for a concrete type.

What is right part in "query : SelectionSet Response RootQuery" type annotations?

I try to understand this line:
query : SelectionSet Response RootQuery
I understand this is a "Type Annotations" syntax, but I don't find documentation example or explanation about multiple "word" separated by whitespace.
I see these examples:
answer : Int
factorial : Int -> Int
distance : { x : Float, y : Float } -> Float
add : number -> number -> number (ref)
I found anywhere query: Int Int Int syntax, neither in Elm Syntax nor in Beginning Elm nor in Elm FAQ.
Do SelectionSet, Response, RootQuery are
functions arguments?
multi value function results?
Best regards,
Stéphane
Same question on Elm Discourse
A response in How do I read the type of a SelectionSet?
SelectionSet is a type with two type variables. Here's the definition:
type SelectionSet decodesTo scope
= SelectionSet (List RawField) (Decoder decodesTo)
In a type declaration like this, any lowercase name after the type is a type variable, which can be filled in by any type (except for a few special constrained type variables, number, appendable, comparable, and compappend). A simpler example would be Maybe, where you can have a Maybe Int or a Maybe String. Similarly, Dict takes two type variables (for the key and value) so you can have Dict String String or Dict Int MyCustomType (the key type of a Dict does need to be comparable).
So, in your scenario, Response corresponds to decodesTo and RootQuery corresponds to scope. The SelectionSet has a Decoder that decodes to a Response value, and it also carries around this scope type variable, which isn't used directly in the data that it holds. It's used as a piece of information at the type level, so that you (and the library) know that calling map (which has the type (a -> b) -> SelectionSet a scope -> SelectionSet b scope) will preserve that scope value; that is, it prevents mixing scopes.
The above is mostly general function syntax for functional languages such as Haskell, Elm, etc.
For example:
add : Int -> Int -> Int
add x y = x + y
The first line says that is function of two integer arguments with an integer return value. The second line implements the specification given in the first. One calls this function as follows:
> add 2 3
5
Note this example:
> inc = add 1
> inc 2
3
Here add 1 is a "partially applied function." It has type Int -> Int. In many languages, add 1 would not make sense. But since functions are first-class things in Elm, add 1 makes sense: it is a function. Partial application is also called "currying."

Understanding Kotlin Type system, What is meant by `{Comparable<{ Double & Int }> & Number}` and how to work with that

So for example:
var a = true
val test = if (a) -1 else -3.2
I was expecting the Type of the test should be the most closest intersection of the type-hierarchy i.e. for Int and Double is Number.
But looking at the IDE, it seems to have a type of {Comparable<{ Double & Int }> & Number}.
And the weird thing is, I cannot specify it like that (since {} is reserved for creating lambdas), I can only set it to a type of Number.
And another wierd thing is that if I try some function from Comparable interface, it throws some error:
// Warning at value 2
// The integer literal does not conform to the expected type {Double & Int}
test.compareTo(2)
3.compareTo(-1.1) // possible
2.3.compareTo(100) // possible
// But why not this is possible, while it has inferred type of Comparable?
test.compareTo(2)
Could somebody help in understanding the concept here? And few questions:
How does that type work all together, i.e. how could one variable hold two types at once?
How could one specify that type explicitly?
How do you use functions from Comparable interface, when test has implementaion of it?
& here means an intersection type (which isn't supported in the Kotlin language itself, but the compiler uses them internally). You can see it mentioned in the (incomplete) specification.
Intersection types are special non-denotable types used to express the fact that a value belongs to all of several types at the same time.
"Non-denotable" means exactly that you can't specify that type. I am not sure but I think the extra { } in types are supposed to indicate exactly this.
In particular, Comparable<Double & Int> means you can only compare test to something which is both Double and Int, but there are no such values. The compiler could probably simplify it to Comparable<Nothing>.
the most closest intersection of the type-hierarchy i.e. for Int and Double is Number.
It's least upper bound, which is closer to union, not intersection. The specification actually calls it "union types", but that's not the normal usage of that term.
This least upper bound is not Number because it also takes least upper bound of the Comparable interfaces which works out to Comparable<Double & Int> because Comparable is contravariant:
lub(Int, Double) =
Number & lub(Comparable<Int>, Comparable<Double>) =
Number & Comparable<Int & Double>
This calculation is described under type decaying:
All union types are subject to type decaying, when they are converted to a specific intersection type, representable within Kotlin type system.
The answer to question 1 is that the compiler is doing its best to infer the type, inventing new constraints to describe it as it goes.
The answer to question 2 is that you cannot.
The answer to question 3 is that you cannot, because Int is not comparable to Double and vice versa. So none of the methods from Comparable are actually usable, but the value definitely implements Comparable against something. This is not useful for Comparable, but could be for another interface. For example, imagine:
interface ZeroAndComparable<T> {
fun compareTo(t: T): Int
fun zero(): T
}
val foo : ZeroAndComparable<Int> = someZeroAndComparableInt()
val bar : ZeroAndComparable<Double> = someZeroAndComparableDouble()
val foobar = if (a) foo else bar
val zero : Any = foobar.zero() // should work
foobar.compareTo(something) // cannot work

Copying subsets of polymorphic arrays into target polymorphic arrays

I have two derived type polymorphic arrays (obj1 and obj2) in a subroutine. Based on the use of the subroutine, while the types of the two arrays may differ, both arrays are the same type; eg both type A or both type B. In the sample code below, I'm only showing one subtype of the abstract class (model), while in reality, I want this to work on multiple subtypes. Furthermore, in the production code, model1's elements have been modified before this copy.
program test
use env_kindtypes, only: si, dp
use abs_obj_model, only: model
use obj_linearDivisionModel, only: linearDivisionModel
implicit none
class(model),allocatable :: model1(:), model2(:)
allocate(linearDivisionModel::model1(10))
!want e.g. model2 = model1([1,4,6,2])
![...]
Given obj1, obj2 (type A) (given as model1, model2 of type linearDivisionMode in the example code) and a set of indices, I want to transfer the specified elements from obj1 to obj2, allocating obj2 in the process.
I have tried quite a few approaches to do so, but none seem to work.
First, I've tried direct assignment using a vector subscript; this fails, complaining that direct assignment of an allocatable polymorphic array is not yet supported.
indices = [ 1 , 2 ]
model2 = model1(indices)
result:
model2 = model1(indices)
1
Error: Assignment to an allocatable polymorphic variable at (1) is not yet supported
Second, I tried using sourced allocation. If I try this with array slice notation, it works (but my problem is not expressible solely with ranges like this). If I try to vector index the source array, it compiles, but upon runtime I get errors from running out of memory (this isn't realistic given the system).
allocate(model2,source=model1(indices))
runtime result:
Operating system error: Cannot allocate memory
Memory allocation failed
Error termination. Backtrace:
#0 0x434471 in __obj_lineardivisionmodel_MOD___copy_obj_lineardivisionmodel_Lineardivisionmode
at build/processed_src/obj_linear_model.f90:462
#1 0x436c75 in cg_charge_fit
at build/processed_src/test.f90:37
#2 0x403019 in main
at build/processed_src/test.f90:22
Works, but isn't sufficient for my purposes.
allocate(model2,source=model1(1:2))
Third, I've been able to allocate the polymorphic array in hopes of manually transferring subelements: However, when I try to do so, I get complaints of polymorphic objects and intrinsic assignment, which I come back to at later in this post.
indices = [ 1 , 2 ]
allocate(model2(size(indices)),source=model1(1))
do i=1,size(indices)
model2(i) = model1(indices(i))
enddo
Error: Nonallocatable variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator.
I have tried using type select statements to remove the polymorphic context, but errors remain.
select type (POBJECT => model1)
TYPE IS (linearDivisionModel)
allocate(linearDivisionModel::model2(size(indices)))
do i=1,size(indices)
model2(i) = POBJECT(indices(i))
enddo
end select
results:
model2(i) = model1(indices(i))
1
Error: Nonallocatable variable must not be polymorphic in intrinsic assignment at (1) - check that there is a matching specific subroutine for '=' operator
As a work around, I hoped to use an intermediate pointer object, and to source allocation from that. Due to the f2008 standard (which is enforced here) I can't assign a pointer to a vector indexed array. Interestingly, if I create a pointer, vector index that pointer, the compiler segfaults, indicating that there make be something weird going on.
To address the compiler complaints about intrinsic assignment, I've considered writing assignment routines; however, this draws a new set of worries: the parent type both of these routines inherit from is abstract, and I cannot seem to specify a generic deferred assignment operator in that class, leading to a complex parent class which requires quite a few private methods to copy as it specifies no private variables. Furthermore, transformation between subclasses A and B is poorly defined. This still seems to be the only remaining way out, and seems complex.
How can I effectively transfer the specified polymorphic subrarrays?
I'm using gfortran version 6.1.1.
With complete F2008 support, this is simply an assignment statement.
Within the constraints of that compiler, you may need to consider nested SELECT TYPE constructs, that eliminate the polymorphic nature of the left and right hand sides of the assignment.
module my_types
implicit none
type, abstract :: model
end type
type, extends(model) :: linearDivisionModel
character :: comp
end type linearDivisionModel
end module my_types
program p
use my_types
implicit none
class(model),allocatable :: model1(:), model2(:)
integer, allocatable :: indicies(:)
! define model1.
block
type(linearDivisionModel), allocatable :: tmp(:)
allocate(tmp(10))
tmp%comp = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j']
call move_alloc(tmp, model1)
end block
indicies = [1, 2, 4, 6]
! allocate model2.
allocate(model2(size(indicies)), mold=model1)
! define model2
select type (model1)
type is (linearDivisionModel)
select type (model2)
type is (linearDivisionModel)
model2 = model1(indicies)
end select
end select
! display results.
select type (model2)
type is (linearDivisionModel)
print *, model2%comp
end select
end program p
The above appears to work with current gfortran trunk.

What is a programming language with dynamic scope and static typing?

I know the language exists, but I can't put my finger on it.
dynamic scope
and
static typing?
We can try to reason about what such a language might look like. Obviously something like this (using a C-like syntax for demonstration purposes) cannot be allowed, or at least not with the obvious meaning:
int x_plus_(int y) {
return x + y; // requires that x have type int
}
int three_plus_(int y) {
double x = 3.0;
return x_plus_(y); // calls x_plus_ when x has type double
}
So, how to avoid this?
I can think of a few approaches offhand:
Commenters above mention that Fortran pre-'77 had this behavior. That worked because a variable's name determined its type; a function like x_plus_ above would be illegal, because x could never have an integer type. (And likewise one like three_plus_, for that matter, because y would have the same restriction.) Integer variables had to have names beginning with i, j, k, l, m, or n.
Perl uses syntax to distinguish a few broad categories of variables, namely scalars vs. arrays (regular arrays) vs. hashes (associative arrays). Variables belonging to the different categories can have the exact same name, because the syntax distinguishes which one is meant. For example, the expression foo $foo, $foo[0], $foo{'foo'} involves the function foo, the scalar $foo, the array #foo ($foo[0] being the first element of #foo), and the hash %foo ($foo{'foo'} being the value in %foo corresponding to the key 'foo'). Now, to be quite clear, Perl is not statically typed, because there are many different scalar types, and these are types not distinguished syntactically. (In particular: all references are scalars, even references to functions or arrays or hashes. So if you use the syntax to dereference a reference to an array, Perl has to check at runtime to see if the value really is an array-reference.) But this same approach could be used for a bona fide type system, especially if the type system were a very simple one. With that approach, the x_plus_ method would be using an x of type int, and would completely ignore the x declared by three_plus_. (Instead, it would use an x of type int that had to be provided from whatever scope called three_plus_.) This could either require some type annotations not included above, or it could use some form of type inference.
A function's signature could indicate the non-local variables it uses, and their expected types. In the above example, x_plus_ would have the signature "takes one argument of type int; uses a calling-scope x of type int; returns a value of type int". Then, just like how a function that calls x_plus_ would have to pass in an argument of type int, it would also have to provide a variable named x of type int — either by declaring it itself, or by inheriting that part of the type-signature (since calling x_plus_ is equivalent to using an x of type int) and propagating this requirement up to its callers. With this approach, the three_plus_ function above would be illegal, because it would violate the signature of the x_plus_ method it invokes — just the same as if it tried to pass a double as its argument.
The above could just have "undefined behavior"; the compiler wouldn't have to explicitly detect and reject it, but the spec wouldn't impose any particular requirements on how it had to handle it. It would be the responsibility of programmers to ensure that they never invoke a function with incorrectly-typed non-local variables.
Your professor was presumably thinking of #1, since pre-'77 Fortran was an actual real-world language with this property. But the other approaches are interesting to think about. :-)
I haven't found elsewhere has it written down, but AXIOM CAS (and various forks, including FriCAS which is still been actively developed) uses a script language called SPAD with both a very novel strong static dependent type system and dynamic scoping (although it is possibly an unintended implementation bug).
Most of the time the user won't realize that, but when they start trying to build closures like other functional languages it reveals its dynamic scoping nature:
FriCAS Computer Algebra System
Version: FriCAS 2021-03-06
Timestamp: Mon May 17 10:43:08 CST 2021
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
(1) -> foo (x,y) == x + y
Type: Void
(2) -> foo (1,2)
Compiling function foo with type (PositiveInteger, PositiveInteger)
-> PositiveInteger
(2) 3
Type: PositiveInteger
(3) -> foo
(3) foo (x, y) == x + y
Type: FunctionCalled(foo)
(4) -> bar x y == x + y
Type: Void
(5) -> bar
(5) bar x == y +-> x + y
Type: FunctionCalled(bar)
(6) -> (bar 1)
Compiling function bar with type PositiveInteger ->
AnonymousFunction
(6) y +-> #1 + y
Type: AnonymousFunction
(7) -> ((bar 1) 2)
(7) #1 + 2
Type: Polynomial(Integer)
Such a behavior is similar to what will happen when trying to build a closure by using (lambda (x) (lambda (y) (+ x y))) in a dynamically scoped Lisp, such as Emacs Lisp. Actually the underlying representation of functions is essentially the same as Lisp in the early days since AXIOM has been first developed on top of an early Lisp implementation on IBM mainframe.
I believe it is however a defect (like what JMC happened did when implementing the first version of LISP language) because the implementor made the parser to do uncurrying as in the function definition of bar, but it is unlikely to be useful without the ability to build the closure in the language.
It is also worth notice that SPAD automatically renames the variables in anomalous functions to avoid captures so its dynamic scoping could be used as a feature as in other Lisps.
Dynamic scope means, that the variable and its type in a specific line of your code depends on the functions, called before. This means, you can not know the type in a specific line of your code, because you can not know, which code has been executed before.
Static typing means, that you have to know the type in every line of your code, before the code starts to run.
This is irreconcilable.