From john at repetae.net  Tue Jun  3 23:44:38 2014
From: john at repetae.net (John Meacham)
Date: Tue, 3 Jun 2014 16:44:38 -0700
Subject: Command line options for forcing 98 and 2010 mode
Message-ID: <CAM0WKeVAJ=kgGZex343-WFqJy_Hvqvw0B5MWkZBC6mNZ7QjHsQ@mail.gmail.com>

Something that would be useful is command line options that will make
ghc conform to the standards in one shot. I have various programs that
conform to the standards and the onlyrce of incompatibility is the
changing options needed to get ghc to compile them. This is analogous
to how hugs has the -98 flag and the C standard specifies that 'c99'
is an alias to your C compiler that enforces full ISO c99
compatibility.

I was thinking providing ghc98 and ghc2010 command aliases, or making
an option '--std=haskell98'.

another option would be to have -XHaskell98 also modify the package
imports in addition to language features, but this may be undesireable
as then it would behave differently when specified in a LANGUAGE
pragma.

     John

-- 
John Meacham - http://notanumber.net/

From john at repetae.net  Tue Jun 10 22:21:25 2014
From: john at repetae.net (John Meacham)
Date: Tue, 10 Jun 2014 15:21:25 -0700
Subject: AlternateLayoutRule
In-Reply-To: <CAM0WKeUA=hkjXX-rMuOUKROoGbiq4ARrOk1Q9K6KFneNTFVMMw@mail.gmail.com>
References: <CAM0WKeX4A7_MWfKnqw=HXA2-rv4xTMtuB0Y8nKNxxU1r7Knp2A@mail.gmail.com>
 <5372815F.40807@gmail.com> <20140513212223.GA4774@matrix.chaos.earth.li>
 <CAM0WKeWJbOObJ+FhhsnhwTy1ojcNu71fSWpDNZF++xc=VCrjRQ@mail.gmail.com>
 <20140513223255.GA6385@matrix.chaos.earth.li>
 <CAM0WKeVTdNc=EnH-77daVP8NNGKWsUkx+RYTfaK8=Nzc+G-nHA@mail.gmail.com>
 <20140514142951.GA16968@matrix.chaos.earth.li>
 <CAM0WKeUA=hkjXX-rMuOUKROoGbiq4ARrOk1Q9K6KFneNTFVMMw@mail.gmail.com>
Message-ID: <CAM0WKeXz5=ww-K0UrkaHvzTeMZJc6o=VgF0a5TOOiu7Yo3VmRQ@mail.gmail.com>

After some work, I have replaced jhcs front end with one using an
AlternateLayoutRule and it passes ghc's parsing regression tests. I
had to make some modifications so the code so it isn't as pretty as
I'd like, I'll see if I can distill the essence out into something
concrete.

Incidentally, I found a particularly troublesome case for the current
ghc rule out in the wild during my testing:

-- Lining up |'s and indenting new blocks 4 spaces. A fairly common practice.
bar x y = case x of
    Just z | y > z*2 -> case y of
        _ -> y
           | y > z -> y*10
    _  -> 1

bar (Just 2) 3  => 30

--add a constant true guard that should be a nop
bar x y = case x of
    Just z | y > z*2 -> case y of
        _ | True -> y              <=== added a no-op guard
           | y > z -> y*10
    _  -> 1

bar (Just 2) 3  => 1

The pattern match was fairly complicated making what happened pretty obscure.

One of the main benefits I have found is being able to process the
token stream between the lexer and parser, which drastically
simplified my parser making it almost shift/reduce conflict free. I
turn (+) and  case into single lexemes and turned reservedids into
varids for the keywords of unenabled extensions.

        John

-- John Meacham - http://notanumber.net/

From mikhail.vorozhtsov at gmail.com  Sat Jun 14 14:48:16 2014
From: mikhail.vorozhtsov at gmail.com (Mikhail Vorozhtsov)
Date: Sat, 14 Jun 2014 18:48:16 +0400
Subject: RFC: Unicode primes and super/subscript characters in GHC
Message-ID: <539C60B0.6010007@gmail.com>

Hello lists,

As some of you may know, GHC's support for Unicode characters in lexemes 
is rather crude and hence prone to inconsistencies in their handling 
versus the ASCII counterparts. For example, APOSTROPHE is treated 
differently from PRIME:

?> data a +' b = Plus a b
<interactive>:3:9:
     Unexpected type ?b?
     In the data declaration for ?+?
     A data declaration should have form
       data + a b c = ...
?> data a +? b = Plus a b

?> let a' = 1
?> let a? = 1
<interactive>:10:8: parse error on input ?=?

Also some rather bizarre looking things are accepted:

?> let ?x?y = 1

In the spirit of improving things little by little I would like to propose:

1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as 
APOSTROPHE, meaning the following alterations to the lexer:

primes -> U+2032 | U+2033 | U+2034 | U+2057
symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
graphic -> small | large | symbol | digit | special | " | ' | primes
varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid)
conid -> large { small | large | digit | ' | primes }

2. Introduce a new lexer nonterminal "subsup" that would include the 
Unicode sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")", 
Latin and Greek letters. And allow these characters to be used in names 
and operators:

symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes | 
subsup )
digit -> ascDigit | uniDigit (EXCEPT subsup)
small -> ascSmall | uniSmall (EXCEPT subsup) | _
large -> ascLarge | uniLarge (EXCEPT subsup)
graphic -> small | large | symbol | digit | special | " | ' | primes | 
subsup
varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT 
reservedid)
conid -> large { small | large | digit | ' | primes | subsup }
varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes)
consym -> (: {symbol | subsup}) (EXCEPT reservedop)

If this proposal is received favorably, I'll write a patch for GHC based 
on my previous stab at the problem[2].

P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion 
to the GHC users list.

