Re: [Haskell] International Intelligence, Sustainability, and Innovation in Healthcare (ISIH 2024), Roanne, France, October 30-31, 2024

[Ivan Perez]

All,

This person has sent these CFPs, which are unrelated to Haskell, to this
mailing list multiple times. They've been asked to stop before.

Can someone please remove oumaima.boulkho...@univ-st-etienne.fr from the
mailing list?

Thanks,

Ivan

On Tue, 2 Jul 2024 at 01:24, Oumaima Boulkhoukh <
oumaima.boulkho...@univ-st-etienne.fr> wrote:

> *Call for papers*
> ** *
> *International Intelligence, Sustainability, and Innovation in Healthcare
> (ISIH 2024) *
> *Roanne, France, October 30-31, 2024*
> *https://confscience.com/isih/ *
>
> *Call for papers*
>
> We would like to remind you that the final submission date is extended to 10
> July 2024
>
> Apologies for Cross-posting
>
> *
>
> International Intelligence, Sustainability, and Innovation in Healthcare
> (ISIH 2024)
>
> Roanne, France, October 30-31, 2024
>
> https://confscience.com/isih/
>
> All papers accepted in ISIH 2024 will be submitted for inclusion into IEEE
> Xplore, IEEE Computer Society Digital Library, Scopus,
>
> EI’s Engineering Information Index, Compendex, ISI Thomson’s Scientific,
> ISTP/ISI Proceedings, etc.
>
> ***
>
> *IMPORTANT DATES:*
>
> - Paper Submission: June 10, 2024 10 July 2024 (extended)
>
> - Acceptance Notification: September 1, 2024
>
> - Final Manuscript Due: October 1, 2024
>
> ***
>
> The ISIH 2024 conference will be held in Conjunction with:
>
> The International Conference on Artificial Intelligence Revolutions (AIR
> 2024)
>
> The International Conference on Borderless Artificial Intelligence and
> Quantum Computing (BAIQC 2024)
>
> ***
>
> *TOPICS:*
>
> Authors are invited to submit their original papers to address the topics
> of the conference, including but not limited to:
>
> Track 1: Fundamental and Theories
>
> - AI methods for medical device testing
>
> - Predicting and monitoring infectious disease
>
> - Machine learning for healthcare
>
> - Medical data and image analysis
>
> - Data quality assessment and improvement
>
> - Electronic medical records analysis
>
> - Deep Learning for healthcare
>
> - Screening and diagnosis
>
> - Explainable AI for healthcare
>
> - Multiagent systems for healthcare
>
> - AI-based simulations
>
> - Bio-inspired solutions for healthcare
>
> - Smart healthcare
>
> - Medical edge computing
>
>
>
> *Track 2: Innovation and Connectivity*
>
> - Remote healthcare management
>
> - Emergent healthcare infrastructure
>
> - Industry Revolution 4.0 for healthcare
>
> - Emergent communication technologies
>
> - IoT-based disease surveillance
>
> - Prevention and detection systems
>
> - Rehabilitation technologies
>
> - Wearable health informatics
>
> - 5G for healthcare
>
> - Healthcare supply chain and logistics
>
> - Telemedicine and Mobile systems
>
> - Drones and robots for healthcare
>
> - Internet of Medical Things
>
> - Medical embedded systems
>
> - Network and services virtualization
>
> - Nanoscale healthcare
>
>
>
> *Track 3: Human Computer Interaction*
>
> - Human-Machine Interaction
>
> - Methods for inputting data for e-health
>
> - Models for human-device interaction
>
> - Model-based design and configuration tools
>
> - New experimental validation methods
>
> - Standardization, certification, and labeling
>
> - Communication and interoperability
>
> - Regulation compliant services (e.g., HIPAA)
>
> - Socio-economic issues
>
> - Feedback integration
>
> - Accessibility
>
> - Personalization and patient experience
>
> - Augmented/Virtual Reality solutions
>
> - Voice recognition
>
> - Enhanced Living Environment (ELE)
>
>
>
> *Track 4: Sustainable Healthcare*
>
> - Green healthcare facilities
>
> - Renewable energy integration in healthcare
>
> - Waste reduction and recycling
>
> - Sustainable supply chain management
>
> - Eco-friendly medical equipment and devices
>
> - Sustainable health practices
>
> - Educational initiatives
>
> - AI approaches for sustainable healthcare
>
> - Innovations for sustainable healthcare
>
> - AI approaches for global health equity
>
> - Quality of Service
>
> - Quality of Experience
>
>
>
> *Track 5: Applications and Trends*
>
> - Network and services virtualization
>
> - Software-Defined Networking (SDN)
>
> - Bioinformatics
>
> - Clinical Decision Support Systems
>
> - Interoperability for personal Health systems
>
> - Medical imaging
>
> - Evidence-based medicine
>
> - Blockchain applications
>
> - Smart health and big data
>
> - Health Information exchange solutions
>
> - Medical and patient scheduling software
>
> - Medication administration systems
>
> - Healthcare information systems
>
> - Integration and interoperability
>
> - Medical records
>
> - Clinical reporting systems
>
> - eHealth servic

Re: [Haskell] 31st Netherlands Functional Programming Day (FP Dag): Call for Participation

[Jesper Cockx via Haskell]

===
  FP Dag 2024

   31th Netherlands Functional Programming Day

Friday, 05 January, 2024

FINAL CALL FOR PARTICIPATION

 http://www.tudelft.nl/fpday-2024
===


Soft registration deadline: 22 December (upcoming Friday)


We still have a couple of open slots for speakers, please consider proposing a 
talk by sending an email to fpnl-...@tudelft.nl


## General description


The Netherlands Functional Programming Day (or FP Dag) is an annual gathering 
of researchers, students, and practitioners sharing a common interest in 
functional programming. The day features talks that cover the latest advances 
in research, teaching and applications in the area of functional programming 
and (implementation of) functional languages.

Coffee and lunch breaks provide ample opportunity for networking with your 
colleagues and meeting new people. Experts and newcomers to the field are 
equally welcome.

Colleagues from neighboring countries are more than welcome to attend; the 
language of the FP Day is English.

## Registration

Participation is free of charge, but registration is required:

https://www.aanmelder.nl/fp-nl2024/subscribe

There is a soft registration deadline of **Friday 22 December 2023**.

## Schedule

You will find a preliminary schedule on the website:

http://www.tudelft.nl/fpday-2024

Details will be added as speakers become known.

## Location

The FP Dag will take place on January 5th 2024, at the Technical University of 
Delft. Address Aula Conference Centre:

Mekelweg 5, 2628 CC Delft, The Netherlands

Nearest busstop: Schoemakerstraat (bus 55 from Train Station Delft)
Nearest train station: Delft Trainstation
To plan your travel, visit https://9292.nl/ or https://ns.nl.

## Organisers

- Jesper Cockx (Overall & Content)
- Shelly Dawn Stok (Website & Logistics)
- Bohdan Liesnikov, Lucas Escot, and Jaro Reinders (Local Organization & 
Support)


From: Jesper Cockx
Sent: Friday, November 3, 2023 1:20:44 PM
To: types-annou...@lists.seas.upenn.edu; fp...@lists.science.uu.nl; 
ipal...@listserver.tue.nl; haskell@haskell.org; a...@lists.chalmers.se; 
coq-c...@inria.fr
Subject: 31st Netherlands Functional Programming Day (FP Dag): Call for 
Participation

===
  FP Dag 2024

   31th Netherlands Functional Programming Day

Friday, 05 January, 2024

 CALL FOR PARTICIPATION

 http://www.tudelft.nl/fpday-2024
===

The Netherlands Functional Programming Day (or FP Dag) is an annual gathering 
of researchers, students, and practitioners sharing a common interest in 
functional programming. The day features talks that cover the latest advances 
in research, teaching and applications in the area of functional programming 
and (implementation of) functional languages.

Coffee and lunch breaks provide ample opportunity for networking with your 
colleagues and meeting new people. Experts and newcomers to the field are 
equally welcome.

Colleagues from neighboring countries are more than welcome to attend; the 
language of the FP Day is English.

## Registration

Participation is free of charge, but registration is required:

https://www.aanmelder.nl/fp-nl2024/subscribe

There is a soft registration deadline of **Friday 22 December 2023**.

## Schedule

You will find a preliminary schedule on the website:

http://www.tudelft.nl/fpday-2024

Details will be added as speakers become known.

## Location

The FP Dag will take place on January 5th 2024, at the Technical University of 
Delft. Address Aula Conference Centre:

Mekelweg 5, 2628 CC Delft, The Netherlands

Nearest busstop: Schoemakerstraat (bus 55 from Train Station Delft)
Nearest train station: Delft Trainstation
To plan your travel, visit https://9292.nl/ or https://ns.nl.

## Organisers

- Jesper Cockx (Overall & Content)
- Shelly Dawn Stok (Website & Logistics)
- Bohdan Liesnikov, Lucas Escot, and Jaro Reinders (Local Organization & 
Support)
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] ANT 2024 CFP (December 4, 2023 (extended)): The 15th International Conference on Ambient Systems, Networks and Technologies (ANT) , Hasselt, Belgium, April 23-25, 2024

[Ali BENZERBADJ]

Dear Ivan,
I would like to ask you to introduce yourself first, please. Are you the
admin of the mailing list? I assume that Haskell is the one who assesses
the relevance of announcements. If the topic doesn't interest you, just
ignore it, and that's it.

Yours sincerely.

On Sun, 26 Nov 2023 at 23:07, Ivan Perez 
wrote:

