Re: A bug of linebuffering

[山本和彦]

Hi,

I found a workaround for this problem.

https://github.com/sol/doctest-haskell/issues/57

--Kazu

> Hi,
> 
> While I support GHC head for "doctest", I encountered the following
> bug.
> 
> "doctest" uses a GHCi subprocess to evaluate an expression represented
> in String. Stderr from GHCi is merged into stdout by hDuplicateTo in
> the GHCi side. Even evaluating an error expression, for instance "1
> `div` 0", the line buffering does not work. "doctest" waits for output
> from GHCi forever. This does not happen if stderr is not merged into
> stdout.
> 
> The following code demonstrates this bug. Running it with GHC head
> waits forever. Running it with GHC 7.6.3 prints:
> "*** Exception: divide by zero"
> "3"
> 
> If you change "1 `div` 0" into "1 `div` 0\nprint 10", this code run by
> GHC head prints:
> "*** Exception: divide by zero"
> "10"
> 
> This is a serious behavior change for "doctest". I hope this will be
> fixed.
> 
> --Kazu
> 
> module Main where
> 
> import System.Process
> import System.IO
> 
> myProc :: CreateProcess
> myProc = (proc "ghc" ["-v0", "--interactive", "-ignore-dot-ghci"]) {
> std_in  = CreatePipe
>   , std_out = CreatePipe
> , std_err = Inherit
>   }
> 
> setMode :: Handle -> IO ()
> setMode hdl = do
> hSetBinaryMode hdl False
> hSetBuffering hdl LineBuffering
> 
> newInterpreter :: IO (Handle, Handle)
> newInterpreter = do
> (Just stdin_, Just stdout_, _, _) <- createProcess myProc
> setMode stdin_
> setMode stdout_
> hPutStrLn stdin_ "import System.IO"
> hPutStrLn stdin_ "import GHC.IO.Handle"
> hPutStrLn stdin_ "hDuplicateTo stdout stderr"
> hFlush stdin_
> return (stdin_, stdout_)
> 
> eval :: Handle -> Handle -> String -> IO String
> eval hin hout expr = do
> hPutStrLn hin expr
> hFlush hin
> hGetLine hout
> 
> main :: IO ()
> main = do
> (stdin_, stdout_) <- newInterpreter
> eval stdin_ stdout_ "1 `div` 0" >>= print
> eval stdin_ stdout_ "1 + 2" >>= print
> return ()
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: delete remote branch

[Nicolas Frisby]

Got it. Thank you, gentlemen.
On Sep 10, 2013 8:45 PM, "Austin Seipp"  wrote:

> Nick, just keep the ActiveBranches[1] page on the wiki up to date. I
> plan on deleting all the dead branches (and sending out a warning
> beforehand) after the 7.8 release. We'll be doing other cleanups then
> too.
>
> On Tue, Sep 10, 2013 at 2:07 PM, Nicolas Frisby
>  wrote:
> > Thanks Herbert.
> >
> > Whom should I email you again when I'm ready to delete my other branches?
> > You? Austin?
> >
> >
> > On Sun, Sep 8, 2013 at 3:43 AM, Herbert Valerio Riedel 
> wrote:
> >>
> >> Hello Nicolas,
> >>
> >> On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote:
> >> > I just merged in my -fdicts-strict work, so I was deleting the old
> >> > branch…
> >> > but it's rejected for some reason.
> >> >
> >> > $ git push origin --delete dicts-strict
> >> > remote: performing tab-check...
> >> > remote: + refs/heads/dicts-strict ghc  DENIED by fallthru
> >> > remote: error: hook declined to update refs/heads/dicts-strict
> >> > To ssh://g...@git.haskell.org/ghc.git
> >> >  ! [remote rejected] dicts-strict (hook declined)
> >> > error: failed to push some refs to 'ssh://g...@git.haskell.org/ghc.git
> '
> >> >
> >> > Git gurus chime in? Thanks.
> >>
> >> The current configuration doesn't permit risky operations, such as
> >> deleting branches and/or non-forward-updates (imagine someone would
> >> delete or rebase branches such as 'master' or 'ghc-7.6'). Moreover,
> >> having commits disappear causes headaches with other facilities
> >> (e.g. git submodules).
> >>
> >> Moreover, it was planned to define a Git ref namespace, where those
> >> operations would be allowed to everybody, something like 'wip/*' (see
> >> [1] for an example). Those branches could then also be made to be
> >> ignored by the Git email notifier, so that rebasing commits doesn't spam
> >> the Git commits mailing list.
> >>
> >> In the long-term, we should avoid cluttering the top-level branch
> >> namespace[2] with topic branches, and move to a more structured naming
> >> scheme, which leaves the top-level namespace to release branches.
> >>
> >> Long story short, I've deleted the 'dicts-strict' branch for you
> >>
> >> Cheers,
> >>   hvr
> >>
> >>  [1]: https://git.gnome.org/browse/glib/
> >>  [2]: http://git.haskell.org/?p=ghc.git;a=heads
> >
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
> Austin - PGP: 4096R/0x91384671
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: delete remote branch

[Austin Seipp]

Nick, just keep the ActiveBranches[1] page on the wiki up to date. I
plan on deleting all the dead branches (and sending out a warning
beforehand) after the 7.8 release. We'll be doing other cleanups then
too.

On Tue, Sep 10, 2013 at 2:07 PM, Nicolas Frisby
 wrote:
> Thanks Herbert.
>
> Whom should I email you again when I'm ready to delete my other branches?
> You? Austin?
>
>
> On Sun, Sep 8, 2013 at 3:43 AM, Herbert Valerio Riedel  wrote:
>>
>> Hello Nicolas,
>>
>> On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote:
>> > I just merged in my -fdicts-strict work, so I was deleting the old
>> > branch…
>> > but it's rejected for some reason.
>> >
>> > $ git push origin --delete dicts-strict
>> > remote: performing tab-check...
>> > remote: + refs/heads/dicts-strict ghc  DENIED by fallthru
>> > remote: error: hook declined to update refs/heads/dicts-strict
>> > To ssh://g...@git.haskell.org/ghc.git
>> >  ! [remote rejected] dicts-strict (hook declined)
>> > error: failed to push some refs to 'ssh://g...@git.haskell.org/ghc.git'
>> >
>> > Git gurus chime in? Thanks.
>>
>> The current configuration doesn't permit risky operations, such as
>> deleting branches and/or non-forward-updates (imagine someone would
>> delete or rebase branches such as 'master' or 'ghc-7.6'). Moreover,
>> having commits disappear causes headaches with other facilities
>> (e.g. git submodules).
>>
>> Moreover, it was planned to define a Git ref namespace, where those
>> operations would be allowed to everybody, something like 'wip/*' (see
>> [1] for an example). Those branches could then also be made to be
>> ignored by the Git email notifier, so that rebasing commits doesn't spam
>> the Git commits mailing list.
>>
>> In the long-term, we should avoid cluttering the top-level branch
>> namespace[2] with topic branches, and move to a more structured naming
>> scheme, which leaves the top-level namespace to release branches.
>>
>> Long story short, I've deleted the 'dicts-strict' branch for you
>>
>> Cheers,
>>   hvr
>>
>>  [1]: https://git.gnome.org/browse/glib/
>>  [2]: http://git.haskell.org/?p=ghc.git;a=heads
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,
Austin - PGP: 4096R/0x91384671
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: delete remote branch

[Nicolas Frisby]

Thanks Herbert.

Whom should I email you again when I'm ready to delete my other branches?
You? Austin?


On Sun, Sep 8, 2013 at 3:43 AM, Herbert Valerio Riedel  wrote:

