I have the following very simple model in Alloy:
abstract sig Object {}
pred show(){}
run show for 5
when I execute this model, Why alloy analyzer still makes an instance of Object while it is defined to be abstract!
An abstract signature can contain atoms so long as it has no subsignatures. This is designed to allow you to build and animate a model incrementally, so you can mark a signature as abstract with the expectation that subsignatures will be introduced later.
Related
In object-oriented languages (e.g; Java and Python) we can make objects/instances from classes.
In Haskell we can make instances from type-classes, ex:
data ShirtSize = S | M | L -- Here ShirtSize is a enum data-type
class MyEq a where
(==) :: a -> a -> Bool
instance MyEq ShirtSize where -- Here ShirtSize is an instance of the MyEq type-class
S == S = True
M == M = True
L == L = True
_ == _ = False
My question is:
What does instance mean in haskell?
In java we can make instances from classes, but in haskell it seems like instances are types (like ShirtSize) which you can apply type-class functions on (e.g the (==) function from MyEq). Am I right? and also what is an instance in Haskell compared to an instance/object in Java?
In Java, the class system is a way to group similar objects. An instance of a class is an individual object which belongs to that class.
In Haskell, the class system is (roughly speaking) a way to group similar types. (This is the reason we call them "type classes"). An instance of a class is an individual type which belongs to that class. (That is, until you start considering multiparametric type classes).
Incidentally, a Haskell (monoparametric) class somewhat resembles a Java interface and, by extension, a Java class. Or perhaps a Haskell instance resembles Java class. It's better to view this as a coincidence. Approach the term keeping its mathematical origins in mind. A class is just a bunch of things that belong together, and an instance is one of these things.
If you're interested in explanation of type classes and difference from Java interfaces you should read this post by <❤>. It also explains instances as well.
As for me, I look at instance as connection between data type and interface. data contains some information, class contains methods. data is about data (sorry for tautology) and class is about behavior. When you look at data type you don't see what you can do with it, instead you see what it stores. When you look at class you see what type should be able to do, you don't care what it stores internally. In real programming you actually care about details of implementations and how methods implemented using specific data. So instance just shows you relation between some data and some behavior — how this behavior implemented using given data.
In case you're interested more in model of type classes then read this blog post: http://www.haskellforall.com/2012/05/scrap-your-type-classes.html
You can look at instances as a values! It might blow your mind if you face such definition first time.
In some dependently type languages instances are really values that you can pass to other functions. Take a look at this question:
In Idris, is "Eq a" a type, and can I supply a value for it?
it seems like instances are types (like ShirtSize) which you
can apply type-class functions on (e.g the (==) function from MyEq)
Absolutely correct.
In Haskell a type is a defined structure of data. Every value that exists in Haskell code has a defined type. And a type can be made an instance of a class, which means... actually, hold that thought. I want to talk about functions.
Functions have type signatures, defining which type(s) they can be used on. If a function is defined to work on a particular type, then the function can be used on any value that has that type. If a function is defined to work on a particular class, then it can be used on any value of any of the types that are instances of that class.
When you define a class you describe some minimal set of functions (eg == in your example) which have to be implemented for all the types that want to be instances of that class. The class defines names and signatures for those functions, and that definition means those names and signatures are fixed. They will be the same for every instance of the class.
But the implementations aren't fixed by the class. They can be different for different types. We make a type into an instance of a class by writing an instance statement, in which we can define how those functions will work. If the class provides a default implementation of a function, then the different instance types can override the default and have their own definitions. And if there is no default, then the instance types must have their own definitions.
Now you have a minimal set of functions which can be called with any value of any of the types. And you can write more functions that work by calling those functions, and build up from there.
The idea is really useful, but IMHO the terminology is awful. Saying that these types are instances of a class makes it sound as if they're subtypes or child types, inheriting properties from parent types. But it's not like that at all. Being an instance of a class is like being a member of a club. Lots of different, unrelated types can all be instances of the same class. And one type can be an instance of lots of different unrelated classes, all at the same time.
In Rust, they have the same idea, but with the word 'trait' instead of 'class'. Instead of saying "this type is an instance of that class", they would say "this type implements that trait". I think that gets the idea across much better.
Apologies for any newbie errors - this is my first ever posting here.
I am not sure if this is a bug, or is the result of some subtlety in Alloy's typechecking. In the example below, I would expect the predicate "strange" to be inconsistent, because B and C are disjoint sets. However, Alloy (version 4.2) claims to find models of the predicate. The models it displays look wrong. For example, there is a model containing just one atom, B$0, labelled as the witness $strange_a. In this model, the Evaluator tells me that isB[B$0] is true, and isC[B$0] gives me a type error, as expected. However, strange[B$0] evaluates as true. The Alloy code I'm using is:
abstract sig A {}
sig B, C extends A {}
pred isB [b:B] { }
pred isC [c:C] { }
pred strange [a:A] {isB[a] and isC[a]}
run strange
You're right: it's surprising. Alloy's type checker uses the decls of predicates and functions to check their bodies but it does not impose them as constraints except when the predicate or function is run at the top level. We did this because we couldn't find a coherent semantics for these constraints in all usage contexts (for example, when a predicate is invoked inside a quantifier, or under negation).
Im UML newbie:)
I have abstract class X with methods A and method B (both with implementation). I have class Y with derives from class X.
I want to mark on UML diagram, that class Y constructor must run X.methodA, and Y.method3 must run X.methodB. How to put it on UML diagram?
It is possible to define in behavioral diagram. UML defines operation (behavioral feature) and behavior. Behavior can be connected to operation as a method. You should define owned behavior in class X, and then call it in behavioral diagram defined in class Y. I recommend you to read UML Superstructure document chapter Common Behavior. UML Web
I am developing a library exposing a potentially large number of Consumers, Producers and Effects (from Pipes). They use a ReaderT r ... as the inner monad.
Each component imposes some class constraint (ServerSettings r, FileSettings r, etc.). This is preferable over using concrete types as it propagates when composing components into Effects.
However, users of the library somehow need to create the concrete type, instantiating all required classes that component imposes for that type. This is tedious and might result in 2^(Number of classes) types.
What I want is some type function that for a set of classes, each with a concrete type that instantiates that class, create a type function that creates a composition of those types and instantiates all those classes.
At first glance, there obvious distinctions between the two kinds of "class". However, I believe there are more similarities:
Both have different kinds of constructors.
Both define a group of operations that could be applied to a particular type of data, in other words, they both define an Interface.
I can see that "class" is much more concise in Haskell and it's also more efficient. But, I have a feeling that, theoretically, "class" and "abstract class" are identical.
What's your opinion?
Er, not really, no.
For one thing, Haskell's type classes don't have constructors; data types do.
Also, a type class instance isn't really attached to the type it's defined for, it's more of a separate entity. You can import instances and data definitions separately, and usually it doesn't really make sense to think about "what class(es) does this piece of data belong to". Nor do functions in a type class have any special access to the data type an instance is defined for.
What a type class actually defines is a collection of identifiers that can be shared to do conceptually equivalent things (in some sense) to different data types, on an explicit per-type basis. This is why it's called ad-hoc polymorphism, in contrast to the standard parametric polymorphism that you get from regular type variables.
It's much, much closer to "overloaded functions" in some languages, where different functions are given the same name, and dispatch is done based on argument types (for some reason, other languages don't typically allow overloading based on return type, though this poses no problem for type classes).
Apart from the implementation differences, one major conceptual difference is regarding when the classes / type classes as declared.
If you create a new class, MyClass, in e.g. Java or C#, you need to specify all the interfaces it provides at the time you develop the class. Now, if you bundle your code up to a library, and provide it to a third party, they are limited by the interfaces you decided the class to have. If they want additional interfaces, they'd have to create a derived class, TheirDerivedClass. Unfortunately, your library might make copies or MyClass without knowledge of the derived class, and might return new instances through its interfaces thatt they'd then have to wrap. So, to really add new interfaces to the class, they'd have to add a whole new layer on top of your library. Not elegant, nor really practical either.
With type classes, you specify interfaces that a type provides separate from the type definition. If a third party library now contained YourType, I can just instantiate YourType to belong to the new interfaces (that you did not provide when you created the type) within my own code.
Thus, type classes allow the user of the type to be in control of what interfaces the type adheres to, while with 'normal' classes, the developer of the class is in control (and has to have the crystal ball needed to see all the possible things for what the user might want to use the class).
From: http://www.haskell.org/tutorial/classes.html
Before going on to further examples of the use of type classes, it is worth pointing out two other views of Haskell's type classes. The first is by analogy with object-oriented programming (OOP). In the following general statement about OOP, simply substituting type class for class, and type for object, yields a valid summary of Haskell's type class mechanism:
"Classes capture common sets of operations. A particular object may be an instance of a class, and will have a method corresponding to each operation. Classes may be arranged hierarchically, forming notions of superclasses and sub classes, and permitting inheritance of operations/methods. A default method may also be associated with an operation."
In contrast to OOP, it should be clear that types are not objects, and in particular there is no notion of an object's or type's internal mutable state. An advantage over some OOP languages is that methods in Haskell are completely type-safe: any attempt to apply a method to a value whose type is not in the required class will be detected at compile time instead of at runtime. In other words, methods are not "looked up" at runtime but are simply passed as higher-order functions.
This slideshow may help you understand the similarities and differences between OO abstract classes and Haskell type classes: Classes, Jim, But Not As We Know Them.