> Ali,
>
> None of the CfPs you've sent to this mailing list over the past year
> appear even remotely related to Haskell. I doubt people on this list will
> find them relevant or interesting.
>
> *Could you please stop sending CfPs to haskell and haskell-cafe?*
>
> Thanks
>
> Ivan
>
> On Sun, 26 Nov 2023 at 11:19, Ali BENZERBADJ <
> ali.benzerb...@univ-temouchent.edu.dz> wrote:
>
>>
>> ***
>> The 15th International Conference on Ambient Systems, Networks and
>> Technologies (ANT)
>>
>> Hasselt, Belgium
>> April 23-25, 2024
>>
>>
>> ***
>> Conference Website:  http://cs-conferences.acadiau.ca/ant-24/
>> Workshops: http://cs-conferences.acadiau.ca/ant-24/#workshop
>>
>> Important Dates
>> - Workshops Proposals Due: October 20, 2023
>> - Paper Submission Due: December 4, 2023 (extended)
>> - Acceptance Notification: January 15, 2024
>> - Camera-Ready Submission: February 9, 2024
>>
>> ANT 2024 accepted papers will be published by Elsevier Science in the
>> open-access Procedia Computer Science series on-line. Procedia Computer
>> Science is hosted by Elsevier on www.Elsevier.com and on Elsevier
>> content platform ScienceDirect (www.sciencedirect.com), and will be
>> freely available worldwide. All papers in Procedia will be indexed by
>> Scopus (www.scopus.com) and by Thomson Reuters' Conference Proceeding
>> Citation Index (
>> http://thomsonreuters.com/conference-proceedings-citation-index/). All
>> papers in Procedia will also be indexed by Scopus (www.scopus.com) and
>> Engineering Village (Ei) (www.engineeringvillage.com). This includes EI
>> Compendex (www.ei.org/compendex). Moreover, all accepted papers will be
>> indexed in DBLP (http://dblp.uni-trier.de/). The papers will contain
>> linked references, XML versions and citable DOI numbers. You will be able
>> to provide a hyperlink to all delegates and direct your conference website
>> visitors to your proceedings. Selected papers will be invited for
>> publication, in the special issues of:
>>
>>
>> - International Journal of Ambient Intelligence and Humanized Computing
>> (IF: 4.594), by Springer (
>> http://www.springer.com/engineering/journal/12652)
>> - International Journal Personal and Ubiquitous Computing (IF:3.006),
>> Springer (https://www.springer.com/journal/779)
>> - International Journal on Transportation Research Part A: Policy and
>> Practice (IF: 3.992), by Elsevier (
>> https://www.journals.elsevier.com/transportation-research-part-a-policy-and-practice/
>> )
>>
>>
>> ANT 2024 will be held in Hasselt, Belgium. ANT 2024 is co-organized &
>> co-hosted by the Hasselt University, Belgium. Since 1973 Hasselt University
>> is located on the Campus Diepenbeek, which occupies an attractive 150 acre
>> site in the middle of Limburg's green belt. It is 2 kms west of the town
>> centre of Diepenbeek, a residential town of 17.717 inhabitants, and 4 kms
>> east of Hasselt which has a population of about 69.529 and is the
>> administrative and commercial centre of the province. Brussels is 90 kms
>> away (to the South-West), Antwerp lies 90 kms to the West, Liège (in the
>> French-speaking part of Belgium) 45 kms to the South, Maastricht (in the
>> Netherlands) 25 kms to the East, Aachen (in Germany) 60 kms to the
>> South-East.
>>
>> ANT 2024 will be held in conjunction with the 7th International
>> Conference on Emerging Data and Industry (EDI40).
>>
>> Conference Tracks
>>- Agent Systems, Intelligent Computing and Applications
>>- Big Data and Analytics
>>- Cloud Computing
>>- Context-awareness and Multimodal Interfaces
>>- Emerging Networking, Tracking and Sensing Technologies
>>- Human Computer Interaction
>>- Internet of Things
>>- Mobile Networks, Protocols and Applications
>>- Modelling and Simulation in Transportation Sciences
>>- Multimedia and Social Computing
>>- Service Oriented Computing for Systems & Applications
>>- Smart, Sustainable Cities and Climate Change Management
>>- Smart Environments and Applications
>>- Systems Security and Privacy
>>- Systems Software Engineering
>>- Vehicular Networks and Applications
>>- General Track
>>
>>
>> General Chairs
>>
>>Atta Badii, University of Reading, UK
>>Albert Zomaya, The University of Sydney, Australia
>>
>> Program Chairs
>>
>>Hossam Hassanein, Queen's University, Canada
>>Ansar-Ul-Haque Yasar, Hasselt University, Belgium
>>
>> Workshops Chair
>>
>>Stephane Galland, UTBM, France
>>
>> Vice Chairs
>>
>>   Muhammad Adnan, Hasselt Universi

Re: [Haskell] ANT 2024 CFP (December 4, 2023 (extended)): The 15th International Conference on Ambient Systems, Networks and Technologies (ANT) , Hasselt, Belgium, April 23-25, 2024

[Ivan Perez]

Ali,

None of the CfPs you've sent to this mailing list over the past year appear
even remotely related to Haskell. I doubt people on this list will find
them relevant or interesting.

*Could you please stop sending CfPs to haskell and haskell-cafe?*

Thanks

Ivan

On Sun, 26 Nov 2023 at 11:19, Ali BENZERBADJ <
ali.benzerb...@univ-temouchent.edu.dz> wrote:

> ***
> The 15th International Conference on Ambient Systems, Networks and
> Technologies (ANT)
>
> Hasselt, Belgium
> April 23-25, 2024
>
> ***
> Conference Website:  http://cs-conferences.acadiau.ca/ant-24/
> Workshops: http://cs-conferences.acadiau.ca/ant-24/#workshop
>
> Important Dates
> - Workshops Proposals Due: October 20, 2023
> - Paper Submission Due: December 4, 2023 (extended)
> - Acceptance Notification: January 15, 2024
> - Camera-Ready Submission: February 9, 2024
>
> ANT 2024 accepted papers will be published by Elsevier Science in the
> open-access Procedia Computer Science series on-line. Procedia Computer
> Science is hosted by Elsevier on www.Elsevier.com and on Elsevier content
> platform ScienceDirect (www.sciencedirect.com), and will be freely
> available worldwide. All papers in Procedia will be indexed by Scopus (
> www.scopus.com) and by Thomson Reuters' Conference Proceeding Citation
> Index (http://thomsonreuters.com/conference-proceedings-citation-index/).
> All papers in Procedia will also be indexed by Scopus (www.scopus.com)
> and Engineering Village (Ei) (www.engineeringvillage.com). This includes
> EI Compendex (www.ei.org/compendex). Moreover, all accepted papers will
> be indexed in DBLP (http://dblp.uni-trier.de/). The papers will contain
> linked references, XML versions and citable DOI numbers. You will be able
> to provide a hyperlink to all delegates and direct your conference website
> visitors to your proceedings. Selected papers will be invited for
> publication, in the special issues of:
>
>
> - International Journal of Ambient Intelligence and Humanized Computing
> (IF: 4.594), by Springer (
> http://www.springer.com/engineering/journal/12652)
> - International Journal Personal and Ubiquitous Computing (IF:3.006),
> Springer (https://www.springer.com/journal/779)
> - International Journal on Transportation Research Part A: Policy and
> Practice (IF: 3.992), by Elsevier (
> https://www.journals.elsevier.com/transportation-research-part-a-policy-and-practice/
> )
>
>
> ANT 2024 will be held in Hasselt, Belgium. ANT 2024 is co-organized &
> co-hosted by the Hasselt University, Belgium. Since 1973 Hasselt University
> is located on the Campus Diepenbeek, which occupies an attractive 150 acre
> site in the middle of Limburg's green belt. It is 2 kms west of the town
> centre of Diepenbeek, a residential town of 17.717 inhabitants, and 4 kms
> east of Hasselt which has a population of about 69.529 and is the
> administrative and commercial centre of the province. Brussels is 90 kms
> away (to the South-West), Antwerp lies 90 kms to the West, Liège (in the
> French-speaking part of Belgium) 45 kms to the South, Maastricht (in the
> Netherlands) 25 kms to the East, Aachen (in Germany) 60 kms to the
> South-East.
>
> ANT 2024 will be held in conjunction with the 7th International Conference
> on Emerging Data and Industry (EDI40).
>
> Conference Tracks
>- Agent Systems, Intelligent Computing and Applications
>- Big Data and Analytics
>- Cloud Computing
>- Context-awareness and Multimodal Interfaces
>- Emerging Networking, Tracking and Sensing Technologies
>- Human Computer Interaction
>- Internet of Things
>- Mobile Networks, Protocols and Applications
>- Modelling and Simulation in Transportation Sciences
>- Multimedia and Social Computing
>- Service Oriented Computing for Systems & Applications
>- Smart, Sustainable Cities and Climate Change Management
>- Smart Environments and Applications
>- Systems Security and Privacy
>- Systems Software Engineering
>- Vehicular Networks and Applications
>- General Track
>
>
> General Chairs
>
>Atta Badii, University of Reading, UK
>Albert Zomaya, The University of Sydney, Australia
>
> Program Chairs
>
>Hossam Hassanein, Queen's University, Canada
>Ansar-Ul-Haque Yasar, Hasselt University, Belgium
>
> Workshops Chair
>
>Stephane Galland, UTBM, France
>
> Vice Chairs
>
>   Muhammad Adnan, Hasselt University, Belgium
>   Manzoor Ahmed, Hubei Engineering University, Xiaogan, China
>   Akramul Azim, Ontario Tech University, Canada
>   Ayoub Bahnasse, Hassan II University, Morocco
>   Nik Bessis, Edge Hill University, UK
>   Samia Bouzefrane, CEDRIC Lab Conservatoire National des Arts et Metiers,
> France
>   Junsung Choi, Chungbuk National University, Republic of Korea
>   Robertas Damasevicius, Kaunas University of Technology, Lithuania
>   Antonella G

Re: [Haskell] CFP, PEPM 2024 ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation

[Meng Wang]

Dear Haskellers,

A gentle reminder that the submission deadline is in two weeks.

Best regards,
Gabriele Keller (Utrecht University, Netherlands)
Meng Wang (University of Bristol, UK)


From: Meng Wang 
Date: Thursday, 7 September 2023 at 08:52
To: haskell-c...@haskell.org , haskell@haskell.org 

Cc: g.k.kel...@uu.nl 
Subject: CFP, PEPM 2024 ACM SIGPLAN Workshop on Partial Evaluation and Program 
Manipulation
Dear Haskellers,

Gabriele and I are organising PEPM this year. Over the years, PEPM has grown 
into a conference of general PL topics and Haskell/FP is strongly represented. 
We look forward to receiving your submissions.

Best regards,
Gabriele Keller (Utrecht University, Netherlands)
Meng Wang (University of Bristol, UK)


--
**
**CALL FOR PAPERS
**
**PEPM at POPL 2024
**Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION
**16th of January 2024, London, United Kingdom
**
**Submission Deadline:
**18 October 2023
**
**https://popl24.sigplan.org/home/pepm-2024
**https://easychair.org/conferences/?conf=pepm24
**
---

ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2024
===

  * Website : https://popl24.sigplan.org/home/pepm-2024
  * Time: 16th January 2024
  * Place   : London, United Kingdom
  (co-located with POPL 2024)

The ACM SIGPLAN Workshop on Partial Evaluation and Program
Manipulation (PEPM) has a history going back to 1991 and has been
co-located with POPL every year since 2006. It originated with the
discoveries of useful automated techniques for evaluating
programs with only partial input. Over the years, the scope of PEPM
has expanded to include a variety of research areas centred around the
theme of semantics-based program manipulation — the systematic
exploitation of treating programs not only as subjects to black-box
execution but also as data structures that can be generated,
analysed, and transformed while establishing or maintaining important
semantic properties.

Scope
-

In addition to the traditional PEPM topics (see below), PEPM 2024
welcomes submissions in new domains, in particular:

  * Semantics based and machine-learning based program synthesis and
program optimisation.

  * Modelling, analysis, and transformation techniques for distributed
and concurrent protocols and programs, such as session types,
linear types, and contract specifications.

More generally, topics of interest for PEPM 2024 include, but are not
limited to:

  * Program and model manipulation techniques such as:
supercompilation, partial evaluation, fusion, on-the-fly program
adaptation, active libraries, program inversion, slicing, symbolic
execution, refactoring, decompilation, and obfuscation.

  * Techniques that treat programs/models as data objects including
metaprogramming, generative programming, embedded domain-specific
languages, program synthesis by sketching and inductive
programming, staged computation, and model-driven program
generation and transformation.

  * Program analysis techniques that are used to drive program/model
manipulation such as: abstract interpretation, termination
checking, binding-time analysis, constraint solving, type systems,
   automated testing and test case generation.

  * Application of the above techniques including case studies of
program manipulation in real-world (industrial, open-source)
projects and software development processes, descriptions of
robust tools capable of effectively handling realistic
applications, benchmarking. Examples of application domains
include legacy program understanding and transformation, DSL
implementations, visual languages and end-user programming,
scientific computing, middleware frameworks and infrastructure
needed for distributed and web-based applications, embedded and
resource-limited computation, and security.

This list of categories is not exhaustive, and we encourage
submissions describing new theories and applications related to
semantics-based program manipulation in general. If you have a
question as to whether a potential submission is within the scope of
the workshop, please contact the programme co-chairs, Gabriele Keller
(g.k.kel...@uu.nl) and Meng Wang 
(meng.w...@bristol.ac.uk).

Submission categories and guidelines


Three kinds of submissions will be accepted:

  * Regular Research Papers should describe new results, and will be
judged on originality, correctness, significance, and clarity.
Regular research papers must not exceed 12 pages.

  * Short Papers may includ

Re: [Haskell] Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension)

[Ryan Scott]

Apologies, that should read *July* 16, not June 16, for the submission
deadline at the top of the email. (The body of the email contains the
correct date.)

Best,

Ryan

On Mon, Jul 10, 2023 at 6:34 PM Ryan Scott  wrote:

> TL;DR: The submission deadline for the 2023 Haskell Implementors' Workshop
> has been extended to June 16.
>
> ==
>
> ACM SIGPLAN Haskell Implementors' Workshop
> https://icfp23.sigplan.org/home/hiw-2023
> Seattle, Washington, United States, September 4, 2023
>
> Co-located with ICFP 2023
> https://icfp23.sigplan.org/
>
> Important dates
> ---
>
> Deadline: July 16, 2023 (AoE) (extended)
> Notification: August 4, 2023
> Workshop: September 4, 2023
>
> The 15th Haskell Implementors' Workshop is to be held alongside ICFP
> 2023 this year in Seattle. 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 to 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
> open spaces in the timetable and room for ad-hoc discussion, demos,
> and short lightning 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 2023. 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.
>
> The Implementors' Workshop is an ideal place to describe a Haskell
> extension, describe works-in-progress, demo a new Haskell-related tool,
> or even propose future lines of Haskell development. Members of the
> wider Haskell community are encouraged to attend the workshop -- we need
> your feedback to keep the Haskell ecosystem thriving. Students working
> with Haskell are especially encouraged to share their work.
>
> 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
> -
>
> We invite proposals from potential speakers for talks and
> demonstrations. We are aiming for 20-minute talks with 5 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 can be made via HotCRP at https://icfp-hiw23.hotcrp.com
> until July 16 (anywhere on earth).
>
> We will also have a lightning talks session. These have been very well
> received in recent years, and we aim to increase the time available to
> them. Lightning talks should be ~7mins and are scheduled on the day of the
> workshop. 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.
>
> Program Committee
> -
>
> * Gergő Érdi (Standard Chartered Bank)
> * Sebastian Graf (Karlsruhe Institute of Technology)
> * Wen Kokke (University of Strathclyde)
> * Ryan Scott (Galois, Inc.)
> * Rebecca Skinner (Mercury)
> * Li-yao Xia (University of Edinburgh)
>
> Contact
> ---
>
> * Ryan Scott 
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] The Point of this List

[Jeremy Gibbons]

The purpose of this list is specified on its webpage:

> The Haskell mailing list is for announcements and short discussions on any 
> topic related to the Haskell language. 
> 
> Discussions should be moved to the Haskell Cafe mailing list after a few 
> exchanges, so that the volume on this list can be kept low.

We don’t (please!) need another list for announcements. 

Perhaps there is scope for a discussion about how “related” a conference 
announcement should be for it to be announced here. And perhaps there is scope 
for a discussion about the name: maybe this list should be renamed 
haskell-announce, for expectation management? But if so, those discussions 
should presumably happen on haskell-cafe, not here.

Jeremy

> On 4 May 2023, at 10:33, James Flanagan  wrote:
> 
> Thank you for this tip. Wasn't aware of Haskell-Cafe.
> 
> Maybe this is the right place for conference announcements then, if it's just 
> for announcements in general. But the quantity is quite high and other stuff 
> is likely to get drowned out. It may be best split into a separate list so 
> that it only goes to those who are interested. (Not all of us are in 
> academia.)
> 
> James
> 
> From: Haskell  <mailto:haskell-boun...@haskell.org>> on behalf of Ivan Perez 
> mailto:ivanperezdoming...@gmail.com>>
> Sent: 01 May 2023 22:45
> To: Dominic Steinitz mailto:domi...@steinitz.org>>
> Cc: haskell@haskell.org <mailto:haskell@haskell.org>  <mailto:haskell@haskell.org>>
> Subject: Re: [Haskell] The Point of this List
>  
> Most people are just subscribed to haskell-cafe instead. If you are not 
> there, maybe that's the one you want to be subscribed to.
> 
> In the past I have reported such conference announcements so that the 
> specific individuals be removed from the list.
> 
> Ivan
> 
> On Mon, 1 May 2023 at 02:34, Dominic Steinitz  <mailto:domi...@steinitz.org>> wrote:
> I have been subscribed to this list for over 20 years but these days all I 
> ever see are announcements of conferences which have at best a tangential 
> relationship with Haskell. Maybe it is time to call it a day?
> 
> Dominic Steinitz
> domi...@steinitz.org <mailto:domi...@steinitz.org>
> http://idontgetoutmuch.org <http://idontgetoutmuch.org/>
> Twitter: @idontgetoutmuch
> 
> ___
> Haskell mailing list
> Haskell@haskell.org <mailto:Haskell@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell 
> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell>
> ___
> Haskell mailing list
> Haskell@haskell.org <mailto:Haskell@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell 
> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell>
jeremy.gibb...@cs.ox.ac.uk
Oxford University Department of Computer Science,
Wolfson Building, Parks Road, Oxford OX1 3QD, UK.
+44 1865 283521
http://www.cs.ox.ac.uk/people/jeremy.gibbons/

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

Re: [Haskell] The Point of this List

[James Flanagan]

Thank you for this tip. Wasn't aware of Haskell-Cafe.

Maybe this is the right place for conference announcements then, if it's just 
for announcements in general. But the quantity is quite high and other stuff is 
likely to get drowned out. It may be best split into a separate list so that it 
only goes to those who are interested. (Not all of us are in academia.)

James


From: Haskell  on behalf of Ivan Perez 

Sent: 01 May 2023 22:45
To: Dominic Steinitz 
Cc: haskell@haskell.org 
Subject: Re: [Haskell] The Point of this List

Most people are just subscribed to haskell-cafe instead. If you are not there, 
maybe that's the one you want to be subscribed to.

In the past I have reported such conference announcements so that the specific 
individuals be removed from the list.

Ivan

On Mon, 1 May 2023 at 02:34, Dominic Steinitz 
mailto:domi...@steinitz.org>> wrote:
I have been subscribed to this list for over 20 years but these days all I ever 
see are announcements of conferences which have at best a tangential 
relationship with Haskell. Maybe it is time to call it a day?

Dominic Steinitz
domi...@steinitz.org<mailto:domi...@steinitz.org>
http://idontgetoutmuch.org
Twitter: @idontgetoutmuch

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

Re: [Haskell] The Point of this List

[Thorsten Wißmann]

Hi all,

I agree: I wondered too what the point (or better say 'scope') of this
list is. I say this as someone who sent multiple conference
announcements / CFPs to this list ('CALCO' / 'CMCS' from coalg.org if
you're interested ☺). Before sending the CFPs, it wasn't clear whether
it is appropriate or might be considered annoying or even spam. So I
definitely welcome some criteria, which could be put on:

https://www.haskell.org/mailing-lists/

In particular, I'd find it helpful to have the following questions
answered there:

  - When sending call for papers, which topics are in scope? (functional
programming in general? "software"? Category theory? "Math"?..)
  - Are deadline extensions or further follow-up mails allowed? (e.g.
call for participation?)

Whether cfp-senders stick to these rules is then a separate issue, which
can be solved by blocking repeated off-topic announcements. My personal
intention is to advertise, of course, but only among those who might be
potentially interested :-)

Best,
Thorsten

On Mon, May 01, 2023, at 14:45 (-0700), Ivan Perez wrote:
> Most people are just subscribed to haskell-cafe instead. If you are not there,
> maybe that's the one you want to be subscribed to.
> In the past I have reported such conference announcements so that the specific
> individuals be removed from the list.
> Ivan
> On Mon, 1 May 2023 at 02:34, Dominic Steinitz <[1]domi...@steinitz.org> wrote:
> 
>   I have been subscribed to this list for over 20 years but these days all I
>   ever see are announcements of conferences which have at best a tangential
>   relationship with Haskell. Maybe it is time to call it a day?
>   Dominic Steinitz

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

Re: [Haskell] The Point of this List

[Ivan Perez]

Most people are just subscribed to haskell-cafe instead. If you are not
there, maybe that's the one you want to be subscribed to.

In the past I have reported such conference announcements so that the
specific individuals be removed from the list.

Ivan

On Mon, 1 May 2023 at 02:34, Dominic Steinitz  wrote:

> I have been subscribed to this list for over 20 years but these days all I
> ever see are announcements of conferences which have at best a tangential
> relationship with Haskell. Maybe it is time to call it a day?
>
> Dominic Steinitz
> domi...@steinitz.org
> http://idontgetoutmuch.org
> Twitter: @idontgetoutmuch
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Request for Nominations to the GHC Steering Committee

[Joachim Breitner]

Sorry for that, but

Am Donnerstag, dem 06.10.2022 um 14:28 +0200 schrieb Joachim Breitner:
> To nominate yourself, please send an email to me (as the committee
> secretary) at m...@joachim-breitner.de until February 11th.
> 

should be October 16th.

Cheers,
Joachim


-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/

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

Re: [Haskell] Research fellow position at University of Bristol

[Meng Wang]

Dear All,

Here is the second post at Bristol PL group. It is at the research associate 
level which is suitable for fresh PhD graduates. 
https://www.bristol.ac.uk/jobs/find/details/?jobId=274941&jobTitle=Research%20Associate%20or%20Senior%20Research%20Associate

Best regards,
Meng Wang, PhD (Oxon)
Senior Lecturer of Programming Languages
Head of PL research group
School International Director
SCEEM (CS, EEE, EMath) School, University of Bristol


From: Meng Wang 
Date: Friday, 20 May 2022 at 09:42
To: haskell-c...@haskell.org , haskell@haskell.org 

Subject: Research fellow position at University of Bristol
Dear Haskellers,

The programming languages group at Bristol is recruiting a research fellow to 
join our dynamic research group https://bristolpl.github.io/. Our research is 
ranked highly internationally and there is a strong focus on Haskell. We 
welcome functional programmers anywhere in the world to apply! (Another similar 
post at the level of research associate is also available.)

https://www.bristol.ac.uk/jobs/find/details/?jobId=274355&jobTitle=Research%20Fellow

Meng Wang, PhD (Oxon)
Senior Lecturer of Programming Languages
Head of PL research group
School International Director
SCEEM (CS, EEE, EMath) School, University of Bristol

PS. A selection of recent papers can be found below. They should give a good 
indication of the type of PL research conducted at Bristol:

- Perera et al. (2022). Linked visualisations via Galois dependencies. POPL 
2022. 10.1145/3498668
- Xie et al. (2022). Staging with Class. POPL 2022. 10.1145/3498723
- Yamaguchi et al. (2021). Synbit: Synthesizing Bidirectional Programs using 
Unidirectional Sketches. OOPSLA 2021. 10.1145/3485482
- Qian Z et al. (2021). Client-Server Sessions in Linear Logic. ICFP 2021. 
10.1145/3473567
- Jones E & Ramsay S. (2021). Intensional Refinement Datatypes. POPL 2021. 
10.1145/3445980
- Gratzer D et al. (2020). Multimodal Dependent Type Theory. LICS 2020. 
10.1145/3373718.3394736
- Matsuda K & Wang M. (2020). Sparcl: A Language for Partially-Invertible 
Computation. ICFP 2020. 10.1145/3409000
- Zhang J et al. (2019). A Study of Bug Resolution Characteristics in Popular 
Programming Languages. IEEE Transactions on Software Engineering. 
10.1109/TSE.2019.2961897
- Abate A et al. (2019). Automated Formal Synthesis of Provably Safe Digital 
Controllers for Continuous Plants. Acta Informatica, vol 57. 
10.1007/s00236-019-00359-1
- Almeida et al. (2019). Machine-Checked Proofs for Cryptographic Standards: 
Indifferentiability of Sponge and Secure High-Assurance Implementations of 
SHA-3. CCS 2019. 10.1145/3319535.336321
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Request for Nominations to the GHC Steering Committee

[Chris Dornan]

Hi Joachim,

I would like to nominate myself for a spot on the GHC Steering Committee if the 
committee thinks it is appropriate. I have been writing Haskell programs for 
pretty much as long as Haskell has been around. (I started with Miranda in 1987 
and tracked the Haskell reports as they became available.)

I think I have pretty good credentials in terms of conservative tendencies 
where Haskell is concerned being an early skeptic of type classes. (Early type 
classes appeared too weak to me given the complexity they were bringing but 
have been delighted to be proved comprehensively wrong.) I think my favourite 
language proposal is DerivingVia — it brings so much of what is good in Haskell 
together in an utterly delightful way. (Though being a past member of the ARM 
patent review committee I never saw anything approaching 1% of the invention in 
this proposal — IMHO, Turing Award have been dished out for less.)  Long story 
short, I like a good proposal, but it really needs to pay its way.

I am a strong believer in the GHC proposals process and tying them to language 
extension pragmas — it has really born tremendous fruits that could hardly have 
come both under the old monolithic language report regime. 

I do not have a strong background in type theory — I have however dabbled in 
the past, writing simple HM solvers, etc., and have a grasp of the fundamentals 
— so my main utility will be reviewing proposals from the perspective of a 
non-type theorist. You might have enough of those in which case you will be 
looking elsewhere!

Cheers,

Chris


> On 2022-01-29, at 11:36, Joachim Breitner  wrote:
> 
> Dear Haskell community,
> 
> the GHC Steering committee is seeking nominations for at least two new
> members.
> 
> The committee scrutinizes, nitpicks, improves, weights and eventually
> accepts or rejects proposals that extend or change the language
> supported by GHC and other (public-facing) aspects of GHC.
> Our processes are described at
>   https://github.com/ghc-proposals/ghc-proposals
> which is also the GitHub repository where proposals are proposed. In
> particular, please have a look at the bylaws at
>   https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst
> 
> 
> We are looking for a member who has the ability 
> * to understand such language extension proposals,
> * to find holes and missing corner cases in the specifications,
> * foresee the interaction with other language features and 
>   specifications,
> * comment constructively and improve the proposals,
> * judge the cost/benefit ratio and
> * finally come to a justifiable conclusion.
> 
> We look for committee members who have some of these properties:
> * have substantial experience in writing Haskell applications or
>   libraries, which they can use to inform judgements about the
>   utility or otherwise of proposed features,
> * have made active contributions to the Haskell community, for
>   some time,
> * have expertise in language design and implementation, in either
>   Haskell or related languages, which they can share with us.
> 
> The committee’s work requires a small, but non-trivial amount of time,
> especially when you are assigned a proposal for shepherding. We
> estimate the workload to be around 2 hours per week, and our process
> works best if members usually respond to technical emails within 1-2
> weeks (within days is even better). Please keep that in mind if your
> email inbox is already overflowing.
> 
> There is no shortage of people who are eager to get fancy new
> features into the language, both in the committee and the wider
> community. But each new feature imposes a cost, to implement, to learn,
> (particularly) through its unexpected interaction with other features.
> We need to strike a balance, one that encourages innovation (as GHC
> always has) while still making Haskell attractive for real-world
> production use and for teaching. We therefore explicitly invite
> “conservative” members of the community to join the committee.
> 
> To make a nomination, please send an email to me (as the committee
> secretary) at m...@joachim-breitner.de until February 11th. I will
> distribute the nominations among the committee, and we will keep the
> nominations and our deliberations private.
> 
> We explicitly encourage self-nominations. You can nominate others, but
> please obtain their explicit consent to do so. (We don’t want to choose
> someone who turns out to be unable to serve.)
> 
> On behalf of the committee,
> Joachim Breitner
> 
> -- 
> Joachim Breitner
>  m...@joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: [Haskell] The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022

[Ivan Perez]

Can we please unsubscribe this person?

Cheers,

Ivan

On Mon, 13 Sept 2021 at 23:02, Shashank Swarup 
wrote:

> ***
> The 5th International Conference on Emerging Data and Industry 4.0 (EDI40)
> Porto, Portugal
> March 22-25, 2022
> ***
>
> Conference Website:  http://cs-conferences.acadiau.ca/EDI40-22/
> Workshops: http://cs-conferences.acadiau.ca/EDI40-22/#workshop
>
> Important Dates
>   - Workshops Proposals Due: October 1, 2021
>
> *   - Paper Submission Due: November 1, 2021 *   - Acceptance
> Notification: December 30, 2021
>- Camera-Ready Submission: January 27, 2022
>
>
> EDI40 2022 accepted papers will be published by Elsevier Science in the
> open-access Procedia Computer Science series on-line. Procedia Computer
> Science is hosted by Elsevier on www.Elsevier.com and on Elsevier content
> platform ScienceDirect (www.sciencedirect.com), and will be freely
> available worldwide. All papers in Procedia will be indexed by Scopus (
> www.scopus.com) and by Thomson Reuters' Conference Proceeding Citation
> Index (http://thomsonreuters.com/conference-proceedings-citation-index/).
> All papers in Procedia will also be indexed by Scopus (www.scopus.com)
> and Engineering Village (Ei) (www.engineeringvillage.com). This includes
> EI Compendex (www.ei.org/compendex). Moreover, all accepted papers will
> be indexed in DBLP (http://dblp.uni-trier.de/). The papers will contain
> linked references, XML versions and citable DOI numbers. You will be able
> to provide a hyperlink to all delegates and direct your conference website
> visitors to your proceedings. Selected papers will be invited for
> publication, in the special issues of:
>
>  - International Journal of Ambient Intelligence and Humanized Computing
> (IF: 4.594), by Springer (
> http://www.springer.com/engineering/journal/12652)
> - International Journal Personal and Ubiquitous Computing (IF:3.006),
> Springer (https://www.springer.com/journal/779)
> - International Journal on Transportation Research Part A: Policy and
> Practice (IF: 3.992), by Elsevier (
> https://www.journals.elsevier.com/transportation-research-part-a-policy-and-practice/
> )
> - International Journal of Computing and Informatics (IF: 0.524), by
> Computing and Informatics (http://www.cai.sk/ojs/index.php/cai/index)
>
>
> EDI40 2022 will be held in Porto, Portugal. Porto is the second-largest
> city in Portugal after Lisbon and one of the major urban areas of the
> Iberian Peninsula. Porto is also called the Invicta because during the 19th
> century Portuguese civil war, the city withstood a siege of over a year.The
> urban area of Porto, which extends beyond the administrative limits of the
> city, has a population of 2.1 million in an area of 389 km2 (150 sq mi),
> making it the second-largest urban area in Portugal. It is recognized as a
> gamma- level global city by the Globalization and World Cities (GaWC) Study
> Group, the only Portuguese city besides Lisbon to be recognized as a global
> city.
> EDI40 will be held in conjunction with the 13th International Conference
> on Ambient Systems, Networks and Technologies (ANT 2022).
>
> Conference Tracks
>   - Benefits of Industry 4.0
>   - Big Data and Analytics
>   - Cloud Computing
>   - Cognitive Computing
>   - Computational Intelligence
>   - Cyber-Physical Systems (CPS)
>   - Fog Computing and Edge Computing
>   - Internet of Everything (IoE)
>   - Standards for IoT Application Integration
>   - The New Business Models in Industry 4.0
>   - General Track: Digitalization Startegies
>
> Committees
> General Chair
>   Danny Hughes, CTO VeraSense NV, Belgium
>
> Program Chairs
>   Jamal Bentahar, Concordia University, Canada
>   Haroon Malik, Marshall University, USA
>
> Local Chair
>   Nuno Varandas, F6S (Where Founders Grow Together), Portugal
>
> Workshops Chair
>   Stephane Galland, UTBM, France Program
>
> Advisory Committee
>   Reda Alhajj, University of Calgary, Canada
>   Ladislav Hluchy, Institute of Informatics, Slovak Academy of Sciences,
> Slovakia
>   Vincenzo Loia, University of Salerno, Italy
>   Peter Sloot, Universiteit van Amsterdam, Netherlands
>   Peter Thomas, Manifesto Research, Australia
>   Mohamed Younis, University of Maryland Baltimore County, USA
>
> International Journals Chair
>   Michael Sheng, Macquarie University, Australia
>
> Publicity Chairs
>   Wim Ectors, Hasselt University, Belgium
>   Faouzi Kammoun, Ecole Supérieure Privée d'Ingénierie et de
> Technologies, Tunis
>   Aneta Poniszewska-Marańda, Lodz University of Technology, Poland
>   Shashank Swarup, Acadia University, Canada
>
> Technical Program Committee
>   http://cs-conferences.acadiau.ca/EDI40-22/#programCommittees
>
> International Liaison Chairs
>   Soumaya Cherkaoui, Sherbrooke University, Canada
>   Nik Bessis, Edge Hill University, UK
>   David Taniar, Monash Un

Re: [Haskell] International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) -Prague

[Ivan Perez]

Can we please permanently ban this person and everyone from the
confscience.com domain?

Thanks,

Ivan

On Tue, 29 Jun 2021 at 08:28, Emilia Marc  wrote:

> Call for papers
>
> *
>
> International Conference on Informatics Revolution for Smarter Healthcare
> (IRSH 2021)
>
> Prague- Czech Republic, October 14-15, 2021
>
> https://confscience.com/irsh/
>
> All papers accepted in IRSH 2021 will be published in Springer CCIS
> (Communications in Computer and Information Science).
>
> CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical
> Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings
> Citation (Former ISI Proceedings)
>
> ***
>
> IMPORTANT DATES:
>
> - Paper Submission: June 30, 2021 (extended)
>
> - Acceptance Notification: July 15, 2021
>
> - Final Manuscript Due: September 1, 2021
>
> ***
>
> The IRSH 2021 conference will be held in Conjunction with:
>
> International Conference on Applied Data Science and Intelligence (ADSI
> 2021)
>
> International Conference on Recent Theories and Applications in
> Transportation and Mobility - (RTATM 2021)
>
> ***
>
> TOPICS:
>
> Authors are invited to submit their original papers to address the topics
> of the conference, including but not limited to:
>
> FUNDAMENTALS AND THEORIES
>
> - Interoperability and Data Integration
>
> - Confidentiality and Data Security
>
> - Data protection
>
> - Data Sharing
>
> - Security, Privacy, and Trust
>
> - Emergent healthcare standards
>
> - Emergent healthcare architectures
>
> - ICT, Ageing and Disability
>
> - Physiological and behavioural modelling
>
> - Pandemic and disease modeling
>
> - Usability and user experience of medical devices
>
> - Human behaviour
>
> - Clinical investigation regulatory frameworks
>
> - Integrated healthcare approaches
>
> - eHealth data standards and interoperability (e.g. HL7/FHIR)
>
> - Databases and data warehousing
>
> - Big Data and Open Data for healthcare
>
> - Design and Development of Methodologies for Healthcare
>
> - Emergent Communication Technologies
>
> - Real-time interaction theories
>
> - Emergent Technologies for Ambient Assisted Living
>
> - User Interface Design for healthcare
>
> - Sustainability
>
> - New approaches for accuracy and effectiveness
>
> - Data mining and bioinformatics
>
> - Enhanced living environments
>
> - Analysis and evaluation of healthcare systems
>
> INTELLIGENT HEALTHCARE
>
> - Pattern recognition and Machine
>
> - Learning for healthcare
>
> - Cognitive Informatics
>
> - Big Data in Healthcare
>
> - Wellbeing Informatics
>
> - Data Mining and Data Analytics
>
> - Data Visualization
>
> - Smart environments
>
> - Smart Ambient Assisted Living
>
> - Intelligent healthcare solutions
>
> - Agent-based solutions for healthcare
>
> - Collaboration systems
>
> - Intelligent Electronic Health Records
>
> - Internet of Things for healthcare
>
> - Cyber-Physical Systems for healthcare
>
> - Ambient Computing and Reasoning
>
> - Context Awareness
>
> - Smart devices for eldercare
>
> - Autonomy and active ageing
>
> - Emergent technologies for intelligent Computer Vision
>
> - Service production and delivery
>
> - Gamification
>
> - Multi-modal interaction
>
> - Computer-aided detection and diagnosis
>
> - Crowdsourcing for smarted healthcare
>
> SERVICES, SYSTEMS, AND INFRASTRUCTURES
>
> - Emergent healthcare services
>
> - Pervasive health systems and services
>
> - Remote healthcare management
>
> - Emergent healthcare infrastructure
>
> - Industry Revolution 4.0 for healthcare
>
> - eHealth
>
> - Electronic health records
>
> - Assistive technologies
>
> - Disease surveillance and patient monitoring systems
>
> - Prevention and detection systems
>
> - Home monitoring
>
> - Healthcare management systems
>
> - ICT-based therapeutic systems
>
> - ICT-based rehabilitation technologies
>
> - Wearable health informatics
>
> - Emergent technologies for data analytics
>
> - Ambient Assisted Leaving (AAL)
>
> - Decision Support Systems
>
> - Emergent Technologies for Remote AAL Monitoring
>
> - Emergent Technologies and Accessibility
>
> - 5G for healthcare
>
> - Healthcare supply chain and logistics
>
> - Wireless Body Networks
>
> - Telemedicine and mobile telemedicine
>
> - Mobile Systems
>
> - Software Defined infrastructures
>
> - Patient empowerment systems
>
> - Smart technology for remote patient visits
>
> - Biosensors
>
> - Medical devices
>
> APPLICATIONS
>
> - eHealth applications
>
> - Application of health informatics in clinical cases
>
> - Mobile technologies for healthcare applications
>
> - Software Systems in healthcare
>
> - Social networking and healthcare
>
> - Case Studies
>
> - Personalization and patient experience
>
> - AR and VR applic

Re: [Haskell] CFP (ICTH 2021) The 11th International Conference on Current and Future Trends of Information and Communication Technologies in Healthcare) Leuven, Belgium

[Ivan Perez]

Admins, see below. Your call.

Hana, if you are allowed to remain subscribed, I'd like to ask that you
just don't send CfPs for this conference or for other conferences.

Ivan

On Tue, 1 Jun 2021 at 07:50, Hana Gharrad  wrote:

> Hi Ivan,
>
> Sorry, I won't repeat other dissemination for the same conference via
> Haskell.
> Could you please keep my email in the list?
>
> I'm so grateful,
> Sorry again.
>
> On Tue, 1 Jun 2021 at 13:48, Ivan Perez 
> wrote:
>
>> Admins,
>>
>> Can we please remove and permanently ban the following addresses from
>> this list?
>>
>> gharred.h...@gmail.com
>> hannah.ghar...@gmail.com
>> hana.ghar...@uhasselt.be
>>
>> Thank you,
>>
>> Ivan
>>
>>
>> On Tue, 1 Jun 2021 at 02:15, Hana Gharrad 
>> wrote:
>>
>>> Conference: The 11th International Conference on Current and Future
>>> Trends of Information and Communication Technologies in Healthcare  (ICTH)
>>>
>>> Date: November 1-4, 2021
>>> Location: Leuven, Belgium
>>> Website: http://cs-conferences.acadiau.ca/icth-21/
>>>
>>> **
>>> ---Important Dates
>>> --
>>>   - Workshop Proposals: May 30, 2021
>>>   - Paper Submission Due:  June 15, 2021
>>>   - Author Notification:   August 4, 2021
>>>   - Final Manuscript Due:   August 30, 2021
>>>
>>> ---Publication
>>> -
>>> All ICTH 2021 accepted papers will be published by Elsevier Science in
>>> the open-access Procedia Computer Science series on-line. Procedia Computer
>>> Science is hosted by Elsevier on www.Elsevier.com and on Elsevier
>>> content platform ScienceDirect (www.sciencedirect.com), and will be
>>> freely available worldwide. All papers in Procedia will be indexed by
>>> Scopus (www.scopus.com) and by Thomson Reuters' Conference Proceeding
>>> Citation Index (
>>> http://thomsonreuters.com/conference-proceedings-citation-index/). All
>>> papers in Procedia will also be indexed by Scopus (www.scopus.com) and
>>> Engineering Village (Ei) (www.engineeringvillage.com). This includes EI
>>> Compendex (www.ei.org/compendex). Moreover, all accepted papers will be
>>> indexed in DBLP (http://dblp.uni-trier.de/). The papers will contain
>>> linked references, XML versions and citable DOI numbers. Selected papers
>>> will be invited for publication, in the special issues of:
>>>
>>>  - International Journal of Ambient Intelligence and Humanized
>>> Computing  (IF: 4.594), by Springer (
>>> http://www.springer.com/engineering/journal/12652)
>>>  - International Journal of Computing and Informatics (IF: 0.524), (
>>> http://www.cai.sk/ojs/index.php/cai/index)
>>>  - International Journal of E-Health and Medical Communications, by
>>> IGI Global: (
>>> http://www.igi-global.com/journal/international-journal-health-medical-communications/1158
>>> )
>>>
>>> ICTH 2021 will be held in conjunction with the 12th International
>>> Conference on Emerging Ubiquitous Systems and Pervasive Networks (EUSPN:
>>> http://cs-conferences.acadiau.ca/euspn-21/). Papers on either completed
>>> or ongoing research are invited:
>>> http://cs-conferences.acadiau.ca/icth-21/call-for-papers.html
>>>
>>> ICTH 2021 will be held in the city of Leuven. Leuven is the capital of
>>> the province of Flemish Brabant in Belgium. It is located about 25
>>> kilometres (16 miles) east of Brussels. It is the 10th largest municipality
>>> in Belgium and the fourth in Flanders. Leuven is home to the Katholieke
>>> Universiteit Leuven, the largest and oldest university of the Low Countries
>>> and the oldest Catholic university still in existence. The related
>>> university hospital of UZ Leuven, is one of the largest hospitals of
>>> Europe. The city is also known for being the headquarters of Anheuser-Busch
>>> InBev, the world's largest brewer and one of the five largest
>>> consumer-goods companies in the world.
>>>
>>> The conference venue will be at Park Inn (by Radisson) Hotel (Leuven),
>>> which is located right in the heart of the Leuven City. The hotel is less
>>> than 2 mins walk from the Leuven train station. All you have to do is to
>>> get off the train (or the taxi or the bus) and take the elevator to the
>>> bridge connecting the hotel with the rest of the city. Leuven city is
>>> directly connected with the Brussels International airport with a 13 min
>>> connection via train, 45 mins via bus or a 20 min by taxi (or Uber).
>>>
>>> ---Topics of interest include, but are not limited to:
>>> --
>>> - Ambient Assisted Living for Elderly Care
>>> - Ambient Intelligence and Intelligent Service Systems
>>> - Analysis and Evaluation of Healthcare Systems
>>> - Clinical Data and Knowledge Management
>>> - Cloud Computing for Healthcare
>>> - Collaboration Technologies for Healthcare
>>> - Context-aware Applications for Patient Monitoring and Care
>>> - Data mining Techniques and Data Warehouses in Healthcare
>>> - Data Visualization
>>> -

Re: [Haskell] CFP (ICTH 2021) The 11th International Conference on Current and Future Trends of Information and Communication Technologies in Healthcare) Leuven, Belgium

[Ivan Perez]

Admins,

Can we please remove and permanently ban the following addresses from this
list?

gharred.h...@gmail.com
hannah.ghar...@gmail.com
hana.ghar...@uhasselt.be

Thank you,

Ivan


On Tue, 1 Jun 2021 at 02:15, Hana Gharrad  wrote:

> Conference: The 11th International Conference on Current and Future Trends
> of Information and Communication Technologies in Healthcare  (ICTH)
>
> Date: November 1-4, 2021
> Location: Leuven, Belgium
> Website: http://cs-conferences.acadiau.ca/icth-21/
>
> **
> ---Important Dates
> --
>   - Workshop Proposals: May 30, 2021
>   - Paper Submission Due:  June 15, 2021
>   - Author Notification:   August 4, 2021
>   - Final Manuscript Due:   August 30, 2021
>
> ---Publication
> -
> All ICTH 2021 accepted papers will be published by Elsevier Science in the
> open-access Procedia Computer Science series on-line. Procedia Computer
> Science is hosted by Elsevier on www.Elsevier.com and on Elsevier content
> platform ScienceDirect (www.sciencedirect.com), and will be freely
> available worldwide. All papers in Procedia will be indexed by Scopus (
> www.scopus.com) and by Thomson Reuters' Conference Proceeding Citation
> Index (http://thomsonreuters.com/conference-proceedings-citation-index/).
> All papers in Procedia will also be indexed by Scopus (www.scopus.com)
> and Engineering Village (Ei) (www.engineeringvillage.com). This includes
> EI Compendex (www.ei.org/compendex). Moreover, all accepted papers will
> be indexed in DBLP (http://dblp.uni-trier.de/). The papers will contain
> linked references, XML versions and citable DOI numbers. Selected papers
> will be invited for publication, in the special issues of:
>
>  - International Journal of Ambient Intelligence and Humanized
> Computing  (IF: 4.594), by Springer (
> http://www.springer.com/engineering/journal/12652)
>  - International Journal of Computing and Informatics (IF: 0.524), (
> http://www.cai.sk/ojs/index.php/cai/index)
>  - International Journal of E-Health and Medical Communications, by
> IGI Global: (
> http://www.igi-global.com/journal/international-journal-health-medical-communications/1158
> )
>
> ICTH 2021 will be held in conjunction with the 12th International
> Conference on Emerging Ubiquitous Systems and Pervasive Networks (EUSPN:
> http://cs-conferences.acadiau.ca/euspn-21/). Papers on either completed
> or ongoing research are invited:
> http://cs-conferences.acadiau.ca/icth-21/call-for-papers.html
>
> ICTH 2021 will be held in the city of Leuven. Leuven is the capital of the
> province of Flemish Brabant in Belgium. It is located about 25 kilometres
> (16 miles) east of Brussels. It is the 10th largest municipality in Belgium
> and the fourth in Flanders. Leuven is home to the Katholieke Universiteit
> Leuven, the largest and oldest university of the Low Countries and the
> oldest Catholic university still in existence. The related university
> hospital of UZ Leuven, is one of the largest hospitals of Europe. The city
> is also known for being the headquarters of Anheuser-Busch InBev, the
> world's largest brewer and one of the five largest consumer-goods companies
> in the world.
>
> The conference venue will be at Park Inn (by Radisson) Hotel (Leuven),
> which is located right in the heart of the Leuven City. The hotel is less
> than 2 mins walk from the Leuven train station. All you have to do is to
> get off the train (or the taxi or the bus) and take the elevator to the
> bridge connecting the hotel with the rest of the city. Leuven city is
> directly connected with the Brussels International airport with a 13 min
> connection via train, 45 mins via bus or a 20 min by taxi (or Uber).
>
> ---Topics of interest include, but are not limited to:
> --
> - Ambient Assisted Living for Elderly Care
> - Ambient Intelligence and Intelligent Service Systems
> - Analysis and Evaluation of Healthcare Systems
> - Clinical Data and Knowledge Management
> - Cloud Computing for Healthcare
> - Collaboration Technologies for Healthcare
> - Context-aware Applications for Patient Monitoring and Care
> - Data mining Techniques and Data Warehouses in Healthcare
> - Data Visualization
> - Decision Support Systems in Healthcare
> - Design and Development Methodologies for Healthcare Systems
> - Diagnostic and Therapeutic Technologies in Healthcare
> - Digital Hospitals
> - Drug Information Systems
> - E-health & m-health
> - Electronic Health Records (EHR) & Personal Health Records (PHR)
> - Evidence Based Medicine (EBM)
> - Healthgrids
> - Health Portals
> - Information and Knowledge Processing in Healthcare Environments
> - Middleware Support for Smart Homes and Intelligent Applications
> - Quantified Self for Pervasive Healthcare
> - Privacy, Confidentiality and Security Issues in Healthcare Systems
> - Related Real World Experimentations 

Re: [Haskell] International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) - Extended Deadline 13 June 2021

[Ivan Perez]

Can the mailing list admins please permanently ban this address as well? 6
CfPs in 5 months and no other contribution.

Ivan


On Sun, 30 May 2021 at 02:05, Mayssa HEMDANI 
wrote:

> Call for papers
> *
> International Conference on Recent Theories and Applications in
> Transportation and Mobility - (RTATM 2021)
> Prague - Czech Republic, October 14-15, 2021
> https://confscience.com/rtatm/
> All papers accepted in RTATM 2021 will be published in Springer CCIS
> (Communications in Computer and Information Science).
> CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical
> Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings
> Citation (Former ISI Proceedings)
> ***
> IMPORTANT DATES:
> - Paper Submission: June 13, 2021 (extended)
> - Acceptance Notification: July 1, 2021
> - Final Manuscript Due: September 1, 2021
> ***
> The RTATM 2021 conference will be held in Conjunction with:
> International Conference on Applied Data Science and Intelligence (ADSI
> 2021)
> International Conference on Informatics Revolution for Smarter Healthcare
> (IRSH 2021)
> ***
> TOPICS:
> Authors are invited to submit their original papers to address the topics
> of the conference, including but not limited to:
> FUNDAMENTALS AND THEORIES
> - Modelling and Simulation Algorithms
> - Vehicular Wireless Medium Access Control
> - V2X communications
> - Routings and Protocols for Connected Vehicles
> - Mobility Models and Architectures
> - Distribution Strategies
> - Traffic Incident Management Systems
> - Bio-Inspired Approaches
> - Optimization and Collaboration
> - Automatic Control in Vehicular Networks
> - Energy-aware Connected Mobility
> - Programming Languages
> - Sustainable Transportation
> - Multimodal Transportation Networks and Systems
> - Systemsb Integration
> - Driver Behavior Models and Simulation
> - Human Factors and Travel Behaviour
> - Green Mobility
> - Regulations and Bylaws for Intelligent
> - Transportation and Mobility
> SMART TRANSPORTATION AND LOGISTICS
> - Mobility Management
> - Connected Vehicles
> - VANETs
> - Predictive Logistics
> - Spatio-Temporal Event Tracking
> - Decision Support Systems
> - Emergency Management
> - Logistics and E-Commerce
> - Supply Chain Design and Execution
> - Supply Chain Management
> - Advanced Planning Systems
> - Fleet Management
> - Multi-Agent Systems
> - Machine Learning for Smart Logistics
> - Intelligent Infrastructures
> - Real-time Analysis of Comprehensive Supply Chain Data
> - Smart Synchronization of Logistics Processes
> - New Approaches for Cost Transparency
> - Big Data for Smart Logistics
> - Logistics 4.0
> - Mobile Networks
> - Next-Generation Smart Logistics
> - Performance Management Approaches
> - Tests and Deployment
> - Software Defined Networks
> - Smart Freight Management
> - Smart Shipment Management
> - Smart Warehousing
> - Smart Inventory management
> DATA AND SERVICES
> - Real-Time transportation Data Acquisition
> - Event Detection and Monitoring
> - Data Warehouses for connected mobility
> - Data mining and Data analytics
> - Data Worthiness in Connected Vehicles
> - Data Trustworthiness for effective transportation and mobility
> - Road Traffic Data Analytics
> - Structured and Unstructured Data for Connected Mobility
> - Volunteered Geographic Information (VGI)
> - Data Representation for Connected Mobility
> - Transportation Data Mining
> - Transportation and mobility Data Visualization
> - Cognitive and Context-aware Intelligence
> - Transportation Decision Support Systems
> - Mobility as a Service (MaaS)
> - Intelligent Transportation Services
> - Smart Mobility Services
> - Big Data and Vehicle Analytics
> - Massive Data Management
> - Collective and connected Intelligence
> - Next Generation Services
> - Driver Behaviour Analysis
> - Geo-Spatial Services
> - Service-Oriented Architecture (SOA)
> - Web and Mobile Services
> SAFETY, SECURITY, AND HAZARD MANAGEMENT
> - Security Issues in Vehicular Communications
> - Safety Applications of Connected Vehicles
> - Weather-related Safety solutions
> - V2V, V2I and I2V Road Safety Applications
> - Connected Mobility for Hazard Management
> - Risk Management
> - Road Traffic Crashes Analytics
> - Traffic Jam Prediction
> - Resource Allocation for Hazard Management
> - Trust and Privacy Issues in Logistics
> - Management of Exceptional Events
> - New approaches to Networking Security for Transportation Applications
> - Failure modes, human factors, software safety
> - Automated Failure Analysis
> - Performance and Human Error Analysis
> - Design and Reliability of Control Systems
> - Dispersion Modelling Software
> - Quantification of Risk
>
>
> *

Re: [Haskell] International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) - Extended Deadline 13 june 2021

[Ivan Perez]

For the record: I have 12 CfP from this person (or bot?) via the Haskell
Mailing list so far in 2021. I think enough is enough.

Ivan

On Sat, 29 May 2021 at 15:58, Ivan Perez 
wrote:

> Haskell mailing lists admins,
>
> Can we please permanently ban everyone from the confscience.com domain?
>
> Thanks,
>
> Ivan
>
>
>
> On Sat, 29 May 2021 at 15:44, Emilia Marc  wrote:
>
>> Call for papers
>>
>> *
>>
>> International Conference on Informatics Revolution for Smarter Healthcare
>> (IRSH 2021)
>>
>> Prague- Czech Republic, October 14-15, 2021
>>
>> https://confscience.com/irsh/
>>
>> All papers accepted in IRSH 2021 will be published in Springer CCIS
>> (Communications in Computer and Information Science).
>>
>> CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical
>> Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings
>> Citation (Former ISI Proceedings)
>>
>>
>> ***
>>
>> IMPORTANT DATES:
>>
>> - Paper Submission: June 13, 2021 (extended)
>>
>> - Acceptance Notification: July 1, 2021
>>
>> - Final Manuscript Due: September 1, 2021
>>
>>
>> ***
>>
>> The IRSH 2021 conference will be held in Conjunction with:
>>
>> International Conference on Applied Data Science and Intelligence (ADSI
>> 2021)
>>
>> International Conference on Recent Theories and Applications in
>> Transportation and Mobility - (RTATM 2021)
>>
>>
>> ***
>>
>> TOPICS:
>>
>> Authors are invited to submit their original papers to address the topics
>> of the conference, including but not limited to:
>>
>> FUNDAMENTALS AND THEORIES
>>
>> - Interoperability and Data Integration
>>
>> - Confidentiality and Data Security
>>
>> - Data protection
>>
>> - Data Sharing
>>
>> - Security, Privacy, and Trust
>>
>> - Emergent healthcare standards
>>
>> - Emergent healthcare architectures
>>
>> - ICT, Ageing and Disability
>>
>> - Physiological and behavioural modelling
>>
>> - Pandemic and disease modeling
>>
>> - Usability and user experience of medical devices
>>
>> - Human behaviour
>>
>> - Clinical investigation regulatory frameworks
>>
>> - Integrated healthcare approaches
>>
>> - eHealth data standards and interoperability (e.g. HL7/FHIR)
>>
>> - Databases and data warehousing
>>
>> - Big Data and Open Data for healthcare
>>
>> - Design and Development of Methodologies for Healthcare
>>
>> - Emergent Communication Technologies
>>
>> - Real-time interaction theories
>>
>> - Emergent Technologies for Ambient Assisted Living
>>
>> - User Interface Design for healthcare
>>
>> - Sustainability
>>
>> - New approaches for accuracy and effectiveness
>>
>> - Data mining and bioinformatics
>>
>> - Enhanced living environments
>>
>> - Analysis and evaluation of healthcare systems
>>
>> INTELLIGENT HEALTHCARE
>>
>> - Pattern recognition and Machine
>>
>> - Learning for healthcare
>>
>> - Cognitive Informatics
>>
>> - Big Data in Healthcare
>>
>> - Wellbeing Informatics
>>
>> - Data Mining and Data Analytics
>>
>> - Data Visualization
>>
>> - Smart environments
>>
>> - Smart Ambient Assisted Living
>>
>> - Intelligent healthcare solutions
>>
>> - Agent-based solutions for healthcare
>>
>> - Collaboration systems
>>
>> - Intelligent Electronic Health Records
>>
>> - Internet of Things for healthcare
>>
>> - Cyber-Physical Systems for healthcare
>>
>> - Ambient Computing and Reasoning
>>
>> - Context Awareness
>>
>> - Smart devices for eldercare
>>
>> - Autonomy and active ageing
>>
>> - Emergent technologies for intelligent Computer Vision
>>
>> - Service production and delivery
>>
>> - Gamification
>>
>> - Multi-modal interaction
>>
>> - Computer-aided detection and diagnosis
>>
>> - Crowdsourcing for smarted healthcare
>>
>> SERVICES, SYSTEMS, AND INFRASTRUCTURES
>>
>> - Emergent healthcare services
>>
>> - Pervasive health systems and services
>>
>> - Remote healthcare management
>>
>> - Emergent healthcare infrastructure
>>
>> - Industry Revolution 4.0 for healthcare
>>
>> - eHealth
>>
>> - Electronic health records
>>
>> - Assistive technologies
>>
>> - Disease surveillance and patient monitoring systems
>>
>> - Prevention and detection systems
>>
>> - Home monitoring
>>
>> - Healthcare management systems
>>
>> - ICT-based therapeutic systems
>>
>> - ICT-based rehabilitation technologies
>>
>> - Wearable health informatics
>>
>> - Emergent technologies for data analytics
>>
>> - Ambient Assisted Leaving (AAL)
>>
>> - Decision Support Systems
>>
>> - Emergent Technologies for Remote AAL Monitoring
>>
>> - Emergent Technologies and Accessibility
>>
>> - 5G for healthcare
>>
>> - Healthcare supply chain and logistics
>>
>> - Wireless Body Networks
>>
>> - Telemedicine and mobile telemedicine
>>
>> - Mobile Systems
>>
>> - Software Defined infrastructures
>>
>> -

Re: [Haskell] International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) - Extended Deadline 13 june 2021

[Ivan Perez]

Haskell mailing lists admins,

Can we please permanently ban everyone from the confscience.com domain?

Thanks,

Ivan



On Sat, 29 May 2021 at 15:44, Emilia Marc  wrote:

> Call for papers
>
> *
>
> International Conference on Informatics Revolution for Smarter Healthcare
> (IRSH 2021)
>
> Prague- Czech Republic, October 14-15, 2021
>
> https://confscience.com/irsh/
>
> All papers accepted in IRSH 2021 will be published in Springer CCIS
> (Communications in Computer and Information Science).
>
> CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical
> Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings
> Citation (Former ISI Proceedings)
>
> ***
>
> IMPORTANT DATES:
>
> - Paper Submission: June 13, 2021 (extended)
>
> - Acceptance Notification: July 1, 2021
>
> - Final Manuscript Due: September 1, 2021
>
> ***
>
> The IRSH 2021 conference will be held in Conjunction with:
>
> International Conference on Applied Data Science and Intelligence (ADSI
> 2021)
>
> International Conference on Recent Theories and Applications in
> Transportation and Mobility - (RTATM 2021)
>
> ***
>
> TOPICS:
>
> Authors are invited to submit their original papers to address the topics
> of the conference, including but not limited to:
>
> FUNDAMENTALS AND THEORIES
>
> - Interoperability and Data Integration
>
> - Confidentiality and Data Security
>
> - Data protection
>
> - Data Sharing
>
> - Security, Privacy, and Trust
>
> - Emergent healthcare standards
>
> - Emergent healthcare architectures
>
> - ICT, Ageing and Disability
>
> - Physiological and behavioural modelling
>
> - Pandemic and disease modeling
>
> - Usability and user experience of medical devices
>
> - Human behaviour
>
> - Clinical investigation regulatory frameworks
>
> - Integrated healthcare approaches
>
> - eHealth data standards and interoperability (e.g. HL7/FHIR)
>
> - Databases and data warehousing
>
> - Big Data and Open Data for healthcare
>
> - Design and Development of Methodologies for Healthcare
>
> - Emergent Communication Technologies
>
> - Real-time interaction theories
>
> - Emergent Technologies for Ambient Assisted Living
>
> - User Interface Design for healthcare
>
> - Sustainability
>
> - New approaches for accuracy and effectiveness
>
> - Data mining and bioinformatics
>
> - Enhanced living environments
>
> - Analysis and evaluation of healthcare systems
>
> INTELLIGENT HEALTHCARE
>
> - Pattern recognition and Machine
>
> - Learning for healthcare
>
> - Cognitive Informatics
>
> - Big Data in Healthcare
>
> - Wellbeing Informatics
>
> - Data Mining and Data Analytics
>
> - Data Visualization
>
> - Smart environments
>
> - Smart Ambient Assisted Living
>
> - Intelligent healthcare solutions
>
> - Agent-based solutions for healthcare
>
> - Collaboration systems
>
> - Intelligent Electronic Health Records
>
> - Internet of Things for healthcare
>
> - Cyber-Physical Systems for healthcare
>
> - Ambient Computing and Reasoning
>
> - Context Awareness
>
> - Smart devices for eldercare
>
> - Autonomy and active ageing
>
> - Emergent technologies for intelligent Computer Vision
>
> - Service production and delivery
>
> - Gamification
>
> - Multi-modal interaction
>
> - Computer-aided detection and diagnosis
>
> - Crowdsourcing for smarted healthcare
>
> SERVICES, SYSTEMS, AND INFRASTRUCTURES
>
> - Emergent healthcare services
>
> - Pervasive health systems and services
>
> - Remote healthcare management
>
> - Emergent healthcare infrastructure
>
> - Industry Revolution 4.0 for healthcare
>
> - eHealth
>
> - Electronic health records
>
> - Assistive technologies
>
> - Disease surveillance and patient monitoring systems
>
> - Prevention and detection systems
>
> - Home monitoring
>
> - Healthcare management systems
>
> - ICT-based therapeutic systems
>
> - ICT-based rehabilitation technologies
>
> - Wearable health informatics
>
> - Emergent technologies for data analytics
>
> - Ambient Assisted Leaving (AAL)
>
> - Decision Support Systems
>
> - Emergent Technologies for Remote AAL Monitoring
>
> - Emergent Technologies and Accessibility
>
> - 5G for healthcare
>
> - Healthcare supply chain and logistics
>
> - Wireless Body Networks
>
> - Telemedicine and mobile telemedicine
>
> - Mobile Systems
>
> - Software Defined infrastructures
>
> - Patient empowerment systems
>
> - Smart technology for remote patient visits
>
> - Biosensors
>
> - Medical devices
>
> APPLICATIONS
>
> - eHealth applications
>
> - Application of health informatics in clinical cases
>
> - Mobile technologies for healthcare applications
>
> - Software Systems in healthcare
>
> - Social networking and healthcare
>
> - Case Studies
>
> - Personalization and patient experience
>
> - 

Re: [Haskell] (Online) Utrecht Summer School on Advanced functional programming

[Ernesto Rodriguez]

Hi,

I just wanted to mention that I studied my MsC. degree at Utrecht
University and Prof. Swiestra was my thesis supervisor. I cannot recommend
this summer school enough. Not only are Prof. Swiestra's accomplishments
extraordinary (you can look that up online) but he is also very gifted at
teaching. I took many courses with him and were both interesting and
entertaining. Prof. Swiestra is also very patient and dedicated and I am
sure he will put a lot of care making sure his students thoroughly
understand the topics and ensuring the summer school is well organized and
structured. All other professors I had in Utrecht were excellent at
teaching so I believe this is a great opportunity to "shift up gears" in
the wonderful Haskell language.

Best regards,

Ernesto Rodriguez

On Thu, May 6, 2021 at 9:11 AM Swierstra, W.S. (Wouter) via Haskell <
haskell@haskell.org> wrote:

> SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING
>
> Online -  05-9 July 2021
>
>  http://www.afp.school
>
> # Call for Participation
>
> ## About
>
> The Advanced Functional Programming summer school has been running for
> more than ten years. We aim to educate aspiring Haskell programmers
> beyond the basic material covered by many textbooks.
>
> This year the course will be offered *online only*. A typical day will
> consist a 2-3 hours of lectures, sandwiched between supervised lab
> sessions. Lectures will be held in the (European) afternoon, but
> recordings will be made available if attending live is problematic.
>
> The lectures will cover several more advanced topics regarding
> programming with types in Haskell, including topics such as:
>
>* monads and applicative functors;
>* lambda calculus;
>* generalized algebraic datatypes;
>* datatype generic programming
>* type families and type-level programming;
>
> ## Lecturers
>
> Utrecht staff:
> * Gabriele Keller
> * Trevor McDonell
> * Wouter Swierstra
>
> ## Prerequisites
>
> We expect students to have a basic familiarity with Haskell
> already. You should be able to write recursive functions over
> algebraic data types, such as lists and trees. There is a great deal
> of material readily available that covers this material. If you've
> already started learning Haskell and are looking to take your
> functional programming skills to the next level, this is the course
> for you.
>
> Soft registration deadline: 1 June, 2021
> School: 05-09 July, 2021
>
> ## Costs
>
>50 euro - Registration fee
>
> We ask ask participants to pay a small registration fee to cover some
> of our organizational expenses. If this is problematic for you *for
> whatever reason*, please let us know and we can waive your
> registration fee.
>
> ## Further information
>
> Further information, including instructions on how to register, is
> available on our website:
>
>http://www.afp.school
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>


-- 
Ernesto Rodriguez

Masters Student
Computer Science
Utrecht University

www.netowork.me
github.com/netogallo
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Haskell.org nomination results

[Emily Pillmore]

Welcome aboard, Ida :)

On Wed, Feb 03, 2021 at 10:14 AM, Ryan Trinkle < r...@trinkle.org > wrote:

> 
> 
> 
> Great to meet you, Ida!
> 
> 
> On 2/3/21 9:57 AM, Alexandre ... wrote:
> 
> 
>> Hello people,
>> 
>> 
>> I'm here to announce the results for the Haskell. org ( http://haskell.org/
>> ) committee.
>> 
>> 
>> The final results are:
>> 
>> 
>> 
>> 
>> * Ida 5
>> * Ryan 5
>> * Tikhon 5
>> 
>> 
>> 
>> 
>> 
>> With no votes to anyone else. Ryan and Tikhon are renominated and Ida is a
>> new member. Welcome aboard, Ida.
>> 
>> 
>> Alexandre.
>> 
> 
>___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [ANNOUNCE] Glasgow Haskell Compiler 8.10.3 released

[Ben Gamari]

Shayne Fletcher  writes:

> On Sat, Dec 19, 2020 at 7:23 PM Ben Gamari  wrote:
>
>> Hello all,
>>
>> The GHC team is happy to announce the release of GHC 8.10.3. Source
>> and binary distributions are available at the usual place:
>>
>> https://downloads.haskell.org/ghc/8.10.3/
>
>
> Thanks!
>
> There doesn't seem to be a ghc-8.10.3-release tag in
> the g...@gitlab.haskell.org:ghc/ghc.git repository. Shouldn't there be?
>
Indeed. Fixed!

Cheers,

- Ben



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

Re: [Haskell] [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released

[Ben Gamari]

George Colpitts  writes:

> Hi Ben,
>
> What are the current plans / schedule for 9.0.1?
>
Hi George,

At the moment things are blocked on a solution to #17760, which I am
currently in the process of working through. There have been several
false-starts on this ticket and while the solution we are ending up with
is indeed a compromise (in both performance impact and convenience), I
am fairly convinced it is the best we can do.

I am waiting for a version of the patch to validate as we speak. As soon
as it (and a few other relevant patches) have been backported I will
move ahead with cutting the release candidate. I hope this can happen by
the end of the week.

Cheers,

- Ben


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

Re: [Haskell] [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released

[David Feuer]

Will this be updated to the latest containers before release? It's two
versions behind at the moment.

On Mon, Sep 28, 2020, 3:14 PM Ben Gamari  wrote:

> Hello all,
>
> The GHC team is very pleased to announce the availability of the first
> alpha release in the GHC 9.0 series. Source and binary distributions are
> available at the usual place:
>
> https://downloads.haskell.org/ghc/9.0.1-alpha1/
>
> This first alpha comes quite a bit later than expected. However, we have
> done a significant amount of testing on this pre-release and therefore
> hope to be able to move forward quickly with a release candidate next
> week and with a final release in mid-October.
>
> GHC 9.0.1 will bring a number of new features:
>
>  * A first cut of the new LinearTypes language extension [1], allowing
>use of linear function syntax and linear record fields.
>
>  * A new bignum library (ghc-bignum), allowing GHC to be more easily
>used with integer libraries other than GMP.
>
>  * Improvements in code generation, resulting in considerable
>performance improvements in some programs.
>
>  * Improvements in pattern-match checking, allowing more precise
>detection of redundant cases and reduced compilation time.
>
>  * Implementation of the "simplified subsumption" proposal [2]
>simplifying the type system and paving the way for QuickLook
>impredicativity in GHC 9.2.
>
>  * Implementation of the QualifiedDo extension [3], allowing more
>convenient overloading of `do` syntax.
>
>  * Improvements in compilation time.
>
> And many more. See the release notes [4] for a full accounting of the
> changes in this release.
>
> Do note that there are a few things that we expect will change before
> the final release:
>
>  * We expect to sort out a notarization workflow for Apple Darwin,
>allowing our binary distributions to be used on macOS Catalina
>without hassle.
>
>Until this has been sorted out Catalina users can exempt the
>current macOS binary distribution from the notarization requirement
>themselves by running `xattr -cr .` on the unpacked tree before
>running `make install`.
>
>  * We will likely transition the Alpine binary distribution to be fully
>statically-linked, providing a convenient, distribution-independent
>packaging option for Linux users.
>
>  * We will be merging a robust solution for #17760 which will introduce
>a new primitive, `keepAlive#`, to the `base` library, subsuming
>most uses of `touch#`.
>
> As always, do test this release and open tickets for whatever issues you
> encounter. To help with this, we will be publishing a blog post
> describing use of our new `head.hackage` infrastructure to ease testing
> of larger projects with Hackage dependencies later this week.
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
> [2]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
> [3]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
> [4]
> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Haskell tutors required!

[Philip Wadler]

Yes, you've located last year's syllabus! Go well, -- P

.   \ Philip Wadler, Professor of Theoretical Computer Science,
.   /\ School of Informatics, University of Edinburgh
.  /  \ and Senior Research Fellow, IOHK
. http://homepages.inf.ed.ac.uk/wadler/



On Tue, 8 Sep 2020 at 21:20, Howard B. Golden 
wrote:

> Hi, I am intrigued by the opportunity, but I wonder if I am up to the
> task. To help me decide, I have this question: Is the syllabus for the
> course similar to the most recent presentation (
> https://www.learn.ed.ac.uk/webapps/blackboard/content/listContent.jsp?course_id=_73477_1&content_id=_3873901_1
> )?
>
> Best regards,
> Howard
>
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Haskell tutors required!

[Howard B. Golden]

Hi, I am intrigued by the opportunity, but I wonder if I am up to the task.
To help me decide, I have this question: Is the syllabus for the course
similar to the most recent presentation (
https://www.learn.ed.ac.uk/webapps/blackboard/content/listContent.jsp?course_id=_73477_1&content_id=_3873901_1
)?

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

Re: [Haskell] [ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released

[Ben Gamari]

Ben Gamari  writes:

> Hello all,
>
> The GHC team is happy to announce the availability of GHC 8.10.1. Source
> and binary distributions are available at the usual place:
>
> https://downloads.haskell.org/ghc/8.10.1/

Note that the release notes can be found here:


https://downloads.haskell.org/ghc/8.10.1/docs/html/users_guide/8.10.1-notes.html

Further, the migration guide can be found here:

https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/8.10

Cheers,

- Ben


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

Re: [Haskell] Haskell Digest, Vol 199, Issue 5

[Rishiyur Nikhil]

Deepest condolences on the passing of Doaitse Swierstra.
I did not know him personally but knew of his work in functional
programming.

Rishiyur Nikhil

On Wed, Mar 11, 2020 at 8:01 AM  wrote:

> Send Haskell mailing list submissions to
> haskell@haskell.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
> or, via email, send a message with subject or body 'help' to
> haskell-requ...@haskell.org
>
> You can reach the person managing the list at
> haskell-ow...@haskell.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Haskell digest..."
> Today's Topics:
>
>1. Sad news (Wouter Swierstra)
>
>
>
> -- Forwarded message --
> From: Wouter Swierstra 
> To: haskell@haskell.org
> Cc:
> Bcc:
> Date: Tue, 10 Mar 2020 14:42:42 +0100
> Subject: [Haskell] Sad news
> Dear all,
>
> With a heavy heart, I would like to inform you that Doaitse
> Swierstra passed away last week. After a period of illness over
> the last half year, he had an unfortunate fall at home that
> ultimately proved to be fatal.
>
> Doaitse was a remarkable character and a passionate advocate for
> functional programming. I'm sure many of us have fond memories
> of Doaitse. He will be sorely missed.
>
>   Wouter
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Fwd: [GitHub] You've been removed from the Haskell organization

[Jasper Van der Jeugt]

Hi Dominic,

My apologies.

There was a proposal about making a plan to clean up the Haskell
organisation on GitHub at some point; but it wasn't supposed to happen
now or like this at all (and definitely not without communication
& agreement of the people involved!) -- it seems someone was a bit
too trigger happy.  I've added you back now and will figure how this
happened.

Warm regards
Jasper

On Wed, Mar 11, 2020 at 03:54:55PM +, domi...@steinitz.org wrote:
> Can someone tell me why I have been removed from the Haskell organisation?
> 
> Many thanks
> 
> Dominic Steinitz
> domi...@steinitz.org
> http://idontgetoutmuch.org
> Twitter: @idontgetoutmuch
> 
> 
> > Begin forwarded message:
> > 
> > From: GitHub 
> > Subject: [GitHub] You've been removed from the Haskell organization
> > Date: 11 March 2020 at 15:53:24 GMT
> > To: idontgetoutmuch 
> > 
> >    
> > You have been removed from the @Haskell 
> > organization
> > 
> > Hi @idontgetoutmuch,
> > You’ve been removed from the Haskell organization.
> > Manage your GitHub email preferences 
> > Terms  • Privacy 
> >  • Log in to 
> > GitHub 
> >  
> > GitHub, Inc.
> > 88 Colin P Kelly Jr Street
> > San Francisco, CA 94107
> 

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

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

Re: [Haskell] [Haskell-cafe] Supporting Haskell.org

[Akhra Gannon]

haskell.org is also an available charity for smile.amazon.com purchases!

On Tue, Dec 24, 2019, 4:21 PM Tikhon Jelvis  wrote:

> A significant part of the Haskell community infrastructure—including the
> haskell.org website, Hackage, Hoogle and the build infrastructure for
> GHC—runs on donations from the Haskell community administered
> by Haskell.org.
>
> Haskell.org also organizes Haskell's participation in the Google Summer of
> Code program. We had 18 projects this year, 15 of which were completed
> successfully, a solid completion ratio.
>
> If you would like to support Haskell.org, you can donate via several
> methods including PayPal and check:
>
> https://wiki.haskell.org/Donate_to_Haskell.org
>
> Haskell.org can also accept donations through employers via Benevity
> using the unique ID 475236502.
>
> Haskell.org is a 501(c)(3) non-profit, so donations may be tax-deductible
> in your jurisdiction.
>
> We look forward to continuing this work with your support in 2020 as well
> as exploring new projects to improve the Haskell community infrastructure.
>
> Best wishes, Tikhon Jelvis on behalf of the haskell.org committee.
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: mmsyn7ukr -- a A program and a library that can be used as a simple basic interface to some SoX functionality or for producing the approximately Ukrainian speech with your own

[olexandr543--- via Haskell]

 Hello,
Ivan, your understanding is correct. But you can use it in a more creative 
manner. Please, see the updated documentation (README).
Best regards,Oleksandr Zhabenko.

четвер, 19 грудня 2019 р., 14:11:41 GMT+1, Ivan Perez 
 написав:  
 
 Nice :)
Without knowing much about the specifics of this, but more as a (permanent) 
student of Ukrainian language, I'm happy to see anything involving Ukrainian :)

My vague understanding when reading the above is that, through this, I can 
provide my voice, plus some text in ukrainian, and it is read in ukrainian with 
my voice.
Is that correct?

Ivan


On Wed, 18 Dec 2019 at 19:04, olexandr543--- via Haskell  
wrote:

Hello, 
There is a new program -- mmsyn7ukr. 

| 
| 
|  | 
mmsyn7ukr: A simple basic interface to some SoX functionality or the app...

Install via `cabal install mmsyn7ukr`.
 |

 |

 |

It can be used as a simple 
basic interface to some SoX functionality or for producing 
the approximately Ukrainian speech with your own recorded 
voice.

The program starts with Caution to be responsible for usage 
and to use it personally. Then the program guides you 
through the creating and using your Ukrainian \"voice\". 
Please, use it carefully. After the execution the program if 
terminated naturally without interruption removes (cleans) 
all the created sound files in the current directory for 
security reasons. If it terminates by interruption or in 
general it is a good practice to remove the current 
directory sound files manually.
Best regards,Oleksandr Zhabenko.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

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

Re: [Haskell] ANNOUNCE: mmsyn7ukr -- a A program and a library that can be used as a simple basic interface to some SoX functionality or for producing the approximately Ukrainian speech with your own

[Ivan Perez]

Nice :)

Without knowing much about the specifics of this, but more as a (permanent)
student of Ukrainian language, I'm happy to see anything involving
Ukrainian :)

My vague understanding when reading the above is that, through this, I can
provide my voice, plus some text in ukrainian, and it is read in ukrainian
with my voice.

Is that correct?

Ivan


On Wed, 18 Dec 2019 at 19:04, olexandr543--- via Haskell <
haskell@haskell.org> wrote:

> Hello,
>
> There is a new program -- mmsyn7ukr
> .
>
> mmsyn7ukr: A simple basic interface to some SoX functionality or the app...
>
> Install via `cabal install mmsyn7ukr`.
> 
>
> It can be used as a simple
> basic interface to some SoX functionality or for producing
> the approximately Ukrainian speech with your own recorded
> voice.
>
> The program starts with Caution to be responsible for usage
> and to use it personally. Then the program guides you
> through the creating and using your Ukrainian \"voice\".
> Please, use it carefully. After the execution the program if
> terminated naturally without interruption removes (cleans)
> all the created sound files in the current directory for
> security reasons. If it terminates by interruption or in
> general it is a good practice to remove the current
> directory sound files manually.
>
>
> Best regards,
> Oleksandr Zhabenko.
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [FP] Postdoc position at University of Bristol in functional programming

[Meng Wang]

Dear Haskellers,

The programming languages group at Bristol has an open post doc position in the 
area of functional programming.
Haskell programmers are particularly welcome.
Please pass it on to anyone who might be interested. Thanks!

Best regards,
Meng

Meng Wang, PhD (Oxon)
Senior Lecturer (Associate Professor)
Department of Computer Science
University of Bristol
Merchant Venturers Building,
Woodland Road, Clifton BS8 1UB
+44 (0) 117 954 5145
meng.w...@bristol.ac.uk


We are looking for an enthusiastic, self-motivated individual to
contribute to an EPSRC-funded project, which aims to design
programming languages that guarantee strong properties, and the
application of them.

The post holder will be based in the programming languages group at
the University of Bristol Computer Science Department, which consists
of three academics, two PDRAs, and a number of PhD students. You will
also be working with a network of partners from Oxford, Edinburgh,
Tohoku Japan, Chalmers Sweden, and industrial partner DFINITY
Foundations providing expertise on WebAssembly.

You should have a PhD in programming languages, or a closely related
field.

This post is available immediately and is offered on a full-time based
for an initial term of three years. Appointment at a higher salary
point than grade I is possible based on relevant experience.

Informal enquiries should be addressed to Dr. Meng Wang
(meng.w...@bristol.ac.uk)

For more details about this position, please see:
http://www.bristol.ac.uk/jobs/find/details.html?nPostingID=57894&nPostingTargetID=171215&option=28&sort=DESC&respnr=1&ID=Q50FK026203F3VBQBV7V77V83&JobNum=ACAD104298&Resultsperpage=10&lg=UK&mask=uobext

Deadline: 25 November 2019


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

Re: [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[olexandr543--- via Haskell]

 I did not check the code for 'case ... of ...' constuction in GHC, my 
intention comes from the explanations how this construction works in Haskell in 
some teaching materials.So, definitely I should do more exploratory work. 
Nevertheless, the type signatures and sorting is realized for rather general 
situation and can be therefore preferable for some situations.
Best regards,Oleksandr Zhabenko.

субота, 21 вересня 2019 р., 21:07:25 GMT+2, Олександр Жабенко 
 написав:  
 
  I did not check the code for 'case ... of ...' constuction in GHC, my 
intention comes from the explanations how this construction works in Haskell in 
some teaching materials.So, definitely I should do more exploratory work. 
Nevertheless, the type signatures and sorting is realized for rather general 
situation and can be therefore preferable for some situations.
Best regards,Oleksandr Zhabenko.
субота, 21 вересня 2019 р., 20:59:03 GMT+2, olexandr...@yahoo.com 
 написав:  
 
  Yes, you can use IntMap. It needs another dependency and the complexity 
choice as O(log (min (n, W))) where W is a number of bits in a representing 
key, used for mapping. 
For me, it is rather hard to solve whether it can be better, because it raises 
another problem of efficient binary representation of the keys.
While working on the topic, I found out that may be the most efficient will be 
hashing (for lookup it can be used e. g. Cuckoo hashing) and there is a library 
in Haskell for it.Data.HashTable.IO Using it, you can write something like:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.HashTable.IO as I
import Data.Maybe (fromJust,isJust)
import System.Environment (getArgs)
main :: IO ()
main = do          args <- getArgs         let a = [([z,t],x) | x <- 
['a'..'d'], z <- ['f'..'t'], t <- ['a'..'p'], [x,z,t] <= "fnf"]          b :: 
I.CuckooHashTable String Char <- I.fromList a          c <- I.lookup b ("kn")   
       let d1 u = do                   d <- I.lookup b u                  print 
c                  if isJust d                     then putStrLn . show . 
fromJust $ d                     else putStrLn "Nothing"                  
return ()          if null args            then d1 "fa"           else d1 (head 
$ args)


| 
| 
|  | 
Data.HashTable.IO


 |

 |

 |


so it works. And the library documentation says that a complexity of Cuckoo 
hash lookup is about O(1), but with hashing there are questions of ratio of 
fulfilling the buckets and collisions.
So, my library having the very generic constraints can be used instead.
Best regards,Oleksandr Zhabenko.

субота, 21 вересня 2019 р., 21:52:18 GMT+3, olexandr...@yahoo.com 
 написав:  
 
  Yes, you can. It needs another dependency and the complexity choice as O(log 
(min (n, W))) where W is a number of bits in a representing key, used for 
mapping. For me, it is rather hard to solve whether it can be better, because 
it raises another problem of efficient binary representation of the keys.
While working on the topic, I found out that may be the most efficient will be 
hashing (for lookup it can be used e. g. Cuckoo hashing) and there is a library 
in Haskell for it.Data.HashTable.IO Using it, you can write something like:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.HashTable.IO as I
import Data.Maybe (fromJust,isJust)
import System.Environment (getArgs)
main :: IO ()
main = do          args <- getArgs         let a = [([z,t],x) | x <- 
['a'..'d'], z <- ['f'..'t'], t <- ['a'..'p'], [x,z,t] <= "fnf"]          b :: 
I.CuckooHashTable String Char <- I.fromList a          c <- I.lookup b ("kn")   
       let d1 u = do                   d <- I.lookup b u                  print 
c                  if isJust d                     then putStrLn . show . 
fromJust $ d                     else putStrLn "Nothing"                  
return ()          if null args            then d1 "fa"           else d1 (head 
$ args)


| 
| 
|  | 
Data.HashTable.IO


 |

 |

 |


so it works. And the library documentation says that a complexity of Cuckoo 
hash lookup is about O(1), but with hashing there are questions of ratio of 
fulfilling the buckets and collisions.
So, my library having the very generic constraints can be used instead.
Best regards,Oleksandr Zhabenko.


субота, 21 вересня 2019 р., 21:34:38 GMT+3, Henning Thielemann 
 написав:  
 
 
On Sat, 21 Sep 2019, olexandr543--- via Haskell wrote:

> My library that can help to optimize using 'case ... of ...' construction if 
> there are multiple (more than at
> least 5) variants.
> mm2: The library that can be used for optimization of multiple (Ord a) => a 
> -> b transformations

Isn't this a problem you would solve using Data.Map?
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[olexandr543--- via Haskell]

 Yes, you can use IntMap. It needs another dependency and the complexity choice 
as O(log (min (n, W))) where W is a number of bits in a representing key, used 
for mapping. 
For me, it is rather hard to solve whether it can be better, because it raises 
another problem of efficient binary representation of the keys.
While working on the topic, I found out that may be the most efficient will be 
hashing (for lookup it can be used e. g. Cuckoo hashing) and there is a library 
in Haskell for it.Data.HashTable.IO Using it, you can write something like:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.HashTable.IO as I
import Data.Maybe (fromJust,isJust)
import System.Environment (getArgs)
main :: IO ()
main = do          args <- getArgs         let a = [([z,t],x) | x <- 
['a'..'d'], z <- ['f'..'t'], t <- ['a'..'p'], [x,z,t] <= "fnf"]          b :: 
I.CuckooHashTable String Char <- I.fromList a          c <- I.lookup b ("kn")   
       let d1 u = do                   d <- I.lookup b u                  print 
c                  if isJust d                     then putStrLn . show . 
fromJust $ d                     else putStrLn "Nothing"                  
return ()          if null args            then d1 "fa"           else d1 (head 
$ args)


| 
| 
|  | 
Data.HashTable.IO


 |

 |

 |


so it works. And the library documentation says that a complexity of Cuckoo 
hash lookup is about O(1), but with hashing there are questions of ratio of 
fulfilling the buckets and collisions.
So, my library having the very generic constraints can be used instead.
Best regards,Oleksandr Zhabenko.

субота, 21 вересня 2019 р., 21:52:18 GMT+3, olexandr...@yahoo.com 
 написав:  
 
  Yes, you can. It needs another dependency and the complexity choice as O(log 
(min (n, W))) where W is a number of bits in a representing key, used for 
mapping. For me, it is rather hard to solve whether it can be better, because 
it raises another problem of efficient binary representation of the keys.
While working on the topic, I found out that may be the most efficient will be 
hashing (for lookup it can be used e. g. Cuckoo hashing) and there is a library 
in Haskell for it.Data.HashTable.IO Using it, you can write something like:
{-# LANGUAGE ScopedTypeVariables #-}
module Main where
import qualified Data.HashTable.IO as I
import Data.Maybe (fromJust,isJust)
import System.Environment (getArgs)
main :: IO ()
main = do          args <- getArgs         let a = [([z,t],x) | x <- 
['a'..'d'], z <- ['f'..'t'], t <- ['a'..'p'], [x,z,t] <= "fnf"]          b :: 
I.CuckooHashTable String Char <- I.fromList a          c <- I.lookup b ("kn")   
       let d1 u = do                   d <- I.lookup b u                  print 
c                  if isJust d                     then putStrLn . show . 
fromJust $ d                     else putStrLn "Nothing"                  
return ()          if null args            then d1 "fa"           else d1 (head 
$ args)


| 
| 
|  | 
Data.HashTable.IO


 |

 |

 |


so it works. And the library documentation says that a complexity of Cuckoo 
hash lookup is about O(1), but with hashing there are questions of ratio of 
fulfilling the buckets and collisions.
So, my library having the very generic constraints can be used instead.
Best regards,Oleksandr Zhabenko.


субота, 21 вересня 2019 р., 21:34:38 GMT+3, Henning Thielemann 
 написав:  
 
 
On Sat, 21 Sep 2019, olexandr543--- via Haskell wrote:

> My library that can help to optimize using 'case ... of ...' construction if 
> there are multiple (more than at
> least 5) variants.
> mm2: The library that can be used for optimization of multiple (Ord a) => a 
> -> b transformations

Isn't this a problem you would solve using Data.Map?
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[Bryon Tjanaka]

At any rate, using binary search doesn’t automatically guarantee faster
runtime. Constant factors can add up, and there might not even be enough
elements to warrant binary search. Benchmarking on realistic data is
definitely a good idea.

On Sat, Sep 21, 2019 at 11:39 AM David Feuer  wrote:

> Case matching is already optimized in GHC. There might be ways to improve
> it, but it already uses binary search and/or jump tables to improve
> performance when there are many branches.
>
> On Sat, Sep 21, 2019, 8:59 AM olexandr543--- via Haskell <
> haskell@haskell.org> wrote:
>
>> Hello!
>>
>> My library that can help to optimize using 'case ... of ...' construction
>> if there are multiple (more than at least 5) variants.
>> mm2: The library that can be used for optimization of multiple (Ord a) =>
>> a -> b transformations 
>>
>> Best regards,
>> Oleksandr Zhabenko.
>>
>>
>> ___
>> Haskell mailing list
>> Haskell@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
-- 

[image: logo]

Bryon Tjanaka

*"Audentes fortuna iuvat"*
btjanaka.netgithub.com/btjanaka
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[Georgi Lyubenov]

case_of_ in Haskell should be constant - Your constructors are ints, you
know in advance how many there are, so you can just jump with an offset? (I
haven't actually checked this, but it doesn't seem unreasonable to me, that
this would be the implementation)

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

Re: [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[David Feuer]

Case matching is already optimized in GHC. There might be ways to improve
it, but it already uses binary search and/or jump tables to improve
performance when there are many branches.

On Sat, Sep 21, 2019, 8:59 AM olexandr543--- via Haskell <
haskell@haskell.org> wrote:

> Hello!
>
> My library that can help to optimize using 'case ... of ...' construction
> if there are multiple (more than at least 5) variants.
> mm2: The library that can be used for optimization of multiple (Ord a) =>
> a -> b transformations 
>
> Best regards,
> Oleksandr Zhabenko.
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[olexandr543--- via Haskell]

 Hello!
Matthew, no, I don't benchmark this library, it should be more sufficient 
theoretically because it uses binary search rather than linear, and the first 
one is known to be more efficient. I used the similar technique for writing 
code for my project mm1. There I firstly used case but then manually made 
optimization using case and guards and if-then-else. You can see it for 
different releases for mm1. The manually optimized program being added 
additional functionality after optimizing were a little more efficient, but it 
should be mentioned that most time while it is running the espeak and sox being 
worked, so I think it should be more efficient for such situations. 

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
OleksandrZhabenko/mm1

Program that reads Ukrainian text using eSpeak and SoX. - OleksandrZhabenko/mm1
 |

 |

 |



I can try to do benchmarking, but it needs some time in advance.
Thank you for your advice!
Best regards,Oleksandr Zhabenko.

субота, 21 вересня 2019 р., 21:26:35 GMT+3, Олександр Жабенко 
 написав:  
 
  Hello!
Matthew, no, I don't benchmark this library, it should be more sufficient 
theoretically because it uses binary search rather than linear, and the first 
one is known to be more efficient. I used the similar technique for writing 
code for my project mm1. There I firstly used case but then manually made 
optimization using case and guards and if-then-else. You can see it for 
different releases for mm1. The manually optimized program being added 
additional functionality after optimizing were a little more efficient, but it 
should be mentioned that most time while it is running the espeak and sox being 
worked, so I think it should be more efficient for such situations. 

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
OleksandrZhabenko/mm1

Program that reads Ukrainian text using eSpeak and SoX. - OleksandrZhabenko/mm1
 |

 |

 |



I can try to do benchmarking, but it needs some time in advance.
Thank you for your advice!
Best regards,Oleksandr Zhabenko.

субота, 21 вересня 2019 р., 20:04:32 GMT+2, olexandr...@yahoo.com 
 написав:  
 
   Hello!
Matthew, no, I don't benchmark this library, it should be more sufficient 
theoretically because it uses binary search rather than linear, and the first 
one is known to be more efficient. I used the similar technique for writing 
code for my project mm1. There I firstly used case but then manually made 
optimization using case and guards and if-then-else. You can see it for 
different releases for mm1. The manually optimized program being added 
additional functionality after optimizing were a little more efficient, but it 
should be mentioned that most time while it is running the espeak and sox being 
worked, so I think it should be more efficient for such situations. 

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
OleksandrZhabenko/mm1

Program that reads Ukrainian text using eSpeak and SoX. - OleksandrZhabenko/mm1
 |

 |

 |



I can try to do benchmarking, but it needs some time in advance.
Thank you for your advice!
Best regards,Oleksandr Zhabenko.


субота, 21 вересня 2019 р., 15:46:38 GMT+2, Matthew Pickering 
 написав:  
 
 Have you benchmarked this library? 
I don't see how using a vector can be any faster than using a case.
On Sat, 21 Sep 2019, 14:00 olexandr543--- via Haskell,  
wrote:

Hello!
My library that can help to optimize using 'case ... of ...' construction if 
there are multiple (more than at least 5) variants.mm2: The library that can be 
used for optimization of multiple (Ord a) => a -> b transformations
Best regards,Oleksandr Zhabenko.

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

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

Re: [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations

[Matthew Pickering]

Have you benchmarked this library?

I don't see how using a vector can be any faster than using a case.

On Sat, 21 Sep 2019, 14:00 olexandr543--- via Haskell, 
wrote:

> Hello!
>
> My library that can help to optimize using 'case ... of ...' construction
> if there are multiple (more than at least 5) variants.
> mm2: The library that can be used for optimization of multiple (Ord a) =>
> a -> b transformations 
>
> Best regards,
> Oleksandr Zhabenko.
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Numeric] Announce: comfort-array, lapack

[dominic]

Hi Ben,

I am intrigued. What application do you have in mind?

Dominic.
Dominic Steinitz
domi...@steinitz.org
http://idontgetoutmuch.org
Twitter: @idontgetoutmuch


> On 27 May 2019, at 22:34, Ben Gamari  wrote:
> 
> Henning Thielemann  writes:
> 
>> I like two announce two of my packages:
>> 
>> 1. comfort-array
>> http://hackage.haskell.org/package/comfort-array
>> 
>> It provides Boxed and Storable arrays with very liberal shape definitions. 
>> You may use ranges of indices like in 'array' or zero-based indexing like 
>> in 'repa', but you can also use arbitrary index Sets, enumerations, 
>> concatenation of arrays and more. E.g. an array with (Shape.Enumeration 
>> Ordering) has three elements with indices LT, EQ, GT.
>> 
> Very nice. I have long wanted something like this. Thanks Henning!
> 
> Cheers,
> 
> - Ben
> ___
> Numeric mailing list
> nume...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/numeric

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

Re: [Haskell] [Numeric] Announce: comfort-array, lapack

[Ben Gamari]

Henning Thielemann  writes:

> I like two announce two of my packages:
>
> 1. comfort-array
> http://hackage.haskell.org/package/comfort-array
>
> It provides Boxed and Storable arrays with very liberal shape definitions. 
> You may use ranges of indices like in 'array' or zero-based indexing like 
> in 'repa', but you can also use arbitrary index Sets, enumerations, 
> concatenation of arrays and more. E.g. an array with (Shape.Enumeration 
> Ordering) has three elements with indices LT, EQ, GT.
>
Very nice. I have long wanted something like this. Thanks Henning!

Cheers,

- Ben


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

Re: [Haskell] [Haskell-cafe] Apply Haskell at scale in a music start-up

[Jeroen Bransen]

If you are interested in working at Chordify, please have a look at:
https://jobs.chordify.net/

The advert in the link seems to indicate the job is based in the
Netherlands. Does Chordify accept remote work as well?

*

Chordify is based in the Netherlands, and not everyone who would like to 
work at Chordify can or is willing to relocate to this nice, but 
relatively rainy part of the world. Therefore, you are not the first 
person to ask whether working remotely is an option.



We have do not have principal reasons to reject remote working, but 
having two offices in the Netherlands, and using all digital means 
available to streamline our communication, our experience is that 
nothing beats face-to-face contact. Also, we really try to make our 
office a pleasant and fun place, and we believe it adds value to be part 
of our office culture.



Therefore, we prefer working in our office over working remotely. That 
said, working part-time or working from home is something that we do on 
a regular basis.


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

Re: [Haskell] Guidelines for respectful communication

[Philippa Cowderoy]

There is a wide spectrum of bad faith behaviour. It may be simply not 
caring if one causes harm ("recklessness", if you like), through 
attempts to undermine the culture of a space or community, to attempts 
to cause people material harm.


The wider Haskell community has witnessed all of these, even if not 
everyone is sufficiently aware of it. On the "material harm" end of the 
spectrum, an incident in 2016 grew sufficiently infamous that friends 
with no connections to the FP community in general, computer science or 
the computing industry were sending me messages of sympathy and support 
- and I was forced to take some "opsec" measures to safeguard both 
myself and others.


The nature of both this spectrum and of bad faith makes this a difficult 
problem to deal with and one that mustn't be oversimplified - not all 
acts are equal and the cultural impacts are complex. But people acting 
in bad faith - some of them persistently and possibly even with a degree 
of coordination - is indeed the root problem I'm highlighting.


Thanks for your time and effort on this,

Philippa

On 09/12/2018 18:03, Richard Eisenberg wrote:
What this email seems to suggest to me is that our guidelines assume 
good faith, and yet some participants act in bad faith. I agree this 
is not well accounted-for in the guidelines. (However, the guidelines 
were designed with the GHC Steering Committee in mind, where members 
join by way of a nomination and selection process and can be removed 
-- quite unlike the broader Haskell community.)


Before thinking about specific words / documents that solve the 
problem, I want to be sure I understand the problem you're 
highlighting. Is it the presence of bad faith actors, specifically?


Thanks for coming forward with these concerns.

Richard

On Dec 6, 2018, at 4:59 PM, Philippa Cowderoy > wrote:


I lack the energy to contribute to GHC directly, but these guidelines 
are far too easy to abuse by someone acting in bad faith and we know 
that bad faith actors have been adjacent to our community and acted 
on things that have taken place within it.


From where I'm sitting, guidelines like this risk doing even more 
damage than not having any. Not only do they lack the means to handle 
incidents that have already occurred, they actively discourage the 
community from finding those means.


As someone these guidelines have been drafted to help include, I fear 
they increase the burden on my participation and that of others like 
me. For a community to hold together without sinking to the worst of 
behaviour, there needs to be some acceptance that we will all fail to 
act in good fatih on occasion, that some people will act in bad faith 
and that behaviour in bad faith may take a great deal of explaining 
to anyone who is not the target of it or familiar with its mechanisms.


I have spent a great deal of time running spaces within the wider 
community and I have witnessed these things repeatedly. I also lack 
the resources some people here have available to mitigate the risks 
others have openly posed to members of the community including myself 
and Simon.


One solution - whether GHC itself needs it or not - might be to pair 
guidelines for respectful communication with guidelines for when 
respectful communication is failing to occur.


Simon, I appreciate both the work you've put in and your love for the 
communty. I hope you can appreciate that where I appear to be cynical 
or even sowing discord here, I am acting out of love and care for a 
community that at its best has done a great deal for me. I apologise 
for being the one to open up what I see as a somewhat inevitable 
discussion.


On 06/12/2018 10:35, Simon Peyton Jones via Haskell wrote:

Friends
As many of you will know, I have been concerned for several years about the standards 
of discourse in the Haskell community.  I think things have improved since the period 
that drove me to write my Respect 
email, 
but it's far from secure.
We discussed this at a meeting of the GHC Steering 
Committee  at ICFP in 
September, and many of us have had related discussions since.  Arising out of that 
conversation, the GHC Steering Committee has decided to adopt these
   Guidelines for respectful 
communication

We are not trying to impose these guidelines on members of the Haskell 
community generally. Rather, we are adopting them for ourselves, as a signal 
that we seek high standards of discourse in the Haskell community, and are 
willing to publicly hold ourselves to that standard, in the hope that others 
may choose to follow suit.
We are calling them "guidelines for respectful communication" rather than a "code of 
conduct", because we want to encourage good communication, rather than focus on bad behavio

Re: [Haskell] Guidelines for respectful communication

[Jean-Marie Gaillourdet]

Hi

On 10.12.18 12:12, Alex Silva wrote:

On 10/12/2018 12:06, Jerzy Karczmarczuk wrote:
The intelligence is crucial here. It is not democratically distributed 
[[my goodness, am I already insulting people?!]], so we will always 
need Constitutions, Catechisms, sportmanship rules, etc., even without 
the accompanying  "criminal codes".  The text of Simon is NOT a 
proposal to introduce  Haskell Inquisition.




You are assuming that intelligent people cannot act in bad faith, which 
is neither true in this community or in general.


That is your interpretation, he could also assume that intelligent 
people usually know better than to behave badly in technical forums --- 
and elsewhere.


Regards,
Jean-Marie


--
Bunkyo-Ku-Straße 1a
67663 Kaiserslautern
j...@gaillourdet.net
+49 176 10 6321 04
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Guidelines for respectful communication

[Alex Silva]

Hi,

On 10/12/2018 12:06, Jerzy Karczmarczuk wrote:
The intelligence is crucial here. It is not democratically distributed 
[[my goodness, am I already insulting people?!]], so we will always need 
Constitutions, Catechisms, sportmanship rules, etc., even without the 
accompanying  "criminal codes".  The text of Simon is NOT a proposal to 
introduce  Haskell Inquisition.




You are assuming that intelligent people cannot act in bad faith, which 
is neither true in this community or in general.


Cheers,
--
- alex
https://unendli.ch/
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Guidelines for respectful communication

[Jerzy Karczmarczuk]

Le 09/12/2018 à 19:03, Richard Eisenberg a écrit :

What this email seems to suggest to me is that our guidelines assume 
good faith, and yet some participants act in bad faith. I agree this 
is not well accounted-for in the guidelines.

...

I don't really think that Philippa Cowderoy's warning
/... guidelines like this risk doing even more damage than not having 
any. Not only do they lack the means to handle incidents that have 
already occurred, they actively discourage the community from finding 
those means.

/
points to a true danger. Teaching a "correct" behaviour is anyway a 
never-ending process.
Although I have seen a good deal of nastiness on the Web, practically 
never related to Haskell. There have been some doctrinal, not very 
serious disputes, occasionally an X or Y had too much adrenaline, but 
the true bad faith is something at most marginal. Perhaps the reason is 
-- I cite Simon: /The Haskell community is such a rich collection of 
*intelligent*, passionate, and committed people/.
The intelligence is crucial here. It is not democratically distributed 
[[my goodness, am I already insulting people?!]], so we will always need 
Constitutions, Catechisms, sportmanship rules, etc., even without the 
accompanying  "criminal codes".  The text of Simon is NOT a proposal to 
introduce  Haskell Inquisition.


In the context of the Haskell community, spending time on prevention & 
punishment of potential bad faith seems to me a bit horrible.


Ben Lippmeier says
/The way I see it, guidelines for Respectful Communication are 
statements of the desired end goal, but they don’t provide much 
insight as to the root causes of the problems, or how to address them. 
At the risk of trivialising the issue, one could reduce many such 
statements to “Can everyone please stop shouting and be nice to each 
other.”/
It is true  that most etiquette rules, as vestimentary  codes, etc. are 
somehow superficial, but the "root causes of the problem" may be 
terribly complicated. It is possible to degenerate a communication 
system without shouting or being manifestly brutal/impolite, and here 
and there the wish to be '/effective/' wins over the diplomacy.


Some of my students stopped  asking questions on the Stack Overflow 
forum because of that, and there are many other places avoided by 
newbies, by fragile people... Sending people away because of 
(apparently; often not so) duplicate questions, "downvoting", forming 
casts of power-enabled "gurus", who behave disrespectfully, since they 
are gurus, issuing statements such as: "read /some/ tutorial, and /then/ 
come back", etc., all this exists, may trigger angry answers, but does 
not implies bad faith (although too often signals somehow weak knowledge 
of psychology).


Let's be optimistic. I think that it would do a favour for the [larger] 
community, if Simon agreed to send the guidelines to haskell-cafe (and 
perhaps to some forum outside Haskell as well), I knew many people (my 
former students for example), who read only the  -café list...


Live long and prosper.  🖖
Jerzy Karczmarczuk
[France.]
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Guidelines for respectful communication

[Richard Eisenberg]

What this email seems to suggest to me is that our guidelines assume good 
faith, and yet some participants act in bad faith. I agree this is not well 
accounted-for in the guidelines. (However, the guidelines were designed with 
the GHC Steering Committee in mind, where members join by way of a nomination 
and selection process and can be removed -- quite unlike the broader Haskell 
community.)

Before thinking about specific words / documents that solve the problem, I want 
to be sure I understand the problem you're highlighting. Is it the presence of 
bad faith actors, specifically?

Thanks for coming forward with these concerns.

Richard

> On Dec 6, 2018, at 4:59 PM, Philippa Cowderoy  wrote:
> 
> I lack the energy to contribute to GHC directly, but these guidelines are far 
> too easy to abuse by someone acting in bad faith and we know that bad faith 
> actors have been adjacent to our community and acted on things that have 
> taken place within it.
> 
> From where I'm sitting, guidelines like this risk doing even more damage than 
> not having any. Not only do they lack the means to handle incidents that have 
> already occurred, they actively discourage the community from finding those 
> means.
> 
> As someone these guidelines have been drafted to help include, I fear they 
> increase the burden on my participation and that of others like me. For a 
> community to hold together without sinking to the worst of behaviour, there 
> needs to be some acceptance that we will all fail to act in good fatih on 
> occasion, that some people will act in bad faith and that behaviour in bad 
> faith may take a great deal of explaining to anyone who is not the target of 
> it or familiar with its mechanisms.
> 
> I have spent a great deal of time running spaces within the wider community 
> and I have witnessed these things repeatedly. I also lack the resources some 
> people here have available to mitigate the risks others have openly posed to 
> members of the community including myself and Simon.
> 
> One solution - whether GHC itself needs it or not - might be to pair 
> guidelines for respectful communication with guidelines for when respectful 
> communication is failing to occur.
> 
> Simon, I appreciate both the work you've put in and your love for the 
> communty. I hope you can appreciate that where I appear to be cynical or even 
> sowing discord here, I am acting out of love and care for a community that at 
> its best has done a great deal for me. I apologise for being the one to open 
> up what I see as a somewhat inevitable discussion.
> 
> On 06/12/2018 10:35, Simon Peyton Jones via Haskell wrote:
>> Friends
>> As many of you will know, I have been concerned for several years about the 
>> standards of discourse in the Haskell community.  I think things have 
>> improved since the period that drove me to write my Respect 
>> email 
>> , but 
>> it's far from secure.
>> We discussed this at a meeting of the GHC Steering 
>> Committee 
>>  at ICFP in September, and 
>> many of us have had related discussions since.  Arising out of that 
>> conversation, the GHC Steering Committee has decided to adopt these
>>   Guidelines for respectful 
>> communication
>>  
>> 
>> We are not trying to impose these guidelines on members of the Haskell 
>> community generally. Rather, we are adopting them for ourselves, as a signal 
>> that we seek high standards of discourse in the Haskell community, and are 
>> willing to publicly hold ourselves to that standard, in the hope that others 
>> may choose to follow suit.
>> We are calling them "guidelines for respectful communication" rather than a 
>> "code of conduct", because we want to encourage good communication, rather 
>> than focus on bad behaviour.  Richard Stallman's recent 
>> post  
>> about the new GNU Kind Communication 
>> Guidelines 
>>  expresses the same idea.
>> Meanwhile, the Stack community is taking a similar 
>> approach 
>> .
>> Our guidelines are not set in stone; you can comment 
>> here
>>  
>> .
>>Perhaps they can evolve so that other Haskell committees (or even 
>> individuals) feel a

Re: [Haskell] Guidelines for respectful communication

[Ben Lippmeier]

> On 7 Dec 2018, at 6:47 pm, Jonathan Lange  wrote:
> 
> In particular, her suggestion about pairing guidelines for respectful 
> communications with guidelines for what to do when things break down is an 
> excellent one, and has worked well in other communities to help those on the 
> fringes of a community feel welcome and able to contribute.


I’ll also back this up. Over the last couple of years I’ve been involved in 3 
separate communities which have struggled with many of the same issues. The way 
I see it, guidelines for Respectful Communication are statements of the desired 
end goal, but they don’t provide much insight as to the root causes of the 
problems, or how to address them. At the risk of trivialising the issue, one 
could reduce many such statements to “Can everyone please stop shouting and be 
nice to each other.” (CEPSSaBNTEO)

Here are two templates for problems that I’ve seen over and over, and not 
necessarily in this community. The names used are placeholders.

1) Alice has become very interested in a particular technical issue and wants 
to change the direction of Project X to address it. Alice has contributed to 
Project X on and off, but did not start it and is not currently leading it. The 
main developer is Bob who agrees that the issue exists, but is focused on other 
things right now, and isn’t motivated to have a long discussion about something 
he sees as a minor detail. Alice continues to post on a public list about the 
issue, until Bob becomes exasperated and replies with something like “yes, but 
I don’t care about that right now”. Alice thinks the comment is directed at her 
personally, posts a hurt reply, then Charlie, Debbie, and Edward chime in about 
whether or not that was an appropriate communication. There is a thread on 
Reddit with 50 comments from people that Alice and Bob have never heard of. 
Both Alice and Bob are demotivated by the whole experience, and future 
potential contributors to Project X stumble across the Reddit post and decide 
they don’t want to get involved anymore.

2) Charlie and Debbie have been building System Y for the last 10 years as a 
side project, which over time has grown to be a key part of the public 
infrastructure. Both Charlie and Debbie are well known and respected by the 
community, but don’t always have time to fix bugs promptly. System Y also has 
some long standing issues that everyone grumbles about, but also know how to 
work around. Edward works for Company Z, which has recently formed to do 
consulting in this area. Company Z has publicly stated that they will invest 2 
million dollars improving the public infrastructure, and plan to build a 
replacement for System Y. Some think that Edward is trying to take over System 
Y as a marketing exercise, others think System Y should have been replaced long 
ago, others think that Edward should just start funding Charlie and Debbie's 
work on System Y full time, instead of trying to build a new system from 
scratch. Charlie and Debbie are overwhelmed with all the emails and have less 
and less time to actually fix bugs in System Y. Next, Harold, who has been 
watching from the sidelines, posts a long tirade about all the reasons that 
Company Z is a terrible company doing the wrong things for the wrong reasons. 
Charlie barely knows Harold, but posts a small comment agreeing with the 
general sentiment. Edward sees the comment and promises himself that there is 
no way the ungrateful System Y people are ever getting any of his money. Two 
years later both System-Y and Company Z’s SystemY-Prime are in common use, do 
basically the same thing, and everyone grumbles about both.

The root problems here are differences in motivation, miscommunication, and the 
Internet Amplification Effect (IAE). Harsh posts in public forums are a surface 
effect that feeds back and exacerbates the underlying problems. People like 
Harold who stoke the flames don’t tend to read the Respectful Communication 
guidelines, and everyone always feels justified in their own opinions. There is 
published work on dealing with conflicts in online communities [1], but I don’t 
pretend to be an expert. 

Perhaps an interested party could start a wiki page with statements of the form 
“If you feel like X is happening then consider doing Y.” This might also help 
people that are not naturally good at understanding the thoughts and 
motivations of other people, and work better when such advice is written down.

Peace,
Ben.

[1] Managing Conflicts in Open Source Communities
Ruben Van Wendel De Joode, 2004.

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

Re: [Haskell] Guidelines for respectful communication

[Jonathan Lange]

I normally lurk here, but I agree with Philippa, and am grateful to her for
saying what I was thinking.

In particular, her suggestion about pairing guidelines for respectful
communications with guidelines for what to do when things break down is an
excellent one, and has worked well in other communities to help those on
the fringes of a community feel welcome and able to contribute.

jml

On Thu, Dec 6, 2018 at 10:00 PM Philippa Cowderoy 
wrote:

> I lack the energy to contribute to GHC directly, but these guidelines are
> far too easy to abuse by someone acting in bad faith and we know that bad
> faith actors have been adjacent to our community and acted on things that
> have taken place within it.
>
> From where I'm sitting, guidelines like this risk doing even more damage
> than not having any. Not only do they lack the means to handle incidents
> that have already occurred, they actively discourage the community from
> finding those means.
>
> As someone these guidelines have been drafted to help include, I fear they
> increase the burden on my participation and that of others like me. For a
> community to hold together without sinking to the worst of behaviour, there
> needs to be some acceptance that we will all fail to act in good fatih on
> occasion, that some people will act in bad faith and that behaviour in bad
> faith may take a great deal of explaining to anyone who is not the target
> of it or familiar with its mechanisms.
>
> I have spent a great deal of time running spaces within the wider
> community and I have witnessed these things repeatedly. I also lack the
> resources some people here have available to mitigate the risks others have
> openly posed to members of the community including myself and Simon.
>
> One solution - whether GHC itself needs it or not - might be to pair
> guidelines for respectful communication with guidelines for when respectful
> communication is failing to occur.
>
> Simon, I appreciate both the work you've put in and your love for the
> communty. I hope you can appreciate that where I appear to be cynical or
> even sowing discord here, I am acting out of love and care for a community
> that at its best has done a great deal for me. I apologise for being the
> one to open up what I see as a somewhat inevitable discussion.
> On 06/12/2018 10:35, Simon Peyton Jones via Haskell wrote:
>
> Friends
> As many of you will know, I have been concerned for several years about the 
> standards of discourse in the Haskell community.  I think things have 
> improved since the period that drove me to write my Respect 
> email 
> , but 
> it's far from secure.
> We discussed this at a meeting of the GHC Steering 
> Committee 
>  at ICFP in September, and 
> many of us have had related discussions since.  Arising out of that 
> conversation, the GHC Steering Committee has decided to adopt these
>   Guidelines for respectful 
> communication
>  
>
> We are not trying to impose these guidelines on members of the Haskell 
> community generally. Rather, we are adopting them for ourselves, as a signal 
> that we seek high standards of discourse in the Haskell community, and are 
> willing to publicly hold ourselves to that standard, in the hope that others 
> may choose to follow suit.
> We are calling them "guidelines for respectful communication" rather than a 
> "code of conduct", because we want to encourage good communication, rather 
> than focus on bad behaviour.  Richard Stallman's recent 
> post  
> about the new GNU Kind Communication 
> Guidelines 
>  expresses the same idea.
> Meanwhile, the Stack community is taking a similar 
> approach 
> .
> Our guidelines are not set in stone; you can comment 
> here
>  
> .
>Perhaps they can evolve so that other Haskell committees (or even 
> individuals) feel able to adopt them.
> The Haskell community is such a rich collection of intelligent, passionate, 
> and committed people. Thank you -- I love you all!
> Simon
>
>
>
>
>
> ___
> Haskell mailing 
> listHaskell@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
>

Re: [Haskell] Guidelines for respectful communication

[Philippa Cowderoy]

I lack the energy to contribute to GHC directly, but these guidelines 
are far too easy to abuse by someone acting in bad faith and we know 
that bad faith actors have been adjacent to our community and acted on 
things that have taken place within it.


From where I'm sitting, guidelines like this risk doing even more 
damage than not having any. Not only do they lack the means to handle 
incidents that have already occurred, they actively discourage the 
community from finding those means.


As someone these guidelines have been drafted to help include, I fear 
they increase the burden on my participation and that of others like me. 
For a community to hold together without sinking to the worst of 
behaviour, there needs to be some acceptance that we will all fail to 
act in good fatih on occasion, that some people will act in bad faith 
and that behaviour in bad faith may take a great deal of explaining to 
anyone who is not the target of it or familiar with its mechanisms.


I have spent a great deal of time running spaces within the wider 
community and I have witnessed these things repeatedly. I also lack the 
resources some people here have available to mitigate the risks others 
have openly posed to members of the community including myself and Simon.


One solution - whether GHC itself needs it or not - might be to pair 
guidelines for respectful communication with guidelines for when 
respectful communication is failing to occur.


Simon, I appreciate both the work you've put in and your love for the 
communty. I hope you can appreciate that where I appear to be cynical or 
even sowing discord here, I am acting out of love and care for a 
community that at its best has done a great deal for me. I apologise for 
being the one to open up what I see as a somewhat inevitable discussion.


On 06/12/2018 10:35, Simon Peyton Jones via Haskell wrote:

Friends
As many of you will know, I have been concerned for several years about the standards 
of discourse in the Haskell community.  I think things have improved since the period 
that drove me to write my Respect 
email, 
but it's far from secure.
We discussed this at a meeting of the GHC Steering 
Committee at ICFP in September, 
and many of us have had related discussions since.  Arising out of that conversation, 
the GHC Steering Committee has decided to adopt these
   Guidelines for respectful 
communication

We are not trying to impose these guidelines on members of the Haskell 
community generally. Rather, we are adopting them for ourselves, as a signal 
that we seek high standards of discourse in the Haskell community, and are 
willing to publicly hold ourselves to that standard, in the hope that others 
may choose to follow suit.
We are calling them "guidelines for respectful communication" rather than a "code of 
conduct", because we want to encourage good communication, rather than focus on bad behaviour.  Richard 
Stallman's recent post about the new GNU Kind Communication 
Guidelines expresses the same idea.
Meanwhile, the Stack community is taking a similar 
approach.
Our guidelines are not set in stone; you can comment 
here.
   Perhaps they can evolve so that other Haskell committees (or even individuals) 
feel able to adopt them.
The Haskell community is such a rich collection of intelligent, passionate, and 
committed people. Thank you -- I love you all!
Simon




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

Re: [Haskell] Treatment of unknown pragmas

[Neil Mitchell]

Hi all,

I've just released HLint 2.1.11 which supports three different forms
of pragma as per https://github.com/ndmitchell/hlint#ignoring-hints,
so you can write:

* {-# ANN module "HLint: ignore Eta reduce" #-}
* {-# HLINT ignore "Eta reduce" #-}
* {- HLINT ignore "Eta reduce" -}

The last two are new to this version of HLint. ANN is a serious
performance penalty, {-# HLINT #-} triggers a GHC warning, and {-
HLINT -} gets highlighted as a comment - so people get to pick their
downside. I will probably remove documentation of the ANN variant at
some point, since it's got serious the most serious downsides.

I have no intention to support a {-@ HLINT @-} or similar syntax,
because everything that might sensibly be used is taken, and even if
it gets adopted universally, I suspect HLINT will account for 80%+
instances, making it still the "weird HLINT syntax".

 My preference is still to have GHC not give warnings on HLINT, but
assuming that's still infeasible, I'll probably see about getting all
the Haskell syntax highlighters to add special support for {- HLINT
-}...

Thanks, Neil
On Sun, Oct 28, 2018 at 3:04 PM Artem Pelenitsyn  wrote:
>
> Hello Daniel,
>
> Annotations API was discussed earlier in this thread. Main points against are:
>
> Neil:
> Significant compilation performance penalty and extra recompilation. ANN 
> pragmas is what HLint currently uses.
>
> Brandon:
> The problem with ANN is it's part of the plugins API, and as such does things 
> like compiling the expression into the program in case a plugin generates 
> code using its value, plus things like recompilation checking end up assuming 
> plugins are in use and doing extra checking. Using it as a compile-time 
> pragma is actually fairly weird from that standpoint.
>
> --
> Best, Artem
> On Sat, 27 Oct 2018 at 22:12 Daniel Wagner  wrote:
>>
>> I don't have a really strong opinion, but... isn't this (attaching string-y 
>> data to source constructs) pretty much exactly what GHC's annotation pragma 
>> is for?
>> ~d
>>
>> On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari  wrote:
>>>
>>> Vladislav Zavialov  writes:
>>>
>>> > What about introducing -fno-warn-pragma=XXX? People who use HLint will
>>> > add -fno-warn-pragma=HLINT to their build configuration.
>>> >
>>> A warning flag is an interesting way to deal with the issue. On the
>>> other hand, it's not great from an ergonomic perspective; afterall, this
>>> would mean that all users of HLint (and any other tool requiring special
>>> pragmas) include this flag in their build configuration. A typical
>>> Haskell project already needs too much such boilerplate, in my opinion.
>>>
>>> I think it makes a lot of sense to have a standard way for third-parties
>>> to attach string-y information to Haskell source constructs. While it's
>>> not strictly speaking necessary to standardize the syntax, doing
>>> so minimizes the chance that tools overlap and hopefully reduces
>>> the language ecosystem learning curve.
>>>
>>> Cheers,
>>>
>>> - Ben
>>> ___
>>>
>>> Haskell mailing list
>>> Haskell@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>>
>> ___
>> Haskell mailing list
>> Haskell@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Treatment of unknown pragmas

[Artem Pelenitsyn]

Hello Daniel,

Annotations API was discussed earlier in this thread. Main points against
are:

Neil:
Significant compilation performance penalty and extra recompilation. ANN
pragmas is what HLint currently uses.

Brandon:
The problem with ANN is it's part of the plugins API, and as such does
things like compiling the expression into the program in case a plugin
generates code using its value, plus things like recompilation checking end
up assuming plugins are in use and doing extra checking. Using it as a
compile-time pragma is actually fairly weird from that standpoint.

--
Best, Artem
On Sat, 27 Oct 2018 at 22:12 Daniel Wagner  wrote:

> I don't have a really strong opinion, but... isn't this (attaching
> string-y data to source constructs) pretty much exactly what GHC's
> annotation pragma is for?
> ~d
>
> On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari  wrote:
>
>> Vladislav Zavialov  writes:
>>
>> > What about introducing -fno-warn-pragma=XXX? People who use HLint will
>> > add -fno-warn-pragma=HLINT to their build configuration.
>> >
>> A warning flag is an interesting way to deal with the issue. On the
>> other hand, it's not great from an ergonomic perspective; afterall, this
>> would mean that all users of HLint (and any other tool requiring special
>> pragmas) include this flag in their build configuration. A typical
>> Haskell project already needs too much such boilerplate, in my opinion.
>>
>> I think it makes a lot of sense to have a standard way for third-parties
>> to attach string-y information to Haskell source constructs. While it's
>> not strictly speaking necessary to standardize the syntax, doing
>> so minimizes the chance that tools overlap and hopefully reduces
>> the language ecosystem learning curve.
>>
>> Cheers,
>>
>> - Ben
>> ___
>>
> Haskell mailing list
>> Haskell@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Treatment of unknown pragmas

[Daniel Wagner]

I don't have a really strong opinion, but... isn't this (attaching string-y
data to source constructs) pretty much exactly what GHC's annotation pragma
is for?
~d

On Tue, Oct 16, 2018 at 3:14 PM Ben Gamari  wrote:

> Vladislav Zavialov  writes:
>
> > What about introducing -fno-warn-pragma=XXX? People who use HLint will
> > add -fno-warn-pragma=HLINT to their build configuration.
> >
> A warning flag is an interesting way to deal with the issue. On the
> other hand, it's not great from an ergonomic perspective; afterall, this
> would mean that all users of HLint (and any other tool requiring special
> pragmas) include this flag in their build configuration. A typical
> Haskell project already needs too much such boilerplate, in my opinion.
>
> I think it makes a lot of sense to have a standard way for third-parties
> to attach string-y information to Haskell source constructs. While it's
> not strictly speaking necessary to standardize the syntax, doing
> so minimizes the chance that tools overlap and hopefully reduces
> the language ecosystem learning curve.
>
> Cheers,
>
> - Ben
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Treatment of unknown pragmas

[Ben Gamari]

Vladislav Zavialov  writes:

> What about introducing -fno-warn-pragma=XXX? People who use HLint will
> add -fno-warn-pragma=HLINT to their build configuration.
>
A warning flag is an interesting way to deal with the issue. On the
other hand, it's not great from an ergonomic perspective; afterall, this
would mean that all users of HLint (and any other tool requiring special
pragmas) include this flag in their build configuration. A typical
Haskell project already needs too much such boilerplate, in my opinion.

I think it makes a lot of sense to have a standard way for third-parties
to attach string-y information to Haskell source constructs. While it's
not strictly speaking necessary to standardize the syntax, doing
so minimizes the chance that tools overlap and hopefully reduces
the language ecosystem learning curve.

Cheers,

- Ben


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

Re: [Haskell] Treatment of unknown pragmas

[Matthew Pickering]

I like the suggestion of a flag. For any realistic compilation you
have to pass a large number of flags to GHC anyway. `stack`, `cabal`
or so on can choose to pass the additional flag by default if they
wish or make it more ergonomic to do so.
On Tue, Oct 16, 2018 at 7:58 PM Jared Weakly  wrote:
>
> The main problem I see with this is now N tools need to implement support for 
> that flag and it will need to be configured for every tool separately. If we 
> standardize on a tool pragma in the compiler, all that stays automatic as it 
> is now (a huge plus for tooling, which should as beginner friendly as 
> possible). It also, in my eyes, helps enforce a cleaner distinction between 
> pragmas as a feature-gate and pragmas as a compiler/tooling directive
>
> On Tue, Oct 16, 2018, 11:13 AM Vladislav Zavialov  
> wrote:
>>
>> What about introducing -fno-warn-pragma=XXX? People who use HLint will add 
>> -fno-warn-pragma=HLINT to their build configuration.
>>
>> On Tue, Oct 16, 2018, 20:51 Ben Gamari  wrote:
>>>
>>> Hi everyone,
>>>
>>> Recently Neil Mitchell opened a pull request [1] proposing a single-line
>>> change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
>>> lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
>>> lexer for every tool that wants a pragma seems quite unsustainable.
>>>
>>> On the other hand, a reasonable counter-argument could be made on the
>>> basis of the Haskell Report, which specifically says that
>>> implementations should ignore unrecognized pragmas. If GHC did this
>>> (instead of warning, as it now does) then this wouldn't be a problem.
>>>
>>> Of course, silently ignoring mis-typed pragmas sounds terrible from a
>>> usability perspective. For this reason I proposed that the following
>>> happen:
>>>
>>>  * The `{-# ... #-}` syntax be reserved in particular for compilers (it
>>>largely already is; the Report defines it as "compiler pragma"
>>>syntax). The next Report should also allow implementations to warn in
>>>the case of unrecognized pragmas.
>>>
>>>  * We introduce a "tool pragma" convention (perhaps even standardized in
>>>the next Report). For this we can follow the model of Liquid Haskell:
>>>`{-@ $TOOL_NAME ... @-}`.
>>>
>>> Does this sound sensible?
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://github.com/ghc/ghc/pull/204
>>> ___
>>> ghc-devs mailing list
>>> ghc-d...@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
>> ghc-devs mailing list
>> ghc-d...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Treatment of unknown pragmas

[Simon Peyton Jones via Haskell]

I rather agree.

We don't even need a convention do we?  /Any/ comment in {- -} is ignored
by GHC /except/ {-# ... #-}.  So tool users are free to pick whatever
convention they like to identify the stuff for their tool.

Simon

| -Original Message-
| From: ghc-devs  On Behalf Of Ben Gamari
| Sent: 16 October 2018 18:51
| To: GHC developers ; haskell@haskell.org
| Subject: Treatment of unknown pragmas
| Hi everyone,
| 
| Recently Neil Mitchell opened a pull request [1] proposing a single-line
| change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
| lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
| lexer for every tool that wants a pragma seems quite unsustainable.
| 
| On the other hand, a reasonable counter-argument could be made on the
| basis of the Haskell Report, which specifically says that
| implementations should ignore unrecognized pragmas. If GHC did this
| (instead of warning, as it now does) then this wouldn't be a problem.
| 
| Of course, silently ignoring mis-typed pragmas sounds terrible from a
| usability perspective. For this reason I proposed that the following
| happen:
| 
|  * The `{-# ... #-}` syntax be reserved in particular for compilers (it
|largely already is; the Report defines it as "compiler pragma"
|syntax). The next Report should also allow implementations to warn in
|the case of unrecognized pragmas.
| 
|  * We introduce a "tool pragma" convention (perhaps even standardized in
|the next Report). For this we can follow the model of Liquid Haskell:
|`{-@ $TOOL_NAME ... @-}`.
| 
| Does this sound sensible?
| 
| Cheers,
| 
| - Ben
| 
| 
| [1] https://github.com/ghc/ghc/pull/204
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [ANNOUNCE] GHC 8.6.1 released

[Ben Gamari]

On September 24, 2018 2:09:13 AM CDT, Jens Petersen  
wrote:
>I have built 8.6.1 for Fedora 27, 28, 29, Rawhide, and EPEL7 in:
>
>https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.6.1/
>
>The repo also includes latest cabal-install.
>
Thanks Jens! This is a very helpful service. 

Cheers, 

- Ben 


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [ANNOUNCE] GHC 8.6.1 released

[Herbert Valerio Riedel]

Hello everyone,

Here's an addendum to the announcment as it ommitted an important detail:

GHC 8.6.1 is only guaranteed to work properly with tooling which uses
lib:Cabal version 2.4.0.1 or later.

As such, GHC 8.6.1 works best with ​`cabal-install` 2.4.0.0 or later;
please upgrade to `cabal-install` 2.4.0.0 if you haven't already.

Note that cabal-install 2.4 supports all GHC versions back till GHC
7.0.4 and we also strongly recommend to use the latest available stable
release of `cabal` even with older GHC releases as bugfixes and
improvements aren't always backported to older Cabal releases as well as
to be able to benefit from recently added CABAL format features[8] (or
be able to access package releases on Hackage[9] which rely on those
features) which require recent enough versions of Cabal as well.

Note that binaries aren't available on cabal's download page[1] yet.

If you're on Ubuntu or Debian, you can get a compiled cabal-install 2.4
`.deb` package via Apt from

- https://launchpad.net/~hvr/+archive/ubuntu/ghc

or

- http://downloads.haskell.org/debian/

respectively.

Binary versions for macOS and Windows are also expected to become
available via [2] and [3] soon (and also at [1]).

In the meantime, if you already have GHC 7.10 or later (together with a
compatible `cabal` executable) installed, you can easily install cabal
2.4 yourself from Hackage[9] by invoking

cabal install cabal-install-2.4.0.0

and making sure that the resulting `cabal` executable is accessible via
your $PATH; you can check with `cabal --version` which should emit
something along the lines of

$ cabal --version
cabal-install version 2.4.0.0
compiled using version 2.4.0.1 of the Cabal library 



Finally, the Haskell Platform[4] release for GHC 8.6.1 should be
available soon as well which provides yet another recommended "standard
way to get GHC and related tools"[5] in a uniform way across multiple
operating systems. See [4] and [5] for more details about the standard
Haskell Platform distribution.


 [1]: https://www.haskell.org/cabal/download.html
 
 [2]: https://haskell.futurice.com/
 
 [3]: https://hub.zhox.com/posts/chocolatey-introduction/
 
 [4]: https://www.haskell.org/platform/
 
 [5]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009379.html

 [6]: https://launchpad.net/~hvr/+archive/ubuntu/ghc
 
 [7]: http://downloads.haskell.org/debian/

 [8]: https://cabal.readthedocs.io/en/latest/file-format-changelog.html

 [9]: http://hackage.haskell.org/
 

-- Herbert


On 2018-09-21 at 20:57:02 -0400, Ben Gamari wrote:
> Hello everyone,
>
> The GHC team is pleased to announce the availability of GHC 8.6.1, the
> fourth major release in the GHC 8 series. The source distribution, binary
> distributions, and documentation for this release are available at
>
> https://downloads.haskell.org/~ghc/8.6.1
>
> The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a
> number of exciting features. These most notably include:
>
>  * A new deriving mechanism, `deriving via`, providing a convenient way
>for users to extend Haskell's typeclass deriving mechanism
>
>  * Quantified constraints, allowing forall quantification in constraint 
> contexts
>
>  * An early version of the GHCi `:doc` command
>
>  * The `ghc-heap-view` package, allowing introspection into the
>structure of GHC's heap
>
>  * Valid hole fit hints, helping the user to find terms to fill typed
>holes in their programs
>
>  * The BlockArguments extension, allowing the `$` operator to be omitted
>in some unambiguous contexts
>
>  * An exciting new plugin mechanism, source plugins, allowing plugins to
>inspect and modify a wide variety of compiler representations.
>
>  * Improved recompilation checking when plugins are used
>
>  * Significantly better handling of macOS linker command size limits,
>avoiding linker errors while linking large projects
>
>  * The next phase of the MonadFail proposal, enabling
>-XMonadFailDesugaring by default
>
> A full list of the changes in this release can be found in the
> release notes:
>
> 
> https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html
>
> Perhaps of equal importance, GHC 8.6 is the second major release made
> under GHC's accelerated six-month release schedule and the first set of
> binary distributions built primarily using our new continuous
> integration scheme. While the final 8.6 release is around three weeks
> later than initially scheduled due to late-breaking bug reports, we
> expect that the 8.8 release schedule shouldn't be affected.
>
> Thanks to everyone who has contributed to developing, documenting, and
> testing this release!
>
> As always, let us know if you encounter trouble.
>
>
> How to get it
> ~
>
> The easy way is to go to the web page, which should be self-explanatory:
>
> https://www.haskell.org/ghc/
>
> We supply binary builds in the native package format for many
> platforms, a

Re: [Haskell] Doc in Pdf format?

[David Ringo]

Hi Donald,

Is this what you're looking for?

https://downloads.haskell.org/~ghc/latest/docs/users_guide.pdf

- David

On Thu, Jul 19, 2018 at 8:04 PM Donald Sitompul 
wrote:

> I cannot find GHC docs in pdf format.  Where are they now?
>
> Donald Sitompul
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Announce: Haskell Platform 8.4.3

[Gershom B]

As  a brief followup, new 8.4.3 installers for windows have been
released (both core and full), which resolve a few issues brought
about by the switch to automatic modification of "extra-prog-path" and
related, and the corresponding hashes have been updated.

Best,
Gershom


On Tue, Jun 12, 2018 at 7:27 AM Gershom B  wrote:
>
> On behalf of the Haskell Platform team, I'm happy to announce the release of
>
> Haskell Platform 8.4.3
>
> Now available at
>
> https://www.haskell.org/platform/
>
> This includes GHC 8.4.3, cabal-install 2.2.0.0, and stack 1.7.1.
>
> A full list of contents is available at
> https://www.haskell.org/platform/contents.html
>
> Outside of the update of the GHC to 8.4.3, the only substantive change
> in this release is to the new version of the primitive library, which
> includes a range of fixes and improvements.
>
> The list of GHC changes is available at:
> https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.3-released
>
> And the list of changes to Primitive is available at:
> http://hackage.haskell.org/package/primitive-0.6.4.0/changelog
>
> There are (still) currently no 32 bit Windows builds available. We're
> looking into the issues preventing us from building an installer for
> that platform. The components all appear to work individually in such
> a case, and can be installed separately by users who so desire.
>
> Happy Haskell Hacking all,
> Gershom
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Announce: Haskell Platform 8.4.2

[Gershom B]

One additional feature I forgot to note: the windows platform
installers should no longer require manually altering the cabal config
file to add `extra-prog-path`, etc. to point to the msys distribution.
The new windows installer takes advantage of the `cabal user-config
--augment` command to add those lines automatically. This should give
a smoother install experience for new windows users.

--gershom

On Sat, May 5, 2018 at 2:16 AM, Gershom B  wrote:
> On behalf of the Haskell Platform team, I'm happy to announce the release of
>
> Haskell Platform 8.4.2
>
> Now available at
>
> https://www.haskell.org/platform/
>
> This includes GHC 8.4.2, cabal-install 2.2.0.0, and stack 1.7.1, all
> with substantial improvements since the last platform release.
>
> A full list of contents is available at
> https://www.haskell.org/platform/contents.html
>
> Thanks to all the contributors to this release, thanks to all the
> package and tool maintainers and authors, and a big thanks to the GHC
> team for all their hard work.
>
> There are (still) currently no 32 bit Windows builds available. We're
> looking into the issues preventing us from building an installer for
> that platform. The components all appear to work individually in such
> a case, and can be installed separately by users who so desire.
>
> A list of new GHC changes is available at:
> https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.1-released and
> https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.2-released
>
> A list of cabal changes is available at:
> https://hackage.haskell.org/package/cabal-install-2.2.0.0/changelog
>
> The cabal documentation page is at:
> https://www.haskell.org/cabal/users-guide/
>
> A list of stack changes is at:
> https://docs.haskellstack.org/en/stable/ChangeLog/#v171
>
> The stack documentation page is at:
> https://docs.haskellstack.org/en/stable/README/
>
> Happy Haskell Hacking all,
> Gershom
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Haskell, FP] Anduril Industries is Hiring

[Ivan Lazar Miljenovic]

Hi Travis,

It would be helpful if you said a) where this was and b) if remote
work is possible.

On 5 April 2018 at 15:01, Travis Whitaker  wrote:
> Anduril Industries (https://www.anduril.com) is hiring. TL;DR: Come write
> Haskell, Rust, and Nix (and some C++ when necessary) to make autonomous
> robots and drones go!
>
> We're a team of software and hardware engineers from various backgrounds
> (game development, computer graphics, financial technology, government
> intelligence, biotechnology) working to improve the state of defense
> technology. Our strategy involves focusing on product development instead of
> traditional governmental processes. By funding product development ourselves
> instead of relying on government funds, we're able to create more focused
> products faster and with significantly fewer resources. By leveraging
> hardware and techniques that have only recently become feasible to deploy at
> scale (e.g. GPGPU computing), we can significantly advance the state of the
> defense technology market.
>
> We're searching for generally competent, mathematically inclined software
> engineers, and we're especially interested in those with experience in
> computer vision (first principles techniques and machine learning), sensor
> fusion, detection and tracking, and statistical parameter estimation. Our
> team is increasingly applying functional programming and related
> technologies; we run Haskell and Rust code in production and use Nix to
> achieve reproducible build environments and keep deployment, CI, and
> cross-compilation sane.
>
> If you like functional programming, interfacing with hardware, and solving
> problems in detection, tracking, and autonomous vehicle control (land and
> air), drop me a line at tra...@anduril.com
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Google Summer of Code 2018] Student Applications are now open

[Gershom B]

 
On March 16, 2018 at 7:08:20 AM, Tillmann Vogt 
(tillmann.v...@rwth-aachen.de(mailto:tillmann.v...@rwth-aachen.de)) wrote:
> I know I know. I am supposed to just ignore this. You most likely just  
> copied it from a template. The people with the money want control over  
> our minds. And we should better not complain or there will be no GSOC  
> next year. SCNR.  

This was not mindlessly copied from a template, and it was not imposed by 
google. This was written by the people involved in the Haskell GSoC work, 
because we meant it. It was not written to ask people to ignore. It was written 
to ask people to consider, and to indicate that we understand that in drawing 
people into the world of free software development, we should take pains to 
make the tools we build and use as widely accessible as possible. We want to 
share the joy of functional programming with everyone, and that means, 
especially that we want to help foster Haskell among those that are, thus far, 
historically underrepresented in the world of functional programming. I think 
it is a good thing.

Best,
Gershom

(p.s. This list is intended to be low-traffic and for announcements. Future 
discussion on this list would be off topic. If people would like discussion to 
continue, I suggest haskell-cafe).


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

Re: [Haskell] [Google Summer of Code 2018] Student Applications are now open

[Dan Burton]

Pardon the tangent, but if I could just throw in my two cents about this.

The Haskell community has always been helpful, kind, and inclusive of me.
This was true before I came out of the closet as gay, and remained true
afterwards as well. At a time when I was unable to turn to people in my
personal life, I was able to turn to contacts in the Haskell community. I
would not have done so if I did not explicitly know that those particular
people would be safe to turn to.

Messages of explicit inclusion need not be interpreted as divisive; they do
not imply exclusion of those not explicitly listed. I am grateful that
minorities are explicitly called out and strongly encouraged to apply in
this announcement. I am confident that haskell.org will make every effort
to support and empower all applicants.

-- Dan Burton

On Fri, Mar 16, 2018 at 4:06 AM, Tillmann Vogt  wrote:

> Am 16.03.2018 um 00:49 schrieb Jasper Van der Jeugt:
>
>> Lastly, we recognize that inclusion is an important part of our mission
>> to promote Haskell. Therefore, we strongly encourage applications from
>>
>
> Why "strongly" encourage? Why not just encourage?
> This sounds like you are in a war. I would also be very careful about
> being "on a mission". This by itself would be OK if its just about being
> enthusiastic. But in combination with the other text. Hm. People generally
> don't like missionaries.
> Also: Why are minorities explicitly named? To me this has a dividing and
> discriminating effect.
> I know I know. I am supposed to just ignore this. You most likely just
> copied it from a template. The people with the money want control over our
> minds. And we should better not complain or there will be no GSOC next
> year. SCNR.
>
>> people in communities that are underrepresented in functional
>> programming, including but not limited to women; people of color; people
>> in gender, sexual and romantic minorities; people with disabilities;
>> people residing in Asia, Africa, or Latin America; and people who have
>> never taken part in similar programs before.
>>
>> Kind regards, Jasper Van der Jeugt & George Wilson on behalf of the
>> Haskell.org Committee
>>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Google Summer of Code 2018] Student Applications are now open

[Tillmann Vogt]

Am 16.03.2018 um 00:49 schrieb Jasper Van der Jeugt:

Lastly, we recognize that inclusion is an important part of our mission
to promote Haskell. Therefore, we strongly encourage applications from


Why "strongly" encourage? Why not just encourage?
This sounds like you are in a war. I would also be very careful about 
being "on a mission". This by itself would be OK if its just about being 
enthusiastic. But in combination with the other text. Hm. People 
generally don't like missionaries.
Also: Why are minorities explicitly named? To me this has a dividing and 
discriminating effect.
I know I know. I am supposed to just ignore this. You most likely just 
copied it from a template. The people with the money want control over 
our minds. And we should better not complain or there will be no GSOC 
next year. SCNR.

people in communities that are underrepresented in functional
programming, including but not limited to women; people of color; people
in gender, sexual and romantic minorities; people with disabilities;
people residing in Asia, Africa, or Latin America; and people who have
never taken part in similar programs before.

Kind regards, Jasper Van der Jeugt & George Wilson on behalf of the
Haskell.org Committee


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

Re: [Haskell] The Haskell Report: who maintains it?

[David Feuer]

We also have an inconsistency between the textual descriptions of
accumArray and accum and their reference implementations. I recently
changed GHC's implementations to better match the text (for efficiency
reasons), but the reference implementations should be adjusted too.

On Thu, Mar 15, 2018 at 6:52 PM, Simon Peyton Jones via Haskell <
haskell@haskell.org> wrote:

> Friends
>
>
>
> Does anyone know who, if anyone, feels responsible for committing updates
> to the Haskell 2010 Report?
>
>
>
> Who even has commit rights?
>
>
>
> There’s Frank’s pull request below, and I have another important typo to
> fix.
>
>
>
> Thanks
>
>
>
> Simon
>
>
>
> *From:* Frank Steffahn [mailto:notificati...@github.com]
> *Sent:* 11 March 2018 17:03
> *To:* haskell/haskell-report 
> *Cc:* Subscribed 
> *Subject:* [haskell/haskell-report] Fix a typo in: Semantics of Case
> Expressions, Part 3 (s) (#4)
>
>
>
> Hi. I noticed this in the Haskell 2010 report, which is an obvious typo /
> mistake. I’m not 100% sure if this is the right branch (or even in general
> the right place) to note this, but I hope it will get fixed ;-)
>
> This seems like it is an artifact of copy-and-pasting from “Semantics of
> Case Expressions, Part 1 (c)” without properly adapting the thing,
> especially in commit bc94554
> 
> .
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/haskell/haskell-report/pull/4
> 
> Commit Summary
>
>- Fix a typo in: Semantics of Case Expressions, Part 3 (s)
>
> File Changes
>
>- *M* report/exps.verb
>
> 
>(1)
>
> Patch Links:
>
>- https://github.com/haskell/haskell-report/pull/4.patch
>
> 
>- https://github.com/haskell/haskell-report/pull/4.diff
>
> 
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .
>
> ___
> Haskell mailing list
> Haskell@haskell.

Re: [Haskell] Haskell Digest, Vol 174, Issue 15

[姓名]

> GNU mailman passwords are explicitly _*NOT*_ secure!
>
> _*DO NOT REUSE MAILING LIST PASSWORDS!*_
>
>
> They ARE stored in plaintext and will be mailed back to you periodically
> on some setups to confirm that you want to remain subscribed.

I didn't know that. Thanks for letting me know. However, I feel it is
unfriendly and dangerous for beginners.

Sorry for replying to the digest mail. I've strangely received no mail from
this mailing list without digests.
I'll try to unsubscribe and resubscribe this mailing list.
Thanks.


2018-02-28 21:00 GMT+09:00 :

> Send Haskell mailing list submissions to
> haskell@haskell.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
> or, via email, send a message with subject or body 'help' to
> haskell-requ...@haskell.org
>
> You can reach the person managing the list at
> haskell-ow...@haskell.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Haskell digest..."
>
>
> Today's Topics:
>
>1. Re: Security problem of email registration page (Thomas Jakway)
>2. Re: Security problem of email registration page (Thomas Jakway)
>
>
> ------
>
> Message: 1
> Date: Tue, 27 Feb 2018 08:23:42 -0800
> From: Thomas Jakway 
> To: haskell@haskell.org
> Subject: Re: [Haskell] Security problem of email registration page
> Message-ID: <7b17a89d-8fb9-634e-ab9b-7839f4d89...@nyu.edu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> GNU mailman passwords are explicitly _*NOT*_ secure!
>
> _*DO NOT REUSE MAILING LIST PASSWORDS!*_
>
>
> They ARE stored in plaintext and will be mailed back to you periodically
> on some setups to confirm that you want to remain subscribed.
>
>
> On 02/25/2018 12:44 AM, 姓名 wrote:
> > Hi there,
> >
> > I become aware of the problem that
> > https://mail.haskell.org/mailman/listinfo/haskell send a password to
> > http://mail.haskell.org/cgi-bin/mailman/subscribe/haskell. Probably it
> > means this page will send a password without encryption. Could you use
> > https instead of http, or remove this duplicate page? I had used
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell instead.
> >
> >
> > ___
> > Haskell mailing list
> > Haskell@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
> -- next part ------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/haskell/attachments/
> 20180227/a6e0ab4f/attachment-0001.html>
>
> --
>
> Message: 2
> Date: Tue, 27 Feb 2018 08:27:39 -0800
> From: Thomas Jakway 
> To: haskell@haskell.org
> Subject: Re: [Haskell] Security problem of email registration page
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> ...it's true that without HTTPS someone could man-in-the-middle you and
> get you to join a secret, ILLEGAL haskell mailing list, for NEFARIOUS
> purposes.  Some say demons wander those hills, seeking to lure the
> unwary to the unhallowed lands of javascript...
>
>
> On 02/27/2018 08:23 AM, Thomas Jakway wrote:
> >
> > GNU mailman passwords are explicitly _*NOT*_ secure!
> >
> > _*DO NOT REUSE MAILING LIST PASSWORDS!*_
> >
> >
> > They ARE stored in plaintext and will be mailed back to you
> > periodically on some setups to confirm that you want to remain
> subscribed.
> >
> >
> > On 02/25/2018 12:44 AM, 姓名 wrote:
> >> Hi there,
> >>
> >> I become aware of the problem that
> >> https://mail.haskell.org/mailman/listinfo/haskell send a password to
> >> http://mail.haskell.org/cgi-bin/mailman/subscribe/haskell. Probably
> >> it means this page will send a password without encryption. Could you
> >> use https instead of http, or remove this duplicate page? I had used
> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell instead.
> >>
> >>
> >> ___
> >> Haskell mailing list
> >> Haskell@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
> >
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/haskell/attachments/
> 20180227/c9fdb691/attachment-0001.html>
>
> --
>
> Subject: Digest Footer
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
>
> --
>
> End of Haskell Digest, Vol 174, Issue 15
> 
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Security problem of email registration page

[Thomas Jakway]

...it's true that without HTTPS someone could man-in-the-middle you and 
get you to join a secret, ILLEGAL haskell mailing list, for NEFARIOUS 
purposes.  Some say demons wander those hills, seeking to lure the 
unwary to the unhallowed lands of javascript...



On 02/27/2018 08:23 AM, Thomas Jakway wrote:


GNU mailman passwords are explicitly _*NOT*_ secure!

_*DO NOT REUSE MAILING LIST PASSWORDS!*_


They ARE stored in plaintext and will be mailed back to you 
periodically on some setups to confirm that you want to remain subscribed.



On 02/25/2018 12:44 AM, 姓名 wrote:

Hi there,

I become aware of the problem that 
https://mail.haskell.org/mailman/listinfo/haskell send a password to 
http://mail.haskell.org/cgi-bin/mailman/subscribe/haskell. Probably 
it means this page will send a password without encryption. Could you 
use https instead of http, or remove this duplicate page? I had used 
https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell instead.



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




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

Re: [Haskell] Security problem of email registration page

[Thomas Jakway]

GNU mailman passwords are explicitly _*NOT*_ secure!

_*DO NOT REUSE MAILING LIST PASSWORDS!*_


They ARE stored in plaintext and will be mailed back to you periodically 
on some setups to confirm that you want to remain subscribed.



On 02/25/2018 12:44 AM, 姓名 wrote:

Hi there,

I become aware of the problem that 
https://mail.haskell.org/mailman/listinfo/haskell send a password to 
http://mail.haskell.org/cgi-bin/mailman/subscribe/haskell. Probably it 
means this page will send a password without encryption. Could you use 
https instead of http, or remove this duplicate page? I had used 
https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell instead.



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


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

Re: [Haskell] ANN: Hackage Account Registration Changes

[Geoffrey Huntley]

I feel that this is the wrong direction to take and will add more burden on
people that we shouldn't be adding additional burden to. It's also the
wrong "optics".

I just had a quick squizz at Hackage with a simple PR you'll be able to
remove the incentives for this behaviour.

Add "nofollow" to any links supplied by the user or that are rendered as
part of parsing user input.

https://support.google.com/webmasters/answer/96569?hl=en

The .NET ecosystem recently went through these same notions for the same
reasons - here's the PR

https://github.com/NuGet/NuGetGallery/pull/4841/files

On Fri., 23 Feb. 2018, 10:38 am Matthias Kilian, 
wrote:

> Hi,
>
> On Thu, Feb 22, 2018 at 05:54:33PM -0500, Gershom B wrote:
> > In the meantime, as a short term measure, we have changed new account
> > registration policies on hackage.
> >
> > Users can still register as before, but new users do _not_ have upload
> > rights until they explicitly request them and are granted them by a
> > human being.
> >
> > (This is actually how we had configured hackage to work on initial
> > deployment -- we loosened things up for some years as the extra step
> > seemed unnecessary).
>
> Does this mean that before the todays change, anyone (or anything)
> could register and upload packages without any review and without
> any acknowledgement for trustfulness by another person? Does it
> maen that one can't trust *any* package on hackage.haskell.org at
> least a little bit (based on trust between acknowledging persons
> and reputation) without reviewing the package's source code?
>
> Ciao,
> Kili
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] ANN: Hackage Account Registration Changes

[Matthias Kilian]

Hi,

On Thu, Feb 22, 2018 at 05:54:33PM -0500, Gershom B wrote:
> In the meantime, as a short term measure, we have changed new account
> registration policies on hackage.
> 
> Users can still register as before, but new users do _not_ have upload
> rights until they explicitly request them and are granted them by a
> human being.
> 
> (This is actually how we had configured hackage to work on initial
> deployment -- we loosened things up for some years as the extra step
> seemed unnecessary).

Does this mean that before the todays change, anyone (or anything)
could register and upload packages without any review and without
any acknowledgement for trustfulness by another person? Does it
maen that one can't trust *any* package on hackage.haskell.org at
least a little bit (based on trust between acknowledging persons
and reputation) without reviewing the package's source code?

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

Re: [Haskell] LiftA2 over fmap

[Edward Kmett]

> In particular, if fmap

 is an expensive operation, it is likely better to use liftA2

 than to (fmap

 over the structure *and then use <*>
)*
. (emphasis and parens added).

Consider any data constructor that has a strict spine and look at

f <$> m <*> n

This has to walk `m` twice. Once for the fmap on the first argument, and
once for the <*>, but the liftA2 version can walk `m` once fusing things
together.

-Edward

On Tue, Jan 30, 2018 at 4:42 AM, Damien BIHEL  wrote:

> In the documentation here
> 
> it's written that for some functors liftA2 has better performance than
> fmap. Does anyone have any examples ?
>
> Regards,
>
> --
> Damien Bihel
> R&D (Research & Development) Engineer at ELRA (European Language Resources
> Association)
> E-Mail: biheldam...@gmail.com
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] A small milestone

[Simon Peyton Jones via Haskell]

Hmm.  Maybe 1987 was thirty years ago, not forty.  Clearly old age saps one’s 
mental arithmetic.  Best to read the 
paper
 😊.
Simon
From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Simon 
Peyton Jones via Haskell-Cafe
Sent: 18 January 2018 17:14
To: haskell@haskell.org; Haskell Cafe 
Subject: [Haskell-cafe] A small milestone

Cherished friends
Today is my sixtieth birthday.
It is just over forty thirty years since Phil and I called in at Yale on my way 
to FPCA, and floated the idea of Haskell with Paul 
Hudak.
  (It wasn’t called Haskell then, of course.)   Rather a lot of water has 
flowed under the bridge since then.  GHC’s bug tracker is up to 14,683 tickets; 
 I have read every one of them.
But the best thing is Haskell’s rich community of smart, motivated, passionate, 
and friendly colleagues.  There was a time when I knew every Haskell programmer 
on the planet, but we are far, far beyond that point.  Now it’s beyond me even 
to keep up with the huge wave of elegant and creative ideas, tools, libraries, 
and blog posts that you generate.   (Kudos to Taylor – and doubtless other 
colleagues -- for the Haskell Weekly 
News,
 which I love.)   But despite its size, it’s a community that is still 
characterised by a love of elegance, and a desire to distil the essence of an 
idea and encapsulate it in an abstraction, all tempered with respect and 
tolerance. We don’t always live up to these ideals, but by and large we do.
Thank you all.  Onward and upward!
Simon
PS: as birthday recreation I’m working on 
https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Haskell-cafe] PSA: `cabal update` command needs manual unsticking

[Nathan Collins]

In case this confuses anyone else, I think this PSA only applies if
you're using cabal-install version 2.*, but please correct me if I'm
wrong.

I had some ~/.cabal/packages/hackage.haskell.org/00-index.* files, but
not any 01-index.* files, and running `cabal update` didn't change
that. Then I noticed I was using cabal-install version 1.24.0.2. When
I upgraded to cabal-install version 2.0.0.1 and did another `cabal
update` the 01-index.* files appeared.

Cheers,

-nathan

On Mon, Jan 1, 2018 at 5:24 PM, Gershom B  wrote:
> Dear Haskellers,
>
> A recent update to hackage, which fixed up the 01-index.tar.gz file,
> revealed a bug in existing versions of cabal-install, when index files
> are cleaned up. This bug means that the `cabal update` command, which
> updates the hackage index file, will fail silently and leave the old
> file in place. It is easy to get things working again, but it requires
> manual intervention. Here is the most straightforward way to get
> things working again:
>
> On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.*
> On windows: remove the same files, but from
> %appdata%\cabal\packages\hackage.haskell.org
>
> rerun `cabal update` to fetch a new 01-index.
>
> Apologies all for the inconvenience and any confusion this may have
> caused. There is a PR to fix this behavior in the works, but since the
> problem is on the client side, the fix will only improve the
> situations for new versions of `cabal`.
>
> Happy New Years to all, and cheers to a very functional 2018,
> Gershom
>
> p.s.: since the problem comes in unpacking the 01-index.tar.gz into
> the 01-index.tar, you can also just untar that file in place manually,
> or force cabal into doing the same by running `touch
> ~/.cabal/packages/hackage.haskell.org/01-index.tar`
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] 6 Assistant professor positions in Utrecht

[tiredpixel]

Ha ha ha. :D Grappig. Maar het is normaal voor mij 'talented' en zo woorden te 
zien; definitief, is het beter als 'Ruby rockstar' of 'DevOps evangelist'. ;)

-- tiredpixel


Doaitse Swierstra (2018-01-04 09:13):
> Ik had ook al aan Johan gemeld dat het woord talented suggereert dat er bij 
> jullie ook non-talented personen werken. Hij zou het aan laten passen.
> 
> Doaitse



signature.asc
Description: OpenPGP digital signature
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] 6 Assistant professor positions in Utrecht

[Doaitse Swierstra]

Ik had ook al aan Johan gemeld dat het woord talented suggereert dat er bij
jullie ook non-talented personen werken. Hij zou het aan laten passen.

Doaitse

Op 4 jan. 2018 09:13 schreef "Swierstra, W.S. (Wouter)" :

> We are currently advertising vacancies for
>
>
>   6 talented Assistant Professors in Information and Computing Sciences
>
>
>   (Tenure Track 0.8 - 1.0 FTE)
>
>
> # Job description
>
> We are searching for motivated, excellent candidates, on the
> Assistant Professor level.  You must have expertise in Computing
> and Information Sciences, preferably in the areas of Information
> Science, Games, Artificial Intelligence or Data
> Science. Excellent candidates with other areas of expertise
> related to our current research groups and teaching programmes
> are also invited to apply.
>
> You have proven ambition and talent for research. As teaching is
> an important and satisfying part of our work, we are searching
> for people with a demonstrable motivation to teach. The
> department is expanding and provides a dynamic work
> environment. If you are excited to actively participate in
> shaping the department, you are very welcome to apply.
>
> Due to our successful teaching programmes and our ambitions in
> research the Department is expanding. We are therefore actively
> searching for 6 talented Research and Teaching Assistant
> Professors in Information and Computing Sciences. Please note
> that positions offered will vary, depending on experience and
> expertise.
>
> # Qualifications
>
> ## Research
>
> * PhD in Computer Science, Information Science or another relevant
> discipline;
> * track record of international publications in leading conferences and
> journals;
> * experience with or good prospects for acquiring external research funds;
> * vision on future research directions in own area of expertise;
> * experience with or readiness to supervise PhD projects;
> * active role in international scientific communities.
>
> ## Teaching
>
> * experience with and enthusiasm for teaching and student supervision;
> * ability to teach in departmental BSc and MSc programmes;
> * well-developed didactic skills;
> * excellent command of the English language;
> * experience with or willingness to use innovative teaching methods
>   and (e-learning) technologies;
> * vision on teaching and your own contribution to teaching.
>
> Please note that we are also interested in candidates with a focus on
> teaching.
>
> ## Leadership:
>
> * play an active and cooperative role in the department and the university;
> * willingness to organize scientific events, such as research seminars or
>   teaching seminars;
> * willingness to partake in departmental committees.
>
> The department finds gender balance specifically and diversity in
> a broader sense very important. In recent procedures we attracted
> a significant number of women (three out of five positions). We
> are very keen on appointing more female scientists and therefore
> strongly encourage qualified women to apply.
>
> # Offer
>
> The candidate will be offered a tenure track position, depending
> on experience (0.8 / 1.0 FTE).
>
> Salary depends on qualifications and experience, and ranges
> between 3,111 and 5,405 euro (scale 10 - 12 Collective Labour
> Agreement Dutch Universities) gross per month for a full-time
> employment.
>
> The salary is supplemented with a holiday bonus of 8% and an
> end-of-year bonus of 8.3% per year. We offer flexible employment
> conditions, working-from-home facilities, partially paid parental
> leave, a pension scheme, and collective insurance schemes.
> Facilities for sports and child care are available on our campus,
> which is only 15 minutes away from the historical city center of
> Utrecht.
>
> We offer you the possibility to develop towards a Basic Teaching
> Qualification, supported with educational development programs
> offered by the University. We also offer candidates the
> possibility to travel to conferences.
>
> # About the organization
>
> A better future for everyone. This ambition motivates our
> scientists in executing their leading research and inspiring
> teaching. At Utrecht University, colleagues from various
> disciplines collaborate intensively towards major societal
> themes. Our focus is on Dynamics of Youth, Institutions for Open
> Societies, Life Sciences and Sustainability.
>
> The city of Utrecht is one of the oldest cities in the
> Netherlands, with a charming old center and an internationally
> oriented culture that is strongly influenced by its century-old
> university. Utrecht city has been consistently ranked as one of
> the most livable cities in the Netherlands.
>
> The Faculty of Science consists of six departments: Biology,
> Pharmaceutical Sciences, Information and Computing Sciences,
> Physics and Astronomy, Chemistry and Mathematics. The Faculty is
> home to 5,900 students and nearly 1,600 staff and is
> internationally renowned for the quality of its research. The
> Facu

Re: [Haskell] PSA: `cabal update` command needs manual unsticking

[Michael Snoyman]

On Tue, Jan 2, 2018 at 11:47 AM, Sven Panne  wrote:

> 2018-01-02 2:24 GMT+01:00 Gershom B :
>
>> A recent update to hackage, which fixed up the 01-index.tar.gz file,
>> revealed a bug in existing versions of cabal-install, when index files
>> are cleaned up. This bug means that the `cabal update` command, which
>> updates the hackage index file, will fail silently and leave the old
>> file in place. It is easy to get things working again, but it requires
>> manual intervention. [...]
>
>
> Quick question: Are stack users affected, too, or only cabal users? I'm
> just asking because as a stack user you have 
> ~/.stack/indices/Hackage/01-index.*
> files lying around, too...
>
>
Hey Sven,

Gershom sent me an email about this earlier, and I looked into it. As far
as I can tell, Stack is _not_ affected by this, since—although it uses the
same hackage-security library as cabal-install—it follows a different
codepath outside of hackage-security for downloading tarballs. I'm not 100%
certain Stack is immune, however, so if someone notices a problem, please
report it.

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

Re: [Haskell] PSA: `cabal update` command needs manual unsticking

[Sven Panne]

2018-01-02 2:24 GMT+01:00 Gershom B :

> A recent update to hackage, which fixed up the 01-index.tar.gz file,
> revealed a bug in existing versions of cabal-install, when index files
> are cleaned up. This bug means that the `cabal update` command, which
> updates the hackage index file, will fail silently and leave the old
> file in place. It is easy to get things working again, but it requires
> manual intervention. [...]


Quick question: Are stack users affected, too, or only cabal users? I'm
just asking because as a stack user you have
~/.stack/indices/Hackage/01-index.* files lying around, too...
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Performance impact of GHC profiling?

[Ben Gamari]

"Howard B. Golden via Haskell"  writes:

> Hi,
>
> I have wondered what the approximate execution (not compilation) performance 
> impact (time, space) of compiling all Haskell programs with -prof and -fprof-
> auto compared to regular compilations. For this purpose, I assume that I 
> would 
> run the executables WITHOUT +RTS -p or any other profiling option. In other 
> words, I would make -prof and -fprof-auto the compilation defaults, but only 
> use profiling runtime occasionally.
>
> Does anyone have any data or benchmarks about this? Thanks.
>
While I don't have any hard data, I can say that the severity of the
effect really depends upon the nature of the code and how many cost
centers you insert (either manually or automatically with, say,
-fprof-auto). Cost centers can act as optimization barriers which can
sometimes prevent deforestation. When this happens the effect can be
quite significant. With no cost centers at all I would expect that the
effect of the profiled runtime is quite small (perhaps less than a few
percent?)

Cheers,

- Ben




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

Re: [Haskell] [Announce] ZuriHac 2018: Registration now open

[thomas]

I just learned that ZuriHac will overlap (on Fr-Sa) with the C++ standards 
committee meeting in the very same venue:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/n4673.pdf

The PDF by the way also includes useful hotel and travel information.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Haskell in Leipzig 2017: 1st call for participation

[Wolfgang Jeltsch]

Hi!
Thank you for the suggestion. I will see what we can do.
All the best,
Wolfgang
Am Mittwoch, den 20.09.2017, 13:38 +0700 schrieb Kim-Ee Yeoh:
> Hi Wolfgang,
> 
> May I respectfully suggest that the talks be video recorded and made
> viewable on the internet?
> 
> The benefits are too many to name; not least is the fact that they
> will popularize your conference and increase the turnout for the next
> HaL.
> 
> Best,
> Kim Ee
> 
> 
> On Tuesday, September 19, 2017, Wolfgang Jeltsch 
> info> wrote:
> > Event:Haskell in Leipzig 2017
> > Time: October 26–28, 2017
> > Place:HTWK Leipzig, Germany
> > Homepage: https://hal2017.softbase.org/
> > 
> > 
> > About
> > =
> > 
> > Haskell is a modern functional programming language that allows
> > rapid
> > development of robust and correct software. It is renowned for its
> > expressive type system, its unique approaches to concurrency and
> > parallelism, and its excellent refactoring capabilities. Haskell is
> > both
> > the playing field of cutting-edge programming language research and
> > a
> > reliable base for commercial software development.
> > 
> > The workshop series Haskell in Leipzig (HaL), now in its 12th year,
> > brings together Haskell developers, Haskell researchers, Haskell
> > enthusiasts, and Haskell beginners to listen to talks, take part in
> > tutorials, join in interesting conversations, and hack together. To
> > support the latter, HaL will include a one-day hackathon this year.
> > The
> > workshop will have a focus on functional reactive programming (FRP)
> > this
> > time, while continuing to be open to all aspects of Haskell. As in
> > the
> > previous year, the workshop will be in English.
> > 
> > 
> > Invited Speaker
> > ===
> > 
> >   * Ivan Perez, University of Nottingham, UK
> > 
> > 
> > Invited Performer
> > =
> > 
> >   * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany
> > 
> > 
> > Registration
> > 
> > 
> > Registration information is available on the web page of the local
> > organizers at http://nfa.imn.htwk-leipzig.de/HAL2017/.
> > 
> > 
> > Program Committee
> > =
> > 
> >   * Edward Amsden, Plow Technologies, USA
> >   * Heinrich Apfelmus, Germany
> >   * Jurriaan Hage, Utrecht University, The Netherlands
> >   * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany
> >   * Wolfgang Jeltsch, Tallinn University of Technology, Estonia
> > (chair)
> >   * Andres Löh, Well-Typed LLP, Germany
> >   * Keiko Nakata, SAP SE, Germany
> >   * Henrik Nilsson, University of Nottingham, UK
> >   * Ertuğrul Söylemez, Intelego GmbH, Germany
> >   * Henning Thielemann, Germany
> >   * Niki Vazou, University of Maryland, USA
> >   * Johannes Waldmann, HTWK Leipzig, Germany
> > 
> > 
> > Questions
> > =
> > 
> > If you have any questions, please do not hesitate to contact
> > Wolfgang
> > Jeltsch at wolfgang...@jeltsch.info.
> > ___
> > Haskell mailing list
> > Haskell@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
> > 
> 
> -- 
> -- Kim-Ee___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Haskell-beginners] Restrict type in phantom data-type

[David Feuer]

This is off-topic for this list. This list is for announcements. This
belongs on haskell-c...@haskell.org

On Sep 1, 2017 11:05 AM, "Baa"  wrote:

> David, hello!
>
> 1. Is it the same/different as:
>
>   data family Day a
>   data Sunny
>   data Rainy
>   data instance Day Sunny = SunnyDay deriving Show
>   data instance Day Rainy = RainyDay deriving Show
>
>   ..and here you can not create `Day Int` object because no `Day Int`
>   constructor (but you can create such constructor)
>
> ? Or in case with type families there is possibility to extend it to
> `Day Int` and in case with DayaKinds it's totally impossible?
>
> 2. I read somewhere (on forums) that restrictions on data types... I
> don't remember exactly, but something like they are not real
> restrictions or are related to old extension which is/will be
> deprecated. I'm not sure. Also, I'm not sure is it - in your example -
> restriction (constraint) or something else. Am I wrong?
>
> > This is maybe edging toward haskell-cafe territory, but you can
> > definitely do this in haskell.
> >
> > {-# LANGUAGE DataKinds, KindSignatures #-}
> >
> > data DayType = Sunny | Rainy
> >
> > data Day (a :: DayType) = Day
> >
> >
> > sunnyDay :: Day Sunny
> > sunnyDay = Day
> >
> > rainyDay :: Day Rainy
> > rainyDay = Day
> >
> > -- impossibleDay :: Day ()
> > -- impossibleDay = Day
> >
> > On Fri, Sep 1, 2017 at 10:18 AM, Baa  wrote:
> > > Hello, List!
> > >
> > > For example, I have specialized (right nameis phantom?) type:
> > >
> > >   data Day a = Day { ... no `a` here }
> > >   data Sunny
> > >   data Rainy
> > >
> > >   joyToday :: Day Sunny -> IO ()
> > >   joyToday day = ...
> > >
> > >   melancholyToday :: Day Rainy -> IO ()
> > >   melancholyToday day = ...
> > >
> > > And I can create (in spite of that it's phantom) some day:
> > >
> > >   let day1 = Day {...} :: Day Sunny
> > >   joyToday day1
> > >
> > > but no problem to create `Day Int`, `Day Char`, etc which is
> > > pointless actually (sure "creator"-function can be exported from the
> > > module only, but I'm talking about type-level solution).
> > >
> > > I know that constraints (`... =>`) on data types are
> > > redundant/removed from the language. And I'm not sure how it's
> > > possible to restrict that parameter `a` (I know that it's possible
> > > to Java/C++/Perl6 (not sure), some other languages but how to add
> > > such restriction in Haskell? IMHO type families can help but I'm
> > > not sure how it will look (Sunny, Rainy are "nullary" type, so...).
> > >
> > > Is it possible for Haskell too?
> > >
> > > ===
> > > Best regards, Paul
> > > ___
> > > Beginners mailing list
> > > beginn...@haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> > ___
> > Beginners mailing list
> > beginn...@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Haskell-beginners] Restrict type in phantom data-type

[Baa]

David, hello!

1. Is it the same/different as:

  data family Day a
  data Sunny
  data Rainy
  data instance Day Sunny = SunnyDay deriving Show
  data instance Day Rainy = RainyDay deriving Show

  ..and here you can not create `Day Int` object because no `Day Int`
  constructor (but you can create such constructor)

? Or in case with type families there is possibility to extend it to
`Day Int` and in case with DayaKinds it's totally impossible?

2. I read somewhere (on forums) that restrictions on data types... I
don't remember exactly, but something like they are not real
restrictions or are related to old extension which is/will be
deprecated. I'm not sure. Also, I'm not sure is it - in your example -
restriction (constraint) or something else. Am I wrong?

> This is maybe edging toward haskell-cafe territory, but you can
> definitely do this in haskell.
> 
> {-# LANGUAGE DataKinds, KindSignatures #-}
> 
> data DayType = Sunny | Rainy
> 
> data Day (a :: DayType) = Day
> 
> 
> sunnyDay :: Day Sunny
> sunnyDay = Day
> 
> rainyDay :: Day Rainy
> rainyDay = Day
> 
> -- impossibleDay :: Day ()
> -- impossibleDay = Day
> 
> On Fri, Sep 1, 2017 at 10:18 AM, Baa  wrote:
> > Hello, List!
> >
> > For example, I have specialized (right nameis phantom?) type:
> >
> >   data Day a = Day { ... no `a` here }
> >   data Sunny
> >   data Rainy
> >
> >   joyToday :: Day Sunny -> IO ()
> >   joyToday day = ...
> >
> >   melancholyToday :: Day Rainy -> IO ()
> >   melancholyToday day = ...
> >
> > And I can create (in spite of that it's phantom) some day:
> >
> >   let day1 = Day {...} :: Day Sunny
> >   joyToday day1
> >
> > but no problem to create `Day Int`, `Day Char`, etc which is
> > pointless actually (sure "creator"-function can be exported from the
> > module only, but I'm talking about type-level solution).
> >
> > I know that constraints (`... =>`) on data types are
> > redundant/removed from the language. And I'm not sure how it's
> > possible to restrict that parameter `a` (I know that it's possible
> > to Java/C++/Perl6 (not sure), some other languages but how to add
> > such restriction in Haskell? IMHO type families can help but I'm
> > not sure how it will look (Sunny, Rainy are "nullary" type, so...).
> >
> > Is it possible for Haskell too?
> >
> > ===
> > Best regards, Paul
> > ___
> > Beginners mailing list
> > beginn...@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners  
> ___
> Beginners mailing list
> beginn...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

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

Re: [Haskell] Haskell Digest, Vol 168, Issue 3

[Geraldus]

Wow, looks very promising.

сб, 5 авг. 2017 г. в 17:29, :

> Send Haskell mailing list submissions to
> haskell@haskell.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
> or, via email, send a message with subject or body 'help' to
> haskell-requ...@haskell.org
>
> You can reach the person managing the list at
> haskell-ow...@haskell.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Haskell digest..."
>
>
> Today's Topics:
>
>1. [ANN] brittany - haskell source code formatting tool -
>   hackage release (lennart spitzner)
>
>
> --
>
> Message: 1
> Date: Fri, 4 Aug 2017 15:01:51 +0200
> From: lennart spitzner 
> To: undisclosed-recipients: ;
> Subject: [Haskell] [ANN] brittany - haskell source code formatting
> tool - hackage release
> Message-ID: <14f23926-b296-865d-7eeb-1a232427f...@hexagoxel.de>
> Content-Type: text/plain; charset=utf-8
>
> Greetings,
>
> I am happy to (finally) announce the first hackage release of brittany, a
> configurable haskell source code formatter based on ghc-exactprint [2].
>
> https://hackage.haskell.org/package/brittany
> https://github.com/lspitzner/brittany
>
>
> *Introduction*
>
> Brittany aims to nicely layout the code and retain empty lines and
> comments as
> they appear in the input. For that it uses a fundamentally different
> approach
> (see [7]/theory) than other formatters. The project is not finished, yet it
> already is usable and produces better results than other formatters in many
> cases. Of course these words come from its creator, so see for yourself: I
> have included some examples at the bottom of this mail; see [3] and [4] for
> some more.
>
> I wish to stress that this project will only progress at a very slow speed
> barring support from the community. I hereby offer to work on this and ask
> for funding. See the "future" paragraph below.
>
>
> *Changelog*
>
> Since the "alpha-release" announced previously [5] the most important
> changes
> are:
>
> - Release under the AGPL-v3;
> - Release on hackage;
> - Make horizontal alignment less aggressive by default (see example [6]);
> - Add high-level documentation (see [7]). This might be of interest to
> anyone
>   considering to write a formatter (haskell or even otherwise);
> - Improve testsuite setup;
> - Improve layouting in many many cases and fix various bugs;
> - Add a library interface (this integrates with haskell-ide-engine [8]);
>
> Brittany still..
>
> - does not touch anything other than top-level type signatures and
>   bindings (imports, classes, instances, data decls, .. are not modified);
> - contains some bugs (but it checks its own output for validity and
> aborts);
> - does not handle many "uncommon" syntactic constructs/extentions
>   (e.g. arrow notation);
>
> In preparation of this release the `butcher` and `czipwith` packages were
> published on hackage as well. I will cover those in separate announcements.
>
>
> *Building*
>
> Brittany currently requires ghc-8.0 (no support for previous ghc versions
> is
> planned, but 8.2 will be). Now that this package is on hackage, cabal users
> should be able to install it directly; stack users will currently have to
> clone
> and go from there (a stack.yaml is provided). Detailed building guides for
> cabal, cabal-new and stack are in the project README.
>
> Inclusion in stackage is coming as soon as all dependencies are included.
>
>
> *Known issues*
>
> - Bad performance for large inputs (really noticeable at >1k loc). The
> cause
>   is already determined - quadratic instead of linear complexity in one
>   specific function (see issue #34 [9]). Should be fixable and has high
>   priority.
> - The config (file) lacks documentation.
> - Comments are not always reproduced exactly when reformatting. There is a
> lack
>   of testcases for comments in the testsuite. There is the known case of
>   comments in List/MonadComprehensions that currently breaks idempotency
> (the
>   comments move further left each roundtrip through brittany) where a
> solution
>   will most likely involve some non-trivial changes in ghc-exactprint
>   (see [10]).
> - As mentioned above: only certain module elements are transformed, and
>   not all syntactical constructs are supported. re-layouting of imports,
> data
>   decls, classes and instances are on the radar, but all require a good
> amount
>   o

Re: [Haskell] [Haskell-cafe] Static analysis engineering at Facebook (Clang/OCaml)

[Don Stewart]

Link moved, apply here:
https://www.facebook.com/careers/jobs/a0I120LT8aAEAT



On Thu, Jul 27, 2017 at 12:39 PM, Shannon Sequeira <
shannonseque...@gmail.com> wrote:

> Hi Don, the job link appears to be broken.
>
> Best,
> Shannon Sequeira
>
> On 26 July 2017 at 13:11, Don Stewart  wrote:
>
>> The Infer static analysis team at Facebook is hiring. We have a
>> functional programming engineering role in London to work on the open
>> source Clang/C++ frontend to Infer.
>>
>> Infer is a static analysis suite for C++, Java and Objective C used by
>> thousands of engineers at Facebook and elsewhere to find bugs.
>>
>> The role is a "compiler" role - working on the Clang AST to OCaml, and
>> intermediate phases of Infer to improve our C++ analysis capabilities. Good
>> FP engineering skills (e.g. Haskell or OCaml) are desirable.
>>
>> You should have a working knowledge of C++ semantics, language or
>> compiler design or experience in a range of C++ projects.
>>
>> Infer:
>>
>> http://fbinfer.com/
>>
>> Apply via:
>>
>> https://www.facebook.com/careers/jobs/a0I120LT8aA
>>
>> ___
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Last call for presentations: CUFP 2017, September 7-9, Oxford, UK

[Jasper Van der Jeugt]

We have extended the deadline until Monday (12th of June).

Jasper

On Wed, Jun 7, 2017 at 9:35 PM, Jasper Van der Jeugt  wrote:
> The deadline for CUFP presentations is this friday, the 9th of June.
> This CFP and the form for submitting presentations proposals can be
> found at: http://cufp.org/2017/call-for-presentations.html
>
> 
>
> 2017 Call for Presentations
>
> Workshop for Commercial Users of Functional Programming 2017
> Sponsored by SIGPLAN
> CUFP 2017
> Co-located with ICFP 2017
> Oxford, UK
> September 7-9
> Talk Proposal Submission Deadline: 9 June 2017
>
> The annual CUFP event is a place where people can see how others are
> using functional programming to solve real world problems; where
> practitioners meet and collaborate; where language designers and users
> can share ideas about the future of their favorite language; and where
> one can learn practical techniques and approaches for putting functional
> programming to work.
>
> 
>
> Giving a CUFP Talk
>
> If you have experience using functional languages in a practical
> setting, we invite you to submit a proposal to give a talk at the event.
> We're looking for two kinds of talks:
>
> Retrospective reports are typically 25 minutes long. Now that CUFP has
> run for more than a decade, we intend to invite past speakers to share
> what they’ve learned after a decade spent as commercial users of
> functional programming. We will favour experience reports that include
> technical content.
>
> Technical talks are also 25 minutes long, and should focus on teaching
> the audience something about a particular technique or methodology, from
> the point of view of someone who has seen it play out in practice. These
> talks could cover anything from techniques for building functional
> concurrent applications, to managing dynamic reconfigurations, to design
> recipes for using types effectively in large-scale applications. While
> these talks will often be based on a particular language, they should be
> accessible to a broad range of programmers.
>
> We strongly encourage submissions from people in communities that are
> underrepresented in functional programming, including but not limited to
> women; people of color; people in gender, sexual and romantic
> minorities; people with disabilities; people residing in Asia, Africa,
> or Latin America; and people who have never presented at a conference
> before. We recognize that inclusion is an important part of our ission
> to promote functional programming. So that CUFP can be a safe
> environment in which participants openly exchange ideas, we abide by the
> SIGPLAN Conference Anti-Harassment Policy:
>
> http://www.sigplan.org/Resources/Policies/Anti-harassment
>
> If you are interested in offering a talk, or nominating someone to do
> so, please submit your presentation before 09 June 2017 via the CUFP
> 2017 Presentation Submission Form:
>
> https://goo.gl/forms/KPloANxHHwdiaoVj2
>
> You do not need to submit a paper, just a short proposal for your talk.
> There will be a short scribe's report of the presentations and
> discussions but not of the details of individual talks, as the meeting
> is intended to be more of a discussion forum than a technical
> interchange.
>
> Nevertheless, presentations will be recorded and presenters will be
> expected to sign an ACM copyright release form.
>
> Note that we will need presenters to register for the CUFP workshop and
> travel to Oxford at their own expense. There are some funds available to
> would-be presenters who require assistance in this respect.
>
> 
>
> Program Committee
>
> Alex Lang (Tsuru Capital), co-chair
> Rachel Reese (Mulberry Labs), co-chair
> Garrett Smith (Guild AI)
> Danielle Sucher (Jane Street)
> Jasper Van der Jeugt (Fugue)
> Yukitoshi Suzuki (Ziosoft)
> Evelina Gabasova (University of Cambridge)
> Brian Mitchell (Jet.com)
>
> 
>
> More information
>
> For more information on CUFP, including videos of presentations from
> previous years, take a look at the CUFP website at http://cufp.org. Note
> that presenters, like other attendees, will need to register for the
> event. Acceptance and rejection letters will be sent out by July 15th.
> Guidance on giving a great CUFP talk
>
> Focus on the interesting bits: Think about what will distinguish your
> talk, and what will engage the audience, and focus there. There are a
> number of places to look for those interesting bits.
>
> Setting: FP is pretty well-established in some areas, including formal
> verification, financial processing, and server-side web services. An
> unusual setting can be a source of interest. If you're deploying
> FP-based mobile UIs or buil

Re: [Haskell] How to Get Mailing List Messages without Haskell Digest

[Henk-Jan van Tuyl]

Hi,

You can change from digest to receiving separate messages by changing a
setting at page
https://mail.haskell.org/mailman/listinfo/haskell
, after the question
Would you like to receive list mail batched in a daily digest?
set the radio button to "No"

You might also be interested in Haskell Café, where there is more traffic:
https://mail.haskell.org/mailman/listinfo/haskell-cafe

Regards,
Henk-Jan van Tuyl


On Fri, 02 Jun 2017 14:58:17 +0200, Geraldus  wrote:
[...]

I'm not sure about relation Haskell mailing list and Haskell Digest.
Is it possible to receive messages from list but stop Haskell Digest
subscription?

[...]

--
Folding@home
What if you could share your unused computer power to help find a cure? In
just 5 minutes you can join the world's biggest networked computer and get
us closer sooner. Watch the video.
http://foldingathome.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Deadline extension may 15: Trends in Functional Programming, 19-21 june 2017, University of Kent, Canterbury

[Michael Walker]

If submission is now the 15th, what is the new notification date?

Thanks.

> Submission of draft papers:  ***15 May, 2017*** extension
> Notification:   12 May, 2017
> Registration:   11 June, 2017
> TFP Symposium:  19-21 June, 2017
> Student papers feedback:29 June, 2017
> Submission for formal review:   2 August, 2017
> Notification of acceptance: 3 November, 2017
> Camera ready paper: 2 December, 2017

-- 
Michael Walker (http://www.barrucadu.co.uk)
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] haskell Summer of Code

[Jasper Van der Jeugt]

Sorry for the double mail -- re-sending since my mail bounced for the
haskell mailing list.

Jasper

On Wed, Apr 19, 2017 at 12:10 PM, Jasper Van der Jeugt  
wrote:
> Hey all,
>
> Sorry for the confusion.  As stated in the timeline, the student
> application period begins on the 25th of April, so next week.  At that
> time, a form will be provided on <https://summer.haskell.org/>.  I
> should have added this info explicitly to the homepage -- I will rectify
> that now.
>
> If it is somehow not possible to submit at that time because of schedule
> conflicts, please contact us and we will take of it.
>
> Kind regards
> Jasper Van der Jeugt
>
> On Wed, Apr 19, 2017 at 07:11:17AM +0530, Harendra Kumar wrote:
>> It is surprising that the haskell summer of code webpage does not mention
>> how to or where to submit a proposal. After reading this email I went
>> through the SoC announcement email myself and thus got to
>> https://summer.haskell.org/ which too does not have any details on how to
>> submit proposals, maybe I missed something. However, I could find the
>> following from contacts page on this website:
>>
>> You can reach us by sending an email to committee [AT] haskell.org.
>> Alternatively, you can contact nvazou [AT] cs.umd.edu and m [AT]
>> jaspervdj.be directly.
>>
>> I guess, you can try sending your proposal to these email ids, I have
>> copied them on this email as well.
>>
>> -harendra
>>
>>
>> On 19 April 2017 at 05:14, Bhavishya Desai 
>> wrote:
>>
>> > Hello devs,
>> >
>> > I'm attaching the link of my proposal for summer of code.I'm interested in
>> > IOS app for codeworld.
>> >
>> > Here it is:Proposal
>> > <https://docs.google.com/document/d/1HWTtCZqQdAC9CD9ADCo6CuWfBidunnwi_1vlw5d1nm4/edit?usp=sharing>
>> >
>> > Sorry if it's not the right place for submitting proposals for review, I
>> > couldn't find any appropriate place(even the irc wasn't that active.)
>> >
>> > Waiting for your review,
>> >
>> > Thank YOU.
>> >
>> > ___
>> > Haskell mailing list
>> > Haskell@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>> >
>> >
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] haskell Summer of Code

[Harendra Kumar]

It is surprising that the haskell summer of code webpage does not mention
how to or where to submit a proposal. After reading this email I went
through the SoC announcement email myself and thus got to
https://summer.haskell.org/ which too does not have any details on how to
submit proposals, maybe I missed something. However, I could find the
following from contacts page on this website:

You can reach us by sending an email to committee [AT] haskell.org.
Alternatively, you can contact nvazou [AT] cs.umd.edu and m [AT]
jaspervdj.be directly.

I guess, you can try sending your proposal to these email ids, I have
copied them on this email as well.

-harendra


On 19 April 2017 at 05:14, Bhavishya Desai 
wrote:

> Hello devs,
>
> I'm attaching the link of my proposal for summer of code.I'm interested in
> IOS app for codeworld.
>
> Here it is:Proposal
> 
>
> Sorry if it's not the right place for submitting proposals for review, I
> couldn't find any appropriate place(even the irc wasn't that active.)
>
> Waiting for your review,
>
> Thank YOU.
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Haskell Tools

[Boldizsár Németh]

Thanks for asking, I just added a note that you need to install the 
haskell-tools-daemon package to use the Atom plugin for Haskell Tools.


If you want to run refactorings from a script or just without an editor, 
you can use haskell-tools-cli as well.


On 2017.04.06. 10:40, Ivan Lazar Miljenovic wrote:

Is there support for anything except Atom at this time?

I'm also unsure of what I need to install on my local machine if I
want to try it out (do I need the daemon? or is the cli tool
sufficient?).

On 6 April 2017 at 17:03, Boldizsár Németh  wrote:

Dear Haskellers,

I'm happy to announce a new tool for refactoring Haskell source code.
Check it out: http://haskelltools.org/

Best Regards,
Boldizsár Németh
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell





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

Re: [Haskell] Haskell Tools

[Ivan Lazar Miljenovic]

Is there support for anything except Atom at this time?

I'm also unsure of what I need to install on my local machine if I
want to try it out (do I need the daemon? or is the cli tool
sufficient?).

On 6 April 2017 at 17:03, Boldizsár Németh  wrote:
> Dear Haskellers,
>
> I'm happy to announce a new tool for refactoring Haskell source code.
> Check it out: http://haskelltools.org/
>
> Best Regards,
> Boldizsár Németh
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] regex: a toolkit for regex-base

[Chris Dornan]

Thanks John,

Feedback is important. Please do let us know if you spot anything we have 
missed.

Chris


On 09/03/2017, 20:04, "John Wiegley"  wrote:

> "CD" == Chris Dornan  writes:

CD> I am pleased to announce the regex package, a regular expression toolkit
CD> for regex-base with:

Thank you, I've wanted this since forever, since every alternative is either
too difficult to use, missing some key feature (like proper unicode 
support),
or has undesirable external dependencies.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2



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

Re: [Haskell] regex: a toolkit for regex-base

[John Wiegley]

> "CD" == Chris Dornan  writes:

CD> I am pleased to announce the regex package, a regular expression toolkit
CD> for regex-base with:

Thank you, I've wanted this since forever, since every alternative is either
too difficult to use, missing some key feature (like proper unicode support),
or has undesirable external dependencies.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [ANN] Change of ownership for VTY

[Simon Michael]

On 12/24/16 1:18 PM, Jonathan Daugherty wrote:

The (former) owner of VTY here. Unfortunately, I don't have the
resources to continue to contribute. Jonathan Daugherty has stepped up
in my absence to provide excellent improvements and support. He is now
the official owner/maintainer of VTY.

Accordingly, the repository has moved to my GitHub account and is now
located at

https://github.com/jtdaugherty/vty

NOTE: I am seeking someone to help with maintenance of Vty on Windows
systems. I don't have the resources to ensure that Vty builds or passes
its test suite on Windows, so anyone with the resources and the
motivation to help with this should contact me!

Thanks to Corey for maintaing Vty for many years and for being so
helpful to me when I was starting to contribute!


Thank you very much for the excellent library, Corey! (and now Jonathan).

I hope a Windows user does step up and help complete the work already 
done[1], completing Haskell's cross-platform text UI story!


[1] https://github.com/jtdaugherty/vty/pull/1


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

Re: [Haskell] [ANN] Change of ownership for VTY

[Jonathan Daugherty]

> The (former) owner of VTY here. Unfortunately, I don't have the
> resources to continue to contribute. Jonathan Daugherty has stepped up
> in my absence to provide excellent improvements and support. He is now
> the official owner/maintainer of VTY.

Accordingly, the repository has moved to my GitHub account and is now
located at

https://github.com/jtdaugherty/vty

NOTE: I am seeking someone to help with maintenance of Vty on Windows
systems. I don't have the resources to ensure that Vty builds or passes
its test suite on Windows, so anyone with the resources and the
motivation to help with this should contact me!

Thanks to Corey for maintaing Vty for many years and for being so
helpful to me when I was starting to contribute!

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

Re: [Haskell] [Haskell-community] Call for Haskell.org Committee Nominations

[Gershom B]

We're starting the discussion now. Ideally we'll wrap it up within
seven days or so.

--Gershom

On Mon, Dec 5, 2016 at 4:54 PM, Noon van der Silk  wrote:
> Out of interest, when will the new committee members be announced?
>
> On Sat, Nov 12, 2016 at 9:29 AM, Gershom B  wrote:
>>
>> Dear Haskellers,
>>
>> It is time to put out a call for new nominations (typically but not
>> necessarily self-nominations) to the haskell.org committee. We have
>> four members of our committee due for retirement -- Adam Foltzer,
>> Nicolas Wu, Andres Loeh, and Edward Kmett (who is stepping down
>> early). As per our bylaws, three of the slots will be for regular
>> three year terms, and one will be a short one year term to fill out
>> the remainder of Edward's.
>>
>> To nominate yourself, please send an email to committee at haskell.org
>> by December 2, 2016. The retiring members are eligible to re-nominate
>> themselves. Please feel free to include any information about yourself
>> that you think will help us to make a decision.
>>
>> The Haskell.org committee serves as a board of directors for
>> Haskell.org, a 501(c)3 nonprofit which oversees technical and
>> financial resources related to Haskell community infrastructure.
>>
>> Being a member of the committee does not necessarily require a
>> significant amount of time, but committee members should aim to be
>> responsive during discussions when the committee is called upon to
>> make a decision. Strong leadership, communication, and judgement are
>> very important characteristics for committee members. The role is
>> about setting policy, providing direction/guidance for Haskell.org
>> infrastructure, planning for the long term, and being fiscally
>> responsible with the Haskell.org funds (and donations). As overseers
>> for policy regarding the open source side of Haskell, committee
>> members must also be able to set aside personal or business related
>> bias and make decisions with the good of the open source Haskell
>> community in mind.
>>
>> We seek a broad representation from different segments of the Haskell
>> world -- including but not limited to those focused on education,
>> those focused on industrial applications, those with background in
>> organizing users-groups, and those focused directly on our technical
>> infrastructure.
>>
>> More details about the committee's roles and responsibilities are on
>>
>> https://wiki.haskell.org/Haskell.org_committee
>>
>> If you have any questions about the process, please feel free to
>> e-mail us at committee at haskell.org, or contact one of us
>> individually.
>>
>> Best,
>> Gershom Bazerman
>> ___
>> Haskell-community mailing list
>> haskell-commun...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
>
>
>
>
> --
> Noon Silk, ن
>
> https://silky.github.io/
>
> "Every morning when I wake up, I experience an exquisite joy — the joy
> of being this signature."
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] problem installing Stack on Ubuntu Virtual Machine

[Michael Snoyman]

Adding the haskell-stack mailing list, that's more focused than
haskell@haskell.org. Just leaving this message on that mailing list in case
someone in the future wonders where this conversation is moving to.
Short answer: try adding the following to ~/.stack/config.yaml:

package-indices:
- name: Hackage
  download-prefix: https://s3.amazonaws.com/hackage.fpcomplete.com/package/
  http: https://s3.amazonaws.com/hackage.fpcomplete.com/00-index.tar.gz

Longer answer: most likely it wasn't completely stalled, just going _very_
slowly. We've had some reports from users - usually depending on geography
- of slow downloads of the cabal file Git repo. The snippet above will
switch you into an HTTPS download, which may be faster.

On Sat, Dec 3, 2016 at 10:21 PM, Nikos Karagiannidis  wrote:

> Hi all,
>
> I am tryning to install Stack on an 64-bit Ubuntu VM (Ubuntu 16.04.1 LTS).
>
> I have followed strictly all the steps that are mentioned in:
>
> https://docs.haskellstack.org/en/stable/install_and_upgrade/#ubuntu
>
> the installation completes OK and I get the following stack version
> installed:
>
> *$ stack --version*
> *Version 1.2.0, Git revision 241cd07d576d9c0c0e712e83d947e3dd64541c42
> (4054 commits) x86_64 hpack-0.14.0*
>
> But, when I run "stack setup"  it tries to update package index and then
> it stucks there forever!
>
> *$ stack setup*
> *Run from outside a project, using implicit global project config*
> *Using resolver: lts-7.11 from implicit global project's config file:
> /home/nikos/.stack/global-project/stack.yaml*
> *Updating package index Hackage (mirrored at
> https://github.com/commercialhaskell/all-cabal-hashes.git
> ) ...*
>
> any suggestions?
>
> thank you in advance!
>
> Nikos
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell