Re: Newcomer looking for help with changes to kind system

[Ben Gamari]

Shant Hairapetian  writes:

> Hello,
>
> I’m a master’s student working on implementing the changes outlined in
> “Kinds are Calling Conventions“ (
> https://www.microsoft.com/en-us/research/uploads/prod/2020/03/kacc.pdf). I
> have been working directly with Paul Downen but have hit some roadblocks.
>
> To sum up the changes to the kind system, I am attempting to modify the
> “TYPE” type constructor to accept, rather than just a RuntimeRep, a record
> type (called RuntimeInfo) comprised of a RuntimeRep and a CallingConv
> (calling convention). The calling convention has an “Eval” constructor
> which accepts a levity (effectively moving the levity information from the
> representation to the calling convention. LiftedRep and UnliftedRep would
> also be collapsed into a single PtrRep constructor) and a “Call”
> constructor (denoting the arity of primitive, extensional functions,
> see: Making
> a Faster Curry with Extensional Types
> )
> which accepts a list of RuntimeRep’s. I have created and wired-in the new
> RuntimeInfo and CallingConv types in GHC.Builtin.Types, as well as the
> corresponding primitive types in GHC.Builtin.Types.Prim and have modified
> the “TYPE” constructor to accept a RuntimeInfo rather than a RuntimeRep.
>
Hi Shant,

It would be helpful to have a bit more information on the nature of your
failure. Can you provide a program that your patch rejects, as well as
the full error that is produced?

Incidentally, the collapse of LiftedRep and UnliftedRep will happen in
GHC 9.2 (turning into `BoxedRep :: Levity -> RuntimeRep`).

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Newcomer looking for help with changes to kind system

[Shant Hairapetian]

Hello,

I’m a master’s student working on implementing the changes outlined in
“Kinds are Calling Conventions“ (
https://www.microsoft.com/en-us/research/uploads/prod/2020/03/kacc.pdf). I
have been working directly with Paul Downen but have hit some roadblocks.

To sum up the changes to the kind system, I am attempting to modify the
“TYPE” type constructor to accept, rather than just a RuntimeRep, a record
type (called RuntimeInfo) comprised of a RuntimeRep and a CallingConv
(calling convention). The calling convention has an “Eval” constructor
which accepts a levity (effectively moving the levity information from the
representation to the calling convention. LiftedRep and UnliftedRep would
also be collapsed into a single PtrRep constructor) and a “Call”
constructor (denoting the arity of primitive, extensional functions,
see: Making
a Faster Curry with Extensional Types
)
which accepts a list of RuntimeRep’s. I have created and wired-in the new
RuntimeInfo and CallingConv types in GHC.Builtin.Types, as well as the
corresponding primitive types in GHC.Builtin.Types.Prim and have modified
the “TYPE” constructor to accept a RuntimeInfo rather than a RuntimeRep.

My issue (well, one of my issues) is that, for unboxed tuples, though the
actual kind is being built up correctly, the expected type is still in the
old (or current) representation.

(expected) Couldn't match type: 'TupleRep ('[] @RuntimeRep)

(actual) with: 'RInfo ('TupleRep ('[] @RuntimeRep)) 'GHC.Types.ConvEval

I have not been able to locate where this expected kind is being
constructed. Any help this issue or general guidance would be greatly
appreciated.

Thanks,

Shant
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does GHC implement layout?

[Alexis King]

On 4/5/21 2:36 PM, Ian Lynagh wrote:
It was originally designed by John Meacham: 
https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule 
https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html


Thanks, Ian—I had stumbled across a link to the old Haskell Prime trac 
wiki while I was searching for information, but I didn’t realize where 
it had been migrated to.


It isn't exactly equivalent to the Haskell layout rule, but it's 
fairly close and much simpler (due to not having the "on a parse 
error" case).


Yes, I gathered as much from the implementation. The idea makes sense, 
but of course it doesn’t provide much benefit to have a simpler 
implementation unless it actually /replaces/ the “on parse error” approach.


Given this appears to be a long-defunct proposal, a natural followup 
question is to ask whether there’s any reason this code is still in GHC. 
Is it used for any purpose, or could it be removed?


Alexis

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does GHC implement layout?

[Ian Lynagh]

On Sun, Apr 04, 2021 at 05:18:52PM -0500, Alexis King wrote:
> On 4/4/21 1:52 PM, Iavor Diatchki wrote:
> > 
> > Overall, I do think that Haskell's layout rule is more complicated than
> > it needs to be, and this is mostly because of the rule that requires the
> > insertion of a "virtual close curly" on a parse error.
> 
> Yes, this does seem to be by far the trickiest bit. But I’d be sad not to
> have it, as without it, even simple things like
> 
>let x = 3 in e
> 
> would not be grammatically valid.

That is accepted by the AlternativeLayoutRule.


Thanks
Ian

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does GHC implement layout?

[Ian Lynagh]

On Mon, Apr 05, 2021 at 05:09:21PM +, Simon Peyton-Jones wrote:
> Two people who may know more about the alternative layout rule are Simon 
> Marlow and Ian Lynagh (cc'd).

It was originally designed by John Meacham:
https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule
https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html

It isn't exactly equivalent to the Haskell layout rule, but it's fairly
close and much simpler (due to not having the "on a parse error" case).


Thanks
IAn

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does GHC implement layout?

[Carter Schonwald]

while not totally perfectly related, i have wondered if something like the
the recent pika parsing paper https://arxiv.org/abs/2005.06444 could be
used to provide better error recovery  from layout related errors in
haskell and similar languages.

On Sun, Apr 4, 2021 at 6:19 PM Alexis King  wrote:

> On 4/4/21 1:52 PM, Iavor Diatchki wrote:
>
> Hi Alexis,
>
> I wasn't sure what the "alternative layout" is either and did some
> googling, and it appears that it is something that was never really
> documented properly.   The following link contains pointers to the commit
> that introduced it (in 2009!)  (not the main ticket but some of the
> comments)
>
> Thanks, that’s a helpful pointer, though of course it still doesn’t
> explain very much. I’m still interested in understanding what the purpose
> of “alternative layout” is and how it operates, if anyone else has any idea.
>
> Overall, I do think that Haskell's layout rule is more complicated than it
> needs to be, and this is mostly because of the rule that requires the
> insertion of a "virtual close curly" on a parse error.
>
> Yes, this does seem to be by far the trickiest bit. But I’d be sad not to
> have it, as without it, even simple things like
>
> let x = 3 in e
>
> would not be grammatically valid.
>
> My feeling is that it'd be pretty tricky to do layout in the parser with
> grammar rules, but you may be able to do something with the parser state.
>
> Yes, I have some vague ideas, but none of them are particularly fleshed
> out. It’s entirely possible that I just don’t understand the relationship
> between the lexer and the parser (which seems somewhat obscured by the
> “alternative layout” stuff), and the ideas I have are what’s already
> implemented today. I’ll have to study the implementation more closely.
>
> In any case, thank you for your response! The ALR-related pointer
> certainly clarifies at least a little.
>
> Alexis
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does GHC implement layout?

[Sebastian Graf]

Hi Alexis, Hi Iavor,

I'm afraid I'm not particularly acquainted with how GHC implements
indentation-sensitive parsing, but I really like the way in which this book
 frames the problem. If you
look at the preview for the first chapter, you'll notice that (they call
the lexer scanner, and) they introduce an additional pass between lexer and
parser that handles the context-sensitive bits about indentation-sensitive
parsing, which doesn't fit well with the parser (which assumes a
context-free grammar to stay sane) or with the lexer (which should better
be just a simple DFA).

In particular, the short section 1.3 about the screener explicitly mentions
Haskell as use case:

[image: 2021-04-05-140820_543x163_scrot.png]
Although that doesn't really explain the how. Maybe section 2.5 (where impl
of screeners is covered) provides more insight into that.
Screeners are a bit like semantic analysis, but on the token stream instead
of the parse tree.

Reach out in private if you want more excerpts.

Cheers,
Sebastian

Am Mo., 5. Apr. 2021 um 00:19 Uhr schrieb Alexis King :

> On 4/4/21 1:52 PM, Iavor Diatchki wrote:
>
> Hi Alexis,
>
> I wasn't sure what the "alternative layout" is either and did some
> googling, and it appears that it is something that was never really
> documented properly.   The following link contains pointers to the commit
> that introduced it (in 2009!)  (not the main ticket but some of the
> comments)
>
> Thanks, that’s a helpful pointer, though of course it still doesn’t
> explain very much. I’m still interested in understanding what the purpose
> of “alternative layout” is and how it operates, if anyone else has any idea.
>
> Overall, I do think that Haskell's layout rule is more complicated than it
> needs to be, and this is mostly because of the rule that requires the
> insertion of a "virtual close curly" on a parse error.
>
> Yes, this does seem to be by far the trickiest bit. But I’d be sad not to
> have it, as without it, even simple things like
>
> let x = 3 in e
>
> would not be grammatically valid.
>
> My feeling is that it'd be pretty tricky to do layout in the parser with
> grammar rules, but you may be able to do something with the parser state.
>
> Yes, I have some vague ideas, but none of them are particularly fleshed
> out. It’s entirely possible that I just don’t understand the relationship
> between the lexer and the parser (which seems somewhat obscured by the
> “alternative layout” stuff), and the ideas I have are what’s already
> implemented today. I’ll have to study the implementation more closely.
>
> In any case, thank you for your response! The ALR-related pointer
> certainly clarifies at least a little.
>
> Alexis
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs