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

[Carter Schonwald]

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 making the patch and measuring. It
> will be an easy to fix breaking change and my experience has been that
> teams in an industrial context are a ok with none silent breaking changes.
> This would be very easy to catch :)
>
> On the pedagogy side it actually makes learning simpler afaict :)
>
> On Sun, May 20, 2018 at 8:03 PM Anthony Clayden <
> anthony_clay...@clear.net.nz> wrote:
>
>> On Mon, 21 May 2018 at 11:23 AM, Carter Schonwald <
>> redir...@vodafone.co.nz> 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 to maximise the chance of
>> finding out what code is out there, and how disruptive any 'clean up' might
>> be?
>>
>> Ghc has occasionally made breaking releases (not saying that's what we
>> want to do), usually with some advance warning/deprecation period. And
>> generally the Haskell community has accommodated that with understanding of
>> the decision, to fix their code.
>>
>>
>>
>>> 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
>>> to the outer implicit quantified variable?
>>>
>>
>> I wanted to avoid discussing 'next gen' in possibly-obscure/write-only
>> mailing lists; and preferably get the discussion where posterity can see
>> the reasoning/examination of options.
>>
>> "fresh variables get the usual implicit forall" is what happens now.
>> (It's just that the User Guide explains it really badly -- I'm trying to
>> fix that separately https://ghc.haskell.org/trac/ghc/ticket/15146 .) If
>> the outer variable(s) are not explicitly forall-quantified, then even
>> same-named variables count as fresh. IOW merely putting a `forall` can
>> change the meaning of a program -- that's what causes the most confusion
>> (judging by SO).
>>
>> The exception is variables bound in a pattern signature for an
>> existentially-quantified data constructor: they *must* be fresh. This is
>> hard for a reader to follow because the pattern signature with data
>> constructor looks the same whether or not the constructor is
>> existentially-quantified. What's worse a constructor might have a mix of
>> existential and universal variables.
>>
>> AntC
>>
>>
>>> On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
>>> wrote:
>>>
 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 it's 
> been re-factored to use ScopedTypeVariables, then any tweak to the design 
> could have a freer hand.
>
>
 The reason there's no discussion about that is that nobody here has the
 ability to go hunt down every last piece of code in every public or private
 (think Standard Chartered, Facebook, etc.) code base and its current owner,
 and order them to "fix" it. You can't win that battle.

 --
 brandon s allbery kf8nh   sine nomine
 associates
 allber...@gmail.com
 ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net

>>>
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Carter Schonwald]

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 industrial context are a ok with none silent breaking changes.
This would be very easy to catch :)

On the pedagogy side it actually makes learning simpler afaict :)

On Sun, May 20, 2018 at 8:03 PM Anthony Clayden <
anthony_clay...@clear.net.nz> wrote:

> 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 to maximise the chance of
> finding out what code is out there, and how disruptive any 'clean up' might
> be?
>
> Ghc has occasionally made breaking releases (not saying that's what we
> want to do), usually with some advance warning/deprecation period. And
> generally the Haskell community has accommodated that with understanding of
> the decision, to fix their code.
>
>
>
>> 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
>> to the outer implicit quantified variable?
>>
>
> I wanted to avoid discussing 'next gen' in possibly-obscure/write-only
> mailing lists; and preferably get the discussion where posterity can see
> the reasoning/examination of options.
>
> "fresh variables get the usual implicit forall" is what happens now. (It's
> just that the User Guide explains it really badly -- I'm trying to fix that
> separately https://ghc.haskell.org/trac/ghc/ticket/15146 .) If the outer
> variable(s) are not explicitly forall-quantified, then even same-named
> variables count as fresh. IOW merely putting a `forall` can change the
> meaning of a program -- that's what causes the most confusion (judging by
> SO).
>
> The exception is variables bound in a pattern signature for an
> existentially-quantified data constructor: they *must* be fresh. This is
> hard for a reader to follow because the pattern signature with data
> constructor looks the same whether or not the constructor is
> existentially-quantified. What's worse a constructor might have a mix of
> existential and universal variables.
>
> AntC
>
>
>> On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
>> wrote:
>>
>>> 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 it's been 
 re-factored to use ScopedTypeVariables, then any tweak to the design could 
 have a freer hand.


