On Sep 8, 2006, at 6:58 AM, skaller wrote: > Installing it is an issue: Ocaml is easy to build and upgrade, > GHC isn't. However, we could find out by trying it, maybe > it isn't so bad.
The central problem with upgrading GHC is that a new major release (i.e., 6.4 to 6.5; not 6.4.1 to 6.4.3) invalidates the interface files (think of them as precompiled header files) so you need to recompile your entire library. Also, building it is relatively slower than OCaml. > It may seem strange, but many things work much faster > if one uses mutation. The inliner, for example, inlines > code in some ad hoc dependency order: if it couldn't > modify the instruction streams in place the algorithm would > be an order of magnitude slower. > > Almost all the 'slowness' in the compiler at the moment > is due to using functional techniques. Making functional programs fast requires careful design--and some knowledge of the compiler and runtime system, although this is less of a problem with OCaml. A good functional design is essentially streaming and quite fast (see the Shootout results for GHC on some problems--although these *are* contrived). The one place functional programming in general, Haskell in particular, falls completely flat is sorting: you essentially have to tear down and rebuild the entire structure. As for the inliner, I don't know if there is another way to write the same inliner algorithm so it could, say, insert inlined data in either a more ordered fashion or perform the "inlining" as part of the output process--i.e., stream everything together. Depending on the structure used for representing the text, inlining could be very easy in a functional setting. I know similar things have been done. >>> Typeclasses identify the notion of 'kind' with 'typeclass' the >>> same way run time OO identifies the notion of 'type' with 'class'. >> >> That is actually well put but I'm not sure what you mean by 'kind'. > >> In Haskell, 'kinds' are the type of types, > > Yes. > >> for example the type of >> Int is *, > > In Felix the type of int is TYPE. > >> that is (Int :: *); constructors have type (* -> *)-- > > Functions have type TYPE too, all types have type TYPE. > > Simple type functions, on the other hand, have type TYPE -> TYPE. > For example: > > typedef fun f(x:TYPE):TYPE=>x * x; > > has type > > TYPE -> TYPE > > A variant constructor has type TYPE because it is just a function: > > union Person = | Me of int | You of int > Me: int -> Person > >> data NewInt = N Int >> -- (Int :: *), (N :: Int -> NewInt), (NewInt :: Int) >> where Int may be characterised as a 'kind', the distinction between >> 'kinds' and 'types' is gone as of GHC 6.6 and the System F type >> system: they are the same thing (to the intermediate-language type >> system, see http://hackage.haskell.org/trac/ghc/wiki/ >> IntermediateTypes). > > This is desirable. In Felix the type of TYPE would be > > METATYPE > > and the type of that would be > > METAMETATYPE > > so there's be an infinite regress of kinds. I'd like to get > rid of that. > >> Subclassing type classes is a bit different than deriving functors or >> C++ classes. > > I know. But the same problem exists. When you subclass a typeclass > you're adding constraints: That was my central point: there are no 'constraints' as such. All type classes do is allow functions defined within the type class to be functionally polymorphic over types defined as an instance of that class. >> class Eq a => Ord a where > > So you still have the covariance problem, but I can't > write you an example until after at least 3 more cups of coffee :) As I understand it, the 'covariance' problem comes up when you have the inheriting methods or types may override methods of superclass they inherit from. This is not a problem with type classes because you cannot override the rules inherited from the class. Here is an example with Ord: data Ordering = | LT | EQ | GT class Eq a => Ord a where compare :: a -> a -> Ordering (<), (<=), (>=), (>) :: a -> a -> Bool max, min :: a -> a -- the type class Ord does not redefine or override the Eq 'laws' (==) and (/=), but it may use those laws in its own definitions: compare x y | x == y = EQ | x <= y = LT | otherwise = GT > Eq and Ord are 'subkinds' of *, it's a subset of the types of > all the types, which admit equality and ordering, respectively. They are not "subkinds," they are simply any kind ( 'a' roughly equals *), for which certain function signatures have been defined; there is no effect on the nature of the underlying type except restrictions over which functions may be applied. > The subkinding relation written => above is similar to > inheritance. Only in the same sense of inheritance of Sets: the inheritance becomes (if MyType is an instance of Ord then MyType is an instance of Eq). > It also looks like 'Eq' is nominally kinded, which is quite bad. The "nominally" kinded is really an existential kind for the purpose of defining the 'laws' in the functions; the relation becomes more concrete when making a type an instance of the class--which to a programmer really means (1) the class functions polymorphically operate over that type and especially (2) the type conforms to the laws defined by that class. For a textbook example: data Tree a = | Leaf a | Branch (Tree a) (Tree a) instance Ord a => Ord (Tree a) where Leaf _ < Branch _ _ = True Leaf a < Leaf b = a < b Branch _ _ < Leaf = False ... > For example in Felix, I would like to use 'typeclass' kind > of stuff to handle arithmetic and STL iterators. You would define STL iterator traits as functional 'laws,' with the caveat that the system would not define a set of iterator 'types,' but for your iterator-type the defined operations would hold. class WriteableIterator a where -- *p= write :: a -> b class ForwardIteratableIterator a where -- ++ incr :: a -> a Note that you could *not* define a base type class of IteratorTraits and then proceed select out the functions you wanted to define: --WRONG class IteratorTraits a where read :: a -> b access :: a -> b write :: a -> b iterate :: a -> a --comparison would be defined as an instance of Ord. You *could* define only certain instances of the class, but this would be incomplete and shoddy: instance IteratorTraits a => OutputIterator a where write :: a -> b iterate :: a -> a Why would it be shoddy? Because as a matter of defining unconditional policy someone else could, say, take my instance and add the rest of the IteratorTraits functions; nor would an OutputIterator instance indicate that a type conforming to it had any additional properties not already present in the IteratorTraits set. It would be better to define several different type classes and join them together for a particular type: --add to the rest of the IteratorTraits (in addition to , above class ReadIterator a where read :: a -> b class AccessIterator a where access :: a -> b class BackwardIteratableIterator a where decr :: a -> a Then, for a particular iterator: class OutputIterator a => (WriteableIterator a, ForwardIteratableIterator a) where ... > But an example of the issue is: we have 'widening conversions' > like int->long and float->double, and also widening arithmentic > like int * long -> long (C rules). Since Felix is defining these types as an abstraction for language you would probably classify them as available conversions. (This would be best if you defined it while allowing errors, the Maybe type.) To get into this example well would require a bit more Haskell-training, so I'll leave it for later, but this sort of thing has already been done as part of the "type casting" used in Generics. It isn't impossible and it is not as limited as you might think. -Pete ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
