[Haskell-cafe] type gurus, can you please help?
Hello haskell, i'm started to write article about type classes. can you, type gurus, please check this initial text for correctness in explaining differences between classes and type classes? at this moment C++/C#/Java languages has classes and templates/generics. what is a difference? with a class, type information carried with object itself while with templates it's outside of object and is part of the whole operation for example, if == operation is defined in a class, the actual procedure called for a==b may depend on run-time type of 'a' but if it is defined in template, actual procedure depends only on template instantiated (and determined at compile time) Haskell's objects don't carry run-time type information. instead, class constraint for polymorphic operation passed in form of dictionary implementing all operations of the class (there are also other implementation techniques, but this don't matter). For example, eqList :: (Eq a) = [a] - [a] - Bool translated into: type eqDictionary a = (a-a-Bool, a-a-Bool) eqList :: eqDictionary a - [a] - [a] - Bool where first parameter is dictionary containing implementation of == and /= operations for objects of type 'a'. If there are several class constraints, dictionary for each is passed. If class has base class(es), the dictionary tuple also includes tuples of base classes dictionaries: class Eq a = Cmp a where cmp :: a - a - Comparision cmpList :: (Cmp a) = [a] - [a] - Comparision turns into: type cmpDictionary a = (eqDictionary a, a - a - Comparision) cmpList :: cmpDictionary a - [a] - [a] - Bool Comparing to C++, this is like the templates, not classes! As with templates, typing information is part of operation, not object! But while C++ templates are really form of macro-processing (like Template Haskell) and at last end generates non-polymorphic code, Haskell's using of dictionaries allows run-time polymorphism (explanation of run-time polymorphism?). Moreover, Haskell type classes supports inheritance. Run-time polymorphism together with inheritance are often seen as OOP distinctive points, so during long time i considered type classes as a form of OOP implementation. but that's wrong! Haskell type classes build on different basis, so they are like C++ templates with added inheritance and run-time polymorphism! And this means that usage of type classes is different from using classes, with its own strong and weak points. -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
[...] Basically I interpret a symbol in a syntax-tree which can belong to different type-classes. [...] I meant, to different types of the same type-class. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
I had a feeling this was discussed in Typing Haskell in Haskell by Mark Jones, but after a quick skim I can't find it again (I thought it would be in Section 11.6 of his paper). It is, on page 35 (section 11.6.3) of Typing Haskell in Haskell by Mark Jones. Gerrit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
Gerrit van den Geest wrote: I had a feeling this was discussed in Typing Haskell in Haskell by Mark Jones, but after a quick skim I can't find it again (I thought it would be in Section 11.6 of his paper). It is, on page 35 (section 11.6.3) of Typing Haskell in Haskell by Mark Jones. Quote: This is a consequence of a throw-away comment specifying that all explicit type signatures in a binding group must have the same context up to renaming of variables. This is a syntactic restriction that can easily be checked prior to type checking. Our comment here, however, suggest that it is unnecessarily restrictive. I agree with Mark Jones, the Haskell compiler Helium for example doesn't have this restriction. I think this issue is also related to the following Haskell' ticket: http://hackage.haskell.org/trac/haskell-prime/ticket/65 Gerrit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
Tim Walkenhorst wrote: I had a feeling this was discussed in Typing Haskell in Haskell by Mark Jones, but after a quick skim I can't find it again (I thought it would be in Section 11.6 of his paper). It is, on page 35 (section 11.6.3) of Typing Haskell in Haskell by Mark Jones. Now you got me hooked. Where can I find his paper? The link in the Haskell-wiki[1] seems to be dead... I don't know, I've encountered the same problems. Fortunately I have a printed version on my desk. Gerrit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
On Aug 14, 2006, at 4:52 PM, Gerrit van den Geest wrote: Tim Walkenhorst wrote: I had a feeling this was discussed in Typing Haskell in Haskell by Mark Jones, but after a quick skim I can't find it again (I thought it would be in Section 11.6 of his paper). It is, on page 35 (section 11.6.3) of Typing Haskell in Haskell by Mark Jones. Now you got me hooked. Where can I find his paper? The link in the Haskell-wiki[1] seems to be dead... I don't know, I've encountered the same problems. Fortunately I have a printed version on my desk. Gerrit It can be found here: http://citeseer.ist.psu.edu/424440.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
It can be found here: http://citeseer.ist.psu.edu/424440.html Thanks! Actually I've seen this page before, but was too retarded to figure that you can access the actual document there. I thought it was just an abstract... (*embarrassed*) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Local functional dependencies: solving show . read and XML generation problems
Sorry for a late reply, I'm out of town.
As I understand it, the problem is as follows: we'd like to construct
different realizations of XML documents from data of different
types. We wish to write
p (p foo)
and specify the desired type of the XML document, like
(p (p foo)) :: XMLTree
or
(p (p foo)) :: IO () -- for writing out the XML document
etc.
The function 'p' obviously has to be overloaded with the
type |p :: a - xml|. However, |p (p foo)| exhibits the `show . read'
problem. What should be the result type of the internal `p'?
Functional dependencies help resolve the ambiguity; alas, we can't
assert any dependency here. We should be able to use Strings
with XML documents of different types, so we can't assert the argument
of 'p' determines the result. Also, XML documents of the same type can
be created from children of different types. We indeed have the
`show . read' problem.
Fortunately, there is a solution that does not involve proxies or
type annotations. We use a `syntactic hint' to tell the typechecker
which intermediate type we want. To be more precise, we assert local
functional dependencies. Thus we can write:
p c = build p [embed c]
test1 :: XML
test1 = p [[p [[p foo
Our syntactic crutch is the list notation: [[x]]. We could have used a
single pair of brackets, but we'd like to avoid overlapping
instances (as is done in the following self-contained code).
{-# OPTIONS_GHC -fglasgow-exts #-}
{-# OPTIONS_GHC -fallow-undecidable-instances #-}
module GenXML where
data XML = Element String [XML] | CDATA String deriving Show
class Build child xml | xml - child where
build :: String - [child] - xml
instance Build XML XML where
build = Element
-- This type class has no functional dependency
class Embed a child where
embed :: a - child
instance Embed String XML where
embed = CDATA
-- This instance exhibits the functional dependency child - a
instance TypeCast a XML = Embed [[a]] XML where
embed [[x]] = typeCast x
p c = build p [embed c]
test1 :: XML
test1 = p [[p [[p foo
-- Our silver bullet
class TypeCast a b | a - b, b-a where typeCast :: a - b
class TypeCast' t a b | t a - b, t b - a where typeCast' :: t-a-b
class TypeCast'' t a b | t a - b, t b - a where typeCast'' :: t-a-b
instance TypeCast' () a b = TypeCast a b where typeCast x = typeCast' () x
instance TypeCast'' t a b = TypeCast' t a b where typeCast' = typeCast''
instance TypeCast'' () a a where typeCast'' _ x = x
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
Google Scholar is often quite handy for this sort of situation. http://scholar.google.com/scholar?q=typing-haskell-in-haskell+jones Jared. On 8/14/06, Tim Walkenhorst [EMAIL PROTECTED] wrote: It can be found here: http://citeseer.ist.psu.edu/424440.html Thanks! Actually I've seen this page before, but was too retarded to figure that you can access the actual document there. I thought it was just an abstract... (*embarrassed*) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Exotic Languages Are Not Mainstream
Hello Shae, Monday, August 14, 2006, 1:11:49 AM, you wrote: - lack of specialists (and this means lack of teaching, training, books) There's lots of interactive teaching and training on #haskell What exactly do you think is missing? high school. while some advanced universities teach FP to students. most high schools just teach C++ or smth like this. at least, here in Russia students learn things that business was used 10 years ago while they should learn things that business will use 10 years later (and form this business environment!) skill raising courses. in my town, there are courses for Delphi, C++, at Moscow there are courses for Java, C#, perl, php. again, rare languages are out of luck books. there are tons of books that teach c++, from C++ for dummies up to Using booost::lambda to create 24/7 apps and no more than dozen for entire Haskell with all its extensions/libs. it's not enough to learn Haskell in deep - lack of variety of libraries (application programmers want to have many libraries pre-written) Which libraries do you think are most needed? gui+db for standalone apps, i don't know exact requirements for web apps also plenty of libs that is used in any program: data structures, string processing, regexps, networking, concurrency, so on, so on imvho, these issues are less important for system programming (such as creating of web server or CMS system), so Haskell, with all its features, now is a great tool for system programming. for example, i've written zip-like tool with ghc FreeArc is way nifty! thank you :) i thought that it is interesting only for Russian-speaking haskellers because all comments are in Russian even for this quite enough system program i required the following libraries: ByteString, Binary, filename manipulation and matching, string processing, advanced I/O. most of these was done at the moment when i wrote my code, but was not readily available, concealing itself in labyrinths of ghc, darcs and other apps :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Re: Why Haskell?
Hello Johan, Monday, August 7, 2006, 7:25:47 PM, you wrote: (sorry for too late answer) http, smtp and other networking protocols - yes. xml/sql is too large things. actually, haxml package is already included in GHC sources distribution and i think that it should be excluded from there because it's too large, far more than any other package bundled with GHC The problem I'm having with SQL right now is that there are a number of not complete and splintered implementation efforts. Having one library outside GHCs libraries but still promoted as the default implementation (and hosted under haskell.org) would be enough. that is because there many developers what had different vision. you can't force them to work together. all that we can do is to declare one library as standard one so that the developers who want to contribute to some DB library will work on improving this concrete lib moreover, competition is the only source of progress, so having several competing libs might be better actually than having one ultimate one Same for XML. I think most of my problems would be solved if cabal-get turned out to something like Ruby Gems so I could easily pull the packages I need to the machines I need (and also get dependencies and a way to remove the packages without leaving files scattered on my file system). one of Google SoC projects is to implement this cabal-get at last end. i hope that situation will change during a next month (when a summer will end :) ) returning to the question discussed by me - i'm all for having better libs and make some of them standard. but i'm against distributing with GHC any libs that is larger than base lib. to be exact, i want that all multimedia/gui/xml libs will be excluded from ghc, including opengl-based, fgl, openal, object-io, haxml -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Compiling To C And Why Not Compiling To Java Or C#?
Hello Kaveh, Sunday, August 6, 2006, 5:40:26 PM, you wrote: I think we need a subset of haskell as a new language (or as a developing pattern) to work with and teach and learn more easily as you have mentioned. it called Helium :) but in general problem is what Haskell's way to deal with problems is to find most general and abstract solution, such as enclosing monads just for doing I/O. it's great for programmers interesting in raising their programming languages knowledge (i usually study several new languages each year, so Haskell with all its extensions partially replaces my need in new interesting languages ;) ) but can be nightmare for 99% of programmers. after all, they need to learn many many other things besides of language tricks interesting for souls like me I had read a text about mathematics which was something like this : New mathematic theories does not populize because of their fabiolus logical theorems, but because of death of elder mathematicians and forging a new folk of them that were rised by new theories.. that's true for any science (recall for example Freud's story) and moreover for any ideology (Moses drived Hebrews over the desert for 40 years just in order that Jews that born in slavery was died) That is usefull to have in mind. (And because of that, maybe there is no force to compele someone to disturbe his mind on a peacfull friday afternoon! ;) ) Anyway the point is developing more efficient and easily; instead of serving marketing features of languages. that is entirely different question. while Haskell is rare bird, _i_ can't use it in commercial environment. as one manager said i can easily find 10 C++ programmers. but where i will find 3 Haskell developers? ;) And there must be - and will be - someone (or some will) to makes things better. very high level of FP in Haskell is good but there is no lower level of them somewhere else. So almost the only choice for a useful FP environment is Haskell. if i correctly understood that you mean, there is Ocaml and FP features in many languages. most important things, imho, are anonymous closures and 1st-class functions. even current C# should support this -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Exotic Languages Are Not Mainstream
On 11/08/06, Clifford Beshers [EMAIL PROTECTED] wrote: I've been avoiding that, because there are too many things I'm tempted to fiddle with inside it. But you've talked me into it. See also the really simple Hoogle/Emacs integration: http://haskell.org/haskellwiki/Hoogle#Using_Hoogle_from_Emacs -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Haskell?
Bulat Ziganshin [EMAIL PROTECTED] writes: The problem I'm having with SQL right now is that there are a number of not complete and splintered implementation efforts. Having one library outside GHCs libraries but still promoted as the default implementation (and hosted under haskell.org) would be enough. that is because there many developers what had different vision. you can't force them to work together. all that we can do is to declare one library as standard one While having a single standardised library is a nice goal, I think a first step would be to highlight the current state and pros and cons of the various options. Perhaps we could at least have wiki pages with recommendations? So that a potential user of some particular functionality - whether it is database accesss, GUI, XML, web application development, and so on - can make an as informed decision as possible? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Where is Typing Haskell in Haskell?
Hi Mark, Cc Haskell-café, It seems the OGI links for THIH have gone dead. Is there any preferred download location for THIH these days? I couldnt spot anything. Thanks, Ralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