>>> The reason there's no discussion about that is that nobody here has the
>>> ability to go hunt down every last piece of code in every public or private
>>> (think Standard Chartered, Facebook, etc.) code base and its current owner,
>>> and order them to "fix" it. You can't win that battle.
>>>
>>> --
>>> brandon s allbery kf8nh   sine nomine
>>> associates
>>> allber...@gmail.com
>>> ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>
>>> ___
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Anthony Clayden]

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 to maximise the chance of
finding out what code is out there, and how disruptive any 'clean up' might
be?

Ghc has occasionally made breaking releases (not saying that's what we want
to do), usually with some advance warning/deprecation period. And generally
the Haskell community has accommodated that with understanding of the
decision, to fix their code.



> 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
> to the outer implicit quantified variable?
>

I wanted to avoid discussing 'next gen' in possibly-obscure/write-only
mailing lists; and preferably get the discussion where posterity can see
the reasoning/examination of options.

"fresh variables get the usual implicit forall" is what happens now. (It's
just that the User Guide explains it really badly -- I'm trying to fix that
separately https://ghc.haskell.org/trac/ghc/ticket/15146 .) If the outer
variable(s) are not explicitly forall-quantified, then even same-named
variables count as fresh. IOW merely putting a `forall` can change the
meaning of a program -- that's what causes the most confusion (judging by
SO).

The exception is variables bound in a pattern signature for an
existentially-quantified data constructor: they *must* be fresh. This is
hard for a reader to follow because the pattern signature with data
constructor looks the same whether or not the constructor is
existentially-quantified. What's worse a constructor might have a mix of
existential and universal variables.

AntC


> On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
> wrote:
>
>> 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 it's been re-factored 
>>> to use ScopedTypeVariables, then any tweak to the design could have a freer 
>>> hand.
>>>
>>>
>> The reason there's no discussion about that is that nobody here has the
>> ability to go hunt down every last piece of code in every public or private
>> (think Standard Chartered, Facebook, etc.) code base and its current owner,
>> and order them to "fix" it. You can't win that battle.
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Carter Schonwald]

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 to the
outer implicit quantified variable?

On Sat, May 19, 2018 at 2:56 PM, Brandon Allbery 
wrote:

> 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 it's been re-factored to 
>> use ScopedTypeVariables, then any tweak to the design could have a freer 
>> hand.
>>
>>
> The reason there's no discussion about that is that nobody here has the
> ability to go hunt down every last piece of code in every public or private
> (think Standard Chartered, Facebook, etc.) code base and its current owner,
> and order them to "fix" it. You can't win that battle.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Brandon Allbery]

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 it's been re-factored to 
> use ScopedTypeVariables, then any tweak to the design could have a freer hand.
>
>
The reason there's no discussion about that is that nobody here has the
ability to go hunt down every last piece of code in every public or private
(think Standard Chartered, Facebook, etc.) code base and its current owner,
and order them to "fix" it. You can't win that battle.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[Anthony Clayden]

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 and contrary to how Haskell usually works with type
variables? (I'm not saying yea or nay, I'm trying to invite
discussion.)

> ...

> Backwards compat: Isn't this what we have Haskell 98, Haskell 2010, etc?

The current design for ScopedTypeVariables potentially changes the
types for programs that are valid H98/H2010. (Or for programs that
were valid as at when ScopedTypeVariables was introduced ~10 years
ago, perhaps using ExplicitForAll.) Probably the effect would be that
they don't compile, but it might be more subtle.


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 it's been re-factored to use ScopedTypeVariables, then any
tweak to the design could have a freer hand.


But seems there's no enthusiasm for such discussion, so I'm going to
let it die. I hear there might be moves afoot elsewhere ...


AntC
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

[cheater00 cheater00]

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 modifying a complex type sig. I can do that later, but the
proof of concept should be quick and easy.

Backwards compat: Isn't this what we have Haskell 98, Haskell 2010, etc?

On Sat, 5 May 2018 04:35 Anthony Clayden, 
wrote:

> This thread is a discussion about discussions, not the discussion itself
> ;-)
>
> I'm cc'ing to the cafe; but I'd prefer replies to come to
> glasgow-haskell-users.
>
>
> >> I can volunteer to at least scrape together all the objections to
> ScopedTypeVariables as currently. It's not yet a proposal, so not on
> github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users
> thread? (It'll get ignored.)
>
> > ... don’t care what forums or list or whatever. As long as it’s
> collated and such
> > It could even be on the prime issue tracker for prime proposals. Just
> that it’s written down :)
>
> Thanks Carter, but I understand Haskell Prime to be to assess
> mature/stable proposals (preferably already delivered as extensions). This
> discussion is at first going to be more exploratory:
> * likes and dislikes about ScopedTypeVariables as currently.
> * confusions experienced by users (especially newbies)
> -- although absolute newbies wouldn't be using it(?), so intermediates?
> * feedback from those teaching Haskell.
> * wild ideas for possible alternative designs.
> * possible improvements to the current design.
> * I think we're all agreed that ScopedTypeVariables should have been in
> Haskell from the beginning;
> but it wasn't, so now we have to worry about backwards compatibility for
> programs that worked around the omission.
> Or do we? What code would break? How much pain would that cause?
> * anything else?
>
> > We have lots of forums, but your point is that certain sorts of
> discussions never get going with the right audience – you especially point
> to “confused beginners”.
> > ... It’s quite a challenge because beginners tend not to be vocal, and
> yet they are a crucial set of Haskell users. Every Haskell user started as
> a beginner.
>
> On this particular topic, there's plenty of confused people asking
> questions on StackOverflow. (Heads up: they're especially asking why they
> need explicit `forall` whereas in reguar Haskell that 'intermediates' see,
> the forall is implicit.)
>
> Can other people point me to questions/likes/dislikes on other forums?
> Reddit for example.
>
> If you've read this far, you now understand what we're trying to cover.
> It's going to be random/varied thoughts at first, then perhaps coalescing
> to an approach or two. At that point a formal proposal on github proper;
> and the random stuff might be interesting background but will essentially
> get archived/thrown away.
>
> I do agree with David's suggestion that github Issue tracker looks like a
> suitable solution. We can write formatted code and text. We can add links
> and references. What do others think? Joachim has opened up Issues tracker,
> as a try-out. If using it doesn't work out, that's fine and in keeping with
> my "thrown away" above.
>
> Also where else should I post links to this message to 'advertise' the
> thread? I don't reddit much, so if that's suitable, please someone post
> there.
>
> Thank you
> AntC
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Scoped type variables

[Henrik Nilsson]

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 -fglasgow-exts
for all sorts of reasons totally unrelated to scoped type variables.
Moreover, I suspect that type signatures for local definitions are quite
common too. I, at least, use them a fair bit. So, unless it is 100%
clear that the proposed additional way of introducing scoped type
variables really is the way to go, I would say go for the version
that breaks the fewest programs.
If nothing else, if it does turn out to really be the right way, it
would seem fairly easy to later generalize the rule, by not requiring
an explicit forall (and thus recovering the property that the current
type signature syntax is just a syntactic shorthand) than go the other
way.
Personally, I always get a bit worried when there is too much magic
going on, e.g. when the meaning of syntactic constructs are stretched
in various ways in attempts to do the right thing tacitly. I believe
it usually better, in the long run at least, to state intentions more
explicitly. E.g., in this case, maybe it isn't such a bad idea after
all to differentiate syntactically between binding occurrences and
referring  occurrences of scoped type variables?
Thus, also from this perspective it would seem that requiring an
explicit forall for introducing scoped type variables would be the
better option as it could be argued that intentions are stated a bit
more explicitly that way, although maybe not in as explicitly as
could be desired.
It is, however, unfortunate that a signature without outer foralls
no longer would be just a syntactic shorthand for signatures with the
foralls mentioned explicitly.
Best regards,
/Henrik
--
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
[EMAIL PROTECTED]
This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks.  Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Scoped type variables

[Simon Peyton-Jones]

| 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 explicit quantifier.  Thus

