Ralf Laemmel wrote:
[...]
find . -name configure.ac -print
to find all dirs that need autoreconf (not autoconf anymore)
autoreconf
(cd ghc; autoreconf)
(cd libraries; autoreconf)
FYI: Just issue "autoreconf" at the toplevel, and you're done. It will
descend into all necessary subdirectories, jus
Brandon Michael Moore wrote:
Great. But I can't build from the source: I'm getting errors about a
missing config.h.in in mk. I'm just trying autoconf, comfigure. I'll look
closer over the weekend.
Use the following (more specifically autoREconf).
The GHC build guide is behind.
cvs -d cvs.haskel
On Wed, 5 Nov 2003, Simon Peyton-Jones wrote:
> | More overlapping:
> | Allow any overlapping rules, and apply the most specific rule that
> | matches our target. Only complain if there is a pair of matching
> | rules neither of which is more specific than the other.
> | This follow the spirit o
| More overlapping:
| Allow any overlapping rules, and apply the most specific rule that
| matches our target. Only complain if there is a pair of matching
| rules neither of which is more specific than the other.
| This follow the spirit of the treatment of duplicate imports...
Happy days. I've
Brandon Michael Moore <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in
gmane.comp.lang.haskell.cafe:
> There are two extensions here:
>
> More overlapping: [...]
> Backtracking search: [...]
>
> Overloading resolution: [...]
I'm sorry if I am getting ahead of Simon or behind of you,
Hello!
Let me describe (my understanding of) the problem first. Let us assume
a Java-like OO language, but with multiple inheritance. Let us
consider the following hierarchy:
Object -- the root of the hierarchy
ClassA: inherits from Object
defines method Foo::Int -> B
On Tue, 4 Nov 2003, Simon Peyton-Jones wrote:
>
> | We really should change GHC rather than keep trying to work around
> stuff
> | like this. GHC will be my light reading for winter break.
>
> Maybe so. For the benefit of those of us who have not followed the
> details of your work, could you sum
| We really should change GHC rather than keep trying to work around
stuff
| like this. GHC will be my light reading for winter break.
Maybe so. For the benefit of those of us who have not followed the
details of your work, could you summarise, as precisely as possible,
just what language extens
Thanks for the clever code Oleg. I've tried to extend it again to track
the types of methods as well as just the names, giving a functional
dependancy from the class, method, and to result type. I can't get the
overlapping instances to work out, so I'm handing it back to a master,
and the rest of t
This seems to work. The type checker picks one rule to use at each point
so you can't get backtracking, but you explicitly build the sequence of
base classes, and use the overloading resolution to stop if we find our
goal. This is clever.
It looks like prolog could be interesting. My first introdu
This message illustrates how to get the typechecker to traverse
non-flat, non-linear trees of types in search of a specific type. We
have thus implemented a depth-first tree lookup at the typechecking
time, in the language of classes and instances.
The following test is the best illustration:
>
On Fri, 26 Sep 2003 [EMAIL PROTECTED] wrote:
>
> Brandon Michael Moore wrote regarding the first solution: chain of
> super-classes:
>
> > I'm worried about large class hierarchies. If it works on the
> > java.* classes I should be fine. Have you used this approach before? I'm
> > worried about com
Brandon Michael Moore wrote regarding the first solution: chain of
super-classes:
> I'm worried about large class hierarchies. If it works on the
> java.* classes I should be fine. Have you used this approach before? I'm
> worried about compile time, runtime costs from the casts (hopefully they
>
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote:
>
> Brandon Michael Moore wrote:
>
> > So I defined a class to model the inheritance relationships
>
> > class SubType super sub | sub -> super where
> > upCast :: sub -> super
>
> > Now I can define a default instance of HasFooMethod:
> > instance (Ha
Brandon Michael Moore wrote:
> So I defined a class to model the inheritance relationships
> class SubType super sub | sub -> super where
> upCast :: sub -> super
> Now I can define a default instance of HasFooMethod:
> instance (HasFooMethod super args result,
> SubClass super sub)
On 25/09/2003, at 7:22 AM, Brandon Michael Moore wrote:
I'm trying to build a nicer interface over the one generated by
jvm-bridge. I'm using fancy type classes to remove the need to mangle
method names. I would like methods to be automatcially inherited,
following an inheritance hierarcy defined
may find it interesting none the
less.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Brandon Michael Moore
| Sent: 24 September 2003 22:22
| To: [EMAIL PROTECTED]
| Subject: Modeling multiple inheritance
|
| I'm trying to build a
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote:
> On 25/09/2003, at 7:22 AM, Brandon Michael Moore wrote:
>
> > I'm trying to build a nicer interface over the one generated by
> > jvm-bridge. I'm using fancy type classes to remove the need to mangle
> > method names. I would like methods to be automa
I'm trying to build a nicer interface over the one generated by
jvm-bridge. I'm using fancy type classes to remove the need to mangle
method names. I would like methods to be automatcially inherited,
following an inheritance hierarcy defined with another set of type
classes.
My basic classes look
19 matches
Mail list logo
