Not a bug, but not really ghc-users fare either (I think).
I realise this is "damned if you do, otherwise, damned", but the
following error message confused me:
Intervals.hs:207:
Type signature doesn't match inferred type
Signature: Limit n - Limit n
Inferred : Limit Bool
etc... all seem to be things that are waiting 'till Haskell 2. My
point was that _something_ should be in Standard Haskell. The features
you mention are likely to help when writing a better network library,
but let's not get distracted from the option of including something
straightforward
More generally, regardless of the standards process, it feels like the
GHC, Hugs define the de facto Haskell standard (it doesn't look like HBC
is still in progress but I could be wrong). As such, it seems tough to
write libraries right now as the upcoming GHC/Hugs release will contain
We've seen several examples now, from Ralf, Alex, and others, where it is
useful to relax the proposed restriction:
The types in an instance-declaration context must all be type variables.
(Item 10 in Simon's list:
http://www.dcs.gla.ac.uk/~simonpj/multi-param.html)
Hugs and GHC are currently
Mark Jones:
Looking at the `size' of types is, of course, a generalization of Simon's
suggestion that contexts might be allowed to constrain only proper sub-
expressions of types in the context. (Proper sub-expressions are, by
definition, smaller in size.) However, it is still too strict
Hi Fergus,
| Without the restriction, it is easy to come up with examples that could
| lead to non-termination.
|
| Is non-termination really a problem in practice?
I don't think so, which is why I've been happy not to enforce
restrictions in Hugs. For example, Gofer programs can
Fergus Henderson, replaying to me:
I haven't looked at this in great detail, so forgive me if I'm talking
through my hat, as seems quite likely: is it workable to require only
that contexts be non-increasing in size, and that there be no manifest
circularity where the sizes are
| Fergus Henderson writes of:
| the monomorphism restriction (which exists for a similar reason,
| to ensure termination of type inference).
|
| Is this true? The rationale normally given for it by its advocates
| (boo, hiss) seems invariably the "no re-evaluation of CAFs" mantra.
Yes, I
On Tue, 14 Jul 1998, Alastair Reid wrote:
and it's not clear that
fetching URLs outside the IO monad is sensible. Not at all clear.
S. Alexander Jacobson replied:
I am thinking about using Haskell for XML scripting in which one imports
XML DTD's into Haskell as a set of data statements
On Tue, 14 Jul 1998, Alastair Reid wrote:
and it's not clear that
fetching URLs outside the IO monad is sensible. Not at all clear.
I am thinking about using Haskell for XML scripting in which one imports
XML DTD's into Haskell as a set of data statements and then reads XML
datastructures off
John C. Peterson wrote:
While some may argue that avoiding re-evaluation is the justification
for the monomorphism restriction, the real issue is ambiguity.
Without some form of monomorphism (or scoped type variables?? Someone
needs to convince me that scoped type variables fix everything
Alastair:
There's a lot of things on the list of things we'd like to do but
have no time for at the moment.
Alex:
I understand. Actually the ratio of externally visible tasks to manpower
makes me a little nervous.
You (or other people) could fix that by giving us enough money to
On Wed, 15 Jul 1998, Simon L Peyton Jones wrote:
For these
* multi-parameter type classes
* existential types
* exceptions
* mutually recursive import [GHC does this ok]
we'll have a shiny new GHC beta release before ICFP (end Sept).
(I.e. it's pretty much working now.)
On Wed, 15 Jul 1998, Simon L Peyton Jones wrote:
For these
* multi-parameter type classes
* existential types
* exceptions
* mutually recursive import [GHC does this ok]
we'll have a shiny new GHC beta release before ICFP (end Sept).
(I.e. it's pretty much working now.) Don't know
John Peterson defends the DMR:
read :: Read a = String - a
read s = let [(r,s')] = reads s in r
This *won't compile* if you don't treat the let binding definition
monomorphicly. Without monomorphism, the types of r and s' are
r :: Read a = a
s' :: Read a = String
This leads to an
I hate to reopen an old debate but here goes.
While some may argue that avoiding re-evaluation is the justification
for the monomorphism restriction, the real issue is ambiguity.
Without some form of monomorphism (or scoped type variables?? Someone
needs to convince me that scoped type
On Wed, 15 Jul 1998, Alastair Reid wrote:
I'm not so worried about reliability (though that too is an issue)
as by the fact that web pages keep changing.
My suggestion here is that you can rely on HTTP 1.1 cache control
semantics. Specifically, HTTP 1.1 allows pages to define a
On Thu, 16 Jul 1998, Fergus Henderson wrote:
Well, if you're willing to ignore the possibility that the page will change,
you should be willing to ignore the possibility that accessing the page
may fail... or at least put off dealing with such failures until
Haskell has better exception
I am very dubious about making getURL pure.
Right, and I don't understand why people are so afraid
of the IO monad.
Anyway, using the Haskell-COM interface it is easy to
use IWebBrowser, which gives you anything you want in
terms of web access. The downside is that you are
stuck in the brain
On Wed, 15 Jul 1998, Alastair Reid wrote:
My understanding from Alastair was that Hugs was being synchronized with
GHC so that it could using precompiled GHC libs. Wouldn't that require
that it support these features as well?
The doubt was about when Hugs would do another release
or
Alastair,
I don't have money right now. I am trying to raise it.
When I do, I'd love to spend it on developing a commercial Haskell
middleware project.
-Alex-
On Wed, 15 Jul 1998, Alastair Reid wrote:
Alastair:
There's a lot of things on the list of things we'd like to do but
have
I suppose it would be really elegant if we could define a new net
monad(?) which allows us to reason generally about computations
with different expiration times, but that goes far beyond my
expertise.
See the following paper on "service combinators"...
Both Java and Eiffel attempt to do away with Makefiles.
Java does import chasing (see above). I prefer Eiffel's approach.
Eiffel allows you to define an Assembly of Classes in Eiffel in which
you explicitly specify where to find all the classes used in a particular
23 matches
Mail list logo