[1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
[2] https://ghc.haskell.org/trac/ghc/ticket/5108

From john at repetae.net  Sat Jun 14 23:58:14 2014
From: john at repetae.net (John Meacham)
Date: Sat, 14 Jun 2014 16:58:14 -0700
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <539C60B0.6010007@gmail.com>
References: <539C60B0.6010007@gmail.com>
Message-ID: <CAM0WKeXbxqm9HcLn53Wn6RE=BMdD5qEJFp2pu_D8F1T+u6qaZg@mail.gmail.com>

I have this feature in jhc, where I have a 'trailing' character class
that can appear at the end of both symbols and ids.

currently it consists of

 $trailing = [??????????????????????????]

 John

On Sat, Jun 14, 2014 at 7:48 AM, Mikhail Vorozhtsov
<mikhail.vorozhtsov at gmail.com> wrote:
> Hello lists,
>
> As some of you may know, GHC's support for Unicode characters in lexemes is
> rather crude and hence prone to inconsistencies in their handling versus the
> ASCII counterparts. For example, APOSTROPHE is treated differently from
> PRIME:
>
> ?> data a +' b = Plus a b
> <interactive>:3:9:
>     Unexpected type ?b?
>     In the data declaration for ?+?
>     A data declaration should have form
>       data + a b c = ...
> ?> data a +? b = Plus a b
>
> ?> let a' = 1
> ?> let a? = 1
> <interactive>:10:8: parse error on input ?=?
>
> Also some rather bizarre looking things are accepted:
>
> ?> let ?x?y = 1
>
> In the spirit of improving things little by little I would like to propose:
>
> 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as
> APOSTROPHE, meaning the following alterations to the lexer:
>
> primes -> U+2032 | U+2033 | U+2034 | U+2057
> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
> graphic -> small | large | symbol | digit | special | " | ' | primes
> varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid)
> conid -> large { small | large | digit | ' | primes }
>
> 2. Introduce a new lexer nonterminal "subsup" that would include the Unicode
> sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")", Latin and
> Greek letters. And allow these characters to be used in names and operators:
>
> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes |
> subsup )
> digit -> ascDigit | uniDigit (EXCEPT subsup)
> small -> ascSmall | uniSmall (EXCEPT subsup) | _
> large -> ascLarge | uniLarge (EXCEPT subsup)
> graphic -> small | large | symbol | digit | special | " | ' | primes |
> subsup
> varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT
> reservedid)
> conid -> large { small | large | digit | ' | primes | subsup }
> varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes)
> consym -> (: {symbol | subsup}) (EXCEPT reservedop)
>
> If this proposal is received favorably, I'll write a patch for GHC based on
> my previous stab at the problem[2].
>
> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion to
> the GHC users list.
>
> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
John Meacham - http://notanumber.net/

From fuuzetsu at fuuzetsu.co.uk  Mon Jun 16 00:26:49 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Mon, 16 Jun 2014 02:26:49 +0200
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <539C60B0.6010007@gmail.com>
References: <539C60B0.6010007@gmail.com>
Message-ID: <539E39C9.9010206@fuuzetsu.co.uk>

On 06/14/2014 04:48 PM, Mikhail Vorozhtsov wrote:
> Hello lists,
> 
> As some of you may know, GHC's support for Unicode characters in lexemes 
> is rather crude and hence prone to inconsistencies in their handling 
> versus the ASCII counterparts. For example, APOSTROPHE is treated 
> differently from PRIME:
> 
> ?> data a +' b = Plus a b
> <interactive>:3:9:
>      Unexpected type ?b?
>      In the data declaration for ?+?
>      A data declaration should have form
>        data + a b c = ...
> ?> data a +? b = Plus a b
> 
> ?> let a' = 1
> ?> let a? = 1
> <interactive>:10:8: parse error on input ?=?
> 
> Also some rather bizarre looking things are accepted:
> 
> ?> let ?x?y = 1
> 
> In the spirit of improving things little by little I would like to propose:
> 
> 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as 
> APOSTROPHE, meaning the following alterations to the lexer:
> 
> primes -> U+2032 | U+2033 | U+2034 | U+2057
> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
> graphic -> small | large | symbol | digit | special | " | ' | primes
> varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid)
> conid -> large { small | large | digit | ' | primes }
> 
> 2. Introduce a new lexer nonterminal "subsup" that would include the 
> Unicode sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")", 
> Latin and Greek letters. And allow these characters to be used in names 
> and operators:
> 
> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes | 
> subsup )
> digit -> ascDigit | uniDigit (EXCEPT subsup)
> small -> ascSmall | uniSmall (EXCEPT subsup) | _
> large -> ascLarge | uniLarge (EXCEPT subsup)
> graphic -> small | large | symbol | digit | special | " | ' | primes | 
> subsup
> varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT 
> reservedid)
> conid -> large { small | large | digit | ' | primes | subsup }
> varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes)
> consym -> (: {symbol | subsup}) (EXCEPT reservedop)
> 
> If this proposal is received favorably, I'll write a patch for GHC based 
> on my previous stab at the problem[2].
> 
> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion 
> to the GHC users list.
> 
> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

While personally I like the proposal (wanted prime and sub/sup scripts
way too many times), I worry what this means for compatibility reasons:
suddenly we'll have code that fails to build on 7.8 and before because
someone using 7.9/7.10+ used ? somewhere. Even using CPP based on
version of the compiler used is not too great in this scenario because
it doesn't bring significant practical advantage to justify the CPP
clutter in code. If the choice is either extra lines due to CPP or using
?'? instead of ???, I know which I'll go for.

I also worry (although not based on anything particular you said)
whether this will not change meaning of any existing programs. Does it
only allow new programs?

Will it be enabled by a pragma?

I simply worry about how practical it will be to use for actual programs
and libraries that will go out on Hackage and wider world, even if it is
accepted.

-- 
Mateusz K.

From hvr at gnu.org  Mon Jun 16 07:44:06 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 16 Jun 2014 09:44:06 +0200
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <539E39C9.9010206@fuuzetsu.co.uk> (Mateusz Kowalczyk's message of
 "Mon, 16 Jun 2014 02:26:49 +0200")
References: <539C60B0.6010007@gmail.com> <539E39C9.9010206@fuuzetsu.co.uk>
Message-ID: <87egyp1epl.fsf@gnu.org>

On 2014-06-16 at 02:26:49 +0200, Mateusz Kowalczyk wrote:

[...]

> While personally I like the proposal (wanted prime and sub/sup scripts
> way too many times), I worry what this means for compatibility reasons:
> suddenly we'll have code that fails to build on 7.8 and before because
> someone using 7.9/7.10+ used ? somewhere. 

