[Haskell-cafe] Haskell's type system compared to CLOS
Hi, usually I'm sceptical of programming languages which are not based on the von Neumann architecture, but recently I got interested in functional programming languages. The arrogance of lots of Haskell users, who made me feel that using a programming language other than Haskell is a waste of time, combined with vanguard mathematical notation has been very attractive to me and I have decided to get at least an idea of Haskell and its concepts. Some weeks ago I learned programming in Dylan and was impressed by its object system which is basically a stripped version of CLOS. Multiple dispatch together with a well-thought-out object system is quite powerful, because it removes the burden of including methods in the class definition. At the moment I'm reading the Functional Programming using Standard ML and I'm in the chapter on data types. This afternoon it occurred to me that classes and data types are symmetric. In a class hierarchy you start an abstract super class (the most abstract is the class object in some languages) and further specialise them via inheritance; with data types you can start with specialized versions and abstract them via constructors (I'm not sure how message sending to a superclass looks like in this analogy). Anyhow, I also came across an interesting presentation. Andreas Löh and Ralf Hinze state in their presentation Open data types and open functions [1]: * OO languages support extension of data, but not of functionality. * FP languages support extension of functionality, but not of data. Their first point refers to the fact that in most object-oriented languages don't allow the separate definition of classes and their respective methods. So to add new functions, you have edit the class definitions. However, in functional programming languages you can easily add new functionality via pattern matching, but have to either introduce new types or new constructors, which again means to modify existing code. In Dylan (and in Common Lisp) you define methods separate from classes and have pattern matching based on types. This solves all mentioned problems. So my question is, how are algebraic data types in Haskell superior to CLOS (despite the fact that CLOS is impure)? How do both compare? What has Haskell to provide what Common Lisp and Dylan haven't? Thanks! Regards, Matthias-Christian [1] http://people.cs.uu.nl/andres/open-japan.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's type system compared to CLOS
Matthias-Christian Ott wrote: Hi, usually I'm sceptical of programming languages which are not based on the von Neumann architecture, but recently I got interested in functional programming languages. The arrogance of lots of Haskell users, who made me feel that using a programming language other than Haskell is a waste of time, combined with vanguard mathematical notation has been very attractive to me and I have decided to get at least an idea of Haskell and its concepts. Some weeks ago I learned programming in Dylan and was impressed by its object system which is basically a stripped version of CLOS. Multiple dispatch together with a well-thought-out object system is quite powerful, because it removes the burden of including methods in the class definition. At the moment I'm reading the Functional Programming using Standard ML and I'm in the chapter on data types. This afternoon it occurred to me that classes and data types are symmetric. In a class hierarchy you start an abstract super class (the most abstract is the class object in some languages) and further specialise them via inheritance; with data types you can start with specialized versions and abstract them via constructors (I'm not sure how message sending to a superclass looks like in this analogy). Anyhow, I also came across an interesting presentation. Andreas Löh and Ralf Hinze state in their presentation Open data types and open functions [1]: * OO languages support extension of data, but not of functionality. * FP languages support extension of functionality, but not of data. Their first point refers to the fact that in most object-oriented languages don't allow the separate definition of classes and their respective methods. So to add new functions, you have edit the class definitions. However, in functional programming languages you can easily add new functionality via pattern matching, but have to either introduce new types or new constructors, which again means to modify existing code. In Dylan (and in Common Lisp) you define methods separate from classes and have pattern matching based on types. This solves all mentioned problems. So my question is, how are algebraic data types in Haskell superior to CLOS (despite the fact that CLOS is impure)? How do both compare? What has Haskell to provide what Common Lisp and Dylan haven't? Thanks! Regards, Matthias-Christian Type classes. Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's type system compared to CLOS
On Tue, Aug 11, 2009 at 11:20:02PM +0100, Philippa Cowderoy wrote: Matthias-Christian Ott wrote: What has Haskell to provide what Common Lisp and Dylan haven't? Static typing (with inference). Very large difference, that. That's true. This is a big advantage when compiling programmes. But as far as I know type inference is not always decidable in Haskell. Am I right? Dylan does type inference too and Hannes Mehnert is currently working on better type inference for the dylan compiler [1]. Regards, Matthias-Christian [1] https://berlin.ccc.de/wiki/Dem_Compiler_beim_Optimieren_zuschauen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell's type system compared to CLOS
Matthias-Christian Ott o...@mirix.org writes: That's true. This is a big advantage when compiling programmes. But as far as I know type inference is not always decidable in Haskell. Am I right? Decidability of type inference depends on features you use (GADTs, type classes etc). Type inference in Haskell doesn't mean you avoid providing type signatures at all costs. It is good programming practice to provide type signatures, as elaborate design of ADTs, type classes you use in your program gives you possibility to encode specification of how program behaves in static, that is type signatures help you to document your code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
