[Haskell] Final CFP: Workshop on Type-driven Development (TyDe '17)

[Brent Yorgey]

There's still time to submit an extended abstract!  See below.



 CALL FOR PAPERS

 2nd Workshop on Type-Driven Development (TyDe '17)
  3 September 2017, Oxford, UK

  http://tydeworkshop.org/2017


# Goals of the workshop

The workshop on Type-Driven Development aims to show how static type
information may be used effectively in the development of computer
programs. Co-located with ICFP, this workshop brings together leading
researchers and practitioners who are using or exploring types as a
means of program development.

We welcome all contributions, both theoretical and practical, on a
range of topics including:

-   dependently typed programming;
-   generic programming;
-   design and implementation of programming languages, exploiting types
 in novel ways;
-   exploiting typed data, data dependent data, or type providers;
-   static and dynamic analyses of typed programs;
-   tools, IDEs, or testing tools exploiting type information;
-   pearls, being elegant, instructive examples of types used in the
 derivation, calculation, or construction of programs.

# Invited speaker

Andrew Kennedy, Facebook, UK

# Program Committee

-   Nada Amin, EPFL, Switzerland
-   Ana Bove, Chalmers University of Technology, Sweden
-   Patricia Johann, Appalachian State University, US
-   Yukiyoshi Kameyama, University of Tsukuba, Japan
-   Sam Lindley, The University of Edinburgh, UK (co-chair)
-   Limin Jia, CMU, US
-   Assia Mahboubi, INRIA Saclay, France
-   Liam O’Connor, University of New South Wales, Australia
-   Nicolas Oury, Jane Street, UK
-   Jennifer Paykin, University of Pennsylvania, US
-   Paula Severi, University of Leicester, UK
-   Tarmo Uustalu, Tallinn University of Technology, Estonia
-   Jeremy Yallop, University of Cambridge, UK
-   Brent Yorgey, Hendrix College, US (co-chair)

# Proceedings and Copyright

We plan to have formal proceedings, published by the ACM. Accepted
papers will be included in the ACM Digital Library. Authors must grant
ACM publication rights upon acceptance, but may retain copyright if they
wish. Authors are encouraged to publish auxiliary material with their
paper (source code, test data, and so forth). The proceedings will be
freely available for download from the ACM Digital Library from one week
before the start of the conference until two weeks after the conference.

# Submission details

Submissions should fall into one of two categories:

-   Regular research papers (12 pages)
-   Extended abstracts (2 pages)

The bibliography will not be counted against the page limits for
either category.

Regular research papers are expected to present novel and interesting
research results, and will be included in the formal
proceedings. Extended abstracts should report work in progress that
the authors would like to present at the workshop. Extended abstracts
will be distributed to workshop attendees but will not be published in
the formal proceedings.

We welcome submissions from PC members (with the exception of the two
co-chairs), but these submissions will be held to a higher standard.

Submission is handled through HotCRP:

   https://icfp-tyde17.hotcrp.com/

All submissions should be in portable document format (PDF) and
formatted using the ACM SIGPLAN style guidelines:

   http://www.sigplan.org/Resources/Author/

*Note* that the ACM SIGPLAN style guidelines have changed from
previous years! In particular, submissions should use the new
‘acmart’ format and the two-column ‘sigplan’ subformat (not to be
confused with the one-column ‘acmlarge’ subformat!).

Extended abstracts must be submitted with the label 'Extended
abstract' clearly in the title.

# Important Dates

-   Regular paper deadline: Wednesday, 24th May, 2017
-   Extended abstract deadline: Wednesday, 7th June, 2017
-   Author notification: Wednesday, 28th June, 2017
-   Deadline for camera ready version: Saturday, 15th July, 2017
-   Workshop: Sunday, 3rd September, 2017

# Travel Support

Student attendees with accepted papers can apply for a SIGPLAN PAC grant
to help cover travel expenses. PAC also offers other support, such as
for child-care expenses during the meeting or for travel costs for
companions of SIGPLAN members with physical disabilities, as well as for
travel from locations outside of North America and Europe. For details
on the PAC program, see its web page:

   http://www.sigplan.org/PAC/
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Profiling plugins

[M Farkas-Dyck]

How is this done? I am working on ConCat
[https://github.com/conal/concat] and we need a profile of the plugin
itself. I tried "stack test --profile" but that does a profile of the
test program, not the plugin. Can i do this and not rebuild GHC?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: 8.2.1-rc2 upgrade report

[Simon Peyton Jones via Glasgow-haskell-users]

Thanks for the report.

Going from 67G to 56G allocation is a very worthwhile improvement in runtime!  
Hurrah.

However, trebling compile time is very bad.  It is (I think) far from typical: 
generally 8.2 is faster at compiling than 8.0 so you must be hitting something 
weird.  Anything you can do to make a reproducible case would be helpful.  
-dshow-passes shows the size of each intermediate form, which at least 
sometimes shows where the big changes are.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] 
On Behalf Of Alberto Valverde
Sent: 06 June 2017 12:39
To: GHC users 
Subject: 8.2.1-rc2 upgrade report

Hi,

I've finally managed to upgrade all the dependencies of the proprietary app I 
mentioned some days ago in this list and there are good and bad differences 
I've noticed between 8.0.2 that I'd like to share.

The bad
---

* An optimized cold build (-O2)  is about 3 times slower (~53s vs. ~2m55s) and 
consumes more memory (~2Gb vs. ~7Gb) at it's peak.

The good
-

* An un-optimized cold build (-O0) takes about the same time (~21s, phew! :) 
It's maybe even slightly faster with 8.2 (too few and badly taken measurements 
to really know, though)
* The optimized executable is slightly faster and allocates less memory. For 
this app it makes up for the performance regression of the optimized build 
(which is almost always done by CI), IMHO.

I did only a couple of runs and only wrote down [1] the last run results (which 
were similar to the previous results) so take these observations with a grain 
of salt (except maybe the optimized build slowdown, which doesn't have much 
margin for variance to be skewing the results). I also measured the peak memory 
usage by observing "top".

In case gives a clue: The app is a multi-threaded 2D spread simulator which 
deals with many mmapped Storable mutable vectors and has been pretty optimized 
for countless hours (I mean by this that it has (too) many INLINE pragmas. 
Mostly on polymorphic functions to aid in their specialization). I think some 
of this information can be deduced from the results I'm linking at the footer. 
I believe the INLINEs are playing a big part of the slowdown since the slowest 
modules to compile are the "Main" ones which put everything together, along 
with the typical lens-th-heavy "Types" ones.

I'd like to help by producing a reproducible and isolated benchmark or a better 
analysis or ... so someone more knowledgeable than me on GHC internals can 
someday hopefully attack the regression. Any pointers on what would help and 
where can I learn to do it?

Thanks!


[1] 
https://gist.github.com/albertov/46fbb13d940f67a569f9a25c1cb8154c
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

8.2.1-rc2 upgrade report

[Alberto Valverde]

Hi,

I've finally managed to upgrade all the dependencies of the proprietary app
I mentioned some days ago in this list and there are good and bad
differences I've noticed between 8.0.2 that I'd like to share.

The bad
---

* An optimized cold build (-O2)  is about 3 times slower (~53s vs. ~2m55s)
and consumes more memory (~2Gb vs. ~7Gb) at it's peak.

The good
-

* An un-optimized cold build (-O0) takes about the same time (~21s, phew!
:) It's maybe even slightly faster with 8.2 (too few and badly taken
measurements to really know, though)
* The optimized executable is slightly faster and allocates less memory.
For this app it makes up for the performance regression of the optimized
build (which is almost always done by CI), IMHO.