> Hello Nicolas,
>
> On 2013-09-08 at 09:41:04 +0200, Nicolas Frisby wrote:
> > I just merged in my -fdicts-strict work, so I was deleting the old
> branch…
> > but it's rejected for some reason.
> >
> > $ git push origin --delete dicts-strict
> > remote: performing tab-check...
> > remote: + refs/heads/dicts-strict ghc  DENIED by fallthru
> > remote: error: hook declined to update refs/heads/dicts-strict
> > To ssh://g...@git.haskell.org/ghc.git
> >  ! [remote rejected] dicts-strict (hook declined)
> > error: failed to push some refs to 'ssh://g...@git.haskell.org/ghc.git'
> >
> > Git gurus chime in? Thanks.
>
> The current configuration doesn't permit risky operations, such as
> deleting branches and/or non-forward-updates (imagine someone would
> delete or rebase branches such as 'master' or 'ghc-7.6'). Moreover,
> having commits disappear causes headaches with other facilities
> (e.g. git submodules).
>
> Moreover, it was planned to define a Git ref namespace, where those
> operations would be allowed to everybody, something like 'wip/*' (see
> [1] for an example). Those branches could then also be made to be
> ignored by the Git email notifier, so that rebasing commits doesn't spam
> the Git commits mailing list.
>
> In the long-term, we should avoid cluttering the top-level branch
> namespace[2] with topic branches, and move to a more structured naming
> scheme, which leaves the top-level namespace to release branches.
>
> Long story short, I've deleted the 'dicts-strict' branch for you
>
> Cheers,
>   hvr
>
>  [1]: https://git.gnome.org/browse/glib/
>  [2]: http://git.haskell.org/?p=ghc.git;a=heads
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

the spam should stop now

[Carter Schonwald]

I pingged the haskell infrastructure folks, and they've hopefully fixed it
up properly.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Proposal: Improving the IsString String instance

[Simon Peyton-Jones]

(redirecting to ghc-devs)

Thomas

Let's be clear what is happening here.  After all the dust has settled we call 
TcSimplify.applyDefaultingRules to look at a bunch of unsolved constraints and 
generate new, extra constraints that might help solve them. 

Thus if we see (Eq a, Num a)
we might generate the extra constraint (a ~ Integer)
to try to help solve them.

Now, what you want to do is to spot a constraint like (IsString [a]),
and generate (a ~ Char).

Now it's true that the current machinery in findDefaultableGroups is set up to 
look for constraints of form (C a), because that's what the rules say. If you 
change the rules you'll need to change the code.

But I'm not even sure what the new rule *are*.  The current GHCi defaulting 
rules are documented here:
http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules

The first thing to do is to write down the exact new rules that you are trying 
to implement.

Simon


| -Original Message-
| From: Thomas Schilling [mailto:nomin...@googlemail.com]
| Sent: 09 September 2013 23:24
| To: Ganesh Sittampalam
| Cc: Simon Peyton-Jones; Edward Kmett; Haskell Libraries
| Subject: Re: Proposal: Improving the IsString String instance
| 
| I took a stab at implementing this.  Having a superclass would probably
| make the implementation simpler.
| 
| I can't figure out the proper way to add a "C [a] = " constraint to
| the simplifier.  The defaulting mechanism currently just looks tries
| combinations of "a := " for all the candidate types.  If "a" is not
| just a type variable this needs to be add another wanted constraint, but
| I couldn't find a function that satisfies that purpose.  (Even though I
| read the OutsideIn(X) journal paper a while ago, the type checker code
| does indeed seem nearly impenetrable -- there's still some boxy
| unification code in TcUnify, and it's not clear how that interacts with
| the new solver.)
| 
| Anyway, if someone can point out how I to turn "setWantedTyBind tv ty"
| into something like "setWantedEquality ty1 ty2" I can implement it.
| Otherwise, I'd have to use use some rather gnarly hack that special-
| cases "C [a] = " to "a := Char" iff " == String"
| 
|  / Thomas
| 
| On 29 Aug 2013, at 08:03, Ganesh Sittampalam  wrote:
| 
| > I'd be marginally in favour of the new class + simpler defaulting
| rule.
| >
| > This is mostly on the philosophical ground that it's better to compose
| > existing features than to introduce new ones.
| >
| > It also feels like it might be more future-proof/flexible, though I
| > can't think of a compelling example. A weak one is that someone might
| > want to work with Array Char or similar.
| >
| > On 27/08/2013 08:29, Simon Peyton-Jones wrote:
| >> PS: I'm not convinced that it's worth the overhead of adding a new
| class. Modifying the defaulting rules would probably be enough, although
| it does involve one new feature, namely that it must default IsString
| [beta] as well as IsString alpha.
| >>
| >> Simon
| >>
| >> | -Original Message-
| >> | From: Simon Peyton-Jones
| >> | Sent: 27 August 2013 08:27
| >> | To: 'Ganesh Sittampalam'; Edward Kmett
| >> | Cc: Haskell Libraries
| >> | Subject: RE: Proposal: Improving the IsString String instance
| >> |
| >> | If I understand aright, the problem is that we end up with
| constraints
| >> | like
| >> |  IsString alpha
| >> | or
| >> |  IsString [beta]
| >> | where alpha or beta are otherwise-unconstrained unification
| variables.
| >> | Under those circumstances we'd like to default to IsString String.
| >> |
| >> | This is *exactly* what the current type-class-defaulting mechanism
| does.
| >> | Eg with (show 3) you get (Show alpha, Num alpha) and want to choose
| >> | alpha to be something sensible.
| >> |
| >> | We've already extended it for GHCi
| >> |
| http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-
| >> | evaluation.html#extended-default-rules
| >> |
| >> | I don't think this would be controversial.  The path seems to be:
| >> |  propose a concrete extension to the rules,
| >> |  specify when it's enabled
| >> |  get everyone to agree
| >> |  provide a patch (relevant code is in
| >> | TcSimplify.applyDefaultingRules)
| >> |
| >> | Simon
| >> |
| >> | | -Original Message-
| >> | | From: Libraries [mailto:libraries-boun...@haskell.org] On Behalf
| Of
| >> | | Ganesh Sittampalam
| >> | | Sent: 26 August 2013 21:55
| >> | | To: Edward Kmett
| >> | | Cc: Haskell Libraries
| >> | | Subject: Re: Proposal: Improving the IsString String instance
| >> | |
| >> | | Couldn't it work (with suitable extensions to the list of blessed
| >> | | classes) with Henning's IsCharList suggestion? The unresolved
| >> | constraint
| >> | | would be IsCharList a.
| >> | |
| >> | | On 26/08/2013 21:47, Edward Kmett wrote:
| >> | | > The problem is ExtendedDefaultRules only works when the whole
| type
| >> | is
| >> | | > unknown. If we know part of the type e.g. that it is 

Re: 如何构建人力资源管理系统

[Niculae Ionita]

Hi developers,

I anyone else getting this kind of emails from the ghc-devs list, or 
it's only me?


Nicu

Am 11.09.2013 21:51, schrieb 沛菡姐:


　　
*企业绩效考核与薪酬体系 设计实战特训班
*　
*培训时间：*2013年9月13-15日深圳、10月25-27日深圳、11月07-09日上海、 
11月15-17日广州


*培训对象：*董事长、总（副）经理、企业中高 阶主管及企业营销中高层管理 
人士。


*培训费用：*4800元/人（包括资料费、午 餐、茶点、发票等）

【深圳/市/场/部】0755-6128/8907 【上海/市/场/部】021-3126/1580
【北京/市/场/部】 010-5129/5409【广州/市场/部】020-6113/3775

*课程背景：
*　　现代企业管理，更注重“以人为本”的人性化管理模式，企业管理的重点也 
日趋体现在对人的
管理策略上。作为现代企业的人力资源管理者，应以战略高度构建高效实用的人 
力资源管理系统，
建立科学考核激励制度和先进的企业薪酬体系，以最大限度地激发人才潜能，来 
创建优秀团队，并
推动组织变革与创新，最终实现组织的持续发展。我们针对中国企业在推行西方 
管理模式中的种种
弊端和疑惑，以及中国企业目前正处于改革与创新时期，特举办“企业绩效考核 
与薪酬管理实战特
训班”。由著名人力资源专家著名教授，蔡巍老师讲授，旨在帮助企业家、人力 
资源经理开阔思路，

