Akio Takano | 11 Jul 04:24 2016
Picon

ArgumentDo proposal updated

Hi glasgow-haskell-users,

Thank you for all the feedback to the ArgumentDo proposal. Following
the discussion, I made changes to the proposal and updated the wiki
page [0].

Now the proposed grammar is greatly simplified: it doesn't add a new
non-terminal anymore, indeed it removes one instead. The proposed set
of accepted programs remains unchanged.

I hope the this update addresses one major concern that was raised in
the previous discussion.

Any feedback is appreciated.

Regards,
Takano Akio

[0]: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Ralf Hutchison | 9 Jul 21:26 2016
Picon

Re: Glasgow-haskell-users Digest, Vol 155, Issue 9

Well Iavor likes it. (see 2 below)

Anyway, you know I'm really puzzled with the question of how to spend time.

Maybe you can help me.

In any case, it's such a lucky thing to have some to spend.

Toshia and I are watching season 4 of Game of Thrones.  I'm so addicted.

I'm also addicted to speed chess in the same way. (I am ralf_ben_h at chess.com)

I think that we have some structure in our minds, in our brains or our spines or our hearts say, and any story or game illuminates and awakens this structure.  The addictive feeling or attachment is a fascination with this part of ourselves and a willingness to experience it.

You wrote me a note about music recently.  How are you feeling about music today?

Best,
Ralph

On Sat, Jul 9, 2016 at 2:36 AM, <glasgow-haskell-users-request <at> haskell.org> wrote:
Send Glasgow-haskell-users mailing list submissions to
        glasgow-haskell-users <at> haskell.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

or, via email, send a message with subject or body 'help' to
        glasgow-haskell-users-request <at> haskell.org

You can reach the person managing the list at
        glasgow-haskell-users-owner <at> haskell.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Glasgow-haskell-users digest..."


Today's Topics:

   1. layout was Re: Proposal: ArgumentDo (C Maeder)
   2. Re: Proposal: ArgumentDo (Iavor Diatchki)
   3. Re: Proposal: ArgumentDo (C Maeder)
   4. Re: Proposal: ArgumentDo (Bardur Arantsson)
   5. Re: Proposal: ArgumentDo (Henrik Nilsson)


----------------------------------------------------------------------

Message: 1
Date: Fri, 8 Jul 2016 14:37:04 +0200
From: C Maeder <chr.maeder <at> web.de>
To: glasgow-haskell-users <at> haskell.org
Subject: layout was Re: Proposal: ArgumentDo
Message-ID: <577F9E70.5090300 <at> web.de>
Content-Type: text/plain; charset=utf-8

Hi,

the layout language options are hard to find (at least in the user
guide). Therefore I try to give an overview here. The relevant options
I've found by using ghc-7.10.3 with option --supported-languages are:

NondecreasingIndentation
DoAndIfThenElse

RelaxedLayout
AlternativeLayoutRule
AlternativeLayoutRuleTransitional

I ignore the last 3 options since these seem to be candidates for
removal: https://ghc.haskell.org/trac/ghc/ticket/11359.

The default option is NondecreasingIndentation, that is

  do
  x
  do
  y

is legal and parsed as a single expression "do {x ; do y}". With
-XNoNondecreasingIndentation one gets an "Empty 'do' block" for the
second do (and this error would not change with ArgumentDo!).

DoAndIfThenElse is not switched on by default and requires the keywords
"then" and "else" to be further indented for an "if" within a "do".

So I believe these options do not interfere with ArgumentDo, but maybe
this should be discussed more and maybe mentioned on the wiki page.

Surely a single space (inserted before x or removed before the second
"do") makes a difference between one or two argument expressions in the
example below.

HTH Christian

Am 08.07.2016 um 11:20 schrieb C Maeder:
> Surely layout can bite you:
>
>   f
>   do
>   x
>   do
>   y
>
> and I'm having difficulties to find the documentation for the various
> layout options.
>
> But this is no argument against this proposal!
>
> Improper use of white spaces can always be used to obfuscate code!
> Style guides are important. Furthermore, a wrong/unintended parse tree
> (due to layout) will - in many cases - result in a typing error.
>
> Christian



