Suppose I have an unvalidated XSD input (B) that claims to be a subset of another XSD (A). The subsets are handled via xs:redefine via restriction. Now schema validators will throw errors if types under xs:redefine are incorrectly derived. However, AFAIK there is not a way to assert B ⊆ A, which is a problem if B never references A, B simply extends A, or defines any of its own elements (in my use case its ok for B to define subtypes via restriction from types in A).
Is there a way to mechanically determine if a profile is a subset of another?
Related
I want to exchange data with some remote system (can be via HTTP, a database, files, etc.), and therefore create data transfer objects (DTOs) - basically, records that can be serialised and deserialised easily. In a second step, I want to map these DTOs to my domain objects.
All DTOs have an ID field (e.g., a technical primary key, a message identifier, or a file name). Because this is a general pattern, I try to capture it in a general type. This is my first attempt:
data DtoShell = DtoShell
{ id :: UUID
, dto :: Dto}
data Dto
= MyDto1 ConcreteDto1
| MyDto2 ConcreteDto2
| ...
In this way, functions that are concerned with handling arbitrary DTOs, and therefore only need the ID, can deal with the DtoShellonly but do not need to care about the actual data inside. Functions that are particular to a specific DTO can work with that. In between, there must be some "dispatcher" function that pattern-matches on the concrete type and selects the appropriate function - for example, to map a concrete DTO to its corresponding domain type.
However, this scheme is hard to extend - if there ever is a new ConcreteDto3, I need to change the above code, and I need to change the "dispatcher" function.
I do see that this seems to be a representation of some more fundamental problem (the expression problem? I am not a CS major...). In my search, I came across potential solutions: Phantom types, existential types, and, foremost, typeclasses. But I am not yet proficient enough in Haskell and general abstract CS to value the pros and cons of each approach. Thus, I have two questions:
Is there a general, accepted practice or pattern how to model such "identifiable records"? E.g., when accessing relational databases.
Is there a single resource (book, paper, tutorial) that compares the different approaches to data abstraction?
Why not just create a parametrically polymorphic envelope?
data Envelope a = Envelope { eid :: UUID, edata :: a } deriving (Eq, Show, Functor)
This is basically just a specialised pair (two-tuple), so you make it an instance of all the type classes that (,) is an instance of. Here I've made it a Functor instance by using the DeriveFunctor language extension.
I have a typeclass with an associated type:
class Foo a where
type Bar a :: *
...
Now, I'd like to instance this class for a compound type containing existentially quantified type variables:
data Blat = forall a. Blat a
instance Foo Blat where
type Bar Blat = ???
In my actual application, the "???" needs to make use of the existentially hidden "a" in Blat a, in order for the program logic to be correct.
Is this doable in Haskell?
If so, how?
===
In response to #leftaroundabout 's request for full disclosure of my original intent:
I'm trying to build representations of types, using only a small set of "primitives" (i.e. - unit, sum, and product).
And, for compound types, I'd like to enlist the help of the pre-existing representation instances for the fields making up the new type.
For explicitly parameterized field types this is straightforward.
However, I'd like to be able to do it for field types using existentially hidden type parameters, also.
It can't be done. An existentially quantified type is only chosen at runtime, whereas a type family instantiation (associated or otherwise) must be fixed at compile time.
This is probably an XY problem. Instead of an associated type family, you should deal with the type information in some other way, but it would require knowledge of the problem you're trying to solve to say how.
I saw that, in the book, Programming Language Design Concepts by John Wiley, 2004, there is a definition for bindables:
"A bindable entity is one that may be bound to an identifier.
Programming languages vary in the kinds of entity that are bindable:
• C’s bindable entities are types, variables, and function procedures.
• JAVA’s bindable entities are values, local variables, instance and
class variables, methods, classes, and packages.
• ADA’s bindable entities include types, values, variables,
procedures, exceptions, packages, and tasks."
I'm curious, which bindable entities are in Haskell?
Haskell has three namespaces, one each for runtime computations, types, and modules.
Any term representing a runtime computation may be named in the computation namespace. data and newtype declarations create new names in the computation namespace for constructing values of their new type and, if record syntax is used, for selecting fields from the new type. class declarations create new names in the computation namespace for their methods.
Any monomorphic type may be named in the type namespace with a type declaration (see comments below for my predictions on confusing subtleties in this statement). data and newtype declarations create new names in the type namespace for constructing the type they declare. class declarations create new names in the type namespace for the constraint they create.
module declarations create new names in the module namespace.
GHC extends Haskell, adding a variety of new ways to bind names (almost all in the type namespace); a comprehensive list is probably too large for this format but the manual is excellent and covers them all.
Now, to the subtleties of type. One confusion that I predict will arise is this: I say only monomorphic types may be named. But one may object that I can certainly write, e.g.
type TypeOfIdMono a = a -> a
id :: TypeOfIdMono a
and that looks like it has named a polymorphic type. I claim that Haskell's penchant for making foralls implicit has instead confused the issue, and that TypeOfId a is in fact monomorphic. With explicit foralls, this has been written:
type TypeOfIdMono a = a -> a
id :: forall a. TypeOfIdMono a
That is: we have not actually named id's type here, but rather the type of a monomorphic function which only operates on as. id says additionally that the caller gets to choose a -- that is, that the function is polymorphic. Compare this declaration, which is not allowed in standard Haskell (though is available via GHC extensions, as alluded to above):
type TypeOfIdPoly = forall a. a -> a
id :: TypeOfIdPoly
Here we really have named a polymorphic type.
In short: one can and should distinguish between three orthogonal concepts: "parameterized types" (e.g. TypeOfIdMono which expects an additional argument), types which mention a type variable (e.g. TypeOfIdMono a), and polymorphic types (e.g. TypeOfIdPoly) which necessarily have a forall.
I am trying to understand type classes in Haskell.
I pose the question using a simple example:
Lets consider two datatypes, A and B.
Lets also assume that a1 and a2 are of type A and b1 and b2 are of type B.
Now let's assume that we want to define functions to check if a1 equals a2 and whether b1 is the same as b2.
For this we have two options:
Option 1:
Define two equality functions using separate names like this :
eqA :: A -> A -> Bool
eqA = ...
eqB :: B -> B -> Bool
eqB = ...
Now if we want to check if a1 equals a2 then we write : eqA a1 a2, similarly for B : eqB b1 b2.
Option 2:
We make A and B instances of the Eq typeclass.
In this case we can use the == sign for checking for equality as follows.
a1==a2
b1==b2
So, now the question : as far as I understand the sole purpose of the existence of type classes is that we can reuse the function name == for the equivalence checking function, as shown in Option 2. So if we use type classes we do not have to use different function names for essentially the same purpose ( i.e. checking for equality).
Is that correct? Is name reuse the only advantage that type classes give? Or is there something more to type classes ?
In other words, given any program using type classes, I could rewrite that program to an isomorphic program that does not use type classes by giving separate names (i.e. eqA and eqB) to the overloaded function names (i.e. == in Option 2) that are defined in the type class instance declarations.
In the simple example this transformation would replace Option 2 with Option 1.
Is such a mechanic transformation always possible?
Is that not what the compiler is doing behind the scenes?
Thank you for reading.
EDIT:
Thanks for all the illuminating answers !
There is this very good article regarding type class which shows their desugaring process: https://www.fpcomplete.com/user/jfischoff/instances-and-dictionaries
So, yes, you could do without them, but you will need to have a different function for each type as you did in your question, or you will need to pass the instance dictionary explicitly as described in the article, while the type class do it implicitly so you don't need to bother. In many cases, you would end up with a LOT of functions with different names!
Nevertheless, your question leads also to the fact that type classes are often too much used when other patterns would solve the problem as well:
http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/
Type classes are syntax sugar, so there is nothing that you cannot do without them. It is just a question of how hard it would be to do without them.
My favorite example is QuickCheck, which uses type classes to recurse over function arguments. (Yes, you can do that.) QuickCheck takes a function with an arbitrary number of arguments, and auto-generates random test data for each argument, and checks that the function always returns true. It uses type classes to figure out how to "randomly" generate data of each individual type. And it uses clever type class tricks to support functions with any number of arguments.
You don't need this; you could have a test1 function, and then a test2 function, and then a test3 function, etc. But it's nice to be able to have just "one function" which automatically figures out how many arguments there are. Indeed, without type classes you'd end up having to write something like
test_Int
test_Double
test_Char
test_Int_Int
test_Int_Double
test_Int_Char
test_Double_Int
test_Double_Double
test_Double_Char
...
...for every possible combination of inputs. And that would just be really annoying. (And good luck trying to extend it within your own code.)
Really, type classes make your code more high-level and declarative. It makes it easier to see what the code is trying to do. (Most of the time.) There are really advanced cases where I start to think maybe the design isn't quite right, but for the vast majority of stuff, type classes work really well.
For the most part the answer is that type classes give you name re-use. Sometimes the amount of name re-use you get is more than you might think.
A Type Class is somewhat similar to an Interface in Object Oriented languages. Occasionally someone might ask "is the only purpose of an Interface to enforce contracts in APIs?". We might see this code in java
public <A> void foo (List<A> list) {
list.clear();
}
List<A> list = new ArrayList<>();
List<A> list2 = new LinkedList<>();
foo(list);
foo(list2);
Both ArrayList and LinkedList implement the List interface. As such, we can write a general function that foo which operates on any List. This is similar to your Eq example. In Haskell we have many higher order functions like this. For example foldl can be implemented by more than just lists, and we can use foldl on anything that uses Foldable from Data.Foldable.
In OO you can use generics to do some really interesting abstractions and inheritance (e.g. in Java things like Foo<A extends Foo<A>>). In Haskell we can use Type Classes to do different types of abstractions.
Let's take the Monad class, which requires you to implement "return". Maybe implements return something like this:
instance Monad Maybe where
return a = Just a
Whilst List implements return like this:
instance Monad [] where
return a = [a]
Return, as it is done in Haskell, is not possible in a language like Java. In Java if you want to create a new instance of something in a container (say a new List<String>) you have to use new ArrayList<String>();. You can't create an instance of something because it fulfills a contract. While in Haskell we can write this code which would not be possible in Java:
foobar :: (Monad m) => (m a -> m b) -> a -> m b
foobar g a = g $ return a
Now I can pass anything to foobar. I could pass a function Maybe a -> Maybe b or [a] -> [b] and foobar will still accept.
Now of course this could all be broken down and functions could be written one by one. Just like Java could ignore interfaces and implement everything from scratch on each class of List. But just like the inheritance that's possible in OO once you factor in generics, in Haskell we can do some interesting things in Type Classes using language extensions. For example, check out http://www.haskell.org/haskellwiki/Functional_dependencies_vs._type_families
I am confused about using Functor
is Functor used for defining properties of mapping and how to write a mapping's properties in Haskell?
if so, can haskell be used to generate function or other things after definition written
Malformed head of type or class declaration: flow x y
import Control.Applicative
class flow x y where { f :: x y -> x; } // this line i do not know whether is enforced to write
// how to write this map
instance flow Int Int where
flow t flow(s, p) = flow(t+s, p)
flow 0 p = p
if there are more runnable example rather than the definition of the haskell, it would be better
when i replace properties in example found in google, usually can not run, or fragments
when use example about mapping, for example A -> B, there are data A data B defined first, but do not know why use data as a type defined, when i read category theory, there are arrows and objects
both are Hom, Functor is from Hom to Hom, does it mean data represent Hom?
When compare with software Singular, i become more confusing. Hom is a operation of kontraHom and Kohom and take two matrix.
Do Hom have different meaning in Haskell and Singular
Singular is a computer algebra system. Haskell is a programming language which computer algebra can be implemented within. You need to start simply and just learn basic Haskell syntax and concepts before trying to see the categorical/algebriac picture, especially since different elements can be implemented in different ways.
But let's try something simple to establish a common language. The notes I give here should be consistent with the treatment here: http://en.wikibooks.org/wiki/Haskell/Category_theory
One approach is to describe the category Hask. The objects of Hask are all Haskell types. Hask contains function types, as well as pairs, so it is cartesian closed, and all its arrows are isomorphic to objects. In categorical terms, a hom-set is the collection of all morphisms between two objects. So the hom-set on (Int,Float) is the collection of all functions that turn an Int into a Float.
Categorically, a functor between categories X and Y sends the objects of X to Y and the arrows of X to Y. It also therefore sends the hom-sets (collections of arrows) of X to Y.
The class Functor in Haskell provides part of what you get with a categorical functor. It provides an operation fmap that sends arrows on objects in Hask to arrows on some other category (which, in our case, must also be composed of some objects from Hask). It can send functions on values to functions on lists of values, or functions on values to functions on pairs which contain values, etc.
All that said, I would recommend learning Haskell without thinking about writing type classes or instances at all for some time. Stick to explicit data declarations and functions until you're more comfortable with the basic features of the language.
As an attempt at addressing the immediate confusion, a Haskell Functor defines a structure you can 'map' over, by specifying an implementation of 'fmap' (so yes, in Haskell you could use an instance of the Functor type class in order to specify an implementation of fmap for your specific structure)
Your provided code is problematic in two ways: i) A functor is already provided by Haskell (no need to redefine the class; instead you want to define an 'instance' of the Functor class), and ii) you need to adhere to the Functor interface.
Though I may suggest a more comprehensive resource (highly recommended is the book "Real World Haskell"), if you absolutely need to know more about how to deal with Haskell's instantiation of Functors, an excellent article is http://www.haskell.org/haskellwiki/Monads_as_containers
(every Monad is a Functor).