g :: forall a b. Foo a b = [a] - [a]
g = ...
would bring a  b into scope in the ..., but
g :: Foo a b = [a] - [a]
g = ...
would not.  I guess that has the merit that adding the feature would
break fewer programs.

I'm not keen on putting the foralls before the function name.

Simon

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Scoped type variables

[Olaf Chitil]

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 problem with).
 

The binding of a variable is the declaration of the variable. In 
contrast, type variables are never declared in Haskell 98, they are only 
used. In my opinion this lack of an explicit type variable quantifier is 
just acceptable, because all type variables are universally quantified 
and their scope is just the type in which they appear. The very moment 
you allow for wider scopes of type variables the disadvantage of the 
lacking type variable quantifier becomes appearant:

When you see
   f :: a - a
somewhere within an inner where clause you do not know at all if this 
means
   f :: forall a. a - a
or the a is actually quantified somewhere outside and hence f has a 
far more restricted type (because Haskell does not even require you to 
write a type signature next to its variable binding, you have to search 
the *whole* module to find out).

So scoped type variables do not fit Haskell well anyway, but I think 
when added they should at least be an upward compatible extension; any 
Haskell 98 program should still be correct. 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.

Olaf
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Scoped type variables

[Atze Dijkstra]

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 have to write
f (x :: [a]) = body
to bring 'a' into scope.
I've fought against this because it seems funny for a 'forall' in a type
signature to bring a type variable into scope in perhaps-distant
function body, but it's just so convenient and natural.  Furthermore,
as Martin Sulzmann points out, you might have type variables that are
mentioned only in the context of the type:
g :: Foo a b = [a] - [a]
g = ...
GHC provides no way to bring 'b' into scope at the moment, and that
seems bad design.
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 the signature. Related to this, how 
does this work out for signatures of class members and their 
instances, often separated over different files? A change in a type 
variable in a signature in a class inside a library might then break 
my instance of that class. Or is this mechanism only meant for let 
bound values? If not, and if taken to the other extreme, a type 
variable identifier may well become part of the type itself and its 
'meaning'. That is, given a type signature and a value definition 
complying with the signature always has the type variables available. 
The following then also might be admitted:

f :: (forall a . a - a) - ...
v = f (\x - x::a)
Second, for a duplicate introduction of 'a' in:
f :: [a] - [a]
f (x::a) = body
Is the 'a' introduced in 'f (x::a)' shadowing the 'a' introduced in 
'f :: [a] - [a]'? If so, the separation of body and signature is 
slightly less of a problem because the 'a' introduced in the pattern 
will not create a 'duplicate identifier introduction' error message 
or a type mismatch (here between [a] and a).

From a purist point of view I prefer to avoid spreading local 
information globally because we humans can cater with large programs 
only because we keep things local. From a pragmatic point of view as 
a Haskell user the feature seems to be a convenient one indeed. From 
a pragmatic point of view as a Haskell implementor I obviously still 
have questions.

cheers,
--
- Atze -
Atze Dijkstra, Institute of Information  Computing Sciences,/|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands  / | \
Tel.: +31-30-2534093/1454 | WWW  : http://www.cs.uu.nl/~atze   /--|  \
Fax : +31-30-2513971  | Email: [EMAIL PROTECTED]  /   |___\
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Scoped type variables

[Andre Pang]

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 about this, but I've always 
thought that your suggestion is the way it should have been done.  I 
actually find it confusing when someone re-declares the type 
variables in the function body; e.g. in your example of ...

f :: [a] - [a]
f x = my_id x
   where
   my_id :: a - a
   my_id y = y
I would be very much inclined to use a type signature of my_id :: b - 
b, which makes it 100% obvious that it's using a fresh type variable.  
Considering that normal variables are lexically scoped, it seems 
intuitive to me that type variables should also be lexically scoped.

--
% Andre Pang : trust.in.love.to.save
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Scoped type variables

[Jon Fairbairn]

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 and see if that makes anything pop out of someone
else's head.

First, I've never liked the fact that type variables in
signatures aren't declared anywhere -- this was part of the
motivation that drove me to use a non-Hindley-Milner type
system in Ponder. There, you could put a quantifier on an
expression, so instead of 

   f :: [a] - [a]
   f x = body

