Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

I mean for the fixed / new one I’m proposing :) On Sun, May 20, 2018 at 8:21 PM Carter Schonwald wrote: > No. I’m saying make same variables get the parent quantified, even if it’s > implicit. > > Breaking changes are ok if they make things better. > > Measuring

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

No. I’m saying make same variables get the parent quantified, even if it’s implicit. Breaking changes are ok if they make things better. Measuring impact really comes down to making the patch and measuring. It will be an easy to fix breaking change and my experience has been that teams in an

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald wrote: > indeed .. and we can reasonably say "lets deal with the bandaid in one go > by cleaning it up in the next standard" > Thanks Carter/Brandon, the reason for asking how we should go about the discussion was

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

indeed .. and we can reasonably say "lets deal with the bandaid in one go by cleaning it up in the next standard" so what would the next gen look like? eg: fresh variables get the usual implicit forall at the front of the type, and everything else either needs an explicit quantifier OR it

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

On Sat, May 19, 2018 at 7:32 AM, Anthony Clayden < anthony_clay...@clear.net.nz> wrote: > So the explanation I've seen for the current design is it was deliberately > idiosyncratic, to minimise any disruption to existing code. Then I'm asking > whether any of that code is still around? If

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

On Wed, 9 May 2018 03:01 UTC, cheater00 wrote: > I couldn't live without ScopedTypeVariables. For me it's an essential tool when I want to figure out Yes absolutely. To be clear: nobody's talking about removing it. The question is, could we get the same functionality without being so confusing

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]

I couldn't live without ScopedTypeVariables. For me it's an essential tool when I want to figure out 1. if the type being inferred is the one I expect 2. what type a specific thing in code I am working with is Also useful for adding that one bit the inferer is missing without immediately

[Haskell] Re: scoped type variables

Norman Ramsey n...@cs.tufts.edu wrote in article 20090316154743.12f45104...@lakeland.eecs.harvard.edu in gmane.comp.lang.haskell.general: ... In any case, I hope this question is orthogonal to the problem of permitting a type declaration as a 'decl' in a where clause and not a mere lonely

[Haskell] Re: scoped type variables

[Opening discussion to broader audience: I asked Simon PJ about scoped type variables and type abbreviations] | With scoped type variables, it would be useful to be able to define | a type abbreviation in a where clause, so that the scoped | type variable could be used on a right-hand side.

Capitalized type variables (was Re: Scoped type variables)

I wrote: What I don't like is that given a signature like x :: a - a there's no way to tell, looking at it in isolation, whether a is free or bound in the type. [...] Here's a completely different idea for solving this. It occurs to me that there isn't all that much difference between

Re: Scoped type variables

On Wed, Feb 08, 2006 at 05:48:24PM -, Simon Peyton-Jones wrote: | b) A pattern type signature may bring into scope a skolem bound |in the same pattern: |data T where | MkT :: a - (a-Int) - T |f (MkT (x::a) f) = ... | |The skolem bound by

Re: Scoped type variables

On Tue, Feb 07, 2006 at 08:15:19PM +, Ben Rudiak-Gould wrote: Simon PJ thinks that Haskell' should include scoped type variables, and I tend to agree. But I'm unhappy with one aspect of the way they're implemented in GHC. What I don't like is that given a signature like x :: a - a

RE: Scoped type variables

