Re: [Haskell-cafe] Trouble with record syntax and classes
[EMAIL PROTECTED] wrote: When you type class Foo in Java or C++, it does three things: 1. It declares a new type called Foo. 2. It declares a _set_ of types (i.e. a class). 3. It declares that the type Foo (and all of its subtypes) is a member of the set of types Foo. I would add: 4. Define a namespace, also called Foo, for a set of values (and probably nested classes). In Haskell, these three operations are distinct. 1. You declare a new type using data or newtype. 2. You declare a new set of types using class. 3. You declare that a type is a member of a class using instance. 4. You define a new namespace using module. Cheers, - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Claus Reinke wrote: but on the Pascal note: is there anything in Pascal that Haskell doesn't provide, and improves on (nested procedures, procedure parameters, distinguishing in and out parameters, types, ..)? Subrange types, maybe? But I'm sure Oleg will show us that Haskell already has them. :-) - Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type inference
Brian Hulley wrote: Fred Hosch wrote: Is type inferencing in Haskell essentially the same as in SML? The most significant difference certainly is that type inference has been beefed up with type classes in Haskell, which are quite a powerful mechanism refining Hindley/Milner inference. Besides that, Haskell allows some additional programs for which types can /not/ be inferred (e.g. the examples Brian was giving), while SML does not. SML also has a complicated thing called the value restriction because it allows mutable references to be altered via side effects. Because Haskell has no side effects, there is no need for a value restriction. Although there is no need for it, Haskell still has it, in minor variation. It is commonly known as The Dreaded Monomorphism Restriction ;). - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Dynamic binding
Ralf Lammel wrote: Can you just tell how *you* would favor encoding the shapes example that was posed by poster? (It might just be that your code would be very close to Lennart's proposal?) There is no universal answer. The shape example obviously is just a toy example. As long as I have no idea what *concrete* problem the original poster is trying to solve, I cannot really tell which approach is preferable for his endeavour. It seems more appropriate to describe the options and their trade-offs. First of all, note that very often, you do not need a heterogeneous collection at all. Then plain polymorphism with type classes is more than enough, and more than OO provides in that situation. In many cases where you need some kind of heterogenicity (is that a word?), the standard datatype approach shown by Lennart is perfectly suitable - in fact, often much more suitable than the OO solution. You know about the expression problem, and the two dual notions of extensibility? OO supports one dimension, datatypes the other. It depends on the problem which one is more important. When you really need OO-style intensional kind of behaviour selection then first-class functions can bring you quite a long way, and often with much less amount of boilerplate than typical OO solutions. When the behaviour you have to encapsulate in heterogeneous collection becomes more complex - say, more then just one or two functions - first-class functions can be tedious. Existential types represent a more coarse-grained and structured variant of the first-class function approach. They combine the power of first-class functions with the convenience of type classes, very similar to class-based objects. In these cases, they are the most appropriate solution. Note again that with the latter two solutions, as with the OO approach, you do not have extensibility on the operations dimension. Cheers, - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Dynamic binding
Ralf Lammel wrote: only because it's C-like :) you just can't believe that Haskell program can be 3-10 times smaller while keeping the same functionality :))) But note that same functionality is one thing, having separate compilation and program extensibility too is another one. As I said, and as is well-known, extensibility is a red herring in this context - you merely trade one dimension of extensibility for another one. Cheers, - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Dynamic binding
Ralf Lammel wrote: I would like to add a peer-reviewed clear reference to the OOHaskell paper about the red herring that you mention. I don't have such a reference. May I kindly ask you to offer a few for selection? Off-hand, I recall a paper by Martin Odersky and the Scala people discussing their approach to the Expression Problem, and a related paper by Jacques Garrigue, where he proposes to solve it using OCaml's polymorphic variants. Both should be easy to dig up with Google, and probably contain further pointers. Hope this helps, - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Pure Haskell Printf
Keean Schupke wrote: Remember C is typesafe In which parallel universe? -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Pure Haskell Printf
Keean Schupke wrote:
I of course meant strongly-typed, you cannot pass a pointer to an int
where a pointer
to a float is required ... modern C compilers require you to explicitly
cast.
According to the C standard,
void f(float *p) { *p + 1.0; }
void g(void *p) { f(p); }
void h(int n) { g(n); }
is perfectly valid (though undefined).
Where
it fell down was all that automatic type promotion, and providing unsafe
casts.
And other things, like unions, varargs, etc. Not to speak of subtyping
in C++...
There is now a typesafe 'C', but I can't remember what it is called -
presumably it uses some kind of linear-alias typing to make pointers safe.
Do you mean Cyclone?
http://www.research.att.com/projects/cyclone/
Cheers,
- Andreas
--
Andreas Rossberg, [EMAIL PROTECTED]
Let's get rid of those possible thingies! -- TB
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mutually recursive modules
Alastair Reid wrote: Generating .hiboot files by just deleting function definitions fails if there is no prototype for an exported function. A crude approach is to assume the type (\forall a. a) for any function with no prototype but, although this is sound (I think), it will cause valid programs to be rejected. Huh? How can that ever be sound? Are you sure you didn't mean (\exists a.a)? - Andreas -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] not getting most general type - is this a bug in hugs?
[EMAIL PROTECTED] wrote: rep0' :: [Integer]-- WHAT?? You just have made first contact with the Dreaded Monorphism Restriction. -- Andreas Rossberg, [EMAIL PROTECTED] Let's get rid of those possible thingies! -- TB ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
