OK - let's get operational! Dave's choices are:
1) Build the resolution dictionary using the context of Module Two
(the point of declaration)
2) Build the resolution dictionary using the context of Module Three
(the point of use).
While Dave is on the right track, neither of these choices
Greg,
Full abstraction: there is junk in the standard denotational domains,
in particular a parallel or function (por). We can write two new
functions f1 and f2, such that f1 por = 1 and f2 por = 2, (and both
give bottom for other boolean functions of the correct type).
So: does f1 = f2? Using
> I would like to make a plea for a validation suite for Haskell.
Hear hear.
> One of the best specified procedural languages is Pascal, which is similar in
> size to Haskell. The Pascal standard defines Pascal rather tighter than the
> Haskell report defines Haskell, but in practice the limi
Puzzled, once again. I think I reason too operationally about these
things. It's a curse brought on by being brain-damaged by Basic
programming at an early age.
John Peterson writes:
The issue is at what point is the overloading of trouble, which would
be typed as
trouble :: Problem
> It would be nice if future Haskell implementations were able to display
> function values in some standard form. In particular, closures might
> be represented as local definitions binding free variables in a
> final function value representation.
I'm not so sure that this would be very nice.
To re-address Phil's example for Dave Barton and others confused by
overloading:
module One (Problematic)
class Problematic a where
difficult :: a -> a
module Two (trouble)
imports One (Problematic)
instance Problematic Int
After getting Dr. Wadler to correct a mistaken belief I had concerning
types, I have thought about this some more. The example was:
Consider the following (currently illegal in Haskell):
module One (Problematic)
class Problematic a w
It would be nice if future Haskell implementations were able to display
function values in some standard form. In particular, closures might
be represented as local definitions binding free variables in a
final function value representation.
There are two arguments against this. The first is phi
Prompted by an IOHCC entry I have the following question:
Is the following legal?
--
module M(x) where
x = 1
z = x==1
--
If the definition of z wasn't there it would clearly be
illegal since it exports an overload non-function value.
But the use of x in
I have a followup question to Lennart's motivated by the same
IOHCC entry.
The Haskell report states that in an abbreviated module, the
header is assumed to be
module Main where
which makes all the identifiers exportable (and so the monomorphism
restriction could bite the unwary). I tend to
> Prompted by an IOHCC entry I have the following question:
>
> Is the following legal?
>
> --
> module M(x) where
> x = 1
> z = x==1
> --
>
> If the definition of z wasn't there it would clearly be
> illegal since it exports an overload non-function val
I would like to make a plea for a validation suite for Haskell.
One of the best specified procedural languages is Pascal, which is similar in
size to Haskell. The Pascal standard defines Pascal rather tighter than the
Haskell report defines Haskell, but in practice the limiting cases are define
In connection with the current debate about modules and classes, I will
describe the view we are trying to develop in Brisk, and then describe how
this gives a slightly different perspective on the global instance property at
the end.
We are trying to develop a meaning for overloading, including
13 matches
Mail list logo