------------------------------

Message: 2
Date: Fri, 8 Jul 2016 09:42:24 -0700
From: Iavor Diatchki <iavor.diatchki <at> gmail.com>
To: Aloïs Cochard <alois.cochard <at> gmail.com>
Cc: GHC users <glasgow-haskell-users <at> haskell.org>, Henrik Nilsson
        <Henrik.Nilsson <at> nottingham.ac.uk>
Subject: Re: Proposal: ArgumentDo
Message-ID:
        <CAGK9nuo93t=-g9FktDG37iE7EeFwW6P5w5GOud3dmQkHA8oukg <at> mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

while  we are voting here, I kind of like this proposal, so +1 for me.

I understand that some of the examples look strange to Haskell old-timers
but, as Joachim points out, the behavior is very consistent.   Besides, the
"Less Obvious Examples" were selected so that they are, well, less obvious.
  The common use cases (as in ticket #10843) seem quite appealing, at least
to me, and not at all confusing.  But, then, I also like the
records-with-no-parens notation :-)

-Iavor



On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard <alois.cochard <at> gmail.com>
wrote:

> -1 for same reasons.
>
> On 8 July 2016 at 14:00, Henrik Nilsson <Henrik.Nilsson <at> nottingham.ac.uk>
> wrote:
>
>> Hi all,
>>
>> Joachim Breitner wrote:
>>
>> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
>> > > I don't think so: https://ghc.haskell.org/trac/ghc
>> > /wiki/ArgumentDo#Bl
>> > [...]
>> > Where is the outer set of parenthesis coming from?
>> >
>> > This is all not related to the ArgumentDo notation. Note that [...]
>>
>> The very fact that that experts can't easily agree on how a small
>> Haskell fragment is parsed to me just confirms that Haskell already
>> is a syntactically very cumbersome language.
>>
>> The present proposal just makes matters worse. For that reason
>> alone, I don't find it compelling at all. (So -1 from me, then.)
>>
>> I will not repeat the many other strong arguments against that has been
>> made. But I must say I don't find the use cases as documented
>> on the associated web page compelling at all. Maybe there is a tacit
>> desire to be able to pretend functions are keywords for various
>> creative uses in supporting EDSLs and such. But for that to be truly
>> useful, one need to support groups of related keywords. Something
>> like Agda's mixfix syntax springs to mind. But this proposal does
>> not come close, so the benefits are minimal and the drawbacks large.
>>
>> As a final point, the inherent asymmetry of the proposal (the
>> last argument position is special as, for certain kinds of
>> expressions, parentheses may be omitted there but not elsewhere)
>> is also deeply unsettling.
>>
>> Best,
>>
>> /Henrik
>>
>> --
>> Henrik Nilsson
>> School of Computer Science
>> The University of Nottingham
>> nhn <at> cs.nott.ac.uk
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.  Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users <at> haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160708/f6d53261/attachment-0001.html>

------------------------------

Message: 3
Date: Sat, 9 Jul 2016 09:09:17 +0200
From: C Maeder <chr.maeder <at> web.de>
To: Henrik Nilsson <Henrik.Nilsson <at> nottingham.ac.uk>,
        glasgow-haskell-users <at> haskell.org
Subject: Re: Proposal: ArgumentDo
Message-ID: <5780A31D.5080109 <at> web.de>
Content-Type: text/plain; charset=utf-8

