Hi Gracjan,
On 6/5/05, Gracjan Polak [EMAIL PROTECTED] wrote:
First of all, in Haskell there will be strict separation between
interfaces and data, so almost every method will be declared twice. This
is not so strange to anybody programing in Java, but for C++ programmers
can be. Inheritance
Hi Ralf,
On 6/6/05, Ralf Lammel [EMAIL PROTECTED] wrote:
Re: your enumeration. Let me add one more bullet.
In cases where inheritance is about abstract base classes
and concrete subclasses ((add interface polymorphism likewise))
you can use a (for unknown reasons) unappreciated pattern for
Hello,
My space problems continued...
I have foldl that produces list, some combining function and quite large
source list:
let xyz = foldl f state myBigList
This setting should lazyli consume myBigList when next elements of xyz
are demanded. Except that it seems that myBigList is held by
Cédric Paternotte wrote:
Hi Gracjan,
This is smart. So I understand the point of this part is to forward
the function call to the parent (through get_super). All you have to
do is to define these forwards in each inheriting data.
Yes. I think this is the whole point of inheritance :)
Does
Dimitry Golubovsky [EMAIL PROTECTED] writes:
Does there exist a tool which given a Haskell source, shows functions
that are mutually recursive (i. e. call each other, even via calling
third, etc. functions)? Knowledge of that would help to split the
module into smaller modules without risk to
The differences in the two shape examples doesn't have to do with code
inheritance
- it has to do with subtype polymorphism. Existential types allow you to
throw different subtypes into a collection and have the function dispatch
on the common superclass type. The example without existential
Brian Smith wrote:
Hi,
When will VHS support the Visual Studio.NET 2005 Beta? I'd like to
volunteer to test VHS.NET 2005 when it is available. (Also, MS is
giving away the VS.NET 2005 beta for free, and VS.NET 2003 costs a
whopping $15.00 from my school's bookstore).
Thanks,
Brian
Can we
Hi Chris,
On 6 Jun 2005 14:53:11 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
The differences in the two shape examples doesn't have to do with code
inheritance
- it has to do with subtype polymorphism.
Does this mean that I was wrong in saying in my initial post that
existential
--- Cdric Paternotte [EMAIL PROTECTED]
Does this mean that I was
wrong in saying in my initial post that
existential types can be used to
get code inheritance ? Or is it
just that the Shapes example has never
been meant to illustrate that
side of things ?
The Haskell shapes example
was a
Cédric Paternotte wrote:
...
5. With this :
http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf
Gracjan Polak wrote:
I've been thinking about slight generalization of this lately. Here are
my semi-backed thoughts as of now.
I should have mentioned
Hi Ralf,
I should have mentioned
http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/
(again *not* using OOHaskell)
It's been an interesting evening. I've been having a go at your
poormen's source code and, although it's different from OOHaskell, I
still find it very similar in the sense
Hi Andre,
Manuel Chakravarty and I also wrote a paper titled Interfacing
Haskell to Object-Oriented Languages that you might find useful:
I've been reading it and from what I understood the technique you've
come up with is used to model foreign OO language hierarchies so that
Haskell can
Hi Cedric,
Thanks for your investigation.
Regarding your guess, the code does *not* use state monads (for
mutable data). The whole example would make sense without IO.
(So this approach is *all* different from OOHaskell :-))
The IO monad is used in Poormens2 because some of the
methods might
On Mon, 2005-06-06 at 13:15 +0200, Gracjan Polak wrote:
Hello,
My space problems continued...
I have foldl that produces list, some combining function and quite large
source list:
let xyz = foldl f state myBigList
This setting should lazyli consume myBigList when next elements of
14 matches
Mail list logo
