We have had a number of separate threads discussion end up on so i thought
i would create a dedicated one . Anyway just throwing some ideas up with my
limited understanding so far as i would love to see something elegant
develop here.
Firstly I dont think Type-class as a relation between types is the correct
definition for things like Ord or Eq while you could bang them in that box
, since they list what a type must implement to be a member these seem more
like a abstract base class or an interface for the type.
I think if you look at a function like
where Col('a)
def is_empty ( x: 'a) = {
return count(x) == 0
}
to me this would look more natural , concise and easier to learn as
def is_empty ( x: Col ) = {
return x.count == 0
}
ie Similar to interfaces , base and abstract classes. In addition it works
well with structure functions/ methods and looks natural and easier for the
C/C++/Java/C# etc programmer . To them it would look just like multiple
inheritance ( though it behaves differently).
Conversely where there is a type class relationship between two types the
following functions looks and feels unnatural though it is technically
correct ( the type class definition feels ok) , (note this is not real
/checked code as i have few examples of a relationship yet)
where Ord('a) , ArrayList('b , 'a)
def first ( x: 'b) -> 'a = {
return 'b.internal[0]
}
maybe a relationship would be better ( though technically incorrect) like
this
def first ( 'b:ArrayList) -> 'a:Ord = {
return 'b.internal[0]
}
or more flexibly and better yet
def do_something('b) = {
return 'b.relationshipTypeClassName.field_or_method_on type class
}
Here the compiler can infer everything that is needed and the dot notation
is natural for DB table relationships in many tools/languages though
a separate symbol could be used. The second method also has the advantage
that we only allow type class as types when they are like an abstract base
class type .
The main thing here is type classes stay relationships but maybe type
classes which are "relationships" on a single type become something else (
but use the same or simpler notation) . Maybe the trait keywords becomes
abstract and relationship . ( or trait and relationship)
I believe the above suggestion though completely syntactic sugar would make
it easier (for non experienced Haskell) devs to use type class and
understand them meaning they get used more and would lessen the learning
curve.
Hope my 2c worth is not too confusing / off the track.
Ben.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