Fwiw, we already had that situation. The following code

    {-# LANGUAGE UnicodeSyntax #-}
    
    module Foo where
    
    x? ? Double
    x? = 1.5

compiles with GHC ? 7.2, but with GHC 7.0 fails with:

    GHCi, version 7.0.4: http://www.haskell.org/ghc/  :? for help
    [1 of 1] Compiling Foo              ( foo.hs, interpreted )
    
    foo.hs:5:2: lexical error at character '\8320'
    Failed, modules loaded: none.


Cheers,
  hvr

From mikhail.vorozhtsov at gmail.com  Mon Jun 16 16:41:46 2014
From: mikhail.vorozhtsov at gmail.com (Mikhail Vorozhtsov)
Date: Mon, 16 Jun 2014 20:41:46 +0400
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <539E39C9.9010206@fuuzetsu.co.uk>
References: <539C60B0.6010007@gmail.com> <539E39C9.9010206@fuuzetsu.co.uk>
Message-ID: <539F1E4A.9080504@gmail.com>

On 06/16/2014 04:26 AM, Mateusz Kowalczyk wrote:
> On 06/14/2014 04:48 PM, Mikhail Vorozhtsov wrote:
>> Hello lists,
>>
>> As some of you may know, GHC's support for Unicode characters in lexemes
>> is rather crude and hence prone to inconsistencies in their handling
>> versus the ASCII counterparts. For example, APOSTROPHE is treated
>> differently from PRIME:
>>
>> ?> data a +' b = Plus a b
>> <interactive>:3:9:
>>       Unexpected type ?b?
>>       In the data declaration for ?+?
>>       A data declaration should have form
>>         data + a b c = ...
>> ?> data a +? b = Plus a b
>>
>> ?> let a' = 1
>> ?> let a? = 1
>> <interactive>:10:8: parse error on input ?=?
>>
>> Also some rather bizarre looking things are accepted:
>>
>> ?> let ?x?y = 1
>>
>> In the spirit of improving things little by little I would like to propose:
>>
>> 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as
>> APOSTROPHE, meaning the following alterations to the lexer:
>>
>> primes -> U+2032 | U+2033 | U+2034 | U+2057
>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
>> graphic -> small | large | symbol | digit | special | " | ' | primes
>> varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid)
>> conid -> large { small | large | digit | ' | primes }
>>
>> 2. Introduce a new lexer nonterminal "subsup" that would include the
>> Unicode sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")",
>> Latin and Greek letters. And allow these characters to be used in names
>> and operators:
>>
>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes |
>> subsup )
>> digit -> ascDigit | uniDigit (EXCEPT subsup)
>> small -> ascSmall | uniSmall (EXCEPT subsup) | _
>> large -> ascLarge | uniLarge (EXCEPT subsup)
>> graphic -> small | large | symbol | digit | special | " | ' | primes |
>> subsup
>> varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT
>> reservedid)
>> conid -> large { small | large | digit | ' | primes | subsup }
>> varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes)
>> consym -> (: {symbol | subsup}) (EXCEPT reservedop)
>>
>> If this proposal is received favorably, I'll write a patch for GHC based
>> on my previous stab at the problem[2].
>>
>> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion
>> to the GHC users list.
>>
>> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
>> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
> While personally I like the proposal (wanted prime and sub/sup scripts
> way too many times), I worry what this means for compatibility reasons:
> suddenly we'll have code that fails to build on 7.8 and before because
> someone using 7.9/7.10+ used ? somewhere. Even using CPP based on
> version of the compiler used is not too great in this scenario because
> it doesn't bring significant practical advantage to justify the CPP
> clutter in code. If the choice is either extra lines due to CPP or using
> ?'? instead of ???, I know which I'll go for.

Currently GHC categorizes Unicode PRIME as a "symbol", which means that 
it is allowed to appear only in operators (varsym and consym). So yes, 
if somebody is using things like "+?" or ":+?" (and they really 
shouldn't), they would be hit by this change. Identifiers like "?x" 
would become illegal too. I'd be surprised to find an actual Hackage 
library that does that though.

>
> I also worry (although not based on anything particular you said)
> whether this will not change meaning of any existing programs. Does it
> only allow new programs?

As far as I can see, no change in meaning. Some hacky operators and some 
hacky identifiers would become illegal. And some nicer ones would become 
legal.

>
> Will it be enabled by a pragma?

No, GHC accepts Unicode input without any pragmas.

>
> I simply worry about how practical it will be to use for actual programs
> and libraries that will go out on Hackage and wider world, even if it is
> accepted.
>

From johnw at newartisans.com  Mon Jun 16 22:27:21 2014
From: johnw at newartisans.com (John Wiegley)
Date: Mon, 16 Jun 2014 15:27:21 -0700
Subject: Regression in the typechecker in GHC 7.8.2
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E2819@DB3PRD3001MB020.064d.mgd.msft.net>
 (Simon Peyton Jones's message of "Mon, 16 Jun 2014 12:59:30 +0000")
References: <20140616104537.30015.qmail@www1.g3.pair.com>
 <618BE556AADD624C9C918AA5D5911BEF103E2819@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <m2fvj4lcc6.fsf@newartisans.com>

>>>>> Simon Peyton Jones <simonpj at microsoft.com> writes:

> Copying ghc-devs.  Oleg says:
> |         Sorry for reporting a problem via e-mail. It seems track no
> | longer accepts anonymous (guest) submissions. When I tried to register
> | the account I was told that my submission is a spam. The tracker is
> | really well protected.

> Can anyone help him? I'll open a ticket.

This has been discussed before BTW:

    http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/4239

So it looks like Herbert is the one to contact.

John

From tsuyoshi.ito.2006 at gmail.com  Mon Jun 16 23:13:27 2014
From: tsuyoshi.ito.2006 at gmail.com (Tsuyoshi Ito)
Date: Tue, 17 Jun 2014 08:13:27 +0900
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <539F1E4A.9080504@gmail.com>
References: <539C60B0.6010007@gmail.com> <539E39C9.9010206@fuuzetsu.co.uk>
 <539F1E4A.9080504@gmail.com>
Message-ID: <CALyF_gSkTyO8=Brr6kM9T-fx=bDZsb-a47FSFWX54yZXvPkrgw@mail.gmail.com>

Hello,

Mikhail Vorozhtsov <mikhail.vorozhtsov at gmail.com> wrote:
>> I also worry (although not based on anything particular you said)
>> whether this will not change meaning of any existing programs. Does it
>> only allow new programs?
>
> As far as I can see, no change in meaning. Some hacky operators and some
> hacky identifiers would become illegal. And some nicer ones would become
> legal.

I do not have an opinion for or against the proposal, but I just
wanted to point out that the proposal changes the meaning of some
programs, at least in theory.  The following function currently
evaluates to True, but with the proposed change, I think that it will
evaluate to False.

test =
  let a = ()
      b = ()
      a?b = False in
  let c?d = True in
  a?b

Best regards,
Tsuyoshi

From mikhail.vorozhtsov at gmail.com  Tue Jun 17 12:55:55 2014
From: mikhail.vorozhtsov at gmail.com (Mikhail Vorozhtsov)
Date: Tue, 17 Jun 2014 16:55:55 +0400
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <CALyF_gSkTyO8=Brr6kM9T-fx=bDZsb-a47FSFWX54yZXvPkrgw@mail.gmail.com>
References: <539C60B0.6010007@gmail.com> <539E39C9.9010206@fuuzetsu.co.uk>
 <539F1E4A.9080504@gmail.com>
 <CALyF_gSkTyO8=Brr6kM9T-fx=bDZsb-a47FSFWX54yZXvPkrgw@mail.gmail.com>
Message-ID: <53A03ADB.8060306@gmail.com>

On 06/17/2014 03:13 AM, Tsuyoshi Ito wrote:
> Hello,
>
> Mikhail Vorozhtsov <mikhail.vorozhtsov at gmail.com> wrote:
>>> I also worry (although not based on anything particular you said)
>>> whether this will not change meaning of any existing programs. Does it
>>> only allow new programs?
>> As far as I can see, no change in meaning. Some hacky operators and some
>> hacky identifiers would become illegal. And some nicer ones would become
>> legal.
> I do not have an opinion for or against the proposal, but I just
> wanted to point out that the proposal changes the meaning of some
> programs, at least in theory.  The following function currently
> evaluates to True, but with the proposed change, I think that it will
> evaluate to False.
>
> test =
>    let a = ()
>        b = ()
>        a?b = False in
>    let c?d = True in
>    a?b
>
> Best regards,
> Tsuyoshi
Good catch. Indeed, PRIME will no longer be a valid operator.

From john at repetae.net  Tue Jun 17 14:19:16 2014
From: john at repetae.net (John Meacham)
Date: Tue, 17 Jun 2014 07:19:16 -0700
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <539E39C9.9010206@fuuzetsu.co.uk>
References: <539C60B0.6010007@gmail.com> <539E39C9.9010206@fuuzetsu.co.uk>
Message-ID: <CAM0WKeU25CweGmewLd1dOgs1BsAREHeuXagib3ibJ9q-tK7hfA@mail.gmail.com>

Don't forget that for every line of haskell code on hackage there are
dozens of lines used internally within organizations where
compatibility beyond their target internal tools may not be a concern.
Deciding on a policy of allowing primes or whatnot within an
organization seems quite plausible and doesn't entail CPP concerns.

    John

On Sun, Jun 15, 2014 at 5:26 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 06/14/2014 04:48 PM, Mikhail Vorozhtsov wrote:
>> Hello lists,
>>
>> As some of you may know, GHC's support for Unicode characters in lexemes
>> is rather crude and hence prone to inconsistencies in their handling
>> versus the ASCII counterparts. For example, APOSTROPHE is treated
>> differently from PRIME:
>>
>> ?> data a +' b = Plus a b
>> <interactive>:3:9:
>>      Unexpected type ?b?
>>      In the data declaration for ?+?
>>      A data declaration should have form
>>        data + a b c = ...
>> ?> data a +? b = Plus a b
>>
>> ?> let a' = 1
>> ?> let a? = 1
>> <interactive>:10:8: parse error on input ?=?
>>
>> Also some rather bizarre looking things are accepted:
>>
>> ?> let ?x?y = 1
>>
>> In the spirit of improving things little by little I would like to propose:
>>
>> 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as
>> APOSTROPHE, meaning the following alterations to the lexer:
>>
>> primes -> U+2032 | U+2033 | U+2034 | U+2057
>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
>> graphic -> small | large | symbol | digit | special | " | ' | primes
>> varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid)
>> conid -> large { small | large | digit | ' | primes }
>>
>> 2. Introduce a new lexer nonterminal "subsup" that would include the
>> Unicode sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")",
>> Latin and Greek letters. And allow these characters to be used in names
>> and operators:
>>
>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes |
>> subsup )
>> digit -> ascDigit | uniDigit (EXCEPT subsup)
>> small -> ascSmall | uniSmall (EXCEPT subsup) | _
>> large -> ascLarge | uniLarge (EXCEPT subsup)
>> graphic -> small | large | symbol | digit | special | " | ' | primes |
>> subsup
>> varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT
>> reservedid)
>> conid -> large { small | large | digit | ' | primes | subsup }
>> varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes)
>> consym -> (: {symbol | subsup}) (EXCEPT reservedop)
>>
>> If this proposal is received favorably, I'll write a patch for GHC based
>> on my previous stab at the problem[2].
>>
>> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion
>> to the GHC users list.
>>
>> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
>> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
> While personally I like the proposal (wanted prime and sub/sup scripts
> way too many times), I worry what this means for compatibility reasons:
> suddenly we'll have code that fails to build on 7.8 and before because
> someone using 7.9/7.10+ used ? somewhere. Even using CPP based on
> version of the compiler used is not too great in this scenario because
> it doesn't bring significant practical advantage to justify the CPP
> clutter in code. If the choice is either extra lines due to CPP or using
> ?'? instead of ???, I know which I'll go for.
>
> I also worry (although not based on anything particular you said)
> whether this will not change meaning of any existing programs. Does it
> only allow new programs?
>
> Will it be enabled by a pragma?
>
> I simply worry about how practical it will be to use for actual programs
> and libraries that will go out on Hackage and wider world, even if it is
> accepted.
>
> --
> Mateusz K.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
John Meacham - http://notanumber.net/