| I think we should do the simplest thing that could possibly work, | and then see if we really need more. By work, I mean a compatible | extension of H98 that makes it possible to add type signatures for | local bindings (which isn't always possible in H98). How about: | | * no implicit

Re: Scoped type variables

Ben Rudiak-Gould wrote: Simon PJ thinks that Haskell' should include scoped type variables, and I tend to agree. But I'm unhappy with one aspect of the way they're implemented in GHC. What I don't like is that given a signature like x :: a - a there's no way to tell, looking at it in

Re: Scoped type variables

Hi all, Olaf Chitil wrote: Hence I support Jon in that ghc should only allow those type variables a wider scope that have been explicitly declared with the non-Haskell 98 keyword forall. I'm inclined to support Jon and Olaf here. I'm pretty sure there's lot of code out there that use

RE: Scoped type variables

| Would it help to stick the quantifier at the beginning of | the type declaration? | | forall a b . g :: Foo a b = [a] - [a] | g = ... Since GHC already allows explicit quantifiers, I had indeed wondered about saying that a type sig only brings type variables into scope if it has an

Re: Scoped type variables

I'm not sure I understand the objection raised by Jon; the 'implicit declaration' of type variables in type signatures has never bothered me, and in fact seems quite similar to how names for values don't have to be declared beforehand but are brought into scope by the binding (which I also have

Re: Scoped type variables

At 17:51 + 17/12/2004, Simon Peyton-Jones wrote: OK, OK, I yield! This message is about lexically scoped type variables. I've gradually become convinced that if you write f :: [a] - [a] f x = body then the type variable 'a' should be in scope in body. At present in GHC you

Re: Scoped type variables

On 18/12/2004, at 4:51 AM, Simon Peyton-Jones wrote: This message is about lexically scoped type variables. I've gradually become convinced that if you write f :: [a] - [a] f x = body then the type variable 'a' should be in scope in body. I don't have a particularly strong opinion

Re: Scoped type variables

On 2004-12-17 at 17:51GMT Simon Peyton-Jones wrote: This message is about lexically scoped type variables. I've been trying to work out what I think about this since you sent out the first message in this thread. I'm not sure that I've come to a useful conclusion, so I'll summarise my thoughts

Re: Scoped type variables

what about having -fno-lexically-scoped-types for old code? Keean. Simon Peyton-Jones wrote: OK, OK, I yield! This message is about lexically scoped type variables. I've gradually become convinced that if you write f :: [a] - [a] f x = body then the type variable 'a' should be

Re: Scoped type variables

Please! I've lost count of the number of times when I've written code as f :: a - b f (x :: a) = ... wishing that I didn't have to locally bind the 'a'. I'm not sure I understand the objection raised by Jon; the 'implicit declaration' of type variables in type signatures has never bothered me,

Re: scoped type variables in instance?

I wrote: | OK, I see this was intentional: | | The type variables in the head of a class or instance | declaration scope over the methods defined in the where part. | | But both provisions cause Haskell 98 modules to be rejected, | even without -fglasgow-exts. On Mon, Apr 22,

RE: scoped type variables in instance?

| Is rejecting Haskell 98 modules when -fglasgow-exts is on | also a bug? (i.e. does GHC Haskell aim to be a conservative | extension of H98?) Yes, we do so aim, but this seems to be an occasion where there's no obvious way to make the extension 100% conservative without making the extended

Re: scoped type variables in instance?

OK, I see this was intentional: The type variables in the head of a class or instance declaration scope over the methods defined in the where part. But both provisions cause Haskell 98 modules to be rejected, even without -fglasgow-exts.

RE: scoped type variables in instance?

That's a bug; I'll fix it. | -Original Message- | From: Ross Paterson [mailto:[EMAIL PROTECTED]] | Sent: 22 April 2002 14:15 | To: [EMAIL PROTECTED] | Subject: Re: scoped type variables in instance? | | | OK, I see this was intentional: | | The type variables in the head

Re: scoped type variables in instance?

On Mon, 15 Apr 2002, Ross Paterson wrote: GHC (even without -fglasgow-exts) rejects the following: newtype Foo a = Foo a instance Eq a = Eq (Foo a) where Foo x == Foo y = bar where bar :: a bar = undefined

Re: scoped type variables in instance?

On Mon, 15 Apr 2002, Jay Cox wrote: class Eq z where (==) :: z - z - Bool Oops. Here to report a Jay.Brain bug. I understand you now. Heh. I infered the bug you report was standard haskell usage. Here's a more dramatic example of your bug :)

RE: Scoped type variables

| | When you say there's a good theoretical foundation (typed lambda | | calcului) I think you are imagining that when we say | | | | f (x::a) = e | | | | we are saying There's a /\a as well as a \x::a in this definition. | | No, that's not what I'm thinking. OK, let me try to give some

RE: Scoped type variables

Hi Mark, Thanks for your reply. | | Arguments in favour: | | - It's more like term-variable pattern matching | | Term variables in a pattern are binding occurrences, but type | variables are not. Making the latter look more like the | former would appear to be a recipe for unnecessary

Re: Scoped type variables

Tue, 8 May 2001 00:47:58 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze: g = \x::(Int,Bool) - let-type (a,b) = (Int,Bool) in e But notice that the RHS of a pattern-matching let-type is statically guaranteed to have the right shape. So I don't allow let-type (a,b) = c in

RE: Scoped type variables

| g = \x::(Int,Bool) - let-type (a,b) = (Int,Bool) in e | | But notice that the RHS of a pattern-matching let-type is | statically | guaranteed to have the right shape. So I don't allow | | let-type (a,b) = c in ... | | (where c is a type variable). | | Really? I disagree.

Re: Scoped type variables

Tue, 8 May 2001 08:25:39 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze: I was meaning in the translation into System F of the program. [...] Ah, OK, sorry. More strange behavior of Hugs (none of this is allowed by ghc): \(x :: a) (y :: b) - x+y -- not allowed \(x :: a) - \(y ::

RE: Scoped type variables

Hi Simon! | This is the message that Marcin referred to, proposing a change in | the semantics of scoped type variables. I may just go ahead and | implement it in GHC. (The implementation is easy: delete a couple | of lines; and I guess the same is so for Hugs. The question is whether | it's