激发灵感，培养带领企业持续健康发展的卓越人力资源管理人才，欢迎参加！
　
*课程收益：
*了解薪酬改革背景，更新观念，理清改革思路，明确改革目标，
解岗位测评的相关知识，科学进行岗位测评；
认识绩效管理的重要性、并正确理解绩效管理，
学习考核的方法，全面了解绩效管理的运作程序和设计方法，
重点学习KPI、并介绍平衡计分卡，
了解绩效管理推进中的问题、并避免运作中的误区。
　
*导师简介：[蔡巍]
*　　国内知名的人力资源管理实务专家，工商管理硕士，权威人力资源管理实 
战专家，特别在绩效
与薪酬体系设计方面有很深的造诣，形成了自己特有的实战方法；曾为大型企业 
集团、上市公司、

连锁业集团、高科技公司等多个行业的众多企业进行过全面的人力资源咨询服务。
是《中国经营报》、《人力资本》等多家媒体专栏的特约撰稿人和专家评论员。
　　 蔡先生近几年出版的书籍有：《奔跑的蜈蚣：如何以考核促进成长》.《吹口 
哨的黄牛：以薪
酬留住人才》、《KPI，“关键绩效”指引成功》、《BSC，“平衡计分”保证发展》，受 
到企业的

高度重视，和给予极高的评介。
　　 曾经辅导与参加过蔡老师培训的企业有：东风汽车、东软集团、中国石油 
股份、TCL、青岛啤
酒、振杰国际、创维集团、徐工集团、三一重工、粤高速、农业银行、北京网 
通、山西移动、河南
移动、宁波成路集团、东风学铁龙、雪铁龙、中国电信、广州西婷化妆品、万家 
乐燃气热水器、格
力空调、南航、新疆华世丹药业、南方李锦记、首信集团、光明维他奶、华工科 
技、达实智能、拓

邦电子、武汉高创集团 、华美集团等企业。
　
*课程大纲：
*一．推行KPI与绩效管理体系需要解决的三大问题
1、企业建立绩效体系所面临的方法问题；
　 以感觉为基础判断还是以事实为基础判断？
　 短期考核还是长期考核？
　 短期利益还是长期利益？
　 关键业绩还是非关键业绩？
　 绩效管理如何与战略接口？
　 KPI成绩与奖金挂钩的问题？
2、经理人与员工的认识对推行绩效管理的影响；
　 传统文化对绩效管理的影响
　 为什么没有人愿意做A？
　 为什么推行绩效管理这么困难？
3、管理基础对推行KPI的影响
　
二．KPI操作中的几个基本问题
1、什么是目标与指标
2、KPI指标的基本属性与操作注意要点
　 为什么评价起来感觉很难操作——刻度问题；
　 他们为什么不接受这些考核指标——可控性问题
　 为什么考核这些指标后适得其反——行为问题
3、KPI指标的类型与各个类型KPI指标操作中的注意点：
   财务非财务、时点时期、定量定性、长周期短周期，总量相对
4、职能部门的定性指标，该如何操作？
　
三．建立KPI体系的方式方法：
如何在公司建立KPI体系呢？方法很多，各种方法的适用范围是什么？
企业又高层、中层、基层，怎样保证各个层次的KPI指标层层关联？
1、通过工作分析，明确职责，然后根据职位说明书找KPI指标的操作模式与优点 
缺点与适用范围

2、价值树的操作模式与优点缺点
3、鱼骨图与头脑风暴法
　
四．平衡计分卡
1、平衡计分卡只是从四个角度找指标吗？——平衡计分卡的本质；
2、战略与平衡计分卡有什么关系？——战略与战略地图；
3、平衡计分卡是按照长期、中期、还是短期计划制定？
——平衡计分卡与企业的长期、中期、短期规划；
4、平衡计算分卡就是四个纬度吗？
5、公司级的平衡计分卡如何落实到各个部门呢？
——平衡计分卡的落实；
　
五．如何分解KPI
KPI如果不分解落实下去，就会失去了基础，但是分解KPI的过程中会遇到很多问题，
比如：一个kpi指标和好多部门都有关系，到底考核谁好呢？
如何解决这些问题呢？如何将KPI分解落实下去呢？
1、如何分解KpI——上一级指标与下级指标的关系
2、分解指标的2种基本方法
3、按照驱动因素分解KPI指标，3种基本的模式
4、分解KPI指标的注意问题：权利对指标分解的影响、
组织结构的影响、指标的冲突性等
　
六．指标词典的编制
指标找到了就万事大吉了？还存在什么问题呢？为什么需要定义KPI，怎样定义KPI?
1、为什么需要定义KPI
2、财务指标定义时，需要注意的问题；
3、非财务指标，定义时需要注意的问题；
3、谁来提供数据——自己提供，别人提供，利益相关者提供？
4、几个有问题的KPI的定义的分析；
　
七．确定目标——KPI的计分方式
找到了衡量指标就可以了嘛？如何确定目标呢？超过了目标应该计多少分？
没有达到目标应该得多少分？
1、设定目标的痛苦；
2、目标订不准怎么办？
3.没有历史数据怎么办？
4、竞争，资源，能力对目标的影响；
5、如何让下属主动把目标定的最合适——联合基法
6、长周期的目标如何分解到短周期；
7、痛苦考核与快乐考核——什么时候做到了该加分，
什么时候该扣分，KPI的计分方法；
　
八．绩效管理的周期
年底成绩是每个月成绩的加总嘛？年考核考什么？月考考核什么？
不同的业务类型与职能部门在考核的周期上有什么区别呢？
1、年考考什么？月考考什么？
2、长周期与短周期；
3、不同层次与职能部门的周期；
4、如何设置KPI指标权重——指标的组合方式
　
九．主基二元考核法
关注了关键业绩指标，非关键业绩指标怎么办？
不关注非关键业绩指标是否会出问题？
如果全面关注关键业绩指标和非关键业绩指标，
资源是否够用？如何解决这个问题呢？
1、KPI所无法解决的问题；
2、主要绩效与基础绩效的关系；
3、如何在实践中运用主基二元考核法；
　
十．绩效面谈与沟通
1、计划阶段的绩效沟通
2、辅导阶段
3、考核阶段的绩效沟通
4、绩效问题分析与改进——组织改进、领导改进、员工改进；
　
十一．推行绩效管理所遇到的问题与对策；
推行KPI不只是人力资源部门或者企管部门的事情，
KPI在推行过程中有哪些问题与难点呢？
1、推行绩效管理的组织模式与各个部门的职责；
2、推行的程序；
3、公司政治与绩效管理的推行
4、绩效管理与企业文化；
　
薪酬体系设计课纲：
一、岗位分析的作用与意义
1、岗位分析的作用；
2、为什么岗位分析总是做不好？
二、岗位分析的方法
1、组织与部门职责与岗位职责的关系
2、常用的岗位分析的方法--资料分析法，问卷法，观察法，部门职责分解法；
三、岗位分析的步骤与流程
1、组织结构设计与流程设计；
2、部门职责设计；
3、岗位职责设计；
4、岗位任职资格设计；
5、常见的岗位设计的误区与错误；
四、岗位说明书的运用
1、岗位说明书在薪酬设计中的运用；
2、岗位说明书在培训中的运用；
3、岗位说明书在招聘中的运用；
4、岗位说明书在考核中的运用；
引子：薪酬在人力资源价值链的位置；
一、薪酬管理中与设计核心问题
1、不近人意的薪酬设计对企业的影响；
2、薪酬战略的4大问题与两对核心矛盾；
3、薪酬管理中的几个核心问题；
二、薪酬设计需要解决的矛盾——内部公平性
1.内部公平性的常用工具——职位评估；
2.职位评估中常见的问题
3.职位评估案例
三、薪酬设计需要解决的矛盾——外部公平性
1.什么是外部公平性；
2.解决外部公平性常用的工具；
3.如何确定薪酬水平？
四、薪酬与能力的关系
1.薪酬如何影响员工能力；
2.如何评估员工能力；
3.能力薪酬的设计；
五、奖金设计如何使公司、部门、个人三挂钩；
1、几种公司、部门、个人奖金挂钩模式的思考；
2、几种模式优缺点的对比；
3、集团公司下属分子公司的效益是否要与集团公司挂钩？
六、奖金设计与外部因素的影响
1、老总的奖金究竟该不该发？
2、采购经理的奖金究竟该不该发？
3、如果过滤外部因素的影响；
七、薪酬设计的公平问题
1、业务部门与业务部门的平衡；
2、业务部门与职能部门的平衡；
3、能力差的人与能力强的人之间的平衡；
八、业内各部门奖金设计的要点
1、销售部门提成制，还是奖金制？
2、项目类型工作奖金的设计；
3、生产部门奖金的设计；
4、年薪制奖金的设计；
九、奖金的周期
1、奖金周期与考核周期；
2、年终奖还是年中奖；
3、时机选择要考虑的要点；
4、奖金的滞后性；
十、奖金在收入中所占有的比例；
1、100％奖金与100％固定；
2、不同类型人在收入中奖金的比例；
十一、如何解决好薪酬设计与企业发展之间的关系
1.企业不同的发展阶段薪酬管理的特点
2.如何以薪酬战略有效的激励员工，获得发展
十二、薪酬设计需要考虑的其他问题
1.薪酬与企业文化
2.薪酬与工作模式
十三、薪酬设计的过程与步骤
1.薪酬设计的几种方法
2.薪酬的调整难题




　



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: newtype coercion wrapping status

