Re: CallStack naming

[Joachim Breitner]

Hi,

Am Mittwoch, den 20.01.2016, 00:39 -0500 schrieb Richard Eisenberg:
> I'm sure there's an easy answer to this, but I'm wondering: why is
> the CallStack feature implemented with implicit parameters instead of
> just a magical constraint? Whenever I use this feature, I don't want
> to have to enable -XImplicitParams and then make sure I get the name
> right. What would be wrong with, e.g.,
> 
> > undefined :: AppendsCallStack => a
> 
> Seems simpler. Is it problems with a nullary class?

I tried to construct this using what we have right now:

==> AppendCallStack.hs <==
{-# LANGUAGE ConstraintKinds, ImplicitParams #-}
module AppendCallStack (AppendsCallStack) where

import GHC.Stack

type AppendsCallStack = ?x::CallStack

==> Bar.hs <==
module Bar where

import AppendCallStack

foo x :: AppendsCallStack => a -> a
foo x = error "Test"

But with GHC-7.10 I get

[1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs, AppendCallStack.o 
)
[2 of 2] Compiling Bar  ( Bar.hs, Bar.o )
Bar.hs:5:1:
Invalid type signature: foo x :: AppendsCallStack => a -> a
Should be of form  :: 

although the constraint seems to be a constraint all right:

*AppendCallStack> :kind AppendsCallStack 
AppendsCallStack :: GHC.Prim.Constraint

and with GHC HEAD I get

[1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs, AppendCallStack.o 
)

AppendCallStack.hs:6:1: error:
• Illegal implicit parameter ‘?x::CallStack’
• In the type synonym declaration for ‘AppendsCallStack’

Too bad...

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: CallStack naming

[Simon Peyton Jones]

|  I'm sure there's an easy answer to this, but I'm wondering: why is the
|  CallStack feature implemented with implicit parameters instead of just
|  a magical constraint? Whenever I use this feature, I don't want to
|  have to enable -XImplicitParams and then make sure I get the name
|  right. What would be wrong with, e.g.,
|  
|  > undefined :: AppendsCallStack => a
|  
|  Seems simpler. Is it problems with a nullary class?

Hmm.  Actually I think that's quite a good idea.

The call-stack idea started here 
https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations.  We 
want to be able to get hold of the current call stack.  It obviously doesn't 
make sense to say
currentCallStack :: CallStack

But as the call stack is an implicit parameter (operationally), it obviously 
DOES make sense to say

?currentStack :: (?currentStack :: CallStack) => CallStack

if ?currentStack is an implicit parameter.  And it went from there.

There are disadvantages:

* Need to use -XImplicitParams (Richard's point)

* Need to align two names:
 foo :: (?loc :: CallStack) => Int -> Int
 foo x = if x<0 then error "urk" else -x
  won't work, because 'error' needs (?callStack :: CallStack)

* The special cases in the type checker need a 2-level pattern
  match: for the magic "IP" class, and then the magic "CallStack" type

* In principle you might have multiple call stacks kicking around
  at the same time 
 boo :: (?a::CallStack, ?b::CallStack) => Int -> Int
  Now I'm not really sure what is supposed to happen about solving
  these constraints.  Perhaps it could be a feature, but it's not
  one anyone has asked for, and even having to think about it makes
  my head hurt.

Your alternative suggestion is to have a magic nullary class, the ICallStack 
class ("I" for implicit) so that

   class ICallStack where
  callStack :: CallStack

At least that's is the implementation, but all the user can see is the 
overloaded function

  callStack :: ICallStack => CallStack

The solving rules, the CallStack type, and functions for printing it, would be 
precisely as now.

I like this.  What about others?

(We'd have to think about what to do for 8.0 but first lets see what we want.)

Simon




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

RE: CallStack naming

[Simon Peyton Jones]

|  foo x :: AppendsCallStack => a -> a

Remove the "x"!

S

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 20 January 2016 09:08
|  To: ghc-devs@haskell.org
|  Subject: Re: CallStack naming
|  
|  Hi,
|  
|  Am Mittwoch, den 20.01.2016, 00:39 -0500 schrieb Richard Eisenberg:
|  > I'm sure there's an easy answer to this, but I'm wondering: why is
|  the
|  > CallStack feature implemented with implicit parameters instead of
|  just
|  > a magical constraint? Whenever I use this feature, I don't want to
|  > have to enable -XImplicitParams and then make sure I get the name
|  > right. What would be wrong with, e.g.,
|  >
|  > > undefined :: AppendsCallStack => a
|  >
|  > Seems simpler. Is it problems with a nullary class?
|  
|  I tried to construct this using what we have right now:
|  
|  ==> AppendCallStack.hs <==
|  {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module
|  AppendCallStack (AppendsCallStack) where
|  
|  import GHC.Stack
|  
|  type AppendsCallStack = ?x::CallStack
|  
|  ==> Bar.hs <==
|  module Bar where
|  
|  import AppendCallStack
|  
|  foo x :: AppendsCallStack => a -> a
|  foo x = error "Test"
|  
|  But with GHC-7.10 I get
|  
|  [1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs,
|  AppendCallStack.o )
|  [2 of 2] Compiling Bar  ( Bar.hs, Bar.o )
|  Bar.hs:5:1:
|  Invalid type signature: foo x :: AppendsCallStack => a -> a
|  Should be of form  :: 
|  
|  although the constraint seems to be a constraint all right:
|  
|  *AppendCallStack> :kind AppendsCallStack
|  AppendsCallStack :: GHC.Prim.Constraint
|  
|  and with GHC HEAD I get
|  
|  [1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs,
|  AppendCallStack.o )
|  
|  AppendCallStack.hs:6:1: error:
|  • Illegal implicit parameter ‘?x::CallStack’
|  • In the type synonym declaration for ‘AppendsCallStack’
|  
|  Too bad...
|  
|  Greetings,
|  Joachim
|  
|  --
|  Joachim “nomeata” Breitner
|m...@joachim-breitner.de •
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.jo
|  achim-
|  breitner.de%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd5d44
|  2348f364bcc8a0108d321792a7c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sda
|  ta=5KAXu5980%2bc4CchVNfWyo1mlD6D8%2bQKn9Qjp6ypv0eE%3d
|Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
|Debian Developer: nome...@debian.org

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

Proposal: Longer Testing Cycle

[Harry .]

"Glasgow Haskell Compiler 8.0.1, release candidate 1" was recently announced, 
with a caveat that "This release
candidate in particular is known to suffer from a few significant issues
which are being actively worked upon ... In the coming weeks we will continue 
to iterate on these issues. We will
also look at Trac tickets marked with "highest" priority on the release
status page."

This leads me to wonder whether release management know what the words 
"release" and "candidate" mean!

I would like to propose that the builds which are currently branded "release 
candidate" be rebranded as "beta", seeing as that is what they actually are. 
When the release manager has a build which s/he feels is ready for release, it 
should be published as a release candidate. If after a couple of weeks or so 
the same build is still considered suitable for release, it can be released as 
is, otherwise a new release candidate and testing period are required.

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

Re: Proposal: Longer Testing Cycle

[Ben Gamari]

"Harry ."  writes:

> "Glasgow Haskell Compiler 8.0.1, release candidate 1" was recently
> announced, with a caveat that "This release candidate in particular is
> known to suffer from a few significant issues which are being actively
> worked upon ... In the coming weeks we will continue to iterate on
> these issues. We will also look at Trac tickets marked with "highest"
> priority on the release status page."
>
> This leads me to wonder whether release management know what the words
> "release" and "candidate" mean!
>
> I would like to propose that the builds which are currently branded
> "release candidate" be rebranded as "beta", seeing as that is what
> they actually are. When the release manager has a build which s/he
> feels is ready for release, it should be published as a release
> candidate. If after a couple of weeks or so the same build is still
> considered suitable for release, it can be released as is, otherwise a
> new release candidate and testing period are required.
>
Indeed we do use these words very loosely for reasons that are largely
historical.

I would be open to changing the way we refer to these early "releases"
if the current misuse is causing confusion (although not for 8.0, lest
we spur even more confusion).

I envision we'd probably have one or more "beta" release (beta1, beta2,
...) , followed by hopefully only one "release candidate" (rc1),
followed by the release.

Would this address your concern?

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

Re: CallStack naming

[Joachim Breitner]

Hi,

Am Mittwoch, den 20.01.2016, 10:32 + schrieb Simon Peyton Jones:
> >  foo x :: AppendsCallStack => a -> a
> 
> Remove the "x"!

heh. Silly me. So let’s try again:


With 7.10 it now works:

==> AppendCallStack.hs <==
{-# LANGUAGE ConstraintKinds, ImplicitParams #-}
module AppendCallStack (AppendsCallStack) where

import GHC.Stack

type AppendsCallStack = ?callStack::CallStack

==> Bar.hs <==
{-# LANGUAGE FlexibleContexts #-}
module Main where

import AppendCallStack
import MyError

foo :: AppendsCallStack => a -> a
foo x = myerror "Test"

main = print (foo ())

==> MyError.hs <==
{-# LANGUAGE ImplicitParams #-}
module MyError where

import GHC.Stack

myerror :: (?callStack :: CallStack) => String -> a
myerror msg = error (msg ++ ": " ++ showCallStack ?callStack)


Note that I need FlexibleContexts on the usage site to be able to use
this, otherwise I get

     Non type-variable argument
      in the constraint: ?callStack::GHC.Stack.CallStack

See it in action:

$ ghc --make Bar && ./Bar
Bar: Test: ?callStack, called at ./MyError.hs:7:51 in main:MyError
  myerror, called at Bar.hs:8:9 in main:Main
  foo, called at Bar.hs:10:15 in main:Main


With GHC-HEAD, it compiles no longer(!):

[1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs,
AppendCallStack.o )

AppendCallStack.hs:6:1: error:
• Illegal implicit parameter ‘?callStack::CallStack’
• In the type synonym declaration for ‘AppendsCallStack’


So Richard, does it do what you want with GHC-7.10? And given that GHC
HEAD rejects it, was 7.10 wrong or is there a bug in HEAD?

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Proposal: Longer Testing Cycle

[Harry .]

> From: b...@well-typed.com
> Subject: Re: Proposal: Longer Testing Cycle
> Date: Wed, 20 Jan 2016 12:30:25 +0100
>
> I would be open to changing the way we refer to these early "releases"
> if the current misuse is causing confusion (although not for 8.0, lest
> we spur even more confusion).
>
> I envision we'd probably have one or more "beta" release (beta1, beta2,
> ...) , followed by hopefully only one "release candidate" (rc1),
> followed by the release.
>
> Would this address your concern?

Yes, if the "release candidate" really is a release candidate, i.e. this is 
exactly what we'll publish if no show-stoppers are found.
  
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving trac notifications

[Matthew Pickering]

I attach a patch which should improve the notifications.

Here is an example of the new output.

https://www.irccloud.com/pastebin/HdlVbQt4/

Matt

On Tue, Jan 19, 2016 at 11:29 AM, Matthew Pickering
 wrote:
> Have you had any chance to think about this yet Herbert?
>
> Matt
>
> On Wed, Jan 6, 2016 at 6:44 PM, Ben Gamari  wrote:
>> Ben Gamari  writes:
>>
>>> Matthew Pickering  writes:
>>>
 I subscribe to the ghc-tickets[1] mailing list which provides updates
 to all trac tickets. This is very useful, however when a ticket
 description is updated the whole description is included in the email
 which makes it hard to see what actually changed. The web interface
 shows a nice diff[2] of the changes, I think it would be good if
 emails could also include a diff rather than the current quite useless
 output.

>>> I think this would be a great improvement. I, for one, am quite guilty
>>> of incrementally editing ticket descriptions and the current email
>>> notifications are nearly useless in this case.
>>>
 After a bit of investigation, it appears that the easiest way to
 achieve this is apply a simple patch to our copy of trac. The current
 format is hard coded on line 558 in this module, it seems easy to
 modify this section to instead provide a diff.

>>> Herbert, perhaps we could do something along these lines?
>>>
>> Ping.
>>
>> Cheers,
>>
>> - Ben
From 66cc688282b437266682f3dec211e84efc331721 Mon Sep 17 00:00:00 2001
From: Matthew Pickering 
Date: Wed, 20 Jan 2016 14:09:14 +0100
Subject: [PATCH] Add delta to ticket modification notification

Instead of the previously useless notification which displayed
both the new and old description. We now display the delta and
the new description.
---
 trac/ticket/notification.py | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/trac/ticket/notification.py b/trac/ticket/notification.py
index 8d7e963..7d6598e 100644
--- a/trac/ticket/notification.py
+++ b/trac/ticket/notification.py
@@ -40,6 +40,7 @@ from trac.util.text import exception_to_unicode, obfuscate_email_address, \
shorten_line, text_width, wrap
 from trac.util.translation import _, deactivate, reactivate
 from trac.web.chrome import Chrome
+from trac.versioncontrol.diff import unified_diff


 class TicketNotificationSystem(Component):
@@ -557,14 +558,13 @@ class TicketNotifyEmail(NotifyEmail):
 if field == 'description':
 new_descr = wrap(new, self.COLS, ' ', ' ', '\n',
  self.ambiwidth)
-old_descr = wrap(old, self.COLS, '> ', '> ', '\n',
+
+old_descr = wrap(old, self.COLS, ' ', ' ', '\n',
  self.ambiwidth)
-old_descr = old_descr.replace(2 * '\n', '\n' + '>' +
-  '\n')
+diff = unified_diff(old_descr.split('\n'), new_descr.split('\n'), context=0)
 cdescr = '\n'
-cdescr += 'Old description:' + 2 * '\n' + old_descr + \
-  2 * '\n'
-cdescr += 'New description:' + 2 * '\n' + new_descr + \
+cdescr += '\n'.join(diff)
+cdescr += '\n\nNew description:' + 2 * '\n' + new_descr + \
   '\n'
 changes_descr = cdescr
 elif field == 'summary':
--
2.1.4

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

Library tests failing

[Simon Peyton Jones]

I’m getting this collection of failing tests, all of a sudden (below).  What’s 
up?  I’m pretty sure it’s not my modifications.
The failures ae


=> random1283(normal) 1 of 1 [0, 0, 0]

cd . &&  "/5playpen/simonpj/HEAD-4/inplace/test   spaces/ghc-stage2" -o 
random1283 random1283.hs -fforce-recomp -dcore-lint -dcmm-lint 
-dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs 
-fno-warn-missed-specialisations -fno-ghci-history   -package containers > 
random1283.comp.stderr 2>&1

Compile failed (status 256) errors were:

[1 of 1] Compiling Main ( random1283.hs, random1283.o )



random1283.hs:4:1: error:

Failed to load interface for ‘System.Random’

Use -v to see a list of the files searched for.
and in STM

=> stm050(normal) 1 of 1 [0, 0, 0]

cd . &&  "/5playpen/simonpj/HEAD-4/inplace/test   spaces/ghc-stage2" -o stm050 
stm050.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output 
-no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations 
-fno-ghci-history  -package stm > stm050.comp.stderr 2>&1

Compile failed (status 256) errors were:

: cannot satisfy -package stm

(use -v for more information)
Simon


Unexpected failures:

   ../../libraries/random/tests  random1283 [exit code non-0] (normal)

   ../../libraries/random/tests  rangeTest [exit code non-0] (normal)

   ../../libraries/stm/tests T2411 [exit code non-0] (normal)

   ../../libraries/stm/tests T3049 [exit code non-0] (normal)

   ../../libraries/stm/tests T4057 [exit code non-0] (normal)

   ../../libraries/stm/tests cloneTChan001 [exit code non-0] (normal)

   ../../libraries/stm/tests stm050 [exit code non-0] (normal)

   ../../libraries/stm/tests stm054 [exit code non-0] (normal)

   ../../libraries/stm/tests stm055 [exit code non-0] (normal)

   ../../libraries/stm/tests stm056 [exit code non-0] (threaded1)

   ../../libraries/stm/tests stm060 [exit code non-0] (normal)

   ../../libraries/stm/tests stm061 [exit code non-0] (normal)

   ../../libraries/stm/tests stm062 [exit code non-0] (normal)

   ../../libraries/stm/tests stm064 [exit code non-0] (normal)

   ../../libraries/stm/tests stm065 [exit code non-0] (normal)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: CallStack naming

[Richard Eisenberg]

On Jan 20, 2016, at 6:50 AM, Joachim Breitner  wrote:

> With GHC-HEAD, it compiles no longer(!):
> 
>[1 of 2] Compiling AppendCallStack  ( AppendCallStack.hs,
>AppendCallStack.o )
> 
>AppendCallStack.hs:6:1: error:
>• Illegal implicit parameter ‘?callStack::CallStack’
>• In the type synonym declaration for ‘AppendsCallStack’
> 
> 
> So Richard, does it do what you want with GHC-7.10? And given that GHC
> HEAD rejects it, was 7.10 wrong or is there a bug in HEAD?

Eek. That's a bug. :(

Richard


> 
> Greetings,
> Joachim
> 
> -- 
> Joachim “nomeata” Breitner
>  m...@joachim-breitner.de • http://www.joachim-breitner.de/
>  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>  Debian Developer: nome...@debian.org
> 
> ___
> 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: CallStack naming

[Joachim Breitner]

Hi,

Am Mittwoch, den 20.01.2016, 09:56 -0500 schrieb Richard Eisenberg:
> Eek. That's a bug. :(

There we go: https://ghc.haskell.org/trac/ghc/ticket/11466

Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: ghci and unfoldings?

[Simon Peyton Jones]

Ah….It seems that to get unfoldings exposed in the module you are compiling you 
need both

· -fno-omit-interface-pragmas

· -fexpose-all-unfoldings

And GHCi and –O0 both imply –fomit-interface-pragmas.

To see the unfoldings on imported functions  you need –fno-ignore-interface 
pragmas.

Arguably –fexpose-all-unfoldings should override –fomit-interface-pragmas, 
which it doesn’t at the moment.  Open a ticket if you think that would be 
useful and important.  I can give guidance about the places.

Simon


From: conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] On Behalf Of 
Conal Elliott
Sent: 18 January 2016 17:47
To: Simon Peyton Jones 
Cc: Edward Z. Yang ; Andrew Farmer ; 
ghc-devs@haskell.org
Subject: Re: ghci and unfoldings?

That's the flag I would expect. It doesn't seem to help or hinder availability 
of unfoldings in GHCi. Do you think it should?
And Happy Birthday, Simon!
Warmly, - Conal

On Monday, January 18, 2016, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Or -fexpose-all-unfoldings?

Simon

|  -Original Message-
|  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|  Edward Z. Yang
|  Sent: 18 January 2016 06:37
|  To: Conal Elliott mailto:co...@conal.net>>
|  Cc: Andrew Farmer mailto:afar...@ittc.ku.edu>>; 
ghc-devs@haskell.org
|  Subject: Re: ghci and unfoldings?
|
|  Does passing -fobject-code solve your problem?
|
|  Edward
|
|  Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
|  > Hi Brandon. Thanks for the reply. I’m not sure that it addresses
|  what
|  > I was trying to ask. GHCi *does* invoke plugins and even reloads
|  those
|  > plugins dynamically when their source code changes. So in this sense
|  > ghci does enable optimization, even if it doesn’t perform much
|  > optimization on its own. And of course plugins and unfolding are not
|  just about optimization.
|  >
|  > I’m not looking for ghci to do optimization, but rather to enable me
|  > to more easily develop my GHC plugins. It’s *almost* there already.
|  I
|  > just need access to unfoldings from other modules for my plugin’s
|  use.
|  >
|  > For context, I’m rebuilding my Haskell-to-hardware compiler
|  > , which
|  relies
|  > on giving a non-standard but principled interpretation of Haskell
|  > programs via a conversion through the language of cartesian closed
|  categories (CCCs).
|  > The first back-end is hardware generation (e.g., via Verilog), and I
|  > have plans for several other CCC-based interpretations.
|  >
|  > In addition to facilitating my plugin development, hosting in ghci
|  > will make it much more pleasant for others to *use* the plugin
|  during
|  > exploratory programming, just as with ghci use in general. With
|  access
|  > to unfoldings, users will be able to generate circuit diagrams and
|  > Verilog like those in my compiler talk immediately and directly from
|  > within ghci. I also intend to make a GPU back-end for fast
|  interactive
|  > graphics etc, which would be much more fun in ghci than with batch
|  compilation.
|  > I hope this explanation clarifies my goals and motivation. I hope
|  > there’s a way to access unfoldings from ghci currently or with a
|  small
|  > amount of effort.
|  >
|  > Regards, - Conal
|  >
|  > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery
|  mailto:allber...@gmail.com>>
|  > wrote:
|  >
|  > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott 
mailto:co...@conal.net>>
|  wrote:
|  > >
|  > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use
|  > >> ghci to speed up development. I'm able to do so, except that my
|  > >> plugin critically needs access to unfoldings, which appear to be
|  > >> unavailable in ghci. A little experimenting with ghc shows me
|  that
|  > >> "-O" is the key, but "-O" is incompatible with "--interactive"
|  (as
|  > >> in ghci). Is there any way to persuade ghci to make unfoldings
|  available?
|  > >
|  > >
|  > > I think unfoldings are only done as part of optimization, and the
|  > > bytecode backend doesn't support optimization at all.
|  > >
|  > > --
|  > > brandon s allbery kf8nh   sine nomine
|  > > associates
|  > > allber...@gmail.com
|  > > ballb...@sinenomine.net
|  > > unix, openafs, kerberos, infrastructure, xmonad
|  > >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine
|  > >
|  
nomine.net&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com

Re: CallStack naming

[Eric Seidel]

On Wed, Jan 20, 2016, at 02:25, Simon Peyton Jones wrote:
> |  > undefined :: AppendsCallStack => a
> |  
> |  Seems simpler. Is it problems with a nullary class?
> 
> Hmm.  Actually I think that's quite a good idea.

I agree, this is much nicer than enabling ImplicitParams and having to
remember the naming convention!

However, it seems to me that we could implement this as a constraint
synonym (pending Joachim's bug #11466). So the main benefit from giving
CallStack its own class would be in simplifying the implementation.

> There are disadvantages:
> 
> * The special cases in the type checker need a 2-level pattern
>   match: for the magic "IP" class, and then the magic "CallStack" type

I don't think this is so bad, we already have a function isCallStackCt
that encapsulates the logic.

> * In principle you might have multiple call stacks kicking around
>   at the same time 
>  boo :: (?a::CallStack, ?b::CallStack) => Int -> Int
>   Now I'm not really sure what is supposed to happen about solving
>   these constraints.  Perhaps it could be a feature, but it's not
>   one anyone has asked for, and even having to think about it makes
>   my head hurt.

Ugh, I don't want to think about this either.

> Your alternative suggestion is to have a magic nullary class, the
> ICallStack class ("I" for implicit) so that
> 
>class ICallStack where
>   callStack :: CallStack
> 
> At least that's is the implementation, but all the user can see is the
> overloaded function
> 
>   callStack :: ICallStack => CallStack
> 
> The solving rules, the CallStack type, and functions for printing it,
> would be precisely as now.
> 
> I like this.  What about others?

I think there's a problem with this approach. The new ability to freeze
CallStacks relies on being able to construct new dictionaries on-the-fly
for ImplicitParams. So if we were to re-implement CallStacks with their
own class, we would have to copy the shadowing logic that we already
have for ImplicitParams.

So I'm in favor of Joachim's constraint synonym.

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

RE: CallStack naming

[Simon Peyton Jones]

|  > * In principle you might have multiple call stacks kicking around
|  >   at the same time
|  >  boo :: (?a::CallStack, ?b::CallStack) => Int -> Int
|  >   Now I'm not really sure what is supposed to happen about solving
|  >   these constraints.  Perhaps it could be a feature, but it's not
|  >   one anyone has asked for, and even having to think about it makes
|  >   my head hurt.
|  
|  Ugh, I don't want to think about this either.

But if it's just a synonym, this is entirely possible to do.

|  >class ICallStack where
|  >   callStack :: CallStack


|  I think there's a problem with this approach. The new ability to
|  freeze CallStacks relies on being able to construct new dictionaries
|  on-the-fly for ImplicitParams. So if we were to re-implement
|  CallStacks with their own class, we would have to copy the shadowing
|  logic that we already have for ImplicitParams.

I don't understand the problem.  Can you be more specific.

Regardless, it sounds as though we agreeing that the *user-visible* aspect 
should use this API.  So no more '?callstack' in the user API.  Right?

Would you like to start amending the wiki page with the proposed new design, 
from the user point of view. We can continue to argue about implementation!

|  So I'm in favor of Joachim's constraint synonym.

Currently I'm not :-)

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

Re: CallStack naming

[Eric Seidel]

On Wed, Jan 20, 2016, at 08:14, Simon Peyton Jones wrote:
> |  > * In principle you might have multiple call stacks kicking around
> |  >   at the same time
> |  >  boo :: (?a::CallStack, ?b::CallStack) => Int -> Int
> |  >   Now I'm not really sure what is supposed to happen about solving
> |  >   these constraints.  Perhaps it could be a feature, but it's not
> |  >   one anyone has asked for, and even having to think about it makes
> |  >   my head hurt.
> |  
> |  Ugh, I don't want to think about this either.
> 
> But if it's just a synonym, this is entirely possible to do.

True. I don't think it would cause problems for the solver, but it could
certainly be a pitfall for users.

> |  >class ICallStack where
> |  >   callStack :: CallStack
> 
> 
> |  I think there's a problem with this approach. The new ability to
> |  freeze CallStacks relies on being able to construct new dictionaries
> |  on-the-fly for ImplicitParams. So if we were to re-implement
> |  CallStacks with their own class, we would have to copy the shadowing
> |  logic that we already have for ImplicitParams.
> 
> I don't understand the problem.  Can you be more specific.

I've written up a few notes about the proposal on the wiki.

https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations#AlternateProposal

The problem is that I don't know how to implement `withFrozenCallStack`
(included in the wiki) as a Haskell function if CallStacks aren't
implicit parameters under-the-hood.

> Regardless, it sounds as though we agreeing that the *user-visible*
> aspect should use this API.  So no more '?callstack' in the user API. 
> Right?

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

Special treatment of family and role in the parser

[Jan Stolarek]

Richard, I still don't fully understand special treatment of 'role' and 
'family' in the parser I 
asked about recently on Skype. Say I have:

foo :: role -> role
foo role = role

This results in parse error of type signature, regardless of enabling or 
disabling -XRoleAnnotations. Using `role` as a variable name (not type 
variable) is fine though. 
This is a consequence of explicitly listing 'role' lexeme in the varid 
production in the parser, 
but not in tyvarid production. But if I add 'role' to tyvarid production (or, 
even better, push 
it to special_id production used both by varid and tyvarid) everything works 
perfectly, I can use 
`role` both as variable and type variable name. Role annotations also work. The 
only downside is 
a small increase in number of shift/reduce conflicts. If I treat 'family' in 
the same way (ie. 
add it to tyvarid production) the increase in shift/reduce conflicts really 
becomes significant: 
from 37 to 129. Is this the only reason we don't do it? As you can guess this 
question is related 
to open kinds work: I need to add 'kind' lexeme to special_id to make sure it 
is accepted as a 
variable and type variable name.

Janek

---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual 
to whom it is addressed.
If you are not the intended recipient or if you have received this message in 
error,
please notify the sender and delete it from your system.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Special treatment of family and role in the parser

[Richard Eisenberg]

From your email, you understand everything I do about this. :)

I think the challenge really is just understanding and eliminating these 
conflicts. See the commentary at the top of Parser.y to see how to get an 
analysis of the conflicts.

While you're in the area, you may want to look at #11267. It's not quite 
related, but it's also about parsing types.

Richard

On Jan 20, 2016, at 1:42 PM, Jan Stolarek  wrote:

> Richard, I still don't fully understand special treatment of 'role' and 
> 'family' in the parser I 
> asked about recently on Skype. Say I have:
> 
> foo :: role -> role
> foo role = role
> 
> This results in parse error of type signature, regardless of enabling or 
> disabling -XRoleAnnotations. Using `role` as a variable name (not type 
> variable) is fine though. 
> This is a consequence of explicitly listing 'role' lexeme in the varid 
> production in the parser, 
> but not in tyvarid production. But if I add 'role' to tyvarid production (or, 
> even better, push 
> it to special_id production used both by varid and tyvarid) everything works 
> perfectly, I can use 
> `role` both as variable and type variable name. Role annotations also work. 
> The only downside is 
> a small increase in number of shift/reduce conflicts. If I treat 'family' in 
> the same way (ie. 
> add it to tyvarid production) the increase in shift/reduce conflicts really 
> becomes significant: 
> from 37 to 129. Is this the only reason we don't do it? As you can guess this 
> question is related 
> to open kinds work: I need to add 'kind' lexeme to special_id to make sure it 
> is accepted as a 
> variable and type variable name.
> 
> Janek
> 
> ---
> Politechnika Łódzka
> Lodz University of Technology
> 
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez 
> pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> 
> This email contains information intended solely for the use of the individual 
> to whom it is addressed.
> If you are not the intended recipient or if you have received this message in 
> error,
> please notify the sender and delete it from your system.

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

Re: Special treatment of family and role in the parser

[Thomas Miedema]

CC Ulya Trofimovich (skvadrik), who removed the remaining reduce/reduce
conflicts from the parser last year, and can maybe also help out here.

Ulya: see email from Jan below.


On Wed, Jan 20, 2016 at 8:25 PM, Richard Eisenberg 
wrote:

> From your email, you understand everything I do about this. :)
>
> I think the challenge really is just understanding and eliminating these
> conflicts. See the commentary at the top of Parser.y to see how to get an
> analysis of the conflicts.
>
> While you're in the area, you may want to look at #11267. It's not quite
> related, but it's also about parsing types.
>
> Richard
>
> On Jan 20, 2016, at 1:42 PM, Jan Stolarek  wrote:
>
> > Richard, I still don't fully understand special treatment of 'role' and
> 'family' in the parser I
> > asked about recently on Skype. Say I have:
> >
> > foo :: role -> role
> > foo role = role
> >
> > This results in parse error of type signature, regardless of enabling or
> > disabling -XRoleAnnotations. Using `role` as a variable name (not type
> variable) is fine though.
> > This is a consequence of explicitly listing 'role' lexeme in the varid
> production in the parser,
> > but not in tyvarid production. But if I add 'role' to tyvarid production
> (or, even better, push
> > it to special_id production used both by varid and tyvarid) everything
> works perfectly, I can use
> > `role` both as variable and type variable name. Role annotations also
> work. The only downside is
> > a small increase in number of shift/reduce conflicts. If I treat
> 'family' in the same way (ie.
> > add it to tyvarid production) the increase in shift/reduce conflicts
> really becomes significant:
> > from 37 to 129. Is this the only reason we don't do it? As you can guess
> this question is related
> > to open kinds work: I need to add 'kind' lexeme to special_id to make
> sure it is accepted as a
> > variable and type variable name.
> >
> > Janek
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> pomyłkę
> > prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> individual to whom it is addressed.
> > If you are not the intended recipient or if you have received this
> message in error,
> > please notify the sender and delete it from your system.
>
> ___
> 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: ghci and unfoldings?

[Conal Elliott]

Thanks for the additional tips. I'm having very inconsistent results with
unfolding definitions from other modules in ghci, even with all of these
flags. I'll keep poking at it until I have some consistent info and
questions.

-- Conal

On Wed, Jan 20, 2016 at 7:46 AM, Simon Peyton Jones 
wrote:

> Ah….It seems that to get unfoldings exposed in the *module you are
> compiling* you need *both*
>
> · -fno-omit-interface-pragmas
>
> · -fexpose-all-unfoldings
>
>
>
> And GHCi and –O0 both imply –fomit-interface-pragmas.
>
>
>
> To see the unfoldings on *imported* functions  you need
> –fno-ignore-interface pragmas.
>
>
>
> Arguably –fexpose-all-unfoldings should override –fomit-interface-pragmas,
> which it doesn’t at the moment.  Open a ticket if you think that would be
> useful and important.  I can give guidance about the places.
>
>
>
> Simon
>
>
>
>
>
> *From:* conal.elli...@gmail.com [mailto:conal.elli...@gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 18 January 2016 17:47
> *To:* Simon Peyton Jones 
> *Cc:* Edward Z. Yang ; Andrew Farmer ;
> ghc-devs@haskell.org
>
> *Subject:* Re: ghci and unfoldings?
>
>
>
> That's the flag I would expect. It doesn't seem to help or hinder
> availability of unfoldings in GHCi. Do you think it should?
>
> And Happy Birthday, Simon!
>
> Warmly, - Conal
>
>
> On Monday, January 18, 2016, Simon Peyton Jones 
> wrote:
>
> Or -fexpose-all-unfoldings?
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org
> ] On Behalf Of
> |  Edward Z. Yang
> |  Sent: 18 January 2016 06:37
> |  To: Conal Elliott 
> |  Cc: Andrew Farmer ; ghc-devs@haskell.org
> |  Subject: Re: ghci and unfoldings?
> |
> |  Does passing -fobject-code solve your problem?
> |
> |  Edward
> |
> |  Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
> |  > Hi Brandon. Thanks for the reply. I’m not sure that it addresses
> |  what
> |  > I was trying to ask. GHCi *does* invoke plugins and even reloads
> |  those
> |  > plugins dynamically when their source code changes. So in this sense
> |  > ghci does enable optimization, even if it doesn’t perform much
> |  > optimization on its own. And of course plugins and unfolding are not
> |  just about optimization.
> |  >
> |  > I’m not looking for ghci to do optimization, but rather to enable me
> |  > to more easily develop my GHC plugins. It’s *almost* there already.
> |  I
> |  > just need access to unfoldings from other modules for my plugin’s
> |  use.
> |  >
> |  > For context, I’m rebuilding my Haskell-to-hardware compiler
> |  > , which
> |  relies
> |  > on giving a non-standard but principled interpretation of Haskell
> |  > programs via a conversion through the language of cartesian closed
> |  categories (CCCs).
> |  > The first back-end is hardware generation (e.g., via Verilog), and I
> |  > have plans for several other CCC-based interpretations.
> |  >
> |  > In addition to facilitating my plugin development, hosting in ghci
> |  > will make it much more pleasant for others to *use* the plugin
> |  during
> |  > exploratory programming, just as with ghci use in general. With
> |  access
> |  > to unfoldings, users will be able to generate circuit diagrams and
> |  > Verilog like those in my compiler talk immediately and directly from
> |  > within ghci. I also intend to make a GPU back-end for fast
> |  interactive
> |  > graphics etc, which would be much more fun in ghci than with batch
> |  compilation.
> |  > I hope this explanation clarifies my goals and motivation. I hope
> |  > there’s a way to access unfoldings from ghci currently or with a
> |  small
> |  > amount of effort.
> |  >
> |  > Regards, - Conal
> |  >
> |  > On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery
> |  
> |  > wrote:
> |  >
> |  > > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott 
> |  wrote:
> |  > >
> |  > >> I'm developing a GHC plugin (using HERMIT), and I'd like to use
> |  > >> ghci to speed up development. I'm able to do so, except that my
> |  > >> plugin critically needs access to unfoldings, which appear to be
> |  > >> unavailable in ghci. A little experimenting with ghc shows me
> |  that
> |  > >> "-O" is the key, but "-O" is incompatible with "--interactive"
> |  (as
> |  > >> in ghci). Is there any way to persuade ghci to make unfoldings
> |  available?
> |  > >
> |  > >
> |  > > I think unfoldings are only done as part of optimization, and the
> |  > > bytecode backend doesn't support optimization at all.
> |  > >
> |  > > --
> |  > > brandon s allbery kf8nh   sine nomine
> |  > > associates
> |  > > allber...@gmail.com
> |  > > ballb...@sinenomine.net
> |  > > unix, openafs, kerberos, infrastructure, xmonad
> |  > >
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsine
> |  > >
> |  nomine.net
> 

Re: Improving trac notifications

[Matthew Pickering]

Herbert now seems to have applied the patch. Hopefully this will improve
the email situation for everyone.

Matt
On 20 Jan 2016 1:15 pm, "Matthew Pickering" 
wrote:

> I attach a patch which should improve the notifications.
>
> Here is an example of the new output.
>
> https://www.irccloud.com/pastebin/HdlVbQt4/
>
> Matt
>
> On Tue, Jan 19, 2016 at 11:29 AM, Matthew Pickering
>  wrote:
> > Have you had any chance to think about this yet Herbert?
> >
> > Matt
> >
> > On Wed, Jan 6, 2016 at 6:44 PM, Ben Gamari  wrote:
> >> Ben Gamari  writes:
> >>
> >>> Matthew Pickering  writes:
> >>>
>  I subscribe to the ghc-tickets[1] mailing list which provides updates
>  to all trac tickets. This is very useful, however when a ticket
>  description is updated the whole description is included in the email
>  which makes it hard to see what actually changed. The web interface
>  shows a nice diff[2] of the changes, I think it would be good if
>  emails could also include a diff rather than the current quite useless
>  output.
> 
> >>> I think this would be a great improvement. I, for one, am quite guilty
> >>> of incrementally editing ticket descriptions and the current email
> >>> notifications are nearly useless in this case.
> >>>
>  After a bit of investigation, it appears that the easiest way to
>  achieve this is apply a simple patch to our copy of trac. The current
>  format is hard coded on line 558 in this module, it seems easy to
>  modify this section to instead provide a diff.
> 
> >>> Herbert, perhaps we could do something along these lines?
> >>>
> >> Ping.
> >>
> >> Cheers,
> >>
> >> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fwd: Host-Oriented Template Haskell

[Edward Z. Yang]

Hello John,

Almost!

As you point out, if you just want a cross-compiler, you don't
need to build stage2.  The real problem is that we want stage0
to be *the same version* as stage1, so that stage0 has the correct
API in order to load stage0 libraries which are going to be used
for TH, plugins, etc.  (Alternately, build a non-cross-compiler
stage1, and then a cross-compiler stage2--NOT a cross compiled
stage 2.)

Edward

Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800:
> From #11378:
> 
> > Can we actually link against the old version of ghc? Yes we can! All we 
> > need is
> > (1) for it to have been built with a different IPID, and
> > (2) to use module renaming to rename the relevant modules to a different
> > module name, so that we can import them without a conflict.
> 
> 
> If I understand this, you are saying stage1 links stage0 (the normal,
> non-cross-compiler used to build stage1), to build stage2? I agree
> that should work, but if stage1 is multi-target isn't that level of
> complexity not even needed? I'm not too familiar with GHC or its build
> system, but a multi-target compiler that doesn't support normal TH
> doesn't seem that hard to build in principle.
> 
> John
> 
> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John  wrote:
> > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-}
> > imports is precisely equivalent to what I propose. I find a clean
> > separation with that and normal TH useful, however, precisely so the
> > stage2 compiler's source can include such a thing.
> >
> > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang  wrote:
> >> Hello John
> >>
> >> You may find this implementation ticket of interest:
> >> https://ghc.haskell.org/trac/ghc/ticket/11378
> >>
> >> Edward
> >>
> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
> >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I
> >>> envision this as normal feature that anyone can use, in practice its
> >>> biggest consumers would be GHC devs.
> >>>
> >>> John
> >>>
> >>> -- Forwarded message --
> >>> From: Ericson, John 
> >>> Date: Tue, Jan 19, 2016 at 1:17 PM
> >>> Subject: Host-Oriented Template Haskell
> >>> To: Haskell-Cafe 
> >>>
> >>>
> >>> As is well known, TH and cross-compiling do not get along. There are
> >>> various proposals on how to make this interaction less annoying, and I
> >>> am not against them. But as I see it, the problem is largely inherent
> >>> to the design of TH itself: since values can (usually) be lifted from
> >>> compile-time to run-time, and normal definitions from upstream modules
> >>> to downstream modules' TH, TH and normal code must "live in the same
> >>> world".
> >>>
> >>> Now this restriction in turn bequeaths TH with much expressive power,
> >>> and I wouldn't advocate getting rid of it. But many tasks do not need
> >>> it, and in some cases, say in bootstrapping compilers[1] themselves,
> >>> it is impossible to use TH because of it, even were all the current
> >>> proposals implemented.
> >>>
> >>> For these reason, I propose a new TH variant which has much harsher
> >>> phase separation. Normal definitions from upstream modules can not be
> >>> used, lifting values is either not permitted or is allowed to fail
> >>> (because of missing/incompatible definitions), and IO is defined to
> >>> match the behavior of the host, not target, platform (in the cross
> >>> compiling case). The only interaction between the two phases is that
> >>> quoted syntax is resolved against the the run-time phase's definitions
> >>> (just like today).
> >>>
> >>> Some of you may find this a shoddy substitute for defining a subset of
> >>> Haskell which behaves identically on all platforms, and optionally
> >>> constraining TH to it. But the big feature that my proposal offers and
> >>> that one doesn't is to be able to independently specify compile-time
> >>> dependencies for the host-oriented TH---this is analogous to the
> >>> newish `Setup.hs` dependencies. That in turns leads to what I think is
> >>> the "killer app" for Host-Oriented TH: exposing the various
> >>> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
> >>> and side-stepping any need for "executable dependencies" in Cabal.
> >>> Note also that at least hsc2hs additionally requires host-IO---there
> >>> may not even exist a C compiler on the target platform at all.
> >>>
> >>> Finally, forgive me if this has been brought up before. I've been
> >>> thinking about this a while, and did a final pass over the GHC wiki to
> >>> make sure it wasn't already proposed, but I could have missed
> >>> something (this is also my first post to the list).
> >>>
> >>> John
> >>>
> >>> [1]: 
> >>> https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-de

Fwd: Fwd: Host-Oriented Template Haskell

[Ericson, John]

Oops, Sent just to Edward by mistake.



That all sounds good to me---I think what I was thinking all along in
fact, unless I am still missing some nuance :).

My idea of using a multi-target compiler was to avoid needing stage0
to be the same version as stage1 (or adding a new stage, stage1 as in
your alternative). The cross compiler is multi-target so it doesn't
need to link another compiler to load plugins / run "host-oriented
Template Haskell". I mentioned the usecase of trying to build a stage2
which needs plugins / Host-Oriented Template Haskell, but it could
well apply to building anything else with the need for those to things
(and not normal TH, which cannot be built with a cross compiler)

In diagrams, rather than:

> stage0 (version foo, platform-x -> platform-x)
> ==> stage1 (version foo, platform-x -> platform-y)
> ==> some program (with plugins, with host-oriented TH, without normal TH)

or

> stage0 (version bar, platform-x -> platform-x)
> ==> stage1 (version foo, platform-x -> platform-x) ->
> ==> stage2 (version foo, platform-x -> platform-y) ->
> ==> some program (with plugins, with host-oriented TH, without normal TH)

do just

> stage0 (version bar, platform-x -> platform-x)
> ==> stage1 (version foo, platform-x -> {platform-x, platform-y})
> ==> some program (with plugins, with host-oriented TH, without normal TH)

Now it may be that building such a multi-target compiler today is just
as arduous as making sure one has a native compiler of the same
version before building the cross compiler, so my idea is of no
practical value. But if so, I hope in the long term that could be
fixed.

John


On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang  wrote:
> Hello John,
>
> Almost!
>
> As you point out, if you just want a cross-compiler, you don't
> need to build stage2.  The real problem is that we want stage0
> to be *the same version* as stage1, so that stage0 has the correct
> API in order to load stage0 libraries which are going to be used
> for TH, plugins, etc.  (Alternately, build a non-cross-compiler
> stage1, and then a cross-compiler stage2--NOT a cross compiled
> stage 2.)
>
> Edward
>
> Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800:
>> From #11378:
>>
>> > Can we actually link against the old version of ghc? Yes we can! All we 
>> > need is
>> > (1) for it to have been built with a different IPID, and
>> > (2) to use module renaming to rename the relevant modules to a different
>> > module name, so that we can import them without a conflict.
>>
>>
>> If I understand this, you are saying stage1 links stage0 (the normal,
>> non-cross-compiler used to build stage1), to build stage2? I agree
>> that should work, but if stage1 is multi-target isn't that level of
>> complexity not even needed? I'm not too familiar with GHC or its build
>> system, but a multi-target compiler that doesn't support normal TH
>> doesn't seem that hard to build in principle.
>>
>> John
>>
>> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John  
>> wrote:
>> > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-}
>> > imports is precisely equivalent to what I propose. I find a clean
>> > separation with that and normal TH useful, however, precisely so the
>> > stage2 compiler's source can include such a thing.
>> >
>> > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang  wrote:
>> >> Hello John
>> >>
>> >> You may find this implementation ticket of interest:
>> >> https://ghc.haskell.org/trac/ghc/ticket/11378
>> >>
>> >> Edward
>> >>
>> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
>> >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I
>> >>> envision this as normal feature that anyone can use, in practice its
>> >>> biggest consumers would be GHC devs.
>> >>>
>> >>> John
>> >>>
>> >>> -- Forwarded message --
>> >>> From: Ericson, John 
>> >>> Date: Tue, Jan 19, 2016 at 1:17 PM
>> >>> Subject: Host-Oriented Template Haskell
>> >>> To: Haskell-Cafe 
>> >>>
>> >>>
>> >>> As is well known, TH and cross-compiling do not get along. There are
>> >>> various proposals on how to make this interaction less annoying, and I
>> >>> am not against them. But as I see it, the problem is largely inherent
>> >>> to the design of TH itself: since values can (usually) be lifted from
>> >>> compile-time to run-time, and normal definitions from upstream modules
>> >>> to downstream modules' TH, TH and normal code must "live in the same
>> >>> world".
>> >>>
>> >>> Now this restriction in turn bequeaths TH with much expressive power,
>> >>> and I wouldn't advocate getting rid of it. But many tasks do not need
>> >>> it, and in some cases, say in bootstrapping compilers[1] themselves,
>> >>> it is impossible to use TH because of it, even were all the current
>> >>> proposals implemented.
>> >>>
>> >>> For these reason, I propose a new TH variant which has much harsher
>> >>> phase separation. Normal definitions from upstream modules can not be

Re: Fwd: Fwd: Host-Oriented Template Haskell

[Edward Z. Yang]

Yes, in principle, a compiler that supports cross-compiling to many
targets without needing to be configured (at build time) which
target it should support is ideal.  Unfortunately, currently GHC
relies on autoconf to determine all of the necessary parameters
for a cross-compile.  I am not sure how feasible it would be to
allow these parameters to be configured at runtime: it might be
easy, it might be hard!  (And of course you have to arrange
to have cross-compiled all the boot libraries too...)

In any case, I think that a GHC that permits changing cross-compilation
targets at runtime is a fine goal, and if it is supported, then we
would only have to make adjustments to GHC internally to distinguish
between the interfaces/objects for various targets (including itself.)

Edward

Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800:
> Oops, Sent just to Edward by mistake.
> 
> 
> 
> That all sounds good to me---I think what I was thinking all along in
> fact, unless I am still missing some nuance :).
> 
> My idea of using a multi-target compiler was to avoid needing stage0
> to be the same version as stage1 (or adding a new stage, stage1 as in
> your alternative). The cross compiler is multi-target so it doesn't
> need to link another compiler to load plugins / run "host-oriented
> Template Haskell". I mentioned the usecase of trying to build a stage2
> which needs plugins / Host-Oriented Template Haskell, but it could
> well apply to building anything else with the need for those to things
> (and not normal TH, which cannot be built with a cross compiler)
> 
> In diagrams, rather than:
> 
> > stage0 (version foo, platform-x -> platform-x)
> > ==> stage1 (version foo, platform-x -> platform-y)
> > ==> some program (with plugins, with host-oriented TH, without normal TH)
> 
> or
> 
> > stage0 (version bar, platform-x -> platform-x)
> > ==> stage1 (version foo, platform-x -> platform-x) ->
> > ==> stage2 (version foo, platform-x -> platform-y) ->
> > ==> some program (with plugins, with host-oriented TH, without normal TH)
> 
> do just
> 
> > stage0 (version bar, platform-x -> platform-x)
> > ==> stage1 (version foo, platform-x -> {platform-x, platform-y})
> > ==> some program (with plugins, with host-oriented TH, without normal TH)
> 
> Now it may be that building such a multi-target compiler today is just
> as arduous as making sure one has a native compiler of the same
> version before building the cross compiler, so my idea is of no
> practical value. But if so, I hope in the long term that could be
> fixed.
> 
> John
> 
> On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang  wrote:
> > Hello John,
> >
> > Almost!
> >
> > As you point out, if you just want a cross-compiler, you don't
> > need to build stage2.  The real problem is that we want stage0
> > to be *the same version* as stage1, so that stage0 has the correct
> > API in order to load stage0 libraries which are going to be used
> > for TH, plugins, etc.  (Alternately, build a non-cross-compiler
> > stage1, and then a cross-compiler stage2--NOT a cross compiled
> > stage 2.)
> >
> > Edward
> >
> > Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800:
> >> From #11378:
> >>
> >> > Can we actually link against the old version of ghc? Yes we can! All we 
> >> > need is
> >> > (1) for it to have been built with a different IPID, and
> >> > (2) to use module renaming to rename the relevant modules to a different
> >> > module name, so that we can import them without a conflict.
> >>
> >>
> >> If I understand this, you are saying stage1 links stage0 (the normal,
> >> non-cross-compiler used to build stage1), to build stage2? I agree
> >> that should work, but if stage1 is multi-target isn't that level of
> >> complexity not even needed? I'm not too familiar with GHC or its build
> >> system, but a multi-target compiler that doesn't support normal TH
> >> doesn't seem that hard to build in principle.
> >>
> >> John
> >>
> >> On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John  
> >> wrote:
> >> > Ah thanks for the link. Template Haskell with only {-# TH-ONLY #-}
> >> > imports is precisely equivalent to what I propose. I find a clean
> >> > separation with that and normal TH useful, however, precisely so the
> >> > stage2 compiler's source can include such a thing.
> >> >
> >> > On Tue, Jan 19, 2016 at 3:20 PM, Edward Z. Yang  wrote:
> >> >> Hello John
> >> >>
> >> >> You may find this implementation ticket of interest:
> >> >> https://ghc.haskell.org/trac/ghc/ticket/11378
> >> >>
> >> >> Edward
> >> >>
> >> >> Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
> >> >>> Cross-posting this as was suggested on the Haskell-Cafe list. While I
> >> >>> envision this as normal feature that anyone can use, in practice its
> >> >>> biggest consumers would be GHC devs.
> >> >>>
> >> >>> John
> >> >>>
> >> >>> -- Forwarded message --
> >> >>> From: Ericson, John 
> >> >>> Date: Tue, Jan 19, 2016 at 1:17 PM
> 

Re: Host-Oriented Template Haskell

[Moritz Angermann]

Colour me an interested party!  For iOS one currently builds two
different ghc compiler.  One for the simulator (i386) and one for the
actual device (arm).  My initial work on bringing ghcjs’s TH support,
(which basically ships the TH out to a process on the target to compile
and brings back the compiled TH into the cross compiler) to ghc, was
based on the idea of having a TH handler plugin, which would handle the
TH parts, and could then be adapted for different TH situations.  This
of course could only work if the plugin was compiled with the same version
of ghc, that the cross compiler was.

I wonder if the multi-target pipeline might be simpler to achieve with
the llvm backend.

If someone is taking a shot at this, I’d like to help!

Cheers,
 Moritz

> On Jan 21, 2016, at 2:44 PM, Edward Z. Yang  wrote:
> 
> Yes, in principle, a compiler that supports cross-compiling to many
> targets without needing to be configured (at build time) which
> target it should support is ideal.  Unfortunately, currently GHC
> relies on autoconf to determine all of the necessary parameters
> for a cross-compile.  I am not sure how feasible it would be to
> allow these parameters to be configured at runtime: it might be
> easy, it might be hard!  (And of course you have to arrange
> to have cross-compiled all the boot libraries too...)
> 
> In any case, I think that a GHC that permits changing cross-compilation
> targets at runtime is a fine goal, and if it is supported, then we
> would only have to make adjustments to GHC internally to distinguish
> between the interfaces/objects for various targets (including itself.)
> 
> Edward
> 
> Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800:
>> Oops, Sent just to Edward by mistake.
>> 
>> 
>> 
>> That all sounds good to me---I think what I was thinking all along in
>> fact, unless I am still missing some nuance :).
>> 
>> My idea of using a multi-target compiler was to avoid needing stage0
>> to be the same version as stage1 (or adding a new stage, stage1 as in
>> your alternative). The cross compiler is multi-target so it doesn't
>> need to link another compiler to load plugins / run "host-oriented
>> Template Haskell". I mentioned the usecase of trying to build a stage2
>> which needs plugins / Host-Oriented Template Haskell, but it could
>> well apply to building anything else with the need for those to things
>> (and not normal TH, which cannot be built with a cross compiler)
>> 
>> In diagrams, rather than:
>> 
>>> stage0 (version foo, platform-x -> platform-x)
>>> ==> stage1 (version foo, platform-x -> platform-y)
>>> ==> some program (with plugins, with host-oriented TH, without normal TH)
>> 
>> or
>> 
>>> stage0 (version bar, platform-x -> platform-x)
>>> ==> stage1 (version foo, platform-x -> platform-x) ->
>>> ==> stage2 (version foo, platform-x -> platform-y) ->
>>> ==> some program (with plugins, with host-oriented TH, without normal TH)
>> 
>> do just
>> 
>>> stage0 (version bar, platform-x -> platform-x)
>>> ==> stage1 (version foo, platform-x -> {platform-x, platform-y})
>>> ==> some program (with plugins, with host-oriented TH, without normal TH)
>> 
>> Now it may be that building such a multi-target compiler today is just
>> as arduous as making sure one has a native compiler of the same
>> version before building the cross compiler, so my idea is of no
>> practical value. But if so, I hope in the long term that could be
>> fixed.
>> 
>> John
>> 
>> On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang  wrote:
>>> Hello John,
>>> 
>>> Almost!
>>> 
>>> As you point out, if you just want a cross-compiler, you don't
>>> need to build stage2.  The real problem is that we want stage0
>>> to be *the same version* as stage1, so that stage0 has the correct
>>> API in order to load stage0 libraries which are going to be used
>>> for TH, plugins, etc.  (Alternately, build a non-cross-compiler
>>> stage1, and then a cross-compiler stage2--NOT a cross compiled
>>> stage 2.)
>>> 
>>> Edward
>>> 
>>> Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800:
 From #11378:
 
