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 impact really comes down to makin
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 indu
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 exactly: where/how are we going
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 refers
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 not/if
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 an
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 modifyin
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 "-fgla
| Some design choices are unclear, at least to me. First, the
| separation of body and signature. I am used to locally introduced
| identifiers being visible locally too (i.e. requiring minimal
| scrolling through a file). This would break, meaning that I have to
| know which identifier was used in
| 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 a
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 =
then the type variable 'a' should be in scope in . At present in
GHC you have to w
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 no
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 =
then the type variable 'a' should be in scope in .
I don't have a particularly strong opinion about t
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,
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 =
then the type variable 'a' should be in s
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
16 matches
Mail list logo
