On 06-May-2001, Bernard James POPE <[EMAIL PROTECTED]> wrote:
>
> If you applied the Mercury algorithm to Haskell (ie used fixed point iteration
> to search for a type, rather than requiring a type annotation), would
> the new type inference algorithm accept/reject the same programs as the
> exi
> Fergus Henderson wrote:
> In contrast, Haskell uses a type inference algorithm
> which sometimes infers what I would call wrong answers:
> types which are less general that can be obtained with an explicit
> type declaration. These types might not be what the programmer had
> intended, and thi
On 04-May-2001, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Lennart Augustsson [mailto:[EMAIL PROTECTED]] wrote:
> | It is not at all surprising that you can write this.
> | Originally type signatures only allowed you to put a
> | signature that was more specific.
> | Polymorhic recursion o
Fri, 4 May 2001 11:27:07 -0700, John Meacham <[EMAIL PROTECTED]> pisze:
> My idea was to allow '_' to be used in type signatures and represent
> any type.
I like it. There were also proposals for '..'.
It would be useful in cases analogous to this:
import IArray
import MArray
f:: (IArray a e,
I have thought about this too. omission of type signatures seems to be
an effective catalyst for code re-use yet this benefit is rarely
emphasised. I was thinking about ways to make it easier and toyed around
with allowing 'unkowns' in type declarations to allow you to specify
only the important p
On Fri, May 04, 2001 at 09:27:51AM +0200, John Hughes wrote:
> One good reason for NOT giving inferrable type signatures is that
> including them makes programs less modifiable: a small local change, such as
> adding a parameter to a type, may force a large number of consequential
> change
3 May 2001 15:24
| To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]
| Subject: Re: Implict parameters and monomorphism
|
|
| OK, so since noone liked my original example here's another
| one. It involves no defaulting and no classes in the funny
| function definition.
|
| --
Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes <[EMAIL PROTECTED]> pisze:
> One good reason for NOT giving inferrable type signatures is that
> including them makes programs less modifiable: a small local change,
> such as adding a parameter to a type, may force a large number of
> consequ
> Except, of course, for top level bindings which is where the
> monomorphism restriction is usually most noticable.
Right, but an explicit monomorphic type signature would ensure that
it's computed once. Type signatures on toplevel bindings are a good
ide
This whole monomorphism-restriction debate was one that we had when we were writing
the implicit parameters paper. We noted the dire impact of the monomorphism
restriction, and commented upon it.
On reviewing the whole issue again I am forced again to conclude: There Is No
Satisfactory Solutio
Thu, 3 May 2001 15:26:38 -0600, Alastair Reid <[EMAIL PROTECTED]> pisze:
>> You can always use 'case' instead of 'let' for variable bindings.
>
> Except, of course, for top level bindings which is where the
> monomorphism restriction is usually most noticable.
Right, but an explicit monomorphic
> You can always use 'case' instead of 'let' for variable bindings.
Except, of course, for top level bindings which is where the
monomorphism restriction is usually most noticable.
> I would remove the monomorphism restriction, [...]
This seems to be a pretty common sentiment but
I don't see an
Wed, 2 May 2001 10:51:58 +0200 (MET DST), John Hughes <[EMAIL PROTECTED]> pisze:
> Breaking the monomorphism restriction in ANY case makes both space
> and time cost of evaluation unpredictable, and brittle when program
> changes elsewhere introduce or remove an implicit parameter.
You can alway
OK, so since noone liked my original example here's another one.
It involves no defaulting and no classes in the funny function definition.
-- Here's the type signature that makes a difference.
--fun :: a -> Char
fun x = const (fun x) (fun True)
fix f = let x = f x in x
class C a where
m ::
> But most importantly, this was a bad example. There was a much better
> one posted on this mailing list a while ago. Does anyone remember it?
>
> -- Lennart
Perhaps I should mention a useful application of this game, somewhat
unhelpfully named "Representative thingies" in my Haskell cor
Thu, 03 May 2001 08:07:10 -0400, Lennart Augustsson <[EMAIL PROTECTED]>
pisze:
> First, I cannot parse that sentence, but I assume you mean when all
> classes are Prelude classes.
Not only Prelude but the whole Haskell 98 standard library.
> Second, I'm pretty sure we all agreed that this was
> > > Try this program:
> > > -- Try commenting out this type signature.
> > > fun:: (Num a) => a -> Int
> > Defaulting applies only when all classes involved are Haskell 98.
>
> First, I cannot parse that sentence, but I assume you mean when all
> classes are Prelude classes.
> Second, I'm pret
Lennart Augustsson wrote:
>
> But most importantly, this was a bad example. There was a much better
> one posted on this mailing list a while ago. Does anyone remember it?
No, but this should do it:
data T = T Int
instance Show T where
show (T n) = show n
instance Eq
instance Num T
> > Try this program:
> > -- Try commenting out this type signature.
> > fun:: (Num a) => a -> Int
> Defaulting applies only when all classes involved are Haskell 98.
> hbc, nhc98 and Hugs are not conforming.
Seems you're right (all classes for the ambiguous type variable need to
be from prelude
Marcin 'Qrczak' Kowalczyk wrote:
> Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson <[EMAIL PROTECTED]>
>pisze:
>
> > Try this program:
> > -- Try commenting out this type signature.
> > fun:: (Num a) => a -> Int
>
> Test.hs:7:
> Ambiguous type variable(s) `a' in the constraint `Num a'
>
Thu, 03 May 2001 06:29:35 -0400, Lennart Augustsson <[EMAIL PROTECTED]>
pisze:
> Try this program:
> -- Try commenting out this type signature.
> fun:: (Num a) => a -> Int
Test.hs:7:
Ambiguous type variable(s) `a' in the constraint `Num a'
arising from use of `fun' at Test.hs:7
In t
Simon Peyton-Jones wrote:
> | a) That adding a type signature can change the dynamic semantics
> | of the program. This would be the first and only
> | occurrence of
> | such behaviour.
> |
> | At present, adding a type signature changes both the static
> | semantics an
Simon Peyton-Jones wrote:
> John: just to check, you do realise that (B) means
>
> a) That adding a type signature can change the dynamic semantics
> of the program. This would be the first and only occurrence of
> such behaviour.
Not so, there are already Haskell program that give a di
| a) That adding a type signature can change the dynamic semantics
| of the program. This would be the first and only
| occurrence of
| such behaviour.
|
| At present, adding a type signature changes both the static
| semantics and the cost of running a program
That
John: just to check, you do realise that (B) means
a) That adding a type signature can change the dynamic semantics
of the program. This would be the first and only occurrence of
such behaviour.
At present, adding a type signature changes both the static
Simon Peyton-Jones wrote:
> | As far as what one would `expect', it's in the very nature of
> | dynamic binding that it makes the meaning of an expression
> | depend on its context. I for one would certainly not expect
> | that inlining a definition bound to such an
> | expression should preserve
Maybe I misinterpret the Haskell Report but I thought it does not even
demand call-by-need evaluation (it only speaks of non-strict semantics).
So why have a special rule in the language definition to support
something cbn-ish for this particular case? As long as t
But a term with an "implicit" argument is a function no matter how you turn
it, you just don't write the argument explicitely.
I don't buy that. You could equally well say a term with a free variable is
a "function" (of the environment): sure it is, but if it's bound with a let
t
| As far as what one would `expect', it's in the very nature of
| dynamic binding that it makes the meaning of an expression
| depend on its context. I for one would certainly not expect
| that inlining a definition bound to such an
| expression should preserve its meaning! Inlining changes th
John Hughes wrote:
> ... Function bodies are clearly evaluated many times, once for each
> call, but non-function bindings should be evaluated at most once to respect
> call-by-need semantics.
Isn't this a very fragile distinction? It seems so susceptible
to routine program transformations by
> [...many lines deleted...]
> I think it's important to have a simple model of how many times
expressions
> are evaluated. Function bodies are clearly evaluated many times, once for
each
> call, but non-function bindings should be evaluated at most once to
respect
> call-by-need semantics. Breaki
John Hughes wrote:
>
> I think it's important to have a simple model of how many
> times expressions are evaluated. Function bodies are clearly
> evaluated many times, once for each call, but non-function
> bindings should be evaluated at most once to respect
> call-by-need semantics.
Maybe I mi
(B) Monomorphism restriction "wins"
Bindings that fall under the monomorphism restriction can't
be generalised
Always generalise over implicit parameters *except* for bindings
that fall under the monomorphism restriction
Jeff
Thanks for your detailed reply.
| In other words, the monomorphism restriction converts certain
| let bindings to lambda bindings.
But this approach pre-supposes that the monomorphism restriction
takes priority over the "must generalise implicit parameters" rule.
Once you make that suppo
Jeffrey R. Lewis <[EMAIL PROTECTED]> argued that
the monomorphism restriction enabled translations of
let-bindungs into lambda-bindings:
> > let z = x + ?y in z+z
> >
>
> [...]
>
> The example above becomes:
> (\z -> z + z) (x + ?y)
In Hindley-Milner type systems,
the poin
Simon Peyton-Jones wrote:
> This is a long message about the design of implicit parameters.
> In particular, it is about the interaction of the monomorphism
> restriction with implicit parameters. This issue was discussed
> in the original implicit-parameter paper, but I wanted to articulate
> i
As a minor point in our draft paper
``From Type Classes to Module Constraints''
http://ist.unibw-muenchen.de/Haskell/ModConstraints/
we argue that implicit parameters and conventional type class contexts
are really the same thing.
This immediately dictated the answers to the first two questi
> On Wed, 25 Apr 2001, Robert Ennals wrote:
>
> > Thus if we want to "inherit" our implicit paramater, we would have:
> >
> > f ?y x = (x :: Int) + ?y
>
> I like the current solution better. They are called "implicit parameters"
> because they are, well, implicit :-)
The semantics is still imp
On Wed, 25 Apr 2001, Robert Ennals wrote:
> Thus if we want to "inherit" our implicit paramater, we would have:
>
> f ?y x = (x :: Int) + ?y
I like the current solution better. They are called "implicit parameters"
because they are, well, implicit :-)
--
Marcin 'Qrczak' Kowalczyk
__
25 Apr 2001 07:18:50 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze:
> Why would it magically turn into an ordinary identifier for inner
> scopes? It dynamically appears in each place it is used.
In other words since ?x is legal in an inner scope no matter whether
it appears in an oute
> On Tue, Apr 24, 2001 at 04:04:54PM -0700, Simon Peyton-Jones wrote:
> > Question 1: can we "inherit" implicit parameters
> >
> > Consider this:
> >
> > f x = (x::Int) + ?y
> > ...
> > f :: Int -> Int
> > [versus]
> > f :: (?y::Int) =>
Tue, 24 Apr 2001 22:51:41 -0400, Dylan Thurston <[EMAIL PROTECTED]> pisze:
> It seems desirable to provide some way to allow either possible answer
> to Question 1 (i.e., dynamically scoped or statically scoped ?y).
You can bind its value to a statically scoped variable.
IMHO it shoult not be s
Tue, 24 Apr 2001 16:04:54 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> Choice (C) really says "the monomorphism restriction doesn't apply
> to implicit parameters". Which is fine, but remember that every
> innocent binding 'x = ...' that mentions an implicit parameter in
> the RHS bec
On Tue, Apr 24, 2001 at 04:04:54PM -0700, Simon Peyton-Jones wrote:
> Question 1: can we "inherit" implicit parameters
>
> Consider this:
>
> f x = (x::Int) + ?y
> ...
> f :: Int -> Int
> [versus]
> f :: (?y::Int) => Int -> Int
>
This is a long message about the design of implicit parameters.
In particular, it is about the interaction of the monomorphism
restriction with implicit parameters. This issue was discussed
in the original implicit-parameter paper, but I wanted to articulate
it afresh and propose some design choi
45 matches
Mail list logo