you could write (mangled to make it look more like Haskell)
stuff like f = forall a.\(x::[a]) - body::[a] and the
scope of a was completely clear.

Of course, this doesn't work with the way variables are
declared in Haskell.

Would it help to stick the quantifier at the beginning of
the type declaration?

   forall a b . g :: Foo a b = [a] - [a]
   g = ...

That reads OK, and one can imagine that whenever you see a
g = ...  bit, you implicitly get the type variables that
come at the front of the type declaration in scope as well.

Doing this would mean that you keep the old behaviour for
cases where there is no quantifier at the beginning of the
type declaration, so things wouldn't break.

 So there it is.  Any one have strong opinions?  (This is
 in addition to the existing mechanism for bringing scoped
 type variables into scope via pattern type signatures, of
 course.)

If I have a strong opinion about anything it's that the only
thing that should bring type variables into scope is a(n
implied) quantifier. Free variables are nasty. I don't hold
out much hope of convincing anyone of this last, though.


  Jón

-- 
Jón Fairbairn [EMAIL PROTECTED]


___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Scoped type variables

[Keean Schupke]

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 in scope in body.   At present in
GHC you have to write
	f (x :: [a]) = body
to bring 'a' into scope. 

I've fought against this because it seems funny for a 'forall' in a type
signature to bring a type variable into scope in perhaps-distant
function body, but it's just so convenient and natural.  Furthermore,
as Martin Sulzmann points out, you might have type variables that are
mentioned only in the context of the type:
g :: Foo a b = [a] - [a]
g = ...
GHC provides no way to bring 'b' into scope at the moment, and that
seems bad design.
If I do this, which I'm inclined to, it could break some programs,
because (with -fglasgow-exts) all type signatures will bring scoped type
variables into scope in their function body.  Here's an example that
will break
f :: [a] - [a]
f x = my_id x
   where
   my_id :: a - a
   my_id y = y
The type signature for my_id will become monomorphic, since 'a' is now
in scope, so the application (my_id x) will fail saying
	can't unify 'a' with '[a]'.  
In some ways that makes sense.  If you used 'b' instead in the defn of
my_id, it'd be fine, because my_id would get the type (forall b. b-b).
Fixing such breakages is easy.

So there it is.   Any one have strong opinions?  (This is in addition to
the existing mechanism for bringing scoped type variables into scope via
pattern type signatures, of course.)
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Scoped type variables

[Abraham Egnor]

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, 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 problem with).

Abe

On Fri, 17 Dec 2004 19:37:00 +, Keean Schupke
[EMAIL PROTECTED] wrote:
 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 in scope in body.   At present in
 GHC you have to write
f (x :: [a]) = body
 to bring 'a' into scope.
 
 I've fought against this because it seems funny for a 'forall' in a type
 signature to bring a type variable into scope in perhaps-distant
 function body, but it's just so convenient and natural.  Furthermore,
 as Martin Sulzmann points out, you might have type variables that are
 mentioned only in the context of the type:
g :: Foo a b = [a] - [a]
g = ...
 GHC provides no way to bring 'b' into scope at the moment, and that
 seems bad design.
 
 
 If I do this, which I'm inclined to, it could break some programs,
 because (with -fglasgow-exts) all type signatures will bring scoped type
 variables into scope in their function body.  Here's an example that
 will break
 
f :: [a] - [a]
f x = my_id x
   where
   my_id :: a - a
   my_id y = y
 
 The type signature for my_id will become monomorphic, since 'a' is now
 in scope, so the application (my_id x) will fail saying
can't unify 'a' with '[a]'.
 In some ways that makes sense.  If you used 'b' instead in the defn of
 my_id, it'd be fine, because my_id would get the type (forall b. b-b).
 Fixing such breakages is easy.
 
 
 So there it is.   Any one have strong opinions?  (This is in addition to
 the existing mechanism for bringing scoped type variables into scope via
 pattern type signatures, of course.)
 
 Simon
 ___
 Glasgow-haskell-users mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 
 
 
 ___
 Glasgow-haskell-users mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users