The asymmetry that you mention is already apparent for (Haskell98) infix
expressions, i.e. when "composing" lambda- or if-expression:

 (if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but
parentheses around the first argument make a real difference (that the
type checker will not detect)!

Cheers Christian

Am 08.07.2016 um 14:00 schrieb Henrik Nilsson:
> Hi all,

[...]

> As a final point, the inherent asymmetry of the proposal (the
> last argument position is special as, for certain kinds of
> expressions, parentheses may be omitted there but not elsewhere)
> is also deeply unsettling.
>
> Best,
>
> /Henrik
>



------------------------------

Message: 4
Date: Sat, 9 Jul 2016 09:42:06 +0200
From: Bardur Arantsson <spam <at> scientician.net>
To: glasgow-haskell-users <at> haskell.org
Subject: Re: Proposal: ArgumentDo
Message-ID: <nlq9se$vem$1 <at> ger.gmane.org>
Content-Type: text/plain; charset=utf-8

On 07/09/2016 09:09 AM, C Maeder wrote:
> The asymmetry that you mention is already apparent for (Haskell98) infix
> expressions, i.e. when "composing" lambda- or if-expression:
>
>  (if c then f else g) . \ x -> h x
>
> Parentheses around the last argument of "." do not matter, but
> parentheses around the first argument make a real difference (that the
> type checker will not detect)!
>

What I'm reading here is essentially

  "Parser already does non-obvious thing"
      ===> "Adding more non-obvious things is fine!"

This is simply bad reasoning, and I'm not sure why a number of people
are saying it. Am I missing something?

Regards,



------------------------------

Message: 5
Date: Sat, 09 Jul 2016 10:46:14 +0100
From: Henrik Nilsson <Henrik.Nilsson <at> nottingham.ac.uk>
To: C Maeder <chr.maeder <at> web.de>,  Henrik Nilsson
        <Henrik.Nilsson <at> nottingham.ac.uk>, glasgow-haskell-users <at> haskell.org
Subject: Re: Proposal: ArgumentDo
Message-ID: <5780C7E6.6030606 <at> nottingham.ac.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi all,

On 07/09/2016 08:09 AM, C Maeder wrote:
> The asymmetry that you mention is already apparent for (Haskell98) infix
> expressions, i.e. when "composing" lambda- or if-expression:
>
>   (if c then f else g) . \ x -> h x
>
> Parentheses around the last argument of "." do not matter, but
> parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to
in this case "if" and "lambda" are resolved by letting
the constructs extend as far as possible to the right.

This the standard way of resolving that kind of ambiguity
across a very wide range of programming languages and parsing
tools (e.g. preferring shift over reduce in an LR parser).
(And also in principle how lexical ambiguities are typically
resolved, sometimes referred to as the "maximal munch rule".)

In contrast, the present proposal suggests treating
different argument positions in grammatically
different ways (different non-terminals). As far as I know,
that is unprecedented. And in any case, it manifestly
complicates the grammar (more non-terminals) and as
a consequence adds another grammatical hurdle to
learning the language.

I think we often tend to forget just how exotic
Haskell syntax can be to the uninitiated. Which is
the vast majority of the rest of the programmer world
as well as beginners. Only the other week I gave a
presentation to a group of highly skilled developers
at a tech-savvy London-based company. The emphasis of
the talk was not at all on Haskell as such, but small
Haskell fragments did feature here and there, which I
(naively) thought would be mostly self explanatory.
Well, let's just say I was wrong.

Now, we can't make Haskell syntax less exotic (not that I'd
advocate that: I think basic Haskell syntax for the most part
strikes a pretty good balance on a number of counts), but we can
certainly avoid making it even more complicated and exotic.
Which the present proposal would, in my opinion.

Best,

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
nhn <at> cs.nott.ac.uk




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.



------------------------------

Subject: Digest Footer

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


------------------------------

End of Glasgow-haskell-users Digest, Vol 155, Issue 9
*****************************************************

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Christiaan Baaij | 6 Jul 10:08 2016
Picon
Gravatar

Space-leak incurred by constraints

Hi,