I did only a couple of runs and only wrote down [1] the last run results
(which were similar to the previous results) so take these observations
with a grain of salt (except maybe the optimized build slowdown, which
doesn't have much margin for variance to be skewing the results). I also
measured the peak memory usage by observing "top".

In case gives a clue: The app is a multi-threaded 2D spread simulator which
deals with many mmapped Storable mutable vectors and has been pretty
optimized for countless hours (I mean by this that it has (too) many INLINE
pragmas. Mostly on polymorphic functions to aid in their specialization). I
think some of this information can be deduced from the results I'm linking
at the footer. I believe the INLINEs are playing a big part of the slowdown
since the slowest modules to compile are the "Main" ones which put
everything together, along with the typical lens-th-heavy "Types" ones.

I'd like to help by producing a reproducible and isolated benchmark or a
better analysis or ... so someone more knowledgeable than me on GHC
internals can someday hopefully attack the regression. Any pointers on what
would help and where can I learn to do it?

Thanks!


[1] https://gist.github.com/albertov/46fbb13d940f67a569f9a25c1cb8154c
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[Haskell] Lectureship/Senior Lectureship Positions at St Andrews

[Kevin Hammond]

[Please forward to anyone who might be interested!  Thanks!  Kevin]

The School of Computer Science is looking to recruit new academics as part of a 
large on-going expansion of our academic staff. We wish to appoint two new 
Lecturers/Senior Lecturers (depending on experience) to join our vibrant 
teaching and research community that is ranked amongst the top venues for 
Computer Science education and research worldwide.

You will be a scholar with a growing international research reputation in 
Computer Science and a commitment to delivering high quality teaching within 
the broad field of Computer Science and its applications. The successful 
candidate will be expected to have a range of interests, to be active in 
research publication that strengthens or complements those in the School and to 
be capable of teaching the subject to undergraduate and taught postgraduate 
students who come to us with a wide range of backgrounds.  

Candidates should hold a PhD in a cognate discipline. Excellent teaching skills 
and an interest in promoting knowledge exchange are essential.  You should also 
have some familiarity with grant seeking processes in relation to research 
councils and other sources.  

Informal enquiries can be directed to Professor Steve Linton 
(hos...@st-andrews.ac.uk) or Dr Dharini Balasubramaniam 
(dot...@st-andrews.ac.uk). 

Applications are particularly welcome from women, who are under-represented in 
Science posts at the University.  You can find out more about Equality & 
Diversity at https://www.st-andrews.ac.uk/hr/edi/. 

The University of St Andrews is committed to promoting equality of opportunity 
for all, which is further demonstrated through its working on the Gender and 
Race Equality Charters and being awarded the Athena SWAN award for women in 
science, HR Excellence in Research Award and the LGBT Charter;  
http://www.st-andrews.ac.uk/hr/edi/diversityawards/.  The School endorses the 
Athena SWAN charter and is actively working towards recognition.

Please quote ref:  AC2116SB 

Closing Date:  23 June 2017

Further Particulars: AC2116SB FPs.doc

School of Computer Science
Salary: £39,324 - £48,327 per annum, Senior Lecturer £49,772 - £55,998 per annum
Start: As soon as possible

https://www.vacancies.st-andrews.ac.uk/ViewVacancyV2.aspx?enc=mEgrBL4XQK0+ld8aNkwYmLYAYEGVHElLWsnTJgL+CarIHBCM/EiQaeKOsYHKP51KpI3DcpxT/zQcAl/8iq/B+IMGPJwugR63L68sBJUS3+i3hCU7JR/EJv31DirWmhwtDXIz2HSywsmfeey5lSxnIg==



Best Wishes,
Kevin



Kevin Hammond, Professor of Computer Science, University of St Andrews

T: +44-1334 463241   F: +44-1334-463278W: http://www.cs.st-andrews.ac.uk/~kh

In accordance with University policy on electronic mail, this email reflects 
the opinions of the individual concerned, may contain confidential or copyright 
information that should not be copied or distributed without permission, may be 
of a private or personal nature unless explicitly indicated otherwise, and 
should not under any circumstances be taken as an official statement of 
University policy or procedure (see http://www.st-and.ac.uk).

The University of St Andrews is a charity registered in Scotland : No SC013532

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