[Joachim Breitner]

Hi,

Am Montag, den 09.09.2013, 13:25 -0400 schrieb Richard Eisenberg:
> According to the original post and the comments on #5498
> (http://ghc.haskell.org/trac/ghc/ticket/5498), breaking through
> abstraction is another reason for keeping GND outside of Safe Haskell.
> I'm worried that the same concern would affect newtype coercions given
> the current proposal.

an easy fix would be to disallow coerce in Safe Haskell.

A similarly easy fix would be to add the requirements that constructors
have to be in scope when generating the
instance Coercible a b => Coercible (D a) (D b)
rule in Safe Haskell code. Although that might cripple the feature too
much, but not more than not having the feature at all.

I think the latter is a good compromise for the non-advertised release.

Greetings,
Joachim

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


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

Re: Preventing manual instances

[Joachim Breitner]

Hi,

Am Montag, den 09.09.2013, 15:57 + schrieb Simon Peyton-Jones:
> I think I'd prefer all of these checks to be done in
> checkValidInstHead. It makes sense... it's just the kind of thing that
> checkValidInstHead is for. It would remove clutter (and filtration)
> from tcInstDecls1.  
> 
> The same goes for the SafeHaskell checks in tcInstDecls1.
> 
> I'm not sure who is willing to do this?  If no one wants to do it now
> can someone make a ticket? But it might be easier just to cut to the
> chase and do it :-)

I tried to cut the chase, but the issue is that checkValidInstHead has
no idea whether the instance head it is about to check is a standalone
instance or a regular one. For Coercible this is fine, but for Typeable
it needs to allow standalone instances. So this requires more
refactoring than I’m comfortable to do at the moment, hence the
requested ticket:
http://ghc.haskell.org/trac/ghc/ticket/8264

Greetings,
Joachim

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


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

Re: [core libraries] RE: Alex and new Bool primops

[Michael Snoyman]

Having a requirement to manually install a newer Alex doesn't seem too
onerous to me. That would be my recommendation.


On Tue, Sep 10, 2013 at 11:53 AM, Simon Peyton-Jones
wrote:

>  (Simon M: are you ok with updating Alex?  You were the one of those who
> argued strongly for using the old names for the new primops.)
>
> ** **
>
> The difficulty is this.  
>
> **· **Alex generates Haskell code, by transforming Foo.x into
> Foo.hs
>
> **· **The generated Foo.hs contains references to comparison
> primops, say (>#) :: Int# -> Int# -> Bool
>
> **· **Therefore Foo.hs will not work with GHC 7.8 if we have
> changed the type of (>#), which is what I think we have agreed to do.
>
> **· **The solution is to make Alex generates a Foo.hs that is
> compilable either with GHC 7.8 or 7.6, by including enough CPP directives.
> Alex already does this for compatibility with earlier GHCs
>
> **· **However, until there is a new version of Alex, you simply
> won’t be able to bootstrap GHC 7.8 (or indeed the current HEAD).
>
> ** **
>
> That’s all there is to it.  It’s tiresome and trivial in a sense, but it’s
> a choice we have to make.
>
> ** **
>
> It might be perfectly reasonable to say 
>
> **· **You can’t build GHC 7.8 from source with the Haskell
> Platform until a new HP comes out with the new Alex (which will be soon).*
> ***
>
> **· **Unless you install the new Alex manually
>
> ** **
>
> This seems not too bad; people who build GHC from source are generally
> pretty savvy.  The choice between the two is what we seek your guidance on.
> 
>
> ** **
>
> (Incidentally, a very similar situation has arisen for Happy: see
> http://ghc.haskell.org/trac/ghc/ticket/8022.  But there the cost of
> perpetuating the status quo for another release cycle seems minimal.)
>
> ** **
>
> Simon
>
> ** **
>
> *From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
> Behalf Of *Michael Snoyman
> *Sent:* 10 September 2013 05:28
> *To:* Simon Peyton-Jones
> *Cc:* core-libraries-commit...@haskell.org; ghc-devs; Geoffrey Mainland;
> Jan Stolarek
> *Subject:* Re: [core libraries] RE: Alex and new Bool primops
>
> ** **
>
> I'll admit a fair amount of ignorance of the GHC build process. But
> wouldn't it be standard that any tool used in the GHC build process itself,
> and built by GHC itself, would need to have some conditional compilation in
> place to handle API changes? It seems like the questions here are whether
> we should ever allow breaking changes in the API, and in this case whether
> the changes are coming too late in the development cycle. It seems like
> we've agreed on the first count that it's beneficial to allow breaking API
> changes. It could be that in this case we're too late in the dev cycle.***
> *
>
> ** **
>
> In this case, it sounds like including the compatibility module in Alex
> would be most expedient, but I'd defer to those who understand the process
> better than me.
>
> ** **
>
> On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones 
> wrote:
>
>  Dear Core Libraries Committee
>
> I think we need your advice.
>
> This thread (mostly on ghc-devs) shows that if the shim-package and
> boolean-primop decision goes as currently proposed, then we'll need a new
> release of Alex
>  * Either to generate an import of GHC.Exts.Compat
>(ie depend on the shim package)
>  * Or to make its own local tiny shim module for the primops it uses
>  * Or maybe some other plan
> (Alex already has quite a bit of stuff designed to make it generate code
> that will be compilable with a variety of GHCs.)
>
> Moreover this new release of Alex will be necessary simply in order to
> allow 7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current
> HP could not be used to build GHC.
>
> How would you like us to proceed?  Thanks!
>
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> | Geoffrey Mainland
>
> | Sent: 09 September 2013 16:14
> | To: Jan Stolarek
> | Cc: ghc-devs
> | Subject: Re: Alex and new Bool primops
> |
>
> | I say this only somewhat facetiously, but this is *exactly* the sort of
> | problem that the pro-backwards compatibility camp anticipates, and I
> | mean the "pro-backwards compatibility camp" in the most general possible
> | way :) The point is that you can never anticipate all the ways in which
> | breaking backwards compatibility breaks things. How much "technical
> | debt" is really accrued with backwards compatible primops? What is
> | preventing us from doing the so-called "Right Thing" *after* the 7.8
> | release?
> |
> | Anyway, the one solution I can think of off the top of my head is to
> | patch Alex's templates to use an #ifdef to pick primops based on the
> | version of GHC being used for compilation. That will need to be done
> | anyway.
> |
> | As an aside, I think any discussion th

Re: extending GHC plugins with Hooks

[Nicolas Frisby]

My patch was extremely simple, so I'm asking for forgiveness instead of
permission!

https://github.com/ghc/ghc/commit/850490af1df426b306d898381a358a35425d16c7

The commit note includes a brief explanation of the benefits.

The motivation originates with the HERMIT project at Univ. of Kansas: we'd
like to help the user generate new top-level declarations in a module (eg a
new datatype). Re-using the type-checker seems the simplest path towards
robustness and feature completeness and this patch removes a simple but
onerous obstacle.

Is this OK?

On Thu, Aug 22, 2013 at 11:13 AM, Simon Peyton-Jones
wrote:

>  Luite, Edsko, Thomas, Nicolas
>
> ** **
>
> You have all variously proposed improvements to the GHC API and/or the
> plug-in mechanism.  I have been so swamped in the last few months that I
> have not had a chance to look carefully at your proposals, nor how they
> relate to each other.
>
> ** **
>
> We are now only three weeks away from wanting to do a feature freeze on
> GHC 7.8, and there are a lot of other things that we want to complete
>
> http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
>
> (Mostly they have gestating for some time.)
>
> ** **
>
> So I’m hoping you’ll be ok with not putting these plugin-related changes
> into 7.8.  I have the sense that they’d benefit from more discussion among
> the folk interested in plugins.  Perhaps some of the ideas could be
> combined nicely; I don’t know.  And the people who are going to write
> plugins are also probably up for building HEAD anyhow.
>
> ** **
>
> (Exception: Luite, I think you have some fairly narrow, specific changes
> that would help GHCJS, and I’m probably fine with those if you care to send
> patches.)
>
> ** **
>
> Please say if you think there’s a really strong reason for putting stuff
> in the 7.8.
>
> ** **
>
> Thanks
>
> ** **
>
> Simon
>
> ** **
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Luite
> Stegeman
> *Sent:* 21 August 2013 03:51
> *To:* ghc-devs
> *Subject:* extending GHC plugins with Hooks
>
> ** **
>
> hi all,
>
> ** **
>
> Sorry for taking so long to get back with this. I'm proposing a somewhat
> general way for adding 'hooks' to the GHC API, where users can override
> parts of the default compiling pipeline.
>
> ** **
>
> Hooks are simply functions or actions that replace existing compiler
> functionality. This means that usually only one application can use a
> specific hook at a time. 
>
> ** **
>
> The obvious data structure to store the hooks is DynFlags. Unfortunately
> defining hooks in DynFlags directly would give birth to the mother of all
> import cycles, and it would also break the split-dll scheme on Windows. So
> here's the idea:
>
> ** **
>
> - Define each hook in the module where it's exported
>
> - For each hook make a 'phantom' DataType and an instance for the Hook
> type familiy
>
> - Add a TypeRep based map in DynFlags [0]
>
> - For each hooked function, check for existence of a hook in DynFlags,
> otherwise run the default. Example:
> https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L83
> 
>
> ** **
>
> Now this approach does have some disadvantages:
>
> - No clear integration with existing plugins (I've tried adding an
> onLoadPlugin field to Plugin, where the Plugin could update DynFlags when
> it's loaded, but it was a bit messy, and plugins would not be loaded in
> time for some hooks, particularly what Edsko needs)
>
> - More of GHC depends on type families
>
> - Decentralized hooks definitions feel a bit messy
>
> ** **
>
> So I'm open to suggestions for improvements (or replacements) of this
> scheme. I have some time the coming weeks to clean up or change the patch.
> 
>
> ** **
>
> We've been testing some hooks with GHCJS for a while, and so far they seem
> to provide what we need (but I'm going to doublecheck the coming weeks that
> we don't have missing functionality):
>
> ** **
>
> - Customizations for linking JavaScript code with our own library
> locations [1]
>
> - Hooking into the DriverPipeline so we can use the compilation manager [2]
> 
>
> - Desugaring customizations to remove some C-isms from the FFI code [3]***
> *
>
> - Typechecking foreign import javascript imports [4]
>
> - Override the built-in GHC.Prim so we can customize primop types [5]
>
> ** **
>
> I think it's easy to add those for Edsko and Thomas as well.
>
> ** **
>
> luite
>
> ** **
>
> [0]
> https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L239
> 
>
> [1]
> https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44*
> ***
>
> [2]
> https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192
> 
>
>
> https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L335
> 
>
> [3] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Fo

Re: [GHC] #8256: adding locality levels to prefetch# and friends

[Carter Schonwald]

Hey all,
I'd really love some preliminary feedback on this augmented prefetch patch,
1) so i can have any issues addressed before the merge window closes
2) If the basic patch looks good to folks (subject to some cleanup), I'd
like to also see about adding prefetch support on x86 native backend, and
fallback NOOP on other architectures. (because its something which
shouldn't be llvm only)

thanks!
-Carter


On Tue, Sep 10, 2013 at 1:21 PM, GHC  wrote:

> #8256: adding locality levels to prefetch# and friends
> -+
> Reporter:  carter|Owner:  carter
> Type:  task  |   Status:  new
> Priority:  normal|Milestone:  7.8.1
>Component:  Compiler  |  Version:  7.7
>   Resolution:| Keywords:
> Operating System:  Unknown/Multiple  | Architecture:  Unknown/Multiple
>  Type of failure:  None/Unknown  |   Difficulty:  Unknown
>Test Case:|   Blocked By:
> Blocking:|  Related Tickets:  #8252 ,#8107
> -+
>
> Comment (by carter):
>
>  one thing i'm worried i'm overlooking, is how do I make sure cmm-lint
>  knows about prefetch op types?
>
>  (or is that a none issue)
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Problems with validating template-haskell

[Jan Stolarek]

I have problems with validating my changes in template-haskell, file 
Language/Haskell/Th/Syntax.hs. I added isTrue# function in the import:

import GHC.Base ( Int(..), Int#, (<#), (==#), isTrue# )

And later on I'm using isTrue#. However, when stage1 compiler tries to compile 
Syntax.hs, validation fails (due to -Werror):

libraries/template-haskell/Language/Haskell/TH/Syntax.hs:19:1: Warning:
The import of ‛Int#, Int, ==#, <#’
from module ‛GHC.Base’ is redundant

The module obviously uses mentioned operators and data types. I wonder what did 
I miss. Ideas anyone?

Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [core libraries] RE: Alex and new Bool primops

[Jan Stolarek]

From a technical point of view changes to Alex and Happy are simple and already 
implemented on my branch:

https://github.com/jstolarek/alex/commit/32d4244894ae2702d965415483d0479d91570049
https://github.com/jstolarek/happy/commit/430ebe1f82744818cc488cd45fee0effaf5d4b47

I say we bite the bullet - this moment is as good as any other.

Janek

- Oryginalna wiadomość -
Od: "Simon Peyton-Jones" 
Do: "Michael Snoyman" 
DW: core-libraries-commit...@haskell.org, "ghc-devs" , 
"Geoffrey Mainland" , "Jan Stolarek" 
, "Simon Marlow" 
Wysłane: wtorek, 10 wrzesień 2013 9:53:07
Temat: RE: [core libraries] RE: Alex and new Bool primops

(Simon M: are you ok with updating Alex?  You were the one of those who argued 
strongly for using the old names for the new primops.)

The difficulty is this.

· Alex generates Haskell code, by transforming Foo.x into Foo.hs

· The generated Foo.hs contains references to comparison primops, say 
(>#) :: Int# -> Int# -> Bool

· Therefore Foo.hs will not work with GHC 7.8 if we have changed the 
type of (>#), which is what I think we have agreed to do.

· The solution is to make Alex generates a Foo.hs that is compilable 
either with GHC 7.8 or 7.6, by including enough CPP directives.  Alex already 
does this for compatibility with earlier GHCs

· However, until there is a new version of Alex, you simply won’t be 
able to bootstrap GHC 7.8 (or indeed the current HEAD).

That’s all there is to it.  It’s tiresome and trivial in a sense, but it’s a 
choice we have to make.

It might be perfectly reasonable to say

· You can’t build GHC 7.8 from source with the Haskell Platform until a 
new HP comes out with the new Alex (which will be soon).

· Unless you install the new Alex manually

This seems not too bad; people who build GHC from source are generally pretty 
savvy.  The choice between the two is what we seek your guidance on.

(Incidentally, a very similar situation has arisen for Happy: see 
http://ghc.haskell.org/trac/ghc/ticket/8022.  But there the cost of 
perpetuating the status quo for another release cycle seems minimal.)

Simon

From: michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] On Behalf Of 
Michael Snoyman
Sent: 10 September 2013 05:28
To: Simon Peyton-Jones
Cc: core-libraries-commit...@haskell.org; ghc-devs; Geoffrey Mainland; Jan 
Stolarek
Subject: Re: [core libraries] RE: Alex and new Bool primops

I'll admit a fair amount of ignorance of the GHC build process. But wouldn't it 
be standard that any tool used in the GHC build process itself, and built by 
GHC itself, would need to have some conditional compilation in place to handle 
API changes? It seems like the questions here are whether we should ever allow 
breaking changes in the API, and in this case whether the changes are coming 
too late in the development cycle. It seems like we've agreed on the first 
count that it's beneficial to allow breaking API changes. It could be that in 
this case we're too late in the dev cycle.

In this case, it sounds like including the compatibility module in Alex would 
be most expedient, but I'd defer to those who understand the process better 
than me.

On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones 
mailto:simo...@microsoft.com>> wrote:
Dear Core Libraries Committee

I think we need your advice.

This thread (mostly on ghc-devs) shows that if the shim-package and 
boolean-primop decision goes as currently proposed, then we'll need a new 
release of Alex
 * Either to generate an import of GHC.Exts.Compat
   (ie depend on the shim package)
 * Or to make its own local tiny shim module for the primops it uses
 * Or maybe some other plan
(Alex already has quite a bit of stuff designed to make it generate code that 
will be compilable with a variety of GHCs.)

Moreover this new release of Alex will be necessary simply in order to allow 
7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current HP could 
not be used to build GHC.

How would you like us to proceed?  Thanks!

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of
| Geoffrey Mainland
| Sent: 09 September 2013 16:14
| To: Jan Stolarek
| Cc: ghc-devs
| Subject: Re: Alex and new Bool primops
|
| I say this only somewhat facetiously, but this is *exactly* the sort of
| problem that the pro-backwards compatibility camp anticipates, and I
| mean the "pro-backwards compatibility camp" in the most general possible
| way :) The point is that you can never anticipate all the ways in which
| breaking backwards compatibility breaks things. How much "technical
| debt" is really accrued with backwards compatible primops? What is
| preventing us from doing the so-called "Right Thing" *after* the 7.8
| release?
|
| Anyway, the one solution I can think of off the top of my head is to
| patch Alex's templates to use an #ifdef to pick primops based on the
| ver

Re: [core libraries] RE: Alex and new Bool primops

[Geoffrey Mainland]

Sounds reasonable to me.

Geoff

On 9/10/13 11:37 AM, Michael Snoyman wrote:
> Having a requirement to manually install a newer Alex doesn't seem too
> onerous to me. That would be my recommendation.
>
>
> On Tue, Sep 10, 2013 at 11:53 AM, Simon Peyton-Jones
> mailto:simo...@microsoft.com>> wrote:
>
> (Simon M: are you ok with updating Alex?  You were the one of
> those who argued strongly for using the old names for the new
> primops.)
>
>  
>
> The difficulty is this. 
>
> · Alex generates Haskell code, by transforming Foo.x into
> Foo.hs
>
> · The generated Foo.hs contains references to comparison
> primops, say (>#) :: Int# -> Int# -> Bool
>
> · Therefore Foo.hs will not work with GHC 7.8 if we have
> changed the type of (>#), which is what I think we have agreed to do.
>
> · The solution is to make Alex generates a Foo.hs that is
> compilable either with GHC 7.8 or 7.6, by including enough CPP
> directives.  Alex already does this for compatibility with earlier
> GHCs
>
> · However, until there is a new version of Alex, you
> simply won’t be able to bootstrap GHC 7.8 (or indeed the current
> HEAD).
>
>  
>
> That’s all there is to it.  It’s tiresome and trivial in a sense,
> but it’s a choice we have to make.
>
>  
>
> It might be perfectly reasonable to say
>
> · You can’t build GHC 7.8 from source with the Haskell
> Platform until a new HP comes out with the new Alex (which will be
> soon).
>
> · Unless you install the new Alex manually
>
>  
>
> This seems not too bad; people who build GHC from source are
> generally pretty savvy.  The choice between the two is what we
> seek your guidance on.
>
>  
>
> (Incidentally, a very similar situation has arisen for Happy: see
> http://ghc.haskell.org/trac/ghc/ticket/8022.  But there the cost
> of perpetuating the status quo for another release cycle seems
> minimal.)
>
>  
>
> Simon
>
>  
>
> *From:*michael.snoy...@gmail.com
> 
> [mailto:michael.snoy...@gmail.com
> ] *On Behalf Of *Michael Snoyman
> *Sent:* 10 September 2013 05:28
> *To:* Simon Peyton-Jones
> *Cc:* core-libraries-commit...@haskell.org
> ; ghc-devs; Geoffrey
> Mainland; Jan Stolarek
> *Subject:* Re: [core libraries] RE: Alex and new Bool primops
>
>  
>
> I'll admit a fair amount of ignorance of the GHC build process.
> But wouldn't it be standard that any tool used in the GHC build
> process itself, and built by GHC itself, would need to have some
> conditional compilation in place to handle API changes? It seems
> like the questions here are whether we should ever allow breaking
> changes in the API, and in this case whether the changes are
> coming too late in the development cycle. It seems like we've
> agreed on the first count that it's beneficial to allow breaking
> API changes. It could be that in this case we're too late in the
> dev cycle.
>
>  
>
> In this case, it sounds like including the compatibility module in
> Alex would be most expedient, but I'd defer to those who
> understand the process better than me.
>
>  
>
> On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones
> mailto:simo...@microsoft.com>> wrote:
>
> Dear Core Libraries Committee
>
> I think we need your advice.
>
> This thread (mostly on ghc-devs) shows that if the
> shim-package and boolean-primop decision goes as currently
> proposed, then we'll need a new release of Alex
>  * Either to generate an import of GHC.Exts.Compat
>(ie depend on the shim package)
>  * Or to make its own local tiny shim module for the primops
> it uses
>  * Or maybe some other plan
> (Alex already has quite a bit of stuff designed to make it
> generate code that will be compilable with a variety of GHCs.)
>
> Moreover this new release of Alex will be necessary simply in
> order to allow 7.8 (or indeed 7.7) to be bootstrapped. So, for
> example, the current HP could not be used to build GHC.
>
> How would you like us to proceed?  Thanks!
>
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org
> ] On Behalf Of
> | Geoffrey Mainland
>
> | Sent: 09 September 2013 16:14
> | To: Jan Stolarek
> | Cc: ghc-devs
> | Subject: Re: Alex and new Bool primops
> |
>
> | I say this only somewhat facetiously, but this is *exactly*
> the sort of
> | problem that the pro-backwards compatibility camp
> antici

Re: Pattern synonyms: help needed: capturing EvBinds in tcPat

[Dr. ERDI Gergo]

Hi Richard,

Thanks for looking into this!

On Mon, 9 Sep 2013, Richard Eisenberg wrote:

I took a look here and would like to help, but I'm confused: What makes 
you think the dictionary for (Eq [b]) would be in scope? I can see where 
the (Eq b) comes from (the theta that pops out of patSynSig), but where 
does (Eq [b]) come from?



pattern P b b' = (MkT b b', ())

f (P x y) = [x] == [y]


I thought when I call 'thing_inside' in tcPatSynPat, it would (eventually) 
get to typechecking the right-hand side, which has a dependency on (Eq 
[b]). I thought this dependency is captured somewhere around here so that 
it(s solution) can be added to the pat_binds field of the ConPatOut. 
Otherwise, I don't see where it should be created -- and as you can see 
from the warning emitted by GHC, it is assumed later on to be there:


WARNING: file compiler/coreSyn/CoreSubst.lhs, line 272
CoreSubst.lookupIdSubst simpleOptExpr $dEq_an7{v} [lid]
InScope [(00, wild_00{v} [lid]), (X6, wild_X6{v} [lid]),
 (Xb, wild_Xb{v} [lid]), (amr, x{v amr} [lid]),
 (ams, y{v ams} [lid]), (amR, b{tv amR} [tv]),
 (an5, $dEq_an5{v} [lid]), (an8, cobox_an8{v} [lid]),
 (dnk, ds_dnk{v} [lid]), (dnl, ds_dnl{v} [lid]),
 (dnm, ds_dnm{v} [lid]), (dnr, cobox{v dnr} [lid]),
 (rgK, main:ConstrEx.f{v rgK} [lidx])]

here, $dEq_an5 is (Eq b), and $dEq_an7 is (Eq [b]).

So it seems the emitted core expects this (Eq [b]) to be there (bound to 
the parametrised instance (Eq[] (Eq b))).


Thanks,
Gergo
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: GHC 7.8 release status

[Simon Peyton-Jones]

I do like the single record.

I would really really like a strong clear Note [blah] on the hooks::Dynamic 
field of DynFlags. It's *so* non-obvious why it's dynamic, and the reason is a 
really bad one, namely the windows DLL split nonsense.  (Not our fault but 
still needs very clear signposting.)

I don't understand why we need 4 new hs-boot files.  Eg why DsMonad.hs-boot?  
It should be safely below Hooks.

Linker.hs-boot is solely because of LibrarySpec.  It would be possible to push 
that into HscTypes.  (Again with a comment to explain why.)

DriverPipeline is aleady 2,100 lines long, and could reasonably be split with 
CompPipeline in the PipelineMonad module, say.


In other words, a bit of refactoring might eliminate the loops *and* sometimes 
arguably improve the code.


I don't feel terribly strongly about all this.  It does feel a bit ad hoc... in 
a variety of places (eg deep in Linker.hs) there are calls to hooks, and it's 
not clear to me why exactly those are the right places. But I suppose they are 
simply driven by what has been needed.

Anyway if you two are happy (no one else seems to mind either way) then go 
ahead.

Simon


From: Luite Stegeman [mailto:stege...@gmail.com]
Sent: 10 September 2013 08:37
To: Edsko de Vries
Cc: Simon Peyton-Jones; ghc-devs; Edsko de Vries
Subject: Re: GHC 7.8 release status

Edsko has done some work of rearranging imports in DynFlags to make the DLL 
split work, and I've implemented the hooks on top of this, in a record, as 
discussed:

- 
https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch
 (not final yet, but should be usable for testing)
- demo program: https://gist.github.com/luite/6506064

Some disadvantages:
- as long as the DLL split exists, more restructuring will be required if a new 
hook is added to something in a module on which DynFlags depends
- 4 new hs-boot files required, new hooks will often require additional hs-boot 
files (when module A has a hook (so A imports Hooks, this can't be a source 
import), the hook will often have some types defined by A, so Hooks will have 
to import A)

Advantages (over type families / Dynamic hooks):
- Hooks neatly defined together in a single record

I'm not so sure myself, but if everyone agrees that this is better than the 
older hooks I'll convert GHCJS to the new implementation later today and 
finalize the patch (comments are a bit out of date, and I'm not 100% sure yet 
that GHCJS doesn't need another hook for TH support in certain setups) and 
update the wiki.

luite

On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries 
mailto:edskodevr...@gmail.com>> wrote:
Simon,

I talked to Luite this morning and I think we can come up with a
design that includes the enumeration we prefer, with a single use of
Dynamic in DynFlags -- it involves splitting off a PackageState module
from Packages so that DynFlags doesn't depend on the entirely of
Packages anymore (which would then, transitively, mean that it depends
on Hooks and hence on a large part of ghc), but I think that should be
doable. I'm working on that now.

Edsko

On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones
mailto:simo...@microsoft.com>> wrote:
> Edsko
>
>
>
> I'm very short of time right now. I think you understand the issues here.
> Can you do a round or two with Luite and emerge with a design that you both
> think is best?
>
>
>
> As I said earlier I'm uncomfortable with doing design work so late in the
> cycle, and I feel that I don't have time to study the various alternatives
> properly in the next four days.  But since you tell me it's crucial for
> GHCJS, I suppose that a possible compromise is this.  We release a GHC with
> some design for hooks, but specifically say that the hook design is evolving
> and may well change with the next version.  And then you two, with Thomas
> and other interested parties, work together to evolve a design that everyone
> is happy with.
>
>
>
> Does that sound ok?
>
>
>
> Simon
>
>
>
> From: Luite Stegeman [mailto:stege...@gmail.com]
> Sent: 07 September 2013 22:04
> To: Simon Peyton-Jones
> Cc: Thomas Schilling; Edsko de Vries; ghc-devs
>
>
> Subject: Re: GHC 7.8 release status
>
>
>
> * Why aren't you using Data.Dynamic for the hook things?  You are
> precisely doing dynamic typing after all.  (Moreover I want to change
> Data.Dynamic so that it says
>
>  data Dynamic where
>  Dyn :: Typeable a => a -> Dynamic
> and you want to take advantage of this.
>
>
>
> Ah the goal is to avoid the Typeable constraint on the hooked function, and
> to identify what things are actually hooks. Wrapping it in a newtype also
> achieves the first goal and does make the design a bit simpler.
>
>
>
> No need for these strange "data DsForeignsHook = DsForeignsHook" things, or
> for the Hook type family.  Simple!
>
> But it means that hooks are no longer recognisable by their type, they're
> just some Typeable (the type families approach would at le

RE: [core libraries] RE: Alex and new Bool primops

[Simon Peyton-Jones]

(Simon M: are you ok with updating Alex?  You were the one of those who argued 
strongly for using the old names for the new primops.)

The difficulty is this.

· Alex generates Haskell code, by transforming Foo.x into Foo.hs

· The generated Foo.hs contains references to comparison primops, say 
(>#) :: Int# -> Int# -> Bool

· Therefore Foo.hs will not work with GHC 7.8 if we have changed the 
type of (>#), which is what I think we have agreed to do.

· The solution is to make Alex generates a Foo.hs that is compilable 
either with GHC 7.8 or 7.6, by including enough CPP directives.  Alex already 
does this for compatibility with earlier GHCs

· However, until there is a new version of Alex, you simply won’t be 
able to bootstrap GHC 7.8 (or indeed the current HEAD).

That’s all there is to it.  It’s tiresome and trivial in a sense, but it’s a 
choice we have to make.

It might be perfectly reasonable to say

· You can’t build GHC 7.8 from source with the Haskell Platform until a 
new HP comes out with the new Alex (which will be soon).

· Unless you install the new Alex manually

This seems not too bad; people who build GHC from source are generally pretty 
savvy.  The choice between the two is what we seek your guidance on.

(Incidentally, a very similar situation has arisen for Happy: see 
http://ghc.haskell.org/trac/ghc/ticket/8022.  But there the cost of 
perpetuating the status quo for another release cycle seems minimal.)

Simon

From: michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] On Behalf Of 
Michael Snoyman
Sent: 10 September 2013 05:28
To: Simon Peyton-Jones
Cc: core-libraries-commit...@haskell.org; ghc-devs; Geoffrey Mainland; Jan 
Stolarek
Subject: Re: [core libraries] RE: Alex and new Bool primops

I'll admit a fair amount of ignorance of the GHC build process. But wouldn't it 
be standard that any tool used in the GHC build process itself, and built by 
GHC itself, would need to have some conditional compilation in place to handle 
API changes? It seems like the questions here are whether we should ever allow 
breaking changes in the API, and in this case whether the changes are coming 
too late in the development cycle. It seems like we've agreed on the first 
count that it's beneficial to allow breaking API changes. It could be that in 
this case we're too late in the dev cycle.

In this case, it sounds like including the compatibility module in Alex would 
be most expedient, but I'd defer to those who understand the process better 
than me.

On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones 
mailto:simo...@microsoft.com>> wrote:
Dear Core Libraries Committee

I think we need your advice.

This thread (mostly on ghc-devs) shows that if the shim-package and 
boolean-primop decision goes as currently proposed, then we'll need a new 
release of Alex
 * Either to generate an import of GHC.Exts.Compat
   (ie depend on the shim package)
 * Or to make its own local tiny shim module for the primops it uses
 * Or maybe some other plan
(Alex already has quite a bit of stuff designed to make it generate code that 
will be compilable with a variety of GHCs.)

Moreover this new release of Alex will be necessary simply in order to allow 
7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current HP could 
not be used to build GHC.

How would you like us to proceed?  Thanks!

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of
| Geoffrey Mainland
| Sent: 09 September 2013 16:14
| To: Jan Stolarek
| Cc: ghc-devs
| Subject: Re: Alex and new Bool primops
|
| I say this only somewhat facetiously, but this is *exactly* the sort of
| problem that the pro-backwards compatibility camp anticipates, and I
| mean the "pro-backwards compatibility camp" in the most general possible
| way :) The point is that you can never anticipate all the ways in which
| breaking backwards compatibility breaks things. How much "technical
| debt" is really accrued with backwards compatible primops? What is
| preventing us from doing the so-called "Right Thing" *after* the 7.8
| release?
|
| Anyway, the one solution I can think of off the top of my head is to
| patch Alex's templates to use an #ifdef to pick primops based on the
| version of GHC being used for compilation. That will need to be done
| anyway.
|
| As an aside, I think any discussion that involves making decisions that
| effect the community as a whole should have a public mail archive.
|
| Geoff
|
| On 09/09/2013 11:02 AM, Jan Stolarek wrote:
| > I think the there was a general agreement in the committee that we
| should follow the best long-term solution, not the best short-term one.
| Here are two arguments (Plan B = break backwards compatibility):
| >
| >   > I'd rather not hamstring GHC.* with a rats nest of backwards
| compatibility decisions,
| >   > which all come at accreted costs, the mort

Re: GHC 7.8 release status

[Luite Stegeman]

Edsko has done some work of rearranging imports in DynFlags to make the DLL
split work, and I've implemented the hooks on top of this, in a record, as
discussed:

-
https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch(not
final yet, but should be usable for testing)
- demo program: https://gist.github.com/luite/6506064

Some disadvantages:
- as long as the DLL split exists, more restructuring will be required if a
new hook is added to something in a module on which DynFlags depends
- 4 new hs-boot files required, new hooks will often require additional
hs-boot files (when module A has a hook (so A imports Hooks, this can't be
a source import), the hook will often have some types defined by A, so
Hooks will have to import A)

Advantages (over type families / Dynamic hooks):
- Hooks neatly defined together in a single record

I'm not so sure myself, but if everyone agrees that this is better than the
older hooks I'll convert GHCJS to the new implementation later today and
finalize the patch (comments are a bit out of date, and I'm not 100% sure
yet that GHCJS doesn't need another hook for TH support in certain setups)
and update the wiki.

luite


On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries wrote:

> Simon,
>
> I talked to Luite this morning and I think we can come up with a
> design that includes the enumeration we prefer, with a single use of
> Dynamic in DynFlags -- it involves splitting off a PackageState module
> from Packages so that DynFlags doesn't depend on the entirely of
> Packages anymore (which would then, transitively, mean that it depends
> on Hooks and hence on a large part of ghc), but I think that should be
> doable. I'm working on that now.
>
> Edsko
>
> On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones
>  wrote:
> > Edsko
> >
> >
> >
> > I’m very short of time right now. I think you understand the issues here.
> > Can you do a round or two with Luite and emerge with a design that you
> both
> > think is best?
> >
> >
> >
> > As I said earlier I’m uncomfortable with doing design work so late in the
> > cycle, and I feel that I don’t have time to study the various
> alternatives
> > properly in the next four days.  But since you tell me it’s crucial for
> > GHCJS, I suppose that a possible compromise is this.  We release a GHC
> with
> > some design for hooks, but specifically say that the hook design is
> evolving
> > and may well change with the next version.  And then you two, with Thomas
> > and other interested parties, work together to evolve a design that
> everyone
> > is happy with.
> >
> >
> >
> > Does that sound ok?
> >
> >
> >
> > Simon
> >
> >
> >
> > From: Luite Stegeman [mailto:stege...@gmail.com]
> > Sent: 07 September 2013 22:04
> > To: Simon Peyton-Jones
> > Cc: Thomas Schilling; Edsko de Vries; ghc-devs
> >
> >
> > Subject: Re: GHC 7.8 release status
> >
> >
> >
> > · Why aren’t you using Data.Dynamic for the hook things?  You are
> > precisely doing dynamic typing after all.  (Moreover I want to change
> > Data.Dynamic so that it says
> >
> >  data Dynamic where
> >  Dyn :: Typeable a => a -> Dynamic
> > and you want to take advantage of this.
> >
> >
> >
> > Ah the goal is to avoid the Typeable constraint on the hooked function,
> and
> > to identify what things are actually hooks. Wrapping it in a newtype also
> > achieves the first goal and does make the design a bit simpler.
> >
> >
> >
> > No need for these strange “data DsForeignsHook = DsForeignsHook” things,
> or
> > for the Hook type family.  Simple!
> >
> > But it means that hooks are no longer recognisable by their type, they're
> > just some Typeable (the type families approach would at least prevent
> users
> > from accidentally inserting wrong hooks, even though they would still be
> > able to make bogus instances on purpose)
> >
> > · The design *must* list all the hooks that GHC uses and their
> > types.  There’s no point in adding a hook that GHC doesn’t call!
> >
> > It appears to be difficult to define all hooks in one module or have
> them in
> > one record because of dependencies and the DLL split on Windows.
> > Re-exporting everything from a single module can be done, but would
> offer no
> > guarantees about completeness.
> >
> >
> >
> > With the type families design, everything that's an instance of Hook is a
> > hook, although the definitions are scattered throughout the GHC source.
> The
> > Dynamic design would just have to rely on a consistent naming convention.
> > Would listing the hooks in comments (in the Hooks module) and on the
> wiki be
> > a reasonable way to document them?
> >
> >
> >
> > I've uploaded a new patch, using Dynamic, although I'm not sure if it's
> an
> > improvement over the original one:
> >
> >
> >
> > - patch:
> >
> https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch
> >
> > - updated hooksDemo: https://gist.github.com/luite/6478973
> >
> >
> >
> > It also adds hscParse'