> Can we actually link against the old version of ghc? Yes we can! All we 
> need is
> (1) for it to have been built with a different IPID, and
> (2) to use module renaming to rename the relevant modules to a different
> module name, so that we can import them without a conflict.
 
 
 If I understand this, you are saying stage1 links stage0 (the normal,
 non-cross-compiler used to build stage1), to build stage2? I agree
 that should work, but if stage1 is multi-target isn't that level of
 complexity not even needed? I'm not too familiar with GHC or its build
 system, but a multi-target compiler that doesn't support normal TH
 doesn't seem that hard to build in principle.
 
 John
 
 On Tue, Jan 19, 2016 at 3:59 PM, Ericson, John  
 wrote:
> Ah thanks for the link. Template Haskell with only {-# TH-ON

Re: Host-Oriented Template Haskell

[Edward Z. Yang]

I've filed a Trac ticket for this: 
https://ghc.haskell.org/trac/ghc/ticket/11470#ticket

Edward

Excerpts from Moritz Angermann's message of 2016-01-20 22:55:36 -0800:
> Colour me an interested party!  For iOS one currently builds two
> different ghc compiler.  One for the simulator (i386) and one for the
> actual device (arm).  My initial work on bringing ghcjs’s TH support,
> (which basically ships the TH out to a process on the target to compile
> and brings back the compiled TH into the cross compiler) to ghc, was
> based on the idea of having a TH handler plugin, which would handle the
> TH parts, and could then be adapted for different TH situations.  This
> of course could only work if the plugin was compiled with the same version
> of ghc, that the cross compiler was.
> 
> I wonder if the multi-target pipeline might be simpler to achieve with
> the llvm backend.
> 
> If someone is taking a shot at this, I’d like to help!
> 
> Cheers,
>  Moritz
> 
> > On Jan 21, 2016, at 2:44 PM, Edward Z. Yang  wrote:
> > 
> > Yes, in principle, a compiler that supports cross-compiling to many
> > targets without needing to be configured (at build time) which
> > target it should support is ideal.  Unfortunately, currently GHC
> > relies on autoconf to determine all of the necessary parameters
> > for a cross-compile.  I am not sure how feasible it would be to
> > allow these parameters to be configured at runtime: it might be
> > easy, it might be hard!  (And of course you have to arrange
> > to have cross-compiled all the boot libraries too...)
> > 
> > In any case, I think that a GHC that permits changing cross-compilation
> > targets at runtime is a fine goal, and if it is supported, then we
> > would only have to make adjustments to GHC internally to distinguish
> > between the interfaces/objects for various targets (including itself.)
> > 
> > Edward
> > 
> > Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800:
> >> Oops, Sent just to Edward by mistake.
> >> 
> >> 
> >> 
> >> That all sounds good to me---I think what I was thinking all along in
> >> fact, unless I am still missing some nuance :).
> >> 
> >> My idea of using a multi-target compiler was to avoid needing stage0
> >> to be the same version as stage1 (or adding a new stage, stage1 as in
> >> your alternative). The cross compiler is multi-target so it doesn't
> >> need to link another compiler to load plugins / run "host-oriented
> >> Template Haskell". I mentioned the usecase of trying to build a stage2
> >> which needs plugins / Host-Oriented Template Haskell, but it could
> >> well apply to building anything else with the need for those to things
> >> (and not normal TH, which cannot be built with a cross compiler)
> >> 
> >> In diagrams, rather than:
> >> 
> >>> stage0 (version foo, platform-x -> platform-x)
> >>> ==> stage1 (version foo, platform-x -> platform-y)
> >>> ==> some program (with plugins, with host-oriented TH, without normal TH)
> >> 
> >> or
> >> 
> >>> stage0 (version bar, platform-x -> platform-x)
> >>> ==> stage1 (version foo, platform-x -> platform-x) ->
> >>> ==> stage2 (version foo, platform-x -> platform-y) ->
> >>> ==> some program (with plugins, with host-oriented TH, without normal TH)
> >> 
> >> do just
> >> 
> >>> stage0 (version bar, platform-x -> platform-x)
> >>> ==> stage1 (version foo, platform-x -> {platform-x, platform-y})
> >>> ==> some program (with plugins, with host-oriented TH, without normal TH)
> >> 
> >> Now it may be that building such a multi-target compiler today is just
> >> as arduous as making sure one has a native compiler of the same
> >> version before building the cross compiler, so my idea is of no
> >> practical value. But if so, I hope in the long term that could be
> >> fixed.
> >> 
> >> John
> >> 
> >> On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang  wrote:
> >>> Hello John,
> >>> 
> >>> Almost!
> >>> 
> >>> As you point out, if you just want a cross-compiler, you don't
> >>> need to build stage2.  The real problem is that we want stage0
> >>> to be *the same version* as stage1, so that stage0 has the correct
> >>> API in order to load stage0 libraries which are going to be used
> >>> for TH, plugins, etc.  (Alternately, build a non-cross-compiler
> >>> stage1, and then a cross-compiler stage2--NOT a cross compiled
> >>> stage 2.)
> >>> 
> >>> Edward
> >>> 
> >>> Excerpts from Ericson, John's message of 2016-01-19 16:13:24 -0800:
>  From #11378:
>  
> > Can we actually link against the old version of ghc? Yes we can! All we 
> > need is
> > (1) for it to have been built with a different IPID, and
> > (2) to use module renaming to rename the relevant modules to a different
> > module name, so that we can import them without a conflict.
>  
>  
>  If I understand this, you are saying stage1 links stage0 (the normal,
>  non-cross-compiler used to build stage1), to build stage2? I agree
>  that should work, but if stage1 is m