From conal at conal.net  Thu Jun 19 19:28:26 2014
From: conal at conal.net (Conal Elliott)
Date: Thu, 19 Jun 2014 12:28:26 -0700
Subject: Monomorphizing GHC Core?
Message-ID: <CAD6SzR++FZO3kc2eRXvs-2iHNyqCvZE9A1Ro9vXE+rSqST8TWQ@mail.gmail.com>

Has anyone worked on a monomorphizing transformation for GHC Core? I
understand that polymorphic recursion presents a challenge, and I do indeed
want to work with polymorphic recursion but only on types for which the
recursion bottoms out statically (i.e., each recursive call is on a smaller
type). I'm aiming at writing high-level polymorphic code and generating
monomorphic code on unboxed values. This work is part of a project for
compiling Haskell to hardware, described on my blog (http://conal.net).

Thanks,  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140619/30f0b19f/attachment.html>

From ekmett at gmail.com  Thu Jun 19 20:22:44 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 19 Jun 2014 16:22:44 -0400
Subject: Monomorphizing GHC Core?
In-Reply-To: <CAD6SzR++FZO3kc2eRXvs-2iHNyqCvZE9A1Ro9vXE+rSqST8TWQ@mail.gmail.com>
References: <CAD6SzR++FZO3kc2eRXvs-2iHNyqCvZE9A1Ro9vXE+rSqST8TWQ@mail.gmail.com>
Message-ID: <CAJumaK-4mmzxvDb=+Bxo3OtQLno2n5wqKV7W7JLQyp_Mw5Qw6Q@mail.gmail.com>

Might you have more success with a Reynolds style defunctionalization pass
for the polymorphic recursion you can't eliminate?

Then you wouldn't have to rule out things like

data Complete a = S (Complete (a,a)) | Z a

which don't pass that test.

-Edward


On Thu, Jun 19, 2014 at 3:28 PM, Conal Elliott <conal at conal.net> wrote:

> Has anyone worked on a monomorphizing transformation for GHC Core? I
> understand that polymorphic recursion presents a challenge, and I do indeed
> want to work with polymorphic recursion but only on types for which the
> recursion bottoms out statically (i.e., each recursive call is on a smaller
> type). I'm aiming at writing high-level polymorphic code and generating
> monomorphic code on unboxed values. This work is part of a project for
> compiling Haskell to hardware, described on my blog (http://conal.net).
>
> Thanks,  - Conal
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140619/6accfe68/attachment.html>

From conal at conal.net  Thu Jun 19 20:49:15 2014
From: conal at conal.net (Conal Elliott)
Date: Thu, 19 Jun 2014 13:49:15 -0700
Subject: Monomorphizing GHC Core?
In-Reply-To: <CAJumaK-4mmzxvDb=+Bxo3OtQLno2n5wqKV7W7JLQyp_Mw5Qw6Q@mail.gmail.com>
References: <CAD6SzR++FZO3kc2eRXvs-2iHNyqCvZE9A1Ro9vXE+rSqST8TWQ@mail.gmail.com>
 <CAJumaK-4mmzxvDb=+Bxo3OtQLno2n5wqKV7W7JLQyp_Mw5Qw6Q@mail.gmail.com>
Message-ID: <CAD6SzR+NmsX6GvNq9FT2y5JKYzoJvmVMuzOexdfrym2v2kQJuw@mail.gmail.com>

Thanks, Ed. It hadn't occurred to me that defunctionalization might be
useful for monomorphization. Do you know of a connection?

I'm using a perfect leaf tree type similar to the one you mentioned but
indexed by depth:

> data Tree :: (* -> *) -> Nat -> * -> * where
>   L :: a -> Tree k 0 a
>   B :: Tree k n (k a) -> Tree k (1+n) a

Similarly for "top-down" perfect leaf trees:

> data Tree :: (* -> *) -> Nat -> * -> * where
>   L :: a -> Tree k 0 a
>   B :: k (Tree k n a) -> Tree k (1+n) a

This way, after monomorphization, there won't be any sums remaining.

  -- Conal


On Thu, Jun 19, 2014 at 1:22 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Might you have more success with a Reynolds style defunctionalization pass
> for the polymorphic recursion you can't eliminate?
>
> Then you wouldn't have to rule out things like
>
> data Complete a = S (Complete (a,a)) | Z a
>
> which don't pass that test.
>
> -Edward
>
>
> On Thu, Jun 19, 2014 at 3:28 PM, Conal Elliott <conal at conal.net> wrote:
>
>>  Has anyone worked on a monomorphizing transformation for GHC Core? I
>> understand that polymorphic recursion presents a challenge, and I do indeed
>> want to work with polymorphic recursion but only on types for which the
>> recursion bottoms out statically (i.e., each recursive call is on a smaller
>> type). I'm aiming at writing high-level polymorphic code and generating
>> monomorphic code on unboxed values. This work is part of a project for
>> compiling Haskell to hardware, described on my blog (http://conal.net).
>>
>> Thanks,  - Conal
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140619/cb05a311/attachment.html>

From ekmett at gmail.com  Thu Jun 19 21:27:27 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 19 Jun 2014 17:27:27 -0400
Subject: Monomorphizing GHC Core?
In-Reply-To: <CAD6SzR+NmsX6GvNq9FT2y5JKYzoJvmVMuzOexdfrym2v2kQJuw@mail.gmail.com>
References: <CAD6SzR++FZO3kc2eRXvs-2iHNyqCvZE9A1Ro9vXE+rSqST8TWQ@mail.gmail.com>
 <CAJumaK-4mmzxvDb=+Bxo3OtQLno2n5wqKV7W7JLQyp_Mw5Qw6Q@mail.gmail.com>
 <CAD6SzR+NmsX6GvNq9FT2y5JKYzoJvmVMuzOexdfrym2v2kQJuw@mail.gmail.com>
Message-ID: <CAJumaK_K49i7qxpjZ=CRTnxeQUOtFQremL7_zL-QBBYRF=si=A@mail.gmail.com>

I think the first time I saw a connection to polymorphic recursion was in
Neil Mitchell's supero, which used it as a catch-all fallback plan.

http://community.haskell.org/~ndm/downloads/slides-haskell_with_go_faster_stripes-30_nov_2006.pdf

-Edward


On Thu, Jun 19, 2014 at 4:49 PM, Conal Elliott <conal at conal.net> wrote:

> Thanks, Ed. It hadn't occurred to me that defunctionalization might be
> useful for monomorphization. Do you know of a connection?
>
> I'm using a perfect leaf tree type similar to the one you mentioned but
> indexed by depth:
>
> > data Tree :: (* -> *) -> Nat -> * -> * where
> >   L :: a -> Tree k 0 a
> >   B :: Tree k n (k a) -> Tree k (1+n) a
>
> Similarly for "top-down" perfect leaf trees:
>
> > data Tree :: (* -> *) -> Nat -> * -> * where
> >   L :: a -> Tree k 0 a
> >   B :: k (Tree k n a) -> Tree k (1+n) a
>
> This way, after monomorphization, there won't be any sums remaining.
>
>   -- Conal
>
>
>
> On Thu, Jun 19, 2014 at 1:22 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Might you have more success with a Reynolds style defunctionalization
>> pass for the polymorphic recursion you can't eliminate?
>>
>> Then you wouldn't have to rule out things like
>>
>> data Complete a = S (Complete (a,a)) | Z a
>>
>> which don't pass that test.
>>
>> -Edward
>>
>>
>> On Thu, Jun 19, 2014 at 3:28 PM, Conal Elliott <conal at conal.net> wrote:
>>
>>>  Has anyone worked on a monomorphizing transformation for GHC Core? I
>>> understand that polymorphic recursion presents a challenge, and I do indeed
>>> want to work with polymorphic recursion but only on types for which the
>>> recursion bottoms out statically (i.e., each recursive call is on a smaller
>>> type). I'm aiming at writing high-level polymorphic code and generating
>>> monomorphic code on unboxed values. This work is part of a project for
>>> compiling Haskell to hardware, described on my blog (http://conal.net).
>>>
>>> Thanks,  - Conal
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140619/bcf713e1/attachment.html>

From john at repetae.net  Sat Jun 21 02:11:14 2014
From: john at repetae.net (John Meacham)
Date: Fri, 20 Jun 2014 19:11:14 -0700
Subject: Monomorphizing GHC Core?
In-Reply-To: <CAD6SzR++FZO3kc2eRXvs-2iHNyqCvZE9A1Ro9vXE+rSqST8TWQ@mail.gmail.com>
References: <CAD6SzR++FZO3kc2eRXvs-2iHNyqCvZE9A1Ro9vXE+rSqST8TWQ@mail.gmail.com>
Message-ID: <CAM0WKeX+kkGDXdCahP5sBc0ouyMpbcpswKZXQYDwEa_wLkcbrw@mail.gmail.com>

I do that with jhc to allow compilation to bare hardware. The Grin
intermediate language is neither polymorphic nor higher order.
Basically, in involves adding a sprinkling of type coercions and
conjuring up some types that reflect the 'shape' of the data without
being self-referential. so I don't do it til fairly late in the
lambda-cube optimization passes because it loses some information. I
wonder if the explicit coercions in system Fc used by ghc now will
allow a more principled approach.

    John

On Thu, Jun 19, 2014 at 12:28 PM, Conal Elliott <conal at conal.net> wrote:
> Has anyone worked on a monomorphizing transformation for GHC Core? I
> understand that polymorphic recursion presents a challenge, and I do indeed
> want to work with polymorphic recursion but only on types for which the
> recursion bottoms out statically (i.e., each recursive call is on a smaller
> type). I'm aiming at writing high-level polymorphic code and generating
> monomorphic code on unboxed values. This work is part of a project for
> compiling Haskell to hardware, described on my blog (http://conal.net).
>
> Thanks,  - Conal
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
John Meacham - http://notanumber.net/

From simonpj at microsoft.com  Mon Jun 23 16:36:00 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Jun 2014 16:36:00 +0000
Subject: Associated type instances
Message-ID: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net>

Friends
I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack.
Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
All of this arose when thinking about fixing Trac #9063.
I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10).
Does anyone object?
Thanks
Simon

The issue
Consider this:

class C a where

   type T a b :: *



instance C [x] where

   type T [x] b = x -> b
That is just what you'd expect.  But currently this is allowed too:

instance C [x] where

   type T [x] Int = x -> Int

   type T [x] Bool = Bool -> x
That is, GHC 7.8 allows many associated type instances, provided they don't overlap.  But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed:

instance C [x] where

   type T [Int] b = b -> Int

   type T [Bool] b = Bool -> b
Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like

class D a where

   type S (b :: Bool) a :: *
Now this would make some kind of sense:

instance D [x] where

   type S True [x] = x -> x

   type S False [x] = x
But for closed kinds, you really want a closed type family.  So this would be better:

instance D [x] where

   type S b [x] = SHelp x b



type family SHelp x b where

  SHelp x True = x -> x

  SHelp x False = x


So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange.
All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect.
My solution
I propose to simplify substantially, as follows:

*         The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header.  So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared.

*         A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have

o   type variables in the non-shared argument positions, and

o   an exact copy of the corresponding instance header type in the shared positions

*         For each associated type you can have

o   at most one default declaration in the class declaration

o   at most one type instance declaration in the class instance declaration


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140623/70a2ff7d/attachment.html>

From chak at cse.unsw.edu.au  Tue Jun 24 08:05:40 2014
From: chak at cse.unsw.edu.au (Manuel M T Chakravarty)
Date: Tue, 24 Jun 2014 18:05:40 +1000
Subject: Associated type instances
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <F5A0B1DB-21C6-4117-ADF9-E4D9DF653763@cse.unsw.edu.au>

Simon,

I?m not sure when this ?feature? was added, but I?m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything?

Manuel

Simon Peyton Jones <simonpj at microsoft.com>:
> Friends
> 
> I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack.
> 
> Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
> 
> All of this arose when thinking about fixing Trac #9063.
> 
> I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). 
> 
> Does anyone object?
> 
> Thanks
> 
> Simon
> 
>  
> 
> The issue
> 
> Consider this:
> 
> class C a where
>    type T a b :: *
>  
> instance C [x] where
>    type T [x] b = x -> b
> That is just what you?d expect.  But currently this is allowed too:
> 
> instance C [x] where
>    type T [x] Int = x -> Int
>    type T [x] Bool = Bool -> x
> That is, GHC 7.8 allows many associated type instances, provided they don?t overlap.  But, oddly you can?t further instantiate the instance pattern. This would make just as much sense, but isn?t allowed:
> 
> instance C [x] where
>    type T [Int] b = b -> Int
>    type T [Bool] b = Bool -> b
> Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like
> 
> class D a where
>    type S (b :: Bool) a :: *
> Now this would make some kind of sense:
> 
> instance D [x] where
>    type S True [x] = x -> x
>    type S False [x] = x
> But for closed kinds, you really want a closed type family.  So this would be better:
> 
> instance D [x] where
>    type S b [x] = SHelp x b
>  
> type family SHelp x b where
>   SHelp x True = x -> x
>   SHelp x False = x
>  
> So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange.
> 
> All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it?s a bit more complicated and indirect.
> 
> My solution
> 
> I propose to simplify substantially, as follows:
> 
> ?         The ?shared arguments? of an associated type are the argument positions that mention a type variable from the class header.  So in class C above, the first argument position of T is ?shared?; and in class D, the second argument position of S is shared.
> 
> ?         A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have
> 
> o   type variables in the non-shared argument positions, and
> 
> o   an exact copy of the corresponding instance header type in the shared positions
> 
> ?         For each associated type you can have
> 
> o   at most one default declaration in the class declaration
> 
> o   at most one type instance declaration in the class instance declaration
> 
>  
> 
>  
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140624/01a80695/attachment-0001.html>

From simonpj at microsoft.com  Tue Jun 24 08:07:02 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Jun 2014 08:07:02 +0000
Subject: Associated type instances
In-Reply-To: <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com>
References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net>
 <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net>

I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything?

I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting!   But I'm just checking that no one has meanwhile become addicted to it.

Simon

From: Manuel Chakravarty [mailto:mchakravarty at me.com]
Sent: 24 June 2014 08:54
To: Simon Peyton Jones
Cc: GHC List; ghc-devs at haskell.org
Subject: Re: Associated type instances

Simon,

I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything?

Manuel

Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>:
Friends
I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack.
Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
All of this arose when thinking about fixing Trac #9063.
I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10).
Does anyone object?
Thanks
Simon

The issue
Consider this:
class C a where
   type T a b :: *

instance C [x] where
   type T [x] b = x -> b
That is just what you'd expect.  But currently this is allowed too:
instance C [x] where
   type T [x] Int = x -> Int
   type T [x] Bool = Bool -> x
That is, GHC 7.8 allows many associated type instances, provided they don't overlap.  But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed:
instance C [x] where
   type T [Int] b = b -> Int
   type T [Bool] b = Bool -> b
Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like
class D a where
   type S (b :: Bool) a :: *
Now this would make some kind of sense:
instance D [x] where
   type S True [x] = x -> x
   type S False [x] = x
But for closed kinds, you really want a closed type family.  So this would be better:
instance D [x] where
   type S b [x] = SHelp x b

type family SHelp x b where
  SHelp x True = x -> x
  SHelp x False = x

So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange.
All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect.
My solution
I propose to simplify substantially, as follows:

*         The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header.  So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared.

*         A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have

o   type variables in the non-shared argument positions, and

o   an exact copy of the corresponding instance header type in the shared positions

*         For each associated type you can have

o   at most one default declaration in the class declaration

o   at most one type instance declaration in the class instance declaration


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140624/2c1b4594/attachment.html>

From eir at cis.upenn.edu  Tue Jun 24 14:25:41 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 24 Jun 2014 10:25:41 -0400
Subject: Associated type instances
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net>
 <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com>
 <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <98A196BA-8E5E-4A31-8E94-A1B3D8F4AEB2@cis.upenn.edu>

I'm sure I've used the feature that you're proposing to remove, but I'll adapt. To be clear, the change means no loss of expressiveness, just that I'll sometimes have to use a helper type family (closed or open), right?

If I'm right there, then no complaints from me.

Richard

On Jun 24, 2014, at 4:07 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> I?m not sure when this ?feature? was added, but I?m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything?
>  
> I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting!   But I?m just checking that no one has meanwhile become addicted to it.
> 
> Simon
>  
> From: Manuel Chakravarty [mailto:mchakravarty at me.com] 
> Sent: 24 June 2014 08:54
> To: Simon Peyton Jones
> Cc: GHC List; ghc-devs at haskell.org
> Subject: Re: Associated type instances
>  
> Simon,
>  
> I?m not sure when this ?feature? was added, but I?m pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything?
>  
> Manuel
>  
> Simon Peyton Jones <simonpj at microsoft.com>:
> Friends
> 
> I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack.
> 
> Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
> 
> All of this arose when thinking about fixing Trac #9063.
> 
> I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10). 
> 
> Does anyone object?
> 
> Thanks
> 
> Simon
> 
>  
> 
> The issue
> 
> Consider this:
> 
> class C a where
>    type T a b :: *
>  
> instance C [x] where
>    type T [x] b = x -> b
> That is just what you?d expect.  But currently this is allowed too:
> 
> instance C [x] where
>    type T [x] Int = x -> Int
>    type T [x] Bool = Bool -> x
> That is, GHC 7.8 allows many associated type instances, provided they don?t overlap.  But, oddly you can?t further instantiate the instance pattern. This would make just as much sense, but isn?t allowed:
> 
> instance C [x] where
>    type T [Int] b = b -> Int
>    type T [Bool] b = Bool -> b
> Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like
> 
> class D a where
>    type S (b :: Bool) a :: *
> Now this would make some kind of sense:
> 
> instance D [x] where
>    type S True [x] = x -> x
>    type S False [x] = x
> But for closed kinds, you really want a closed type family.  So this would be better:
> 
> instance D [x] where
>    type S b [x] = SHelp x b
>  
> type family SHelp x b where
>   SHelp x True = x -> x
>   SHelp x False = x
>  
> So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange.
> 
> All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it?s a bit more complicated and indirect.
> 
> My solution
> 
> I propose to simplify substantially, as follows:
> 
> ?         The ?shared arguments? of an associated type are the argument positions that mention a type variable from the class header.  So in class C above, the first argument position of T is ?shared?; and in class D, the second argument position of S is shared.
> 
> ?         A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have
> 
> o   type variables in the non-shared argument positions, and
> 
> o   an exact copy of the corresponding instance header type in the shared positions
> 
> ?         For each associated type you can have
> 
> o   at most one default declaration in the class declaration
> 
> o   at most one type instance declaration in the class instance declaration
> 
>  
> 
>  
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>  
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140624/8a986c5d/attachment-0001.html>

From simonpj at microsoft.com  Tue Jun 24 16:16:10 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 24 Jun 2014 16:16:10 +0000
Subject: Associated type instances
In-Reply-To: <98A196BA-8E5E-4A31-8E94-A1B3D8F4AEB2@cis.upenn.edu>
References: <618BE556AADD624C9C918AA5D5911BEF103E9B63@DB3PRD3001MB020.064d.mgd.msft.net>
 <4AF4EC6E-9EAC-4FA2-A660-ED6505A201F2@me.com>
 <618BE556AADD624C9C918AA5D5911BEF103EA549@DB3PRD3001MB020.064d.mgd.msft.net>
 <98A196BA-8E5E-4A31-8E94-A1B3D8F4AEB2@cis.upenn.edu>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF103EB29F@DB3PRD3001MB020.064d.mgd.msft.net>

Yes I should have said that originally.  My proposed change has no loss of expressiveness; at worst you need a helper type family

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 24 June 2014 15:26
To: Simon Peyton Jones
Cc: GHC List; Manuel Chakravarty; ghc-devs at haskell.org
Subject: Re: Associated type instances

I'm sure I've used the feature that you're proposing to remove, but I'll adapt. To be clear, the change means no loss of expressiveness, just that I'll sometimes have to use a helper type family (closed or open), right?

If I'm right there, then no complaints from me.

Richard

On Jun 24, 2014, at 4:07 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:


I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything?

I think you are right. I think I added the new stuff in a fit of enthusiasm one day, a fit that I am now regretting!   But I'm just checking that no one has meanwhile become addicted to it.

Simon

From: Manuel Chakravarty [mailto:mchakravarty at me.com<http://me.com>]
Sent: 24 June 2014 08:54
To: Simon Peyton Jones
Cc: GHC List; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Associated type instances

Simon,

I'm not sure when this "feature" was added, but I'm pretty sure that my original implementation of associated types was exactly what you describe in the solution. Or did I miss anything?

Manuel

Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>:
Friends
I want to make withdraw (or, rather, simplify) a little-known feature in GHC, but before I do so I want to check that no one is going to have a heart attack.
Relevant bits of the user manual: http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
All of this arose when thinking about fixing Trac #9063.
I believe that this change will affect essentially nobody, and I propose to implement forthwith in HEAD (and hence 7.10).
Does anyone object?
Thanks
Simon

The issue
Consider this:
class C a where
   type T a b :: *

instance C [x] where
   type T [x] b = x -> b
That is just what you'd expect.  But currently this is allowed too:
instance C [x] where
   type T [x] Int = x -> Int
   type T [x] Bool = Bool -> x
That is, GHC 7.8 allows many associated type instances, provided they don't overlap.  But, oddly you can't further instantiate the instance pattern. This would make just as much sense, but isn't allowed:
instance C [x] where
   type T [Int] b = b -> Int
   type T [Bool] b = Bool -> b
Moreover, as the user manual says, for an open kind like *, none of this really makes sense. It really only makes sense for a closed kind. Something like
class D a where
   type S (b :: Bool) a :: *
Now this would make some kind of sense:
instance D [x] where
   type S True [x] = x -> x
   type S False [x] = x
But for closed kinds, you really want a closed type family.  So this would be better:
instance D [x] where
   type S b [x] = SHelp x b

type family SHelp x b where
  SHelp x True = x -> x
  SHelp x False = x

So yes, you do have to declare a named helper type, but you get something much more perspicuous and explicit in exchange.
All of this also applies to the default declaration(s) which you can supply for an associated type (see 7.7.3.2 in the link above), only it's a bit more complicated and indirect.
My solution
I propose to simplify substantially, as follows:

*         The "shared arguments" of an associated type are the argument positions that mention a type variable from the class header.  So in class C above, the first argument position of T is "shared"; and in class D, the second argument position of S is shared.

*         A instance for an associated type (in a class instance declaration) cf 7.7.3.1 must have

o   type variables in the non-shared argument positions, and

o   an exact copy of the corresponding instance header type in the shared positions

*         For each associated type you can have

o   at most one default declaration in the class declaration

o   at most one type instance declaration in the class instance declaration


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140624/93555bf5/attachment-0001.html>

From mikhail.vorozhtsov at gmail.com  Wed Jun 25 19:54:57 2014
From: mikhail.vorozhtsov at gmail.com (Mikhail Vorozhtsov)
Date: Wed, 25 Jun 2014 23:54:57 +0400
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <CAM0WKeXbxqm9HcLn53Wn6RE=BMdD5qEJFp2pu_D8F1T+u6qaZg@mail.gmail.com>
References: <539C60B0.6010007@gmail.com>
 <CAM0WKeXbxqm9HcLn53Wn6RE=BMdD5qEJFp2pu_D8F1T+u6qaZg@mail.gmail.com>
Message-ID: <53AB2911.9080800@gmail.com>

Isn't it weird that you can't write `a?'`? I was considering proposing

varid -> (small { small | large | digit | ' | primes } { subsup | primes 
}) (EXCEPT reservedid)

but felt that it would be odd to allow primes in the middle of an 
identifier but not super/subscripts. I wish we could just abandon things 
like `a'bc'd` altogether...

On 06/15/2014 03:58 AM, John Meacham wrote:
> I have this feature in jhc, where I have a 'trailing' character class
> that can appear at the end of both symbols and ids.
>
> currently it consists of
>
>   $trailing = [??????????????????????????]
>
>   John
>
> On Sat, Jun 14, 2014 at 7:48 AM, Mikhail Vorozhtsov
> <mikhail.vorozhtsov at gmail.com> wrote:
>> Hello lists,
>>
>> As some of you may know, GHC's support for Unicode characters in lexemes is
>> rather crude and hence prone to inconsistencies in their handling versus the
>> ASCII counterparts. For example, APOSTROPHE is treated differently from
>> PRIME:
>>
>> ?> data a +' b = Plus a b
>> <interactive>:3:9:
>>      Unexpected type ?b?
>>      In the data declaration for ?+?
>>      A data declaration should have form
>>        data + a b c = ...
>> ?> data a +? b = Plus a b
>>
>> ?> let a' = 1
>> ?> let a? = 1
>> <interactive>:10:8: parse error on input ?=?
>>
>> Also some rather bizarre looking things are accepted:
>>
>> ?> let ?x?y = 1
>>
>> In the spirit of improving things little by little I would like to propose:
>>
>> 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as
>> APOSTROPHE, meaning the following alterations to the lexer:
>>
>> primes -> U+2032 | U+2033 | U+2034 | U+2057
>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
>> graphic -> small | large | symbol | digit | special | " | ' | primes
>> varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid)
>> conid -> large { small | large | digit | ' | primes }
>>
>> 2. Introduce a new lexer nonterminal "subsup" that would include the Unicode
>> sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")", Latin and
>> Greek letters. And allow these characters to be used in names and operators:
>>
>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes |
>> subsup )
>> digit -> ascDigit | uniDigit (EXCEPT subsup)
>> small -> ascSmall | uniSmall (EXCEPT subsup) | _
>> large -> ascLarge | uniLarge (EXCEPT subsup)
>> graphic -> small | large | symbol | digit | special | " | ' | primes |
>> subsup
>> varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT
>> reservedid)
>> conid -> large { small | large | digit | ' | primes | subsup }
>> varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes)
>> consym -> (: {symbol | subsup}) (EXCEPT reservedop)
>>
>> If this proposal is received favorably, I'll write a patch for GHC based on
>> my previous stab at the problem[2].
>>
>> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion to
>> the GHC users list.
>>
>> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
>> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>


From john at repetae.net  Fri Jun 27 19:53:16 2014
From: john at repetae.net (John Meacham)
Date: Fri, 27 Jun 2014 12:53:16 -0700
Subject: RFC: Unicode primes and super/subscript characters in GHC
In-Reply-To: <53AB2911.9080800@gmail.com>
References: <539C60B0.6010007@gmail.com>
 <CAM0WKeXbxqm9HcLn53Wn6RE=BMdD5qEJFp2pu_D8F1T+u6qaZg@mail.gmail.com>
 <53AB2911.9080800@gmail.com>
Message-ID: <CAM0WKeVvjAvQQWY+5ArVMmcW1V40Kaa6CXixf5KOw1uuLAToEQ@mail.gmail.com>

Yeah, I specifically excluded ascii prime (') from special handling in
jhc due to its already overloaded meaning in haskell. I just added the
subscript/superscript ones to the 'trailing' character class.

    John

On Wed, Jun 25, 2014 at 12:54 PM, Mikhail Vorozhtsov
<mikhail.vorozhtsov at gmail.com> wrote:
> Isn't it weird that you can't write `a?'`? I was considering proposing
>
> varid -> (small { small | large | digit | ' | primes } { subsup | primes })
> (EXCEPT reservedid)
>
> but felt that it would be odd to allow primes in the middle of an identifier
> but not super/subscripts. I wish we could just abandon things like `a'bc'd`
> altogether...
>
>
> On 06/15/2014 03:58 AM, John Meacham wrote:
>>
>> I have this feature in jhc, where I have a 'trailing' character class
>> that can appear at the end of both symbols and ids.
>>
>> currently it consists of
>>
>>   $trailing = [??????????????????????????]
>>
>>   John
>>
>> On Sat, Jun 14, 2014 at 7:48 AM, Mikhail Vorozhtsov
>> <mikhail.vorozhtsov at gmail.com> wrote:
>>>
>>> Hello lists,
>>>
>>> As some of you may know, GHC's support for Unicode characters in lexemes
>>> is
>>> rather crude and hence prone to inconsistencies in their handling versus
>>> the
>>> ASCII counterparts. For example, APOSTROPHE is treated differently from
>>> PRIME:
>>>
>>> ?> data a +' b = Plus a b
>>> <interactive>:3:9:
>>>      Unexpected type ?b?
>>>      In the data declaration for ?+?
>>>      A data declaration should have form
>>>        data + a b c = ...
>>> ?> data a +? b = Plus a b
>>>
>>> ?> let a' = 1
>>> ?> let a? = 1
>>> <interactive>:10:8: parse error on input ?=?
>>>
>>> Also some rather bizarre looking things are accepted:
>>>
>>> ?> let ?x?y = 1
>>>
>>> In the spirit of improving things little by little I would like to
>>> propose:
>>>
>>> 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as
>>> APOSTROPHE, meaning the following alterations to the lexer:
>>>
>>> primes -> U+2032 | U+2033 | U+2034 | U+2057
>>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
>>> graphic -> small | large | symbol | digit | special | " | ' | primes
>>> varid -> (small { small | large | digit | ' | primes }) (EXCEPT
>>> reservedid)
>>> conid -> large { small | large | digit | ' | primes }
>>>
>>> 2. Introduce a new lexer nonterminal "subsup" that would include the
>>> Unicode
>>> sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")", Latin
>>> and
>>> Greek letters. And allow these characters to be used in names and
>>> operators:
>>>
>>> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes |
>>> subsup )
>>> digit -> ascDigit | uniDigit (EXCEPT subsup)
>>> small -> ascSmall | uniSmall (EXCEPT subsup) | _
>>> large -> ascLarge | uniLarge (EXCEPT subsup)
>>> graphic -> small | large | symbol | digit | special | " | ' | primes |
>>> subsup
>>> varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT
>>> reservedid)
>>> conid -> large { small | large | digit | ' | primes | subsup }
>>> varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop |
>>> dashes)
>>> consym -> (: {symbol | subsup}) (EXCEPT reservedop)
>>>
>>> If this proposal is received favorably, I'll write a patch for GHC based
>>> on
>>> my previous stab at the problem[2].
>>>
>>> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion
>>> to
>>> the GHC users list.
>>>
>>> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
>>> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>>
>



-- 
John Meacham - http://notanumber.net/