The following reduced test-case:

 > {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, ConstraintKinds,
 >              FlexibleContexts, BangPatterns #-}
 > module ConstraintLeak where
 >
 > import GHC.TypeLits
 > import Data.Proxy
 >
 > type Constraint1 n
 >     = ( Constraint2 n
 >       , Constraint2 (2^n)
 >       )
 > type Constraint2 n
 >     = ( KnownNat n
 >       , ((n-1)+1) ~ n -- Comment this line to run in constant space
 >       )
 >
 > test :: Constraint1 x => Proxy x -> String
 > test !s | s == s = test s
 >
 > main :: IO ()
 > main = putStr (test (Proxy :: Proxy 3))

contains a space-leak when compiled without optimisations (i.e. -O0 or 
in GHCi). It's true that the code doesn't actually do anything (when 
compiled with -O you get "Exception <<loop>>"), but I'm using it to 
exemplify some code that runs for some time, and then prints something.

As you can see, 'test' is strict in its arguments, but it seems lazy in 
its constraints. When I look at the heap profile (-hy), I see it rapidly 
accumulating values of the following types:

- ~
- KnownNat
- (,)

The problem with these constraints, unlike a normal type-class 
constraints, is that I cannot 'seq' one of its members to force the 
dictionary and hence be strict in the constraints.

We stumbled upon this particular space-leak while trying to find a 
space-leak in our own code; we don't think it's the real culprit in our 
own code, but find it disturbing nonetheless.
GHCi is heavily used in our work-flow, meaning we often run in an -O0 
setting, so I would like to know if it is possible to plug this 
constraint-induced space-leak.

Regards,

Christiaan Baaij
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Akio Takano | 4 Jul 12:31 2016
Picon

Proposal: ArgumentDo

Hi glasgow-haskell-users,

I have written a wiki page about a proposed extension called
ArgumentDo. It's a small syntactic extension that allows "do"
expressions, lambdas and a few other kinds of expressions to be used
as function arguments, without parentheses.

https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo

Any feedback is appreciated. In particular, since the idea has
received mixed support (see the "Discussion" section on the wiki
page), I'd like to make sure that there is enough support for this
feature to justify an implementation in GHC.

Regards,
Takano Akio
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Simon's email classified as spam

Dear GHC devs/users

This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder.  Gershom thinks he’s fixed it (below).  Can I trespass on your patience once more?

Just let me know if this email ends up in your inbox or spam.  Can you cc John and Gershom (but perhaps not everyone else)?  Thanks

Simon

 

| From: Gershom B [mailto:gershomb <at> gmail.com]

| Sent: 18 June 2016 18:53

| To: Simon Peyton Jones <simonpj <at> microsoft.com>; John Wiegley

| <johnw <at> newartisans.com>

| Cc: Michael Burge <michaelburge <at> pobox.com>

| Subject: Re: FW: CMM-to-SAM: Register allocation weirdness

|

| Simon — I just found two possible sources of the problem (first: the top

| level config didn’t take hold due to other errors when updating — fixed that,

| and second, it might be possible the top level config isn’t retroactively

| applied to all lists — so i added the config to the relevant lists directly).

|

| I think if you try one more time it might work (fingers crossed).

 

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Simon Peyton Jones | 18 Jun 15:01 2016
Picon
Gravatar

RE: CMM-to-ASM: Register allocation wierdness

Takenobu, and others

Thanks.  Several people have mentioned that email from me is ending up in spam.

It turns out to be a fault in the Haskell.org mailman setup, which was mis-forwarding my email.

Apparently it is fixed now.  If THIS message ends up in spam with a complaint like that below, could you let me know?

Thanks

Simon

                                                                                                                                                                                                                    

From: Takenobu Tani [mailto:takenobu.hs <at> gmail.com]
Sent: 18 June 2016 08:18
To: Simon Peyton Jones <simonpj <at> microsoft.com>
Subject: Re: CMM-to-ASM: Register allocation wierdness

 

Hi Simon,

 

I report to you about your mails.

 

Maybe, your mails don't reach to Gmail users.

I don't know why, but your mails have been distributed to "Spam" folder in Gmail.

 

Gmail displays following message:

  "Why is this message in Spam? It has a from address in microsoft.com but has failed microsoft.com's required tests for authentication."

 

 

For reference, I attach the screen of my Gmail of spam folder.

Recent your mails have been detected as spam.

Please check your mail settings.

 

Regards,

Takenobu

 

2016-06-16 21:10 GMT+09:00 Simon Peyton Jones <simonpj <at> microsoft.com>:

| All-in-all, the graph coloring allocator is in great need of some love;
| Harendra, perhaps you'd like to have a try at dusting it off and perhaps
| look into why it regresses in compiler performance? It would be great if
| we could use it by default.

I second this.   Volunteers are sorely needed.

Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

 

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Harendra Kumar | 12 Jun 20:38 2016
Picon

CMM-to-ASM: Register allocation wierdness

Hi,

I am implementing unicode normalization in Haskell. I challenged myself to match the performance with the best C/C++ implementation, the best being the ICU library. I am almost there, beating it in one of the benchmarks and within 30% for others. I am out of all application level tricks that I could think of and now need help from the compiler.

I started with a bare minimum loop and adding functionality incrementally watching where the performance trips. At one point I saw that adding just one 'if' condition reduced the performance by half. I looked at what's going on at the assembly level. Here is a github gist of the assembly instructions executed in the fast path of the loop, corresponding cmm snippets and also the full cmm corresponding to the loop:


I have annotated the assembly code with labels matching the corresponding CMM.

With the addition of another "if" condition the loop which was pretty simple till now suddenly got bloated with a lot of register reassignments. Here is a snippet of the register movements added:

# _n4se:
# swap r14 <-> r11
=> 0x408d6b: mov    %r11,0x98(%rsp)
=> 0x408d73: mov    %r14,%r11
=> 0x408d76: mov    0x98(%rsp),%r14

# reassignments
# rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx
=> 0x408d7e: mov    %rbx,0x90(%rsp)
=> 0x408d86: mov    %rcx,%rbx
=> 0x408d89: mov    %rdx,%rcx
=> 0x408d8c: mov    %rsi,%rdx
=> 0x408d8f: mov    %rdi,%rsi
=> 0x408d92: mov    %r8,%rdi
=> 0x408d95: mov    %r9,%r8
=> 0x408d98: mov    %r10,%r9
=> 0x408d9b: mov    0x90(%rsp),%r10
.
.
.
loop logic here which uses only %rax, %r10 and %r9 . 
.
.
.
# _n4s8:
# shuffle back to original assignments
=> 0x4090dc: mov    %r14,%r11
=> 0x4090df: mov    %r9,%r10
=> 0x4090e2: mov    %r8,%r9
=> 0x4090e5: mov    %rdi,%r8
=> 0x4090e8: mov    %rsi,%rdi
=> 0x4090eb: mov    %rdx,%rsi
=> 0x4090ee: mov    %rcx,%rdx
=> 0x4090f1: mov    %rbx,%rcx
=> 0x4090f4: mov    %rax,%rbx
=> 0x4090f7: mov    0x88(%rsp),%rax

=> 0x4090ff: jmpq   0x408d2a


The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. 

Maybe this is because these are reusable blocks and the movement is necessary when used in some other path?

Can this be avoided? Or at least avoided in a certain fast path somehow by hinting the compiler? Any pointers to the GHC code will be appreciated. I am not yet much familiar with the GHC code but can dig deeper pretty quickly. But before that I hope someone knowledgeable in this area can shed some light on this at a conceptual level or if at all it can be improved. I can provide more details and experiment more if needed.

Thanks,
Harendra
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Michael Burge | 11 Jun 21:12 2016
Picon

Allow extra commas in module declarations or lists?

Some languages like Perl allow you to include additional commas in your lists, so that you can freely reorder them without worrying about adding or removing commas from the last or first item:

my <at> array = (
  1,
  2,
  3,
);

Perl even allows multiple redundant commas everywhere after the first element, which is less useful but has come up on occasion:
my <at> array = (1,,,2,,,,,,,,,3,,,,,);

I propose allowing an optional single extra comma at the end in module declarations, record declarations, record constructors, and list constructors:

module Example (
  module Example,
  SomeConstructor(..),
  ) where

data SomeConstructor = SomeConstructor {
  foo :: Int,
  bar :: Int,
}

baz :: SomeConstructor -> SomeConstructor
baz x = x {
  foo = 5,
  bar = 10,
}

qux :: [ Int ]
qux = [
  1,
  2,
  3,
]

What do you think?
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Edward Z. Yang | 9 Jun 09:17 2016
Picon
Gravatar

Call for talks: Haskell Implementors Workshop 2016, Sep 24 (FIXED), Nara

(...and now with the right date in the subject line!)

                        Call for Contributions
               ACM SIGPLAN Haskell Implementors' Workshop

    http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
                Nara, Japan, 24 September, 2016

                    Co-located with ICFP 2016
               http://www.icfpconference.org/icfp2016/

Important dates
---------------
Proposal Deadline:  Monday, 8 August, 2016
Notification:       Monday, 22 August, 2016
Workshop:           Saturday, 24 September, 2016

The 8th Haskell Implementors' Workshop is to be held alongside ICFP
2016 this year in Nara. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Scope and target audience
-------------------------

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2016. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-----

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
  https://icfp-hiw16.hotcrp.com/

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
----------

  * Joachim Breitner        (Karlsruhe Institut für Technologie)
  * Duncan Coutts           (Well Typed)
  * Michael Snoyman         (FP Complete)
  * Luite Stegeman          (ghcjs)
  * Niki Vazou              (UCSD)
  * Stephanie Weirich       (University of Pennsylvania) 
  * Edward Z. Yang - chair  (Stanford University)
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Edward Z. Yang | 9 Jun 09:14 2016
Picon
Gravatar

Call for talks: Haskell Implementors Workshop 2016, Aug 24, Nara

                        Call for Contributions
               ACM SIGPLAN Haskell Implementors' Workshop

    http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
                Nara, Japan, 24 September, 2016

                    Co-located with ICFP 2016
               http://www.icfpconference.org/icfp2016/

Important dates
---------------
Proposal Deadline:  Monday, 8 August, 2016
Notification:       Monday, 22 August, 2016
Workshop:           Saturday, 24 September, 2016

The 8th Haskell Implementors' Workshop is to be held alongside ICFP
2016 this year in Nara. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Scope and target audience
-------------------------

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2016. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-----

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
  https://icfp-hiw16.hotcrp.com/

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
----------

  * Joachim Breitner        (Karlsruhe Institut für Technologie)
  * Duncan Coutts           (Well Typed)
  * Michael Snoyman         (FP Complete)
  * Luite Stegeman          (ghcjs)
  * Niki Vazou              (UCSD)
  * Stephanie Weirich       (University of Pennsylvania) 
  * Edward Z. Yang - chair  (Stanford University)
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Adam Foltzer | 3 Jun 23:33 2016
Picon
Gravatar

Feedback on -Wredundant-constraints

With 8.0.1 freshly arrived, I'm taking on the task of updating a number of our larger projects here at Galois. I made a couple of these comments briefly on a relevant Trac ticket[1], but I wanted to open this discussion to a wider audience.

We tend to use -Wall (and -Werror, in CI environments), and so I've had to make decisions about how to handle the new -Wredundant-constraints warnings. So far, I've come to think of it as two different warnings that happen to be combined:

Warning 1: a warning for constraints made redundant by superclass relationships, and
Warning 2: a warning for unused constraints

Overall I'm a fan of Warning 1. It seems very much in the spirit of other warnings such as unused imports. The only stumbling block is how it affects the 3-release compatibility plan with respect to, e.g., the AMP. Most of our code targets a 2-release window, though, so in every such case it has been fine for us to simply remove the offending constraint.

Warning 2 on the other hand is far more dubious to me. In the best case, it finds constraints that through oversight or non-local changes are truly no longer necessary in the codebase. This is nice, but the much more common case in our code is that we've made a deliberate decision to include that constraint as part of our API design.

The most painful example of this I've hit so far is in an API of related functions, where we've put the same constraint on each function even when the implementation of that particular function might not need that constraint. This is good for consistency and forward-looking compatibility (what if we need that constraint in the next version?). The warning's advice in this case makes the API harder to understand, and less abstract (the client shouldn't care or know that f needs Functor, but g doesn't, if both will always be used in a Functor context).

On another level, Warning 2 is a warning that we could have given a more general type to a definition. We quite rightly don't do this for the non-constraint parts of the type signatures, so why are we doing it for the constraints?

I'm happy that Warning 1 is now around, but Warning 2 feels much more like an opinionated lint check, and I really wish it wasn't part of -Wall.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Gmane