From daniel.trstenjak at gmail.com  Mon Feb  1 09:10:33 2021
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Mon, 1 Feb 2021 10:10:33 +0100
Subject: [Haskell-cafe] Project builds with stack,
 not with cabal. How to diagnose?
In-Reply-To: <CAKzCsfgwt+Kk1JW=jO3QbXd6HyEbHKW9-EAt02dyzA==z_syQA@mail.gmail.com>
References: <CAKzCsfgwt+Kk1JW=jO3QbXd6HyEbHKW9-EAt02dyzA==z_syQA@mail.gmail.com>
Message-ID: <20210201091033.GA5592@octa>

Hi Han,

because stack uses the cabal library for the building of the project, it
might be possible to use cabal-bounds[1] to update the version bounds of
the dependencies in the cabal file, after a stack build has been executed.

So just calling 'cabal-bounds update' might do the job.

Greetings,
Daniel

[1] https://github.com/dan-t/cabal-bounds

From sylvain at haskus.fr  Mon Feb  1 09:51:00 2021
From: sylvain at haskus.fr (Sylvain Henry)
Date: Mon, 1 Feb 2021 10:51:00 +0100
Subject: [Haskell-cafe] TH: quoting name and value
Message-ID: <05cf2ca9-65a0-8861-169b-ce7b71ecb837@haskus.fr>

Hi,

I have the following kind of template haskell code:

module Foo where
foo :: String -> Name -> Q [Dec]
foo str name = return []

module Bar where
bar :: String
bar = "whatever"

module FooBar where
import Foo
import Bar
foo bar 'bar

It works great as in `foo` I can use both bar's Name and bar's value 
computed at compile time.

But it's unsafe for my purpose because a user could call: `foo 
"fakeBarValue"  'bar`

So the question is: is there a way to write `foo` so that it can only be 
used safely?


If not, I guess it could be possible to add a new kind of quote to TH, 
something like:

data Named a = Named Name a -- constructor not exported so that Named 
values can't be forged by users.

[namedValue||bar||] :: Named String -- new quote

What do you think?

Thanks,
Sylvain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210201/120e1187/attachment.html>

From rae at richarde.dev  Mon Feb  1 17:06:14 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 1 Feb 2021 17:06:14 +0000
Subject: [Haskell-cafe] TH: quoting name and value
In-Reply-To: <05cf2ca9-65a0-8861-169b-ce7b71ecb837@haskus.fr>
References: <05cf2ca9-65a0-8861-169b-ce7b71ecb837@haskus.fr>
Message-ID: <010f01775e8f20f5-a685a432-6400-4e77-bd69-43669b9e97e9-000000@us-east-2.amazonses.com>

Hi Sylvain,

I think you're after https://gitlab.haskell.org/ghc/ghc/-/issues/14474. There is some real work to do there, but it should be quite possible.

Richard

> On Feb 1, 2021, at 4:51 AM, Sylvain Henry <sylvain at haskus.fr> wrote:
> 
> Hi,
> 
> I have the following kind of template haskell code:
> 
> module Foo where
> foo :: String -> Name -> Q [Dec]
> foo str name = return []
> 
> module Bar where
> bar :: String
> bar = "whatever"
> 
> module FooBar where
> import Foo
> import Bar
> foo bar 'bar
> It works great as in `foo` I can use both bar's Name and bar's value computed at compile time.
> 
> But it's unsafe for my purpose because a user could call: `foo "fakeBarValue"  'bar`
> 
> So the question is: is there a way to write `foo` so that it can only be used safely?
> 
> 
> If not, I guess it could be possible to add a new kind of quote to TH, something like:
> 
> data Named a = Named Name a -- constructor not exported so that Named values can't be forged by users.
> 
> [namedValue||bar||] :: Named String -- new quote
> 
> What do you think?
> Thanks,
> Sylvain
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210201/3d6986d6/attachment.html>

From nikivazou at gmail.com  Tue Feb  2 09:24:20 2021
From: nikivazou at gmail.com (Niki Vazou)
Date: Tue, 2 Feb 2021 10:24:20 +0100
Subject: [Haskell-cafe] PhD position at IMDEA Software Institute
Message-ID: <CAG9wkeVvz9rzgbwyiODTmmyt6d_wZBLp5ozf4E+pVrbzcVrS3g@mail.gmail.com>

Hey Haskellers,

Applications are invited for a PhD position at the IMDEA Software
Institute, Madrid, Spain. The selected candidate will work under my
supervision on the theory and practise of refinement types.

Application deadline is March 15.
More information are available here:
https://software.imdea.org/open_positions/2021-02-phd-refinements.html

Best,
Niki Vazou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210202/ed16e450/attachment.html>

From icfp.publicity at googlemail.com  Tue Feb  2 15:57:39 2021
From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt)
Date: Tue, 02 Feb 2021 10:57:39 -0500
Subject: [Haskell-cafe] Call for Papers: PACMPL issue ICFP 2021
Message-ID: <6019767355a1f_c46e221c1428@homer.mail>


               PACMPL Volume 5, Issue ICFP 2021
                           Call for Papers

           Accepted papers to be invited for presentation at
The 26th ACM SIGPLAN International Conference on Functional Programming
                            To Be Held Virtualy
                      http://icfp21.sigplan.org/

### Important dates

Submissions due:    2 March 2021 (Tuesday) Anywhere on Earth
                   https://icfp21.hotcrp.com
Author response:    20 April (Tuesday) - 23 April (Friday) 17:00 UTC
Notification:       7 May (Friday)
Final copy due:     30 June (Wednesday)
Conference:         22 August (Sunday) - 27 August (Friday)

### About PACMPL

Proceedings of the ACM on Programming Languages (PACMPL
<https://pacmpl.acm.org/>) is a Gold Open Access journal publishing
research on all aspects of programming languages, from design to
implementation and from mathematical formalisms to empirical
studies. Each issue of the journal is devoted to a particular subject
area within programming languages and will be announced through
publicized Calls for Papers, like this one.

### Scope

[PACMPL](https://pacmpl.acm.org/) issue ICFP 2021 seeks original
papers on the art and science of functional programming. Submissions
are invited on all topics from principles to practice, from
foundations to features, and from abstraction to application. The
scope includes all languages that encourage functional programming,
including both purely applicative and imperative languages, as well as
languages with objects, concurrency, or parallelism. Topics of
interest include (but are not limited to):

* Language Design: concurrency, parallelism, and distribution;
   modules; components and composition; metaprogramming; macros;
   pattern matching; type systems; type inference; dependent types;
   session types; gradual typing; refinement types; interoperability;
   domain-specific languages; imperative programming; object-oriented
   programming; logic programming; probabilistic programming;
   reactive programming; generic programming; bidirectional
   programming.

* Implementation: abstract machines; virtual machines;
   interpretation; compilation; compile-time and run-time
   optimization; garbage collection and memory management; runtime
   systems; multi-threading; exploiting parallel hardware; interfaces
   to foreign functions, services, components, or low-level machine
   resources.

* Software-Development Techniques: algorithms and data structures;
   design patterns; specification; verification; validation; proof
   assistants; debugging; testing; tracing; profiling; build systems;
   program synthesis.

* Foundations: formal semantics; lambda calculus; program
   equivalence; rewriting; type theory; logic; category theory;
   monads; continuations; control; state; effects; names and binding;
   program verification.

* Analysis and Transformation: control flow; data flow; abstract
   interpretation; partial evaluation; program calculation.

* Applications: symbolic computing; formal-methods tools; artificial
   intelligence; systems programming; distributed systems and web
   programming; hardware design; databases; XML processing;
   scientific and numerical computing; graphical user interfaces;
   graphics and multimedia; GPU programming; scripting; system
   administration; security.

* Education: teaching introductory programming; parallel
   programming; mathematical proof; algebra.

Submissions will be evaluated according to their relevance,
correctness, significance, originality, and clarity. Each submission
should explain its contributions in both general and technical terms,
clearly identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. The technical
content should be accessible to a broad audience.

PACMPL issue ICFP 2021 also welcomes submissions in two separate
categories — Functional Pearls and Experience Reports — that must be
marked as such when submitted and that need not report original
research results. Detailed guidelines on both categories are given at
the end of this call.

Please contact the associate editor if you have questions or are
concerned about the appropriateness of a topic.


### Preparation of submissions

**Deadline**: The deadline for submissions is **Tuesday, March 2, 2021**,
Anywhere on Earth (<https://www.timeanddate.com/time/zones/aoe>).
This deadline will be strictly enforced.

**Formatting**: Submissions must be in PDF format, printable in black
and white on US Letter sized paper, and interpretable by common PDF
tools. All submissions must adhere to the "ACM Small" template that is
available (in both LaTeX and Word formats) from
<https://www.acm.org/publications/authors/submissions>. 

There is a limit of **25 pages for a full paper or Functional Pearl**
and **12 pages for an Experience Report**; in either case, the
bibliography will not be counted against these limits. Submissions
that exceed the page limits or, for other reasons, do not meet the
requirements for formatting, will be summarily rejected. Supplementary
material can and should be **separately** submitted (see below).

See also PACMPL's Information and Guidelines for Authors at
<https://pacmpl.acm.org/authors.cfm>.

**Submission**: Submissions will be accepted at <https://icfp21.hotcrp.com/>

Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.

**Author Response Period**: Authors will have a 72-hour period,
starting at 17:00 UTC on **Tuesday, April 20, 2021**, to read reviews
and respond to them.

**Supplementary Material**: Authors have the option to attach
supplementary material to a submission, on the understanding that
reviewers may choose not to look at it. This supplementary material
should **not** be submitted as part of the main document; instead, it
should be uploaded as a **separate** PDF document or tarball.

Supplementary material should be uploaded **at submission time**, not
by providing a URL in the paper that points to an external repository.

Authors are free to upload both anonymized and non-anonymized
supplementary material. Anonymized supplementary material will be
visible to reviewers immediately; non-anonymized supplementary
material will be revealed to reviewers only after they have submitted
their review of the paper and learned the identity of the author(s).

**Authorship Policies**: All submissions are expected to comply with
the ACM Policies for Authorship that are detailed at
<https://www.acm.org/publications/authors/information-for-authors>.

**Republication Policies**: Each submission must adhere to SIGPLAN's
republication policy, as explained on the web at
<http://www.sigplan.org/Resources/Policies/Republication>.

### Review Process

This section outlines the two-stage process with lightweight
double-blind reviewing that will be used to select papers for PACMPL
issue ICFP 2021.  We anticipate that there will be a need to clarify
and expand on this process, and we will maintain a list of frequently
asked questions and answers on the PACMPL issue website to address
common concerns.

**PACMPL issue ICFP 2021 will employ a two-stage review process.** The
 first stage in the review process will assess submitted papers using
 the criteria stated above and will allow for feedback and input on
 initial reviews through the author response period mentioned
 previously. As a result of the review process, a set of papers will be
 conditionally accepted and all other papers will be rejected.
 Authors will be notified of these decisions on **May 7, 2021**.

Authors of conditionally accepted papers will be provided with
committee reviews along with a set of mandatory revisions. After four
weeks (June 4, 2021), the authors will provide a second
submission. The second and final reviewing phase assesses whether the
mandatory revisions have been adequately addressed by the authors and
thereby determines the final accept/reject status of the paper. The
intent and expectation is that the mandatory revisions can be
addressed within four weeks and hence that conditionally accepted
papers will in general be accepted in the second phase.

The second submission should clearly identify how the mandatory
revisions were addressed. To that end, the second submission must be
accompanied by a cover letter mapping each mandatory revision request
to specific parts of the paper. The cover letter will facilitate a
quick second review, allowing for confirmation of final acceptance
within two weeks. Conversely, the absence of a cover letter will be
grounds for the paper’s rejection.

**PACMPL issue ICFP 2021 will employ a lightweight double-blind
 reviewing process.** To facilitate this, submitted papers must
 adhere to two rules:

 1. **author names and institutions must be omitted**, and
 2. **references to authors' own related work should be in the third
 person** (e.g., not "We build on our previous work ..." but rather
 "We build on the work of ...").

The purpose of this process is to help the reviewers come to an
initial judgement about the paper without bias, not to make it
impossible for them to discover the authors if they were to
try. Nothing should be done in the name of anonymity that weakens the
submission or makes the job of reviewing the paper more difficult
(e.g., important background references should not be omitted or
anonymized). In addition, authors should feel free to disseminate
their ideas or draft versions of their paper as they normally
would. For instance, authors may post drafts of their papers on the
web or give talks on their research ideas.

### Information for Authors of Accepted Papers

* As a condition of acceptance, final versions of all papers must
 adhere to the new ACM Small format. The page limit for the final
 versions of papers will be increased by two pages to help authors
 respond to reviewer comments and mandatory revisions: **27 pages
 plus bibliography for a regular paper or Functional Pearl, 14 pages
 plus bibliography for an Experience Report**.

* Authors of accepted submissions will be required to agree to one of
 the three ACM licensing options: open access on payment of a fee
 (**recommended**, and SIGPLAN can cover the cost as described next);
 copyright transfer to ACM; or retaining copyright but granting ACM
 exclusive publication rights.  Further information about ACM author
 rights is available from <http://authors.acm.org>.

* PACMPL is a Gold Open Access journal, and authors are encouraged to
  publish their work under a CC-BY license. Gold Open Access
  guarantees permanent free online access to the definitive version in
  the ACM Digital Library, and the recommended CC-BY option also
  allows anyone to copy and distribute the work with attribution.
  Gold Open Access has been made possible by generous funding through
  ACM SIGPLAN, which will cover all open access costs in the event
  authors cannot. Authors who can cover the costs may do so by paying
  an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM
  Headquarters are committed to exploring routes to making Gold Open
  Access publication both affordable and sustainable.

* ACM offers authors a range of copyright options, one of which is
 Creative Commons CC-BY publication; this is the option recommended
 by the PACMPL editorial board. A reasoned argument in favour of this
 option can be found in the article [Why
 CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open
 Access Scholarly Publishers Association.

* ACM Author-Izer is a unique service that enables ACM authors to
 generate and post links on either their home page or institutional
 repository for visitors to download the definitive version of their
 articles from the ACM Digital Library at no charge. Downloads
 through Author-Izer links are captured in official ACM statistics,
 improving the accuracy of usage and impact
 measurements. Consistently linking to the definitive version of an
 ACM article should reduce user confusion over article
 versioning. After an article has been published and assigned to the
 appropriate ACM Author Profile pages, authors should visit
 <http://www.acm.org/publications/acm-author-izer-service> to learn
 how to create links for free downloads from the ACM DL.

* The official publication date is the date the papers are made
 available in the ACM Digital Library. This date may be up to *two
 weeks prior* to the first day of the conference. The official
 publication date affects the deadline for any patent filings related
 to published work.

* Authors of each accepted submission are invited to attend and be
 available for the presentation of that paper at the conference. The
 schedule for presentations will be determined and shared with authors
 after the full program has been selected.



### Artifact Evaluation

Authors of papers that are conditionally accepted in the first phase
of the review process will be encouraged (but not required) to submit
supporting materials for Artifact Evaluation. These items will then be
reviewed by an Artifact Evaluation Committee, separate from the paper
Review Committee, whose task is to assess how the artifacts support
the work described in the associated paper. Papers that go through the
Artifact Evaluation process successfully will receive a seal of
approval printed on the papers themselves. Authors of accepted papers
will be encouraged to make the supporting materials publicly available
upon publication of the papers, for example, by including them as
"source materials" in the ACM Digital Library.  An additional seal
will mark papers whose artifacts are made available, as outlined in
the ACM guidelines for artifact badging.

Participation in Artifact Evaluation is voluntary and will not
influence the final decision regarding paper acceptance.

### Special categories of papers

In addition to research papers, PACMPL issue ICFP solicits two kinds
of papers that do not require original research contributions:
Functional Pearls, which are full papers, and Experience Reports,
which are limited to half the length of a full paper. Authors
submitting such papers should consider the following guidelines.

#### Functional Pearls

A Functional Pearl is an elegant essay about something related to
functional programming. Examples include, but are not limited to:

 * a new and thought-provoking way of looking at an old idea

 * an instructive example of program calculation or proof

 * a nifty presentation of an old or new data structure

 * an interesting application of functional programming techniques

 * a novel use or exposition of functional programming in the classroom

While pearls often demonstrate an idea through the development of a
short program, there is no requirement or expectation that they do
so. Thus, they encompass the notions of theoretical and educational
pearls.

Functional Pearls are valued as highly and judged as rigorously as
ordinary papers, but using somewhat different criteria. In particular,
a pearl is not required to report original research, but, it should be
concise, instructive, and entertaining. A pearl is likely to be
rejected if its readers get bored, if the material gets too
complicated, if too much specialized knowledge is needed, or if the
writing is inelegant. The key to writing a good pearl is polishing.

A submission that is intended to be treated as a pearl must be marked
as such on the submission web page, and should contain the words
"Functional Pearl" somewhere in its title or subtitle. These steps
will alert reviewers to use the appropriate evaluation
criteria. Pearls will be combined with ordinary papers, however, for
the purpose of computing the conference's acceptance rate.

#### Experience Reports

The purpose of an Experience Report is to help create a body of
published, refereed, citable evidence that functional programming
really works -- or to describe what obstacles prevent it from
working.

Possible topics for an Experience Report include, but are not limited to:

 * insights gained from real-world projects using functional programming

 * comparison of functional programming with conventional programming
   in the context of an industrial project or a university curriculum

 * project-management, business, or legal issues encountered when
   using functional programming in a real-world project

 * curricular issues encountered when using functional programming in
   education

 * real-world constraints that created special challenges for an
   implementation of a functional language or for functional
   programming in general

An Experience Report is distinguished from a normal PACMPL issue ICFP
paper by its title, by its length, and by the criteria used to
evaluate it.

 * Both in the papers and in any citations, the title of each
   accepted Experience Report must end with the words "(Experience
   Report)" in parentheses. The acceptance rate for Experience
   Reports will be computed and reported separately from the rate for
   ordinary papers.

 * Experience Report submissions can be at most 12 pages long,
   excluding bibliography.

 * Each Experience Report accepted to the PACMPL issue will be
   presented at the conference, but depending on the number of
   Experience Reports and regular papers accepted, authors of
   Experience reports may be asked to give shorter talks.

 * Because the purpose of Experience Reports is to enable our
   community to accumulate a body of evidence about the efficacy of
   functional programming, an acceptable Experience Report need not
   add to the body of knowledge of the functional-programming
   community by presenting novel results or conclusions. It is
   sufficient if the Report states a clear thesis and provides
   supporting evidence. The thesis must be relevant to the PACMPL
   issue, but it need not be novel.

The review committee will accept or reject Experience Reports based on
whether they judge the evidence to be convincing. Anecdotal evidence
will be acceptable provided it is well argued and the author explains
what efforts were made to gather as much evidence as
possible. Typically, more convincing evidence is obtained from papers
which show how functional programming was used than from papers which
only say that functional programming was used. The most convincing
evidence often includes comparisons of situations before and after the
introduction or discontinuation of functional programming. Evidence
drawn from a single person's experience may be sufficient, but more
weight will be given to evidence drawn from the experience of groups
of people.

An Experience Report should be short and to the point: it should make
a claim about how well functional programming worked on a particular
project and why, and produce evidence to substantiate this claim. If
functional programming worked in this case in the same ways it has
worked for others, the paper need only summarize the results;
the main part of the paper should discuss how well it worked and in
what context. Most readers will not want to know all the details of
the project and its implementation, but the paper should characterize
the project and its context well enough so that readers can judge to
what degree this experience is relevant to their own projects. The
paper should take care to highlight any unusual aspects of the
project. Specifics about the project are more valuable than
generalities about functional programming; for example, it is more
valuable to say that the team delivered its software a month ahead of
schedule than it is to say that functional programming made the team
more productive.

If the paper not only describes experience but also presents new
technical results, or if the experience refutes cherished beliefs of
the functional-programming community, it may be better to submit it as
a full paper, which will be judged by the usual criteria of novelty,
originality, and relevance. The associate editor will be happy to
advise on any concerns about which category to submit to.



### ICFP Organizers

General Chair: Sukyoung Ryu (KAIST, South Korea)

Accessibility Co-Chairs: Lindsey Kuper (UC Santa Cruz, USA), Kathrin
Stark (Princeton University, USA)
Artifact Evaluation Co-Chairs: Gabriel Scherer (INRIA Saclay, France),
Brent Yorgey (Hendrix College, USA)
Industrial Relations Co-Chairs: Alan Jeffrey (Roblox, USA),
Simon Marlow (Facebook, England)
Programming Contest Co-Organisers: Alex Lang, Jasper Van der Jeugt
(Fugue, Switzerland)
Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA)
Student Research Competition Chair: Anders Miltner (University of
Texas, USA)
Student Volunteer Co-Chairs: Lily Bryant (University of British
Columbia, Canada), Jaemin Hong (KAIST, South Korea), Hanneli Tavante
(McGill University, Canada)
Video Co-Chairs: Leif Andersen (Northeastern University, USA),
Benjamin Chung (Northeastern University, USA)
Workshops Co-Chairs: Leonidas Lampropoulos (University of Maryland, USA),
Zoe Paraskevopoulou (Princeton University, USA)



### PACMPL Volume 5, Issue ICFP 2021

Associate Editor: Ronald Garcia, (University of British Columbia, Canada)

Review Committee:

Zena Ariola (University of Oregon, USA)
Stephanie Balzer (Carnegie Mellon University, USA)
Matteo Cimini (UMass Lowell, USA)
Youyou Cong (Tokyo Institute of Technology, Japan)
Harley Eades (University of Augusta, USA)
Andrew Gordon (Microsoft Research & University of Edinburgh, United Kingdom)
Benjamin Greenman (Brown University, USA)
Arjun Guha (Northeastern University, USA)
Jurriaan Hage (Utrecht, The Netherlands)
Favonia  (University of Minnesota, USA)
Suresh Jagannathan (Purdue University, USA)
Patricia Johann (Appalachian State University, USA)
Ralf Jung (Max Planck Institute, Germany)
Ekaterina Komendantskaya (Heriot-Watt, Scotland)
Leonidas Lampropoulos (University of Maryland, USA)
Kazutaka Matsuda (Tohoku University, Japan)
Akimasa Morihata (Univeristy of Tokyo, Japan)
Stefan Muller (Illinois Institute of Technology, USA)
Max New (Wesleyan University, USA)
Rishiyur Nikhil (Bluespec , USA)
Cyrus Omar (University of Michigan, USA)
Brigitte Pientka (McGill University, Canada)
Norman Ramsey (Tufts University, USA)
Christine Rizkallah (University of New South Wales, Australia)
Taro Sekiyama (National Institute for Informatics, Japan)
Eijiro Sumii (Tohoku University, Japan)
Amin Timany (Aarhus University, Denmark)
Mitchell Wand (Northeastern University, USA)
Steve Zdancewic (University of Pennsylvania, USA)

From sylvain at haskus.fr  Tue Feb  2 18:17:38 2021
From: sylvain at haskus.fr (Sylvain Henry)
Date: Tue, 2 Feb 2021 19:17:38 +0100
Subject: [Haskell-cafe] TH: quoting name and value
In-Reply-To: <010f01775e8f20f5-a685a432-6400-4e77-bd69-43669b9e97e9-000000@us-east-2.amazonses.com>
References: <05cf2ca9-65a0-8861-169b-ce7b71ecb837@haskus.fr>
 <010f01775e8f20f5-a685a432-6400-4e77-bd69-43669b9e97e9-000000@us-east-2.amazonses.com>
Message-ID: <47c7c968-fb89-1cdc-10c2-059108b06729@haskus.fr>

Hi Richard,

Thanks for the pointer. It's not exactly what I am after though because 
I don't need the RHS (AST) of `bar` in my example but the result of 
running it at compile time. I think it should be simpler than reifying a 
Name into a TH AST.

I will open a new ticket.
Thanks,
Sylvain


On 01/02/2021 18:06, Richard Eisenberg wrote:
> Hi Sylvain,
>
> I think you're after https://gitlab.haskell.org/ghc/ghc/-/issues/14474 
> <https://gitlab.haskell.org/ghc/ghc/-/issues/14474>. There is some 
> real work to do there, but it should be quite possible.
>
> Richard
>
>> On Feb 1, 2021, at 4:51 AM, Sylvain Henry <sylvain at haskus.fr 
>> <mailto:sylvain at haskus.fr>> wrote:
>>
>> Hi,
>>
>> I have the following kind of template haskell code:
>>
>> module Foo where
>> foo :: String -> Name -> Q [Dec]
>> foo str name = return []
>>
>> module Bar where
>> bar :: String
>> bar = "whatever"
>>
>> module FooBar where
>> import Foo
>> import Bar
>> foo bar 'bar
>>
>> It works great as in `foo` I can use both bar's Name and bar's value 
>> computed at compile time.
>>
>> But it's unsafe for my purpose because a user could call: `foo 
>> "fakeBarValue"  'bar`
>>
>> So the question is: is there a way to write `foo` so that it can only 
>> be used safely?
>>
>>
>> If not, I guess it could be possible to add a new kind of quote to 
>> TH, something like:
>>
>> data Named a = Named Name a -- constructor not exported so that Named 
>> values can't be forged by users.
>>
>> [namedValue||bar||] :: Named String -- new quote
>>
>> What do you think?
>>
>> Thanks,
>> Sylvain
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe 
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210202/1cec9491/attachment.html>

From ben.franksen at online.de  Thu Feb  4 15:08:07 2021
From: ben.franksen at online.de (Ben Franksen)
Date: Thu, 4 Feb 2021 16:08:07 +0100
Subject: [Haskell-cafe] International Conference on Recent Theories and
 Applications in Transportation and Mobility - (RTATM 2021) Prague
In-Reply-To: <003e01d6f5b6$ead18160$c0748420$@confscience.com>
References: <003e01d6f5b6$ead18160$c0748420$@confscience.com>
Message-ID: <rvh2kn$bf$1@ciao.gmane.io>

Clearly junk/pseudo science. I suggest blocking confscience.com from
haskell lists.

Cheers
Ben


From rudy at matela.com.br  Fri Feb  5 17:00:24 2021
From: rudy at matela.com.br (Rudy Matela)
Date: Fri, 5 Feb 2021 14:00:24 -0300
Subject: [Haskell-cafe] Haskell exercises for beginners
Message-ID: <CALCD0B-X7sM_7ZRiA_Nwh-DZHrt-3aeTCwqCC5U-y+MqgGc4_w@mail.gmail.com>

Hello Haskell Café,

I have been working on a website aimed at teaching programming and Computer
Science through quick examples.  It is called "Computer Science by Example
<https://cscx.org/>": https://cscx.org/

The exercises start very simple (e.g. read two numbers and print their sum
<https://cscx.org/add>) then increase in difficulty and complexity
gradually (e.g. solving the change-making problem <https://cscx.org/cash>).
The website has an "online judge" functionality where students can submit
their solutions which are tested and graded automatically without human
intervention.  It currently supports solutions in *Haskell* and
additionally: Python, C, C++, C#, Java, JavaScript, Lua and Ruby.

The exercises are useful not only to first time programmers, but also to
experienced programmers trying to learn a new language such as Haskell.

Check it out at cscx.org.  The exercises are freely available for anyone to
try.

Best Regards,
Rudy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210205/0579bedd/attachment.html>

From matteo at confscience.com  Sat Feb  6 08:57:25 2021
From: matteo at confscience.com (matteo at confscience.com)
Date: Sat, 6 Feb 2021 09:57:25 +0100
Subject: [Haskell-cafe] International Conference on Applied Data Science and
	Intelligence - (ADSI 2021) Prague
Message-ID: <00f201d6fc66$175071a0$45f154e0$@confscience.com>

Call for papers

************************************************* 

International Conference on Applied Data Science and Intelligence - (ADSI 2021) 

Prague- Czech Republic, October 14-15, 2021

https://confscience.com/adsi/  

Submission deadline: April 1, 2021

All papers accepted in ADSI 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: April 1, 2021

- Acceptance Notification: July 1, 2021

- Final Manuscript Due: September 1, 2021

***************************************************************************

The ADSI 2021 conference will be held in Conjunction with: 

International Conference on Recent Theories and Applications in Transportation and Mobility (RTATM 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

- Theoretical Models

- Spatial and temporal multi-models

- Multi-dimensional data

- Data acquisition and pre-processing

- Data inference

- Data Classification and Taxonomy

- Data Metrics

- New approaches for collaboration and competition

- Self-organization, self-healing, fault-tolerance approaches

- Spatial reasoning

- Context awareness

- Intelligent mobility

- New approaches to supervised and unsupervised learning

- New approaches for security, privacy, trust, and ethics in data science

- Real-time data analytics

- Multi-Agent Systems for data science

- Distributed data analytics

- Data authenticity

- New theories and approaches for Deep learning

- New approaches for Business Intelligence

- Fuzzy logic

- Decision trees

- Support vector machines

- Evolutionary computation

- Statistical methods

- Collaborative filtering

- Data engineering

- Content mining

- Indexing schemes

- Information retrieval

- Metadata use and management

INTELLIGENT DATA PROCESSING AND ANALYTICS 

- Multi-level data processing

- Data analytics optimization

- Smart data mining

- Machine Learning

- Deep Learning

- Bio-Inspired Computing

- Secure data analytics

- Privacy in data analytics

- Trust in Big Data

- Business intelligence

- Visualization Analytics

- Intelligence as a Service (IaaS)

- Data Science as a Service (DSaaS)

- Natural Language Processing

- Signal Processing

- Simulation and Modeling

- Data-Intensive Computing

SYSTEMS AND INFRASTRUCTURES 

- Data storage infrastructure

- Data warehouses

- Data Query and Indexing Technologies

- Software Defined Infrastructures 

- Software Defined Networks (SDN)

- Distributed data systems

- Smart grid computing

- Intelligent data management

- Big Data computing

- Smart data networking  

- Internet of Things

- Cyber Physical Systems

- Blockchain

- Fog and Edge intelligence

- Parallel Computing systems  

- Open Source systems for data science

- Embedded intelligence

- Embedded data science

- In-Memory computing 

- Intelligent drones

- Internet of Drones

- Real-time data acquisition systems

APPLICATIONS

- Intelligent Hazard management

- Intelligent data science in healthcare

- Intelligent data science in farming

- Intelligent data science in Oil and Gas

- Smart logistics 

- Intelligent data science in transportation

- Intelligent data science in surveillance

- Xtech (Fintech, Agritech, etc.)

- Intelligent drones

- Digital transformation

- Bioinformatics

- Marketing

- Social Science

- E-learning and E-services

 

***************************************************************************

OUTSTANDING PAPERS:

Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. 

*************************************************************************** 

PAPER SUBMISSION: 

Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=adsi2021). 

All papers will be peer reviewed. 

Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page)

Length of Short papers: less than 12 pages 

For more information, please refer to the conference website: https://confscience.com/adsi/    

 

***************************************************************************

CONTACT 

For more information, please send an email to info-adsi at confscience.com  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210206/41f21fee/attachment.html>

From olf at aatal-apotheke.de  Sat Feb  6 20:37:55 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 06 Feb 2021 21:37:55 +0100
Subject: [Haskell-cafe]  Haskell exercises for beginners
Message-ID: <68be7a82718a31003a0f00af1550549119e371e8.camel@aatal-apotheke.de>

> Hello Haskell Café,
> 
> I have been working on a website aimed at teaching programming and Computer
> Science through quick examples.  It is called "Computer Science by Example
> <https://cscx.org/>;": https://cscx.org/
> 
> The exercises start very simple (e.g. read two numbers and print their sum
> <https://cscx.org/add>;) then increase in difficulty and complexity
> gradually (e.g. solving the change-making problem <https://cscx.org/cash>;).
> The website has an "online judge" functionality where students can submit
> their solutions which are tested and graded automatically without human
> intervention.  It currently supports solutions in *Haskell* and
> additionally: Python, C, C++, C#, Java, JavaScript, Lua and Ruby.
> 
> The exercises are useful not only to first time programmers, but also to
> experienced programmers trying to learn a new language such as Haskell.
> 
> Check it out at cscx.org.  The exercises are freely available for anyone to
> try.
> 
> Best Regards,
> Rudy

Dear Rudy, 

thanks for sharing all these excercises. Automated grading has many
advantages. The kind of automated grading cscx uses lets the program
use stdin and stdout. However, for Haskell (and all other programming
languages too) this means that students are, from the very beginning,
forced to write parsers for the data the grading system gives on stdin.
This means that either 
* You limit input data to stuff with built-in parsers (which you don't)
* You teach proper parsing early, which is non-trivial, or
* You permit the students develop an ad-hoc and potentially messy style
of coping with unstructured input. 

In all the excercises I looked at, the grading specification does not
say what the program should do with invalid input. Therefore messy ad-
hoc parsing is what you should expect to see in, and in some cases
comprise the largest part of, submitted solutions. Others may disagree
whether this is to be prevented or not. I have limited experience in
teaching. 

In some other CS courses the excercises give a program fragment which
is to be completed by the student. In Haskell you could use property-
based testing [1] like QuickCheck or doctests to do the heavy lifting
for you, while at the same time presenting the students with an
infinity of test cases. 
Another way might be to provide a random generator of structured test
data, and the student's task is to write a program that echoes the
random data together with the computed result. That way, you could
still use the stdout-based automated grading. 

Example of QuickCheck-based grading:

module Triple1 where
--  Your task: Complete this function 
-- so that for example
--
-- >>> triple 2
-- 6
-- >>> triple 123
-- 369
triple :: Integer -> Integer
triple = undefined
-- Automated grading appends the following and runs
-- quickCheck prop_triple
prop_triple :: Integer -> Bool
prop_triple = triple n == 3*n

Example of Random-based grading:

module Triple1 where
-- Your task: complete this function
-- so that for example
-- 
-- >>> pure 2 >>= triple
-- 2
-- 6
triple :: Integer -> IO ()
triple n = do
  print n
  undefined
-- Automated grading compiles
-- main = (yourIntegerGenerator :: IO Integer) >>= triple
-- and executes repeatedly. 


Kind regards
Olaf

[1] 
https://www.cs.tufts.edu/~nr/cs257/archive/john-hughes/automatic-grading.pdf


From kazu at iij.ad.jp  Mon Feb  8 20:01:28 2021
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Tue, 09 Feb 2021 05:01:28 +0900 (JST)
Subject: [Haskell-cafe] tls 1.5.5
Message-ID: <20210209.050128.875036470814367442.kazu@iij.ad.jp>

Hi all,

I would like to announce that tls 1.5.5 has been released. The main
purpose of this version is provide the Network.TLS.QUIC module. This
is the first step to bring QUIC to the Haksell community.

Changelog says:

- QUIC support
  [#419](https://github.com/vincenthz/hs-tls/pull/419)
  [#427](https://github.com/vincenthz/hs-tls/pull/427)
  [#428](https://github.com/vincenthz/hs-tls/pull/428)
  [#430](https://github.com/vincenthz/hs-tls/pull/430)
  [#433](https://github.com/vincenthz/hs-tls/pull/433)
  [#441](https://github.com/vincenthz/hs-tls/pull/441)
- Server ECDSA for P-256
  [#436](https://github.com/vincenthz/hs-tls/pull/436)
- Sort ciphersuites based on hardware-acceleration support
  [#439](https://github.com/vincenthz/hs-tls/pull/439)
- Sending no_application_protocol
  [#440](https://github.com/vincenthz/hs-tls/pull/440)
- Internal improvements
  [#426](https://github.com/vincenthz/hs-tls/pull/426)
  [#431](https://github.com/vincenthz/hs-tls/pull/431)

Technical information can be found from the following blog posts:

- Implementation status of QUIC in Haskell
    https://kazu-yamamoto.hatenablog.jp/entry/2020/02/18/145038
- Improving QUIC APIs of the TLS library in Haskell
    https://kazu-yamamoto.hatenablog.jp/entry/2020/09/16/150801
- The Current Plan for Haskell QUIC
    https://kazu-yamamoto.hatenablog.jp/entry/2020/10/23/141648

IMPORTANT NOTE:

If you want to make "tls" faster, please install "cryptonite" with the
"support_pclmuldq" flag:
 
  % cabal install cryptonite -f support_pclmuldq

This enables hardware acceleration for the GCM part of AES-GCM. If you
use old GCC, you need to disable the "use_target_attributes" flag:

  % cabal install cryptonite -f support_pclmuldq -f-use_target_attributes

--Kazu


From cmb21 at st-andrews.ac.uk  Tue Feb  9 08:09:24 2021
From: cmb21 at st-andrews.ac.uk (Christopher Brown)
Date: Tue, 9 Feb 2021 08:09:24 +0000
Subject: [Haskell-cafe] Postdoc Position (up to 3 years) at St Andrews
Message-ID: <DB7PR06MB535432228C653CFC4FB9C706DB8E9@DB7PR06MB5354.eurprd06.prod.outlook.com>

Dear All

I have an opening for a postdoc to work on a new 3-year EPSRC project in the Programming Languages group at St Andrews. The deadline has been extended to the 26th February.

Send me an email (cmb21 at st-andrews.ac.uk<mailto:cmb21 at st-andrews.ac.uk>) if you’d like to informally chat about the post. I’m very happy to chat to you.

Thanks
Chris

Lecturer in Computer Science
University of St Andrews
Scotland

--------------------
The Programming Languages Group seeks a Research Fellow to work on the newly funded 3-year EPSRC project, Energise: Refactorings and Skeletons for Energy-Aware Applications on High-Performance Embedded Systems.

Embedded devices, such as mobile phones, drones, medical devices and even satellite imaging are now common place in society. These types of devices rely very heavily on battery power, contributing to climate change and global warming. Optimizing the software that runs on such devices for energy is a very challenging problem for software developers. The Energise project aims to address this issue by providing the developer with a refactoring tool to repurpose their software to make it consume less energy, and to do it in such a way that the code is guaranteed to still meet its specification.

The Energise project aims to develop new, formally-motivated, refactorings and transformations that reduce energy consumption for embedded multi-core devices. This includes implementing refactorings for target languages such as C; proving general soundness of the refactorings using e.g. dependent types; developing new programming abstractions (skeletons) for common energy-reducing programming patterns; running experiments; writing proofs of correctness, etc.

The post will require skills in formal semantics of programming languages, compilers, program transformation, lightweight formal methods (including, e.g. dependent types) and knowledge of parallelism and non-functional properties, including energy.

Informal enquiries can be directed to Dr Chris Brown (cmb21 at st-andrews.ac.uk<mailto:cmb21 at st-andrews.ac.uk>).

Applications are particularly welcome from women, people from the Black, Asian, Minority or Ethnic (BAME) community and other protected characteristics who are under-represented in research posts at the University.

The University is committed to equality for all, demonstrated through our working on diversity awards (ECU Athena SWAN/Race Charters; Carer Positive; LGBT Charter; and Stonewall). More details can be found at http://www.st-andrews.ac.uk/hr/edi/diversityawards/.

Interviews will be held on TBC.

Please quote ref: AR2474MR

Closing Date: 26 February 2021

School of Computer Science
Salary: £33,797 - £36,914 per annum
Fixed Term: 3 years
Start: As soon as possible

More details at: https://www.vacancies.st-andrews.ac.uk/Vacancies/W/6918/0/284952/889/research-fellow-ar2474mr


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210209/052831ab/attachment.html>

From andrei.h.popescu at gmail.com  Tue Feb  9 17:31:49 2021
From: andrei.h.popescu at gmail.com (Andrei Popescu)
Date: Tue, 9 Feb 2021 17:31:49 +0000
Subject: [Haskell-cafe] 21st Midlands Graduate School in the Foundations of
 Computing Science: Call for Participation
Message-ID: <CAACfPHqf+s4O_zHzOfyC1wDAsWahGtsVnbnB=3G=Te-As8agKg@mail.gmail.com>

CALL FOR PARTICIPATION

     21st Midlands Graduate School in the Foundations of Computing Science
                                                       MGS 21
                                       12-16 April 2021, virtually
           https://staffwww.dcs.shef.ac.uk/people/G.Struth/mgs21.html


OVERVIEW

The annual Midlands Graduate School in the Foundations of Computing
Science (MGS) offers an intensive programme of lectures on the
mathematical foundations of computing. It addresses first of all PhD
students in their first or second year, but is open to anyone
interested in its topics, from academia to industry and around the
world. The MGS has been run since 1999 and is hosted alternately by
the Universities of Birmingham, Leicester, Nottingham and Sheffield.
MGS 21 is its 21st incarnation. Information about previous events can
be found at the MGS web site

http://www.cs.nott.ac.uk/MGS


PROGRAMME

MGS 21 consists of eight courses, each with four or five hours of
lectures and a similar number of exercise sessions. Three courses are
introductory; one is given by an invited lecturer. These should be
attended by all participants. The remaining more advanced courses
should be selected based on interest. MGS 21 aims at a mix of
livestreamed and prerecorded lectures and livestreamed exercise
sessions, with additional social online events.

Invited lectures:

Monads and Interactions
  Tarmo Uustalu, Reykjavik

Introductory courses:

Category Theory
  Jacopo Emmenegger, Birmingham

Type Theory
  Thorsten Altenkirch, Nottingham

Proof Theory
  Anupam Das, Birmingham

Advanced courses:

Homotopy Type Theory
  Nicolai Kraus, Nottingham

Inductive and Coinductive Reasoning with Isabelle/HOL
  Andrei Popescu, Sheffield

Effects and Call-by-Push-Value
  Paul Levy, Birmingham

Formal Modelling and Analysis of Concurrent Systems
  Mohammad Mousavi, Leicester

In addition we are organising a session where participants can briefly
present and discuss their own research. A call will be made in March.


REGISTRATION

Participation at MGS 21 is free of charge, but selective. Requests
must be submitted online via

https://staffwww.dcs.shef.ac.uk/people/G.Struth/mgs21.html

Registration deadline is April 1.


ORGANISATION

Please direct all queries about MGS 21 to Georg Struth.

The Sheffield organisers are

Harsh Beohar (H.Beohar at sheffield.ac.uk)

Andrei Popescu (A.Popescu at sheffield.ac.uk)

Georg Struth (G.Struth at sheffield.ac.uk)

From benjamin.redelings at gmail.com  Wed Feb 10 04:57:43 2021
From: benjamin.redelings at gmail.com (Benjamin Redelings)
Date: Tue, 9 Feb 2021 20:57:43 -0800
Subject: [Haskell-cafe] lexing nested comments in GHC/Parser/Lexer.x
Message-ID: <4f8483c3-407b-b5ea-da48-feda64aef56e@gmail.com>

Hi,

I notice that in Lexer.x for GHC nested comments are parsed using a 
special function, with the comment "nested comments require traversing 
by hand, they can't be parsed using regular expressions."

While I see that nested comments can't be parsed using regular 
expressions, the lexer has a state stack, and so it seems like nested 
comments could be parsed by pushing a new "nested comment" state onto 
the lexer state every time a "{-" is encountered.  But perhaps this is 
not done because its not clear how to make the entire comment into a 
single token that way?  This might be a naive question -- I don't have 
that much experience with lexers.

Thanks!

-BenRI


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Feb 10 11:31:49 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 10 Feb 2021 11:31:49 +0000
Subject: [Haskell-cafe] Surprising lack of generalisation
Message-ID: <20210210113149.GN1520@cloudinit-builder>

Dear all,

I don't understand why the type of pBD defined in the where clause of
pFG cannot be inferred to a general type in the presence of
TypeFamilies.  In particular I don't understand why nonetheless the
type of pBD definied in the where clause of pF (only slightly simpler)
*can* be inferred.

Can anyone explain?

Thanks

Tom



{-# LANGUAGE TypeFamilies #-}

-- This code came up in the context of writing a parser, but that's
-- not terribly important

import Prelude hiding ((<$>))

data B = B

data D f = F     f
         | GF AP f
         | DF AM f

data AM = AM
data AP = AP

pB :: Parser B
pB = Parser

-- Works fine
pF :: Parser (D B)
pF = pBD GF AP <|> pBD DF AM
  where pBD f p = f p <$> pB

-- Shows the (presumably) inferred type for pBD
pFWithType :: Parser (D B)
pFWithType = pBD GF AP <|> pBD DF AM
  where pBD :: (t -> B -> b) -> t -> Parser b
        pBD f p = f p <$> pB

-- One would hope this type would be inferred too
pFGWithType :: Parser B -> Parser (D B)
pFGWithType pBArg = pBD GF AP <|> pBD DF AM
  where pBD :: (t -> B -> b) -> t -> Parser b
        pBD f p = f p <$> pBArg

-- But omitting it leads to a type error if TypeFamilies is enabled.
-- There is no error if TypeFamilies is not enabled.
pFG :: Parser B -> Parser (D B)
pFG pBArg = pBD GF AP <|> pBD DF AM
  where pBD f p = f p <$> pBArg


-- The specifics of the parser don't matter
data Parser a = Parser

(<|>) :: Parser a -> Parser a -> Parser a
(<|>) _ _ = Parser

(<$>) :: (a -> b) -> Parser a -> Parser b
(<$>) _ _ = Parser

From rae at richarde.dev  Wed Feb 10 13:30:10 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 10 Feb 2021 13:30:10 +0000
Subject: [Haskell-cafe] Surprising lack of generalisation
In-Reply-To: <20210210113149.GN1520@cloudinit-builder>
References: <20210210113149.GN1520@cloudinit-builder>
Message-ID: <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>

This is the effect of -XMonoLocalBinds, which is implied by -XTypeFamilies (and also by -XGADTs). See https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html>.

Happy to give more background -- let me know if that link doesn't answer your question.

Richard

> On Feb 10, 2021, at 6:31 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> 
> Dear all,
> 
> I don't understand why the type of pBD defined in the where clause of
> pFG cannot be inferred to a general type in the presence of
> TypeFamilies.  In particular I don't understand why nonetheless the
> type of pBD definied in the where clause of pF (only slightly simpler)
> *can* be inferred.
> 
> Can anyone explain?
> 
> Thanks
> 
> Tom
> 
> 
> 
> {-# LANGUAGE TypeFamilies #-}
> 
> -- This code came up in the context of writing a parser, but that's
> -- not terribly important
> 
> import Prelude hiding ((<$>))
> 
> data B = B
> 
> data D f = F     f
>         | GF AP f
>         | DF AM f
> 
> data AM = AM
> data AP = AP
> 
> pB :: Parser B
> pB = Parser
> 
> -- Works fine
> pF :: Parser (D B)
> pF = pBD GF AP <|> pBD DF AM
>  where pBD f p = f p <$> pB
> 
> -- Shows the (presumably) inferred type for pBD
> pFWithType :: Parser (D B)
> pFWithType = pBD GF AP <|> pBD DF AM
>  where pBD :: (t -> B -> b) -> t -> Parser b
>        pBD f p = f p <$> pB
> 
> -- One would hope this type would be inferred too
> pFGWithType :: Parser B -> Parser (D B)
> pFGWithType pBArg = pBD GF AP <|> pBD DF AM
>  where pBD :: (t -> B -> b) -> t -> Parser b
>        pBD f p = f p <$> pBArg
> 
> -- But omitting it leads to a type error if TypeFamilies is enabled.
> -- There is no error if TypeFamilies is not enabled.
> pFG :: Parser B -> Parser (D B)
> pFG pBArg = pBD GF AP <|> pBD DF AM
>  where pBD f p = f p <$> pBArg
> 
> 
> -- The specifics of the parser don't matter
> data Parser a = Parser
> 
> (<|>) :: Parser a -> Parser a -> Parser a
> (<|>) _ _ = Parser
> 
> (<$>) :: (a -> b) -> Parser a -> Parser b
> (<$>) _ _ = Parser
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210210/ce95579e/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Feb 10 15:21:42 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 10 Feb 2021 15:21:42 +0000
Subject: [Haskell-cafe] Surprising lack of generalisation
In-Reply-To: <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>
References: <20210210113149.GN1520@cloudinit-builder>
 <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>
Message-ID: <20210210152142.GO1520@cloudinit-builder>

I'm rather puzzled by that page. I"m not sure if I'm missing
something.

Firstly, I don't understand the definition of "variable is closed" and
"binding group is fully generalised".

Consider

f = let x = x in ()

Is x closed?  Well, according to the definition it is closed when

* the variable is let-bound

  [It is]

* one of the following holds:

  * the variable has an explicit type signature that has no free
    type variables

    [It does not]

  * its binding group is fully generalised (see next bullet)

    [OK, let's check the definition of "fully generalised"]

Is x's binding group fully generalised?  According to the definition
is is fully generalised when

* each of its free variables is either imported or closed, and

  [x is the only free variable.  It is not imported.  Is it closed?
  See below!]

* the binding is not affected by the monomorphism restriction
  (Haskell Report, Section 4.5.5)

  [I don't believe it is -- no constrained variables are in play.  See
  https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-930004.5.5]


Following these rules x is closed if and only if its binding group is
fully generalised, and its binding group is fully generalised if and
only if x is closed.  At this point I don't know how to determine
whether x is closed.  Have I misinterpreted some part of this
definition?


Secondly, if I knew whether x is closed then what?  Perhaps "fully
generalised" is not just the name of a property that a binding group
may have but something that is actually *performed* to the binding
group, something to do with whether it is assigned a general type.  Is
that right?

Tom




On Wed, Feb 10, 2021 at 01:30:10PM +0000, Richard Eisenberg wrote:
> This is the effect of -XMonoLocalBinds, which is implied by -XTypeFamilies (and also by -XGADTs). See https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html>.
> 
> Happy to give more background -- let me know if that link doesn't answer your question.
> 
> Richard
> 
> > On Feb 10, 2021, at 6:31 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> > Dear all,
> > 
> > I don't understand why the type of pBD defined in the where clause of
> > pFG cannot be inferred to a general type in the presence of
> > TypeFamilies.  In particular I don't understand why nonetheless the
> > type of pBD definied in the where clause of pF (only slightly simpler)
> > *can* be inferred.
> > 
> > Can anyone explain?
> > 
> > Thanks
> > 
> > Tom
> > 
> > 
> > 
> > {-# LANGUAGE TypeFamilies #-}
> > 
> > -- This code came up in the context of writing a parser, but that's
> > -- not terribly important
> > 
> > import Prelude hiding ((<$>))
> > 
> > data B = B
> > 
> > data D f = F     f
> >         | GF AP f
> >         | DF AM f
> > 
> > data AM = AM
> > data AP = AP
> > 
> > pB :: Parser B
> > pB = Parser
> > 
> > -- Works fine
> > pF :: Parser (D B)
> > pF = pBD GF AP <|> pBD DF AM
> >  where pBD f p = f p <$> pB
> > 
> > -- Shows the (presumably) inferred type for pBD
> > pFWithType :: Parser (D B)
> > pFWithType = pBD GF AP <|> pBD DF AM
> >  where pBD :: (t -> B -> b) -> t -> Parser b
> >        pBD f p = f p <$> pB
> > 
> > -- One would hope this type would be inferred too
> > pFGWithType :: Parser B -> Parser (D B)
> > pFGWithType pBArg = pBD GF AP <|> pBD DF AM
> >  where pBD :: (t -> B -> b) -> t -> Parser b
> >        pBD f p = f p <$> pBArg
> > 
> > -- But omitting it leads to a type error if TypeFamilies is enabled.
> > -- There is no error if TypeFamilies is not enabled.
> > pFG :: Parser B -> Parser (D B)
> > pFG pBArg = pBD GF AP <|> pBD DF AM
> >  where pBD f p = f p <$> pBArg
> > 
> > 
> > -- The specifics of the parser don't matter
> > data Parser a = Parser
> > 
> > (<|>) :: Parser a -> Parser a -> Parser a
> > (<|>) _ _ = Parser
> > 
> > (<$>) :: (a -> b) -> Parser a -> Parser b
> > (<$>) _ _ = Parser

From matteo at confscience.com  Wed Feb 10 19:01:19 2021
From: matteo at confscience.com (matteo at confscience.com)
Date: Wed, 10 Feb 2021 20:01:19 +0100
Subject: [Haskell-cafe] International Conference on Recent Theories and
	Applications in Transportation and Mobility - (RTATM 2021) Prague
Message-ID: <01db01d6ffdf$1df9fa40$59edeec0$@confscience.com>

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/  

Submission deadline: April 1, 2021

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: April 1, 2021

- 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

 

 

***************************************************************************

OUTSTANDING PAPERS:

Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. 

*************************************************************************** 

PAPER SUBMISSION: 

Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=rtatm2021). 

All papers will be peer reviewed. 

Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page)

Length of Short papers: less than 12 pages 

For more information, please refer to the conference website: https://confscience.com/rtatm/    

 

***************************************************************************

CONTACT 

For more information, please send an email to info-rtatm at confscience.com  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210210/6fcf1d41/attachment.html>

From vamchale at gmail.com  Thu Feb 11 01:56:03 2021
From: vamchale at gmail.com (Vanessa McHale)
Date: Wed, 10 Feb 2021 19:56:03 -0600
Subject: [Haskell-cafe] lexing nested comments in GHC/Parser/Lexer.x
In-Reply-To: <4f8483c3-407b-b5ea-da48-feda64aef56e@gmail.com>
References: <4f8483c3-407b-b5ea-da48-feda64aef56e@gmail.com>
Message-ID: <f269a4aa-458d-38ec-b8aa-c55e7bf9f890@gmail.com>

The states generated by Alex are a bit inflexible, you could modify the
(user) state when dealing with nested comments I think but then checking
state before applying a rule might be expensive.

Cheers,
Vanessa McHale

On 2/9/21 10:57 PM, Benjamin Redelings wrote:
> Hi,
>
> I notice that in Lexer.x for GHC nested comments are parsed using a
> special function, with the comment "nested comments require traversing
> by hand, they can't be parsed using regular expressions."
>
> While I see that nested comments can't be parsed using regular
> expressions, the lexer has a state stack, and so it seems like nested
> comments could be parsed by pushing a new "nested comment" state onto
> the lexer state every time a "{-" is encountered.  But perhaps this is
> not done because its not clear how to make the entire comment into a
> single token that way?  This might be a naive question -- I don't have
> that much experience with lexers.
>
> Thanks!
>
> -BenRI
>
> _______________________________________________
> 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.

From rae at richarde.dev  Thu Feb 11 02:46:46 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 11 Feb 2021 02:46:46 +0000
Subject: [Haskell-cafe] Surprising lack of generalisation
In-Reply-To: <20210210152142.GO1520@cloudinit-builder>
References: <20210210113149.GN1520@cloudinit-builder>
 <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>
 <20210210152142.GO1520@cloudinit-builder>
Message-ID: <010f01778efbdd15-c5e57051-65fd-427e-9edd-3c2c0e5e59f0-000000@us-east-2.amazonses.com>



> On Feb 10, 2021, at 10:21 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> 
> Is x's binding group fully generalised?  According to the definition
> is is fully generalised when
> 
> * each of its free variables is either imported or closed, and
> 
>  [x is the only free variable.  It is not imported.  Is it closed?
>  See below!]

I argue: x is not a free variable of the binding group, because it is bound by the binding group. It *is* free in the RHS, but that's not what the manual says to look for.
> 
> 
> Following these rules x is closed if and only if its binding group is
> fully generalised, and its binding group is fully generalised if and
> only if x is closed.  At this point I don't know how to determine
> whether x is closed.  Have I misinterpreted some part of this
> definition?

I think so, but it seems a pretty easy mistake to make.

> 
> 
> Secondly, if I knew whether x is closed then what?  Perhaps "fully
> generalised" is not just the name of a property that a binding group
> may have but something that is actually *performed* to the binding
> group, something to do with whether it is assigned a general type.  Is
> that right?

Yes, that's right. Though I'm not sure what the content of the word *fully* is in that description -- I don't know of *partial* generalization.

Does this help?

Richard

> 
> Tom
> 
> 
> 
> 
> On Wed, Feb 10, 2021 at 01:30:10PM +0000, Richard Eisenberg wrote:
>> This is the effect of -XMonoLocalBinds, which is implied by -XTypeFamilies (and also by -XGADTs). See https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html>.
>> 
>> Happy to give more background -- let me know if that link doesn't answer your question.
>> 
>> Richard
>> 
>>> On Feb 10, 2021, at 6:31 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>>> Dear all,
>>> 
>>> I don't understand why the type of pBD defined in the where clause of
>>> pFG cannot be inferred to a general type in the presence of
>>> TypeFamilies.  In particular I don't understand why nonetheless the
>>> type of pBD definied in the where clause of pF (only slightly simpler)
>>> *can* be inferred.
>>> 
>>> Can anyone explain?
>>> 
>>> Thanks
>>> 
>>> Tom
>>> 
>>> 
>>> 
>>> {-# LANGUAGE TypeFamilies #-}
>>> 
>>> -- This code came up in the context of writing a parser, but that's
>>> -- not terribly important
>>> 
>>> import Prelude hiding ((<$>))
>>> 
>>> data B = B
>>> 
>>> data D f = F     f
>>>        | GF AP f
>>>        | DF AM f
>>> 
>>> data AM = AM
>>> data AP = AP
>>> 
>>> pB :: Parser B
>>> pB = Parser
>>> 
>>> -- Works fine
>>> pF :: Parser (D B)
>>> pF = pBD GF AP <|> pBD DF AM
>>> where pBD f p = f p <$> pB
>>> 
>>> -- Shows the (presumably) inferred type for pBD
>>> pFWithType :: Parser (D B)
>>> pFWithType = pBD GF AP <|> pBD DF AM
>>> where pBD :: (t -> B -> b) -> t -> Parser b
>>>       pBD f p = f p <$> pB
>>> 
>>> -- One would hope this type would be inferred too
>>> pFGWithType :: Parser B -> Parser (D B)
>>> pFGWithType pBArg = pBD GF AP <|> pBD DF AM
>>> where pBD :: (t -> B -> b) -> t -> Parser b
>>>       pBD f p = f p <$> pBArg
>>> 
>>> -- But omitting it leads to a type error if TypeFamilies is enabled.
>>> -- There is no error if TypeFamilies is not enabled.
>>> pFG :: Parser B -> Parser (D B)
>>> pFG pBArg = pBD GF AP <|> pBD DF AM
>>> where pBD f p = f p <$> pBArg
>>> 
>>> 
>>> -- The specifics of the parser don't matter
>>> data Parser a = Parser
>>> 
>>> (<|>) :: Parser a -> Parser a -> Parser a
>>> (<|>) _ _ = Parser
>>> 
>>> (<$>) :: (a -> b) -> Parser a -> Parser b
>>> (<$>) _ _ = Parser
> _______________________________________________
> 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.


From Graham.Hutton at nottingham.ac.uk  Thu Feb 11 14:22:26 2021
From: Graham.Hutton at nottingham.ac.uk (Graham Hutton)
Date: Thu, 11 Feb 2021 14:22:26 +0000
Subject: [Haskell-cafe] 10 PhD studentships in Nottingham
Message-ID: <3AC69D59-038A-4A0A-9E78-F61397983BD3@nottingham.ac.uk>

Dear all,

The School of Computer Science at the University of Nottingham 
is seeking applications for 10 fully-funded PhD studentships:
https://tinyurl.com/ten-phds-2021

Applicants in the area of the Functional Programming Laboratory
(https://tinyurl.com/fp-notts) are strongly encouraged!  If you
are interested in applying, please contact a potential supervisor
as soon as possible (the application deadline is 15th March):

  Thorsten Altenkirch - constructive logic, proof assistants,
  homotopy type theory, category theory, lambda calculus.
 
  Graham Hutton - mathematics of program construction, category
  theory, program correctness and efficiency, Haskell.

  Nicolai Kraus - homotopy type theory, higher category theory, 
  constructive mathematics, and related topics.

  Henrik Nilsson - functional reactive programming, domain-
  specific languages, generalised notions of computation.

The studentships are open to applicants of any nationality.

Best wishes,

Graham

+-----------------------------------------------------------+

              10 Fully-Funded PhD Studentships

                 School of Computer Science
                University of Nottingham, UK

                  tinyurl.com/ten-phds-2021

Applications are invited for a number of fully funded PhD
studentships offered by the School of Computer Science at the
University of Nottingham, starting on 1st October 2021.

The topics for the studentships are open, but should relate to the
interests of one of the School’s research groups: Computational
Optimisation and Learning Lab; Computer Vision Lab; Cyber Security;
Functional Programming; Intelligent Modelling and Analysis; Mixed
Reality Lab and Uncertainty in Data and Decision Making. 

The studentships are for three and a half years and include a
stipend of (minimum) £15,609 per year and tuition fees. 

Applicants are normally expected to have a 2:1 Bachelor or
Masters degree or international equivalent, in Computer Science
or a related discipline, and must obtain the support of a
potential supervisor in the School prior to submitting their
application.  Please contact potential supervisors at least two
weeks prior to the closing date for applications.

Informal enquiries may be addressed to Professor Tony Pridmore
(tony.pridmore at nottingham.ac.uk).  To apply, please submit the
following items by email to Lindsay.Norman at nottingham.ac.uk:

(1) A copy of your CV, including your actual or expected degree
class(es), and results of all University examinations; 

(2) An example of your technical writing, such as a project
report or dissertation; 

(3) Contact details for two academic referees - it is the
applicant’s responsibility to ensure that references are
requested and sent to Lindsay.Norman at nottingham.ac.uk;

(4) A research proposal – max 2 x sides A4;

(5) A covering letter, which must include the name of the
member of staff who has agreed to support your application
(without this your application cannot be considered), and
the University’s job reference number (SCI1979).

Closing date for applications: Monday 15th March 2021.

+-----------------------------------------------------------+




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.





From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Feb 11 14:23:39 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 11 Feb 2021 14:23:39 +0000
Subject: [Haskell-cafe] Surprising lack of generalisation
In-Reply-To: <010f01778efbdd15-c5e57051-65fd-427e-9edd-3c2c0e5e59f0-000000@us-east-2.amazonses.com>
References: <20210210113149.GN1520@cloudinit-builder>
 <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>
 <20210210152142.GO1520@cloudinit-builder>
 <010f01778efbdd15-c5e57051-65fd-427e-9edd-3c2c0e5e59f0-000000@us-east-2.amazonses.com>
Message-ID: <20210211142339.GQ1520@cloudinit-builder>

On Thu, Feb 11, 2021 at 02:46:46AM +0000, Richard Eisenberg wrote:
> > On Feb 10, 2021, at 10:21 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> > 
> > Is x's binding group fully generalised?  According to the
> > definition is is fully generalised when
> > 
> > * each of its free variables is either imported or closed, and
> > 
> >  [x is the only free variable.  It is not imported.  Is it closed?
> >  See below!]
> 
> I argue: x is not a free variable of the binding group, because it
> is bound by the binding group. It *is* free in the RHS, but that's
> not what the manual says to look for.

Aha, thank you Richard, now I understand the definition.  If one
unrolls the recursiveness present in the definition then it seems to
be saying saying that a let-bound group is generalised if and only if
every trail of free variable dependencies eventually stops at a
let-bound variable with an explicit type signature.

In my example  pFG  the let-bound function pBD is *not* generalised
because its free variable pBArg is not itself let-bound.

    -- Does not type check because pBD is not generalised yet it is
    -- used at two different types
    pFG :: Parser B -> Parser (D B)
    pFG pBArg = pBD GF AP <|> pBD DF AM
      where pBD f p = f p <$> pBArg

On the other hand, my intuition says that we can let bind  pBArg  to a
new name with explicit type signature and thereby make  pBD closed.
And indeed we can!

    -- Does type check
    pFG1 :: Parser B -> Parser (D B)
    pFG1 pBArg = pBD GF AP <|> pBD DF AM
      where pBArg1 :: Parser B
            pBArg1 = pBArg
            pBD f p = f p <$> pBArg1

My next question then is

   "In pFG, the argument pBArg has been given a type (moreover a
   monomorphic type) by the type signature for pFG itself.  Why does
   the definition of 'closed' require the variable to be let-bound?
   Wouldn't lambda-bound with a type implicitly provided by an
   explicit type signature for the lambda" be equally good?"

The fact that a simple, seemingly redundant, binding (that of pBArg1)
makes a program type check is rather surprising.
            

Thanks,

Tom


[...]
> > On Wed, Feb 10, 2021 at 01:30:10PM +0000, Richard Eisenberg wrote:
> >> This is the effect of -XMonoLocalBinds, which is implied by -XTypeFamilies (and also by -XGADTs). See https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html <https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/let_generalisation.html>.
> >> 
> >> Happy to give more background -- let me know if that link doesn't answer your question.
> >> 
> >> Richard
> >> 
> >>> On Feb 10, 2021, at 6:31 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> >>> Dear all,
> >>> 
> >>> I don't understand why the type of pBD defined in the where clause of
> >>> pFG cannot be inferred to a general type in the presence of
> >>> TypeFamilies.  In particular I don't understand why nonetheless the
> >>> type of pBD definied in the where clause of pF (only slightly simpler)
> >>> *can* be inferred.
> >>> 
> >>> Can anyone explain?
> >>> 
> >>> Thanks
> >>> 
> >>> Tom
> >>> 
> >>> 
> >>> 
> >>> {-# LANGUAGE TypeFamilies #-}
> >>> 
> >>> -- This code came up in the context of writing a parser, but that's
> >>> -- not terribly important
> >>> 
> >>> import Prelude hiding ((<$>))
> >>> 
> >>> data B = B
> >>> 
> >>> data D f = F     f
> >>>        | GF AP f
> >>>        | DF AM f
> >>> 
> >>> data AM = AM
> >>> data AP = AP
> >>> 
> >>> pB :: Parser B
> >>> pB = Parser
> >>> 
> >>> -- Works fine
> >>> pF :: Parser (D B)
> >>> pF = pBD GF AP <|> pBD DF AM
> >>> where pBD f p = f p <$> pB
> >>> 
> >>> -- Shows the (presumably) inferred type for pBD
> >>> pFWithType :: Parser (D B)
> >>> pFWithType = pBD GF AP <|> pBD DF AM
> >>> where pBD :: (t -> B -> b) -> t -> Parser b
> >>>       pBD f p = f p <$> pB
> >>> 
> >>> -- One would hope this type would be inferred too
> >>> pFGWithType :: Parser B -> Parser (D B)
> >>> pFGWithType pBArg = pBD GF AP <|> pBD DF AM
> >>> where pBD :: (t -> B -> b) -> t -> Parser b
> >>>       pBD f p = f p <$> pBArg
> >>> 
> >>> -- But omitting it leads to a type error if TypeFamilies is enabled.
> >>> -- There is no error if TypeFamilies is not enabled.
> >>> pFG :: Parser B -> Parser (D B)
> >>> pFG pBArg = pBD GF AP <|> pBD DF AM
> >>> where pBD f p = f p <$> pBArg
> >>> 
> >>> 
> >>> -- The specifics of the parser don't matter
> >>> data Parser a = Parser
> >>> 
> >>> (<|>) :: Parser a -> Parser a -> Parser a
> >>> (<|>) _ _ = Parser
> >>> 
> >>> (<$>) :: (a -> b) -> Parser a -> Parser b
> >>> (<$>) _ _ = Parser

From rae at richarde.dev  Thu Feb 11 15:03:30 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 11 Feb 2021 15:03:30 +0000
Subject: [Haskell-cafe] Surprising lack of generalisation
In-Reply-To: <20210211142339.GQ1520@cloudinit-builder>
References: <20210210113149.GN1520@cloudinit-builder>
 <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>
 <20210210152142.GO1520@cloudinit-builder>
 <010f01778efbdd15-c5e57051-65fd-427e-9edd-3c2c0e5e59f0-000000@us-east-2.amazonses.com>
 <20210211142339.GQ1520@cloudinit-builder>
Message-ID: <010f0177919e5c8b-77f90d31-af7f-4e01-9125-b3e9ce434cc1-000000@us-east-2.amazonses.com>



> On Feb 11, 2021, at 9:23 AM, Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
> 
>   "In pFG, the argument pBArg has been given a type (moreover a
>   monomorphic type) by the type signature for pFG itself.  Why does
>   the definition of 'closed' require the variable to be let-bound?
>   Wouldn't lambda-bound with a type implicitly provided by an
>   explicit type signature for the lambda" be equally good?"

I think so, yes.

Full disclosure: before this thread, I had never looked closely at the MonoLocalBinds definition. For years, I was operating under a simpler premise: "a local binding group is closed if all variables free in the group are bound at top-level". That is, any binding group that capture variables from the local definition would not be generalized. This interpretation means that your definition within pFG1 would also not be generalized. But my working definition was too limited, as the manual explains.

Bottom line: I think you're right that we could do more generalization. I'm not sure how easy this would be to implement (I don't know how GHC tracks this information off the top of my head), but I do think it's worth filing a ticket to see if we can easily do better.

Good conversation! I've learned something here.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210211/a9d617a5/attachment.html>

From oleg.grenrus at iki.fi  Thu Feb 11 15:14:55 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Thu, 11 Feb 2021 17:14:55 +0200
Subject: [Haskell-cafe] Surprising lack of generalisation
In-Reply-To: <010f0177919e5c8b-77f90d31-af7f-4e01-9125-b3e9ce434cc1-000000@us-east-2.amazonses.com>
References: <20210210113149.GN1520@cloudinit-builder>
 <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>
 <20210210152142.GO1520@cloudinit-builder>
 <010f01778efbdd15-c5e57051-65fd-427e-9edd-3c2c0e5e59f0-000000@us-east-2.amazonses.com>
 <20210211142339.GQ1520@cloudinit-builder>
 <010f0177919e5c8b-77f90d31-af7f-4e01-9125-b3e9ce434cc1-000000@us-east-2.amazonses.com>
Message-ID: <1d440c38-6ebb-431c-16f5-ffe21f08070c@iki.fi>

I also worked under the relaxed interpretation, and it is surprising to
me that GHC does better.

if GHC will do even better, I'd try to first formulate what that better is.

"a local binding group is closed if all variables free in the group are
bound at top-level" is somewhat understandable, adding further
exceptions makes more programs to type-check, but if specifications
becomes more cumbersome verifying that implementations does what
specification advertises becomes more difficult.

The "the variable has an explicit type signature that has no free type
variables" additions seems arbitrary, it's not motivated in the manual.
How much of the "real code" will break if it is removed?

- Oleg

On 11.2.2021 17.03, Richard Eisenberg wrote:
>
>
>> On Feb 11, 2021, at 9:23 AM, Tom Ellis
>> <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk
>> <mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>> wrote:
>>
>>   "In pFG, the argument pBArg has been given a type (moreover a
>>   monomorphic type) by the type signature for pFG itself.  Why does
>>   the definition of 'closed' require the variable to be let-bound?
>>   Wouldn't lambda-bound with a type implicitly provided by an
>>   explicit type signature for the lambda" be equally good?"
>
> I think so, yes.
>
> Full disclosure: before this thread, I had never looked closely at the
> MonoLocalBinds definition. For years, I was operating under a simpler
> premise: "a local binding group is closed if all variables free in the
> group are bound at top-level". That is, any binding group that capture
> variables from the local definition would not be generalized. This
> interpretation means that your definition within pFG1 would also not
> be generalized. But my working definition was too limited, as the
> manual explains.
>
> Bottom line: I think you're right that we could do more
> generalization. I'm not sure how easy this would be to implement (I
> don't know how GHC tracks this information off the top of my head),
> but I do think it's worth filing a ticket to see if we can easily do
> better.
>
> Good conversation! I've learned something here.
>
> Thanks,
> Richard
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210211/895cc616/attachment.html>

From rae at richarde.dev  Thu Feb 11 15:28:53 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 11 Feb 2021 15:28:53 +0000
Subject: [Haskell-cafe] Surprising lack of generalisation
In-Reply-To: <1d440c38-6ebb-431c-16f5-ffe21f08070c@iki.fi>
References: <20210210113149.GN1520@cloudinit-builder>
 <010f01778c228b4d-350e49e4-d90a-434a-bd39-6fcc3838a605-000000@us-east-2.amazonses.com>
 <20210210152142.GO1520@cloudinit-builder>
 <010f01778efbdd15-c5e57051-65fd-427e-9edd-3c2c0e5e59f0-000000@us-east-2.amazonses.com>
 <20210211142339.GQ1520@cloudinit-builder>
 <010f0177919e5c8b-77f90d31-af7f-4e01-9125-b3e9ce434cc1-000000@us-east-2.amazonses.com>
 <1d440c38-6ebb-431c-16f5-ffe21f08070c@iki.fi>
Message-ID: <010f017791b598ac-28846488-332f-4764-9b6e-be4b20af858f-000000@us-east-2.amazonses.com>



> On Feb 11, 2021, at 10:14 AM, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
> 
> The "the variable has an explicit type signature that has no free type variables" additions seems arbitrary, it's not motivated in the manual. How much of the "real code" will break if it is removed?

A very good question. But I think one that's better to ask in a ticket, so we don't lose these pieces. The question is: do we want to be dumb but predictable, or clever but capricious? Tom seems to be moving toward the latter, while Oleg seems to moving toward the former. I tend to prefer dumb but predictable, too, but I don't know how much code would break. Right now, I think we're dumb and capricious, so that's an unhappy place to be.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210211/1189fa8c/attachment.html>

From Juan.Casanova at ed.ac.uk  Fri Feb 12 18:50:10 2021
From: Juan.Casanova at ed.ac.uk (CASANOVA Juan)
Date: Fri, 12 Feb 2021 18:50:10 +0000
Subject: [Haskell-cafe] Kind pairs and kind currying/uncurrying
Message-ID: <DB6PR05MB4694B61AB9F48FE7E1E060DBDF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>

Hello again,

At this point, I think what I am trying to do is simply not possible in Haskell, not even with as many extensions as I would want. Perhaps with template Haskell, but that's ground that I am still afraid to tread. But I thought I would ask anyway.

(All the code in the rest of the email assumes as many extensions as GHC asks me to compile).

The background is more complicated and controversial than the question itself, but I'll give a little bit of it so that you know why I'm trying to do this.

I am trying to define a type class that takes other type classes as arguments. That is fairly straightforward by itself. A single parameter type-class has kind

(k -> Constraint).

So I can write my class

SecondOrderClass (cl :: k -> Constraint)

The problem, however, is that I want to use this class for multi-parameter type classes as well. A two parameter type class has kind

(k1 -> k2 -> Constraint)

The most general unifier of these two kinds is, unfortunately, a free kind (k), which thus includes kinds that are not type classes (like types). Therefore, it is not possible to directly specify a class that takes as parameter a type class with any number of arguments.

So, thus I thought: I've seen this before. This is currying and uncurrying. Except I'm doing it with kinds except of with types. A brief search didn't yield me any library that would do this. So I thought: This should be fairly easy to do by myself if I throw enough extensions at it.

Well, I failed. I tried two variations and neither worked. To be clear, what I tried to do is to

  *   Define a type synonym that would produce a kind representing a pair of two given kinds.
  *   Define type synonyms for currying and uncurrying kinds using the pair kind.

The first variation I tried I feel is the most semantically accurate, as it is clear from the beginning of what I am trying to do. The main "insight" I used was using/assuming extensionality of kinds (and partial application of type synonyms) to define a kind pair:

type KindPair (a :: ka) (b :: kb) (f :: ka -> kb -> *) = f a b

A pair of kinds is simply anything that "owes the two kinds to the type checker". Thus, if given anything expecting those two kinds, it would feed them to it. This by itself compiles fine. But then when trying to define currying and uncurrying, it won't type check:

type KCurry (tf :: (KindPair ka kb) -> kc) (ta :: ka) (tb :: kb) = kc
type KUncurry (tf :: ka -> kb -> kc) (tp :: (KindPair ka kb)) = kc

The error I get is: The type synonym ‘KindPair’ should have 3 arguments, but has been given 2

Partial application of type synonyms is fine, I use it all the time. But it seems it is not fine when it is "kind synonyms"??? It is not even asking me for any extension to allow it.

So I tried a more syntactic approach, abusing the notion that GHC treats kinds and types very similarly:

type KindPair (a :: ka) (b :: kb) = ((ka -> kb -> *) -> *)

type KCurry (tf :: (KindPair ka kb) -> kc) = ka -> kb -> kc
type KUncurry (tf :: ka -> kb -> kc) = (KindPair ka kb) -> kc

This type checks, but it is just a mirage. If you check the kinds of KCurry and KUncurry it does not look good:

(KindPair ka kb -> kc) -> *

Uhh... that's not what I said. It's taking the right hand side entirely as a type, not as a kind.

This becomes obvious when we try to use them:

ftest :: KCurry (KUncurry (,)) Int Int -> (Int, Int)

This does not type check, regardless of the definition (ideally ftest = id would work, but we do not even get that far).

The error is:

Expected kind ‘* -> * -> *’, but ‘KCurry (KUncurry (,))’ has kind ‘*’

So, my question is: Is what I am trying to do possible in Haskell?

Is what I am trying to do completely absurd? I do not think it is, but maybe I am being naive?

Thanks in advance, and sorry for the long email (again). I tried to be as straight to the point as possible.
Juan.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210212/b278f3d9/attachment.html>

From rae at richarde.dev  Fri Feb 12 20:04:36 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 12 Feb 2021 20:04:36 +0000
Subject: [Haskell-cafe] Kind pairs and kind currying/uncurrying
In-Reply-To: <DB6PR05MB4694B61AB9F48FE7E1E060DBDF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
References: <DB6PR05MB4694B61AB9F48FE7E1E060DBDF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
Message-ID: <010f017797d86026-51f48690-4b44-4663-a491-05b4ceed4b0a-000000@us-east-2.amazonses.com>

Hi Juan,



> On Feb 12, 2021, at 1:50 PM, CASANOVA Juan <Juan.Casanova at ed.ac.uk> wrote:
> 
> The first variation I tried I feel is the most semantically accurate, as it is clear from the beginning of what I am trying to do. The main "insight" I used was using/assuming extensionality of kinds (and partial application of type synonyms) to define a kind pair:
> 
> type KindPair (a :: ka) (b :: kb) (f :: ka -> kb -> *) = f a b

Did you try using the normal pair constructor?

> type KindPair a b = '(a, b)

That would seem to meet your needs, but perhaps I'm missing something.
> 
> Partial application of type synonyms is fine, I use it all the time. But it seems it is not fine when it is "kind synonyms"??? It is not even asking me for any extension to allow it.

Partial application of type synonyms is not fine. Try it out. (GHC does allow this in the definition of other type synonyms, as long as it works out in the end. But it won't work in e.g. type signatures.) I think this is the crux of the problem.

> type KCurry (tf :: (KindPair ka kb) -> kc) = ka -> kb -> kc
> type KUncurry (tf :: ka -> kb -> kc) = (KindPair ka kb) -> kc

My definitions of these look like this:

> type Curry :: ((a, b) -> c) -> a -> b -> c
> type Curry f x y = f '(x, y)
> 
> type Uncurry :: (a -> b -> c) -> (a, b) -> c
> type family Uncurry f xy where
>   Uncurry f '(x, y) = f x y

where I've also used -XStandaloneKindSignatures (in GHC 8.10 and up), but you don't need to.

I think part of the problem is that your definitions appear "one level off", unless I'm misunderstanding: you're giving the kind of the result you want, not the actual result you want.

> 
> Is what I am trying to do completely absurd? I do not think it is, but maybe I am being naive?

No, not absurd. I do think that currying/uncurrying in types is problematic because of the saturation condition on type synonyms and type families. But my guess is that there is a way of addressing your root problem, with class constraints, but I'd need more information to suggest a concrete next step.

I hope this helps!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210212/f7621dda/attachment.html>

From Juan.Casanova at ed.ac.uk  Fri Feb 12 22:57:28 2021
From: Juan.Casanova at ed.ac.uk (CASANOVA Juan)
Date: Fri, 12 Feb 2021 22:57:28 +0000
Subject: [Haskell-cafe] Kind pairs and kind currying/uncurrying
In-Reply-To: <010f017797d86026-51f48690-4b44-4663-a491-05b4ceed4b0a-000000@us-east-2.amazonses.com>
References: <DB6PR05MB4694B61AB9F48FE7E1E060DBDF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>,
 <010f017797d86026-51f48690-4b44-4663-a491-05b4ceed4b0a-000000@us-east-2.amazonses.com>
Message-ID: <DB6PR05MB469458C17DE57C034AD4CF40DF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>

Thanks Richard,

I'll try to stay as short as possible.

"Did you try using the normal pair constructor?"

No, I didn't. I didn't even know it existed. I think now I've seen it before. This is a kind pair, which is different from a pair type, is this correct? So, what I am saying, the ' in the front relevantly changes what it means for the type checker. It's not as simple as using a tuple type (I'm pretty sure I even tried this and the type checker looked at me in confusion).

I must complain, though, that I've looked for "kind pair Haskell", "type pair Haskell", "multiple kinds Haskell", "tuple kinds Haskell" and "kind tuples Haskell", and found zero references to this particular construct, so I can't really feel like it's my fault for not knowing about it!

About partial application, you are absolutely right, and I actually knew this, but it sort of went out of my mind when I wrote that. The way that I tend to write Haskell, I do use partial type synonyms quite a bit, and I try to keep type synonyms as high-kinded as possible. That is why I forgot about this. So instead of type List a = [a], it's better to use type List = [] because then you can do a lot more with it. But this is besides the point.

The reasons your solution seems to work and mine doesn't are both the kind pair construct, and the usage of a type family. I've looked into type families before, but never used them in practice, mostly because they didn't actually allow me to do what I looked them up for. This might be the first time that type families are actually the answer for me. I'm still a bit scared of them and not understanding what you can / cannot do with them. This relates to "giving the kind of the result I want": Without type families you cannot do any sort of "computation" at the type level, just syntactic things. I thought this would be enough for Curry / Uncurry, but it obviously isn't.

In practice, however, this was me trying to save myself some work by implementing a high-level solution that I could reuse several times. When I failed, I wrote the email to try and learn from it, but then moved forward with implementing it in a more mundane way (but more redundant). At this point, I think I'm going to keep going with this implementation. I even think I would not have gotten so much from the curry / uncurry now that I think back. But this was definitely very instructive.

Thanks again.
Juan.




________________________________
From: Richard Eisenberg <rae at richarde.dev>
Sent: 12 February 2021 20:04
To: CASANOVA Juan <Juan.Casanova at ed.ac.uk>
Cc: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Kind pairs and kind currying/uncurrying

This email was sent to you by someone outside the University.
You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
Hi Juan,



On Feb 12, 2021, at 1:50 PM, CASANOVA Juan <Juan.Casanova at ed.ac.uk<mailto:Juan.Casanova at ed.ac.uk>> wrote:

The first variation I tried I feel is the most semantically accurate, as it is clear from the beginning of what I am trying to do. The main "insight" I used was using/assuming extensionality of kinds (and partial application of type synonyms) to define a kind pair:

type KindPair (a :: ka) (b :: kb) (f :: ka -> kb -> *) = f a b

Did you try using the normal pair constructor?

> type KindPair a b = '(a, b)

That would seem to meet your needs, but perhaps I'm missing something.

Partial application of type synonyms is fine, I use it all the time. But it seems it is not fine when it is "kind synonyms"??? It is not even asking me for any extension to allow it.

Partial application of type synonyms is not fine. Try it out. (GHC does allow this in the definition of other type synonyms, as long as it works out in the end. But it won't work in e.g. type signatures.) I think this is the crux of the problem.

type KCurry (tf :: (KindPair ka kb) -> kc) = ka -> kb -> kc
type KUncurry (tf :: ka -> kb -> kc) = (KindPair ka kb) -> kc

My definitions of these look like this:

type Curry :: ((a, b) -> c) -> a -> b -> c
type Curry f x y = f '(x, y)

type Uncurry :: (a -> b -> c) -> (a, b) -> c
type family Uncurry f xy where
  Uncurry f '(x, y) = f x y

where I've also used -XStandaloneKindSignatures (in GHC 8.10 and up), but you don't need to.

I think part of the problem is that your definitions appear "one level off", unless I'm misunderstanding: you're giving the kind of the result you want, not the actual result you want.


Is what I am trying to do completely absurd? I do not think it is, but maybe I am being naive?

No, not absurd. I do think that currying/uncurrying in types is problematic because of the saturation condition on type synonyms and type families. But my guess is that there is a way of addressing your root problem, with class constraints, but I'd need more information to suggest a concrete next step.

I hope this helps!
Richard
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210212/bf153113/attachment.html>

From david.feuer at gmail.com  Fri Feb 12 23:33:02 2021
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 12 Feb 2021 18:33:02 -0500
Subject: [Haskell-cafe] Kind pairs and kind currying/uncurrying
In-Reply-To: <DB6PR05MB469458C17DE57C034AD4CF40DF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
References: <DB6PR05MB4694B61AB9F48FE7E1E060DBDF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
 <010f017797d86026-51f48690-4b44-4663-a491-05b4ceed4b0a-000000@us-east-2.amazonses.com>
 <DB6PR05MB469458C17DE57C034AD4CF40DF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
Message-ID: <CAMgWh9tCDVsgSJpFGwMC++5niw_7bSUNuddUV71zsOyEKTbDVw@mail.gmail.com>

Pair kinds come with DataKinds. If you write

  data Pair a b = MkPair a b

then you get two types:

  type Pair :: Type -> Type -> Type
  type 'MkPair :: j -> k -> Pair j k

The built-in tuples work similarly, but with a bit of special syntax, and
they use punning. So

  type (,) :: Type -> Type -> Type
  type '(,) :: j -> k -> (j, k)

So, for example, the type '( 'True, Int) has kind (Bool, Type).

On Fri, Feb 12, 2021, 5:57 PM CASANOVA Juan <Juan.Casanova at ed.ac.uk> wrote:

> Thanks Richard,
>
> I'll try to stay as short as possible.
>
> "Did you try using the normal pair constructor?"
>
> No, I didn't. I didn't even know it existed. I think now I've seen it
> before. This is a kind pair, which is different from a pair type, is this
> correct? So, what I am saying, the ' in the front relevantly changes what
> it means for the type checker. It's not as simple as using a tuple type
> (I'm pretty sure I even tried this and the type checker looked at me in
> confusion).
>
> I must complain, though, that I've looked for "kind pair Haskell", "type
> pair Haskell", "multiple kinds Haskell", "tuple kinds Haskell" and "kind
> tuples Haskell", and found zero references to this particular construct, so
> I can't really feel like it's my fault for not knowing about it!
>
> About partial application, you are absolutely right, and I actually knew
> this, but it sort of went out of my mind when I wrote that. The way that I
> tend to write Haskell, I do use partial type synonyms quite a bit, *and I
> try to keep type synonyms as high-kinded as possible. *That is why I
> forgot about this. So instead of type List a = [a], it's better to use type
> List = [] because then you can do a lot more with it. But this is besides
> the point.
>
> The reasons your solution seems to work and mine doesn't are both the kind
> pair construct, and the usage of a type family. I've looked into type
> families before, but never used them in practice, mostly because they
> didn't actually allow me to do what I looked them up for. This might be the
> first time that type families are actually the answer for me. I'm still a
> bit scared of them and not understanding what you can / cannot do with
> them. This relates to "giving the kind of the result I want": Without type
> families you cannot do any sort of "computation" at the type level, just
> syntactic things. I thought this would be enough for Curry / Uncurry, but
> it obviously isn't.
>
> In practice, however, this was me trying to save myself some work by
> implementing a high-level solution that I could reuse several times. When I
> failed, I wrote the email to try and learn from it, but then moved forward
> with implementing it in a more mundane way (but more redundant). At this
> point, I think I'm going to keep going with this implementation. I even
> think I would not have gotten so much from the curry / uncurry now that I
> think back. But this was definitely very instructive.
>
> Thanks again.
> Juan.
>
>
>
>
> ------------------------------
> *From:* Richard Eisenberg <rae at richarde.dev>
> *Sent:* 12 February 2021 20:04
> *To:* CASANOVA Juan <Juan.Casanova at ed.ac.uk>
> *Cc:* haskell-cafe at haskell.org <haskell-cafe at haskell.org>
> *Subject:* Re: [Haskell-cafe] Kind pairs and kind currying/uncurrying
>
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the
> email is genuine and the content is safe.
> Hi Juan,
>
>
>
> On Feb 12, 2021, at 1:50 PM, CASANOVA Juan <Juan.Casanova at ed.ac.uk> wrote:
>
> The first variation I tried I feel is the most semantically accurate, as
> it is clear from the beginning of what I am trying to do. The main
> "insight" I used was using/assuming extensionality of kinds (and partial
> application of type synonyms) to define a kind pair:
>
>
> type KindPair (a :: ka) (b :: kb) (f :: ka -> kb -> *) = f a b
>
>
> Did you try using the normal pair constructor?
>
> > type KindPair a b = '(a, b)
>
> That would seem to meet your needs, but perhaps I'm missing something.
>
>
> Partial application of type synonyms is fine, I use it all the time. But
> it seems it is not fine when it is "kind synonyms"??? It is not even asking
> me for any extension to allow it.
>
>
> Partial application of type synonyms is *not* fine. Try it out. (GHC does
> allow this in the definition of other type synonyms, as long as it works
> out in the end. But it won't work in e.g. type signatures.) I think this is
> the crux of the problem.
>
> type KCurry (tf :: (KindPair ka kb) -> kc) = ka -> kb -> kc
> type KUncurry (tf :: ka -> kb -> kc) = (KindPair ka kb) -> kc
>
>
> My definitions of these look like this:
>
> type Curry :: ((a, b) -> c) -> a -> b -> c
> type Curry f x y = f '(x, y)
>
> type Uncurry :: (a -> b -> c) -> (a, b) -> c
> type family Uncurry f xy where
>   Uncurry f '(x, y) = f x y
>
>
> where I've also used -XStandaloneKindSignatures (in GHC 8.10 and up), but
> you don't need to.
>
> I think part of the problem is that your definitions appear "one level
> off", unless I'm misunderstanding: you're giving the kind of the result you
> want, not the actual result you want.
>
>
> Is what I am trying to do completely absurd? I do not think it is, but
> maybe I am being naive?
>
>
> No, not absurd. I do think that currying/uncurrying in types is
> problematic because of the saturation condition on type synonyms and type
> families. But my guess is that there is a way of addressing your root
> problem, with class constraints, but I'd need more information to suggest a
> concrete next step.
>
> I hope this helps!
> Richard
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336.
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210212/ccbf67f9/attachment.html>

From trupill at gmail.com  Sat Feb 13 20:20:40 2021
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sat, 13 Feb 2021 20:20:40 +0000
Subject: [Haskell-cafe] Request for Nominations to the GHC Steering Committee
Message-ID: <CAHnFXOsdqHee8PwAwb+kuRgc42BUOC+=K+6BhnpWKPG5hSS88Q@mail.gmail.com>

Dear Haskell community,

The three-year term limit of some of the GHC Steering committee
members has expired. We are really grateful for the awesome work
that Iavor, Richard, and Joachim have done through these years
(especially the latter, who has acted as secretary.) As a result, the
GHC Steering committee is seeking nominations for 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.

We are looking for members who have 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.

The GHC developers themselves are already well represented already.  We
seek Haskell _users_ more than GHC hackers.

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 interim committee
secretary) at trupill at gmail.com until February 28th. 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,
Alejandro Serrano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210213/b44cb1ca/attachment.html>

From rae at richarde.dev  Sat Feb 13 20:38:29 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Sat, 13 Feb 2021 20:38:29 +0000
Subject: [Haskell-cafe] Kind pairs and kind currying/uncurrying
In-Reply-To: <DB6PR05MB469458C17DE57C034AD4CF40DF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
References: <DB6PR05MB4694B61AB9F48FE7E1E060DBDF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
 <010f017797d86026-51f48690-4b44-4663-a491-05b4ceed4b0a-000000@us-east-2.amazonses.com>
 <DB6PR05MB469458C17DE57C034AD4CF40DF8B9@DB6PR05MB4694.eurprd05.prod.outlook.com>
Message-ID: <010f01779d1dc18e-48901b7d-09cd-4458-bade-3570df41c747-000000@us-east-2.amazonses.com>



> On Feb 12, 2021, at 5:57 PM, CASANOVA Juan <Juan.Casanova at ed.ac.uk> wrote:
> 
> Thanks Richard,
> 
> I'll try to stay as short as possible.
> 
> "Did you try using the normal pair constructor?"
> 
> No, I didn't. I didn't even know it existed. I think now I've seen it before. This is a kind pair, which is different from a pair type, is this correct? So, what I am saying, the ' in the front relevantly changes what it means for the type checker. It's not as simple as using a tuple type (I'm pretty sure I even tried this and the type checker looked at me in confusion).

I wouldn't call it a kind pair. I think of '(..., ...) just as the normal pair constructor, but used in a type. The reason for the ' is to disambiguate it with (..., ...), which is the type of pairs. It might be helpful to see the kinds of these constructions:

'(,) :: forall a b. a -> b -> (a, b)
(,) :: Type -> Type -> Type

> 
> I must complain, though, that I've looked for "kind pair Haskell", "type pair Haskell", "multiple kinds Haskell", "tuple kinds Haskell" and "kind tuples Haskell", and found zero references to this particular construct, so I can't really feel like it's my fault for not knowing about it!

I'm not surprised this information is hard to find. On the one hand, I think the Haskell community (myself included) does a mediocre job of clarifying these sorts of things. On the other, '(,) isn't a special case at all: it behaves in an exactly analogous manner to using any other constructor in a type. (For what it's worth, I don't have a good name for this idea, beyond "the pair constructor used in a type".)

> 
> About partial application, you are absolutely right, and I actually knew this, but it sort of went out of my mind when I wrote that. The way that I tend to write Haskell, I do use partial type synonyms quite a bit, and I try to keep type synonyms as high-kinded as possible. That is why I forgot about this. So instead of type List a = [a], it's better to use type List = [] because then you can do a lot more with it. But this is besides the point.

I agree completely that `type List = []` is better than `type List a = [a]`, because the former allows List to be used on its own; the latter would require the argument at all usage sites. It seems you understand this. (Small pointer: I didn't at first understand your meaning from "as high-kinded as possible". I would say "as eta-reduced as possible", but that's perhaps even more opaque if you don't know the term.)

> 
> The reasons your solution seems to work and mine doesn't are both the kind pair construct, and the usage of a type family. I've looked into type families before, but never used them in practice, mostly because they didn't actually allow me to do what I looked them up for. This might be the first time that type families are actually the answer for me. I'm still a bit scared of them and not understanding what you can / cannot do with them. This relates to "giving the kind of the result I want": Without type families you cannot do any sort of "computation" at the type level, just syntactic things. I thought this would be enough for Curry / Uncurry, but it obviously isn't.

The problem is that, for Uncurry, we need to pattern-match on a pair. Pattern-matching requires a type family. Type families are not particularly hard to work with, though: think of them simply as functions written in types. The only "gotcha" is that they always must be saturated.

> 
> In practice, however, this was me trying to save myself some work by implementing a high-level solution that I could reuse several times. When I failed, I wrote the email to try and learn from it, but then moved forward with implementing it in a more mundane way (but more redundant). At this point, I think I'm going to keep going with this implementation. I even think I would not have gotten so much from the curry / uncurry now that I think back. But this was definitely very instructive.

Glad to be of service!

Richard

> 
> Thanks again.
> Juan.
> 
> 
> 
> 
> From: Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>
> Sent: 12 February 2021 20:04
> To: CASANOVA Juan <Juan.Casanova at ed.ac.uk <mailto:Juan.Casanova at ed.ac.uk>>
> Cc: haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org> <haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org>>
> Subject: Re: [Haskell-cafe] Kind pairs and kind currying/uncurrying
>  
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
> Hi Juan,
> 
> 
> 
>> On Feb 12, 2021, at 1:50 PM, CASANOVA Juan <Juan.Casanova at ed.ac.uk <mailto:Juan.Casanova at ed.ac.uk>> wrote:
>> 
>> The first variation I tried I feel is the most semantically accurate, as it is clear from the beginning of what I am trying to do. The main "insight" I used was using/assuming extensionality of kinds (and partial application of type synonyms) to define a kind pair:
>> 
>> type KindPair (a :: ka) (b :: kb) (f :: ka -> kb -> *) = f a b
> 
> Did you try using the normal pair constructor?
> 
> > type KindPair a b = '(a, b)
> 
> That would seem to meet your needs, but perhaps I'm missing something.
>> 
>> Partial application of type synonyms is fine, I use it all the time. But it seems it is not fine when it is "kind synonyms"??? It is not even asking me for any extension to allow it.
> 
> Partial application of type synonyms is not fine. Try it out. (GHC does allow this in the definition of other type synonyms, as long as it works out in the end. But it won't work in e.g. type signatures.) I think this is the crux of the problem.
> 
>> type KCurry (tf :: (KindPair ka kb) -> kc) = ka -> kb -> kc
>> type KUncurry (tf :: ka -> kb -> kc) = (KindPair ka kb) -> kc
> 
> My definitions of these look like this:
> 
>> type Curry :: ((a, b) -> c) -> a -> b -> c
>> type Curry f x y = f '(x, y)
>> 
>> type Uncurry :: (a -> b -> c) -> (a, b) -> c
>> type family Uncurry f xy where
>>   Uncurry f '(x, y) = f x y
> 
> where I've also used -XStandaloneKindSignatures (in GHC 8.10 and up), but you don't need to.
> 
> I think part of the problem is that your definitions appear "one level off", unless I'm misunderstanding: you're giving the kind of the result you want, not the actual result you want.
> 
>> 
>> Is what I am trying to do completely absurd? I do not think it is, but maybe I am being naive?
> 
> No, not absurd. I do think that currying/uncurrying in types is problematic because of the saturation condition on type synonyms and type families. But my guess is that there is a way of addressing your root problem, with class constraints, but I'd need more information to suggest a concrete next step.
> 
> I hope this helps!
> Richard
> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336._______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210213/e1110dc5/attachment.html>

From athas at sigkill.dk  Mon Feb 15 15:14:52 2021
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 15 Feb 2021 16:14:52 +0100
Subject: [Haskell-cafe] Why does my module take so long to compile?
Message-ID: <87y2fp5pn7.fsf@sigkill.dk>

I have a program with about 220 modules.  One of these modules takes
_much_ longer to compile than the others (several minutes longer).  I
don't understand why.  It compiled much faster with GHC 8.8.3, but got
orders of magnitude slower when I changed to GHC 8.10.2.  I don't
understand why, since I don't think there is nothing special about the
module - e.g. no type-level programming.

Is there any good way to "profile" the stack or cabal compilation
process to at least get an intuition for what takes so long?  Note that
the module is in the middle of the dependency tree of my program, so it
is not viable to separate it out and compile it manually with GHC.  It's
slow even when I pass '--fast' to stack which should disable the
optimiser, so I guess the type checker may be spending a lot of time on
handling the admittedly large amount of typeclass constraints I have on
some of my definitions.

I'm mostly looking for techniques and tools I can also use next time
this problem occurs, not the specific problem here, but if anyone's
curious, the module in question is this one:
https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKernels/DistributeNests.hs

-- 
\  Troels
/\ Henriksen

From lemming at henning-thielemann.de  Mon Feb 15 16:39:52 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 15 Feb 2021 17:39:52 +0100 (CET)
Subject: [Haskell-cafe] Why does my module take so long to compile?
In-Reply-To: <87y2fp5pn7.fsf@sigkill.dk>
References: <87y2fp5pn7.fsf@sigkill.dk>
Message-ID: <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>


On Mon, 15 Feb 2021, Troels Henriksen wrote:

> I have a program with about 220 modules.  One of these modules takes
> _much_ longer to compile than the others (several minutes longer).  I
> don't understand why.  It compiled much faster with GHC 8.8.3, but got
> orders of magnitude slower when I changed to GHC 8.10.2.  I don't
> understand why, since I don't think there is nothing special about the
> module - e.g. no type-level programming.

Does the problem persist with GHC-8.10.4?

I would try to out-comment parts of the module and watch when compilation 
becomes faster.

From athas at sigkill.dk  Mon Feb 15 17:03:11 2021
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 15 Feb 2021 18:03:11 +0100
Subject: [Haskell-cafe] Why does my module take so long to compile?
In-Reply-To: <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 (Henning Thielemann's message of "Mon, 15 Feb 2021 17:39:52 +0100
 (CET)")
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
Message-ID: <87pn115kmo.fsf@sigkill.dk>

Henning Thielemann <lemming at henning-thielemann.de> writes:

> On Mon, 15 Feb 2021, Troels Henriksen wrote:
>
>> I have a program with about 220 modules.  One of these modules takes
>> _much_ longer to compile than the others (several minutes longer).  I
>> don't understand why.  It compiled much faster with GHC 8.8.3, but got
>> orders of magnitude slower when I changed to GHC 8.10.2.  I don't
>> understand why, since I don't think there is nothing special about the
>> module - e.g. no type-level programming.
>
> Does the problem persist with GHC-8.10.4?

Yes.  I'll try with GHC 9.10.1 once my dependencies catch up.

> I would try to out-comment parts of the module and watch when
> compilation becomes faster.

I will try that.  I also noticed that other modules are affected as
well, although to a lesser degree, and by passing
'--ghc-options=-dshow-passes' I obtained this information:

!!! Desugar [Futhark.Pass.ExtractKernels.DistributeNests]: finished in 255448.24 milliseconds, allocated 363811.623 megabytes

So apparently the "desugar" pass takes over four minutes.  Apart from
lowering Haskell into Core, what exactly does this pass do that is so
expensive?  The following Simplifier passes take almost no time in
comparison.

-- 
\  Troels
/\ Henriksen

From carter.schonwald at gmail.com  Mon Feb 15 17:11:02 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 15 Feb 2021 12:11:02 -0500
Subject: [Haskell-cafe] Why does my module take so long to compile?
In-Reply-To: <87pn115kmo.fsf@sigkill.dk>
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
Message-ID: <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>

How big are your data types in the file In question? Do you ghc generics or
deriving or template Haskell? Could you share a link to the file in
question ?

On Mon, Feb 15, 2021 at 12:06 PM Troels Henriksen <athas at sigkill.dk> wrote:

> Henning Thielemann <lemming at henning-thielemann.de> writes:
>
> > On Mon, 15 Feb 2021, Troels Henriksen wrote:
> >
> >> I have a program with about 220 modules.  One of these modules takes
> >> _much_ longer to compile than the others (several minutes longer).  I
> >> don't understand why.  It compiled much faster with GHC 8.8.3, but got
> >> orders of magnitude slower when I changed to GHC 8.10.2.  I don't
> >> understand why, since I don't think there is nothing special about the
> >> module - e.g. no type-level programming.
> >
> > Does the problem persist with GHC-8.10.4?
>
> Yes.  I'll try with GHC 9.10.1 once my dependencies catch up.
>
> > I would try to out-comment parts of the module and watch when
> > compilation becomes faster.
>
> I will try that.  I also noticed that other modules are affected as
> well, although to a lesser degree, and by passing
> '--ghc-options=-dshow-passes' I obtained this information:
>
> !!! Desugar [Futhark.Pass.ExtractKernels.DistributeNests]: finished in
> 255448.24 milliseconds, allocated 363811.623 megabytes
>
> So apparently the "desugar" pass takes over four minutes.  Apart from
> lowering Haskell into Core, what exactly does this pass do that is so
> expensive?  The following Simplifier passes take almost no time in
> comparison.
>
> --
> \  Troels
> /\ Henriksen
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210215/ec9ca4fb/attachment.html>

From david.feuer at gmail.com  Mon Feb 15 17:13:21 2021
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 15 Feb 2021 12:13:21 -0500
Subject: [Haskell-cafe] Why does my module take so long to compile?
In-Reply-To: <87pn115kmo.fsf@sigkill.dk>
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
Message-ID: <CAMgWh9samNjOX-5tD+pXb2u2h=P+=Khm2B5oXX=ysD9EUta4wQ@mail.gmail.com>

I suspect that to get deeper into this you'll need a debugging build of
GHC, which I believe will break down the desugaring pass into its
constituent sub-passes. One possibility is that the "gentle optimization"
pass is proving not to be so gentle on your code.

On Mon, Feb 15, 2021, 12:03 PM Troels Henriksen <athas at sigkill.dk> wrote:

> Henning Thielemann <lemming at henning-thielemann.de> writes:
>
> > On Mon, 15 Feb 2021, Troels Henriksen wrote:
> >
> >> I have a program with about 220 modules.  One of these modules takes
> >> _much_ longer to compile than the others (several minutes longer).  I
> >> don't understand why.  It compiled much faster with GHC 8.8.3, but got
> >> orders of magnitude slower when I changed to GHC 8.10.2.  I don't
> >> understand why, since I don't think there is nothing special about the
> >> module - e.g. no type-level programming.
> >
> > Does the problem persist with GHC-8.10.4?
>
> Yes.  I'll try with GHC 9.10.1 once my dependencies catch up.
>
> > I would try to out-comment parts of the module and watch when
> > compilation becomes faster.
>
> I will try that.  I also noticed that other modules are affected as
> well, although to a lesser degree, and by passing
> '--ghc-options=-dshow-passes' I obtained this information:
>
> !!! Desugar [Futhark.Pass.ExtractKernels.DistributeNests]: finished in
> 255448.24 milliseconds, allocated 363811.623 megabytes
>
> So apparently the "desugar" pass takes over four minutes.  Apart from
> lowering Haskell into Core, what exactly does this pass do that is so
> expensive?  The following Simplifier passes take almost no time in
> comparison.
>
> --
> \  Troels
> /\ Henriksen
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210215/b57cd25d/attachment.html>

From athas at sigkill.dk  Mon Feb 15 17:20:55 2021
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 15 Feb 2021 18:20:55 +0100
Subject: [Haskell-cafe] Why does my module take so long to compile?
In-Reply-To: <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
 (Carter Schonwald's message of "Mon, 15 Feb 2021 12:11:02 -0500")
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
 <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
Message-ID: <87zh05458o.fsf@sigkill.dk>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> How big are your data types in the file In question? Do you ghc generics or
> deriving or template Haskell? Could you share a link to the file in
> question ?

The file does not define any large data types itself, but it operates on
some fairly large data types (an AST, it's a compiler).  But so do many
other modules that work just fine.  It uses no generics, nontrivial
deriving, or Template Haskell.  It's this file:
https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKernels/DistributeNests.hs

I also found a handful of other modules in my project that are
significantly slower to compile in GHC 8.10, and seemingly also because
of the desugarer, but none of them have any obvious smoking guns like
generics or TH.

The only commonality I can find is that the affected modules contain
functions with a relatively large typeclass context.  I use
ConstraintKinds to make them more concise, and I guess unfolded there
may be 30-40 equality/class constraints in total.  Like this:

    type DistLore lore =
      ( Bindable lore,
        HasSegOp lore,
        BinderOps lore,
        LetDec lore ~ Type,
        ExpDec lore ~ (),
        BodyDec lore ~ ()
      )

where the 'Bindable' constraint in particular then implies a further
handful of "~" constraints:

    class
      ( ASTLore lore,
        FParamInfo lore ~ DeclType,
        LParamInfo lore ~ Type,
        RetType lore ~ DeclExtType,
        BranchType lore ~ ExtType,
        SetType (LetDec lore)
      ) =>
      Bindable lore
      where
      ...

FParamInfo/LParamInfo/etc are type families.  Are such constraints
particularly slow?

-- 
\  Troels
/\ Henriksen

From carter.schonwald at gmail.com  Mon Feb 15 17:48:44 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 15 Feb 2021 12:48:44 -0500
Subject: [Haskell-cafe] Pattern matching desugaring regression? Re: Why does
 my module take so long to compile?
In-Reply-To: <87zh05458o.fsf@sigkill.dk>
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
 <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
 <87zh05458o.fsf@sigkill.dk>
Message-ID: <CAHYVw0wVSciXpp_1JidSF7+N0iqTjV97zwD_62zys56wfmnOSg@mail.gmail.com>

Ccing ghc devs since that’s a better forum perhaps
Crazy theory:

this is a regression due the the partial changes to pattern matching
coverage checking in 8.10 that finished / landed in ghc 9

Why:
Desugaring is when pattern/ case statement translation happens I think?
And the only obvious “big thing” is that you have some huge , albeit sane
for a compiler, pattern matching

I’d first check if the new ghc 9 release doesn’t have that regression in
build time that you experienced.  And if it does file a ticket.

I may be totally wrong, but that seems like a decent likelihood !


On Mon, Feb 15, 2021 at 12:20 PM Troels Henriksen <athas at sigkill.dk> wrote:

> Carter Schonwald <carter.schonwald at gmail.com> writes:
>
> > How big are your data types in the file In question? Do you ghc generics
> or
> > deriving or template Haskell? Could you share a link to the file in
> > question ?
>
> The file does not define any large data types itself, but it operates on
> some fairly large data types (an AST, it's a compiler).  But so do many
> other modules that work just fine.  It uses no generics, nontrivial
> deriving, or Template Haskell.  It's this file:
>
> https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKernels/DistributeNests.hs
>
> I also found a handful of other modules in my project that are
> significantly slower to compile in GHC 8.10, and seemingly also because
> of the desugarer, but none of them have any obvious smoking guns like
> generics or TH.
>
> The only commonality I can find is that the affected modules contain
> functions with a relatively large typeclass context.  I use
> ConstraintKinds to make them more concise, and I guess unfolded there
> may be 30-40 equality/class constraints in total.  Like this:
>
>     type DistLore lore =
>       ( Bindable lore,
>         HasSegOp lore,
>         BinderOps lore,
>         LetDec lore ~ Type,
>         ExpDec lore ~ (),
>         BodyDec lore ~ ()
>       )
>
> where the 'Bindable' constraint in particular then implies a further
> handful of "~" constraints:
>
>     class
>       ( ASTLore lore,
>         FParamInfo lore ~ DeclType,
>         LParamInfo lore ~ Type,
>         RetType lore ~ DeclExtType,
>         BranchType lore ~ ExtType,
>         SetType (LetDec lore)
>       ) =>
>       Bindable lore
>       where
>       ...
>
> FParamInfo/LParamInfo/etc are type families.  Are such constraints
> particularly slow?
>
> --
> \  Troels
> /\ Henriksen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210215/73ac6c3a/attachment.html>

From athas at sigkill.dk  Mon Feb 15 18:03:22 2021
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 15 Feb 2021 19:03:22 +0100
Subject: [Haskell-cafe] Pattern matching desugaring regression? Re: Why
 does my module take so long to compile?
In-Reply-To: <CAHYVw0wVSciXpp_1JidSF7+N0iqTjV97zwD_62zys56wfmnOSg@mail.gmail.com>
 (Carter Schonwald's message of "Mon, 15 Feb 2021 12:48:44 -0500")
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
 <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
 <87zh05458o.fsf@sigkill.dk>
 <CAHYVw0wVSciXpp_1JidSF7+N0iqTjV97zwD_62zys56wfmnOSg@mail.gmail.com>
Message-ID: <87tuqd439x.fsf@sigkill.dk>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> Ccing ghc devs since that’s a better forum perhaps
> Crazy theory:
>
> this is a regression due the the partial changes to pattern matching
> coverage checking in 8.10 that finished / landed in ghc 9
>
> Why:
> Desugaring is when pattern/ case statement translation happens I think?
> And the only obvious “big thing” is that you have some huge , albeit sane
> for a compiler, pattern matching
>
> I’d first check if the new ghc 9 release doesn’t have that regression in
> build time that you experienced.  And if it does file a ticket.
>
> I may be totally wrong, but that seems like a decent likelihood !

You may be right!  Another module that regressed is also mainly
characterised by large-but-not-insane case expressions:
https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs

I'll try to split these modules up a little bit (I should have done so a
while ago anyway) and maybe that will make the picture even clearer.

-- 
\  Troels
/\ Henriksen

From sgraf1337 at gmail.com  Mon Feb 15 18:13:00 2021
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Mon, 15 Feb 2021 19:13:00 +0100
Subject: [Haskell-cafe] Pattern matching desugaring regression? Re: Why
 does my module take so long to compile?
In-Reply-To: <87tuqd439x.fsf@sigkill.dk>
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
 <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
 <87zh05458o.fsf@sigkill.dk>
 <CAHYVw0wVSciXpp_1JidSF7+N0iqTjV97zwD_62zys56wfmnOSg@mail.gmail.com>
 <87tuqd439x.fsf@sigkill.dk>
Message-ID: <CAAS+=P9wAL0E6_mBdMZQUE-AJEUB=To=KnDWz+K0+bqBUVFCtA@mail.gmail.com>

Hi,

I'm not sure I see all the context of the conversation, but it is entirely
possible that code with many local constraints regresses the pattern-match
checker (which is accounted to Desugaring in the profile emitted by -v2),
I'm afraid. That simply has to do with the fact that we now actually care
about them, previously they were mostly discarded.

I'd be glad if you submitted a relatively isolated reproducer of what is
fast with 8.8 and slow with 8.10 (even better 9.0).
I hope that things have improved since we fixed
https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of 9.0 but
not of 8.10.

Cheers,
Sebastian

Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
athas at sigkill.dk>:

> Carter Schonwald <carter.schonwald at gmail.com> writes:
>
> > Ccing ghc devs since that’s a better forum perhaps
> > Crazy theory:
> >
> > this is a regression due the the partial changes to pattern matching
> > coverage checking in 8.10 that finished / landed in ghc 9
> >
> > Why:
> > Desugaring is when pattern/ case statement translation happens I think?
> > And the only obvious “big thing” is that you have some huge , albeit sane
> > for a compiler, pattern matching
> >
> > I’d first check if the new ghc 9 release doesn’t have that regression in
> > build time that you experienced.  And if it does file a ticket.
> >
> > I may be totally wrong, but that seems like a decent likelihood !
>
> You may be right!  Another module that regressed is also mainly
> characterised by large-but-not-insane case expressions:
>
> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
>
> I'll try to split these modules up a little bit (I should have done so a
> while ago anyway) and maybe that will make the picture even clearer.
>
> --
> \  Troels
> /\ Henriksen
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210215/526f19c6/attachment.html>

From athas at sigkill.dk  Mon Feb 15 19:10:06 2021
From: athas at sigkill.dk (Troels Henriksen)
Date: Mon, 15 Feb 2021 20:10:06 +0100
Subject: [Haskell-cafe] Pattern matching desugaring regression? Re: Why
 does my module take so long to compile?
In-Reply-To: <CAAS+=P9wAL0E6_mBdMZQUE-AJEUB=To=KnDWz+K0+bqBUVFCtA@mail.gmail.com>
 (Sebastian Graf's message of "Mon, 15 Feb 2021 19:13:00 +0100")
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
 <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
 <87zh05458o.fsf@sigkill.dk>
 <CAHYVw0wVSciXpp_1JidSF7+N0iqTjV97zwD_62zys56wfmnOSg@mail.gmail.com>
 <87tuqd439x.fsf@sigkill.dk>
 <CAAS+=P9wAL0E6_mBdMZQUE-AJEUB=To=KnDWz+K0+bqBUVFCtA@mail.gmail.com>
Message-ID: <87mtw5406p.fsf@sigkill.dk>

It is very likely that issue 17386 is the issue.  With

{-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
-Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}

my module(s) compile very quickly.  I'll wait and see if GHC 9 does
better before I try to create a smaller case (and now I at least have a
workaround).

Sebastian Graf <sgraf1337 at gmail.com> writes:

> Hi,
>
> I'm not sure I see all the context of the conversation, but it is entirely
> possible that code with many local constraints regresses the pattern-match
> checker (which is accounted to Desugaring in the profile emitted by -v2),
> I'm afraid. That simply has to do with the fact that we now actually care
> about them, previously they were mostly discarded.
>
> I'd be glad if you submitted a relatively isolated reproducer of what is
> fast with 8.8 and slow with 8.10 (even better 9.0).
> I hope that things have improved since we fixed
> https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of 9.0 but
> not of 8.10.
>
> Cheers,
> Sebastian
>
> Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
> athas at sigkill.dk>:
>
>> Carter Schonwald <carter.schonwald at gmail.com> writes:
>>
>> > Ccing ghc devs since that’s a better forum perhaps
>> > Crazy theory:
>> >
>> > this is a regression due the the partial changes to pattern matching
>> > coverage checking in 8.10 that finished / landed in ghc 9
>> >
>> > Why:
>> > Desugaring is when pattern/ case statement translation happens I think?
>> > And the only obvious “big thing” is that you have some huge , albeit sane
>> > for a compiler, pattern matching
>> >
>> > I’d first check if the new ghc 9 release doesn’t have that regression in
>> > build time that you experienced.  And if it does file a ticket.
>> >
>> > I may be totally wrong, but that seems like a decent likelihood !
>>
>> You may be right!  Another module that regressed is also mainly
>> characterised by large-but-not-insane case expressions:
>>
>> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
>>
>> I'll try to split these modules up a little bit (I should have done so a
>> while ago anyway) and maybe that will make the picture even clearer.
>>
>> --
>> \  Troels
>> /\ Henriksen
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>

-- 
\  Troels
/\ Henriksen

From carter.schonwald at gmail.com  Mon Feb 15 19:21:39 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 15 Feb 2021 14:21:39 -0500
Subject: [Haskell-cafe] Pattern matching desugaring regression? Re: Why
 does my module take so long to compile?
In-Reply-To: <87mtw5406p.fsf@sigkill.dk>
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
 <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
 <87zh05458o.fsf@sigkill.dk>
 <CAHYVw0wVSciXpp_1JidSF7+N0iqTjV97zwD_62zys56wfmnOSg@mail.gmail.com>
 <87tuqd439x.fsf@sigkill.dk>
 <CAAS+=P9wAL0E6_mBdMZQUE-AJEUB=To=KnDWz+K0+bqBUVFCtA@mail.gmail.com>
 <87mtw5406p.fsf@sigkill.dk>
Message-ID: <CAHYVw0wx5X5vTMeZC8cNQTDD5=fE4Ue_cOGmvzO76Xt0HNv9gw@mail.gmail.com>

Don’t forget ghc 9 is already out! :)

On Mon, Feb 15, 2021 at 2:10 PM Troels Henriksen <athas at sigkill.dk> wrote:

> It is very likely that issue 17386 is the issue.  With
>
> {-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
> -Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}
>
> my module(s) compile very quickly.  I'll wait and see if GHC 9 does
> better before I try to create a smaller case (and now I at least have a
> workaround).
>
> Sebastian Graf <sgraf1337 at gmail.com> writes:
>
> > Hi,
> >
> > I'm not sure I see all the context of the conversation, but it is
> entirely
> > possible that code with many local constraints regresses the
> pattern-match
> > checker (which is accounted to Desugaring in the profile emitted by -v2),
> > I'm afraid. That simply has to do with the fact that we now actually care
> > about them, previously they were mostly discarded.
> >
> > I'd be glad if you submitted a relatively isolated reproducer of what is
> > fast with 8.8 and slow with 8.10 (even better 9.0).
> > I hope that things have improved since we fixed
> > https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of 9.0
> but
> > not of 8.10.
> >
> > Cheers,
> > Sebastian
> >
> > Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
> > athas at sigkill.dk>:
> >
> >> Carter Schonwald <carter.schonwald at gmail.com> writes:
> >>
> >> > Ccing ghc devs since that’s a better forum perhaps
> >> > Crazy theory:
> >> >
> >> > this is a regression due the the partial changes to pattern matching
> >> > coverage checking in 8.10 that finished / landed in ghc 9
> >> >
> >> > Why:
> >> > Desugaring is when pattern/ case statement translation happens I
> think?
> >> > And the only obvious “big thing” is that you have some huge , albeit
> sane
> >> > for a compiler, pattern matching
> >> >
> >> > I’d first check if the new ghc 9 release doesn’t have that regression
> in
> >> > build time that you experienced.  And if it does file a ticket.
> >> >
> >> > I may be totally wrong, but that seems like a decent likelihood !
> >>
> >> You may be right!  Another module that regressed is also mainly
> >> characterised by large-but-not-insane case expressions:
> >>
> >>
> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
> >>
> >> I'll try to split these modules up a little bit (I should have done so a
> >> while ago anyway) and maybe that will make the picture even clearer.
> >>
> >> --
> >> \  Troels
> >> /\ Henriksen
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
>
> --
> \  Troels
> /\ Henriksen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210215/f6e5760b/attachment.html>

From allbery.b at gmail.com  Mon Feb 15 19:23:14 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 15 Feb 2021 14:23:14 -0500
Subject: [Haskell-cafe] Pattern matching desugaring regression? Re: Why
 does my module take so long to compile?
In-Reply-To: <CAHYVw0wx5X5vTMeZC8cNQTDD5=fE4Ue_cOGmvzO76Xt0HNv9gw@mail.gmail.com>
References: <87y2fp5pn7.fsf@sigkill.dk>
 <57fb4de7-d4c6-f08c-d226-18d1572d26b@henning-thielemann.de>
 <87pn115kmo.fsf@sigkill.dk>
 <CAHYVw0w5Hbi+Vn_R5=EundMyEfkjHxPKR5vE37O=GJS=DrjBMA@mail.gmail.com>
 <87zh05458o.fsf@sigkill.dk>
 <CAHYVw0wVSciXpp_1JidSF7+N0iqTjV97zwD_62zys56wfmnOSg@mail.gmail.com>
 <87tuqd439x.fsf@sigkill.dk>
 <CAAS+=P9wAL0E6_mBdMZQUE-AJEUB=To=KnDWz+K0+bqBUVFCtA@mail.gmail.com>
 <87mtw5406p.fsf@sigkill.dk>
 <CAHYVw0wx5X5vTMeZC8cNQTDD5=fE4Ue_cOGmvzO76Xt0HNv9gw@mail.gmail.com>
Message-ID: <CAKFCL4WNQcfOXKSBtDPtNjtjFWFEPo51UM==Q8iyFFEypMQ0=A@mail.gmail.com>

They already said something about waiting on dependencies to catch up with
ghc9, IIRC.

On Mon, Feb 15, 2021 at 2:22 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Don’t forget ghc 9 is already out! :)
>
> On Mon, Feb 15, 2021 at 2:10 PM Troels Henriksen <athas at sigkill.dk> wrote:
>
>> It is very likely that issue 17386 is the issue.  With
>>
>> {-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
>> -Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}
>>
>> my module(s) compile very quickly.  I'll wait and see if GHC 9 does
>> better before I try to create a smaller case (and now I at least have a
>> workaround).
>>
>> Sebastian Graf <sgraf1337 at gmail.com> writes:
>>
>> > Hi,
>> >
>> > I'm not sure I see all the context of the conversation, but it is
>> entirely
>> > possible that code with many local constraints regresses the
>> pattern-match
>> > checker (which is accounted to Desugaring in the profile emitted by
>> -v2),
>> > I'm afraid. That simply has to do with the fact that we now actually
>> care
>> > about them, previously they were mostly discarded.
>> >
>> > I'd be glad if you submitted a relatively isolated reproducer of what is
>> > fast with 8.8 and slow with 8.10 (even better 9.0).
>> > I hope that things have improved since we fixed
>> > https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of
>> 9.0 but
>> > not of 8.10.
>> >
>> > Cheers,
>> > Sebastian
>> >
>> > Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
>> > athas at sigkill.dk>:
>> >
>> >> Carter Schonwald <carter.schonwald at gmail.com> writes:
>> >>
>> >> > Ccing ghc devs since that’s a better forum perhaps
>> >> > Crazy theory:
>> >> >
>> >> > this is a regression due the the partial changes to pattern matching
>> >> > coverage checking in 8.10 that finished / landed in ghc 9
>> >> >
>> >> > Why:
>> >> > Desugaring is when pattern/ case statement translation happens I
>> think?
>> >> > And the only obvious “big thing” is that you have some huge , albeit
>> sane
>> >> > for a compiler, pattern matching
>> >> >
>> >> > I’d first check if the new ghc 9 release doesn’t have that
>> regression in
>> >> > build time that you experienced.  And if it does file a ticket.
>> >> >
>> >> > I may be totally wrong, but that seems like a decent likelihood !
>> >>
>> >> You may be right!  Another module that regressed is also mainly
>> >> characterised by large-but-not-insane case expressions:
>> >>
>> >>
>> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
>> >>
>> >> I'll try to split these modules up a little bit (I should have done so
>> a
>> >> while ago anyway) and maybe that will make the picture even clearer.
>> >>
>> >> --
>> >> \  Troels
>> >> /\ Henriksen
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>>
>> --
>> \  Troels
>> /\ Henriksen
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210215/a26a6b06/attachment.html>

From matteo at confscience.com  Mon Feb 15 20:00:41 2021
From: matteo at confscience.com (matteo at confscience.com)
Date: Mon, 15 Feb 2021 21:00:41 +0100
Subject: [Haskell-cafe] International Conference on Informatics Revolution
	for Smarter Healthcare (IRSH 2021) Prague
Message-ID: <004701d703d5$3d3e9d30$b7bbd790$@confscience.com>

Call for papers

************************************************* 

International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) 

Prague- Czech Republic, October 14-15, 2021

https://confscience.com/irsh/  

Submission deadline: April 1, 2021

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: April 1, 2021

- 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

- AR and VR applications  

- Patient billing

- Accounting systems

- Personnel and payroll

- Materials management

- Voice recognition systems

- Asset management solutions

- Disease management

- Feedback integration

- Clinical software

- Crowd-computing applications

- Future directions 

- Drone-based solutions 

- Software Defined Networks for healthcare

 

***************************************************************************

OUTSTANDING PAPERS:

Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. 

*************************************************************************** 

PAPER SUBMISSION: 

Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=irsh2021). 

All papers will be peer reviewed. 

Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page)

Length of Short papers: less than 12 pages 

For more information, please refer to the conference website: https://confscience.com/irsh/    

 

***************************************************************************

CONTACT 

For more information, please send an email to info-irsh at confscience.com  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210215/8dcbb740/attachment-0001.html>

From stefan.wehr at gmail.com  Wed Feb 17 07:29:02 2021
From: stefan.wehr at gmail.com (Stefan Wehr)
Date: Wed, 17 Feb 2021 08:29:02 +0100
Subject: [Haskell-cafe] Final Call for Participation: BOB 2021 (February 26,
	online)
Message-ID: <CAJAdMdGGpHNAjVZhCuf16Lh=ur6GR0NRTMKL1peY5dn1cwY_Wg@mail.gmail.com>

Subject: Final Call for Participation: BOB 2021 (February 26, online)

============================================================================
			       BOB 2021
			      Conference
	     “What happens if we simply use what’s best?”
		      February 26, 2021, online
		              (UTC+0100)
		       http://bobkonf.de/2021/
	   Program: http://bobkonf.de/2021/program.html
      Registration: http://bobkonf.de/2021/registration.html
============================================================================
				
BOB conference is a place for developers, architects and decision-makers
to explore technologies beyond the mainstream in software development,
and to find the best tools available to software developers today. Our
goal is for all participants of BOB to return home with new insights
that enable them to improve their own software development
experience.

The program features 14 talks and 8 tutorials on current topics:
http://bobkonf.de/2021/program.html

The subject range includes functional programming, logic programming,
revision control, formal methods, mindfulness, event sourcing,
front-end development, and more.

Jeremy Gibbons will give the keynote talk.

BOB 2021 will take place online.  We are working towards fostering
lively exchange of exciting ideas and enable meaningful social
interactions.

Registration is open online:
http://bobkonf.de/2021/registration.html

Registration is €30 for a regular ticket, €15 for a student ticket.
(If you need financial aid, let us know.)  We intend to make this the
most diverse, colorful, fun BOB ever!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210217/214d5f85/attachment.html>

From coot at coot.me  Wed Feb 17 10:41:59 2021
From: coot at coot.me (coot at coot.me)
Date: Wed, 17 Feb 2021 10:41:59 +0000
Subject: [Haskell-cafe] Blog post about masking asynchronous exceptions
Message-ID: <X_sIUym2xwmiprHjWRZw9vSdKacWcr0u_WnmPvSxgOZGvceXCF4XgEkuhbIClk_5HHSO8jz8MiCICWE12pxCRC6kUEUbGMXgq42Y5sREihU=@coot.me>

Hello Haskell-Caffee,

I wrote a blog post about masking asynchronous exceptions and interruptible operations: https://coot.me/posts/mask.html

Best regards,
Marcin Szamotulski

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210217/5e88ac99/attachment.sig>

From J.Hage at uu.nl  Wed Feb 17 12:26:49 2021
From: J.Hage at uu.nl (Hage, J. (Jurriaan))
Date: Wed, 17 Feb 2021 12:26:49 +0000
Subject: [Haskell-cafe] First Call for Papers for the Haskell Symposium 2021
Message-ID: <2FCB042C-3B0D-4801-A1DD-051F695451A6@uu.nl>

Dear all,

This is the first call for papers for the upcoming Haskell Symposium.
Please forward to anyone that you believe might be interested.

Apologies for receiving multiple copies of this announcement.

Best regards,
Jurriaan Hage
Chair

PS. Note that the website is not up yet (but will be soon). 

================================================================================
 ACM SIGPLAN                                              CALL FOR SUBMISSIONS

                          Haskell Symposium 2021

                              ** virtual **
                       Thu 26 -- Fri 27 August, 2021

              http://www.haskell.org/haskell-symposium/2021/

================================================================================

The ACM SIGPLAN Haskell Symposium 2021 will be co-located with the 2021
International Conference on Functional Programming (ICFP). Due to COVID-19
it will take place **virtually** this year.

Like last year, we will be using a lightweight double-blind reviewing process.
See further information below. Different from last year is that
we offer a new submission category: the tutorial. Details can be found below.

The Haskell Symposium presents original research on Haskell,
discusses practical experience and future development of the language, and
promotes other forms of declarative programming.

Topics of interest include:

  * Language design, with a focus on possible extensions and modifications of
    Haskell as well as critical discussions of the status quo;

  * Theory, such as formal semantics of the present language or future
    extensions, type systems, effects, metatheory, and foundations for
    program analysis and transformation;

  * Implementations, including program analysis and transformation,
    static and dynamic compilation for sequential, parallel, and distributed
    architectures, memory management, as well as foreign function and
    component interfaces;

  * Libraries, that demonstrate new ideas or techniques for functional
    programming in Haskell;

  * Tools, such as profilers, tracers, debuggers, preprocessors,
    and testing tools;

  * Applications, to scientific and symbolic computing, databases, multimedia,
    telecommunication, the web, and so forth;

  * Functional Pearls, being elegant and instructive programming examples;

  * Experience Reports, to document general practice and experience in
    education, industry, or other contexts;
    
  * Tutorials, to document how to use a particular language feature,
    programming technique, tool or library within the Haskell ecosystem;

  * System Demonstrations, based on running software rather than novel
    research results.

Regular papers should explain their research contributions in both general and
technical terms, identifying what has been accomplished, explaining why it is
significant, and relating it to previous work, and to other languages where
appropriate.

Experience reports and functional pearls need not necessarily report original
academic research results. For example, they may instead report reusable
programming idioms, elegant ways to approach a problem, or practical experience
that will be useful to other users, implementers, or researchers. The key
criterion for such a paper is that it makes a contribution from which other
Haskellers can benefit. It is not enough simply to describe a standard solution
to a standard programming problem, or report on experience where you used
Haskell in the standard way and achieved the result you were expecting.

A new submission category for this year's Haskell Symposium is the tutorial.
Like with the experience report and the functional pearl, the key criterion for
such a paper is that it makes a contribution from which other Haskellers can
benefit. What distinguishes a tutorial is that its
focus is on explaining an aspect of the Haskell language and/or ecosystem in a
way that is generally useful to a Haskell audience. Tutorials for many
such topics can be found online; the distinction here is that by writing it up
for formal review it will be vetted by experts and formally published.

System demonstrations should summarize the system capabilities that would be
demonstrated. The proposals will be judged on whether the ensuing session is
likely to be important and interesting to the Haskell community at large,
whether on grounds academic or industrial, theoretical or practical, technical,
social or artistic. Please contact the program chair with any questions about
the relevance of a proposal.

If your contribution is not a research paper, please mark the title of your
experience report, functional pearl, tutorial or system demonstration as such,
by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration).

Submission Details
==================

Early and Regular Track
-----------------------

The Haskell Symposium uses a two-track submission process so that some papers
can gain early feedback. Strong papers submitted to the early track are
accepted outright, and the others will be given their reviews and invited to
resubmit to the regular track. Papers accepted via the early and regular
tracks are considered of equal value and will not be distinguished in the
proceedings. Although all papers may be submitted to the early track, authors
of functional pearls and experience reports are particularly encouraged to use
this mechanism. The success of these papers depends heavily on the way they
are presented, and submitting early will give the program committee a chance
to provide feedback and help draw out the key ideas.

Formatting
----------

Submitted papers should be in portable document format (PDF), formatted using
the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with
the `sigplan` sub-format for ACM proceedings. For details, see:

  http://www.sigplan.org/Resources/Author/#acmart-format

It is recommended to use the `review` option when submitting a paper; 
this option enables line numbers for easy reference in reviews.

Functional pearls, experience reports, tutorials and demo proposals should be
labelled clearly as such.

Lightweight Double-blind Reviewing
----------------------------------

Haskell Symposium 2021 will use a lightweight double-blind reviewing process.
To facilitate this, submitted papers must adhere to two rules:

 1. Author names and institutions must be omitted, and
 2. References to authors' own related work should be in the third person
    (e.g., not "We build on our previous work" but rather "We build on the work of ").

The purpose of this process is to help the reviewers come to an initial
judgment about the paper without bias, not to make it impossible for them to
discover the authors if they were to try. Nothing should be done in the name
of anonymity that weakens the submission or makes the job of reviewing the
paper more difficult (e.g., important background references should not be
omitted or anonymized). In addition, authors should feel free to disseminate
their ideas or draft versions of their paper as they normally would. For
instance, authors may post drafts of their papers on the web or give talks on
their research ideas.

A reviewer will learn the identity of the author(s) of a paper after a review
is submitted.

Page Limits
-----------

The length of submissions should not exceed the following limits:

Regular paper:      12 pages
Functional pearl:   12 pages
Tutorial:           12 pages
Experience report:   6 pages
Demo proposal:       2 pages

There is no requirement that all pages are used. For example, a
functional pearl may be much shorter than 12 pages. In all cases,
the list of references is not counted against these page limits.

Deadlines
---------

Early track:
  Submission deadline:    19 March 2021     (Fri)
  Notification:           23 April 2021     (Fri)

Regular track and demos:
  Submission deadline:    21 May  2021      (Fri)
  Notification:           23 June 2021      (Wed)


Deadlines are valid anywhere on Earth.

Submission
----------

Submissions must adhere to SIGPLAN's republication policy
(http://sigplan.org/Resources/Policies/Republication/), and authors
should be aware of ACM's policies on plagiarism
(https://www.acm.org/publications/policies/plagiarism).
Program Committee members are allowed to submit papers, but their papers will
be held to a higher standard.

The paper submission deadline and length limitations are firm.
There will be no extensions, and papers violating the length
limitations will be summarily rejected.

Papers should be submitted through HotCRP at:

  https://haskell21.hotcrp.com/

Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.

Supplementary material: Authors have the option to attach supplementary
material to a submission, on the understanding that reviewers may choose not
to look at it. This supplementary material should not be submitted as part of
the main document; instead, it should be uploaded as a separate PDF document
or tarball. Supplementary material should be uploaded at submission time, not by
providing a URL in the paper that points to an external repository.
Authors can distinguish between anonymized and non-anonymized supplementary
material. Anonymized supplementary material will be visible to reviewers
immediately; non-anonymized supplementary material will be revealed to
reviewers only after they have submitted their review of the paper and learned
the identity of the author(s).

Resubmitted Papers: authors who submit a revised version of a paper that has
previously been rejected by another conference have the option to attach an
annotated copy of the reviews of their previous submission(s), explaining how
they have addressed these previous reviews in the present submission. If a
reviewer identifies him/herself as a reviewer of this previous submission and
wishes to see how his/her comments have been addressed, the conference chair
will communicate to this reviewer the annotated copy of his/her previous
review. Otherwise, no reviewer will read the annotated copies of the previous
reviews.

Proceedings
===========

Accepted papers will be included in the ACM Digital Library. Their authors 
will be required to choose one of the following options:
- Author retains copyright of the work and grants ACM a non-exclusive
  permission-to-publish license (and, optionally, licenses the work with a
  Creative Commons license); 
- Author retains copyright of the work and grants ACM an exclusive
  permission-to-publish license; 
- Author transfers copyright of the work to ACM. 
For more information, please see ACM Copyright Policy
(http://www.acm.org/publications/policies/copyright-policy) and ACM Author
Rights (http://authors.acm.org/main.html).

Accepted proposals for system demonstrations will be posted on the
symposium website but not formally published in the proceedings.

Publication date: The official publication date of accepted papers is
the date the proceedings are made available in the ACM Digital
Library. This date may be up to two weeks prior to the first day of the
conference. The official publication date affects the deadline for any
patent filings related to published work.

Artifacts
=========

Authors of accepted papers are encouraged to make auxiliary material (artifacts
like source code, test data, etc.) available with their paper. They can opt to
have these artifacts published alongside their paper in the ACM Digital Library
(copyright of artifacts remains with the authors).

If an accepted paper's artifacts are made permanently available for retrieval in a
publicly accessible archival repository like the ACM Digital Library, that paper
qualifies for an Artifacts Available badge
(https://www.acm.org/publications/policies/artifact-review-badging#available).
Applications for such a badge can be made after paper acceptance and will be
reviewed by the PC chair.

Program Committee
=================

Edwin Brady               University of St Andrews
Koen Claessen             Chalmers University of Technology 
Dominique Devriese        Vrije Universiteit Brussel
Andy Gill                 University of Kansas
Jurriaan Hage (chair)     Universiteit Utrecht
Zhenjiang Hu              Peking University
Ranjit Jhala              University of California
Patricia Johann           Appalachian State University
Yukiyoshi Kameyama        University of Tsukuba
George Karachalias        Tweag
Ralf Laemmel              University of Koblenz-Landau
Daan Leijen               Microsoft Research
Ben Lippmeier             Ghost Locomotion
Neil Mitchell             Facebook
Alberto Pardo             Universidad de la Republica, Uruguay
Matt Roberts              Macquarie University
Janis Voigtlaender        University of Duisburg-Essen
Nicolas Wu                Imperial College London

If you have questions, please contact the chair at: j.hage at uu.nl

================================================================================




From ben.franksen at online.de  Wed Feb 17 20:13:16 2021
From: ben.franksen at online.de (Ben Franksen)
Date: Wed, 17 Feb 2021 21:13:16 +0100
Subject: [Haskell-cafe] Blog post about masking asynchronous exceptions
In-Reply-To: <X_sIUym2xwmiprHjWRZw9vSdKacWcr0u_WnmPvSxgOZGvceXCF4XgEkuhbIClk_5HHSO8jz8MiCICWE12pxCRC6kUEUbGMXgq42Y5sREihU=@coot.me>
References: <X_sIUym2xwmiprHjWRZw9vSdKacWcr0u_WnmPvSxgOZGvceXCF4XgEkuhbIClk_5HHSO8jz8MiCICWE12pxCRC6kUEUbGMXgq42Y5sREihU=@coot.me>
Message-ID: <s0jtcs$ll8$1@ciao.gmane.io>

Am 17.02.21 um 11:41 schrieb coot at coot.me:
> Hello Haskell-Caffee,
> 
> I wrote a blog post about masking asynchronous exceptions and
> interruptible operations: https://coot.me/posts/mask.html

Interesting blog! You should list on Planet Haskell
(https://planet.haskell.org/).

Chers
Ben


From jakob.bruenker at gmail.com  Thu Feb 18 04:52:19 2021
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Thu, 18 Feb 2021 05:52:19 +0100
Subject: [Haskell-cafe] How to deal with type family applications in type
	equalities?
Message-ID: <CAJjQ6oNU2pRXBa+iH+L4kCDswmzA6GHzEaTBWj_jBiPnzd5ymg@mail.gmail.com>

Imagine you want to have a type level function that calculates the
element-wise OR on two bitstrings, encoded as length-indexed vectors filled
with Bools (this is a simplification of something I need for a project).
The vectors should be "aligned to the right" as it were, such that the new
right-most value is True if the right-most value of the first vector OR the
right-most value of the second vector was True.

Example (replacing True and False with 1 and 0 for readability):
ElementwiseOr [1,0,1,1] [0,1,1,0,0,0,0,1]
= [0,1,1,0,1,0,1,1]

Its type would be something like
ElementwiseOr :: Vec n Bool -> Vec m Bool -> Vec (Max n m) Bool

I have written the following code:

---------------------------------------------------------------------------
{-# LANGUAGE TypeFamilies, GADTs, DataKinds, StandaloneKindSignatures,
             PolyKinds, TypeOperators, RankNTypes, TypeApplications,
             UndecidableInstances #-}

import Data.Kind
import Data.Type.Equality

data Nat = Z | S Nat

infixr 5 :<

type Vec :: Nat -> Type -> Type
data Vec n a where
  Nil :: Vec Z a
  (:<) :: a -> Vec n a -> Vec (S n) a

type Cong :: forall f -> a :~: b -> f a :~: f b
type family Cong f p where
  Cong f Refl = Refl

type Max :: Nat -> Nat -> Nat
type family Max n m where
  Max Z m = m
  Max n Z = n
  Max (S n) (S m) = S (Max n m)

-- The reason for this slightly convoluted Ordering type is that it seems
-- to make the "right-alignment" easier.
type NatOrdering :: Ordering -> Nat -> Nat -> Type
data NatOrdering o n m where
  NOLTE :: NatOrdering EQ n m -> NatOrdering LT n (S m)
  NOLTS :: NatOrdering LT n m -> NatOrdering LT n (S m)
  NOEQZ :: NatOrdering EQ Z Z
  NOEQS :: NatOrdering EQ n m -> NatOrdering EQ (S n) (S m)
  NOGTE :: NatOrdering EQ n m -> NatOrdering GT (S n) m
  NOGTS :: NatOrdering GT n m -> NatOrdering GT (S n) m

type MaxSIsSMaxEQ
  :: forall n m . NatOrdering EQ n m -> Max n (S m) :~: S (Max n m)
type family MaxSIsSMaxEQ o where
  MaxSIsSMaxEQ NOEQZ = Refl
  MaxSIsSMaxEQ (NOEQS o) = Cong S (MaxSIsSMaxEQ o)

type TransportVec :: n :~: m -> Vec n a -> Vec m a
type family TransportVec p v where
  TransportVec Refl v = v

type ElementwiseOr
  :: NatOrdering o n m -> Vec n Bool -> Vec m Bool -> Vec (Max n m) Bool
type family ElementwiseOr o u v where
  ElementwiseOr (NOLTE o) u (s :< v) =
    TransportVec (MaxSIsSMaxEQ o) (s :< ElementwiseOr o u v) -- XXX
  -- other equations ommitted
---------------------------------------------------------------------------

To me, the equation at the end marked with XXX seems like it should work.
However, it produces the following error:

    • Couldn't match kind: Max n ('S m)
                     with: 'S (Max n m)
      Expected kind ‘'S (Max n m) :~: 'S (Max n m)’,
        but ‘MaxSIsSMaxEQ o’ has kind ‘Max n ('S m) :~: 'S (Max n m)’
    • In the first argument of ‘TransportVec’, namely
        ‘(MaxSIsSMaxEQ o)’

So it expects something of kind `S (Max n m) :~: S (Max n m)` - it seems
like Refl fits that bill, but that doesn't work either, because replacing
(MaxSIsSMaxEQ o) with Refl means that TransportVec returns a type of the
wrong kind, producing a very similar error.

I suspect the reason this doesn't work is because type equality isn't
equipped to properly handle type family applications. I could potentially
work around this if I defined Max as

data Max n m r where
  MaxZZ :: Max Z Z Z
  MaxSZ :: Max (S n) Z (S n)
  MaxZS :: Max Z (S m) (S m)
  MaxSS :: Max n m r -> Max (S n) (S m) (S r)

However, dealing with a proof object like this is a lot less convenient
than just being able to use a type family for most purposes, so I'd like to
avoid this if possible.

Is there a way to make this work while sticking with type families?

Thanks

Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/cdaf7151/attachment.html>

From jakob.bruenker at gmail.com  Thu Feb 18 05:36:26 2021
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Thu, 18 Feb 2021 06:36:26 +0100
Subject: [Haskell-cafe] How to deal with type family applications in
	type equalities?
In-Reply-To: <CAJjQ6oNU2pRXBa+iH+L4kCDswmzA6GHzEaTBWj_jBiPnzd5ymg@mail.gmail.com>
References: <CAJjQ6oNU2pRXBa+iH+L4kCDswmzA6GHzEaTBWj_jBiPnzd5ymg@mail.gmail.com>
Message-ID: <CAJjQ6oMhh__+MtOL7n+o=Q_J8hanPcgHSC4tz2BGkdw7tfRyWA@mail.gmail.com>

*sigh* sorry, disregard part of this, I missed something obvious. I just
need to replace `MaxSIsSMaxEQ o` with `Sym (MaxSIsSMaxEQ o)`, and then it
works.

However, I'm still somewhat confused - the reason why I thought the type
family application was the problem to begin with is that I tried this:

  type Foo :: Max n (S m) :~: S (Max n m) -> ()
  type family Foo p where
    Foo Refl = '()

and it results in the error

    • Couldn't match kind: Max n ('S m)
                     with: 'S (Max n m)
      Expected kind ‘Max n ('S m) :~: 'S (Max n m)’,
        but ‘Refl’ has kind ‘Max n ('S m) :~: Max n ('S m)’
    • In the first argument of ‘Foo’, namely ‘Refl’
      In the type family declaration for ‘Foo’

What is the reason I can't pattern match on Refl here? I would expect it to
simply being the constraint `Max n (S m) ~ S (Max n m)` into scope.

Thanks,
Jakob

On Thu, Feb 18, 2021 at 5:52 AM Jakob Brünker <jakob.bruenker at gmail.com>
wrote:

> Imagine you want to have a type level function that calculates the
> element-wise OR on two bitstrings, encoded as length-indexed vectors filled
> with Bools (this is a simplification of something I need for a project).
> The vectors should be "aligned to the right" as it were, such that the new
> right-most value is True if the right-most value of the first vector OR the
> right-most value of the second vector was True.
>
> Example (replacing True and False with 1 and 0 for readability):
> ElementwiseOr [1,0,1,1] [0,1,1,0,0,0,0,1]
> = [0,1,1,0,1,0,1,1]
>
> Its type would be something like
> ElementwiseOr :: Vec n Bool -> Vec m Bool -> Vec (Max n m) Bool
>
> I have written the following code:
>
> ---------------------------------------------------------------------------
> {-# LANGUAGE TypeFamilies, GADTs, DataKinds, StandaloneKindSignatures,
>              PolyKinds, TypeOperators, RankNTypes, TypeApplications,
>              UndecidableInstances #-}
>
> import Data.Kind
> import Data.Type.Equality
>
> data Nat = Z | S Nat
>
> infixr 5 :<
>
> type Vec :: Nat -> Type -> Type
> data Vec n a where
>   Nil :: Vec Z a
>   (:<) :: a -> Vec n a -> Vec (S n) a
>
> type Cong :: forall f -> a :~: b -> f a :~: f b
> type family Cong f p where
>   Cong f Refl = Refl
>
> type Max :: Nat -> Nat -> Nat
> type family Max n m where
>   Max Z m = m
>   Max n Z = n
>   Max (S n) (S m) = S (Max n m)
>
> -- The reason for this slightly convoluted Ordering type is that it seems
> -- to make the "right-alignment" easier.
> type NatOrdering :: Ordering -> Nat -> Nat -> Type
> data NatOrdering o n m where
>   NOLTE :: NatOrdering EQ n m -> NatOrdering LT n (S m)
>   NOLTS :: NatOrdering LT n m -> NatOrdering LT n (S m)
>   NOEQZ :: NatOrdering EQ Z Z
>   NOEQS :: NatOrdering EQ n m -> NatOrdering EQ (S n) (S m)
>   NOGTE :: NatOrdering EQ n m -> NatOrdering GT (S n) m
>   NOGTS :: NatOrdering GT n m -> NatOrdering GT (S n) m
>
> type MaxSIsSMaxEQ
>   :: forall n m . NatOrdering EQ n m -> Max n (S m) :~: S (Max n m)
> type family MaxSIsSMaxEQ o where
>   MaxSIsSMaxEQ NOEQZ = Refl
>   MaxSIsSMaxEQ (NOEQS o) = Cong S (MaxSIsSMaxEQ o)
>
> type TransportVec :: n :~: m -> Vec n a -> Vec m a
> type family TransportVec p v where
>   TransportVec Refl v = v
>
> type ElementwiseOr
>   :: NatOrdering o n m -> Vec n Bool -> Vec m Bool -> Vec (Max n m) Bool
> type family ElementwiseOr o u v where
>   ElementwiseOr (NOLTE o) u (s :< v) =
>     TransportVec (MaxSIsSMaxEQ o) (s :< ElementwiseOr o u v) -- XXX
>   -- other equations ommitted
> ---------------------------------------------------------------------------
>
> To me, the equation at the end marked with XXX seems like it should work.
> However, it produces the following error:
>
>     • Couldn't match kind: Max n ('S m)
>                      with: 'S (Max n m)
>       Expected kind ‘'S (Max n m) :~: 'S (Max n m)’,
>         but ‘MaxSIsSMaxEQ o’ has kind ‘Max n ('S m) :~: 'S (Max n m)’
>     • In the first argument of ‘TransportVec’, namely
>         ‘(MaxSIsSMaxEQ o)’
>
> So it expects something of kind `S (Max n m) :~: S (Max n m)` - it seems
> like Refl fits that bill, but that doesn't work either, because replacing
> (MaxSIsSMaxEQ o) with Refl means that TransportVec returns a type of the
> wrong kind, producing a very similar error.
>
> I suspect the reason this doesn't work is because type equality isn't
> equipped to properly handle type family applications. I could potentially
> work around this if I defined Max as
>
> data Max n m r where
>   MaxZZ :: Max Z Z Z
>   MaxSZ :: Max (S n) Z (S n)
>   MaxZS :: Max Z (S m) (S m)
>   MaxSS :: Max n m r -> Max (S n) (S m) (S r)
>
> However, dealing with a proof object like this is a lot less convenient
> than just being able to use a type family for most purposes, so I'd like to
> avoid this if possible.
>
> Is there a way to make this work while sticking with type families?
>
> Thanks
>
> Jakob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/67592b24/attachment.html>

From coot at coot.me  Thu Feb 18 08:15:31 2021
From: coot at coot.me (coot at coot.me)
Date: Thu, 18 Feb 2021 08:15:31 +0000
Subject: [Haskell-cafe] Blog post about masking asynchronous exceptions
In-Reply-To: <s0jtcs$ll8$1@ciao.gmane.io>
References: <X_sIUym2xwmiprHjWRZw9vSdKacWcr0u_WnmPvSxgOZGvceXCF4XgEkuhbIClk_5HHSO8jz8MiCICWE12pxCRC6kUEUbGMXgq42Y5sREihU=@coot.me>
 <s0jtcs$ll8$1@ciao.gmane.io>
Message-ID: <zP3WPHAZ4XCyV_4s4VOakMm3BPzoQnatjtCy04lIvbAiMJJjxReE9wLEGfbVLd0Z5z5qlzMUlSzEbG3Z6zJ7n7qfJ-peSsc5604TY1v2iUY=@coot.me>

Thanks for the idea, I'll look into it.

Regards,
Marcin

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, February 17th, 2021 at 21:13, Ben Franksen <ben.franksen at online.de> wrote:

> Am 17.02.21 um 11:41 schrieb coot at coot.me:
> 

> > Hello Haskell-Caffee,
> > 

> > I wrote a blog post about masking asynchronous exceptions and
> > 

> > interruptible operations: https://coot.me/posts/mask.html
> 

> Interesting blog! You should list on Planet Haskell
> 

> (https://planet.haskell.org/).
> 

> Chers
> 

> Ben
> 

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/c80e4788/attachment.sig>

From 47dragonfyre at gmail.com  Thu Feb 18 08:22:52 2021
From: 47dragonfyre at gmail.com (A. Mc.)
Date: Thu, 18 Feb 2021 00:22:52 -0800
Subject: [Haskell-cafe] Global Package Install
Message-ID: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>

Hello,

I am trying to add the package System.Random to be able to run it the same
way Data.List or Data.Char, et cetera does in ghci and in doing a ghc
command line build.  I've tried using $ stack ghci --package random which I
have to run every single time I want to load a module that imports anything
from System.Random and I've already tried $ cabal install --lib random
which only works with cabal, and I've used the command $ stack install
random, which says 'cache populated' but if a restart and load a dependent
module, still is not working for me.  I've also tried to update the .yaml
file by putting System.Random into the brackets is the sr directory, but
this I'm guessing isn't what you're supposed to do as it doesn't work
either. I'm using Cygwin on a Windows 10 operating system.  Your assistance
in this matter would be greatly appreciated.

Thank you for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/93220873/attachment.html>

From hecate at glitchbra.in  Thu Feb 18 08:40:11 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Thu, 18 Feb 2021 09:40:11 +0100
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
Message-ID: <95c43da9-63fb-0606-911b-053718670e7a@glitchbra.in>

Hi A.

In Stack, the `install` sub-command is an alias to `build --copy-bins`, 
as per the documentation[0]. If you install libraries globally, you may 
hit a point where there is a dependency conflict. ;)
My overall advice is to create a project and add the dependencies with 
which you play.

Cheers,
Hécate

[0]: https://docs.haskellstack.org/en/stable/GUIDE/#the-build-synonyms

On 18/02/2021 09:22, A. Mc. wrote:
> Hello,
>
> I am trying to add the package System.Random to be able to run it the 
> same way Data.List or Data.Char, et cetera does in ghci and in doing a 
> ghc command line build.  I've tried using $ stack ghci --package 
> random which I have to run every single time I want to load a module 
> that imports anything from System.Random and I've already tried $ 
> cabal install --lib random which only works with cabal, and I've used 
> the command $ stack install random, which says 'cache populated' but 
> if a restart and load a dependent module, still is not working for 
> me.  I've also tried to update the .yaml file by putting System.Random 
> into the brackets is the sr directory, but this I'm guessing isn't 
> what you're supposed to do as it doesn't work either. I'm using Cygwin 
> on a Windows 10 operating system.  Your assistance in this matter 
> would be greatly appreciated.
>
> Thank you for your time.
>
> _______________________________________________
> 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.

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Uniaika
WWW: https://glitchbra.in
RUN: BSD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/529da380/attachment.html>

From lemming at henning-thielemann.de  Thu Feb 18 09:42:43 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 18 Feb 2021 10:42:43 +0100 (CET)
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
Message-ID: <67db31b0-bfa7-4272-a782-9654f6ed9bd4@henning-thielemann.de>


On Thu, 18 Feb 2021, A. Mc. wrote:

> I am trying to add the package System.Random to be able to run it the 
> same way Data.List or Data.Char, et cetera does in ghci and in doing a 
> ghc command line build.

Do you want to use it from plain GHCi or from 'stack ghci'?

Plain GHCi accesses the packages that are listed by

$ ghc-pkg list

If you want to install and add a package to this list, you can run

$ cabal v1-install random

From lysxia at gmail.com  Thu Feb 18 14:27:02 2021
From: lysxia at gmail.com (Li-yao Xia)
Date: Thu, 18 Feb 2021 09:27:02 -0500
Subject: [Haskell-cafe] How to deal with type family applications in
 type equalities?
In-Reply-To: <CAJjQ6oMhh__+MtOL7n+o=Q_J8hanPcgHSC4tz2BGkdw7tfRyWA@mail.gmail.com>
References: <CAJjQ6oNU2pRXBa+iH+L4kCDswmzA6GHzEaTBWj_jBiPnzd5ymg@mail.gmail.com>
 <CAJjQ6oMhh__+MtOL7n+o=Q_J8hanPcgHSC4tz2BGkdw7tfRyWA@mail.gmail.com>
Message-ID: <b24727c4-7ed0-89a2-0f3c-34825073fa5f@gmail.com>

Hi Jakob,

For some reason the mental model that "pattern-matching brings 
constraints into scope" does not apply to type families (I think that's 
because "constraints" aren't really a thing at that level). Without such 
a feature, you can only pattern-match on preceding variables to make 
patterns type-check beforehand. In your example the only other variables 
are n and m so you have to split those.

type family Foo n m (p :: Max n (S m) :~: S (Max n m)) :: () where
   Foo O O Refl = '()
   Foo O (S m) Refl = '()
   Foo (S n) m p = '()  -- nontrival because of recursion in the type of p

Under those draconian constraints, it is convenient to first define 
general eliminators for various constructs such as (:~:):

-- type-level equivalent of Data.Type.Equality.castWith
type family Rewrite (p :: a :~: b) (x :: f a) :: f b where
   Rewrite Refl x = x

then you can apply such eliminators in situations where pattern-matching 
is actually not feasible or practical:

type Foo :: Max n (S m) :~: S (Max n m) -> f (Max n (S m)) -> f (S (Max 
n m))
type family Foo (p :: Max n (S m) :~: S (Max n m)) (x :: f (Max n (S 
m))) :: f (S (Max n m)) where
   Foo p x = Rew p x
   -- Good luck doing that by pattern-matching on n and m...

Note that Rewrite looks like what you'd write at the term level, but it 
is actually best thought of as working backwards: first, pattern-match 
on a and b (doing an equality test) and then, if they are equal, 
pattern-match on Refl (at which point this is really redundant). This 
means that Rewrite is *a priori* partial because it does not handle the 
case where a and b are distinct; we only know otherwise because there is 
no Refl in that case. In contrast, the function castWith uses a 
primitive notion of pattern-matching on GADTs, you split (p :: a :~: b) 
and there is only once case by definition of (:~:) (before knowing 
anything about a and b), where you get handed the underlying equality 
constraint.

Cheers,
Li-yao

On 2/18/2021 12:36 AM, Jakob Brünker wrote:
> *sigh* sorry, disregard part of this, I missed something obvious. I just 
> need to replace `MaxSIsSMaxEQ o` with `Sym (MaxSIsSMaxEQ o)`, and then 
> it works.
> 
> However, I'm still somewhat confused - the reason why I thought the type 
> family application was the problem to begin with is that I tried this:
> 
>    type Foo :: Max n (S m) :~: S (Max n m) -> ()
>    type family Foo p where
>      Foo Refl = '()
> 
> and it results in the error
> 
>      • Couldn't match kind: Max n ('S m)
>                       with: 'S (Max n m)
>        Expected kind ‘Max n ('S m) :~: 'S (Max n m)’,
>          but ‘Refl’ has kind ‘Max n ('S m) :~: Max n ('S m)’
>      • In the first argument of ‘Foo’, namely ‘Refl’
>        In the type family declaration for ‘Foo’
> 
> What is the reason I can't pattern match on Refl here? I would expect it 
> to simply being the constraint `Max n (S m) ~ S (Max n m)` into scope.
> 
> Thanks,
> Jakob
> 
> On Thu, Feb 18, 2021 at 5:52 AM Jakob Brünker <jakob.bruenker at gmail.com 
> <mailto:jakob.bruenker at gmail.com>> wrote:
> 
>     Imagine you want to have a type level function that calculates the
>     element-wise OR on two bitstrings, encoded as length-indexed vectors
>     filled with Bools (this is a simplification of something I need for
>     a project). The vectors should be "aligned to the right" as it were,
>     such that the new right-most value is True if the right-most value
>     of the first vector OR the right-most value of the second vector was
>     True.
> 
>     Example (replacing True and False with 1 and 0 for readability):
>     ElementwiseOr [1,0,1,1] [0,1,1,0,0,0,0,1]
>     = [0,1,1,0,1,0,1,1]
> 
>     Its type would be something like
>     ElementwiseOr :: Vec n Bool -> Vec m Bool -> Vec (Max n m) Bool
> 
>     I have written the following code:
> 
>     ---------------------------------------------------------------------------
>     {-# LANGUAGE TypeFamilies, GADTs, DataKinds, StandaloneKindSignatures,
>                   PolyKinds, TypeOperators, RankNTypes, TypeApplications,
>                   UndecidableInstances #-}
> 
>     import Data.Kind
>     import Data.Type.Equality
> 
>     data Nat = Z | S Nat
> 
>     infixr 5 :<
> 
>     type Vec :: Nat -> Type -> Type
>     data Vec n a where
>        Nil :: Vec Z a
>        (:<) :: a -> Vec n a -> Vec (S n) a
> 
>     type Cong :: forall f -> a :~: b -> f a :~: f b
>     type family Cong f p where
>        Cong f Refl = Refl
> 
>     type Max :: Nat -> Nat -> Nat
>     type family Max n m where
>        Max Z m = m
>        Max n Z = n
>        Max (S n) (S m) = S (Max n m)
> 
>     -- The reason for this slightly convoluted Ordering type is that it
>     seems
>     -- to make the "right-alignment" easier.
>     type NatOrdering :: Ordering -> Nat -> Nat -> Type
>     data NatOrdering o n m where
>        NOLTE :: NatOrdering EQ n m -> NatOrdering LT n (S m)
>        NOLTS :: NatOrdering LT n m -> NatOrdering LT n (S m)
>        NOEQZ :: NatOrdering EQ Z Z
>        NOEQS :: NatOrdering EQ n m -> NatOrdering EQ (S n) (S m)
>        NOGTE :: NatOrdering EQ n m -> NatOrdering GT (S n) m
>        NOGTS :: NatOrdering GT n m -> NatOrdering GT (S n) m
> 
>     type MaxSIsSMaxEQ
>        :: forall n m . NatOrdering EQ n m -> Max n (S m) :~: S (Max n m)
>     type family MaxSIsSMaxEQ o where
>        MaxSIsSMaxEQ NOEQZ = Refl
>        MaxSIsSMaxEQ (NOEQS o) = Cong S (MaxSIsSMaxEQ o)
> 
>     type TransportVec :: n :~: m -> Vec n a -> Vec m a
>     type family TransportVec p v where
>        TransportVec Refl v = v
> 
>     type ElementwiseOr
>        :: NatOrdering o n m -> Vec n Bool -> Vec m Bool -> Vec (Max n m)
>     Bool
>     type family ElementwiseOr o u v where
>        ElementwiseOr (NOLTE o) u (s :< v) =
>          TransportVec (MaxSIsSMaxEQ o) (s :< ElementwiseOr o u v) -- XXX
>        -- other equations ommitted
>     ---------------------------------------------------------------------------
> 
>     To me, the equation at the end marked with XXX seems like it should
>     work. However, it produces the following error:
> 
>          • Couldn't match kind: Max n ('S m)
>                           with: 'S (Max n m)
>            Expected kind ‘'S (Max n m) :~: 'S (Max n m)’,
>              but ‘MaxSIsSMaxEQ o’ has kind ‘Max n ('S m) :~: 'S (Max n m)’
>          • In the first argument of ‘TransportVec’, namely
>              ‘(MaxSIsSMaxEQ o)’
> 
>     So it expects something of kind `S (Max n m) :~: S (Max n m)` - it
>     seems like Refl fits that bill, but that doesn't work either,
>     because replacing (MaxSIsSMaxEQ o) with Refl means that TransportVec
>     returns a type of the wrong kind, producing a very similar error.
> 
>     I suspect the reason this doesn't work is because type equality
>     isn't equipped to properly handle type family applications. I could
>     potentially work around this if I defined Max as
> 
>     data Max n m r where
>        MaxZZ :: Max Z Z Z
>        MaxSZ :: Max (S n) Z (S n)
>        MaxZS :: Max Z (S m) (S m)
>        MaxSS :: Max n m r -> Max (S n) (S m) (S r)
> 
>     However, dealing with a proof object like this is a lot less
>     convenient than just being able to use a type family for most
>     purposes, so I'd like to avoid this if possible.
> 
>     Is there a way to make this work while sticking with type families?
> 
>     Thanks
> 
>     Jakob
> 
> 
> _______________________________________________
> 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.
> 

From epsilonhalbe at gmail.com  Thu Feb 18 15:53:15 2021
From: epsilonhalbe at gmail.com (Martin Heuschober)
Date: Thu, 18 Feb 2021 15:53:15 +0000
Subject: [Haskell-cafe] Profiling analyzing ghc compilation
Message-ID: <742DBBB9-AFEB-441F-9B4A-6D52BF168445@getmailspring.com>

Hi,

Is there a way to profile (time/space) GHC compilation itself, I'd be interested in what compilation steps in compiling my project take long and how much RAM it uses/why it uses so much RAM, so I can identify what to rewrite, remove, and split to get a leaner build.
Thanks,
Martin

PS.: I hope this is the right place to ask this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/89dbe81b/attachment.html>

From jakob.bruenker at gmail.com  Thu Feb 18 17:00:53 2021
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Thu, 18 Feb 2021 18:00:53 +0100
Subject: [Haskell-cafe] How to deal with type family applications in
	type equalities?
In-Reply-To: <b24727c4-7ed0-89a2-0f3c-34825073fa5f@gmail.com>
References: <CAJjQ6oNU2pRXBa+iH+L4kCDswmzA6GHzEaTBWj_jBiPnzd5ymg@mail.gmail.com>
 <CAJjQ6oMhh__+MtOL7n+o=Q_J8hanPcgHSC4tz2BGkdw7tfRyWA@mail.gmail.com>
 <b24727c4-7ed0-89a2-0f3c-34825073fa5f@gmail.com>
Message-ID: <CAJjQ6oOUt5T1=i0YG-09X24PVVjSPuLRLqGMAprjNAyDmwFT2Q@mail.gmail.com>

I see, thank you for the explanation, Li-yao. I suppose my TransportVec
ended up being quite similar to Rewrite.

Cheers,

Jakob

On Thu, Feb 18, 2021 at 3:29 PM Li-yao Xia <lysxia at gmail.com> wrote:

> Hi Jakob,
>
> For some reason the mental model that "pattern-matching brings
> constraints into scope" does not apply to type families (I think that's
> because "constraints" aren't really a thing at that level). Without such
> a feature, you can only pattern-match on preceding variables to make
> patterns type-check beforehand. In your example the only other variables
> are n and m so you have to split those.
>
> type family Foo n m (p :: Max n (S m) :~: S (Max n m)) :: () where
>    Foo O O Refl = '()
>    Foo O (S m) Refl = '()
>    Foo (S n) m p = '()  -- nontrival because of recursion in the type of p
>
> Under those draconian constraints, it is convenient to first define
> general eliminators for various constructs such as (:~:):
>
> -- type-level equivalent of Data.Type.Equality.castWith
> type family Rewrite (p :: a :~: b) (x :: f a) :: f b where
>    Rewrite Refl x = x
>
> then you can apply such eliminators in situations where pattern-matching
> is actually not feasible or practical:
>
> type Foo :: Max n (S m) :~: S (Max n m) -> f (Max n (S m)) -> f (S (Max
> n m))
> type family Foo (p :: Max n (S m) :~: S (Max n m)) (x :: f (Max n (S
> m))) :: f (S (Max n m)) where
>    Foo p x = Rew p x
>    -- Good luck doing that by pattern-matching on n and m...
>
> Note that Rewrite looks like what you'd write at the term level, but it
> is actually best thought of as working backwards: first, pattern-match
> on a and b (doing an equality test) and then, if they are equal,
> pattern-match on Refl (at which point this is really redundant). This
> means that Rewrite is *a priori* partial because it does not handle the
> case where a and b are distinct; we only know otherwise because there is
> no Refl in that case. In contrast, the function castWith uses a
> primitive notion of pattern-matching on GADTs, you split (p :: a :~: b)
> and there is only once case by definition of (:~:) (before knowing
> anything about a and b), where you get handed the underlying equality
> constraint.
>
> Cheers,
> Li-yao
>
> On 2/18/2021 12:36 AM, Jakob Brünker wrote:
> > *sigh* sorry, disregard part of this, I missed something obvious. I just
> > need to replace `MaxSIsSMaxEQ o` with `Sym (MaxSIsSMaxEQ o)`, and then
> > it works.
> >
> > However, I'm still somewhat confused - the reason why I thought the type
> > family application was the problem to begin with is that I tried this:
> >
> >    type Foo :: Max n (S m) :~: S (Max n m) -> ()
> >    type family Foo p where
> >      Foo Refl = '()
> >
> > and it results in the error
> >
> >      • Couldn't match kind: Max n ('S m)
> >                       with: 'S (Max n m)
> >        Expected kind ‘Max n ('S m) :~: 'S (Max n m)’,
> >          but ‘Refl’ has kind ‘Max n ('S m) :~: Max n ('S m)’
> >      • In the first argument of ‘Foo’, namely ‘Refl’
> >        In the type family declaration for ‘Foo’
> >
> > What is the reason I can't pattern match on Refl here? I would expect it
> > to simply being the constraint `Max n (S m) ~ S (Max n m)` into scope.
> >
> > Thanks,
> > Jakob
> >
> > On Thu, Feb 18, 2021 at 5:52 AM Jakob Brünker <jakob.bruenker at gmail.com
> > <mailto:jakob.bruenker at gmail.com>> wrote:
> >
> >     Imagine you want to have a type level function that calculates the
> >     element-wise OR on two bitstrings, encoded as length-indexed vectors
> >     filled with Bools (this is a simplification of something I need for
> >     a project). The vectors should be "aligned to the right" as it were,
> >     such that the new right-most value is True if the right-most value
> >     of the first vector OR the right-most value of the second vector was
> >     True.
> >
> >     Example (replacing True and False with 1 and 0 for readability):
> >     ElementwiseOr [1,0,1,1] [0,1,1,0,0,0,0,1]
> >     = [0,1,1,0,1,0,1,1]
> >
> >     Its type would be something like
> >     ElementwiseOr :: Vec n Bool -> Vec m Bool -> Vec (Max n m) Bool
> >
> >     I have written the following code:
> >
> >
>  ---------------------------------------------------------------------------
> >     {-# LANGUAGE TypeFamilies, GADTs, DataKinds,
> StandaloneKindSignatures,
> >                   PolyKinds, TypeOperators, RankNTypes, TypeApplications,
> >                   UndecidableInstances #-}
> >
> >     import Data.Kind
> >     import Data.Type.Equality
> >
> >     data Nat = Z | S Nat
> >
> >     infixr 5 :<
> >
> >     type Vec :: Nat -> Type -> Type
> >     data Vec n a where
> >        Nil :: Vec Z a
> >        (:<) :: a -> Vec n a -> Vec (S n) a
> >
> >     type Cong :: forall f -> a :~: b -> f a :~: f b
> >     type family Cong f p where
> >        Cong f Refl = Refl
> >
> >     type Max :: Nat -> Nat -> Nat
> >     type family Max n m where
> >        Max Z m = m
> >        Max n Z = n
> >        Max (S n) (S m) = S (Max n m)
> >
> >     -- The reason for this slightly convoluted Ordering type is that it
> >     seems
> >     -- to make the "right-alignment" easier.
> >     type NatOrdering :: Ordering -> Nat -> Nat -> Type
> >     data NatOrdering o n m where
> >        NOLTE :: NatOrdering EQ n m -> NatOrdering LT n (S m)
> >        NOLTS :: NatOrdering LT n m -> NatOrdering LT n (S m)
> >        NOEQZ :: NatOrdering EQ Z Z
> >        NOEQS :: NatOrdering EQ n m -> NatOrdering EQ (S n) (S m)
> >        NOGTE :: NatOrdering EQ n m -> NatOrdering GT (S n) m
> >        NOGTS :: NatOrdering GT n m -> NatOrdering GT (S n) m
> >
> >     type MaxSIsSMaxEQ
> >        :: forall n m . NatOrdering EQ n m -> Max n (S m) :~: S (Max n m)
> >     type family MaxSIsSMaxEQ o where
> >        MaxSIsSMaxEQ NOEQZ = Refl
> >        MaxSIsSMaxEQ (NOEQS o) = Cong S (MaxSIsSMaxEQ o)
> >
> >     type TransportVec :: n :~: m -> Vec n a -> Vec m a
> >     type family TransportVec p v where
> >        TransportVec Refl v = v
> >
> >     type ElementwiseOr
> >        :: NatOrdering o n m -> Vec n Bool -> Vec m Bool -> Vec (Max n m)
> >     Bool
> >     type family ElementwiseOr o u v where
> >        ElementwiseOr (NOLTE o) u (s :< v) =
> >          TransportVec (MaxSIsSMaxEQ o) (s :< ElementwiseOr o u v) -- XXX
> >        -- other equations ommitted
> >
>  ---------------------------------------------------------------------------
> >
> >     To me, the equation at the end marked with XXX seems like it should
> >     work. However, it produces the following error:
> >
> >          • Couldn't match kind: Max n ('S m)
> >                           with: 'S (Max n m)
> >            Expected kind ‘'S (Max n m) :~: 'S (Max n m)’,
> >              but ‘MaxSIsSMaxEQ o’ has kind ‘Max n ('S m) :~: 'S (Max n
> m)’
> >          • In the first argument of ‘TransportVec’, namely
> >              ‘(MaxSIsSMaxEQ o)’
> >
> >     So it expects something of kind `S (Max n m) :~: S (Max n m)` - it
> >     seems like Refl fits that bill, but that doesn't work either,
> >     because replacing (MaxSIsSMaxEQ o) with Refl means that TransportVec
> >     returns a type of the wrong kind, producing a very similar error.
> >
> >     I suspect the reason this doesn't work is because type equality
> >     isn't equipped to properly handle type family applications. I could
> >     potentially work around this if I defined Max as
> >
> >     data Max n m r where
> >        MaxZZ :: Max Z Z Z
> >        MaxSZ :: Max (S n) Z (S n)
> >        MaxZS :: Max Z (S m) (S m)
> >        MaxSS :: Max n m r -> Max (S n) (S m) (S r)
> >
> >     However, dealing with a proof object like this is a lot less
> >     convenient than just being able to use a type family for most
> >     purposes, so I'd like to avoid this if possible.
> >
> >     Is there a way to make this work while sticking with type families?
> >
> >     Thanks
> >
> >     Jakob
> >
> >
> > _______________________________________________
> > 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-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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/1793a7cb/attachment.html>

From rae at richarde.dev  Thu Feb 18 19:26:34 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 18 Feb 2021 19:26:34 +0000
Subject: [Haskell-cafe] Profiling analyzing ghc compilation
In-Reply-To: <742DBBB9-AFEB-441F-9B4A-6D52BF168445@getmailspring.com>
References: <742DBBB9-AFEB-441F-9B4A-6D52BF168445@getmailspring.com>
Message-ID: <010f0177b69bb8e1-8c19d5f1-22ed-4b67-9364-4c11a86de524-000000@us-east-2.amazonses.com>

Hi Martin,

Having seen this before, I knew there had to be a compiler option for this... and checking the Debugging the Compiler section of the manual surfaces -dshow-passes, which should do exactly what you're asking for.

I hope this helps!
Richard

> On Feb 18, 2021, at 10:53 AM, Martin Heuschober <epsilonhalbe at gmail.com> wrote:
> 
> Hi,
> 
> Is there a way to profile (time/space) GHC compilation itself, I'd be interested in what compilation steps in compiling my project take long and how much RAM it uses/why it uses so much RAM, so I can identify what to rewrite, remove, and split to get a leaner build.
> 
> Thanks,
> Martin
> 
> PS.: I hope this is the right place to ask this.
> 
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/fbfcf54a/attachment.html>

From rae at richarde.dev  Thu Feb 18 19:52:01 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 18 Feb 2021 19:52:01 +0000
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
Message-ID: <010f0177b6b30699-420dd0c9-ca69-4880-afe0-eb276413d83d-000000@us-east-2.amazonses.com>

As someone who usually works on individual scraps of Haskell (not projects), I frequently wish to do the same and have struggled with both cabal and stack in getting what I want.

Happily, there is a nicely working alternative to both: cabal-env from https://github.com/phadej/cabal-extras <https://github.com/phadej/cabal-extras> works great. I use it regularly. It does what you want.

Happy Haskelling,
Richard

> On Feb 18, 2021, at 3:22 AM, A. Mc. <47dragonfyre at gmail.com> wrote:
> 
> Hello,
> 
> I am trying to add the package System.Random to be able to run it the same way Data.List or Data.Char, et cetera does in ghci and in doing a ghc command line build.  I've tried using $ stack ghci --package random which I have to run every single time I want to load a module that imports anything from System.Random and I've already tried $ cabal install --lib random which only works with cabal, and I've used the command $ stack install random, which says 'cache populated' but if a restart and load a dependent module, still is not working for me.  I've also tried to update the .yaml file by putting System.Random into the brackets is the sr directory, but this I'm guessing isn't what you're supposed to do as it doesn't work either. I'm using Cygwin on a Windows 10 operating system.  Your assistance in this matter would be greatly appreciated.
> 
> Thank you for your time.
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/c4ade008/attachment.html>

From ietf-dane at dukhovni.org  Thu Feb 18 20:35:10 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 18 Feb 2021 15:35:10 -0500
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
Message-ID: <YC7PfsCffnTf1mGK@straasha.imrryr.org>

On Thu, Feb 18, 2021 at 12:22:52AM -0800, A. Mc. wrote:

> I am trying to add the package System.Random to be able to run it the same
> way Data.List or Data.Char, et cetera does in ghci and in doing a ghc
> command line build.  I've tried using $ stack ghci --package random which I
> have to run every single time I want to load a module that imports anything
> from System.Random and I've already tried $ cabal install --lib random
> which only works with cabal, and I've used the command $ stack install
> random, which says 'cache populated' but if a restart and load a dependent
> module, still is not working for me.  I've also tried to update the .yaml
> file by putting System.Random into the brackets is the sr directory, but
> this I'm guessing isn't what you're supposed to do as it doesn't work
> either. I'm using Cygwin on a Windows 10 operating system.  Your assistance
> in this matter would be greatly appreciated.

You can use "cabal repl -z" to run ghci with the Cabal "user" package
database in scope:

    $ ghci
    GHCi, version 9.0.1: https://www.haskell.org/ghc/  :? for help
    λ> :set -package iproute
    cannot satisfy -package iproute
        (use -v for more information)
    λ>
    Leaving GHCi.

    $ cabal repl -z
    Resolving dependencies...
    Build profile: -w ghc-9.0.1 -O1
    In order, the following will be built (use -v for more details):
     - fake-package-0 (lib) (first run)
    Configuring library for fake-package-0..
    Preprocessing library for fake-package-0..
    Warning: No exposed modules
    GHCi, version 9.0.1: https://www.haskell.org/ghc/  :? for help
    Loaded GHCi configuration from /tmp/cabal-repl.-87318/setcwd.ghci
    λ> :set -XOverloadedStrings
    λ> :set -package iproute
    package flags have changed, resetting and loading new packages...
    λ> import Data.IP
    λ> import Numeric
    λ> showHex (fromIPv4w "127.0.0.1") ""
    "7f000001"

-- 
    Viktor.

From ietf-dane at dukhovni.org  Thu Feb 18 20:48:57 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 18 Feb 2021 15:48:57 -0500
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <YC7PfsCffnTf1mGK@straasha.imrryr.org>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
 <YC7PfsCffnTf1mGK@straasha.imrryr.org>
Message-ID: <YC7SudQYQ+u3iA8K@straasha.imrryr.org>

On Thu, Feb 18, 2021 at 03:35:10PM -0500, Viktor Dukhovni wrote:

> You can use "cabal repl -z" to run ghci with the Cabal "user" package
> database in scope:
> 
>     $ cabal repl -z
>     [...]
>     λ> :set -XOverloadedStrings
>     λ> :set -package iproute

Or you can also put some of the requirements on the command-line, and
drop the verbose start up messages via:

    $ cabal repl -v0 -z --repl-options -package=iproute --repl-options -XOverloadedStrings
    λ> import Data.IP
    λ> import Numeric
    λ> showHex (fromIPv4w "127.0.0.1") ""
    "7f000001"

This way, you can define shell aliases for frequently used combinations
of parameters.

-- 
    Viktor.

From rae at richarde.dev  Thu Feb 18 21:15:53 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 18 Feb 2021 21:15:53 +0000
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <YC7SudQYQ+u3iA8K@straasha.imrryr.org>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
 <YC7PfsCffnTf1mGK@straasha.imrryr.org> <YC7SudQYQ+u3iA8K@straasha.imrryr.org>
Message-ID: <010f0177b6ffcbb6-6a4d2bc7-a2ba-4e2e-b868-a484b15472eb-000000@us-east-2.amazonses.com>



> On Feb 18, 2021, at 3:48 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
>    $ cabal repl -v0 -z --repl-options -package=iproute --repl-options -XOverloadedStrings

Yes, but it's so, so much easier just to say `ghci`. And then I can pass lots of options to `ghci` directly when I want to. And I don't have to spend time writing and maintaining wrapper scripts.

I do know what can go wrong with a global package database, and sometimes (once every 2-3 years?) it does go wrong. But I still prefer to work with a global database for my usual workflow.

Richard


From migmit at gmail.com  Thu Feb 18 21:36:54 2021
From: migmit at gmail.com (MigMit)
Date: Thu, 18 Feb 2021 22:36:54 +0100
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <010f0177b6ffcbb6-6a4d2bc7-a2ba-4e2e-b868-a484b15472eb-000000@us-east-2.amazonses.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
 <YC7PfsCffnTf1mGK@straasha.imrryr.org> <YC7SudQYQ+u3iA8K@straasha.imrryr.org>
 <010f0177b6ffcbb6-6a4d2bc7-a2ba-4e2e-b868-a484b15472eb-000000@us-east-2.amazonses.com>
Message-ID: <D7A66037-E60D-4C34-A79C-0068C1ECB387@gmail.com>

So do I.

But it seems to me like a global trend: more and more tools are designed to make our life easier, and it becomes harder and harder to deal with the mess they create.

> On 18 Feb 2021, at 22:15, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> 
> 
>> On Feb 18, 2021, at 3:48 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>> 
>>   $ cabal repl -v0 -z --repl-options -package=iproute --repl-options -XOverloadedStrings
> 
> Yes, but it's so, so much easier just to say `ghci`. And then I can pass lots of options to `ghci` directly when I want to. And I don't have to spend time writing and maintaining wrapper scripts.
> 
> I do know what can go wrong with a global package database, and sometimes (once every 2-3 years?) it does go wrong. But I still prefer to work with a global database for my usual workflow.
> 
> Richard
> 
> _______________________________________________
> 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.


From guthrie at miu.edu  Thu Feb 18 21:50:40 2021
From: guthrie at miu.edu (Gregory Guthrie)
Date: Thu, 18 Feb 2021 21:50:40 +0000
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <D7A66037-E60D-4C34-A79C-0068C1ECB387@gmail.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
 <YC7PfsCffnTf1mGK@straasha.imrryr.org> <YC7SudQYQ+u3iA8K@straasha.imrryr.org>
 <010f0177b6ffcbb6-6a4d2bc7-a2ba-4e2e-b868-a484b15472eb-000000@us-east-2.amazonses.com>
 <D7A66037-E60D-4C34-A79C-0068C1ECB387@gmail.com>
Message-ID: <DM6PR03MB43314B8063EE361D29C23D78A1859@DM6PR03MB4331.namprd03.prod.outlook.com>

I agree - and had a run-around with this same issue recently (https://stackoverflow.com/questions/65836038/haskell-timeit-module-systemtimeit-not-found)

The options for simple usage were failing - a JIRA was filed:
"ghc and ghci don't read the default package environment file on Windows"
https://gitlab.haskell.org/ghc/ghc/-/issues/19286


-----Original Message-----
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of MigMit
Sent: Thursday, February 18, 2021 3:37 PM

So do I.

But it seems to me like a global trend: more and more tools are designed to make our life easier, and it becomes harder and harder to deal with the mess they create.

> On 18 Feb 2021, at 22:15, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> Yes, but it's so, so much easier just to say `ghci`. And then I can pass lots of options to `ghci` directly when I want to. And I don't have to spend time writing and maintaining wrapper scripts.
> 

From qdunkan at gmail.com  Fri Feb 19 03:38:50 2021
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu, 18 Feb 2021 19:38:50 -0800
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <010f0177b6ffcbb6-6a4d2bc7-a2ba-4e2e-b868-a484b15472eb-000000@us-east-2.amazonses.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
 <YC7PfsCffnTf1mGK@straasha.imrryr.org> <YC7SudQYQ+u3iA8K@straasha.imrryr.org>
 <010f0177b6ffcbb6-6a4d2bc7-a2ba-4e2e-b868-a484b15472eb-000000@us-east-2.amazonses.com>
Message-ID: <CACbaDy4mztBqzuTK7ZkdZi4d2SaXuB+6-OYyWqMVX8bXimZ2rA@mail.gmail.com>

On Thu, Feb 18, 2021, 1:18 PM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> > On Feb 18, 2021, at 3:48 PM, Viktor Dukhovni <ietf-dane at dukhovni.org>
> wrote:
> >
> >    $ cabal repl -v0 -z --repl-options -package=iproute --repl-options
> -XOverloadedStrings
>
> Yes, but it's so, so much easier just to say `ghci`. And then I can pass
> lots of options to `ghci` directly when I want to. And I don't have to
> spend time writing and maintaining wrapper scripts.
>

I've been using the global db for the last 15 years or so and never came
across cabal hell. I don't really know why but maybe one reason is that I
wrote an uninstaller right in the beginning and then would only allow a
single version of each package.

Nowadays I also use nix and it's good for experiments but the old fashioned
way still works fine and is more convenient. I've never actually used cabal
repl.

So I say go ahead and v1-install it works fine.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210218/25380489/attachment.html>

From kolar at fit.vut.cz  Fri Feb 19 08:05:04 2021
From: kolar at fit.vut.cz (=?utf-8?B?RHXFoWFuIEtvbMOhxZk=?=)
Date: Fri, 19 Feb 2021 09:05:04 +0100
Subject: [Haskell-cafe] Sizes in memory?
Message-ID: <2597374.qnE7q5IlLC@pckolar>

Dear café,

I don't know, whether this is the right place to ask, but I'll try :-)

If I would like to know size of the list in the memory (after complete evaluation, e.g. 
deepseq). The type is [( Int, [([Int],[Int])] )].

So we have K tuples of the type (Int,[([Int],[Int])])
Each tuple has N tuples of the type ([Int],[Int])
and each of these lists M elements long (yes, both a are of the same length).

Top level list needs (on 64bit CPU) 8 bytes for pointer to elements, 8 bytes to point 
to another element, some more "expenses", probably yes, tag, anything else?

So we have K*(16+XXX), where XXX is for size of (Int,[([Int],[Int])]).

Tuple needs 8 bytes for each pointer, so XXX = 16 + YYY, where YYY is the size of the 
[([Int],[Int])] list. It needs 8 + 8 bytes on the list, we have N such elements, thus YYY = 
N * (16 + ZZZ), where ZZZ is size of the ([Int],[Int]).

Again tuple, so 16 bytes + 2*(M * (16 + 8))
-- 16 bytes for 2 tuple elements
-- 2 for two lists
-- every list 16 bytes for list itself
-- 8 bytes for Int

So ZZZ = 16 + 2*(M * (16 + 8)), thus
YYY = N * (16 + 16 + 2*(M * (16 + 8))), thus
XXX = 16 + N * (16 + 16 + 2*(M * (16 + 8))), thus
size = K * (16 + 16 + N * (16 + 16 + 2*(M * (16 + 8))))
     = K* (32 + N* (32 + M*48) )

Am I right? Roughly right? Or totally wrong?

E.g. for K = 25, N = 10000, M = 7 we get cca 88MiB ? 

Why am I asking? In reality the memory consumption is much higher, so I must be 
missing some extras, e.g. each memory chunk extra 8 bytes for GC, extra for tag, 
extra to point to VMT?

Regards,
Dušan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210219/db5c9215/attachment.html>

From mail at joachim-breitner.de  Fri Feb 19 21:54:35 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 19 Feb 2021 22:54:35 +0100
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <010f0177b6b30699-420dd0c9-ca69-4880-afe0-eb276413d83d-000000@us-east-2.amazonses.com>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
 <010f0177b6b30699-420dd0c9-ca69-4880-afe0-eb276413d83d-000000@us-east-2.amazonses.com>
Message-ID: <cdcfbf39175a3d542a9eb0e7d11e465fc5dd0db3.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 18.02.2021, 19:52 +0000 schrieb Richard Eisenberg:
> As someone who usually works on individual scraps of Haskell (not
> projects), I frequently wish to do the same and have struggled with
> both cabal and stack in getting what I want.
> 
> Happily, there is a nicely working alternative to both: cabal-env
> from https://github.com/phadej/cabal-extras works great. I use it
> regularly. It does what you want.


I couldn't find a README, hard to see what it does exactly. Is it just
more convenience around the idiom of using

   cabal install --env . --lib ghc-heap-view

to get a .ghc.environment file in the local directory (which is, as
long as you use ghc or ghci in that directory, as good as the good old
cabal v1-install, it seems)?


Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Fri Feb 19 22:01:17 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 19 Feb 2021 23:01:17 +0100
Subject: [Haskell-cafe] Sizes in memory?
In-Reply-To: <2597374.qnE7q5IlLC@pckolar>
References: <2597374.qnE7q5IlLC@pckolar>
Message-ID: <02ffb8bd8ff14cd63ad73e621c409d47ebc00a38.camel@joachim-breitner.de>

Hi Dušan,


Am Freitag, den 19.02.2021, 09:05 +0100 schrieb Dušan Kolář:
> Dear café,
> 
> I don't know, whether this is the right place to ask, but I'll try :-)
> 
> If I would like to know size of the list in the memory (after complete evaluation, e.g. deepseq). The type is [( Int, [([Int],[Int])] )].
> 
> So we have K tuples of the type (Int,[([Int],[Int])])
> Each tuple has N tuples of the type ([Int],[Int])
> and each of these lists M elements long (yes, both a are of the same length).
> 
> Top level list needs (on 64bit CPU) 8 bytes for pointer to elements, 8 bytes to point to another element, some more "expenses", probably yes, tag, anything else?

A list cons cell indeed needs 3 words.

> So we have K*(16+XXX), where XXX is for size of (Int,[([Int],[Int])]).
> 
> Tuple needs 8 bytes for each pointer, so XXX = 16 + YYY, where YYY is
> the size of the [([Int],[Int])] list.

Again, another word for the tag, so make it 32 bytes for the tuple.

> It needs 8 + 8 bytes on the list, we have N such elements, thus YYY =
> N * (16 + ZZZ), where ZZZ is size of the ([Int],[Int]).
> 
> Again tuple, so 16 bytes + 2*(M * (16 + 8))
> -- 16 bytes for 2 tuple elements
> -- 2 for two lists
> -- every list 16 bytes for list itself
> -- 8 bytes for Int
> 
> So ZZZ = 16 + 2*(M * (16 + 8)), thus
> YYY = N * (16 + 16 + 2*(M * (16 + 8))), thus
> XXX = 16 + N * (16 + 16 + 2*(M * (16 + 8))), thus
> size = K * (16 + 16 + N * (16 + 16 + 2*(M * (16 + 8))))
>      = K* (32 + N* (32 + M*48) )
> 
> Am I right? Roughly right? Or totally wrong?

Up to the tags, mostly right, got lost half way. An Int is actually two
words as well (tag plus raw value). Unless its value is ≤ 16, these are
statically allocated…

You can play around with
https://hackage.haskell.org/package/ghc-datasize
or sign up to https://bobkonf.de/2021/de/registration.html where I
happen to give a tutorial next Friday where I will look (among other
things) exactly at questions like these.

Or seem my talk on that from a while ago:
https://vimeo.com/100166511

> Why am I asking? In reality the memory consumption is much higher, so
> I must be missing some extras, e.g. each memory chunk extra 8 bytes
> for GC, extra for tag, extra to point to VMT?

You missed the one word for the tag, yes. And are you sure it’s fully
evaluated? Else you might see thunks around.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Fri Feb 19 22:10:23 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 19 Feb 2021 22:10:23 +0000
Subject: [Haskell-cafe] Global Package Install
In-Reply-To: <cdcfbf39175a3d542a9eb0e7d11e465fc5dd0db3.camel@joachim-breitner.de>
References: <CAOsti3k_hj6aSfoEqRcy6ojnZnYnvqChaydpYMhDz6b+=B7J3w@mail.gmail.com>
 <010f0177b6b30699-420dd0c9-ca69-4880-afe0-eb276413d83d-000000@us-east-2.amazonses.com>
 <cdcfbf39175a3d542a9eb0e7d11e465fc5dd0db3.camel@joachim-breitner.de>
Message-ID: <010f0177bc580f2a-533af24f-8025-4c14-9387-2676ac5c9424-000000@us-east-2.amazonses.com>



> On Feb 19, 2021, at 4:54 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> I couldn't find a README, hard to see what it does exactly. Is it just
> more convenience around the idiom of using
> 
>   cabal install --env . --lib ghc-heap-view
> 
> to get a .ghc.environment file in the local directory (which is, as
> long as you use ghc or ghci in that directory, as good as the good old
> cabal v1-install, it seems)?

Maybe? I don't know -- that's part of the beauty of it (for me). I just type `cabal-env lens` and then I can access lens modules from ghci, no matter where I start ghci. So it can't be exactly what you wrote, because whatever cabal-env does is directory-agnostic.

Richard

From amindfv at mailbox.org  Sat Feb 20 01:05:12 2021
From: amindfv at mailbox.org (amindfv at mailbox.org)
Date: Fri, 19 Feb 2021 18:05:12 -0700
Subject: [Haskell-cafe] Grapheme length?
Message-ID: <20210220010512.GA4124@painter.painter>

Does there exist a Haskell library or function for getting grapheme lengths of String/Text values?

e.g. right now,

    Prelude.length ("ä" :: String) == 2
    Data.Text.length ("ä" :: Text) == 2

But I'd like, either for String or Text, to get 1 instead (there are 2 code points but only 1 grapheme).

Thanks,
Tom

From ietf-dane at dukhovni.org  Sat Feb 20 02:03:44 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 19 Feb 2021 21:03:44 -0500
Subject: [Haskell-cafe] Grapheme length?
In-Reply-To: <20210220010512.GA4124@painter.painter>
References: <20210220010512.GA4124@painter.painter>
Message-ID: <YDBuAGlo2qwp9cao@straasha.imrryr.org>

On Fri, Feb 19, 2021 at 06:05:12PM -0700, amindfv--- via Haskell-Cafe wrote:

> Does there exist a Haskell library or function for getting grapheme
> lengths of String/Text values?

Depends on your definition of "grapheme length" :-)
If you're OK with counting NFC code points, then the answer is yes,
via the "text-icu" package.

    $ cabal repl -z -v0 \
      --repl-options "-package=text-icu" \
      --repl-options "-package=text" \
      --repl-options -XOverloadedStrings
    λ> import qualified Data.Text as T
    λ> import Data.Text.ICU.Normalize
    λ> length $ T.unpack $ normalize NFC "ä"
    1
    λ> length $ T.unpack $ normalize NFD "ä"
    2
    λ> length $ T.unpack $ normalize NFC $ normalize NFD "ä"
    1

With the "Data.Text.ICU.Char" module, it may be possible to determine
grapheme boundaries:

    https://hackage.haskell.org/package/text-icu-0.7.0.1/docs/Data-Text-ICU-Char.html#g:5

-- 
    Viktor.

From amindfv at mailbox.org  Sat Feb 20 03:03:54 2021
From: amindfv at mailbox.org (amindfv at mailbox.org)
Date: Fri, 19 Feb 2021 20:03:54 -0700
Subject: [Haskell-cafe] Grapheme length?
In-Reply-To: <YDBuAGlo2qwp9cao@straasha.imrryr.org>
References: <20210220010512.GA4124@painter.painter>
 <YDBuAGlo2qwp9cao@straasha.imrryr.org>
Message-ID: <20210220030354.GA11092@painter.painter>

On Fri, Feb 19, 2021 at 09:03:44PM -0500, Viktor Dukhovni wrote:
> On Fri, Feb 19, 2021 at 06:05:12PM -0700, amindfv--- via Haskell-Cafe wrote:
> 
> > Does there exist a Haskell library or function for getting grapheme
> > lengths of String/Text values?
> 
> Depends on your definition of "grapheme length" :-)
> If you're OK with counting NFC code points, then the answer is yes,
> via the "text-icu" package.
> 
>     $ cabal repl -z -v0 \
>       --repl-options "-package=text-icu" \
>       --repl-options "-package=text" \
>       --repl-options -XOverloadedStrings
>     λ> import qualified Data.Text as T
>     λ> import Data.Text.ICU.Normalize
>     λ> length $ T.unpack $ normalize NFC "ä"
>     1
>     λ> length $ T.unpack $ normalize NFD "ä"
>     2
>     λ> length $ T.unpack $ normalize NFC $ normalize NFD "ä"
>     1
> 

Thanks. Unfortunately this doesn't work well for graphemes which don't have a 1-code-point equivalent, like:

    length $ T.unpack $ normalize NFC $ normalize NFD "❤️"
    == 2

> With the "Data.Text.ICU.Char" module, it may be possible to determine
> grapheme boundaries:
> 
>     https://hackage.haskell.org/package/text-icu-0.7.0.1/docs/Data-Text-ICU-Char.html#g:5

I'll look into this and report back.

Tom

From amindfv at mailbox.org  Sat Feb 20 05:59:59 2021
From: amindfv at mailbox.org (amindfv at mailbox.org)
Date: Fri, 19 Feb 2021 22:59:59 -0700
Subject: [Haskell-cafe] Grapheme length?
In-Reply-To: <20210220030354.GA11092@painter.painter>
References: <20210220010512.GA4124@painter.painter>
 <YDBuAGlo2qwp9cao@straasha.imrryr.org>
 <20210220030354.GA11092@painter.painter>
Message-ID: <20210220055959.GA16570@painter.painter>

> > With the "Data.Text.ICU.Char" module, it may be possible to determine
> > grapheme boundaries:
> > 
> >     https://hackage.haskell.org/package/text-icu-0.7.0.1/docs/Data-Text-ICU-Char.html#g:5
> 
> I'll look into this and report back.
> 

I'm quite prepared to believe this is wrong/misguided, but I was able to hack something together that works for my uses so far:

    import Data.Text.ICU.Char
    len = length . filter (==Nothing) . map (property GraphemeClusterBreak) . T.unpack

Example:

len ("🤣h👩🏻elloä❤️❤️👩❤️👩" :: Text)
== 13

Tom

From ietf-dane at dukhovni.org  Sat Feb 20 07:56:16 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 20 Feb 2021 05:56:16 -0200
Subject: [Haskell-cafe] Grapheme length?
In-Reply-To: <20210220055959.GA16570@painter.painter>
References: <20210220010512.GA4124@painter.painter>
 <YDBuAGlo2qwp9cao@straasha.imrryr.org>
 <20210220030354.GA11092@painter.painter>
 <20210220055959.GA16570@painter.painter>
Message-ID: <F5E2F1E7-26A0-4618-A870-4E9755FB134C@dukhovni.org>



> On Feb 20, 2021, at 3:59 AM, amindfv--- via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
>>> With the "Data.Text.ICU.Char" module, it may be possible to determine
>>> grapheme boundaries:
>>> 
>>>    https://hackage.haskell.org/package/text-icu-0.7.0.1/docs/Data-Text-ICU-Char.html#g:5
>> 
>> I'll look into this and report back.
>> 
> 
> I'm quite prepared to believe this is wrong/misguided, but I was able to hack something together that works for my uses so far:
> 
>    import Data.Text.ICU.Char
>    len = length . filter (==Nothing) . map (property GraphemeClusterBreak) . T.unpack
> 
> Example:
> 
> len ("🤣h👩🏻elloä❤️❤️👩❤️👩" :: Text)
> == 13

There's unfortunately at least one problem, which requires attention
from a text-icu maintainer, but AFAIK, there isn't one just at the
moment (see the libraries list archive).

The issue is that recent "icu" versions return GraphemClusterBreak values
that outside the range known to the "Char" module:

  https://github.com/haskell/text-icu/blob/36c2cf236da06cb3b08fa8e5c3981d784d4b9af2/Data/Text/ICU/Char.hsc#L853-L865

but it blithely calls "toEnum" on whatever the FFI call returns, and triggers an error:

  [Nothing,*** Exception: toEnum{GraphemeClusterBreak}: tag (16) is outside of enumeration's range (0,10)
  CallStack (from HasCallStack):
    error, called at Data/Text/ICU/Char.hsc:865:19 in text-icu-0.7.0.1-08bd532cd2c809ab3173b6766231a799217ecc9a166de7458474e8784471d168:Data.Text.ICU.Char

But in fact, exactly some of the new code points are relevant for detection
of grapheme cluster boundaries (your algorithm looks too naïve) see:

http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundary_Rules

When citing the Unicode definition of grapheme clusters, it must be clear which
of the two alternatives are being specified: extended versus legacy.

Break at the start and end of text, unless the text is empty.
GB1	sot	÷	Any
GB2	Any	÷	eot

Do not break between a CR and LF. Otherwise, break before and after controls.
GB3	CR	×	LF
GB4	(Control | CR | LF)	÷	 
GB5				÷	(Control | CR | LF)

Do not break Hangul syllable sequences.
GB6	L	×	(L | V | LV | LVT)
GB7	(LV | V)	×	(V | T)
GB8	(LVT | T)	×	T

Do not break before extending characters or ZWJ.
GB9	 	×	(Extend | ZWJ)

The GB9a and GB9b rules only apply to extended grapheme clusters: 
Do not break before SpacingMarks, or after Prepend characters.
GB9a	 	×	SpacingMark
GB9b	Prepend	×
	 
Do not break within emoji modifier sequences or emoji zwj sequences.
GB11	\p{Extended_Pictographic} Extend* ZWJ	×	\p{Extended_Pictographic}

Do not break within emoji flag sequences. That is, do not break between regional indicator (RI) symbols if there is an odd number of RI characters before the break point.
GB12	sot (RI RI)* RI	×	RI
GB13	[^RI] (RI RI)* RI	×	RI

Otherwise, break everywhere.
GB999	Any	÷	Any
Notes:

	• Grapheme cluster boundaries can be transformed into simple regular expressions. For more information, see Section 6.3, State Machines.
	• The Grapheme_Base and Grapheme_Extend properties predated the development of the Grapheme_Cluster_Break property. The set of characters with Grapheme_Extend=Yes is used to derive the set of characters with Grapheme_Cluster_Break=Extend. However, the Grapheme_Base property proved to be insufficient for determining grapheme cluster boundaries. Grapheme_Base is no longer used by this specification.

-- 
	Viktor.


From ietf-dane at dukhovni.org  Sat Feb 20 08:12:58 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 20 Feb 2021 06:12:58 -0200
Subject: [Haskell-cafe] Grapheme length?
In-Reply-To: <F5E2F1E7-26A0-4618-A870-4E9755FB134C@dukhovni.org>
References: <20210220010512.GA4124@painter.painter>
 <YDBuAGlo2qwp9cao@straasha.imrryr.org>
 <20210220030354.GA11092@painter.painter>
 <20210220055959.GA16570@painter.painter>
 <F5E2F1E7-26A0-4618-A870-4E9755FB134C@dukhovni.org>
Message-ID: <26DBDFC8-AADA-42E4-939B-73C64D68CD9B@dukhovni.org>



> On Feb 20, 2021, at 5:56 AM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> But in fact, exactly some of the new code points are relevant for detection
> of grapheme cluster boundaries (your algorithm looks too naïve) see:

More importantly, the ICU documentation does not recommend working with the
underlying low-level properties and rules.  Rather the suggested way to
traverse a string one grapheme at a time is to use a BreakIterator:

  https://unicode-org.github.io/icu/userguide/boundaryanalysis/#character-boundary

Fortunately, these are also supported:

  https://hackage.haskell.org/package/text-icu-0.7.0.1/docs/Data-Text-ICU-Break.html#g:2

So my referral to the "Char" module probably led you astray.  Sorry about that...

-- 
	Viktor.


From ietf-dane at dukhovni.org  Sat Feb 20 08:57:05 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 20 Feb 2021 03:57:05 -0500
Subject: [Haskell-cafe] Grapheme length?
In-Reply-To: <26DBDFC8-AADA-42E4-939B-73C64D68CD9B@dukhovni.org>
References: <20210220010512.GA4124@painter.painter>
 <YDBuAGlo2qwp9cao@straasha.imrryr.org>
 <20210220030354.GA11092@painter.painter>
 <20210220055959.GA16570@painter.painter>
 <F5E2F1E7-26A0-4618-A870-4E9755FB134C@dukhovni.org>
 <26DBDFC8-AADA-42E4-939B-73C64D68CD9B@dukhovni.org>
Message-ID: <YDDO4ZsP0Vpm8aiX@straasha.imrryr.org>

On Sat, Feb 20, 2021 at 06:12:58AM -0200, Viktor Dukhovni wrote:

> Fortunately, these are also supported:
> 
>   https://hackage.haskell.org/package/text-icu-0.7.0.1/docs/Data-Text-ICU-Break.html#g:2

A complete example (the NFC normalisation may be overkill):

    {-# LANGUAGE BangPatterns #-}
    module Main (main) where

    import qualified Data.Text as T
    import qualified Data.Text.Lazy as LT
    import qualified Data.Text.Lazy.Builder as LT
    import qualified Data.Text.Lazy.IO as LT
    import qualified Data.Text.Lazy.Builder.Int as LT
    import Data.Text.ICU.Break
    import Data.Text.ICU.Normalize
    import Data.Text.ICU.Types (LocaleName(..))
    import System.Environment

    main :: IO ()
    main = do
        brkIter <- breakCharacter Current ""
        getArgs >>= mapM_ (go brkIter . normalize NFC . T.pack)
      where
        go :: BreakIterator () -> T.Text -> IO ()
        go b t = do
            setText b t
            len <- count b 0
            LT.putStrLn $ LT.toLazyText $
                LT.fromText t <>
                LT.fromString " has grapheme length: " <>
                LT.decimal len
          where
            count :: Int -> IO Int
            count !acc = next b >>= maybe (pure acc) (const $ count $ acc + 1)

-- 
	Viktor.

From kenta at mit.edu  Sat Feb 20 11:19:40 2021
From: kenta at mit.edu (Ken T Takusagawa)
Date: Sat, 20 Feb 2021 06:19:40 -0500 (EST)
Subject: [Haskell-cafe] help with existential type signature?
Message-ID: <alpine.DEB.2.21.2102200616240.103526@aero-astro-estates.mit.edu>

{-
I am experimenting with type-level naturals and with moving 
values known at runtime to type space.

Is there a type signature that I can add to f1 below so that 
this will compile (maybe also requiring some additional 
LANGUAGE pragmas)?

If I were to change the return value of f1 from "x" to "show 
x", then the program does compile, suggesting that there's 
nothing inherently wrong with "x".  But I'd prefer the 
option to compose the output of f1 with other computations 
separately, e.g., "show . f1" .

Thanks,
Ken

-}

{-# LANGUAGE KindSignatures, ScopedTypeVariables, DataKinds, Rank2Types #-}
import qualified GHC.TypeLits as TypeLits;
import Data.Proxy(Proxy);
main = undefined;

data Foo (fn :: TypeLits.Nat) = Mkfoo deriving (Show);

--f1 :: TypeLits.SomeNat -> ? ;
f1 mynat = case mynat of {
  TypeLits.SomeNat (_ :: Proxy n) -> let {
    x :: Foo n;
    x = Mkfoo;
  } in x
};

{-
typelits.hs:27:8: error:
    * Couldn't match expected type `p' with actual type `Foo n'
        because type variable `n' would escape its scope
      This (rigid, skolem) type variable is bound by
        a pattern with constructor:
          TypeLits.SomeNat :: forall (n :: TypeLits.Nat).
                              TypeLits.KnownNat n =>
                              Proxy n -> TypeLits.SomeNat,
        in a case alternative
        at smalltypelits2.hs:24:3-33
    * In the expression: x
      In the expression:
        let
          x :: Foo n
          x = Mkfoo
        in x
      In a case alternative:
          TypeLits.SomeNat (_ :: Proxy n)
            -> let
                 x :: Foo n
                 x = Mkfoo
               in x
    * Relevant bindings include
        x :: Foo n (bound at smalltypelits2.hs:26:5)
        f1 :: TypeLits.SomeNat -> p (bound at smalltypelits2.hs:23:1)
   |
27 |   } in x
   |        ^
-}

From jakob.bruenker at gmail.com  Sat Feb 20 15:25:35 2021
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Sat, 20 Feb 2021 16:25:35 +0100
Subject: [Haskell-cafe] help with existential type signature?
In-Reply-To: <alpine.DEB.2.21.2102200616240.103526@aero-astro-estates.mit.edu>
References: <alpine.DEB.2.21.2102200616240.103526@aero-astro-estates.mit.edu>
Message-ID: <CAJjQ6oMi7oimLht6kHVapHJRgGm5Cu1PY=G3BEie8+akkyexvQ@mail.gmail.com>

Hi Ken,

ideally, you'd want something like

f1 :: TypeLits.SomeNat -> exists n . Foo n

to indicate that this function will produce a Foo with some natural number,
but you don't know beforehand what that number is.
However, Haskell doesn't have built-in existential quantification (yet), so
you have to use some encoding that uses existing features instead.

There's at least two ways to do this. The first is to use an "existential
data type":

data SomeFoo = forall n . MkSomeFoo (Foo n)

You'll notice that it's named quite similarly to SomeNat - that's because
SomeNat is also an existential data type.
Then you could have a function like

showSomeFoo :: SomeFoo -> String
showSomeFoo (MkSomeFoo x) = show x

The other way is to pass in a function that tells f1 what to do with Foo it
produces:

  f1 :: TypeLits.SomeNat -> (forall fn . Foo fn -> a) -> a
  f1 mynat f = case mynat of {
    TypeLits.SomeNat (_ :: Proxy n) -> let {
      x :: Foo n;
      x = Mkfoo;
    } in f x
  };

In this case, you could call `f1 someNat show` to show a Foo made from
someNat.

These two encodings are equally powerful, but sometimes one is more
convenient than the other.

Cheers,

Jakob

On Sat, Feb 20, 2021 at 12:22 PM Ken T Takusagawa <kenta at mit.edu> wrote:

> {-
> I am experimenting with type-level naturals and with moving
> values known at runtime to type space.
>
> Is there a type signature that I can add to f1 below so that
> this will compile (maybe also requiring some additional
> LANGUAGE pragmas)?
>
> If I were to change the return value of f1 from "x" to "show
> x", then the program does compile, suggesting that there's
> nothing inherently wrong with "x".  But I'd prefer the
> option to compose the output of f1 with other computations
> separately, e.g., "show . f1" .
>
> Thanks,
> Ken
>
> -}
>
> {-# LANGUAGE KindSignatures, ScopedTypeVariables, DataKinds, Rank2Types #-}
> import qualified GHC.TypeLits as TypeLits;
> import Data.Proxy(Proxy);
> main = undefined;
>
> data Foo (fn :: TypeLits.Nat) = Mkfoo deriving (Show);
>
> --f1 :: TypeLits.SomeNat -> ? ;
> f1 mynat = case mynat of {
>   TypeLits.SomeNat (_ :: Proxy n) -> let {
>     x :: Foo n;
>     x = Mkfoo;
>   } in x
> };
>
> {-
> typelits.hs:27:8: error:
>     * Couldn't match expected type `p' with actual type `Foo n'
>         because type variable `n' would escape its scope
>       This (rigid, skolem) type variable is bound by
>         a pattern with constructor:
>           TypeLits.SomeNat :: forall (n :: TypeLits.Nat).
>                               TypeLits.KnownNat n =>
>                               Proxy n -> TypeLits.SomeNat,
>         in a case alternative
>         at smalltypelits2.hs:24:3-33
>     * In the expression: x
>       In the expression:
>         let
>           x :: Foo n
>           x = Mkfoo
>         in x
>       In a case alternative:
>           TypeLits.SomeNat (_ :: Proxy n)
>             -> let
>                  x :: Foo n
>                  x = Mkfoo
>                in x
>     * Relevant bindings include
>         x :: Foo n (bound at smalltypelits2.hs:26:5)
>         f1 :: TypeLits.SomeNat -> p (bound at smalltypelits2.hs:23:1)
>    |
> 27 |   } in x
>    |        ^
> -}
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210220/2adc543d/attachment.html>

From 47dragonfyre at gmail.com  Sun Feb 21 00:36:00 2021
From: 47dragonfyre at gmail.com (A. Mc.)
Date: Sat, 20 Feb 2021 16:36:00 -0800
Subject: [Haskell-cafe] More Efficient Recursion
Message-ID: <CAOsti3m7baCAGRpYiNYEnBUq-m2pz_z3No_sb-ORv7gOPaZkqQ@mail.gmail.com>

Hello,

I'm just starting off, but I'm wondering if anyone has any suggestions.
I've made a recursive function that's goal is to handle a base raised to a
very large power.
modLoop :: Integer -> Integer -> Integer -> Integer -> Integer -> Integer
modLoop iterator exponent result base modulus
  | (iterator == exponent) = result
   | (iterator < exponent) = modLoop (iterator + 1) (exponent) (mod (result
* base) modulus) base modulus
   | (iterator > exponent) = (-1)

However, it flat breaks or takes a long time when using large numbers.

I need to get better at using strict functions, however, I compiled with
ghc -o (as it tends to implement the strict version - ?) and I still have
the same problem.  What's a better way?

Thanks in advance and thank you for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210220/e73a2df5/attachment.html>

From david.feuer at gmail.com  Sun Feb 21 00:45:17 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 20 Feb 2021 19:45:17 -0500
Subject: [Haskell-cafe] More Efficient Recursion
In-Reply-To: <CAOsti3m7baCAGRpYiNYEnBUq-m2pz_z3No_sb-ORv7gOPaZkqQ@mail.gmail.com>
References: <CAOsti3m7baCAGRpYiNYEnBUq-m2pz_z3No_sb-ORv7gOPaZkqQ@mail.gmail.com>
Message-ID: <CAMgWh9u4ZraapxD8w=kLuF3jiGzTWQh85-suaotck6QN2fnm1g@mail.gmail.com>

You can solve the (potential) strictness problem like this:

  | (iterator < exponent) = result `seq` modLoop (iterator + 1) exponent
(mod (result * base) modulus)

but you'd be better off changing your function to use exponentiation by
squaring, which will dramatically reduce the number of multiplications.

On Sat, Feb 20, 2021, 7:36 PM A. Mc. <47dragonfyre at gmail.com> wrote:

> Hello,
>
> I'm just starting off, but I'm wondering if anyone has any suggestions.
> I've made a recursive function that's goal is to handle a base raised to a
> very large power.
> modLoop :: Integer -> Integer -> Integer -> Integer -> Integer -> Integer
> modLoop iterator exponent result base modulus
>   | (iterator == exponent) = result
>    | (iterator < exponent) = modLoop (iterator + 1) (exponent) (mod
> (result * base) modulus) base modulus
>    | (iterator > exponent) = (-1)
>
> However, it flat breaks or takes a long time when using large numbers.
>
> I need to get better at using strict functions, however, I compiled with
> ghc -o (as it tends to implement the strict version - ?) and I still have
> the same problem.  What's a better way?
>
> Thanks in advance and thank you for your time.
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210220/a927667e/attachment.html>

From lemming at henning-thielemann.de  Sun Feb 21 00:50:52 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 21 Feb 2021 01:50:52 +0100 (CET)
Subject: [Haskell-cafe] More Efficient Recursion
In-Reply-To: <CAOsti3m7baCAGRpYiNYEnBUq-m2pz_z3No_sb-ORv7gOPaZkqQ@mail.gmail.com>
References: <CAOsti3m7baCAGRpYiNYEnBUq-m2pz_z3No_sb-ORv7gOPaZkqQ@mail.gmail.com>
Message-ID: <37343e57-52ba-8926-d48b-4e626191ba55@henning-thielemann.de>


On Sat, 20 Feb 2021, A. Mc. wrote:

> Hello,
> I'm just starting off, but I'm wondering if anyone has any suggestions.  I've made a recursive function that's goal is to handle a
> base raised to a very large power.  
> modLoop :: Integer -> Integer -> Integer -> Integer -> Integer -> Integer
> modLoop iterator exponent result base modulus
>   | (iterator == exponent) = result
>    | (iterator < exponent) = modLoop (iterator + 1) (exponent) (mod (result * base) modulus) base modulus
>    | (iterator > exponent) = (-1)

Btw. what about:

   case compare iterator exponent of
      EQ ->
      LT ->
      GT -> ...

From frase at frase.id.au  Sun Feb 21 09:18:40 2021
From: frase at frase.id.au (Fraser Tweedale)
Date: Sun, 21 Feb 2021 19:18:40 +1000
Subject: [Haskell-cafe] dyre-0.9.0 release candidate and call for testing
Message-ID: <YDIlcF2LSPZ5gW0G@bacardi.hollandpark.frase.id.au>

Dyre is a tool for Haskell program configuration by (re)compilation.
After years of project dormancy, I am pleased to announce a Dyre 0.9
release candidate[1].  If you are interested and able to test this
candidate release, you can report results at [2].  For more details
including changelog, see the accompanying blog post[3].

[1] https://hackage.haskell.org/package/dyre-0.9.0/candidate
[2] https://github.com/willdonnelly/dyre/issues/39
[3] https://frasertweedale.github.io/blog-fp/posts/2021-02-21-dyre-0.9-rc.html

Thanks,
Fraser

From leah at vuxu.org  Sun Feb 21 15:20:36 2021
From: leah at vuxu.org (Leah Neukirchen)
Date: Sun, 21 Feb 2021 16:20:36 +0100
Subject: [Haskell-cafe] Munich Virtual Haskell Meeting, 2021-02-23 @ 19:30
Message-ID: <874ki5bg6z.fsf@vuxu.org>

Dear all,

Next week, our monthly Munich Haskell Meeting will take place again on
Tuesday, Feburary 23 on Google Meet at 19:30 CET.

**Due to meetup limitations in Bavaria, this meeting will take place online!**

For details see here:

https://muenchen.haskell.bayern/dates.html

A Google Meet link to join the room is provided on the page.

Everybody is welcome, especially the Haskellers from Bavaria that do
not usually come to our Munich meetings due to travel distance!

cu,
-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/

From matteo at confscience.com  Sun Feb 21 16:30:23 2021
From: matteo at confscience.com (matteo at confscience.com)
Date: Sun, 21 Feb 2021 17:30:23 +0100
Subject: [Haskell-cafe] International Conference on Applied Data Science and
	Intelligence - (ADSI 2021) Prague
Message-ID: <004c01d7086e$dabe7a60$903b6f20$@confscience.com>

Call for papers

************************************************* 

International Conference on Applied Data Science and Intelligence - (ADSI 2021) 

Prague- Czech Republic, October 14-15, 2021

https://confscience.com/adsi/  

Submission deadline: April 1, 2021

All papers accepted in ADSI 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: April 1, 2021

- Acceptance Notification: July 1, 2021

- Final Manuscript Due: September 1, 2021

***************************************************************************

The ADSI 2021 conference will be held in Conjunction with: 

International Conference on Recent Theories and Applications in Transportation and Mobility (RTATM 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

- Theoretical Models

- Spatial and temporal multi-models

- Multi-dimensional data

- Data acquisition and pre-processing

- Data inference

- Data Classification and Taxonomy

- Data Metrics

- New approaches for collaboration and competition

- Self-organization, self-healing, fault-tolerance approaches

- Spatial reasoning

- Context awareness

- Intelligent mobility

- New approaches to supervised and unsupervised learning

- New approaches for security, privacy, trust, and ethics in data science

- Real-time data analytics

- Multi-Agent Systems for data science

- Distributed data analytics

- Data authenticity

- New theories and approaches for Deep learning

- New approaches for Business Intelligence

- Fuzzy logic

- Decision trees

- Support vector machines

- Evolutionary computation

- Statistical methods

- Collaborative filtering

- Data engineering

- Content mining

- Indexing schemes

- Information retrieval

- Metadata use and management

INTELLIGENT DATA PROCESSING AND ANALYTICS 

- Multi-level data processing

- Data analytics optimization

- Smart data mining

- Machine Learning

- Deep Learning

- Bio-Inspired Computing

- Secure data analytics

- Privacy in data analytics

- Trust in Big Data

- Business intelligence

- Visualization Analytics

- Intelligence as a Service (IaaS)

- Data Science as a Service (DSaaS)

- Natural Language Processing

- Signal Processing

- Simulation and Modeling

- Data-Intensive Computing

SYSTEMS AND INFRASTRUCTURES 

- Data storage infrastructure

- Data warehouses

- Data Query and Indexing Technologies

- Software Defined Infrastructures 

- Software Defined Networks (SDN)

- Distributed data systems

- Smart grid computing

- Intelligent data management

- Big Data computing

- Smart data networking  

- Internet of Things

- Cyber Physical Systems

- Blockchain

- Fog and Edge intelligence

- Parallel Computing systems  

- Open Source systems for data science

- Embedded intelligence

- Embedded data science

- In-Memory computing 

- Intelligent drones

- Internet of Drones

- Real-time data acquisition systems

APPLICATIONS

- Intelligent Hazard management

- Intelligent data science in healthcare

- Intelligent data science in farming

- Intelligent data science in Oil and Gas

- Smart logistics 

- Intelligent data science in transportation

- Intelligent data science in surveillance

- Xtech (Fintech, Agritech, etc.)

- Intelligent drones

- Digital transformation

- Bioinformatics

- Marketing

- Social Science

- E-learning and E-services

 

***************************************************************************

OUTSTANDING PAPERS:

Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. 

*************************************************************************** 

PAPER SUBMISSION: 

Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=adsi2021). 

All papers will be peer reviewed. 

Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page)

Length of Short papers: less than 12 pages 

For more information, please refer to the conference website: https://confscience.com/adsi/    

 

***************************************************************************

CONTACT 

For more information, please send an email to info-adsi at confscience.com  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210221/5a1d7954/attachment.html>

From emilypi at cohomolo.gy  Sun Feb 21 18:34:05 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Sun, 21 Feb 2021 18:34:05 +0000
Subject: [Haskell-cafe] [ANN] zlib-0.6.2.3
Message-ID: <klfhmof3.9a0ed089-0791-4d87-8998-909ff78868b2@we.are.superhuman.com>

Hello Everyone,

I'm pleased to announce zlib-0.6.2.3, which adds support for the bytestring-0.11 work, and unblocks a decent number of packages to the next bytestring versions. I would also like to announce that two new maintainers have been added to the zlib team: Andrew Lelechenko (bodigrim), and myself (topos).

Cheers,

Emily
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210221/d6f5645d/attachment.html>

From ben.franksen at online.de  Mon Feb 22 08:57:12 2021
From: ben.franksen at online.de (Ben Franksen)
Date: Mon, 22 Feb 2021 09:57:12 +0100
Subject: [Haskell-cafe] International Conference on Applied Data Science
 and Intelligence - (ADSI 2021) Prague
In-Reply-To: <004c01d7086e$dabe7a60$903b6f20$@confscience.com>
References: <004c01d7086e$dabe7a60$903b6f20$@confscience.com>
Message-ID: <s0vrl8$99p$1@ciao.gmane.io>

Dear list maintainers

I would like to renew my request to block this fake conference spammer.
This sort of business is disgusting and offensive.

Thanks
Ben

Am 21.02.21 um 17:30 schrieb matteo at confscience.com:
> Call for papers
> 
> ************************************************* 
> 
> International Conference on Applied Data Science and Intelligence - (ADSI 2021) 
> 
> Prague- Czech Republic, October 14-15, 2021
> 
> https://confscience.com/adsi/  
> 
> Submission deadline: April 1, 2021
> 
> All papers accepted in ADSI 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: April 1, 2021
> 
> - Acceptance Notification: July 1, 2021
> 
> - Final Manuscript Due: September 1, 2021
> 
> ***************************************************************************
> 
> The ADSI 2021 conference will be held in Conjunction with: 
> 
> International Conference on Recent Theories and Applications in Transportation and Mobility (RTATM 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
> 
> - Theoretical Models
> 
> - Spatial and temporal multi-models
> 
> - Multi-dimensional data
> 
> - Data acquisition and pre-processing
> 
> - Data inference
> 
> - Data Classification and Taxonomy
> 
> - Data Metrics
> 
> - New approaches for collaboration and competition
> 
> - Self-organization, self-healing, fault-tolerance approaches
> 
> - Spatial reasoning
> 
> - Context awareness
> 
> - Intelligent mobility
> 
> - New approaches to supervised and unsupervised learning
> 
> - New approaches for security, privacy, trust, and ethics in data science
> 
> - Real-time data analytics
> 
> - Multi-Agent Systems for data science
> 
> - Distributed data analytics
> 
> - Data authenticity
> 
> - New theories and approaches for Deep learning
> 
> - New approaches for Business Intelligence
> 
> - Fuzzy logic
> 
> - Decision trees
> 
> - Support vector machines
> 
> - Evolutionary computation
> 
> - Statistical methods
> 
> - Collaborative filtering
> 
> - Data engineering
> 
> - Content mining
> 
> - Indexing schemes
> 
> - Information retrieval
> 
> - Metadata use and management
> 
> INTELLIGENT DATA PROCESSING AND ANALYTICS 
> 
> - Multi-level data processing
> 
> - Data analytics optimization
> 
> - Smart data mining
> 
> - Machine Learning
> 
> - Deep Learning
> 
> - Bio-Inspired Computing
> 
> - Secure data analytics
> 
> - Privacy in data analytics
> 
> - Trust in Big Data
> 
> - Business intelligence
> 
> - Visualization Analytics
> 
> - Intelligence as a Service (IaaS)
> 
> - Data Science as a Service (DSaaS)
> 
> - Natural Language Processing
> 
> - Signal Processing
> 
> - Simulation and Modeling
> 
> - Data-Intensive Computing
> 
> SYSTEMS AND INFRASTRUCTURES 
> 
> - Data storage infrastructure
> 
> - Data warehouses
> 
> - Data Query and Indexing Technologies
> 
> - Software Defined Infrastructures 
> 
> - Software Defined Networks (SDN)
> 
> - Distributed data systems
> 
> - Smart grid computing
> 
> - Intelligent data management
> 
> - Big Data computing
> 
> - Smart data networking  
> 
> - Internet of Things
> 
> - Cyber Physical Systems
> 
> - Blockchain
> 
> - Fog and Edge intelligence
> 
> - Parallel Computing systems  
> 
> - Open Source systems for data science
> 
> - Embedded intelligence
> 
> - Embedded data science
> 
> - In-Memory computing 
> 
> - Intelligent drones
> 
> - Internet of Drones
> 
> - Real-time data acquisition systems
> 
> APPLICATIONS
> 
> - Intelligent Hazard management
> 
> - Intelligent data science in healthcare
> 
> - Intelligent data science in farming
> 
> - Intelligent data science in Oil and Gas
> 
> - Smart logistics 
> 
> - Intelligent data science in transportation
> 
> - Intelligent data science in surveillance
> 
> - Xtech (Fintech, Agritech, etc.)
> 
> - Intelligent drones
> 
> - Digital transformation
> 
> - Bioinformatics
> 
> - Marketing
> 
> - Social Science
> 
> - E-learning and E-services
> 
>  
> 
> ***************************************************************************
> 
> OUTSTANDING PAPERS:
> 
> Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. 
> 
> *************************************************************************** 
> 
> PAPER SUBMISSION: 
> 
> Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=adsi2021). 
> 
> All papers will be peer reviewed. 
> 
> Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page)
> 
> Length of Short papers: less than 12 pages 
> 
> For more information, please refer to the conference website: https://confscience.com/adsi/    
> 
>  
> 
> ***************************************************************************
> 
> CONTACT 
> 
> For more information, please send an email to info-adsi at confscience.com  
> 
>  
> 
> 
> 
> _______________________________________________
> 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.
> 



From compl.yue at icloud.com  Mon Feb 22 14:24:20 2021
From: compl.yue at icloud.com (YueCompl)
Date: Mon, 22 Feb 2021 22:24:20 +0800
Subject: [Haskell-cafe] Cabal 3.2.0.0, run okay with profiling enabled,
 but installed exe NO profiling enabled
Message-ID: <B5A2CF0B-7FD6-44A9-B976-3C822B98E8E9@icloud.com>

Dear Cafe,

I'm not sure it is a bug or just designed behavior? But I can't install profiling-enabled exe with cabal 3.2.0.0, while direct running works correctly.

$ cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library 
$ cabal run --enable-profiling --enable-executable-profiling  exe:els -- +RTS --info
Up to date
 [("GHC RTS", "YES")
 ,("GHC version", "8.8.4")
 ,("RTS way", "rts_thr_p")
 ,("Build platform", "x86_64-apple-darwin")
 ,("Build architecture", "x86_64")
 ,("Build OS", "darwin")
 ,("Build vendor", "apple")
 ,("Host platform", "x86_64-apple-darwin")
 ,("Host architecture", "x86_64")
 ,("Host OS", "darwin")
 ,("Host vendor", "apple")
 ,("Target platform", "x86_64-apple-darwin")
 ,("Target architecture", "x86_64")
 ,("Target OS", "darwin")
 ,("Target vendor", "apple")
 ,("Word size", "64")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ,("Flag -with-rtsopts", "-maxN31 -qg")
 ]
$ cabal install --enable-profiling --overwrite-policy=always --enable-executable-profiling exe:els && els +RTS --info 
Wrote tarball sdist to
 ...
Resolving dependencies...
Up to date
Copying 'els'
 [("GHC RTS", "YES")
 ,("GHC version", "8.8.4")
 ,("RTS way", "rts_thr")
 ,("Build platform", "x86_64-apple-darwin")
 ,("Build architecture", "x86_64")
 ,("Build OS", "darwin")
 ,("Build vendor", "apple")
 ,("Host platform", "x86_64-apple-darwin")
 ,("Host architecture", "x86_64")
 ,("Host OS", "darwin")
 ,("Host vendor", "apple")
 ,("Target platform", "x86_64-apple-darwin")
 ,("Target architecture", "x86_64")
 ,("Target OS", "darwin")
 ,("Target vendor", "apple")
 ,("Word size", "64")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ,("Flag -with-rtsopts", "-maxN31 -qg")
 ]
$ cabal install --enable-profiling --overwrite-policy=always --enable-executable-profiling exe:els && els +RTS -p    
Wrote tarball sdist to
 ...
Resolving dependencies...
Up to date
Copying 'els'
els: the flag -p requires the program to be built with -prof
els: 
els: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
els: ...

Is there other options to get a profiling enabled exe installed?

Thanks with regards,
Compl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210222/3cc6ca87/attachment.html>

From Juan.Casanova at ed.ac.uk  Tue Feb 23 18:14:59 2021
From: Juan.Casanova at ed.ac.uk (CASANOVA Juan)
Date: Tue, 23 Feb 2021 18:14:59 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
Message-ID: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>

Hello again, Haskell Cafe,

Here again with another doubt on how am I supposed to. This one should be fairly easier, I believe.

In short, I would like to have a functor type that can only be applied to certain type parameters. Why? Well, something like this:

module DatatypeContextsExample where

import Data.Map
import Data.Bifunctor

data Foo t = Foo (Map t t)

instance Functor Foo where
    fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))

This does not compile, because I am using toList and fromList, which require (Ord t). But I cannot really have Foo be a functor in this way without it. The thing is, every time I am going to use it, t is actually going to be Ord. But how do I tell Haskell to have this constraint?

DatatypeContexts seems to be the extension that allows this:

data Ord t => Foo t = Foo (Map t t)

But this has two issues. First, DatatypeContexts is deprecated. Second, more importantly, it still does not type check! It produces the exact same error, saying that Ord t could not be inferred. It should be inferred from the very fact that I am using the type Foo, but GHC does not seem to want to understand this.

I could also try with GADTs:

data Foo t where
    Foo :: Ord t => Map t t -> Foo t

But this still gives the same error on the fmap definition, stating it cannot use Foo without Ord. But I am pattern-matching against it, shouldn't that be enough to know that (Ord t) is going to hold? I don't understand it.

Is there anything simple I am missing? Any other simple way to achieve this? Any fundamental problem with what I am trying to do?

Thanks as usual,
Juan.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210223/caaa0b87/attachment.html>

From Juan.Casanova at ed.ac.uk  Tue Feb 23 18:21:23 2021
From: Juan.Casanova at ed.ac.uk (CASANOVA Juan)
Date: Tue, 23 Feb 2021 18:21:23 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
Message-ID: <DB7PR05MB5369A2B853EACF2DC23FE2FADF809@DB7PR05MB5369.eurprd05.prod.outlook.com>

Reply to myself:

I realized, with GADTs, it does assume Ord a, it's Ord b that fails. I can see how that cannot be derived from the context. Since Foo is only used for types with Ord, though, is there any way that I could let GHC know that this is going to be the case by definition.

(So basically, in a way that would make fmap not typecheck on Foo when trying to use a function (a -> b) where Ord b does not hold)

Sorry I did not realize this earlier.
________________________________
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of CASANOVA Juan <Juan.Casanova at ed.ac.uk>
Sent: 23 February 2021 18:14
To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
Subject: [Haskell-cafe] DatatypeContexts / alternative

Hello again, Haskell Cafe,

Here again with another doubt on how am I supposed to. This one should be fairly easier, I believe.

In short, I would like to have a functor type that can only be applied to certain type parameters. Why? Well, something like this:

module DatatypeContextsExample where

import Data.Map
import Data.Bifunctor

data Foo t = Foo (Map t t)

instance Functor Foo where
    fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))

This does not compile, because I am using toList and fromList, which require (Ord t). But I cannot really have Foo be a functor in this way without it. The thing is, every time I am going to use it, t is actually going to be Ord. But how do I tell Haskell to have this constraint?

DatatypeContexts seems to be the extension that allows this:

data Ord t => Foo t = Foo (Map t t)

But this has two issues. First, DatatypeContexts is deprecated. Second, more importantly, it still does not type check! It produces the exact same error, saying that Ord t could not be inferred. It should be inferred from the very fact that I am using the type Foo, but GHC does not seem to want to understand this.

I could also try with GADTs:

data Foo t where
    Foo :: Ord t => Map t t -> Foo t

But this still gives the same error on the fmap definition, stating it cannot use Foo without Ord. But I am pattern-matching against it, shouldn't that be enough to know that (Ord t) is going to hold? I don't understand it.

Is there anything simple I am missing? Any other simple way to achieve this? Any fundamental problem with what I am trying to do?

Thanks as usual,
Juan.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210223/197efcc1/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Tue Feb 23 18:29:47 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 23 Feb 2021 18:29:47 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
Message-ID: <20210223182947.GB6186@cloudinit-builder>

On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
> module DatatypeContextsExample where
> 
> import Data.Map
> import Data.Bifunctor
> 
> data Foo t = Foo (Map t t)
> 
> instance Functor Foo where
>     fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))
> 
> This does not compile, because I am using toList and fromList, which
> require (Ord t). But I cannot really have Foo be a functor in this
> way without it. The thing is, every time I am going to use it, t is
> actually going to be Ord. But how do I tell Haskell to have this
> constraint?

You say that every time you are going to use it t is actually going to
be Ord, but how does the compiler know that when it comes to type
check fmap?  After all, somewhere else you could write

    fmap (const getLine) :: Foo t -> Foo (IO String)

and  IO String  is certainly not Ord.

Tom

From ietf-dane at dukhovni.org  Tue Feb 23 18:33:53 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 23 Feb 2021 13:33:53 -0500
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <DB7PR05MB5369A2B853EACF2DC23FE2FADF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <DB7PR05MB5369A2B853EACF2DC23FE2FADF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
Message-ID: <YDVKkWmR+p8xfqoW@straasha.imrryr.org>

On Tue, Feb 23, 2021 at 06:21:23PM +0000, CASANOVA Juan wrote:

> I realized, with GADTs, it does assume Ord a, it's Ord b that fails. I
> can see how that cannot be derived from the context. Since Foo is only
> used for types with Ord, though, is there any way that I could let GHC
> know that this is going to be the case by definition.

This is NOT a GHC issue, this is a library issue.  To be a "Functor", a
data structure MUST accept values of any type.  This is essential in
Monads, where we, e.g., expect "return" to be able to return any value.

It seems you want to work with the endo-functors of a sub-category of
"Hask", so perhaps:

    https://hackage.haskell.org/package/constrained-category-0.1.0.0/docs/Data-Functor-Constrained.html

but then of course, you have to limit yourself to functions
that work within that category, so the standard "fmap" is
not available, standard Monads are not available, ...

-- 
    Viktor.

From Juan.Casanova at ed.ac.uk  Tue Feb 23 18:37:06 2021
From: Juan.Casanova at ed.ac.uk (CASANOVA Juan)
Date: Tue, 23 Feb 2021 18:37:06 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <20210223182947.GB6186@cloudinit-builder>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>,
 <20210223182947.GB6186@cloudinit-builder>
Message-ID: <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>

Tom,

Yes I realize that, but what I am expecting, I guess, is for the type checker to tell me (or anyone who tried to use it) that Foo (IO String) makes no sense, because Foo is always applied to something with Ord. That the very concept of the type Foo (IO String) itself does not type check.

I realize the answer might be that this is impossible with current Haskell, but then a) Is there any fundamental reason why it is impossible, like it would never be possible to do this, or is it just a feature that is not clear how to implement in GHC? and b) The basic problem that I have: Implementing an fmap for something like Foo. Can I really just not do it in any way or shape, with any form of workaround?

So far what I have been doing with situation similar to this is to just create the function fmap_foo that does what fmap does, with the proper constraints. But this is not enough when later on I want to use some other function that requires Foo to actually implement Functor. It would basically mean I have to re-implement all the structure while adding all the additional "Ord" constraints.

Thanks,
Juan.


________________________________
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
Sent: 23 February 2021 18:29
To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] DatatypeContexts / alternative

This email was sent to you by someone outside the University.
You should only click on links or attachments if you are certain that the email is genuine and the content is safe.

On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
> module DatatypeContextsExample where
>
> import Data.Map
> import Data.Bifunctor
>
> data Foo t = Foo (Map t t)
>
> instance Functor Foo where
>     fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))
>
> This does not compile, because I am using toList and fromList, which
> require (Ord t). But I cannot really have Foo be a functor in this
> way without it. The thing is, every time I am going to use it, t is
> actually going to be Ord. But how do I tell Haskell to have this
> constraint?

You say that every time you are going to use it t is actually going to
be Ord, but how does the compiler know that when it comes to type
check fmap?  After all, somewhere else you could write

    fmap (const getLine) :: Foo t -> Foo (IO String)

and  IO String  is certainly not Ord.

Tom
_______________________________________________
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.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210223/fdae62f1/attachment.html>

From rae at richarde.dev  Tue Feb 23 19:07:27 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 23 Feb 2021 19:07:27 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
Message-ID: <010f0177d04a01ec-cdcf65f0-b70d-4344-ad2b-8ccc0de7b29f-000000@us-east-2.amazonses.com>

Hi café,

You might be interested in my recent paper on exactly this problem: how to make DatatypeContexts actually work the way you want: https://richarde.dev/papers/2020/partialdata/partialdata.pdf <https://richarde.dev/papers/2020/partialdata/partialdata.pdf>. Sections 1-3 and 6 onwards should be approachable with only a Haskell background (but not, say, type theory). (Section 4 gives details about the design, but these details are broadly inferrable from the other sections. Section 5 is a proof that the idea is sound; you can just take this on faith.)

There are, sadly, no plans to implement this paper, because the interactions with other GHC features means that implementing this would require dependent types. But perhaps with dependent types, we'll choose to go in this direction. In my role as a GHC Steering Committee member, I'm leery of proposals which would bring GHC further from the ideal expressed in this paper.

Richard

> On Feb 23, 2021, at 1:37 PM, CASANOVA Juan <Juan.Casanova at ed.ac.uk> wrote:
> 
> Tom,
> 
> Yes I realize that, but what I am expecting, I guess, is for the type checker to tell me (or anyone who tried to use it) that Foo (IO String) makes no sense, because Foo is always applied to something with Ord. That the very concept of the type Foo (IO String) itself does not type check.
> 
> I realize the answer might be that this is impossible with current Haskell, but then a) Is there any fundamental reason why it is impossible, like it would never be possible to do this, or is it just a feature that is not clear how to implement in GHC? and b) The basic problem that I have: Implementing an fmap for something like Foo. Can I really just not do it in any way or shape, with any form of workaround?
> 
> So far what I have been doing with situation similar to this is to just create the function fmap_foo that does what fmap does, with the proper constraints. But this is not enough when later on I want to use some other function that requires Foo to actually implement Functor. It would basically mean I have to re-implement all the structure while adding all the additional "Ord" constraints.
> 
> Thanks,
> Juan.
> 
> 
> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org <mailto:haskell-cafe-bounces at haskell.org>> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk <mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>>
> Sent: 23 February 2021 18:29
> To: haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org> <haskell-cafe at haskell.org <mailto:haskell-cafe at haskell.org>>
> Subject: Re: [Haskell-cafe] DatatypeContexts / alternative
>  
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
> 
> On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
> > module DatatypeContextsExample where
> >
> > import Data.Map
> > import Data.Bifunctor
> >
> > data Foo t = Foo (Map t t)
> >
> > instance Functor Foo where
> >     fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))
> >
> > This does not compile, because I am using toList and fromList, which
> > require (Ord t). But I cannot really have Foo be a functor in this
> > way without it. The thing is, every time I am going to use it, t is
> > actually going to be Ord. But how do I tell Haskell to have this
> > constraint?
> 
> You say that every time you are going to use it t is actually going to
> be Ord, but how does the compiler know that when it comes to type
> check fmap?  After all, somewhere else you could write
> 
>     fmap (const getLine) :: Foo t -> Foo (IO String)
> 
> and  IO String  is certainly not Ord.
> 
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> Only members subscribed via the mailman list are allowed to post.
> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336. _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210223/71bb21d1/attachment.html>

From trebla at vex.net  Tue Feb 23 19:25:10 2021
From: trebla at vex.net (Albert Y. C. Lai)
Date: Tue, 23 Feb 2021 14:25:10 -0500
Subject: [Haskell-cafe] Cabal 3.2.0.0, run okay with profiling enabled,
 but installed exe NO profiling enabled
In-Reply-To: <B5A2CF0B-7FD6-44A9-B976-3C822B98E8E9@icloud.com>
References: <B5A2CF0B-7FD6-44A9-B976-3C822B98E8E9@icloud.com>
Message-ID: <9f1a811a-e22f-4ec8-2453-78d68b13aab3@vex.net>

3.4.0.0 does the same. I am not sure whether it is a bug or a feature.

Workaround: Write a cabal.project file that goes like:

packages: .

package *
   profiling: True

https://cabal.readthedocs.io/en/3.4/cabal-project.html has every 
variation and fine-tuning.


On 2021-02-22 9:24 a.m., YueCompl via Haskell-Cafe wrote:
> Dear Cafe,
> 
> I'm not sure it is a bug or just designed behavior? But I can't install 
> profiling-enabled exe with cabal 3.2.0.0, while direct running works 
> correctly.
> 
> $ cabal --version
> cabal-install version 3.2.0.0
> compiled using version 3.2.0.0 of the Cabal library
> $cabal run --enable-profiling --enable-executable-profiling  exe:els -- 
> +RTS --info
> Up to date
>   [("GHC RTS", "YES")
>   ,("GHC version", "8.8.4")
>   ,("RTS way", "rts_thr_p")
>   ,("Build platform", "x86_64-apple-darwin")
>   ,("Build architecture", "x86_64")
>   ,("Build OS", "darwin")
>   ,("Build vendor", "apple")
>   ,("Host platform", "x86_64-apple-darwin")
>   ,("Host architecture", "x86_64")
>   ,("Host OS", "darwin")
>   ,("Host vendor", "apple")
>   ,("Target platform", "x86_64-apple-darwin")
>   ,("Target architecture", "x86_64")
>   ,("Target OS", "darwin")
>   ,("Target vendor", "apple")
>   ,("Word size", "64")
>   ,("Compiler unregisterised", "NO")
>   ,("Tables next to code", "YES")
>   ,("Flag -with-rtsopts", "-maxN31 -qg")
>   ]
> $cabal install --enable-profiling --overwrite-policy=always 
> --enable-executable-profiling exe:els && els +RTS --info
> Wrote tarball sdist to
>   ...
> Resolving dependencies...
> Up to date
> Copying 'els'
>   [("GHC RTS", "YES")
>   ,("GHC version", "8.8.4")
>   ,("RTS way", "rts_thr")
>   ,("Build platform", "x86_64-apple-darwin")
>   ,("Build architecture", "x86_64")
>   ,("Build OS", "darwin")
>   ,("Build vendor", "apple")
>   ,("Host platform", "x86_64-apple-darwin")
>   ,("Host architecture", "x86_64")
>   ,("Host OS", "darwin")
>   ,("Host vendor", "apple")
>   ,("Target platform", "x86_64-apple-darwin")
>   ,("Target architecture", "x86_64")
>   ,("Target OS", "darwin")
>   ,("Target vendor", "apple")
>   ,("Word size", "64")
>   ,("Compiler unregisterised", "NO")
>   ,("Tables next to code", "YES")
>   ,("Flag -with-rtsopts", "-maxN31 -qg")
>   ]
> $ cabal install --enable-profiling --overwrite-policy=always 
> --enable-executable-profiling exe:els && els +RTS -p
> Wrote tarball sdist to
>   ...
> Resolving dependencies...
> Up to date
> Copying 'els'
> els: the flag -p requires the program to be built with -prof
> els:
> els: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
> els: ...
> 
> Is there other options to get a profiling enabled exe installed?
> 
> Thanks with regards,
> Compl
> 
> 
> _______________________________________________
> 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.
> 


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Tue Feb 23 19:27:15 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 23 Feb 2021 19:27:15 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
Message-ID: <20210223192715.GC6186@cloudinit-builder>

On Tue, Feb 23, 2021 at 06:37:06PM +0000, CASANOVA Juan wrote:
> Yes I realize that, but what I am expecting, I guess, is for the
> type checker to tell me (or anyone who tried to use it) that Foo (IO
> String) makes no sense, because Foo is always applied to something
> with Ord. That the very concept of the type Foo (IO String) itself
> does not type check.
> 
> I realize the answer might be that this is impossible with current
> Haskell, but then a) Is there any fundamental reason why it is
> impossible

Yes, there's a fundamental reason.  Neither you nor the compiler can
possibly know when invalid Foos (i.e. those whose parameter isn't Ord)
are constructed inside a function polymorphic in a  Functor . Let's
extend my example.

    mapToUnit :: Functor f => f a -> f ()
    mapToUnit = fmap (const ()) . fmap (const getLine)

    whatShouldItDo :: Foo ()
    whatShouldItDo = mapToUnit (Foo (Data.Map.singleton () ()))

Do you agree that  whatShouldItDo  is well typed?  If not, why not?
If so, how should it behave when evaluated?  The implementation of
 mapToUnit , combined with your  Functor  instance says that  fromList
must be run on  [(getLine, getLine)] .  But this is impossible!

Accepting that  whatShouldItDo  is well typed implies that you must
accept that your  Functor  instance for  Foo  cannot work.  (I don't
believe any instance can work if it is law-abiding but I don't know of
a proof.)

There is a cottage industry of trying to work around this problem.
See, for example [1].  I have never seen a satisfactory solution.

Based on your posts here you are frequently running into the limits of
type class based programming in Haskell.  If your purpose is practical
I strongly advise you to stay away from type classes for anything
non-trivial. Stick to the value level. Your life will be much
easier. If your purpose is research into type classes, or general
interest, then good luck and enjoy!

Tom


[1] https://jeltsch.wordpress.com/2015/09/03/constrained-monads/


> ________________________________
> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
> Sent: 23 February 2021 18:29
> To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] DatatypeContexts / alternative
> 
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
> 
> On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
> > module DatatypeContextsExample where
> >
> > import Data.Map
> > import Data.Bifunctor
> >
> > data Foo t = Foo (Map t t)
> >
> > instance Functor Foo where
> >     fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))
> >
> > This does not compile, because I am using toList and fromList, which
> > require (Ord t). But I cannot really have Foo be a functor in this
> > way without it. The thing is, every time I am going to use it, t is
> > actually going to be Ord. But how do I tell Haskell to have this
> > constraint?
> 
> You say that every time you are going to use it t is actually going to
> be Ord, but how does the compiler know that when it comes to type
> check fmap?  After all, somewhere else you could write
> 
>     fmap (const getLine) :: Foo t -> Foo (IO String)
> 
> and  IO String  is certainly not Ord.

From compl.yue at icloud.com  Tue Feb 23 19:57:02 2021
From: compl.yue at icloud.com (YueCompl)
Date: Wed, 24 Feb 2021 03:57:02 +0800
Subject: [Haskell-cafe] Cabal 3.2.0.0, run okay with profiling enabled,
 but installed exe NO profiling enabled
In-Reply-To: <9f1a811a-e22f-4ec8-2453-78d68b13aab3@vex.net>
References: <B5A2CF0B-7FD6-44A9-B976-3C822B98E8E9@icloud.com>
 <9f1a811a-e22f-4ec8-2453-78d68b13aab3@vex.net>
Message-ID: <E179BE56-F946-4A65-B695-4F48D2549060@icloud.com>

I'm using a multi-package project with `profiling: True` defined in cabal.project.local, and my cabal.project is generated by tools, so maybe this workaround doesn't work around 3.2.0.0?

```
$ cat cabal.project.local 

profiling: True
profiling-detail: all-functions

optimization: 0

$ cat cabal.project

-- Please change Cabal project settings per your needs

-- FOLLOWING CONTENTS GONNA BE OVERWRITTEN BY EPM --

--  * this file should be:
--  /fw/m3cyue/edh-universe/cabal.project

packages:
  ./e-wrks/edh/lossless-decimal/lossless-decimal.cabal
  ./e-wrks/edh/elr/elr.cabal
  ./e-wrks/edh/host.hs/edh.cabal
  ./e-wrks/nedh/host.hs/nedh.cabal
  ./e-wrks/sedh/host.hs/sedh.cabal
  ./e-wrks/hasdim/host.hs/hasdim.cabal
  ./e-wrks/haskit/host.hs/haskit.cabal
  ./e-wrks/els/host.hs/els.cabal
$ 
```

> On 2021-02-24, at 03:25, Albert Y. C. Lai <trebla at vex.net> wrote:
> 
> 3.4.0.0 does the same. I am not sure whether it is a bug or a feature.
> 
> Workaround: Write a cabal.project file that goes like:
> 
> packages: .
> 
> package *
>  profiling: True
> 
> https://cabal.readthedocs.io/en/3.4/cabal-project.html has every variation and fine-tuning.
> 
> 
> On 2021-02-22 9:24 a.m., YueCompl via Haskell-Cafe wrote:
>> Dear Cafe,
>> I'm not sure it is a bug or just designed behavior? But I can't install profiling-enabled exe with cabal 3.2.0.0, while direct running works correctly.
>> $ cabal --version
>> cabal-install version 3.2.0.0
>> compiled using version 3.2.0.0 of the Cabal library
>> $cabal run --enable-profiling --enable-executable-profiling  exe:els -- +RTS --info
>> Up to date
>>  [("GHC RTS", "YES")
>>  ,("GHC version", "8.8.4")
>>  ,("RTS way", "rts_thr_p")
>>  ,("Build platform", "x86_64-apple-darwin")
>>  ,("Build architecture", "x86_64")
>>  ,("Build OS", "darwin")
>>  ,("Build vendor", "apple")
>>  ,("Host platform", "x86_64-apple-darwin")
>>  ,("Host architecture", "x86_64")
>>  ,("Host OS", "darwin")
>>  ,("Host vendor", "apple")
>>  ,("Target platform", "x86_64-apple-darwin")
>>  ,("Target architecture", "x86_64")
>>  ,("Target OS", "darwin")
>>  ,("Target vendor", "apple")
>>  ,("Word size", "64")
>>  ,("Compiler unregisterised", "NO")
>>  ,("Tables next to code", "YES")
>>  ,("Flag -with-rtsopts", "-maxN31 -qg")
>>  ]
>> $cabal install --enable-profiling --overwrite-policy=always --enable-executable-profiling exe:els && els +RTS --info
>> Wrote tarball sdist to
>>  ...
>> Resolving dependencies...
>> Up to date
>> Copying 'els'
>>  [("GHC RTS", "YES")
>>  ,("GHC version", "8.8.4")
>>  ,("RTS way", "rts_thr")
>>  ,("Build platform", "x86_64-apple-darwin")
>>  ,("Build architecture", "x86_64")
>>  ,("Build OS", "darwin")
>>  ,("Build vendor", "apple")
>>  ,("Host platform", "x86_64-apple-darwin")
>>  ,("Host architecture", "x86_64")
>>  ,("Host OS", "darwin")
>>  ,("Host vendor", "apple")
>>  ,("Target platform", "x86_64-apple-darwin")
>>  ,("Target architecture", "x86_64")
>>  ,("Target OS", "darwin")
>>  ,("Target vendor", "apple")
>>  ,("Word size", "64")
>>  ,("Compiler unregisterised", "NO")
>>  ,("Tables next to code", "YES")
>>  ,("Flag -with-rtsopts", "-maxN31 -qg")
>>  ]
>> $ cabal install --enable-profiling --overwrite-policy=always --enable-executable-profiling exe:els && els +RTS -p
>> Wrote tarball sdist to
>>  ...
>> Resolving dependencies...
>> Up to date
>> Copying 'els'
>> els: the flag -p requires the program to be built with -prof
>> els:
>> els: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
>> els: ...
>> Is there other options to get a profiling enabled exe installed?
>> Thanks with regards,
>> Compl
>> _______________________________________________
>> 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-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.


From Juan.Casanova at ed.ac.uk  Tue Feb 23 20:09:21 2021
From: Juan.Casanova at ed.ac.uk (CASANOVA Juan)
Date: Tue, 23 Feb 2021 20:09:21 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <20210223192715.GC6186@cloudinit-builder>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>,
 <20210223192715.GC6186@cloudinit-builder>
Message-ID: <DB7PR05MB5369637AFDFD6A39159CA432DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>

Thanks Tom,

After the last email I sent, I was left thinking that the way in which this could be a problem was some generic Functor function that had intermediate values that could violate the constraints, but such that it's type signature respected it, but I didn't think much else on it. I think your example is exactly this: you use the getLine fmap inside the function, which is fine for a general Functor, but produces a temporary no-Ord functor, while the overall function preserves the signature.

And yeah, the only possible way to go around this would be to actually have additional "notes" on the signature of functions which said what it internally needed, which not only is horrendous but I believe crashes strongly against a lot of other things we do in Haskell (or any similar language for that matter)

So, yeah, I understand the issue.

To respond to your last comment. First, I realize this is not what you are saying, but please someone do let me know if at some point my posts feel excessive or out of place. I have a strong issue with both often not being able to tell the social context very well and also being very insecure about making a fool out of myself for that reason. Second, my situation is practical (my research is not on programming languages), but I cannot deny I like an elegant solution like most other people here probably do, so I often go a bit further than strictly necessary out of curiosity. This is not the case in this instance, though. This is still giving me problems and I still haven't found a satisfactory workaround for my particular problem, no matter how "dirty" it would be. I think I'll figure it out eventually, though. It seems to be just a matter of instantiating enough type variables to exactly what I want to use them for.

I do see your suggestion, one that I had considered myself; but it's more useful coming from someone who seems to know what they're doing better than me, so that if I end up deciding to avoid type classes for certain complex things I am more secure it's not just me being dumb, but rather that there be dragons that I don't want to fight. However, a practical issue with avoiding type classes tends to be that function signatures tend to become larger, larger and larger, making the code very very cluttered. So I think that's where the art comes, in finding the balance between those two things. A lot of my complex issues come from a sort-of obsession with making code as modular as possible. This is a long topic and I know it's not a "solvable" problem, but I try to push things as far as I can in that regard (within reason, I try).

Thanks again, this does respond everything I doubted about this particular issue.
Juan.
________________________________
From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
Sent: 23 February 2021 19:27
To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] DatatypeContexts / alternative

This email was sent to you by someone outside the University.
You should only click on links or attachments if you are certain that the email is genuine and the content is safe.

On Tue, Feb 23, 2021 at 06:37:06PM +0000, CASANOVA Juan wrote:
> Yes I realize that, but what I am expecting, I guess, is for the
> type checker to tell me (or anyone who tried to use it) that Foo (IO
> String) makes no sense, because Foo is always applied to something
> with Ord. That the very concept of the type Foo (IO String) itself
> does not type check.
>
> I realize the answer might be that this is impossible with current
> Haskell, but then a) Is there any fundamental reason why it is
> impossible

Yes, there's a fundamental reason.  Neither you nor the compiler can
possibly know when invalid Foos (i.e. those whose parameter isn't Ord)
are constructed inside a function polymorphic in a  Functor . Let's
extend my example.

    mapToUnit :: Functor f => f a -> f ()
    mapToUnit = fmap (const ()) . fmap (const getLine)

    whatShouldItDo :: Foo ()
    whatShouldItDo = mapToUnit (Foo (Data.Map.singleton () ()))

Do you agree that  whatShouldItDo  is well typed?  If not, why not?
If so, how should it behave when evaluated?  The implementation of
 mapToUnit , combined with your  Functor  instance says that  fromList
must be run on  [(getLine, getLine)] .  But this is impossible!

Accepting that  whatShouldItDo  is well typed implies that you must
accept that your  Functor  instance for  Foo  cannot work.  (I don't
believe any instance can work if it is law-abiding but I don't know of
a proof.)

There is a cottage industry of trying to work around this problem.
See, for example [1].  I have never seen a satisfactory solution.

Based on your posts here you are frequently running into the limits of
type class based programming in Haskell.  If your purpose is practical
I strongly advise you to stay away from type classes for anything
non-trivial. Stick to the value level. Your life will be much
easier. If your purpose is research into type classes, or general
interest, then good luck and enjoy!

Tom


[1] https://jeltsch.wordpress.com/2015/09/03/constrained-monads/


> ________________________________
> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
> Sent: 23 February 2021 18:29
> To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] DatatypeContexts / alternative
>
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
>
> On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
> > module DatatypeContextsExample where
> >
> > import Data.Map
> > import Data.Bifunctor
> >
> > data Foo t = Foo (Map t t)
> >
> > instance Functor Foo where
> >     fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))
> >
> > This does not compile, because I am using toList and fromList, which
> > require (Ord t). But I cannot really have Foo be a functor in this
> > way without it. The thing is, every time I am going to use it, t is
> > actually going to be Ord. But how do I tell Haskell to have this
> > constraint?
>
> You say that every time you are going to use it t is actually going to
> be Ord, but how does the compiler know that when it comes to type
> check fmap?  After all, somewhere else you could write
>
>     fmap (const getLine) :: Foo t -> Foo (IO String)
>
> and  IO String  is certainly not Ord.
_______________________________________________
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.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210223/162b997b/attachment-0001.html>

From emilypi at cohomolo.gy  Tue Feb 23 23:27:13 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Tue, 23 Feb 2021 23:27:13 +0000
Subject: [Haskell-cafe] [ANN] cabal-install-3.4.0.0
Message-ID: <klin1jrs.eaadd97f-9ecf-4a44-aa51-af15275ee580@we.are.superhuman.com>

The Cabal team is excited to announce the release of cabal-install 3.4. This is the third release of the 3.0 release series, bringing a support for the `Cabal-Version: 3.4` `.cabal` file format. This introduces a number of user-facing features including:

- Support for GHC 9.0

- Package sublibrary dependency syntax

- Allowing omission of the `default-language` declaration

- A mixins field allowing the user to specify a sublibrary

- [Many other features]( https://cabal.readthedocs.io/en/latest/file-format-changelog.html#cabal-version-3-4 )

In addition, the `cabal-install` frontend itself has gained a number of new features including:

- New `active-repositories` `cabal.project` fields allowing users to specify an order and various ways of combining package repositories

- Improvements to `cabal init`

- A rework of the `cabal v2-sdist` command. `cabal v1-sdist` is removed as of this version

- `source-repository-package` directories are no longer local

- A new `list-bin` command

- `cabal sandbox` is now removed in favor of default nix-style builds

- `cabal list` now accepts regular expressions

- More rich `index-state` syntax. `v2-freeze` saves `index-state`

I'd also like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help!

For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.4.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues.

Happy hacking!

Emily
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210223/c5a22867/attachment.html>

From guthrie at miu.edu  Wed Feb 24 04:23:36 2021
From: guthrie at miu.edu (Gregory Guthrie)
Date: Wed, 24 Feb 2021 04:23:36 +0000
Subject: [Haskell-cafe] [ANN] cabal-install-3.4.0.0
In-Reply-To: <klin1jrs.eaadd97f-9ecf-4a44-aa51-af15275ee580@we.are.superhuman.com>
References: <klin1jrs.eaadd97f-9ecf-4a44-aa51-af15275ee580@we.are.superhuman.com>
Message-ID: <DM6PR03MB4331988526EA069AE173E4C2A19F9@DM6PR03MB4331.namprd03.prod.outlook.com>

I am running cabal version 3.2.0.0,
Trying to update fails:

C:\Users\guthrie\Desktop>cabal new-install Cabal cabal-install
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: Cabal-3.4.0.0 (user goal)
[__1] trying: time-1.9.3/installed-1.9.3 (dependency of Cabal)
[__2] trying: process-1.6.9.0/installed-1.6.9.0 (dependency of Cabal)
[__3] trying: pretty-1.1.3.6/installed-1.1.3.6 (dependency of Cabal)
[__4] trying: directory-1.3.6.0/installed-1.3.6.0 (dependency of Cabal)
[__5] trying: base-4.14.1.0/installed-4.14.1.0 (dependency of Cabal)
[__6] trying: cabal-install-3.4.0.0 (user goal)
[__7] trying: cabal-install:+native-dns
[__8] next goal: windns (dependency of cabal-install +native-dns)
[__8] rejecting: windns-0.1.0.1 (conflict: time =>
base==4.14.1.0/installed-4.14.1.0, windns => base>=4.5.1.0 && <4.14)
[__8] rejecting: windns-0.1.0.0 (conflict: time =>
base==4.14.1.0/installed-4.14.1.0, windns => base>=4.8 && <4.13)
[__8] fail (backjumping, conflict set: cabal-install, time, windns,
cabal-install:native-dns)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: cabal-install, Cabal, base, HTTP,
directory, process, time, template-haskell, network, pretty, Cabal:setup.base,
hackage-security, windns, cabal-install:native-dns, cabal-install:lib
Try running with --minimize-conflict-set to improve the error message.

???


From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> On Behalf Of Emily Pillmore
Sent: Tuesday, February 23, 2021 5:27 PM
To: haskell-cafe at haskell.org
Subject: [Haskell-cafe] [ANN] cabal-install-3.4.0.0

The Cabal team is excited to announce the release of cabal-install 3.4. This is the third release of the 3.0 release series, bringing a support for the `Cabal-Version: 3.4` `.cabal` file format. This introduces a number of user-facing features including:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210224/e1ddd5a2/attachment.html>

From emilypi at cohomolo.gy  Wed Feb 24 05:14:41 2021
From: emilypi at cohomolo.gy (Emily Pillmore)
Date: Wed, 24 Feb 2021 05:14:41 +0000
Subject: [Haskell-cafe] [ANN] cabal-install-3.4.0.0
In-Reply-To: <DM6PR03MB4331988526EA069AE173E4C2A19F9@DM6PR03MB4331.namprd03.prod.outlook.com>
References: <klin1jrs.eaadd97f-9ecf-4a44-aa51-af15275ee580@we.are.superhuman.com>
 <DM6PR03MB4331988526EA069AE173E4C2A19F9@DM6PR03MB4331.namprd03.prod.outlook.com>
Message-ID: <klizf881.1abd8bcc-8d47-474f-a6f1-4180c88f2080@we.are.superhuman.com>

Hi Gregory,

It looks like `windns` needs a base bounds bump to accommodate GHC 8.10.x (see: https://github.com/haskell-hvr/windns/issues/1 ). I'll file an issue with the Hackage Trustees and we'll get this resolved.

Cheers,

Emily

On Tue, Feb 23, 2021 at 11:23 PM, Gregory Guthrie < guthrie at miu.edu > wrote:

> 
> 
> 
> I am running cabal version 3.2.0.0,
> 
> 
> 
> Trying to update fails:
> 
> 
> 
> 
> 
> 
> 
> C:\Users\guthrie\Desktop>cabal new-install Cabal cabal-install
> 
> 
> 
> Resolving dependencies...
> 
> 
> 
> cabal: Could not resolve dependencies:
> 
> 
> 
> [__0] trying: Cabal-3.4.0.0 (user goal)
> 
> 
> 
> [__1] trying: time-1.9.3/installed-1.9.3 (dependency of Cabal)
> 
> 
> 
> [__2] trying: process-1.6.9.0/installed-1.6.9.0 (dependency of Cabal)
> 
> 
> 
> [__3] trying: pretty-1.1.3.6/installed-1.1.3.6 (dependency of Cabal)
> 
> 
> 
> [__4] trying: directory-1.3.6.0/installed-1.3.6.0 (dependency of Cabal)
> 
> 
> 
> [__5] trying: base-4.14.1.0/installed-4.14.1.0 (dependency of Cabal)
> 
> 
> 
> [__6] trying: cabal-install-3.4.0.0 (user goal)
> 
> 
> 
> [__7] trying: cabal-install:+native-dns
> 
> 
> 
> [__8] next goal: windns (dependency of cabal-install +native-dns)
> 
> 
> 
> [__8] rejecting: windns-0.1.0.1 (conflict: time =>
> 
> 
> 
> base==4.14.1.0/installed-4.14.1.0, windns => base>=4.5.1.0 && <4.14)
> 
> 
> 
> [__8] rejecting: windns-0.1.0.0 (conflict: time =>
> 
> 
> 
> base==4.14.1.0/installed-4.14.1.0, windns => base>=4.8 && <4.13)
> 
> 
> 
> [__8] fail (backjumping, conflict set: cabal-install, time, windns,
> 
> 
> 
> cabal-install:native-dns)
> 
> 
> 
> After searching the rest of the dependency tree exhaustively, these were
> the
> 
> 
> 
> goals I've had most trouble fulfilling: cabal-install, Cabal, base, HTTP,
> 
> 
> 
> directory, process, time, template-haskell, network, pretty,
> Cabal:setup.base,
> 
> 
> 
> hackage-security, windns, cabal-install:native-dns, cabal-install:lib
> 
> 
> 
> Try running with --minimize-conflict-set to improve the error message.
> 
> 
> 
> 
> 
> 
> 
> ???
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *From:* Haskell-Cafe < haskell-cafe-bounces@ haskell. org (
> haskell-cafe-bounces at haskell.org ) > *On Behalf Of* Emily Pillmore
> *Sent:* Tuesday, February 23, 2021 5:27 PM
> *To:* haskell-cafe@ haskell. org ( haskell-cafe at haskell.org )
> *Subject:* [Haskell-cafe] [ANN] cabal-install-3.4.0.0
> 
> 
> 
> 
> 
> 
> 
> 
> The Cabal team is excited to announce the release of cabal-install 3.4.
> This is the third release of the 3.0 release series, bringing a support
> for the `Cabal-Version: 3.4` `.cabal` file format. This introduces a
> number of user-facing features including:
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210224/f6a4e075/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Feb 24 10:17:48 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 24 Feb 2021 10:17:48 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <DB7PR05MB5369637AFDFD6A39159CA432DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223192715.GC6186@cloudinit-builder>
 <DB7PR05MB5369637AFDFD6A39159CA432DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
Message-ID: <20210224101748.GD6186@cloudinit-builder>

On Tue, Feb 23, 2021 at 08:09:21PM +0000, CASANOVA Juan wrote:
> please someone do let me know if at some point my posts feel
> excessive or out of place.

I think your questions are perfectly reasonable for this list and many
people here, including me, will enjoy thinking about them and
answering them. My suggestion is purely to point out that, in
practical terms, there are probably much more direct and simple routes
to achieving your goal.  It is a rare problem that gets simpler by the
addition of type classes. That being said, there's also a lot of value
in deeply exploring different approaches even if they don't turn out
to be practical in the end.

Tom 


> ________________________________
> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
> Sent: 23 February 2021 19:27
> To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
> Subject: Re: [Haskell-cafe] DatatypeContexts / alternative
> 
> This email was sent to you by someone outside the University.
> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
> 
> On Tue, Feb 23, 2021 at 06:37:06PM +0000, CASANOVA Juan wrote:
> > Yes I realize that, but what I am expecting, I guess, is for the
> > type checker to tell me (or anyone who tried to use it) that Foo (IO
> > String) makes no sense, because Foo is always applied to something
> > with Ord. That the very concept of the type Foo (IO String) itself
> > does not type check.
> >
> > I realize the answer might be that this is impossible with current
> > Haskell, but then a) Is there any fundamental reason why it is
> > impossible
> 
> Yes, there's a fundamental reason.  Neither you nor the compiler can
> possibly know when invalid Foos (i.e. those whose parameter isn't Ord)
> are constructed inside a function polymorphic in a  Functor . Let's
> extend my example.
> 
>     mapToUnit :: Functor f => f a -> f ()
>     mapToUnit = fmap (const ()) . fmap (const getLine)
> 
>     whatShouldItDo :: Foo ()
>     whatShouldItDo = mapToUnit (Foo (Data.Map.singleton () ()))
> 
> Do you agree that  whatShouldItDo  is well typed?  If not, why not?
> If so, how should it behave when evaluated?  The implementation of
>  mapToUnit , combined with your  Functor  instance says that  fromList
> must be run on  [(getLine, getLine)] .  But this is impossible!
> 
> Accepting that  whatShouldItDo  is well typed implies that you must
> accept that your  Functor  instance for  Foo  cannot work.  (I don't
> believe any instance can work if it is law-abiding but I don't know of
> a proof.)
> 
> There is a cottage industry of trying to work around this problem.
> See, for example [1].  I have never seen a satisfactory solution.
> 
> Based on your posts here you are frequently running into the limits of
> type class based programming in Haskell.  If your purpose is practical
> I strongly advise you to stay away from type classes for anything
> non-trivial. Stick to the value level. Your life will be much
> easier. If your purpose is research into type classes, or general
> interest, then good luck and enjoy!
> 
> Tom
> 
> 
> [1] https://jeltsch.wordpress.com/2015/09/03/constrained-monads/
> 
> 
> > ________________________________
> > From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
> > Sent: 23 February 2021 18:29
> > To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
> > Subject: Re: [Haskell-cafe] DatatypeContexts / alternative
> >
> > This email was sent to you by someone outside the University.
> > You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
> >
> > On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
> > > module DatatypeContextsExample where
> > >
> > > import Data.Map
> > > import Data.Bifunctor
> > >
> > > data Foo t = Foo (Map t t)
> > >
> > > instance Functor Foo where
> > >     fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))
> > >
> > > This does not compile, because I am using toList and fromList, which
> > > require (Ord t). But I cannot really have Foo be a functor in this
> > > way without it. The thing is, every time I am going to use it, t is
> > > actually going to be Ord. But how do I tell Haskell to have this
> > > constraint?
> >
> > You say that every time you are going to use it t is actually going to
> > be Ord, but how does the compiler know that when it comes to type
> > check fmap?  After all, somewhere else you could write
> >
> >     fmap (const getLine) :: Foo t -> Foo (IO String)
> >
> > and  IO String  is certainly not Ord.

From kindaro at gmail.com  Wed Feb 24 12:19:53 2021
From: kindaro at gmail.com (Ignat Insarov)
Date: Wed, 24 Feb 2021 17:19:53 +0500
Subject: [Haskell-cafe] What is your favourite graph library?
Message-ID: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>

Hello!

I really like graphs. People seem to like thinking in terms of dots
and arrows, and graph theory provides a formalization for this.
(Homogeneous binary) relations, finite state automata, networks and
categories are sorts of graphs too.

But unfortunately it is not possible to represent a graph as an
algebraic type. For example, a list is a fixed point of a maybe tuple,
and every usual linear container _(an array, a vector, a sequence…)_
is isomorphous to a list, so we have an easy time prototyping and
specifying the behaviour of any such thing. With graphs, we have a
hard time!

The most popular library for graphs in Haskell is `fgl`.
Unfortunately, it is really easy to get weird behaviour with it,
because folds tear away the limbs from contexts so that your
observation of said contexts depends on the order of folding. I have
been poking at it, trying to make graphs resemble a comonad… but of
course you can have an empty graph, and a comonad cannot be empty.

There is also `alga` — it seemed promising, but now it is deprecated
for some reason… The usual `containers` also provide something they
call a graph, but it does not offer much in terms of instances and
algorithms — a graph is merely a type alias to an array.

So, is there any cool library that I missed? Or some promising
research? Do you know of any packages that use graphs heavily and in
interesting ways? Are you curious to see progress in this area?

From jaro.reinders at gmail.com  Wed Feb 24 12:24:49 2021
From: jaro.reinders at gmail.com (Jaro Reinders)
Date: Wed, 24 Feb 2021 13:24:49 +0100
Subject: [Haskell-cafe] What is your favourite graph library?
In-Reply-To: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
References: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
Message-ID: <f77f6c8e-59c5-2258-3f88-8dba9aab53ab@gmail.com>

> There is also `alga` — it seemed promising, but now it is deprecated
> for some reason…

The alga graph library is called algebraic-graphs on Hackage. I think because 
there was already an unrelated alga package on Hackage.

From jack at jackkelly.name  Wed Feb 24 12:33:19 2021
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Wed, 24 Feb 2021 12:33:19 +0000
Subject: [Haskell-cafe] What is your favourite graph library?
In-Reply-To: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
References: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
Message-ID: <831ffb45569172044feb41c48ec4bb5c@jackkelly.name>

February 24, 2021 10:19 PM, "Ignat Insarov" <kindaro at gmail.com> wrote:

> I have been trying to make graphs resemble a comonad… but of
> course you can have an empty graph, and a comonad cannot be empty.

You may be interested in the `Extend` class from `semigroupoids`, which is "`Comonad` without `extract`":
https://hackage.haskell.org/package/semigroupoids-5.3.5/docs/Data-Functor-Extend.html#t:Extend

> So, is there any cool library that I missed? Or some promising
> research? Do you know of any packages that use graphs heavily and in
> interesting ways? Are you curious to see progress in this area?

Not strictly a package about graph representation, but I always liked how easily functions from search-algorithms plugged into my projects:
https://hackage.haskell.org/package/search-algorithms-0.3.1/docs/Algorithm-Search.html

There's also the "Algebraic Graphs with Class" functional pearl, which you might already be aware of:
https://eprint.ncl.ac.uk/file_store/production/239461/EF82F5FE-66E3-4F64-A1AC-A366D1961738.pdf

HTH,

-- Jack

From seph at codex.scot  Wed Feb 24 12:55:00 2021
From: seph at codex.scot (Seph Shewell Brockway)
Date: Wed, 24 Feb 2021 12:55:00 +0000
Subject: [Haskell-cafe] Problem with stack
Message-ID: <20210224125500.2ew4bxubpzildcp4@leviathan>

Hi all,

A system update (on Arch Linux) seems to have broken my stack
installation. It’s started producing linker errors that look like this:

   dns                  > /usr/bin/ld.gold: error: /mnt/data/home/seph/.stack/snapshots/x86_64-linux-tinfo6/0ae0d61c27cd61876740871252be93ed57cf041b2170a9014507e77ea977085d/8.10.4/lib/x86_64-linux-ghc-8.10.4/libHScryptonite-0.27-G0nFpwexMw39Vj7zbfAUBq-ghc8.10.4.so:1:1: invalid character
   dns                  > collect2: error: ld returned 1 exit status
   dns                  > `gcc' failed in phase `Linker'. (Exit code: 1)

This seems to happen no matter what snapshot I’m using, although not
necessarily with the same packages. Does anyone have any idea what might
be going on?

                                                            Regards,

                                                            Seph

-- 
Seph Shewell Brockway, BSc MSc (Glas.)
Pronouns: she/her

From ulidtko at gmail.com  Wed Feb 24 13:59:02 2021
From: ulidtko at gmail.com (ulidtko at gmail.com)
Date: Wed, 24 Feb 2021 15:59:02 +0200
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <20210224125500.2ew4bxubpzildcp4@leviathan>
References: <20210224125500.2ew4bxubpzildcp4@leviathan>
Message-ID: <EID1PQ.N7DQF96D394D2@gmail.com>

Hi,

On Wed, Feb 24 2021 at 12:55:00 PM +0000, Seph Shewell Brockway 
<seph at codex.scot> wrote:
>  /mnt/data/home

Are you building on a networked filesystem?

Here's a somewhat similar report where switching to a completely local 
filesystem has resolved the issue.
https://github.com/easybuilders/easybuild-easyconfigs/issues/4191




From lemming at henning-thielemann.de  Wed Feb 24 14:45:54 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 24 Feb 2021 15:45:54 +0100 (CET)
Subject: [Haskell-cafe] What is your favourite graph library?
In-Reply-To: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
References: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
Message-ID: <1ef9511-ea6a-e165-776d-1a8386e717f5@henning-thielemann.de>


On Wed, 24 Feb 2021, Ignat Insarov wrote:

> So, is there any cool library that I missed? Or some promising
> research? Do you know of any packages that use graphs heavily and in
> interesting ways? Are you curious to see progress in this area?

I wrote this package:
    http://hackage.haskell.org/package/comfort-graph

The goal was to have more descriptive node and edge identifiers than Int 
and the ability to mix directed and undirected edges.

From seph at codex.scot  Wed Feb 24 15:17:50 2021
From: seph at codex.scot (Seph Shewell Brockway)
Date: Wed, 24 Feb 2021 15:17:50 +0000
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <EID1PQ.N7DQF96D394D2@gmail.com>
References: <20210224125500.2ew4bxubpzildcp4@leviathan>
 <EID1PQ.N7DQF96D394D2@gmail.com>
Message-ID: <20210224151750.i6a3xfzcpf6fu5p7@leviathan>

On Wed, Feb 24, 2021 at 03:59:02PM +0200, ulidtko at gmail.com wrote:
> >  /mnt/data/home
> 
> Are you building on a networked filesystem?

Thanks for responding. /mnt/data is local—a separate partition to allow
user data to be preserved across reinstalls.

-- 
Seph Shewell Brockway, BSc MSc (Glas.)
Pronouns: she/her

From seph at codex.scot  Wed Feb 24 16:52:44 2021
From: seph at codex.scot (Seph Shewell Brockway)
Date: Wed, 24 Feb 2021 16:52:44 +0000
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <20210224125500.2ew4bxubpzildcp4@leviathan>
References: <20210224125500.2ew4bxubpzildcp4@leviathan>
Message-ID: <20210224165244.yhwvfsgk55mysu2h@leviathan>

Looks like another system update has sorted the problem. Thanks anyway.

-- 
Seph Shewell Brockway, BSc MSc (Glas.)
Pronouns: she/her

From jeffbrown.the at gmail.com  Wed Feb 24 19:24:26 2021
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Wed, 24 Feb 2021 14:24:26 -0500
Subject: [Haskell-cafe] What is your favourite graph library?
In-Reply-To: <1ef9511-ea6a-e165-776d-1a8386e717f5@henning-thielemann.de>
References: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
 <1ef9511-ea6a-e165-776d-1a8386e717f5@henning-thielemann.de>
Message-ID: <CAEc4Ma3HBQLeMPfcB51-r4AKwhi7XF3C6a_vOtDaWBSgGxKYbw@mail.gmail.com>

I wrote Hode[1], a library for a generalization of graphs. Relatiionships
in Hode can have any number of members, and those members can themselves be
relationships. Relationships are "templated"; relationship templates are
the natural generalization of edge labels. Hode includes a TUI and a query
language resembling natural language.

I intended it to be for managing a personal knowledge base. Hode is more
expressive than anything I know about, but (so far) harder to use. Encoding
things is easy, and search is as easy as I think can be hoped for -- but
deciding *how* to encode things turns out to be really hard. So much so
that I've ended up using Semantic Synchrony[2] and org-roam[3] instead.

[1] https://github.com/JeffreyBenjaminBrown/hode
[2] https://github.com/synchrony/smsn
[3] https://github.com/org-roam/org-roam

On Wed, Feb 24, 2021 at 9:48 AM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Wed, 24 Feb 2021, Ignat Insarov wrote:
>
> > So, is there any cool library that I missed? Or some promising
> > research? Do you know of any packages that use graphs heavily and in
> > interesting ways? Are you curious to see progress in this area?
>
> I wrote this package:
>     http://hackage.haskell.org/package/comfort-graph
>
> The goal was to have more descriptive node and edge identifiers than Int
> and the ability to mix directed and undirected
> edges._______________________________________________
> 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.



-- 
Jeff Brown | Jeffrey Benjamin Brown
LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>   |   Github
<https://github.com/jeffreybenjaminbrown>   |   Twitter
<https://twitter.com/carelogic>  |  Facebook
<https://www.facebook.com/mejeff.younotjeff>  |  very old Website
<https://msu.edu/~brown202/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210224/c6b1c89e/attachment.html>

From andrei.paskevich at lri.fr  Wed Feb 24 20:28:37 2021
From: andrei.paskevich at lri.fr (Andrei Paskevich)
Date: Wed, 24 Feb 2021 21:28:37 +0100
Subject: [Haskell-cafe] F-IDE 2021 - Last Call for Papers - Extended Deadline
Message-ID: <YDa29WcROJWa/DQg@tikki.lri.fr>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210224/5cf55303/attachment.ksh>

From matteo at confscience.com  Thu Feb 25 13:36:25 2021
From: matteo at confscience.com (matteo at confscience.com)
Date: Thu, 25 Feb 2021 14:36:25 +0100
Subject: [Haskell-cafe] International Conference on Recent Theories and
	Applications in Transportation and Mobility - (RTATM 2021) Prague
Message-ID: <005901d70b7b$36d91bc0$a48b5340$@confscience.com>

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/  

Submission deadline: April 1, 2021

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: April 1, 2021

- 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

 

 

***************************************************************************

OUTSTANDING PAPERS:

Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. 

*************************************************************************** 

PAPER SUBMISSION: 

Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=rtatm2021). 

All papers will be peer reviewed. 

Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page)

Length of Short papers: less than 12 pages 

For more information, please refer to the conference website: https://confscience.com/rtatm/    

 

***************************************************************************

CONTACT 

For more information, please send an email to info-rtatm at confscience.com  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210225/cf50589e/attachment.html>

From olf at aatal-apotheke.de  Thu Feb 25 14:56:40 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 25 Feb 2021 15:56:40 +0100
Subject: [Haskell-cafe] Problem with stack
Message-ID: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>

> Are you building on a networked filesystem?
> 
> Here's a somewhat similar report where switching to a completely local 
> filesystem has resolved the issue.

Speaking of which, is there a specification about what filesystem
features stack and its sub-tools expect? I can not build stack projects
on a remote cifs share, but on the local filesystem it works fine. The
error is

Encountered error while migrating Stack database:
    SQLite3 returned ErrorBusy while attempting to perform step:
database is locked
Please report this on https://github.com/commercialhaskell/stack/issues

I suspect that things like symlinks are expected to work, which samba
does not support despite the target drive being ext4. 

Olaf


From compl.yue at icloud.com  Thu Feb 25 15:30:53 2021
From: compl.yue at icloud.com (YueCompl)
Date: Thu, 25 Feb 2021 23:30:53 +0800
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>
References: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>
Message-ID: <0CA26782-E407-4A90-8055-601D2E10FE4E@icloud.com>

We've been running diskless Linux (Ubuntu 18.04) boxes fine with cabal/stack since about 2 years ago, with all filesystems mounted remotely through NFS, those served by SmartOS with ZFS on the server.

FYI, Compl

> On 2021-02-25, at 22:56, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> 
>> Are you building on a networked filesystem?
>> 
>> Here's a somewhat similar report where switching to a completely local 
>> filesystem has resolved the issue.
> 
> Speaking of which, is there a specification about what filesystem
> features stack and its sub-tools expect? I can not build stack projects
> on a remote cifs share, but on the local filesystem it works fine. The
> error is
> 
> Encountered error while migrating Stack database:
>    SQLite3 returned ErrorBusy while attempting to perform step:
> database is locked
> Please report this on https://github.com/commercialhaskell/stack/issues
> 
> I suspect that things like symlinks are expected to work, which samba
> does not support despite the target drive being ext4. 
> 
> Olaf
> 
> _______________________________________________
> 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.


From svenpanne at gmail.com  Thu Feb 25 15:59:12 2021
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 25 Feb 2021 16:59:12 +0100
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>
References: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>
Message-ID: <CANBN=ms4L-7U1SJCPaH=AOyML6U-yJM7KpaGMw5JYTA3EBj4QA@mail.gmail.com>

Am Do., 25. Feb. 2021 um 15:59 Uhr schrieb Olaf Klinke <
olf at aatal-apotheke.de>:

> Speaking of which, is there a specification about what filesystem
> features stack and its sub-tools expect? I can not build stack projects
> on a remote cifs share, but on the local filesystem it works fine. The
> error is
>
> Encountered error while migrating Stack database:
>     SQLite3 returned ErrorBusy while attempting to perform step:
> database is locked
> Please report this on https://github.com/commercialhaskell/stack/issues
> [...]
>

In ancient times, locking over NFS didn't work, or at least not reliably.
With NFS 4, locking was added to the protocol IIRC, but I have no clue how
good it works, especially when you mix various platforms/implementations.
What the current state with CIFS regarding locking is: I don't know, but in
general I don't really trust remote file systems in this area. :-}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210225/b2f3625b/attachment.html>

From javran.c at gmail.com  Thu Feb 25 21:08:41 2021
From: javran.c at gmail.com (Javran Cheng)
Date: Thu, 25 Feb 2021 13:08:41 -0800
Subject: [Haskell-cafe] Is there a StateT but with resulting pair swapped?
Message-ID: <CA+TfdNZ8K7Tx0bb38vQver7JfK87kQe7Dd3Npzg26+KAPks2aA@mail.gmail.com>

Hi cafe,

I'm playing with alex recently and noticed that:

newtype Alex a
  = Alex {unAlex :: AlexState -> Either String (AlexState, a)}

which is almost StateT AlexState (Except String), and looks like I can make
a MonadError instance out of it.

Therefore I'm curious if there's any existing package that has newtype
StateT' s m a = StateT' (s -> m (s, a)) -- note the swapped pair here

so that I can just deriving (MonadError String) via StateT' AlexState
(Except String) to implement MonadError.

Thanks!
-- 
Javran (Fang) Cheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210225/98267e3a/attachment.html>

From olf at aatal-apotheke.de  Thu Feb 25 21:26:21 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 25 Feb 2021 22:26:21 +0100
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <CANBN=ms4L-7U1SJCPaH=AOyML6U-yJM7KpaGMw5JYTA3EBj4QA@mail.gmail.com>
References: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>
 <CANBN=ms4L-7U1SJCPaH=AOyML6U-yJM7KpaGMw5JYTA3EBj4QA@mail.gmail.com>
Message-ID: <a3dacccdea299ce7766cc83100e1f5f824b8db34.camel@aatal-apotheke.de>

On Thu, 2021-02-25 at 16:59 +0100, Sven Panne wrote:
> Am Do., 25. Feb. 2021 um 15:59 Uhr schrieb Olaf Klinke <
> olf at aatal-apotheke.de>:
> 
> > Speaking of which, is there a specification about what filesystem
> > features stack and its sub-tools expect? I can not build stack projects
> > on a remote cifs share, but on the local filesystem it works fine. The
> > error is
> > 
> > Encountered error while migrating Stack database:
> >     SQLite3 returned ErrorBusy while attempting to perform step:
> > database is locked
> > Please report this on https://github.com/commercialhaskell/stack/issues
> > [...]
> > 
> 
> In ancient times, locking over NFS didn't work, or at least not reliably.
> With NFS 4, locking was added to the protocol IIRC, but I have no clue how
> good it works, especially when you mix various platforms/implementations.
> What the current state with CIFS regarding locking is: I don't know, but in
> general I don't really trust remote file systems in this area. :-}

Thanks for the clue. 

So what exactly is "locking" on the file-system level, then? I searched
and found the term "oplocks" and that this is an option for cifs. Which
state does stack need? oplock=on or oplock=off? My SMB server currently
has oplock=on. Tried toggling it, still same SQLite3 locking error. 

And yes, I'd rather sooner than later switch over to NFS 4, but I have
to sort that out on my NAS. 

It's a pity, my approach was to have as much of my Haskell stuff on a
NAS as possible, so I wouldn't run into disk space issues. But this and
the fact that stack/ghc stubbornly insist on using local dirs like /tmp
make this hard. Has anynone else here successfully built a stack
project on a cifs share? 

Olaf

P.S.: Yes, I even re-mapped /tmp to another partition once to bootstrap
ghc because it would occupy my entire tmpfs. But it would be nice if
one could do without such tricks. 


From ietf-dane at dukhovni.org  Fri Feb 26 02:13:55 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Thu, 25 Feb 2021 21:13:55 -0500
Subject: [Haskell-cafe] Is there a StateT but with resulting pair
	swapped?
In-Reply-To: <CA+TfdNZ8K7Tx0bb38vQver7JfK87kQe7Dd3Npzg26+KAPks2aA@mail.gmail.com>
References: <CA+TfdNZ8K7Tx0bb38vQver7JfK87kQe7Dd3Npzg26+KAPks2aA@mail.gmail.com>
Message-ID: <YDhZY8CTiSsZKMH4@straasha.imrryr.org>

On Thu, Feb 25, 2021 at 01:08:41PM -0800, Javran Cheng wrote:

> I'm playing with alex recently and noticed that:
> 
> newtype Alex a
>   = Alex {unAlex :: AlexState -> Either String (AlexState, a)}
> 
> which is almost StateT AlexState (Except String), and looks like I can make
> a MonadError instance out of it.
> 
> Therefore I'm curious if there's any existing package that has newtype
> StateT' s m a = StateT' (s -> m (s, a)) -- note the swapped pair here

I am not aware of any, so I gave a go at writing a prototype of a StateT
that's agnostic as to the order in which the pair elements are stored,
allowing the Alex type to be coerced to the variant that's stored in
"reverse" order as (s, a).  The use of coercion requires that all the
relevant constructors be in scope, even those you're not otherwise
explicitly using.

Running the below program (also attached):

    module Main (main) where

    import Data.Coerce (coerce)
    import Control.Monad.Identity (Identity(..))
    import Control.Monad.Trans.Except (ExceptT(..), Except, runExcept)

    import qualified GStateT as GS
    import GStateT ( GStateT(..), Swap(..) )

    -- Fake Alex with state Int
    type AlexState = Int
    newtype Alex a = Alex {unAlex :: AlexState -> Either String (AlexState, a) }

    -- Alias the swapped GStateT as StateT
    type StateT = GS.SwapStateT
    runStateT :: Monad m => StateT s m a -> s -> m (s, a)
    runStateT m = GS.runSwapStateT m

    main :: IO ()
    main = do
        let x = (Alex $ \i -> Right (i, i+1)) :: Alex Int
            y = coerce x :: StateT AlexState (Except String) Int
        print $ unAlex x 1
        print $ runExcept $ runStateT y 1
        print $ runExcept $ GS.execStateT y 1
        print $ runExcept $ GS.evalStateT y 1

prints:

    Right (1,2)
    Right (1,2)
    Right 1
    Right 2

showing that all the pieces appear to fit togher.  I've not implemented
MTL-style class instances, but those could also be added.

-- 
    Viktor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GStateT.hs
Type: text/x-haskell
Size: 3105 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210225/a5488405/attachment.hs>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstate.hs
Type: text/x-haskell
Size: 806 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210225/a5488405/attachment-0001.hs>

From spam at scientician.net  Sat Feb 27 08:23:55 2021
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 27 Feb 2021 09:23:55 +0100
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <a3dacccdea299ce7766cc83100e1f5f824b8db34.camel@aatal-apotheke.de>
References: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>
 <CANBN=ms4L-7U1SJCPaH=AOyML6U-yJM7KpaGMw5JYTA3EBj4QA@mail.gmail.com>
 <a3dacccdea299ce7766cc83100e1f5f824b8db34.camel@aatal-apotheke.de>
Message-ID: <s1cvir$h4i$1@ciao.gmane.io>

On 25/02/2021 22.26, Olaf Klinke wrote:
> So what exactly is "locking" on the file-system level, then? I searched
> and found the term "oplocks" and that this is an option for cifs. Which
> state does stack need? oplock=on or oplock=off? My SMB server currently
> has oplock=on. Tried toggling it, still same SQLite3 locking error. 

I have no clue about stack internals, but I suspect that the only
requirements regarding file system semantics are really the requirements
of SQLite3. (Which is obviously what you're seeing.)

> It's a pity, my approach was to have as much of my Haskell stuff on a
> NAS as possible, so I wouldn't run into disk space issues. But this and
> the fact that stack/ghc stubbornly insist on using local dirs like /tmp
> make this hard. Has anynone else here successfully built a stack
> project on a cifs share? 

Judging by the output from

$ strings `which stack`|grep TMP

I'm guessing you could convince the embedded SQLite3 to use a different
temporary directory
by setting the SQLITE_TMPDIR env var.

Not sure if there are other variables of interest there. (I'm assuming
you're already setting STACK_ROOT and/or your $HOME is already on the
network drive.)

Setting TMPDIR=/foo is respected by *many* programs, not sure about
whether GHC/Cabal do.

> P.S.: Yes, I even re-mapped /tmp to another partition once to bootstrap
> ghc because it would occupy my entire tmpfs. But it would be nice if
> one could do without such tricks. 

Yeah, it's a bit of a sad state of affairs that there is only one
"TMPDIR" variable while there are typically

   /tmp -> backed by RAM
   /var/tmp -> backed by disk

on modern Linux systems.

Regards,


From kindaro at gmail.com  Sat Feb 27 11:27:15 2021
From: kindaro at gmail.com (Ignat Insarov)
Date: Sat, 27 Feb 2021 16:27:15 +0500
Subject: [Haskell-cafe] Not too extensible records?
Message-ID: <CAB-2Q09=5jgWBd5uJHCqH-q+DaVuuRuszU3R220ky+3qSGZijg@mail.gmail.com>

Hello!

I have a situation that I think is a good case to apply extensible records to. I
have two kinds of entities that are both extensible but in different ways — I
would like to make sure their fields are not mixed. At the same time, I want to
be able to extend the sets of fields across several modules. Is it possible and
is it practical?

My case is that I have a type for graphs that is a bifunctor — in node labels
and edge labels. I want to gradually decorate these labels with more and more
information. For nodes, it may be the number of outgoing edges or the position
of the node in space. For edges, it may be whether an edge is directed or not,
or whether it was added by some computation, like say transitive closure.

So, I need to be able to add more and more fields to labels, but in such a way
that it is impossible to assign an unsuitable field. It would be nonsense if a
node was said to be undirected or for an edge to be declared a leaf. I would
also like not to provide all the labels ahead of time, but rather define
whatever labels are needed in the module that defines the corresponding
decorating functions.

An example for the sort of things I have in mind:

    class Suitable label type | label → type

    …

    data Topology = Root | Internal | Leaf

    instance Suitable Topology NodeLabels

    detectTopology
      ∷ graph someNodeLabels whateverEdgeLabels
      → graph (someNodeLabels + Topology) whateverEdgeLabels

I looked into `extensible` and `vinyl`.

* `extensible` does not seem to fit because it defines field labels to be type
  level strings, making them all interchangeable — there is no way to enforce
  the distinction between labels suitable for nodes and for edges.

* `vinyl` seems to be more flexible and low level, but this also means that it
  is steeper to learn. The example from the repository uses an enumeration to
  define a set of labels for a type of records, and this means that the set of
  labels cannot be extended across modules — this is a problem for me and I am
  not sure if it can be solved within `vinyl`.

What should I do?

From olf at aatal-apotheke.de  Sat Feb 27 12:42:07 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 27 Feb 2021 13:42:07 +0100
Subject: [Haskell-cafe] Not too extensible records?
Message-ID: <d6c4a89695245476ace607cdd01a2adcf72d9576.camel@aatal-apotheke.de>

> I have a situation that I think is a good case to apply extensible records to. I
> have two kinds of entities that are both extensible but in different ways — I
> would like to make sure their fields are not mixed. At the same time, I want to
> be able to extend the sets of fields across several modules. Is it possible and
> is it practical?
> My case is that I have a type for graphs that is a bifunctor — in node labels
> and edge labels.
> So, I need to be able to add more and more fields to labels, but in such a way
> that it is impossible to assign an unsuitable field.

If your graph is already a bifunctor, why not use a disctinct label or
node type in each use case/module? That certainly fits the requirement
of not mixing fields. Then you could go the old-fashioned way of type
classes, e.g.
class HasTopology label where
   topology :: label -> Topology
instance HasTopology Topology where
   topology = id
instance HasTopology label => HasTopology (label,moreInfo) where
   topology = topology.fst

Or for updateable fields, use a Lens Topology. 
This is a lot of boilerplate, I admit, but you have fine-grained
control over what your types have in common. Nested pairs are type-
level polymorphic lists and with the right type classes can be used as
such, if the list of types is known at compile-time. It is similar to
what mtl does with the MonadFoo classes. 

Olaf


From kindaro at gmail.com  Sat Feb 27 14:59:15 2021
From: kindaro at gmail.com (Ignat Insarov)
Date: Sat, 27 Feb 2021 19:59:15 +0500
Subject: [Haskell-cafe] Not too extensible records?
In-Reply-To: <d6c4a89695245476ace607cdd01a2adcf72d9576.camel@aatal-apotheke.de>
References: <d6c4a89695245476ace607cdd01a2adcf72d9576.camel@aatal-apotheke.de>
Message-ID: <CAB-2Q0-bDPjt4OpTQfD+tVLeyqQQAPqP3qa2Y-30tqLXAzUW+g@mail.gmail.com>

Thank you for your kind suggestions, Olaf and Henning.

I am looking into an extensible record based solution for the sake of
extensibility and convenience. I could certainly manage everything
with a bunch of tuples, but that would require writing a huge number
of `HasThis` and `HasThat` instances and even then would not provide
the flexibility I should like.

For example, suppose I have two functions: one is a layout algorithm
that assigns to nodes some spatial positions, and the second is a
topological algorithm that discerns roots and leaves. These two
functions are conceptually independent and may be applied in any
order, but it seems to me that as many as 5 types would be needed to
handle this situation: `label`, `(label, V2 Double)`, `(label,
Topology)`, `((label, V2 Double), Topology)` and `((label, Topology),
V2 Double)`. And what if there is another quality independent of these
two? The number of permutations goes through the roof.

So, it seems to me that some smart technology is needed to make this manageable.

From lemming at henning-thielemann.de  Sat Feb 27 17:41:14 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 27 Feb 2021 18:41:14 +0100 (CET)
Subject: [Haskell-cafe] Not too extensible records?
In-Reply-To: <CAB-2Q0-bDPjt4OpTQfD+tVLeyqQQAPqP3qa2Y-30tqLXAzUW+g@mail.gmail.com>
References: <d6c4a89695245476ace607cdd01a2adcf72d9576.camel@aatal-apotheke.de>
 <CAB-2Q0-bDPjt4OpTQfD+tVLeyqQQAPqP3qa2Y-30tqLXAzUW+g@mail.gmail.com>
Message-ID: <998fd716-2652-a8d7-2b7c-b2b9dbd4d756@henning-thielemann.de>


On Sat, 27 Feb 2021, Ignat Insarov wrote:

> I am looking into an extensible record based solution for the sake of 
> extensibility and convenience. I could certainly manage everything with 
> a bunch of tuples, but that would require writing a huge number of 
> `HasThis` and `HasThat` instances and even then would not provide the 
> flexibility I should like.

Before thinking about a new type extension to the already complicated type 
system with its many extensions I would try to solve the problem with the 
existing machinery. I think the existing solutions can solve your problem 
and you do not know whether extensible records would really simplify your 
code in the end.


> For example, suppose I have two functions: one is a layout algorithm
> that assigns to nodes some spatial positions, and the second is a
> topological algorithm that discerns roots and leaves. These two
> functions are conceptually independent and may be applied in any
> order, but it seems to me that as many as 5 types would be needed to
> handle this situation: `label`, `(label, V2 Double)`, `(label,
> Topology)`, `((label, V2 Double), Topology)` and `((label, Topology),
> V2 Double)`. And what if there is another quality independent of these
> two? The number of permutations goes through the roof.

What about a record with parameters:

data EdgeLabel label vector topology =
   EdgeLabel {label :: label, vector :: vector, topology :: topology}

You can easily disable a field by using the unit type (), i.e.

your type		my type
label			EdgeLabel label () ()
(label, V2 Double)	EdgeLabel label (V2 Double) ()
(label, Topology)	EdgeLabel label () Topology
((label, V2 Double), Topology)
 			EdgeLabel label (V2 Double) Topology

My experience is that working with a fixed (but maybe large) number of 
type parameters is much easier than trying to cope with different shapes 
of nested tuples, extending types, wrappers.

From olf at aatal-apotheke.de  Sat Feb 27 18:20:00 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 27 Feb 2021 19:20:00 +0100
Subject: [Haskell-cafe] Not too extensible records?
In-Reply-To: <CAB-2Q0-bDPjt4OpTQfD+tVLeyqQQAPqP3qa2Y-30tqLXAzUW+g@mail.gmail.com>
References: <d6c4a89695245476ace607cdd01a2adcf72d9576.camel@aatal-apotheke.de>
 <CAB-2Q0-bDPjt4OpTQfD+tVLeyqQQAPqP3qa2Y-30tqLXAzUW+g@mail.gmail.com>
Message-ID: <7f3e4578cfbf1ef2a5796fb235852fe7bbac083e.camel@aatal-apotheke.de>

On Sat, 2021-02-27 at 19:59 +0500, Ignat Insarov wrote:
> Thank you for your kind suggestions, Olaf and Henning.
> 
> I am looking into an extensible record based solution for the sake of
> extensibility and convenience. I could certainly manage everything
> with a bunch of tuples, but that would require writing a huge number
> of `HasThis` and `HasThat` instances and even then would not provide
> the flexibility I should like.
> 
> For example, suppose I have two functions: one is a layout algorithm
> that assigns to nodes some spatial positions, and the second is a
> topological algorithm that discerns roots and leaves. These two
> functions are conceptually independent and may be applied in any
> order, but it seems to me that as many as 5 types would be needed to
> handle this situation: `label`, `(label, V2 Double)`, `(label,
> Topology)`, `((label, V2 Double), Topology)` and `((label, Topology),
> V2 Double)`. And what if there is another quality independent of these
> two? The number of permutations goes through the roof.
> 
> So, it seems to me that some smart technology is needed to make this manageable.
Precisely. And I advocate that this might be ordinary type classes.
While the number of combinations is exponential, you'd only write the
base and inductive cases for HasFoo. The compiler would figure out the
rest. 
I suggest you look at the machinery in the mtl package. There, a very
similar problem is solved: Different types are stacked on top of each
other, in any order and depth, and each type provides a certain
functionality. Yet in any combination, each functionality in the stack
is available at the top level. 

Olaf



From 47dragonfyre at gmail.com  Sun Feb 28 00:41:56 2021
From: 47dragonfyre at gmail.com (A. Mc.)
Date: Sat, 27 Feb 2021 16:41:56 -0800
Subject: [Haskell-cafe] Desktop GUI in Haskell
Message-ID: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>

Hello,

I'm attempting to use GTK+3 to create a Desktop, but I am having a problem
installing all of the dependencies.  I keep getting the following error:
GUI cabal: version >=0.9.0 of pkg-config is required

I am using Cygwin on a Windows 10 operating system. What is
needed to fix this? Is this the best way to do a
desktop GUI in Haskell?

Thanks in advance and thank you for your time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210227/3e9af43f/attachment.html>

From branimir.maksimovic at gmail.com  Sun Feb 28 01:07:18 2021
From: branimir.maksimovic at gmail.com (Branimir Maksimovic)
Date: Sun, 28 Feb 2021 02:07:18 +0100
Subject: [Haskell-cafe] Desktop GUI in Haskell
In-Reply-To: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
References: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
Message-ID: <0251cb04-79cd-d267-200b-abc49fa9ae03@gmail.com>

I wouldn't go that route on Windows. I would make my winapi lib 
wrapper,\and make

standard Windows GUI. Perhaps someone did that already.

Greets, Branimir.

On 28.2.21. 1:41 пре подне, A. Mc. wrote:
> Hello,
>
> I'm attempting to use GTK+3 to create a Desktop, but I am having a 
> problem installing all of the dependencies.  I keep getting the 
> following error:
> GUI cabal: version >=0.9.0 of pkg-config is required
> I am using Cygwin on a Windows 10 operating system. What is
> needed to fix this? Is this the best way to do a
> desktop GUI in Haskell?
> Thanks in advance and thank you for your time.
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210228/a23cf440/attachment.html>

From lemming at henning-thielemann.de  Sun Feb 28 07:34:28 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 28 Feb 2021 08:34:28 +0100 (CET)
Subject: [Haskell-cafe] Desktop GUI in Haskell
In-Reply-To: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
References: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
Message-ID: <95272361-f791-c175-9ce7-9a492cef79d@henning-thielemann.de>


On Sat, 27 Feb 2021, A. Mc. wrote:

> I'm attempting to use GTK+3 to create a Desktop, but I am having a problem installing all of the dependencies.  I keep getting the
> following error: 
> GUI cabal: version >=0.9.0 of pkg-config is required

I understand this error message as: You need to install pkg-config first. 
pkg-config is the tool that manages path and versions of installed C 
libraries and Cabal uses it to query existence and compiler flags of 
installed C libraries.

> I am using Cygwin on a Windows 10 operating system. What is needed to 
> fix this? Is this the best way to do a desktop GUI in Haskell?

On Windows I used MSYS2 and this helped a lot to install components like 
pkg-config and other C libraries plus their interfaces.

From coot at coot.me  Sun Feb 28 08:15:19 2021
From: coot at coot.me (coot at coot.me)
Date: Sun, 28 Feb 2021 08:15:19 +0000
Subject: [Haskell-cafe] Desktop GUI in Haskell
In-Reply-To: <95272361-f791-c175-9ce7-9a492cef79d@henning-thielemann.de>
References: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
 <95272361-f791-c175-9ce7-9a492cef79d@henning-thielemann.de>
Message-ID: <Szj60qmJkpy4G7nvoBZ_pc215O5uFmhVbttTRQ-UQsNZorROQDOFWModrEzLlTQi-ya_JSbkG2Vad9aRDnBR3Bc6-tVq8OvL9FEjWx6BoUo=@coot.me>

This is not directly related but I once spent some time trying to satisfy pkg-config dependencies on Windows. This is what I ended up with: https://github.com/input-output-hk/cardano-node/blob/8bb0d2322d81bb9e73553f5823af7d307910369d/doc/getting-started/building-the-node-on-windows.md

In particular you can install pkg-config with \`choco install pgkconfiglite\` using chocolatey package manager.

Best regards,
Marcin Szamotulski


Sent from ProtonMail mobile



\-------- Original Message --------
On 28 Feb 2021, 08:34, Henning Thielemann < lemming at henning-thielemann.de> wrote:

>
>
>
>
> On Sat, 27 Feb 2021, A. Mc. wrote:
>
> > I'm attempting to use GTK+3 to create a Desktop, but I am having a problem installing all of the dependencies. I keep getting the
> > following error:
> > GUI cabal: version >=0.9.0 of pkg-config is required
>
> I understand this error message as: You need to install pkg-config first.
> pkg-config is the tool that manages path and versions of installed C
> libraries and Cabal uses it to query existence and compiler flags of
> installed C libraries.
>
> > I am using Cygwin on a Windows 10 operating system. What is needed to
> > fix this? Is this the best way to do a desktop GUI in Haskell?
>
> On Windows I used MSYS2 and this helped a lot to install components like
> pkg-config and other C libraries plus their interfaces.\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210228/d8c1b544/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210228/d8c1b544/attachment.sig>

From ben.franksen at online.de  Sun Feb 28 08:25:45 2021
From: ben.franksen at online.de (Ben Franksen)
Date: Sun, 28 Feb 2021 09:25:45 +0100
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <010f0177d04a01ec-cdcf65f0-b70d-4344-ad2b-8ccc0de7b29f-000000@us-east-2.amazonses.com>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <010f0177d04a01ec-cdcf65f0-b70d-4344-ad2b-8ccc0de7b29f-000000@us-east-2.amazonses.com>
Message-ID: <s1fk29$13vh$1@ciao.gmane.io>

Am 23.02.21 um 20:07 schrieb Richard Eisenberg:
> You might be interested in my recent paper on exactly this problem:
> how to make DatatypeContexts actually work the way you want:
> https://richarde.dev/papers/2020/partialdata/partialdata.pdf
> <https://richarde.dev/papers/2020/partialdata/partialdata.pdf>.
> Sections 1-3 and 6 onwards should be approachable with only a Haskell
> background (but not, say, type theory). (Section 4 gives details
> about the design, but these details are broadly inferrable from the
> other sections. Section 5 is a proof that the idea is sound; you can
> just take this on faith.)

Richard, this is absolutely fantastic! I have just read as far as the
listed contributions and I think this exactly what we need.

> There are, sadly, no plans to implement this paper, because the
> interactions with other GHC features means that implementing this
> would require dependent types.

What are these other GHC features? Does the paper explain this?
Otherwise where can I read more about it?

Cheers
Ben

>> On Feb 23, 2021, at 1:37 PM, CASANOVA Juan <Juan.Casanova at ed.ac.uk>
>> wrote:
>> 
>> Tom,
>> 
>> Yes I realize that, but what I am expecting, I guess, is for the
>> type checker to tell me (or anyone who tried to use it) that Foo
>> (IO String) makes no sense, because Foo is always applied to
>> something with Ord. That the very concept of the type Foo (IO
>> String) itself does not type check.
>> 
>> I realize the answer might be that this is impossible with current
>> Haskell, but then a) Is there any fundamental reason why it is
>> impossible, like it would never be possible to do this, or is it
>> just a feature that is not clear how to implement in GHC? and b)
>> The basic problem that I have: Implementing an fmap for something
>> like Foo. Can I really just not do it in any way or shape, with any
>> form of workaround?
>> 
>> So far what I have been doing with situation similar to this is to
>> just create the function fmap_foo that does what fmap does, with
>> the proper constraints. But this is not enough when later on I want
>> to use some other function that requires Foo to actually implement
>> Functor. It would basically mean I have to re-implement all the
>> structure while adding all the additional "Ord" constraints.
>> 
>> Thanks, Juan.
>> 
>> 
>> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org
>> <mailto:haskell-cafe-bounces at haskell.org>> on behalf of Tom Ellis
>> <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk
>> <mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>> Sent: 23
>> February 2021 18:29 To: haskell-cafe at haskell.org
>> <mailto:haskell-cafe at haskell.org> <haskell-cafe at haskell.org
>> <mailto:haskell-cafe at haskell.org>> Subject: Re: [Haskell-cafe]
>> DatatypeContexts / alternative
>> 
>> This email was sent to you by someone outside the University. You
>> should only click on links or attachments if you are certain that
>> the email is genuine and the content is safe.
>> 
>> On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
>>> module DatatypeContextsExample where
>>> 
>>> import Data.Map import Data.Bifunctor
>>> 
>>> data Foo t = Foo (Map t t)
>>> 
>>> instance Functor Foo where fmap f (Foo m) = Foo (fromList (fmap
>>> (bimap f f) (toList m)))
>>> 
>>> This does not compile, because I am using toList and fromList,
>>> which require (Ord t). But I cannot really have Foo be a functor
>>> in this way without it. The thing is, every time I am going to
>>> use it, t is actually going to be Ord. But how do I tell Haskell
>>> to have this constraint?
>> 
>> You say that every time you are going to use it t is actually going
>> to be Ord, but how does the compiler know that when it comes to
>> type check fmap?  After all, somewhere else you could write
>> 
>> fmap (const getLine) :: Foo t -> Foo (IO String)
>> 
>> and  IO String  is certainly not Ord.
>> 
>> Tom _______________________________________________ Haskell-Cafe
>> mailing list To (un)subscribe, modify options or view archives go
>> to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> 
>> Only members subscribed via the mailman list are allowed to post. 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336. Is e buidheann
>> carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba,
>> àireamh clàraidh SC005336.
>> _______________________________________________ Haskell-Cafe
>> mailing list To (un)subscribe, modify options or view archives go
>> to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> 
>> Only members subscribed via the mailman list are allowed to post.
> 
> 
> 
> _______________________________________________ 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.
> 



From ben.franksen at online.de  Sun Feb 28 08:38:17 2021
From: ben.franksen at online.de (Ben Franksen)
Date: Sun, 28 Feb 2021 09:38:17 +0100
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <20210224101748.GD6186@cloudinit-builder>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223192715.GC6186@cloudinit-builder>
 <DB7PR05MB5369637AFDFD6A39159CA432DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210224101748.GD6186@cloudinit-builder>
Message-ID: <s1fkpp$7qp$1@ciao.gmane.io>

Am 24.02.21 um 11:17 schrieb Tom Ellis:
> It is a rare problem that gets simpler by the
> addition of type classes.

I disagree that this is a rare problem. It is a pervasive problem. It
crops up almost everywhere, at least that is my personal experience. And
I think Section 2 of the "Partial Type Constructors" paper shows that my
experience is not particularly unusual.

Cheers
Ben

>> ________________________________
>> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
>> Sent: 23 February 2021 19:27
>> To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
>> Subject: Re: [Haskell-cafe] DatatypeContexts / alternative
>>
>> This email was sent to you by someone outside the University.
>> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
>>
>> On Tue, Feb 23, 2021 at 06:37:06PM +0000, CASANOVA Juan wrote:
>>> Yes I realize that, but what I am expecting, I guess, is for the
>>> type checker to tell me (or anyone who tried to use it) that Foo (IO
>>> String) makes no sense, because Foo is always applied to something
>>> with Ord. That the very concept of the type Foo (IO String) itself
>>> does not type check.
>>>
>>> I realize the answer might be that this is impossible with current
>>> Haskell, but then a) Is there any fundamental reason why it is
>>> impossible
>>
>> Yes, there's a fundamental reason.  Neither you nor the compiler can
>> possibly know when invalid Foos (i.e. those whose parameter isn't Ord)
>> are constructed inside a function polymorphic in a  Functor . Let's
>> extend my example.
>>
>>     mapToUnit :: Functor f => f a -> f ()
>>     mapToUnit = fmap (const ()) . fmap (const getLine)
>>
>>     whatShouldItDo :: Foo ()
>>     whatShouldItDo = mapToUnit (Foo (Data.Map.singleton () ()))
>>
>> Do you agree that  whatShouldItDo  is well typed?  If not, why not?
>> If so, how should it behave when evaluated?  The implementation of
>>  mapToUnit , combined with your  Functor  instance says that  fromList
>> must be run on  [(getLine, getLine)] .  But this is impossible!
>>
>> Accepting that  whatShouldItDo  is well typed implies that you must
>> accept that your  Functor  instance for  Foo  cannot work.  (I don't
>> believe any instance can work if it is law-abiding but I don't know of
>> a proof.)
>>
>> There is a cottage industry of trying to work around this problem.
>> See, for example [1].  I have never seen a satisfactory solution.
>>
>> Based on your posts here you are frequently running into the limits of
>> type class based programming in Haskell.  If your purpose is practical
>> I strongly advise you to stay away from type classes for anything
>> non-trivial. Stick to the value level. Your life will be much
>> easier. If your purpose is research into type classes, or general
>> interest, then good luck and enjoy!
>>
>> Tom
>>
>>
>> [1] https://jeltsch.wordpress.com/2015/09/03/constrained-monads/
>>
>>
>>> ________________________________
>>> From: Haskell-Cafe <haskell-cafe-bounces at haskell.org> on behalf of Tom Ellis <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>
>>> Sent: 23 February 2021 18:29
>>> To: haskell-cafe at haskell.org <haskell-cafe at haskell.org>
>>> Subject: Re: [Haskell-cafe] DatatypeContexts / alternative
>>>
>>> This email was sent to you by someone outside the University.
>>> You should only click on links or attachments if you are certain that the email is genuine and the content is safe.
>>>
>>> On Tue, Feb 23, 2021 at 06:14:59PM +0000, CASANOVA Juan wrote:
>>>> module DatatypeContextsExample where
>>>>
>>>> import Data.Map
>>>> import Data.Bifunctor
>>>>
>>>> data Foo t = Foo (Map t t)
>>>>
>>>> instance Functor Foo where
>>>>     fmap f (Foo m) = Foo (fromList (fmap (bimap f f) (toList m)))
>>>>
>>>> This does not compile, because I am using toList and fromList, which
>>>> require (Ord t). But I cannot really have Foo be a functor in this
>>>> way without it. The thing is, every time I am going to use it, t is
>>>> actually going to be Ord. But how do I tell Haskell to have this
>>>> constraint?
>>>
>>> You say that every time you are going to use it t is actually going to
>>> be Ord, but how does the compiler know that when it comes to type
>>> check fmap?  After all, somewhere else you could write
>>>
>>>     fmap (const getLine) :: Foo t -> Foo (IO String)
>>>
>>> and  IO String  is certainly not Ord.
> _______________________________________________
> 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.
> 



From ben.franksen at online.de  Sun Feb 28 08:47:34 2021
From: ben.franksen at online.de (Ben Franksen)
Date: Sun, 28 Feb 2021 09:47:34 +0100
Subject: [Haskell-cafe] What is your favourite graph library?
In-Reply-To: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
References: <CAB-2Q09KCdyhn7Jx4ReSGPeRO+m+r0iQLGwtn2jhRpem2ZGkPA@mail.gmail.com>
Message-ID: <s1flb8$56q$1@ciao.gmane.io>

Am 24.02.21 um 13:19 schrieb Ignat Insarov:
> I really like graphs.

I hate them. Whenever I encounter a graph related problem I /want/ to
reach for an established library, same as you. And invariably I end up
re-inventing the wheel because I find that for my particular problem the
data representation in any of the general purpose graph libraries are
not suitable.

Cheers
Ben


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sun Feb 28 08:52:16 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 28 Feb 2021 08:52:16 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <s1fkpp$7qp$1@ciao.gmane.io>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223192715.GC6186@cloudinit-builder>
 <DB7PR05MB5369637AFDFD6A39159CA432DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210224101748.GD6186@cloudinit-builder>
 <s1fkpp$7qp$1@ciao.gmane.io>
Message-ID: <20210228085216.GG17096@cloudinit-builder>

On Sun, Feb 28, 2021 at 09:38:17AM +0100, Ben Franksen wrote:
> Am 24.02.21 um 11:17 schrieb Tom Ellis:
> > It is a rare problem that gets simpler by the
> > addition of type classes.
> 
> I disagree that this is a rare problem. It is a pervasive problem. It
> crops up almost everywhere, at least that is my personal experience. And
> I think Section 2 of the "Partial Type Constructors" paper shows that my
> experience is not particularly unusual.

I think I must have use language that was unnecessarily confusing. My
meaning was

"Only rarely is a problem simplified by the addition of typeclasses"

Tom

From 6yearold at gmail.com  Sun Feb 28 09:03:15 2021
From: 6yearold at gmail.com (Gleb Popov)
Date: Sun, 28 Feb 2021 12:03:15 +0300
Subject: [Haskell-cafe] Desktop GUI in Haskell
In-Reply-To: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
References: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
Message-ID: <CALH631n796j6_+bQnmcoVhkekrQHJxrsrGA-MfHN7tNRojW=Og@mail.gmail.com>

On Sun, Feb 28, 2021 at 3:43 AM A. Mc. <47dragonfyre at gmail.com> wrote:

> Hello,
>
> I'm attempting to use GTK+3 to create a Desktop, but I am having a problem
> installing all of the dependencies.  I keep getting the following error:
> GUI cabal: version >=0.9.0 of pkg-config is required
>
> I am using Cygwin on a Windows 10 operating system. What is
> needed to fix this? Is this the best way to do a
> desktop GUI in Haskell?
>
> Thanks in advance and thank you for your time.
> _______________________________________________
> 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 Stack comes with a MSYS environment, which can be used to install
pkg-config and various dependencies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210228/76694515/attachment.html>

From jack at jackkelly.name  Sun Feb 28 09:09:54 2021
From: jack at jackkelly.name (jack at jackkelly.name)
Date: Sun, 28 Feb 2021 09:09:54 +0000
Subject: [Haskell-cafe] Desktop GUI in Haskell
In-Reply-To: <Szj60qmJkpy4G7nvoBZ_pc215O5uFmhVbttTRQ-UQsNZorROQDOFWModrEzLlTQi-ya_JSbkG2Vad9aRDnBR3Bc6-tVq8OvL9FEjWx6BoUo=@coot.me>
References: <Szj60qmJkpy4G7nvoBZ_pc215O5uFmhVbttTRQ-UQsNZorROQDOFWModrEzLlTQi-ya_JSbkG2Vad9aRDnBR3Bc6-tVq8OvL9FEjWx6BoUo=@coot.me>
 <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
 <95272361-f791-c175-9ce7-9a492cef79d@henning-thielemann.de>
Message-ID: <4276df541daf35040d40aee1af3e70a7@jackkelly.name>

February 28, 2021 6:15 PM, coot at coot.me wrote:

> In particular you can install pkg-config with `choco install pgkconfiglite` using chocolatey
> package manager.

I believe chocolatey can also install msys, and has support for telling cabal-install about it.

If you haven't installed anything with chocolatey before, `choco install haskell-dev` should get you a GHC and MSYS, which should get you `pkg-config`.

If you've installed cabal before msys, you will need to force a reinstall (so that it detects msys and configures itself accordingly). After installing msys (either directly or via `choco install haskell-dev`), run `choco install cabal -y --reinstall`.

HTH,

-- Jack

> -------- Original Message --------
> On 28 Feb 2021, 08:34, Henning Thielemann wrote:
> 
>> On Sat, 27 Feb 2021, A. Mc. wrote:
>> 
>>> I'm attempting to use GTK+3 to create a Desktop, but I am having a problem installing all of the
>> dependencies. I keep getting the
>>> following error:
>>> GUI cabal: version >=0.9.0 of pkg-config is required
>> 
>> I understand this error message as: You need to install pkg-config first.
>> pkg-config is the tool that manages path and versions of installed C
>> libraries and Cabal uses it to query existence and compiler flags of
>> installed C libraries.
>> 
>>> I am using Cygwin on a Windows 10 operating system. What is needed to
>>> fix this? Is this the best way to do a desktop GUI in Haskell?
>> 
>> On Windows I used MSYS2 and this helped a lot to install components like
>> pkg-config and other C libraries plus their
>> interfaces._______________________________________________
>> 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.

From ben.franksen at online.de  Sun Feb 28 11:40:50 2021
From: ben.franksen at online.de (Ben Franksen)
Date: Sun, 28 Feb 2021 12:40:50 +0100
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <20210228085216.GG17096@cloudinit-builder>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223192715.GC6186@cloudinit-builder>
 <DB7PR05MB5369637AFDFD6A39159CA432DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210224101748.GD6186@cloudinit-builder> <s1fkpp$7qp$1@ciao.gmane.io>
 <20210228085216.GG17096@cloudinit-builder>
Message-ID: <s1fvg2$11sh$1@ciao.gmane.io>

Am 28.02.21 um 09:52 schrieb Tom Ellis:
> On Sun, Feb 28, 2021 at 09:38:17AM +0100, Ben Franksen wrote:
>> Am 24.02.21 um 11:17 schrieb Tom Ellis:
>>> It is a rare problem that gets simpler by the
>>> addition of type classes.
>>
>> I disagree that this is a rare problem. It is a pervasive problem. It
>> crops up almost everywhere, at least that is my personal experience. And
>> I think Section 2 of the "Partial Type Constructors" paper shows that my
>> experience is not particularly unusual.
> 
> I think I must have use language that was unnecessarily confusing. My
> meaning was
> 
> "Only rarely is a problem simplified by the addition of typeclasses"

Oops. No objection to that!

Cheers
Ben


From lemmih at gmail.com  Sun Feb 28 11:59:07 2021
From: lemmih at gmail.com (Lemmih)
Date: Sun, 28 Feb 2021 19:59:07 +0800
Subject: [Haskell-cafe] [ANN] HGeometry-0.12
Message-ID: <CADf-JbmA6-Red-kh1e17QZr4m7Cy53Zme6vn11_zxT6TRQRPNg@mail.gmail.com>

It is our great pleasure to announce version 0.12 of HGeometry!

HGeometry is a swiss army knife for computational geometry. Wondering if a
point is inside a polygon? HGeometry will tell you. Looking for the
shortest path inside a maze? HGeometry will light your way. Planning a
museum heist? HGeometry will show you the camera blindspots in O(n log n)
time!

Check out our website for more: https://hgeometry.org/

HGeometry is open to contributors at all levels of Haskell experience and
we have a list of weekend-sized projects. Ask in the Discord server for
guidance and/or pair programming.

New in 0.12:
- Algorithms:
  - Visibility polygon in O(n log n).
  - Earclip triangulation in O(n^2) worst case, O(n) expected case.
  - Single-source shortest path in O(n).
  - Planar point locator in O(log n).
  - Point set diameter in O(n log n).
  - Convex hull of a polygon in O(n).
  - Diameter of a convex polygon in O(n).
  - Check if a point lies inside a convex polygon in O(n).
- Bug fixes and improved numerical robustness.
- Property testing and several methods for generating random polygons.
- See changelog.org for an exhaustive list of changes.

Future developments:
- Bring Haddock documentation coverage up to 100%. Currently, we're in the
low eighties.
- A holistic approach to demonstrating correctness:
   - Proven algorithms.
   - Unit testing for hand-picked corner cases.
   - Property testing with randomly generated polygons / geometric data.
   - Exhaustive property testing with real-world datasets (osm).
- Benchmarks to show the relative performance of HGeometry's many
algorithms.

Contributors:
- Frank Staals, @noinia
- David Himmelstrup, @Lemmih
- Hunter DeMeyer, @1ndy

Website: https://hgeometry.org
GitHub:  https://github.com/nionia/hgeometry
Hackage: https://hackage.haskell.org/package/hgeometry
Discord: https://discord.gg/HQwbD9jWqg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210228/0deb54f0/attachment.html>

From ivanperezdominguez at gmail.com  Sun Feb 28 14:53:23 2021
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Sun, 28 Feb 2021 09:53:23 -0500
Subject: [Haskell-cafe] Desktop GUI in Haskell
In-Reply-To: <0251cb04-79cd-d267-200b-abc49fa9ae03@gmail.com>
References: <CAOsti3k=_GSriCsAkL2vco0==bLNXzFKt5=v=waZ-_7PZD1t8Q@mail.gmail.com>
 <0251cb04-79cd-d267-200b-abc49fa9ae03@gmail.com>
Message-ID: <CACZKWEJPGrOPHVwHGStDvKsfBsMms29=YVe-CRjABi9z=61Z7A@mail.gmail.com>

Hi A. Mc.,

Just in case it helps:

Its perfectly fine to create a Haskell windows desktop application in Gtk.
I've done it, and I deployed commercial desktop applications in the past
(AFAIK, they were in production for over a decade without issues and they
may still be used). Gtk has a mailing list that, as of last year, was still
active: gtk2hs-users at lists.sourceforge.net. It's *very* low traffic.

If installing or getting gtk to work gives you headaches, you may want to
consider Wx. I had some issues last time I tried wx on mac (IIRC 2020), but
those issues may no longer be there.

If you have questions, feel free to drop me a line. I may not be able to
spend time debugging low-level details, but I may be able to help if I hit
the same roadblock.

Cheers

Ivan

On Sat, 27 Feb 2021 at 20:08, Branimir Maksimovic <
branimir.maksimovic at gmail.com> wrote:

> I wouldn't go that route on Windows. I would make my winapi lib
> wrapper,\and make
>
> standard Windows GUI. Perhaps someone did that already.
>
> Greets, Branimir.
> On 28.2.21. 1:41 пре подне, A. Mc. wrote:
>
> Hello,
>
> I'm attempting to use GTK+3 to create a Desktop, but I am having a problem
> installing all of the dependencies.  I keep getting the following error:
> GUI cabal: version >=0.9.0 of pkg-config is required
> I am using Cygwin on a Windows 10 operating system. What is
> needed to fix this? Is this the best way to do a
> desktop GUI in Haskell?
> Thanks in advance and thank you for your time.
>
> _______________________________________________
> 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-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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210228/fbffff8f/attachment.html>

From rae at richarde.dev  Sun Feb 28 19:00:00 2021
From: rae at richarde.dev (Richard Eisenberg)
Date: Sun, 28 Feb 2021 19:00:00 +0000
Subject: [Haskell-cafe] DatatypeContexts / alternative
In-Reply-To: <s1fk29$13vh$1@ciao.gmane.io>
References: <DB7PR05MB5369E790764CABDDCBD3D602DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <20210223182947.GB6186@cloudinit-builder>
 <DB7PR05MB53693F056DAEE31F7CD5F726DF809@DB7PR05MB5369.eurprd05.prod.outlook.com>
 <010f0177d04a01ec-cdcf65f0-b70d-4344-ad2b-8ccc0de7b29f-000000@us-east-2.amazonses.com>
 <s1fk29$13vh$1@ciao.gmane.io>
Message-ID: <010f0177ea02fd16-74356e30-dd0b-4a49-818a-404ee8e8437c-000000@us-east-2.amazonses.com>



> On Feb 28, 2021, at 3:25 AM, Ben Franksen <ben.franksen at online.de> wrote:
> 
> What are these other GHC features? Does the paper explain this?
> Otherwise where can I read more about it?

I think it was data families. But, perhaps more troublesome is the fact that the paper assumes a dependently-typed internal language. Maybe it's possible to do this without dependent types in the internal language, but I'm not sure how to begin to think about that problem.

I was about to write that it might be helpful to have a GHC proposal to implement this paper, which would depend on (and provide further motivation for)  having dependent types... but I'm not actually sure that would be productive at this point.

I have spent some time thinking about how to clear my decks to make more time for implementation work, and I expect to prioritize this more going forward.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210228/01c232a8/attachment.html>

From compl.yue at icloud.com  Thu Feb 25 18:31:36 2021
From: compl.yue at icloud.com (YueCompl)
Date: Fri, 26 Feb 2021 02:31:36 +0800
Subject: [Haskell-cafe] Problem with stack
In-Reply-To: <CANBN=ms4L-7U1SJCPaH=AOyML6U-yJM7KpaGMw5JYTA3EBj4QA@mail.gmail.com>
References: <5b79106ecbb613d0a499b006a986c461b3b4da7a.camel@aatal-apotheke.de>
 <CANBN=ms4L-7U1SJCPaH=AOyML6U-yJM7KpaGMw5JYTA3EBj4QA@mail.gmail.com>
Message-ID: <C349583E-C67D-4481-A3C6-EEF99F0B72EC@icloud.com>

Yes, NFSv3 client side locking works pretty well so long as no shared concurrent write happens. A single node's os would assume successful lock for it to write to a file, when multiple nodes do this concurrently, the file will be corrupted. As with stack it can happen and rendering the tool unusable.

But NFSv4 server side locking can leave dead locks appear live, leading stack to wait forever. So we stay client side locking, and carefully have each node use different path on the shared storage for .stack folders, then reinitialize it in case corrupted by accident.

> On 2021-02-25, at 23:59, Sven Panne <svenpanne at gmail.com> wrote:
> 
> Am Do., 25. Feb. 2021 um 15:59 Uhr schrieb Olaf Klinke <olf at aatal-apotheke.de <mailto:olf at aatal-apotheke.de>>:
> Speaking of which, is there a specification about what filesystem
> features stack and its sub-tools expect? I can not build stack projects
> on a remote cifs share, but on the local filesystem it works fine. The
> error is
> 
> Encountered error while migrating Stack database:
>     SQLite3 returned ErrorBusy while attempting to perform step:
> database is locked
> Please report this on https://github.com/commercialhaskell/stack/issues <https://github.com/commercialhaskell/stack/issues>
> [...]
> 
> In ancient times, locking over NFS didn't work, or at least not reliably. With NFS 4, locking was added to the protocol IIRC, but I have no clue how good it works, especially when you mix various platforms/implementations. What the current state with CIFS regarding locking is: I don't know, but in general I don't really trust remote file systems in this area. :-}
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210226/be127269/attachment.html>