From mblazevic at stilo.com  Tue Jun  1 17:16:57 2021
From: mblazevic at stilo.com (Mario Blazevic)
Date: Tue, 1 Jun 2021 13:16:57 -0400
Subject: [Haskell-cafe] Generic Traversal of ASTs
In-Reply-To: <CAChL11bQMJ65y_2LirybWTmu8kCbMEa3V-DDviUH0U_tcfBtNA@mail.gmail.com>
References: <CAChL11bQMJ65y_2LirybWTmu8kCbMEa3V-DDviUH0U_tcfBtNA@mail.gmail.com>
Message-ID: <CAP-J8jUf27h1q=9L3NNRk897Cw-vgiV688NcLAPVReEtGTQ8sQ@mail.gmail.com>

Have you tried Multiplate?

If Multiplate is not powerful enough and you're willing to make your types
more complex, have a look at deep-transformations.


On Mon, May 24, 2021 at 4:52 PM Richard Yu <richardyu042 at gmail.com> wrote:

> I have a question about generic traversal/transformation of nested data
> structures. From what I understand the main options available are SYB,
> Uniplate, GHC.Generics and Data.Lens (although I am under the impression
> this requires record types). The data structure I am attempting to traverse
> is similar to this simplified version:
>
> data SExpr = Expr | Const
> data Const = B bool | I int
> data Expr  = Lambda String SExpr | If Expr ...
>
> I have attempted to use Uniplate and GHC.Generics to traverse the built
> AST and modify for example, the string of a Lambda type, but have not been
> able to figure out how to get any of the libraries to typecheck. The
> examples or docs I found were not quite enough. Does anyone know of
> examples that might help or explain how I should be using the generic
> libraries?
> In addition if I moved to writing the AST with GADTs, do some generic
> traversal strategies/libraries stop working?
>
>
> Many 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/20210601/eb7f4101/attachment.html>

From richardyu042 at gmail.com  Wed Jun  2 05:02:43 2021
From: richardyu042 at gmail.com (Richard Yu)
Date: Wed, 2 Jun 2021 01:02:43 -0400
Subject: [Haskell-cafe] Generic Traversal of ASTs
In-Reply-To: <CAP-J8jUf27h1q=9L3NNRk897Cw-vgiV688NcLAPVReEtGTQ8sQ@mail.gmail.com>
References: <CAChL11bQMJ65y_2LirybWTmu8kCbMEa3V-DDviUH0U_tcfBtNA@mail.gmail.com>
 <CAP-J8jUf27h1q=9L3NNRk897Cw-vgiV688NcLAPVReEtGTQ8sQ@mail.gmail.com>
Message-ID: <CAChL11b7V1B8Ky69jmsG7fTJ-Pt5swrbyP8JEw5GFVs1tm60Sg@mail.gmail.com>

Multiplate actually looks very likely for my use case - I figured there
must be some prior work in this area that I had not found yet, so thanks!
As sort of a follow up, is there a quick way to try out all of these
libraries without having to setup a new stack project every time? I used to
use the arch packages to manually invoke ghc on small files, but that only
works if the package is on the aur so I was wondering if anyone had any
thoughts.

Thanks,
Richard

On Tue, Jun 1, 2021 at 1:17 PM Mario Blazevic <mblazevic at stilo.com> wrote:

> Have you tried Multiplate?
>
> If Multiplate is not powerful enough and you're willing to make your types
> more complex, have a look at deep-transformations.
>
>
> On Mon, May 24, 2021 at 4:52 PM Richard Yu <richardyu042 at gmail.com> wrote:
>
>> I have a question about generic traversal/transformation of nested data
>> structures. From what I understand the main options available are SYB,
>> Uniplate, GHC.Generics and Data.Lens (although I am under the impression
>> this requires record types). The data structure I am attempting to traverse
>> is similar to this simplified version:
>>
>> data SExpr = Expr | Const
>> data Const = B bool | I int
>> data Expr  = Lambda String SExpr | If Expr ...
>>
>> I have attempted to use Uniplate and GHC.Generics to traverse the built
>> AST and modify for example, the string of a Lambda type, but have not been
>> able to figure out how to get any of the libraries to typecheck. The
>> examples or docs I found were not quite enough. Does anyone know of
>> examples that might help or explain how I should be using the generic
>> libraries?
>> In addition if I moved to writing the AST with GADTs, do some generic
>> traversal strategies/libraries stop working?
>>
>>
>> Many 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.
>
>

-- 
Richard Yu
B.S Aerospace Engineering | B.S Computer Science
Gemstone Honors Program
University of Maryland, College Park
https://github.com/beForged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210602/f28631de/attachment.html>

From lysxia at gmail.com  Wed Jun  2 11:17:29 2021
From: lysxia at gmail.com (Li-yao Xia)
Date: Wed, 2 Jun 2021 07:17:29 -0400
Subject: [Haskell-cafe] Generic Traversal of ASTs
In-Reply-To: <CAChL11b7V1B8Ky69jmsG7fTJ-Pt5swrbyP8JEw5GFVs1tm60Sg@mail.gmail.com>
References: <CAChL11bQMJ65y_2LirybWTmu8kCbMEa3V-DDviUH0U_tcfBtNA@mail.gmail.com>
 <CAP-J8jUf27h1q=9L3NNRk897Cw-vgiV688NcLAPVReEtGTQ8sQ@mail.gmail.com>
 <CAChL11b7V1B8Ky69jmsG7fTJ-Pt5swrbyP8JEw5GFVs1tm60Sg@mail.gmail.com>
Message-ID: <a6fdb46c-6f2b-8635-8f43-18c719b9348e@gmail.com>

 > As sort of a follow up, is there a quick way to try out all of these
 > libraries without having to setup a new stack project every time?


You can use "stack install" and "stack ghc" outside of any stack project 
(no "stack.yaml" in any preceding directory). It will read 
"~/.stack/global-config/stack.yaml", that's where you can set the 
resolver and add "extra-deps" for packages not on stackage.

Li-yao

On 6/2/2021 1:02 AM, Richard Yu wrote:
> Multiplate actually looks very likely for my use case - I figured there 
> must be some prior work in this area that I had not found yet, so thanks!
> As sort of a follow up, is there a quick way to try out all of these 
> libraries without having to setup a new stack project every time? I used 
> to use the arch packages to manually invoke ghc on small files, but that 
> only works if the package is on the aur so I was wondering if anyone had 
> any thoughts.
> 
> Thanks,
> Richard
> 
> On Tue, Jun 1, 2021 at 1:17 PM Mario Blazevic <mblazevic at stilo.com 
> <mailto:mblazevic at stilo.com>> wrote:
> 
>     Have you tried Multiplate?
> 
>     If Multiplate is not powerful enough and you're willing to make your
>     types more complex, have a look at deep-transformations.
> 
> 
>     On Mon, May 24, 2021 at 4:52 PM Richard Yu <richardyu042 at gmail.com
>     <mailto:richardyu042 at gmail.com>> wrote:
> 
>         I have a question about generic traversal/transformation of
>         nested data structures. From what I understand the main options
>         available are SYB, Uniplate, GHC.Generics and Data.Lens
>         (although I am under the impression this requires record types).
>         The data structure I am attempting to traverse is similar to
>         this simplified version:
> 
>         data SExpr = Expr | Const
>         data Const = B bool | I int
>         data Expr  = Lambda String SExpr | If Expr ...
> 
>         I have attempted to use Uniplate and GHC.Generics to traverse
>         the built AST and modify for example, the string of a Lambda
>         type, but have not been able to figure out how to get any of the
>         libraries to typecheck. The examples or docs I found were not
>         quite enough. Does anyone know of examples that might help or
>         explain how I should be using the generic libraries?
>         In addition if I moved to writing the AST with GADTs, do some
>         generic traversal strategies/libraries stop working?
> 
> 
>         Many 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
>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>         Only members subscribed via the mailman list are allowed to post.
> 
> 
> 
> -- 
> Richard Yu
> B.S Aerospace Engineering | B.S Computer Science
> Gemstone Honors Program
> University of Maryland, College Park
> https://github.com/beForged <https://github.com/beForged>
> 
> 
> _______________________________________________
> 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 icfp.publicity at googlemail.com  Wed Jun  2 19:11:49 2021
From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt)
Date: Wed, 02 Jun 2021 15:11:49 -0400
Subject: [Haskell-cafe] Call for Tutorial, Panel,
	and Discussion Proposals: ICFP 2021
Message-ID: <60b7d7f55ec60_24cee2941419@homer.mail>

        CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS
                            ICFP 2020
 25th ACM SIGPLAN International Conference on Functional Programming


                       August 22 - 27, 2021
                              Virtual
                    https://icfp21.sigplan.org/

The 25th ACM SIGPLAN International Conference on Functional Programming
will be held virtually on August 22-27, 2021.
ICFP provides a forum for researchers and developers to hear about the 
latest work on the design, implementations, principles, and uses of 
functional programming.

Proposals are invited for tutorials, lasting approximately 3 hours each,
to be presented during ICFP and its co-located workshops and other
events. These tutorials are the successor to the CUFP tutorials from
previous years, but we also welcome tutorials whose primary audience is
researchers rather than practitioners. Tutorials may focus either on a
concrete technology or on a theoretical or mathematical tool. Ideally,
tutorials will have a concrete result, such as "Learn to do X with Y"
rather than "Learn language Y". 

Just like last year, following the success of the #ShutDownPL event @ ICFP, 
we are also inviting proposals for panels and discussions on topics of 
broader interest to the PL community.

Tutorials, panels, and discussions may occur before or after ICFP, 
co-located with the associated workshops, on August 22 or August 26-27.


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

Submission details
 Deadline for submission:     June 28th, 2020
 Notification of acceptance:  July 5th, 2020

Prospective organizers of tutorials are invited to submit a completed
tutorial proposal form in plain text format to the ICFP 2021 workshop
co-chairs (Leonidas Lampropoulos and Zoe Paraskevopoulou), via email to

             icfp-workshops-2021 at googlegroups.com
    
by June 28th, 2021. Please note that this is a firm deadline.

Organizers will be notified if their event proposal is accepted by
July 5th, 2021.

The proposal form is available at:

http://www.icfpconference.org/icfp2021-files/icfp21-panel-form.txt
http://www.icfpconference.org/icfp2021-files/icfp21-tutorials-form.txt

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

Selection committee

The proposals will be evaluated by a committee comprising the
following members of the ICFP 2021 organizing committee.

 Tutorials Co-Chair: Zoe Paraskevopoulou                 (Northeastern)
 Tutorials Co-Chair: Leonidas Lampropoulos     (University of Maryland)
 General Chair:      Sukyoung Ryu                               (KAIST)
 Program Chair:      Ron Garcia        (University of British Columbia)


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

Further information

Any queries should be addressed to the tutorial co-chairs (
Leonidas Lampropoulos and Zoe Paraskevopoulou), via email to 
icfp-workshops-2021 at googlegroups.com

From travis.cardwell at extrema.is  Thu Jun  3 02:06:23 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Thu, 3 Jun 2021 11:06:23 +0900
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
Message-ID: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>

I am happy to announce the 1.0 release of TTC (Textual Type Classes).

The library provides the following functionality:

* The Textual type class is used to convert between common textual data
  types.  It can be used to write functions that accept or return values
  of any of these textual data types.

* The Render type class is used to render a value as text.  Avoid bugs
  by only using Show for debugging/development purposes.

* The Parse type class is used to parse a value from text.  Unlike Read,
  it has support for error messages.

* Validate constants at compile-time using Parse instances.

Links:

* GitHub: https://github.com/ExtremaIS/ttc-haskell
* Hackage: https://hackage.haskell.org/package/ttc
* Guided Tour: https://www.extrema.is/articles/ttc-textual-type-classes

Best regards,

Travis

From lemming at henning-thielemann.de  Thu Jun  3 05:57:25 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 3 Jun 2021 07:57:25 +0200 (CEST)
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
Message-ID: <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>


On Thu, 3 Jun 2021, Travis Cardwell via Haskell-Cafe wrote:

> I am happy to announce the 1.0 release of TTC (Textual Type Classes).
>
> The library provides the following functionality:
>
> * The Textual type class is used to convert between common textual data
>  types.  It can be used to write functions that accept or return values
>  of any of these textual data types.
>
> * The Render type class is used to render a value as text.  Avoid bugs
>  by only using Show for debugging/development purposes.

That is, your class is intended for text representation for program users 
(instead of programmers)?

I think a notable difference between Show (which is for programmers) and a 
human readable text formatter should be a control of formatting details.

Currently 'printf' is the way to format human readable text and you can 
control formatting of numbers e.g. by "%d", "%3d", "%03d" etc. It's not 
type safe but better than Show.

From travis.cardwell at extrema.is  Thu Jun  3 07:43:55 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Thu, 3 Jun 2021 16:43:55 +0900
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
Message-ID: <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>

On Thu, Jun 3, 2021 at 2:57 PM Henning Thielemann wrote:
> That is, your class is intended for text representation for program users
> (instead of programmers)?

Yes, that is correct.  While Show instances should produce valid Haskell
code and Read instances should parse that code to create the original
value, forming an isomorphism, the Render and Parse type classes can be
used by the developer to define instances as required for each
particular application.  The Render and Parse type classes in Data.TTC
have no instances, allowing developers to write their own instances for
Int for example, but some default instances can optionally be imported
from Data.TTC.Instances when they are appropriate.

> I think a notable difference between Show (which is for programmers) and a
> human readable text formatter should be a control of formatting details.
>
> Currently 'printf' is the way to format human readable text and you can
> control formatting of numbers e.g. by "%d", "%3d", "%03d" etc. It's not
> type safe but better than Show.

Indeed.  Due to the nature of type classes, each concrete type can have
a single instance.  I usually define Render and Parse instances that use
the canonical representation, and I provide separate functions for
customized formatting based on options.  Functions that only need the
canonical representation can rely on the Render instance, while
functions that need to be more flexible can accept a render/formatting
function, to which TTC.render can be passed when the canonical
representation is sufficient.

I worry that my explanation is not clear, so here is a minimal example,
using a type Quantity that is assumed to have a Render instance.

    -- This function relies on the Render instance of Quantity.
    formatQuantityList :: [Quantity] -> Text

    -- This function allows you to customize how a Quantity is rendered.
    -- TTC.render can be passed as the first argument when appropriate.
    formatQuantityList' :: (Quantity -> Text) -> [Quantity] -> Text

The common way to get around the one-instance-per-type limitation is to
use newtypes.  I generally do not use this strategy with TTC to
provide different ways to format text, however.

Best regards,

Travis

From lemming at henning-thielemann.de  Thu Jun  3 07:49:49 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 3 Jun 2021 09:49:49 +0200 (CEST)
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
Message-ID: <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>


On Thu, 3 Jun 2021, Travis Cardwell wrote:

> On Thu, Jun 3, 2021 at 2:57 PM Henning Thielemann wrote:
>> That is, your class is intended for text representation for program users
>> (instead of programmers)?
>
> Yes, that is correct.  While Show instances should produce valid Haskell
> code and Read instances should parse that code to create the original
> value, forming an isomorphism, the Render and Parse type classes can be
> used by the developer to define instances as required for each
> particular application.  The Render and Parse type classes in Data.TTC
> have no instances, allowing developers to write their own instances for
> Int for example, but some default instances can optionally be imported
> from Data.TTC.Instances when they are appropriate.

Are these instances orphan?


> The common way to get around the one-instance-per-type limitation is to 
> use newtypes.  I generally do not use this strategy with TTC to provide 
> different ways to format text, however.

Is it feasible to have a newtype for any of "%3d", "%03d", "%05d" ...?

From travis.cardwell at extrema.is  Thu Jun  3 09:05:54 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Thu, 3 Jun 2021 18:05:54 +0900
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
 <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
Message-ID: <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>

On Thu, Jun 3, 2021 at 4:49 PM Henning Thielemann wrote:
> On Thu, 3 Jun 2021, Travis Cardwell wrote:
> > The Render and Parse type classes in Data.TTC
> > have no instances, allowing developers to write their own instances for
> > Int for example, but some default instances can optionally be imported
> > from Data.TTC.Instances when they are appropriate.
>
> Are these instances orphan?

Indeed they are.  I use the following directive to hide the warnings for
that module:

    {-# OPTIONS_GHC -fno-warn-orphans #-}

> > The common way to get around the one-instance-per-type limitation is to
> > use newtypes.  I generally do not use this strategy with TTC to provide
> > different ways to format text, however.
>
> Is it feasible to have a newtype for any of "%3d", "%03d", "%05d" ...?

In cases where the formats are fixed and finite/few, one could create
a newtype corresponding to each format.  Personally, I think that using
a formatting function would result in a better design in most cases,
however.

For example, one might want to format numbers according to locale, using
appropriate decimal separators.  If newtypes are defined for each
supported format, the constructor could be passed to functions to
determine how values are formatted.

    formatQuantityList
      :: TTC.Render a
      => (Quantity -> a)
      -> [Quantity]
      -> TLB.Builder

In my opinion, passing a formatting function instead results in a better
design because it is more flexible.

    formatQuantityList
      :: (Quantity -> TLB.Builder)
      -> [Quantity]
      -> TLB.Builder

This function might be called as follows, where locale is a sum type
that enumerates the supported locales (instead of using newtypes) and
the formatFor function formats the Quantity value appropriately for the
specified locale:

    formatQuantityList (Quantity.formatFor locale) quantities

I hope that I understood your question correctly and that my response is
helpful.

Best regards,

Travis

From lemming at henning-thielemann.de  Thu Jun  3 09:18:20 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 3 Jun 2021 11:18:20 +0200 (CEST)
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
 <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
 <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>
Message-ID: <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>


On Thu, 3 Jun 2021, Travis Cardwell wrote:

> On Thu, Jun 3, 2021 at 4:49 PM Henning Thielemann wrote:
>> On Thu, 3 Jun 2021, Travis Cardwell wrote:
>>> The Render and Parse type classes in Data.TTC
>>> have no instances, allowing developers to write their own instances for
>>> Int for example, but some default instances can optionally be imported
>>> from Data.TTC.Instances when they are appropriate.
>>
>> Are these instances orphan?
>
> Indeed they are.  I use the following directive to hide the warnings for
> that module:
>
>    {-# OPTIONS_GHC -fno-warn-orphans #-}

I would not do that. Even orphan instances must be unique. If I would 
decide to define my own instances but import a library that transitively 
imports Data.TTC.Instances somewhere, I get a clash. Orphan instances are 
really only helpful for the case where you need an instance but you 
neither maintain the class nor the type definition but otherwise are sure 
that your instance is the one and only.

From migmit at gmail.com  Thu Jun  3 09:44:45 2021
From: migmit at gmail.com (MigMit)
Date: Thu, 3 Jun 2021 11:44:45 +0200
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
 <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
 <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>
 <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>
Message-ID: <7E7D0333-FF3C-48C6-81CF-5BC10EBED2F2@gmail.com>

Agreed. I like to use DefaultSignatures like this:

class Parse a where
  parse :: ...
  default parse :: ParseInternal a => ... -- same ... as above
  parse = parseInternal

class ParseInternal a where
  parseInternal :: ... -- again, same ...

instance ParseInternal Double where
  parseInternal = ... -- specific implementation
instance ParseInternal Float where
  parseInternal = ... -- specific implementation

Then all the user needs to do is to say

instance Parse Double

and it would automagically use the provided implementation.

> On 3 Jun 2021, at 11:18, Henning Thielemann <lemming at henning-thielemann.de> wrote:
> 
> 
> On Thu, 3 Jun 2021, Travis Cardwell wrote:
> 
>> On Thu, Jun 3, 2021 at 4:49 PM Henning Thielemann wrote:
>>> On Thu, 3 Jun 2021, Travis Cardwell wrote:
>>>> The Render and Parse type classes in Data.TTC
>>>> have no instances, allowing developers to write their own instances for
>>>> Int for example, but some default instances can optionally be imported
>>>> from Data.TTC.Instances when they are appropriate.
>>> 
>>> Are these instances orphan?
>> 
>> Indeed they are.  I use the following directive to hide the warnings for
>> that module:
>> 
>>   {-# OPTIONS_GHC -fno-warn-orphans #-}
> 
> I would not do that. Even orphan instances must be unique. If I would decide to define my own instances but import a library that transitively imports Data.TTC.Instances somewhere, I get a clash. Orphan instances are really only helpful for the case where you need an instance but you neither maintain the class nor the type definition but otherwise are sure that your instance is the one and only.
> _______________________________________________
> 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 x at tomsmeding.com  Thu Jun  3 09:58:39 2021
From: x at tomsmeding.com (Tom Smeding)
Date: Thu, 03 Jun 2021 09:58:39 +0000
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <7E7D0333-FF3C-48C6-81CF-5BC10EBED2F2@gmail.com>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
 <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
 <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>
 <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>
 <7E7D0333-FF3C-48C6-81CF-5BC10EBED2F2@gmail.com>
Message-ID: <b2b17bb1-73a9-73c6-8e8b-8d348d6bcd22@tomsmeding.com>

On 3 Jun 2021, at 11:18, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
 >> I would not do that. Even orphan instances must be unique. If I
would decide to define my own instances but import a library that
transitively imports Data.TTC.Instances somewhere, I get a clash. Orphan
instances are really only helpful for the case where you need an
instance but you neither maintain the class nor the type definition but
otherwise are sure that your instance is the one and only.

While this is true, as far as I understand, avoiding orphan instances
(be it using MigMit's method below or by directly providing instances in
the library) requires that the library that provides the type class (TTC
in this case) depend on all packages necessary to even be able to write
those instances.

While this is clearly not an issue for Base types like Int, Float etc.,
some libraries seem to have the tendency to provide instances for random
data types that require pulling in additional dependencies that no-one
in the tree actually needs.

As someone who always gets slightly depressed when `cabal install XYZ`
gives a multi-screen list of packages to compile, I would like to
suggest that providing pre-made instances is cool, as long as that
doesn't introduce extra dependencies for the type-class-providing library.

How to solve the orphan problem, I also don't know. :)

Cheers,
Tom

On 03/06/2021 11:44, MigMit wrote:
> Agreed. I like to use DefaultSignatures like this:
>
> class Parse a where
>    parse :: ...
>    default parse :: ParseInternal a => ... -- same ... as above
>    parse = parseInternal
>
> class ParseInternal a where
>    parseInternal :: ... -- again, same ...
>
> instance ParseInternal Double where
>    parseInternal = ... -- specific implementation
> instance ParseInternal Float where
>    parseInternal = ... -- specific implementation
>
> Then all the user needs to do is to say
>
> instance Parse Double
>
> and it would automagically use the provided implementation.
>
>> On 3 Jun 2021, at 11:18, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>>
>>
>> On Thu, 3 Jun 2021, Travis Cardwell wrote:
>>
>>> On Thu, Jun 3, 2021 at 4:49 PM Henning Thielemann wrote:
>>>> On Thu, 3 Jun 2021, Travis Cardwell wrote:
>>>>> The Render and Parse type classes in Data.TTC
>>>>> have no instances, allowing developers to write their own instances for
>>>>> Int for example, but some default instances can optionally be imported
>>>>> from Data.TTC.Instances when they are appropriate.
>>>>
>>>> Are these instances orphan?
>>>
>>> Indeed they are.  I use the following directive to hide the warnings for
>>> that module:
>>>
>>>    {-# OPTIONS_GHC -fno-warn-orphans #-}
>>
>> I would not do that. Even orphan instances must be unique. If I would decide to define my own instances but import a library that transitively imports Data.TTC.Instances somewhere, I get a clash. Orphan instances are really only helpful for the case where you need an instance but you neither maintain the class nor the type definition but otherwise are sure that your instance is the one and only.
>> _______________________________________________
>> 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 travis.cardwell at extrema.is  Thu Jun  3 10:01:23 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Thu, 3 Jun 2021 19:01:23 +0900
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
 <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
 <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>
 <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>
Message-ID: <CACaJP_S07DFYQZ45h6g4omw2YgQdGv-gQ4j1LVfEOCvKdA5kNg@mail.gmail.com>

On Thu, Jun 3, 2021 at 6:18 PM Henning Thielemann wrote:
> On Thu, 3 Jun 2021, Travis Cardwell wrote:
> > On Thu, Jun 3, 2021 at 4:49 PM Henning Thielemann wrote:
> >> On Thu, 3 Jun 2021, Travis Cardwell wrote:
> >>> The Render and Parse type classes in Data.TTC
> >>> have no instances, allowing developers to write their own instances for
> >>> Int for example, but some default instances can optionally be imported
> >>> from Data.TTC.Instances when they are appropriate.
> >>
> >> Are these instances orphan?
> >
> > Indeed they are.  I use the following directive to hide the warnings for
> > that module:
> >
> >    {-# OPTIONS_GHC -fno-warn-orphans #-}
>
> I would not do that. Even orphan instances must be unique. If I would
> decide to define my own instances but import a library that transitively
> imports Data.TTC.Instances somewhere, I get a clash. Orphan instances are
> really only helpful for the case where you need an instance but you
> neither maintain the class nor the type definition but otherwise are sure
> that your instance is the one and only.

Indeed.  It seems that I have forgotten to put a prominent warning about
usage of those instances.

In the past, I have used TTC in applications, avoiding using it in
(shared) libraries.  In shared libraries, I simply define "render" and
"parse" functions using the most appropriate textual types.
Applications can then define (orphan) instances of Render and Parse as
simple wrappers around the functions exposed by the library.  By only
defining instances in the leaves of the dependency hierarchy, one does
not run into conflicts.

Very recently, I have started to use TTC in libraries as well, however,
in cases where I would otherwise have to duplicate functionality that
TTC provides.  I had planned on advising not using TTC in libraries, but
I ended up deciding to not do so.

Frankly, I have never used Data.TTC.Instances myself.  I included it in
an attempt to provide convenience for others.  It is indeed extremely
inconvenient if a shared library imports the instances, and that is
possible->probable even with a prominent warning against doing so.
Perhaps it would be best to remove the Data.TTC.Instances module as well
as add a prominent warning against declaring orphan instances,
especially in a shared library.

Thank you very much for the feedback!  I really appreciate it!

Best regards,

Travis

From travis.cardwell at extrema.is  Thu Jun  3 10:21:30 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Thu, 3 Jun 2021 19:21:30 +0900
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <7E7D0333-FF3C-48C6-81CF-5BC10EBED2F2@gmail.com>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
 <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
 <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>
 <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>
 <7E7D0333-FF3C-48C6-81CF-5BC10EBED2F2@gmail.com>
Message-ID: <CACaJP_RorxEuuSVi=YD3LEUUOg2XKayDcrmsiNiA5SOTXr6ZYQ@mail.gmail.com>

On Thu, Jun 3, 2021 at 6:44 PM MigMit wrote:
> Agreed. I like to use DefaultSignatures like this:
<SNIP>
> Then all the user needs to do is to say
>
> instance Parse Double
>
> and it would automagically use the provided implementation.

This looks like a great compromise, allowing developers to utilize the
default implementation for a specific type with very little code.  A
prominent warning against doing so in shared libraries would still be
needed, of course.  I look forward to experimenting with this design
soon!

Thank you very much for the suggestion!  Also, thank you for the
example code, as this pattern is new to me.

Best regards,

Travis

From olf at aatal-apotheke.de  Thu Jun  3 20:21:32 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 3 Jun 2021 22:21:32 +0200 (CEST)
Subject: [Haskell-cafe] printf using values more than once
Message-ID: <alpine.DEB.2.20.2106032053300.1474@tarski.funk>

Dear Café,

since the topic recently was rendering text, I'd like to ask a related 
design question. I want a version of printf that
- is more type-safe because unused or surplus arguments cause compile-time 
errors,
- the formatting instructions can use arguments out of order and more than 
once, 
- is polymorphic in the text type being built: Suppose I want to build a 
Pandoc Block but the holes are of type Inline. The format string must 
therefore be able to promote the Block type's constructors to constructors 
with holes.

The closest match I know of is HoleyMonoid [1] but it only provides 
printf-like holes, whereas I need named positional arguments like arg1, 
arg2 etc. that can be repeated. Document templating libraries provide 
these, but all templating libraries I looked at are type-unsafe.

In order to fulfill the second requirement, one could use the free monad 
over a Reader functor, e.g.
     Free ((->) (forall a. Show a => a)) String
with some custom instances. 
Here one can use the nesting levels of the free monad to encode the 
argument position. But it is just as type-unsafe as printf. Funneling 
return type constructors through this works sort of, but it's awkward.

One can achieve type saftey with type classes like printf does:
class Eventually r a where
    eventually :: r -> a
instance Eventually r r where
    eventually = id
instance (Eventually r a) => Eventually r (b -> a) where
    eventually r = const (eventually r)

This class can be used to inject constant Text into any nesting of
(Text -> ... -> Text -> Text)
and argument position is indeed function argument position. But using this 
system often leads to type ambiguity errors. Also, it is so type-safe that 
it is impossible to write a function taking a natural number and returning 
the hole of the corresponding position: Such a function would be 
dependently-typed.

My current best implementation uses a combination of Eventually and 
HoleyMonoid, but I'm not entirely satisfied.

Olaf

[1] https://hackage.haskell.org/package/HoleyMonoid

From migmit at gmail.com  Thu Jun  3 21:12:01 2021
From: migmit at gmail.com (MigMit)
Date: Thu, 3 Jun 2021 23:12:01 +0200
Subject: [Haskell-cafe] printf using values more than once
In-Reply-To: <alpine.DEB.2.20.2106032053300.1474@tarski.funk>
References: <alpine.DEB.2.20.2106032053300.1474@tarski.funk>
Message-ID: <881F1230-D38B-4C29-94CA-3303BCA8822A@gmail.com>

At this point I'm not sure how it is different from a simple function. The HoleyMonoid example

> holey = now "x = " . later show . now ", y = " . later show

when paired with 'argn'-style variables essentially becomes

> holey arg1 arg2 = "y = " ++ show arg2 ++ "; x = " ++ show arg1

So, what kind of syntax do you have in mind?

> On 3 Jun 2021, at 22:21, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> 
> Dear Café,
> 
> since the topic recently was rendering text, I'd like to ask a related design question. I want a version of printf that
> - is more type-safe because unused or surplus arguments cause compile-time errors,
> - the formatting instructions can use arguments out of order and more than once, - is polymorphic in the text type being built: Suppose I want to build a Pandoc Block but the holes are of type Inline. The format string must therefore be able to promote the Block type's constructors to constructors with holes.
> 
> The closest match I know of is HoleyMonoid [1] but it only provides printf-like holes, whereas I need named positional arguments like arg1, arg2 etc. that can be repeated. Document templating libraries provide these, but all templating libraries I looked at are type-unsafe.
> 
> In order to fulfill the second requirement, one could use the free monad over a Reader functor, e.g.
>    Free ((->) (forall a. Show a => a)) String
> with some custom instances. Here one can use the nesting levels of the free monad to encode the argument position. But it is just as type-unsafe as printf. Funneling return type constructors through this works sort of, but it's awkward.
> 
> One can achieve type saftey with type classes like printf does:
> class Eventually r a where
>   eventually :: r -> a
> instance Eventually r r where
>   eventually = id
> instance (Eventually r a) => Eventually r (b -> a) where
>   eventually r = const (eventually r)
> 
> This class can be used to inject constant Text into any nesting of
> (Text -> ... -> Text -> Text)
> and argument position is indeed function argument position. But using this system often leads to type ambiguity errors. Also, it is so type-safe that it is impossible to write a function taking a natural number and returning the hole of the corresponding position: Such a function would be dependently-typed.
> 
> My current best implementation uses a combination of Eventually and HoleyMonoid, but I'm not entirely satisfied.
> 
> Olaf
> 
> [1] https://hackage.haskell.org/package/HoleyMonoid_______________________________________________
> 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 travis.cardwell at extrema.is  Fri Jun  4 03:01:01 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Fri, 4 Jun 2021 12:01:01 +0900
Subject: [Haskell-cafe] [ANN] ttc-1.0.0.0 - Textual Type Classes
In-Reply-To: <CACaJP_RorxEuuSVi=YD3LEUUOg2XKayDcrmsiNiA5SOTXr6ZYQ@mail.gmail.com>
References: <CACaJP_RrhFkmEJqcOm28FxNvLrHNWE8TWwj5NeGrDsnnK7G0Ew@mail.gmail.com>
 <4ed88d67-76bf-565f-d9ac-eae6cc89a9@henning-thielemann.de>
 <CACaJP_Rj-1t-U950hO=sNQ0a5J4v97xLut=_8PRzVarRnhd0sA@mail.gmail.com>
 <b12766c-5bfc-301a-fc8-92751aecaedb@henning-thielemann.de>
 <CACaJP_SaB_fbLOVWJOVuH+E0_pj72npEeY1inSgin987PBppcw@mail.gmail.com>
 <789212c9-a3a1-dea5-7bb5-eb6b337fec@henning-thielemann.de>
 <7E7D0333-FF3C-48C6-81CF-5BC10EBED2F2@gmail.com>
 <CACaJP_RorxEuuSVi=YD3LEUUOg2XKayDcrmsiNiA5SOTXr6ZYQ@mail.gmail.com>
Message-ID: <CACaJP_TNFRAS+-Mxm9aCM0LLcLmXc2CQ-rZpRR_vC+DVZ1QvqA@mail.gmail.com>

I have created an issue on GitHub concerning the orphan instances.

https://github.com/ExtremaIS/ttc-haskell/issues/1

Thank you very much for the feedback and advice so far.  Anybody who
would like to weigh in is welcome to add a comment to the GitHub issue
or reply on this thread.  I avoided editorializing in the issue
description, but please feel free to express opinions and preferences.

Best regards,

Travis

From olf at aatal-apotheke.de  Fri Jun  4 07:32:33 2021
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Fri, 4 Jun 2021 09:32:33 +0200 (CEST)
Subject: [Haskell-cafe] printf using values more than once
In-Reply-To: <881F1230-D38B-4C29-94CA-3303BCA8822A@gmail.com>
References: <alpine.DEB.2.20.2106032053300.1474@tarski.funk>
 <881F1230-D38B-4C29-94CA-3303BCA8822A@gmail.com>
Message-ID: <alpine.DEB.2.20.2106040911510.1795@tarski.funk>

On Thu, 3 Jun 2021, MigMit wrote:

> At this point I'm not sure how it is different from a simple function. The HoleyMonoid example
>
>> holey = now "x = " . later show . now ", y = " . later show
>
> when paired with 'argn'-style variables essentially becomes
>
>> holey arg1 arg2 = "y = " ++ show arg2 ++ "; x = " ++ show arg1
>
> So, what kind of syntax do you have in mind?

What I'm after is documentation of n-ary functions. Suppose

f :: a -> a -> Maybe a
f arg1 arg2 = if arg1 < arg2 then Nothing else Just arg2

The docstring of f should be a function that, given descriptions of the 
arguments, generates a description of the result. E.g.

doc_f = "if " <> arg1 <> " is smaller than " <> arg2 <> " then Nothing 
else Just " <> arg2

Say you have concrete arguments which are already tagged with a 
description:
x :: (String,a)
y :: (String,a)

One could then have an operator <%> that acts like function application 
but at the same time takes care of documentation:

func desc_f f <%> x <%> y :: (String,c)

Here 'func' is an operator that translates the hypothetical docstring type 
into a real function.

My provenience package currently burdens the user with constructing the 
docstrings by manually inserting the appropriate descriptions from x and y 
into doc_f. I'd like to automate that and make it more type-safe so that 
mismatch between documentation and type of f is a compile-time error.

Olaf

>
>> On 3 Jun 2021, at 22:21, Olaf Klinke <olf at aatal-apotheke.de> wrote:
>>
>> Dear Café,
>>
>> since the topic recently was rendering text, I'd like to ask a related design question. I want a version of printf that
>> - is more type-safe because unused or surplus arguments cause compile-time errors,
>> - the formatting instructions can use arguments out of order and more than once, - is polymorphic in the text type being built: Suppose I want to build a Pandoc Block but the holes are of type Inline. The format string must therefore be able to promote the Block type's constructors to constructors with holes.
>>
>> The closest match I know of is HoleyMonoid [1] but it only provides printf-like holes, whereas I need named positional arguments like arg1, arg2 etc. that can be repeated. Document templating libraries provide these, but all templating libraries I looked at are type-unsafe.
>>
>> In order to fulfill the second requirement, one could use the free monad over a Reader functor, e.g.
>>    Free ((->) (forall a. Show a => a)) String
>> with some custom instances. Here one can use the nesting levels of the free monad to encode the argument position. But it is just as type-unsafe as printf. Funneling return type constructors through this works sort of, but it's awkward.
>>
>> One can achieve type saftey with type classes like printf does:
>> class Eventually r a where
>>   eventually :: r -> a
>> instance Eventually r r where
>>   eventually = id
>> instance (Eventually r a) => Eventually r (b -> a) where
>>   eventually r = const (eventually r)
>>
>> This class can be used to inject constant Text into any nesting of
>> (Text -> ... -> Text -> Text)
>> and argument position is indeed function argument position. But using this system often leads to type ambiguity errors. Also, it is so type-safe that it is impossible to write a function taking a natural number and returning the hole of the corresponding position: Such a function would be dependently-typed.
>>
>> My current best implementation uses a combination of Eventually and HoleyMonoid, but I'm not entirely satisfied.
>>
>> Olaf
>>
>> [1] https://hackage.haskell.org/package/HoleyMonoid_______________________________________________
>> 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 lemming at henning-thielemann.de  Fri Jun  4 07:58:21 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 4 Jun 2021 09:58:21 +0200 (CEST)
Subject: [Haskell-cafe] printf using values more than once
In-Reply-To: <alpine.DEB.2.20.2106040911510.1795@tarski.funk>
References: <alpine.DEB.2.20.2106032053300.1474@tarski.funk>
 <881F1230-D38B-4C29-94CA-3303BCA8822A@gmail.com>
 <alpine.DEB.2.20.2106040911510.1795@tarski.funk>
Message-ID: <2cbc2236-315-fe72-1cfb-f0e29362146@henning-thielemann.de>


On Fri, 4 Jun 2021, Olaf Klinke wrote:

> On Thu, 3 Jun 2021, MigMit wrote:
>
>> At this point I'm not sure how it is different from a simple function. The 
>> HoleyMonoid example
>> 
>>> holey = now "x = " . later show . now ", y = " . later show
>> 
>> when paired with 'argn'-style variables essentially becomes
>> 
>>> holey arg1 arg2 = "y = " ++ show arg2 ++ "; x = " ++ show arg1
>> 
>> So, what kind of syntax do you have in mind?
>
> What I'm after is documentation of n-ary functions. Suppose
>
> f :: a -> a -> Maybe a
> f arg1 arg2 = if arg1 < arg2 then Nothing else Just arg2
>
> The docstring of f should be a function that, given descriptions of the 
> arguments, generates a description of the result. E.g.
>
> doc_f = "if " <> arg1 <> " is smaller than " <> arg2 <> " then Nothing else 
> Just " <> arg2
>
> Say you have concrete arguments which are already tagged with a description:
> x :: (String,a)
> y :: (String,a)
>
> One could then have an operator <%> that acts like function application but 
> at the same time takes care of documentation:
>
> func desc_f f <%> x <%> y :: (String,c)
>
> Here 'func' is an operator that translates the hypothetical docstring type 
> into a real function.


I don't fully understand the problem, but for me it sounds like an 
Applicative functor:

data T a = Cons String a

x,y :: T a

func desc_f f <*> x <*> y :: T c

From tdecacqu at redhat.com  Sat Jun  5 21:48:24 2021
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Sat, 05 Jun 2021 21:48:24 +0000
Subject: [Haskell-cafe] A matrix.org client library proposal
Message-ID: <878s3o3rvb.tristanC@fedora>


Dear Café,

I'd like to publish a rather simple `matrix-client` package on hackage
based on this implementation:
  https://github.com/softwarefactory-project/matrix-client-haskell

Please let me know if you are interested or if you have a similar
implementation we could collaborate on.

Kind Regards,
-Tristan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 515 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210605/b1e59ad0/attachment.sig>

From zubin at well-typed.com  Sun Jun  6 00:15:41 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sun, 6 Jun 2021 05:45:41 +0530
Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 8.10.5 released
Message-ID: <20210606001541.5am52lsjrpjlkcbx@zubin-msi>

The GHC team is very pleased to announce the availability of GHC
8.10.5. Source and binary distributions are available at the [usual
place](https://downloads.haskell.org/ghc/8.10.5/).

This release adds native ARM/Darwin support, as well as bringing
performance improvements and fixing numerous bugs of varying severity
present in the 8.10 series:

- First-class support for Apple M1 hardware using GHC's LLVM ARM backend

- Fix a bug resulting in segmentation faults where code may be unloaded
prematurely when using the parallel garbage collector (#19417) along
with other bugs in the GC and linker (#19147, #19287)

- Improve code layout fixing certain performance regressions (#18053)
and other code generation bug fixes (#19645)

- Bug fixes for signal handling when using the pthread itimer
implementation.

- Improvements to the specializer and simplifier reducing code size and
and memory usage (#17151, #18923,#18140, #10421, #18282, #13253).

- Fix a bug where typechecker plugins could be run with an inconsistent
typechecker environment (#19191).

- Fix a simplifier bug which lead to an exponential blow up and
excessive memory usage in certain cases

A complete list of bug fixes and improvements
can be found in the release notes: [release
notes](https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10.5-notes.html)

As always, feel free to report any issues you encounter via
[gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

From zubin at well-typed.com  Sun Jun  6 00:44:30 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sun, 6 Jun 2021 06:14:30 +0530
Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 8.10.5 released
In-Reply-To: <20210606001057.2ku6z5zjjv5skw7q@zubin-msi>
References: <20210606001057.2ku6z5zjjv5skw7q@zubin-msi>
Message-ID: <20210606004430.gc2a6t7eglidmri6@zubin-msi>

The correct link to the release notes is:

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

(Note the missing tilde)

Apolgies,
Zubin

From borgauf at gmail.com  Sun Jun  6 19:45:52 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Sun, 6 Jun 2021 14:45:52 -0500
Subject: [Haskell-cafe] Using stack outside the project box
Message-ID: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>

As a beginner, I was told to use stack. And I seemed to get something
Haskell installed initially on my Ubuntu 21.04. But stack seems to be
geared toward projects and compiling executables with ghc, and not a global
ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a
very nice "literate" programming in tandem with a running REPL in many
REPL-friendly languages, e.g., here are code blocks in an org-mode file

#+begin_src haskell :results silent :exports code
data Peano = Zero | Succ Peano deriving (Show)
#+end_src

#+begin_src haskell :results silent :exports code
myThree = Succ (Succ (Succ Zero))
#+end_src

#+begin_src haskell :results verbatim :exports both
myThree
#+end_src

#+RESULTS:
: Succ (Succ (Succ Zero))

I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a
running ghci REPL started up in another Emacs buffer. Supposedly, a
haskell-mode and a specific Babel ob-haskell package are working together
to enable this. And so it works okay, once quirks (must enclose multi-lined
code in :{..:} and every REPL session seems to need a :set +m as well). I'm
really quite happy with this way of doing things and have resisted the
whole monolithic 1) create project in a directory, 2) put code into .hs
file, 3) compile with ghc.

But what I'm constantly having problems with is getting additional packages
beyond the Prelude basics. My org files are in various directories, but I
want (like most languages offer) to simply interact with that language on a
global level wherever I am, whatever files and directories and Haskell code
I'm working on. Sometimes doing an import works; often enough not. Then I
have to do something with stack -- hopefully globally . . . and there the
confusion and inconsistencies begin. Lately I can't seem to get Safe
installed. And all docs about editing some yaml stuff get me lost in the
weeds quickly. What yaml where for my "global" situation?

If you simply say to me, Don't try to work outside of the project--hs
files--compile to executable framework I'll say okay, then have to decide
whether I want to stay within the org-mode world or leave Haskell for an
org-mode friendlier language. And no, lhs and jupyter are primitive
compared to org-mode literate programming. Both are a step backwards.

Any help on working outside the project box with stack, e.g., how to
install and use packages (and even how to update/upgrade ghc and ghci would
be a start!).

-
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210606/2f118d26/attachment.html>

From jclites at mac.com  Sun Jun  6 20:55:56 2021
From: jclites at mac.com (Jeff Clites)
Date: Sun, 6 Jun 2021 13:55:56 -0700
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
Message-ID: <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>

Run ‘stack ghci’ and it will log the path to the YAML file you can edit to customize what configuration it uses when run outside of a project. Here you can specify additional packages you want to be available, and you set the resolver version which controls the GHC version. (Then you configure emacs to run ‘stack ghci’ instead of ‘ghci’.)

Jeff

> On Jun 6, 2021, at 12:45 PM, Galaxy Being <borgauf at gmail.com> wrote:
> 
> As a beginner, I was told to use stack. And I seemed to get something Haskell installed initially on my Ubuntu 21.04. But stack seems to be geared toward projects and compiling executables with ghc, and not a global ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a very nice "literate" programming in tandem with a running REPL in many REPL-friendly languages, e.g., here are code blocks in an org-mode file
> 
> #+begin_src haskell :results silent :exports code
> data Peano = Zero | Succ Peano deriving (Show)
> #+end_src
> 
> #+begin_src haskell :results silent :exports code
> myThree = Succ (Succ (Succ Zero))
> #+end_src
> 
> #+begin_src haskell :results verbatim :exports both
> myThree
> #+end_src
> 
> #+RESULTS:
> : Succ (Succ (Succ Zero))
> 
> I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a running ghci REPL started up in another Emacs buffer. Supposedly, a haskell-mode and a specific Babel ob-haskell package are working together to enable this. And so it works okay, once quirks (must enclose multi-lined code in :{..:} and every REPL session seems to need a :set +m as well). I'm really quite happy with this way of doing things and have resisted the whole monolithic 1) create project in a directory, 2) put code into .hs file, 3) compile with ghc.
> 
> But what I'm constantly having problems with is getting additional packages beyond the Prelude basics. My org files are in various directories, but I want (like most languages offer) to simply interact with that language on a global level wherever I am, whatever files and directories and Haskell code I'm working on. Sometimes doing an import works; often enough not. Then I have to do something with stack -- hopefully globally . . . and there the confusion and inconsistencies begin. Lately I can't seem to get Safe installed. And all docs about editing some yaml stuff get me lost in the weeds quickly. What yaml where for my "global" situation?
> 
> If you simply say to me, Don't try to work outside of the project--hs files--compile to executable framework I'll say okay, then have to decide whether I want to stay within the org-mode world or leave Haskell for an org-mode friendlier language. And no, lhs and jupyter are primitive compared to org-mode literate programming. Both are a step backwards.
> 
> Any help on working outside the project box with stack, e.g., how to install and use packages (and even how to update/upgrade ghc and ghci would be a start!).
> 
> -
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210606/b2d4c4aa/attachment.html>

From borgauf at gmail.com  Sun Jun  6 21:08:42 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Sun, 6 Jun 2021 16:08:42 -0500
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
Message-ID: <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>

I could use some examples maybe. So I do

Prelude> :show paths
current working directory:
  /home/galaxybeing/Dropbox/org/RealWorldHaskell
module import search paths:
  .

...and there is no *.yaml file in this directory. I'm saying there's a
disjoint between where my ghci REPL inside of Emacs is working and the
actual :! pwd. And I when I do find the appropriate yaml I'd need some
examples on the way to add the correct lines to get the packages, the
ghc/ghci platform. I've tried just a generic stack command from the command
prompt, which I assumed would apply to wherever my "global" Haskell is --
to no avail, just cryptic errors talking about downloaded code examples.

On Sun, Jun 6, 2021 at 4:01 PM Jeff Clites via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Run ‘stack ghci’ and it will log the path to the YAML file you can edit to
> customize what configuration it uses when run outside of a project. Here
> you can specify additional packages you want to be available, and you set
> the resolver version which controls the GHC version. (Then you configure
> emacs to run ‘stack ghci’ instead of ‘ghci’.)
>
> Jeff
>
> On Jun 6, 2021, at 12:45 PM, Galaxy Being <borgauf at gmail.com> wrote:
>
> As a beginner, I was told to use stack. And I seemed to get something
> Haskell installed initially on my Ubuntu 21.04. But stack seems to be
> geared toward projects and compiling executables with ghc, and not a global
> ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a
> very nice "literate" programming in tandem with a running REPL in many
> REPL-friendly languages, e.g., here are code blocks in an org-mode file
>
> #+begin_src haskell :results silent :exports code
> data Peano = Zero | Succ Peano deriving (Show)
> #+end_src
>
> #+begin_src haskell :results silent :exports code
> myThree = Succ (Succ (Succ Zero))
> #+end_src
>
> #+begin_src haskell :results verbatim :exports both
> myThree
> #+end_src
>
> #+RESULTS:
> : Succ (Succ (Succ Zero))
>
> I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a
> running ghci REPL started up in another Emacs buffer. Supposedly, a
> haskell-mode and a specific Babel ob-haskell package are working together
> to enable this. And so it works okay, once quirks (must enclose multi-lined
> code in :{..:} and every REPL session seems to need a :set +m as well). I'm
> really quite happy with this way of doing things and have resisted the
> whole monolithic 1) create project in a directory, 2) put code into .hs
> file, 3) compile with ghc.
>
> But what I'm constantly having problems with is getting additional
> packages beyond the Prelude basics. My org files are in various
> directories, but I want (like most languages offer) to simply interact with
> that language on a global level wherever I am, whatever files and
> directories and Haskell code I'm working on. Sometimes doing an import
> works; often enough not. Then I have to do something with stack --
> hopefully globally . . . and there the confusion and inconsistencies begin.
> Lately I can't seem to get Safe installed. And all docs about editing
> some yaml stuff get me lost in the weeds quickly. What yaml where for my
> "global" situation?
>
> If you simply say to me, Don't try to work outside of the project--hs
> files--compile to executable framework I'll say okay, then have to decide
> whether I want to stay within the org-mode world or leave Haskell for an
> org-mode friendlier language. And no, lhs and jupyter are primitive
> compared to org-mode literate programming. Both are a step backwards.
>
> Any help on working outside the project box with stack, e.g., how to
> install and use packages (and even how to update/upgrade ghc and ghci would
> be a start!).
>
> -
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.
>
> _______________________________________________
> 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.



-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210606/35e2321e/attachment.html>

From jclites at mac.com  Sun Jun  6 23:09:34 2021
From: jclites at mac.com (Jeff Clites)
Date: Sun, 6 Jun 2021 16:09:34 -0700
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
Message-ID: <5D00443E-4C08-43C1-907D-5313E3DFCEA8@mac.com>

I believe you wanted to be able to run code without having to set up a project. If you run a stack command from outside of a project, there is a default stack.yaml that it uses. (That corresponds to a default “global” project.) If you run ‘stack ghci’ (just that, from a directory that doesn’t have a stack.yaml file) then it will log a message that tells you where that stack.yaml file is. It will probably be inside $HOME/.stack/global-project.

You can also specify a stack.yaml at some other arbitrary path via the “—stack-yaml” argument to stack, or via the STACK_YAML environment variable.

So that’s step one.

I don’t know how emacs’ org-mode Babel is running code, but if you get it to use “stack ghci” instead of “ghci” then you will opt it into this ecosystem.

Jeff

> On Jun 6, 2021, at 2:08 PM, Galaxy Being <borgauf at gmail.com> wrote:
> 
> I could use some examples maybe. So I do
> 
> Prelude> :show paths
> current working directory:
>   /home/galaxybeing/Dropbox/org/RealWorldHaskell
> module import search paths:
>   .
> 
> ...and there is no *.yaml file in this directory. I'm saying there's a disjoint between where my ghci REPL inside of Emacs is working and the actual :! pwd. And I when I do find the appropriate yaml I'd need some examples on the way to add the correct lines to get the packages, the ghc/ghci platform. I've tried just a generic stack command from the command prompt, which I assumed would apply to wherever my "global" Haskell is -- to no avail, just cryptic errors talking about downloaded code examples.
> 
>> On Sun, Jun 6, 2021 at 4:01 PM Jeff Clites via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
>> Run ‘stack ghci’ and it will log the path to the YAML file you can edit to customize what configuration it uses when run outside of a project. Here you can specify additional packages you want to be available, and you set the resolver version which controls the GHC version. (Then you configure emacs to run ‘stack ghci’ instead of ‘ghci’.)
>> 
>> Jeff
>> 
>>> On Jun 6, 2021, at 12:45 PM, Galaxy Being <borgauf at gmail.com> wrote:
>>> 
>>> As a beginner, I was told to use stack. And I seemed to get something Haskell installed initially on my Ubuntu 21.04. But stack seems to be geared toward projects and compiling executables with ghc, and not a global ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a very nice "literate" programming in tandem with a running REPL in many REPL-friendly languages, e.g., here are code blocks in an org-mode file
>>> 
>>> #+begin_src haskell :results silent :exports code
>>> data Peano = Zero | Succ Peano deriving (Show)
>>> #+end_src
>>> 
>>> #+begin_src haskell :results silent :exports code
>>> myThree = Succ (Succ (Succ Zero))
>>> #+end_src
>>> 
>>> #+begin_src haskell :results verbatim :exports both
>>> myThree
>>> #+end_src
>>> 
>>> #+RESULTS:
>>> : Succ (Succ (Succ Zero))
>>> 
>>> I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a running ghci REPL started up in another Emacs buffer. Supposedly, a haskell-mode and a specific Babel ob-haskell package are working together to enable this. And so it works okay, once quirks (must enclose multi-lined code in :{..:} and every REPL session seems to need a :set +m as well). I'm really quite happy with this way of doing things and have resisted the whole monolithic 1) create project in a directory, 2) put code into .hs file, 3) compile with ghc.
>>> 
>>> But what I'm constantly having problems with is getting additional packages beyond the Prelude basics. My org files are in various directories, but I want (like most languages offer) to simply interact with that language on a global level wherever I am, whatever files and directories and Haskell code I'm working on. Sometimes doing an import works; often enough not. Then I have to do something with stack -- hopefully globally . . . and there the confusion and inconsistencies begin. Lately I can't seem to get Safe installed. And all docs about editing some yaml stuff get me lost in the weeds quickly. What yaml where for my "global" situation?
>>> 
>>> If you simply say to me, Don't try to work outside of the project--hs files--compile to executable framework I'll say okay, then have to decide whether I want to stay within the org-mode world or leave Haskell for an org-mode friendlier language. And no, lhs and jupyter are primitive compared to org-mode literate programming. Both are a step backwards.
>>> 
>>> Any help on working outside the project box with stack, e.g., how to install and use packages (and even how to update/upgrade ghc and ghci would be a start!).
>>> 
>>> -
>>> ⨽
>>> Lawrence Bottorff
>>> Grand Marais, MN, USA
>>> borgauf at gmail.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.
>> _______________________________________________
>> 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.
> 
> 
> -- 
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210606/8d94e87b/attachment.html>

From travis.cardwell at extrema.is  Mon Jun  7 00:10:24 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Mon, 7 Jun 2021 09:10:24 +0900
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
Message-ID: <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>

The Stack configuration that is used outside of projects is stored in
the following location:

    ~/.stack/global-project/stack.yaml

This configuration file is used when you run `stack ghci` outside of a
project.  Such project configuration files can specify the Stackage
snapshot to be used (`resolver`), any packages that should be used that
are different from or not in the specified Stackage snapshot
(`extra-deps`), a list of packages that are being developed (`packages`,
none by default in the "global project"), as well as some other settings
documented at the following location.

https://docs.haskellstack.org/en/stable/yaml_configuration/

Such a project configuration file determines what packages are
*available* for use.  The motivation is to provide an environment where
all of the available packages work together, saving you from having to
deal with dependency conflicts.  It does not *expose* packages to the
compiler or REPL.  Packages are usually exposed by specifying them in a
`.cabal` file (or `package.yaml` file when using hpack).

In my experience, the `~/.stack/global-project/stack.yaml` configuration
is most often used when installing executables using Stack.  For example,
one can install the version of `hlint` that is in the Stackage snapshot
configured in the configuration file as follows:

    stack install hlint

What you would like to do is not normal usage of Stack, but I understand
your motivation.  It is possible to do what you want by configuring a
global project with the packages that you would like to make available.
First, create file `~/.stack/global-project/global-project.cabal` with
the following content:

    name:           global-project
    version:        0.0.0.0
    cabal-version:  1.24
    build-type:     Simple

    library
      build-depends:
          base
        , safe
      default-language: Haskell2010

Add any packages that you would like to expose to the `build-depends`
list.  Next, configure `~/.stack/global-project/stack.yaml` as follows:

    resolver: lts-17.14

    packages:
      - .

Update the `resolver` configuration whenever you want to change Stackage
snapshots.  Note that you will need to add `extra-deps` configuration to
this file if you ever want to expose a package that is not in the
configured snapshot, in addition to adding it to the `build-depends`
list.

With this configuration, the listed packages should be exposed when you
run `stack ghci` to run a REPL.

Good luck!

Travis

From borgauf at gmail.com  Mon Jun  7 21:22:30 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Mon, 7 Jun 2021 16:22:30 -0500
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
Message-ID: <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>

I installed stack on my Windows computer using chocolatey, which went
smoothly. But I had nothing anywhere I could find. On a hunch, at the
prompt I tried to run stack ghci, *then *it started downloading and
installing stuff. Good. I then was able to track down an example of a
stack.yaml in the ...stack/global-project directory. My whole motivation
was to see an actual global stack.yaml in the wild, and not have to
guess-and-test from the stack docs. Good. I duplicated

packages: []
resolver: lts-17.15

on my Ubuntu 21.04 in the .stack/global-project/stack.yaml. Tried running stack
ghci from the Ubuntu prompt, and, similarly, it started installing lots of
stuff. (The resolver version I replaced was lts-17.08. Why that old I don't
know.). But then I got a cryptic error as it seemed to clash or not like
something it saw in some obscure github directory I had cloned ages ago
with Haskell example code. I deleted everything in the github directory
that looked stack/cabal-ish and tried stack ghci again. Now it says

Warning (added by new or init): Some packages were found to have names
conflicting with others and have been commented out in the packages section.
Warning (added by new or init): Some packages were found to be incompatible
with the resolver and have been left commented out in the packages section.
You can omit this message by removing it from stack.yaml

Stack looks for packages in the directories configured in
the 'packages' and 'extra-deps' fields defined in your stack.yaml
The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
but no .cabal or package.yaml file could be found there.

Yes, that was the directory I purged. My
.stack/global-project/stack.yaml contains
only

packages: []
resolver: lts-17.15

Not sure how to proceed. Seeing how that vast majority of Haskell intro
books don't use projects, just install, start ghci, load code at the REPL
prompt, I'd really like to nail this "global", non-project stack down.




On Sun, Jun 6, 2021 at 7:10 PM Travis Cardwell <travis.cardwell at extrema.is>
wrote:

> The Stack configuration that is used outside of projects is stored in
> the following location:
>
>     ~/.stack/global-project/stack.yaml
>
> This configuration file is used when you run `stack ghci` outside of a
> project.  Such project configuration files can specify the Stackage
> snapshot to be used (`resolver`), any packages that should be used that
> are different from or not in the specified Stackage snapshot
> (`extra-deps`), a list of packages that are being developed (`packages`,
> none by default in the "global project"), as well as some other settings
> documented at the following location.
>
> https://docs.haskellstack.org/en/stable/yaml_configuration/
>
> Such a project configuration file determines what packages are
> *available* for use.  The motivation is to provide an environment where
> all of the available packages work together, saving you from having to
> deal with dependency conflicts.  It does not *expose* packages to the
> compiler or REPL.  Packages are usually exposed by specifying them in a
> `.cabal` file (or `package.yaml` file when using hpack).
>
> In my experience, the `~/.stack/global-project/stack.yaml` configuration
> is most often used when installing executables using Stack.  For example,
> one can install the version of `hlint` that is in the Stackage snapshot
> configured in the configuration file as follows:
>
>     stack install hlint
>
> What you would like to do is not normal usage of Stack, but I understand
> your motivation.  It is possible to do what you want by configuring a
> global project with the packages that you would like to make available.
> First, create file `~/.stack/global-project/global-project.cabal` with
> the following content:
>
>     name:           global-project
>     version:        0.0.0.0
>     cabal-version:  1.24
>     build-type:     Simple
>
>     library
>       build-depends:
>           base
>         , safe
>       default-language: Haskell2010
>
> Add any packages that you would like to expose to the `build-depends`
> list.  Next, configure `~/.stack/global-project/stack.yaml` as follows:
>
>     resolver: lts-17.14
>
>     packages:
>       - .
>
> Update the `resolver` configuration whenever you want to change Stackage
> snapshots.  Note that you will need to add `extra-deps` configuration to
> this file if you ever want to expose a package that is not in the
> configured snapshot, in addition to adding it to the `build-depends`
> list.
>
> With this configuration, the listed packages should be exposed when you
> run `stack ghci` to run a REPL.
>
> Good luck!
>
> Travis
>


-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210607/d1748483/attachment.html>

From jclites at mac.com  Mon Jun  7 22:54:08 2021
From: jclites at mac.com (Jeff Clites)
Date: Mon, 7 Jun 2021 15:54:08 -0700
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
Message-ID: <AF14DF44-699F-412A-961C-C34B79BC47F6@mac.com>

Was there a stack.yaml file in the directory you were in when you ran stack? If it finds a stack.yaml in your current directory when you run stack, it uses it.

Jeff

> On Jun 7, 2021, at 2:22 PM, Galaxy Being <borgauf at gmail.com> wrote:
> 
> I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs. Good. I duplicated
> 
> packages: []
> resolver: lts-17.15
> 
> on my Ubuntu 21.04 in the .stack/global-project/stack.yaml. Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.). But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says
> 
> Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section.
> Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section.
> You can omit this message by removing it from stack.yaml
> 
> Stack looks for packages in the directories configured in
> the 'packages' and 'extra-deps' fields defined in your stack.yaml
> The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
> but no .cabal or package.yaml file could be found there.
> 
> Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only
> 
> packages: []
> resolver: lts-17.15
> 
> Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.
> 
> 
> 
> 
>> On Sun, Jun 6, 2021 at 7:10 PM Travis Cardwell <travis.cardwell at extrema.is> wrote:
>> The Stack configuration that is used outside of projects is stored in
>> the following location:
>> 
>>     ~/.stack/global-project/stack.yaml
>> 
>> This configuration file is used when you run `stack ghci` outside of a
>> project.  Such project configuration files can specify the Stackage
>> snapshot to be used (`resolver`), any packages that should be used that
>> are different from or not in the specified Stackage snapshot
>> (`extra-deps`), a list of packages that are being developed (`packages`,
>> none by default in the "global project"), as well as some other settings
>> documented at the following location.
>> 
>> https://docs.haskellstack.org/en/stable/yaml_configuration/
>> 
>> Such a project configuration file determines what packages are
>> *available* for use.  The motivation is to provide an environment where
>> all of the available packages work together, saving you from having to
>> deal with dependency conflicts.  It does not *expose* packages to the
>> compiler or REPL.  Packages are usually exposed by specifying them in a
>> `.cabal` file (or `package.yaml` file when using hpack).
>> 
>> In my experience, the `~/.stack/global-project/stack.yaml` configuration
>> is most often used when installing executables using Stack.  For example,
>> one can install the version of `hlint` that is in the Stackage snapshot
>> configured in the configuration file as follows:
>> 
>>     stack install hlint
>> 
>> What you would like to do is not normal usage of Stack, but I understand
>> your motivation.  It is possible to do what you want by configuring a
>> global project with the packages that you would like to make available.
>> First, create file `~/.stack/global-project/global-project.cabal` with
>> the following content:
>> 
>>     name:           global-project
>>     version:        0.0.0.0
>>     cabal-version:  1.24
>>     build-type:     Simple
>> 
>>     library
>>       build-depends:
>>           base
>>         , safe
>>       default-language: Haskell2010
>> 
>> Add any packages that you would like to expose to the `build-depends`
>> list.  Next, configure `~/.stack/global-project/stack.yaml` as follows:
>> 
>>     resolver: lts-17.14
>> 
>>     packages:
>>       - .
>> 
>> Update the `resolver` configuration whenever you want to change Stackage
>> snapshots.  Note that you will need to add `extra-deps` configuration to
>> this file if you ever want to expose a package that is not in the
>> configured snapshot, in addition to adding it to the `build-depends`
>> list.
>> 
>> With this configuration, the listed packages should be exposed when you
>> run `stack ghci` to run a REPL.
>> 
>> Good luck!
>> 
>> Travis
> 
> 
> -- 
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210607/833b37ed/attachment.html>

From immanuel.litzroth at gmail.com  Mon Jun  7 23:22:21 2021
From: immanuel.litzroth at gmail.com (Immanuel Litzroth)
Date: Tue, 8 Jun 2021 01:22:21 +0200
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <AF14DF44-699F-412A-961C-C34B79BC47F6@mac.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
 <AF14DF44-699F-412A-961C-C34B79BC47F6@mac.com>
Message-ID: <CAM1nAcwsK0KSZekoABRXwt2Kb979y0A982y384P0_o+8Te34Tw@mail.gmail.com>

I like org-babel and I like haskell, but getting org babel to work with compiled
languages showed a big impedance mismatch. I ended up writing my own tangler
(reusing many parts of org) for reasons I document in the readme of the repo.
Unfortunately I the repo is not public and I don't have much time to
work on it for
the next month or so
>> README
Simple tangling for org buffers
Reason
I like org and org-babel but they have some problems with compiled languages.

Not possible to tangle all code going to a specified file
Not possible to add line directives without major surgery
Not all modes do the correct thing
No way to prevent overwriting an unchanged file
Special casing e.g. Don’t tangle to a file called ‘no’.
:prologue and :epilogue are not honoured by all modes
Try this

#+ BEGIN_SRC emacs-lisp :prologue "hello" :epilogue "goodbye" :tangle ex1.el
(+ 1 2)
#+ END_SRC


#+ BEGIN_SRC haskell :tangle ex1.hs :prologue "hello" :epilogue "goodbye"
hey
#+ END_SRC

hey

#+HEADER: :tangle ex1.cpp
#+ BEGIN_SRC cpp :prologue "hello" :epilogue "goodbye"
main()
{}
#+ END_SRC

#+ BEGIN_SRC bash :tangle ex1.bash :prologue "hello" :epilogue "goodbye"
aha
#+ END_SRC
Sometimes they do, sometimes they don’t.

Prologue and epilogue are written after and before the links respectively
Quite annoying if you’d like all your emacs code have a

;;; -*- lexical-binding: t -*-

header. Although you can specify :lexical t as a header argument, it’s
not written in the tangled code.

Simple tangling
Write a simple tangler that is mostly compatible with org mode and
reuses it’s functionality. The basic idea is to tangle the code with a
hashmap holding callbacks for the languages you are interested in.
These callbacks happen at

start and end of tangling to a file
start and end of tangling a block
start and end of tangling a noweb reference
and are called in the context of the buffer you are tangling to.

No language support required by the core tangle
Tangling in org requires the mode of the language to be available.
This can be a problem when batch tangling – you don’t want batch emacs
to go through your complete emacs init file then.

Flexible decisions
You get full control over what is happening:

Tangling doesn’t need to write the buffer, it can e.g. choose to send
it to a program.
You get information about the complete tangling context e.g. a noweb
expansion will know all the parent blocks it is expanded from.
Reuse as much of the org machinery as possible
To ensure grosso modo compatibility with org, the org mode calls are reused.

The rules
Only blocks with :tangle header args are tangled
Noweb is enabled by default with but you can configure it via the org
way – org-babel-noweb-wrap-start and org-babel-noweb-wrap-end
Do minimal work outside the callbacks, the tangled buffer is not even
written to a file unless you request it.
>>
Immanuel

On Tue, Jun 8, 2021 at 1:00 AM Jeff Clites via Haskell-Cafe
<haskell-cafe at haskell.org> wrote:
>
> Was there a stack.yaml file in the directory you were in when you ran stack? If it finds a stack.yaml in your current directory when you run stack, it uses it.
>
> Jeff
>
> On Jun 7, 2021, at 2:22 PM, Galaxy Being <borgauf at gmail.com> wrote:
>
> I installed stack on my Windows computer using chocolatey, which went smoothly. But I had nothing anywhere I could find. On a hunch, at the prompt I tried to run stack ghci, then it started downloading and installing stuff. Good. I then was able to track down an example of a stack.yaml in the ...stack/global-project directory. My whole motivation was to see an actual global stack.yaml in the wild, and not have to guess-and-test from the stack docs. Good. I duplicated
>
> packages: []
> resolver: lts-17.15
>
> on my Ubuntu 21.04 in the .stack/global-project/stack.yaml. Tried running stack ghci from the Ubuntu prompt, and, similarly, it started installing lots of stuff. (The resolver version I replaced was lts-17.08. Why that old I don't know.). But then I got a cryptic error as it seemed to clash or not like something it saw in some obscure github directory I had cloned ages ago with Haskell example code. I deleted everything in the github directory that looked stack/cabal-ish and tried stack ghci again. Now it says
>
> Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section.
> Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section.
> You can omit this message by removing it from stack.yaml
>
> Stack looks for packages in the directories configured in
> the 'packages' and 'extra-deps' fields defined in your stack.yaml
> The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
> but no .cabal or package.yaml file could be found there.
>
> Yes, that was the directory I purged. My .stack/global-project/stack.yaml contains only
>
> packages: []
> resolver: lts-17.15
>
> Not sure how to proceed. Seeing how that vast majority of Haskell intro books don't use projects, just install, start ghci, load code at the REPL prompt, I'd really like to nail this "global", non-project stack down.
>
>
>
>
> On Sun, Jun 6, 2021 at 7:10 PM Travis Cardwell <travis.cardwell at extrema.is> wrote:
>>
>> The Stack configuration that is used outside of projects is stored in
>> the following location:
>>
>>     ~/.stack/global-project/stack.yaml
>>
>> This configuration file is used when you run `stack ghci` outside of a
>> project.  Such project configuration files can specify the Stackage
>> snapshot to be used (`resolver`), any packages that should be used that
>> are different from or not in the specified Stackage snapshot
>> (`extra-deps`), a list of packages that are being developed (`packages`,
>> none by default in the "global project"), as well as some other settings
>> documented at the following location.
>>
>> https://docs.haskellstack.org/en/stable/yaml_configuration/
>>
>> Such a project configuration file determines what packages are
>> *available* for use.  The motivation is to provide an environment where
>> all of the available packages work together, saving you from having to
>> deal with dependency conflicts.  It does not *expose* packages to the
>> compiler or REPL.  Packages are usually exposed by specifying them in a
>> `.cabal` file (or `package.yaml` file when using hpack).
>>
>> In my experience, the `~/.stack/global-project/stack.yaml` configuration
>> is most often used when installing executables using Stack.  For example,
>> one can install the version of `hlint` that is in the Stackage snapshot
>> configured in the configuration file as follows:
>>
>>     stack install hlint
>>
>> What you would like to do is not normal usage of Stack, but I understand
>> your motivation.  It is possible to do what you want by configuring a
>> global project with the packages that you would like to make available.
>> First, create file `~/.stack/global-project/global-project.cabal` with
>> the following content:
>>
>>     name:           global-project
>>     version:        0.0.0.0
>>     cabal-version:  1.24
>>     build-type:     Simple
>>
>>     library
>>       build-depends:
>>           base
>>         , safe
>>       default-language: Haskell2010
>>
>> Add any packages that you would like to expose to the `build-depends`
>> list.  Next, configure `~/.stack/global-project/stack.yaml` as follows:
>>
>>     resolver: lts-17.14
>>
>>     packages:
>>       - .
>>
>> Update the `resolver` configuration whenever you want to change Stackage
>> snapshots.  Note that you will need to add `extra-deps` configuration to
>> this file if you ever want to expose a package that is not in the
>> configured snapshot, in addition to adding it to the `build-depends`
>> list.
>>
>> With this configuration, the listed packages should be exposed when you
>> run `stack ghci` to run a REPL.
>>
>> Good luck!
>>
>> Travis
>
>
>
> --
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.
>
> _______________________________________________
> 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.



-- 
-- Researching the dual problem of finding the function that has a
given point as fixpoint.

From travis.cardwell at extrema.is  Mon Jun  7 23:45:39 2021
From: travis.cardwell at extrema.is (Travis Cardwell)
Date: Tue, 8 Jun 2021 08:45:39 +0900
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
Message-ID: <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>

Sorry to hear that it is still not working for you yet.

On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
> I installed stack on my Windows computer using chocolatey, which went
> smoothly. But I had nothing anywhere I could find. On a hunch, at the
> prompt I tried to run stack ghci, then it started downloading and
> installing stuff. Good. I then was able to track down an example of a
> stack.yaml in the ...stack/global-project directory. My whole
> motivation was to see an actual global stack.yaml in the wild, and not
> have to guess-and-test from the stack docs.

Stack provides functionality to initialize a project with a "template"
so that you do not have to start from scratch.  For example, if you want
to start a new project called "HaskellTest" in your `~/Dropbox/org`
directory, run the following commands:

    $ cd ~/Dropbox/org
    $ stack new HaskellTest

The default template provides you with a `stack.yaml` file that includes
documentation and examples.  The template also provides you with a
`package.yaml` file (used to generate the `.cabal` file using hpack)
that has a library, executable, and test suite configured, as well as
stub source code and various other files.

Note that in cases where you already have a Haskell project (with a
`.cabal` or `package.yaml` file), the `stack init` command can be used
to add just the `stack.yaml` to the existing project.

> Good. I duplicated
>
> packages: []
> resolver: lts-17.15
>
> on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.

Note that this `stack.yaml` file is for the "global-project" as it does
not have any packages configured.  The `stack.yaml` file for any (other)
project should list at least one package.

> Tried running stack ghci from the Ubuntu prompt, and, similarly, it
> started installing lots of stuff. (The resolver version I replaced was
> lts-17.08. Why that old I don't know.).

The resolver snapshot in the "global-project" is set when you first run
Stack.  After that, it is up to you to update it *if/when* you would
like to use a different snapshot.

Similarly, the resolver snapshot for a project `stack.yaml` is set when
you run `stack new` or `stack init`, and then it is up to you to
maintain it as desired.

> But then I got a cryptic error as it seemed to clash or not like
> something it saw in some obscure github directory I had cloned ages
> ago with Haskell example code. I deleted everything in the github
> directory that looked stack/cabal-ish and tried stack ghci again. Now
> it says
>
> Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section.
> Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section.
> You can omit this message by removing it from stack.yaml
>
> Stack looks for packages in the directories configured in
> the 'packages' and 'extra-deps' fields defined in your stack.yaml
> The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
> but no .cabal or package.yaml file could be found there.
>
> Yes, that was the directory I purged. My
> .stack/global-project/stack.yaml contains only
>
> packages: []
> resolver: lts-17.15

These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
being used.  It is likely that you are running `stack` commands in a
directory that contains a `stack.yaml` file which references these other
directories, and that file is being used.  Try (re)moving that
`stack.yaml` file and trying again.  Do the errors persist?

Once you (re)move the project `stack.yaml` configuration, the
`stack ghci` will use the `~/.stack/global-project/stack.yaml`
configuration.  With the above content, the LTS 17.15 resolver will be
used, with no packages configured.  As explained in my previous email,
this does *not* expose libraries to GHCi.  If you want to expose
libraries in the global project, you need to follow the instructions I
gave previously for configuring the global project.

> Not sure how to proceed. Seeing how that vast majority of Haskell
> intro books don't use projects, just install, start ghci, load code at
> the REPL prompt, I'd really like to nail this "global", non-project
> stack down.

Indeed.  Installation is tricky, particularly across multiple operating
systems.  Most book authors avoid writing about it, as writing about it
in sufficient detail would likely fill a book itself.  Most beginner
books even stick with the `base` package so that readers do not even
have to worry about packages.

Global installation of packages leads to a *lot* of trouble when you get
to more complex development.  When I first learned Haskell, I would
occasionally completely remove my package database when I got into a
situation that was difficult to resolve.  The situation improved a lot
when Cabal introduced sandbox features, allowing dependencies to be
managed separately per project.  Stack is project-based for the same
reason: allowing each project to use separate sets of packages makes
things a lot easier.  The "global-project" is called "global" because
it is used when outside of any other Haskell project (determined by the
existence of a `stack.yaml` file in the current working directory), but
note that it is actually a project.  Following the instructions that I
wrote in my previous email, you can configure Stack to work in the way
that you want *without* running into the aforementioned trouble even
when you start to develop other projects.

Good luck!

Travis

From simon.jakobi at googlemail.com  Tue Jun  8 14:25:52 2021
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Tue, 8 Jun 2021 16:25:52 +0200
Subject: [Haskell-cafe] Optimizing Eq instances with reallyUnsafePtrEquality#
Message-ID: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>

Hi everyone!

In https://github.com/haskell-unordered-containers/unordered-containers/issues/77
we're wondering whether certain Eq instances, for example record types
or strings, could be optimized by including a pointer equality check
that detects when an object is compared with itself.

Does anyone here have experience with such an optimization? Has this
been considered before, for example in GHC's deriving machinery?

One complication seems to be the correct handling of fields with
irreflexive instances, for example Float and Double. In such a case,
pointer equality doesn't imply "==-equality".

I'm looking forward to hearing your thoughts on this! :)

Cheers,
Simon

From cdsmith at gmail.com  Tue Jun  8 14:32:24 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Tue, 8 Jun 2021 10:32:24 -0400
Subject: [Haskell-cafe] Optimizing Eq instances with
	reallyUnsafePtrEquality#
In-Reply-To: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
References: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
Message-ID: <CAPq5Pv+vxfetT6Qeikk1g34nAQJgbSh8V365YixkweXAVFg-+w@mail.gmail.com>

I have definitely done this before in situations where equality comparison
is unusually expensive, such as when it involves walking a tree.  It hasn't
caused any problems, and I choose to believe that it helped a bit.  That
said, I have never measured the effect, so I'm interested if anyone has a
principled way of quantifying the performance gain.  My solution to the
problem of irreflexive equality was just to not care about it... YMMV on
whether that's okay for your use case!

On Tue, Jun 8, 2021 at 10:27 AM Simon Jakobi via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Hi everyone!
>
> In
> https://github.com/haskell-unordered-containers/unordered-containers/issues/77
> we're wondering whether certain Eq instances, for example record types
> or strings, could be optimized by including a pointer equality check
> that detects when an object is compared with itself.
>
> Does anyone here have experience with such an optimization? Has this
> been considered before, for example in GHC's deriving machinery?
>
> One complication seems to be the correct handling of fields with
> irreflexive instances, for example Float and Double. In such a case,
> pointer equality doesn't imply "==-equality".
>
> I'm looking forward to hearing your thoughts on this! :)
>
> Cheers,
> Simon
> _______________________________________________
> 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/20210608/bae5e748/attachment.html>

From jo at durchholz.org  Tue Jun  8 14:42:21 2021
From: jo at durchholz.org (Joachim Durchholz)
Date: Tue, 8 Jun 2021 16:42:21 +0200
Subject: [Haskell-cafe] Optimizing Eq instances with
 reallyUnsafePtrEquality#
In-Reply-To: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
References: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
Message-ID: <56835f17-1372-b355-8d19-e98c8f7384fc@durchholz.org>

Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
> Hi everyone!
> 
> In https://github.com/haskell-unordered-containers/unordered-containers/issues/77
> we're wondering whether certain Eq instances, for example record types
> or strings, could be optimized by including a pointer equality check
> that detects when an object is compared with itself.

You have to be aware that the pointer comparison itself does not come 
for free. Execution prediction means that the "happy path" may be so 
rare it's not loaded into the CPU cache and you might end with a slower 
system - the case is somewhat pathological but not so rare that you can 
just assume that it will not happen to you.
A lot also depends on whether the data to be compared needs to be loaded 
anyway. If yes, the pointer comparison won't give you any gains, it will 
be just one instruction more to execute, creating more execution unit 
contention inside the CPU. If no, then obviously the pointer comparison 
will help.

In the end, you need to benchmark to see if it helps you.
And you cannot usefully benchmark unless you have also nailed down all 
performance-relevant compiler and runtime options, which you do only if 
you have exhausted all other optimization possibilities.

IOW if it complicates your code, don't do it - unless you are already 
long past the point where code reusability has taken a back seat to raw 
optimization.

Regards,
Jo

From anton.kholomiov at gmail.com  Tue Jun  8 15:19:49 2021
From: anton.kholomiov at gmail.com (Anton Kholomiov)
Date: Tue, 8 Jun 2021 18:19:49 +0300
Subject: [Haskell-cafe] [ANN] hindley-milner-type-check-0.1.1.0 -
 type-checker for extended lambda-calculus
Message-ID: <CADDxdqPpfecZO5Vgipv8Bt35k-2qt4Byrx+vs9j93=s64DJ5dA@mail.gmail.com>

I am happy to announce the first release of hindley-milner-type-check.

It is generic type checker for lambda-calculus augmented with
let-expressions,
case-expressions pattern-matching and polymorphism.
Library can report source code locations and returns the list of all errors
if any.

The library is generic in terms of source code locations, names for
variables, literals
of the language.

You can find tutorials and examples in the github repo.

Links:

Hackage: https://hackage.haskell.org/package/hindley-milner-type-check
Github: https://github.com/anton-k/hindley-milner-type-check

Happy type-checking! Cheers,
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210608/5b13be0a/attachment.html>

From borgauf at gmail.com  Tue Jun  8 16:20:19 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Tue, 8 Jun 2021 11:20:19 -0500
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
 <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>
Message-ID: <CAFAhFSVLxjcyLVt03EKAT3Fy07KX4i67W-wuNTxea7RCEUC+6g@mail.gmail.com>

If I'm understanding correctly, I can follow the stack way of setting up a
project in a directory, then if I start a ghci REPL in that directory, I'm
in that project's sandbox, true? But if I start a ghci REPL in some
directory that has no stack project already set up, then that REPL is
relying on the global "project," so to speak. It's somewhat confusing since
the project way of doing Haskell is to compile with ghc, and run at a shell
(same as C) and not have a running ghci. Two different cultures. After
working in the REPL-based world of, say, Scheme and Emacs Lisp, it's hard
to come back to a code-compile-run world. In Emacs, all Lisp coding you do
is feeding, tweaking a live Emacs beast. It's difficult for me as a Haskell
beginner to understand why beginner tutorials all have me working with the
ghci REPL -- but then that's apparently not how real-world Haskell works.
Or is it? So Emacs is a running ball of C and Elisp code with an Elisp REPL
that gives you control over the running system. Something similar is going
on with, say, XMonad, right? XMonad is a running Haskell executable, but
then you change XMonad by altering xmonad.hs and, I'm guessing, recompile
the whole XMonad system, then restart it?

On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <travis.cardwell at extrema.is>
wrote:

> Sorry to hear that it is still not working for you yet.
>
> On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
> > I installed stack on my Windows computer using chocolatey, which went
> > smoothly. But I had nothing anywhere I could find. On a hunch, at the
> > prompt I tried to run stack ghci, then it started downloading and
> > installing stuff. Good. I then was able to track down an example of a
> > stack.yaml in the ...stack/global-project directory. My whole
> > motivation was to see an actual global stack.yaml in the wild, and not
> > have to guess-and-test from the stack docs.
>
> Stack provides functionality to initialize a project with a "template"
> so that you do not have to start from scratch.  For example, if you want
> to start a new project called "HaskellTest" in your `~/Dropbox/org`
> directory, run the following commands:
>
>     $ cd ~/Dropbox/org
>     $ stack new HaskellTest
>
> The default template provides you with a `stack.yaml` file that includes
> documentation and examples.  The template also provides you with a
> `package.yaml` file (used to generate the `.cabal` file using hpack)
> that has a library, executable, and test suite configured, as well as
> stub source code and various other files.
>
> Note that in cases where you already have a Haskell project (with a
> `.cabal` or `package.yaml` file), the `stack init` command can be used
> to add just the `stack.yaml` to the existing project.
>
> > Good. I duplicated
> >
> > packages: []
> > resolver: lts-17.15
> >
> > on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.
>
> Note that this `stack.yaml` file is for the "global-project" as it does
> not have any packages configured.  The `stack.yaml` file for any (other)
> project should list at least one package.
>
> > Tried running stack ghci from the Ubuntu prompt, and, similarly, it
> > started installing lots of stuff. (The resolver version I replaced was
> > lts-17.08. Why that old I don't know.).
>
> The resolver snapshot in the "global-project" is set when you first run
> Stack.  After that, it is up to you to update it *if/when* you would
> like to use a different snapshot.
>
> Similarly, the resolver snapshot for a project `stack.yaml` is set when
> you run `stack new` or `stack init`, and then it is up to you to
> maintain it as desired.
>
> > But then I got a cryptic error as it seemed to clash or not like
> > something it saw in some obscure github directory I had cloned ages
> > ago with Haskell example code. I deleted everything in the github
> > directory that looked stack/cabal-ish and tried stack ghci again. Now
> > it says
> >
> > Warning (added by new or init): Some packages were found to have names
> conflicting with others and have been commented out in the packages section.
> > Warning (added by new or init): Some packages were found to be
> incompatible with the resolver and have been left commented out in the
> packages section.
> > You can omit this message by removing it from stack.yaml
> >
> > Stack looks for packages in the directories configured in
> > the 'packages' and 'extra-deps' fields defined in your stack.yaml
> > The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
> > but no .cabal or package.yaml file could be found there.
> >
> > Yes, that was the directory I purged. My
> > .stack/global-project/stack.yaml contains only
> >
> > packages: []
> > resolver: lts-17.15
>
> These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
> being used.  It is likely that you are running `stack` commands in a
> directory that contains a `stack.yaml` file which references these other
> directories, and that file is being used.  Try (re)moving that
> `stack.yaml` file and trying again.  Do the errors persist?
>
> Once you (re)move the project `stack.yaml` configuration, the
> `stack ghci` will use the `~/.stack/global-project/stack.yaml`
> configuration.  With the above content, the LTS 17.15 resolver will be
> used, with no packages configured.  As explained in my previous email,
> this does *not* expose libraries to GHCi.  If you want to expose
> libraries in the global project, you need to follow the instructions I
> gave previously for configuring the global project.
>
> > Not sure how to proceed. Seeing how that vast majority of Haskell
> > intro books don't use projects, just install, start ghci, load code at
> > the REPL prompt, I'd really like to nail this "global", non-project
> > stack down.
>
> Indeed.  Installation is tricky, particularly across multiple operating
> systems.  Most book authors avoid writing about it, as writing about it
> in sufficient detail would likely fill a book itself.  Most beginner
> books even stick with the `base` package so that readers do not even
> have to worry about packages.
>
> Global installation of packages leads to a *lot* of trouble when you get
> to more complex development.  When I first learned Haskell, I would
> occasionally completely remove my package database when I got into a
> situation that was difficult to resolve.  The situation improved a lot
> when Cabal introduced sandbox features, allowing dependencies to be
> managed separately per project.  Stack is project-based for the same
> reason: allowing each project to use separate sets of packages makes
> things a lot easier.  The "global-project" is called "global" because
> it is used when outside of any other Haskell project (determined by the
> existence of a `stack.yaml` file in the current working directory), but
> note that it is actually a project.  Following the instructions that I
> wrote in my previous email, you can configure Stack to work in the way
> that you want *without* running into the aforementioned trouble even
> when you start to develop other projects.
>
> Good luck!
>
> Travis
>


-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210608/523dbbad/attachment.html>

From sjcjoosten+haskell at gmail.com  Tue Jun  8 16:48:12 2021
From: sjcjoosten+haskell at gmail.com (Sebastiaan Joosten)
Date: Tue, 8 Jun 2021 12:48:12 -0400
Subject: [Haskell-cafe] Optimizing Eq instances with
	reallyUnsafePtrEquality#
In-Reply-To: <56835f17-1372-b355-8d19-e98c8f7384fc@durchholz.org>
References: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
 <56835f17-1372-b355-8d19-e98c8f7384fc@durchholz.org>
Message-ID: <CABhTcUswv_QZ4fNQ8-6scAAYxzhLfGxMzvNGr9a2hJJ95mV1bA@mail.gmail.com>

The containers library uses this trick:
https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Utils/Containers/Internal/PtrEquality.hs
It mentions the useful hint to evaluate the arguments to WHNF before
calling PtrEquality.
The function ptrEq is used here (for instance):
https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L532
The places where ptrEq is used in that file, its purpose seems to be to
reduce memory by reusing existing data-structures, which I suppose also
helps with performance.
Surprisingly enough (at least to me) ptrEq is not used in the Eq instance
there:
https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L1141

Outside of GHC, there are some (pure) languages that extensively make use
of this principle and it's too cool not to mention:
The programming language Elm does this in its generated code (at least when
generating JavaScript): https://github.com/elm/compiler/
The theorem proving environment ACL2 uses this principle for memoizing
functions, fast 'Map's ('dictionaries' in python lingo, 'alist' or
association-list in ACL2 lingo), as well as fast equality. As a LISP
dialect, all data-structures are pairs (called CONS). In ACL2, the function
'HONS' (hashed CONS) will construct a pair if it does not already exist,
and otherwise it returns a pointer to the already existing object. The
point of using HONS in ACL2 is to *only* perform pointer comparison,
without needing to do any other equality check.
General background information:
https://www.cs.utexas.edu/~ragerdl/acl2-manual/index.html?topic=ACL2____HONS-AND-MEMOIZATION
The equality test:
https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-EQUAL
And there is of course a function to create a 'normed object':
https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-COPY
Note that the ACL2 approach only works because it is supported by the run
time system (the implementation needs to access 'all data in memory') so it
won't work in Haskell (assuming you're not writing your own RTS).

Hope this helps.

On Tue, Jun 8, 2021 at 10:47 AM Joachim Durchholz <jo at durchholz.org> wrote:

> Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
> > Hi everyone!
> >
> > In
> https://github.com/haskell-unordered-containers/unordered-containers/issues/77
> > we're wondering whether certain Eq instances, for example record types
> > or strings, could be optimized by including a pointer equality check
> > that detects when an object is compared with itself.
>
> You have to be aware that the pointer comparison itself does not come
> for free. Execution prediction means that the "happy path" may be so
> rare it's not loaded into the CPU cache and you might end with a slower
> system - the case is somewhat pathological but not so rare that you can
> just assume that it will not happen to you.
> A lot also depends on whether the data to be compared needs to be loaded
> anyway. If yes, the pointer comparison won't give you any gains, it will
> be just one instruction more to execute, creating more execution unit
> contention inside the CPU. If no, then obviously the pointer comparison
> will help.
>
> In the end, you need to benchmark to see if it helps you.
> And you cannot usefully benchmark unless you have also nailed down all
> performance-relevant compiler and runtime options, which you do only if
> you have exhausted all other optimization possibilities.
>
> IOW if it complicates your code, don't do it - unless you are already
> long past the point where code reusability has taken a back seat to raw
> optimization.
>
> Regards,
> Jo
> _______________________________________________
> 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/20210608/bf078cad/attachment.html>

From jclites at mac.com  Tue Jun  8 17:29:23 2021
From: jclites at mac.com (Jeff Clites)
Date: Tue, 8 Jun 2021 10:29:23 -0700
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSVLxjcyLVt03EKAT3Fy07KX4i67W-wuNTxea7RCEUC+6g@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
 <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>
 <CAFAhFSVLxjcyLVt03EKAT3Fy07KX4i67W-wuNTxea7RCEUC+6g@mail.gmail.com>
Message-ID: <70BCE1F1-7031-4469-9998-4335148F91D6@mac.com>

> On Jun 8, 2021, at 9:20 AM, Galaxy Being <borgauf at gmail.com> wrote:
> 
> If I'm understanding correctly, I can follow the stack way of setting up a project in a directory, then if I start a ghci REPL in that directory, I'm in that project's sandbox, true? But if I start a ghci REPL in some directory that has no stack project already set up, then that REPL is relying on the global "project," so to speak.

Yes. The point of Stack is to allow different projects to use different versions of GHC and different versions of libraries and have those projects never interfere with each other. To do this it’s logically necessary for Stack to always run based on a configuration file that tells it which set of versions you want to use for this run.

> It's somewhat confusing since the project way of doing Haskell is to compile with ghc, and run at a shell (same as C) and not have a running ghci. Two different cultures.

In both cases you are compiling some Haskell code and running it. It’s just that in the ghci case it’s doing both of those for you in one step. Really ghci is just meant for experimentation.

I think this is similar for most languages I’ve encountered that have a REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not directly using the REPL, even if the REPL happens to be built into the same tool you use to run your program. The REPL is mostly a tool for quick experimentation.

Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a loop around compiling and running some code. From that perspective, the compile and run steps are the fundamental steps and the REPL is just a bit of automation around those. It’s not the fundamental thing.

> It's difficult for me as a Haskell beginner to understand why beginner tutorials all have me working with the ghci REPL

It’s because that’s the way to run small experiments quickly. They are trying to teach you the language as concisely as possible, and not the overall development environment. (Also, as a practical matter, the instructions for setting up a development environment change and printed books don’t, so including detailed setup instructions would be a waste because they’d become out of date.)

> -- but then that's apparently not how real-world Haskell works. Or is it?

Correct; you don’t use the REPL to run large programs. You use it to try things out.

> So Emacs is a running ball of C and Elisp code with an Elisp REPL that gives you control over the running system.

Right. The Emacs case is different than others in that in this case your elisp programs are (typically) extending the functionality of this particular text editor, basically acting as plugin, rather than functioning as separate programs that have nothing to do with a text editor. I wouldn’t use Emacs as a model for conceptualizing other languages; it’s quite a special case.

Jeff

>> On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <travis.cardwell at extrema.is> wrote:
>> Sorry to hear that it is still not working for you yet.
>> 
>> On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
>> > I installed stack on my Windows computer using chocolatey, which went
>> > smoothly. But I had nothing anywhere I could find. On a hunch, at the
>> > prompt I tried to run stack ghci, then it started downloading and
>> > installing stuff. Good. I then was able to track down an example of a
>> > stack.yaml in the ...stack/global-project directory. My whole
>> > motivation was to see an actual global stack.yaml in the wild, and not
>> > have to guess-and-test from the stack docs.
>> 
>> Stack provides functionality to initialize a project with a "template"
>> so that you do not have to start from scratch.  For example, if you want
>> to start a new project called "HaskellTest" in your `~/Dropbox/org`
>> directory, run the following commands:
>> 
>>     $ cd ~/Dropbox/org
>>     $ stack new HaskellTest
>> 
>> The default template provides you with a `stack.yaml` file that includes
>> documentation and examples.  The template also provides you with a
>> `package.yaml` file (used to generate the `.cabal` file using hpack)
>> that has a library, executable, and test suite configured, as well as
>> stub source code and various other files.
>> 
>> Note that in cases where you already have a Haskell project (with a
>> `.cabal` or `package.yaml` file), the `stack init` command can be used
>> to add just the `stack.yaml` to the existing project.
>> 
>> > Good. I duplicated
>> >
>> > packages: []
>> > resolver: lts-17.15
>> >
>> > on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.
>> 
>> Note that this `stack.yaml` file is for the "global-project" as it does
>> not have any packages configured.  The `stack.yaml` file for any (other)
>> project should list at least one package.
>> 
>> > Tried running stack ghci from the Ubuntu prompt, and, similarly, it
>> > started installing lots of stuff. (The resolver version I replaced was
>> > lts-17.08. Why that old I don't know.).
>> 
>> The resolver snapshot in the "global-project" is set when you first run
>> Stack.  After that, it is up to you to update it *if/when* you would
>> like to use a different snapshot.
>> 
>> Similarly, the resolver snapshot for a project `stack.yaml` is set when
>> you run `stack new` or `stack init`, and then it is up to you to
>> maintain it as desired.
>> 
>> > But then I got a cryptic error as it seemed to clash or not like
>> > something it saw in some obscure github directory I had cloned ages
>> > ago with Haskell example code. I deleted everything in the github
>> > directory that looked stack/cabal-ish and tried stack ghci again. Now
>> > it says
>> >
>> > Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section.
>> > Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section.
>> > You can omit this message by removing it from stack.yaml
>> >
>> > Stack looks for packages in the directories configured in
>> > the 'packages' and 'extra-deps' fields defined in your stack.yaml
>> > The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
>> > but no .cabal or package.yaml file could be found there.
>> >
>> > Yes, that was the directory I purged. My
>> > .stack/global-project/stack.yaml contains only
>> >
>> > packages: []
>> > resolver: lts-17.15
>> 
>> These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
>> being used.  It is likely that you are running `stack` commands in a
>> directory that contains a `stack.yaml` file which references these other
>> directories, and that file is being used.  Try (re)moving that
>> `stack.yaml` file and trying again.  Do the errors persist?
>> 
>> Once you (re)move the project `stack.yaml` configuration, the
>> `stack ghci` will use the `~/.stack/global-project/stack.yaml`
>> configuration.  With the above content, the LTS 17.15 resolver will be
>> used, with no packages configured.  As explained in my previous email,
>> this does *not* expose libraries to GHCi.  If you want to expose
>> libraries in the global project, you need to follow the instructions I
>> gave previously for configuring the global project.
>> 
>> > Not sure how to proceed. Seeing how that vast majority of Haskell
>> > intro books don't use projects, just install, start ghci, load code at
>> > the REPL prompt, I'd really like to nail this "global", non-project
>> > stack down.
>> 
>> Indeed.  Installation is tricky, particularly across multiple operating
>> systems.  Most book authors avoid writing about it, as writing about it
>> in sufficient detail would likely fill a book itself.  Most beginner
>> books even stick with the `base` package so that readers do not even
>> have to worry about packages.
>> 
>> Global installation of packages leads to a *lot* of trouble when you get
>> to more complex development.  When I first learned Haskell, I would
>> occasionally completely remove my package database when I got into a
>> situation that was difficult to resolve.  The situation improved a lot
>> when Cabal introduced sandbox features, allowing dependencies to be
>> managed separately per project.  Stack is project-based for the same
>> reason: allowing each project to use separate sets of packages makes
>> things a lot easier.  The "global-project" is called "global" because
>> it is used when outside of any other Haskell project (determined by the
>> existence of a `stack.yaml` file in the current working directory), but
>> note that it is actually a project.  Following the instructions that I
>> wrote in my previous email, you can configure Stack to work in the way
>> that you want *without* running into the aforementioned trouble even
>> when you start to develop other projects.
>> 
>> Good luck!
>> 
>> Travis
> 
> 
> -- 
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210608/4dd1ef63/attachment.html>

From borgauf at gmail.com  Tue Jun  8 18:38:12 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Tue, 8 Jun 2021 13:38:12 -0500
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <70BCE1F1-7031-4469-9998-4335148F91D6@mac.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
 <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>
 <CAFAhFSVLxjcyLVt03EKAT3Fy07KX4i67W-wuNTxea7RCEUC+6g@mail.gmail.com>
 <70BCE1F1-7031-4469-9998-4335148F91D6@mac.com>
Message-ID: <CAFAhFSWmBz4EC1UT6L_GFBwDNnkcRLiSeV27obJ+x0V+pEw-cQ@mail.gmail.com>

But to my XMonad example. The Emacs world has the Emacs system running
live, but the REPL capable of tweaking the live, running Emacs world in any
way imaginable. Lisp and Scheme are this way too. (PicoLisp only this way.)
Something similar must be happening with XMonad. After all, if I make
configuration changes to xmonad.hs, somehow they must go into effect on a
live, running XMonad, right? I don't log out of XMonad to a system shell,
then compile the new executable with my config tweaks, then restart this
new XMonad. No, I must be in some sort of Emacs-like situation -- or like a
shell with C forking -- or some sort of event management device of XMonad
where the "meta" XMonad is always running, but treating my config changes
as hot-swappable plugins. Or like Unix/Linux with bootstrapping of a sort.
Or am I missing something? I think this is very basic information, but I
sure can't find it anywhere. As I have come to understand the REPL from the
Lisp world, it's a running virtual machine that allows live tweaking and
programming. An executable, OTOH, is an independent agent living as a
process on the host OS. In Emacs, with some languages you can even have
separate org mode babel REPL sessions. But back to XMonad, I'm guessing
it's a Haskell executable that then acts like a virtual machine that allows
hot-swapping plug-and-play....

On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites <jclites at mac.com> wrote:

> On Jun 8, 2021, at 9:20 AM, Galaxy Being <borgauf at gmail.com> wrote:
>
> If I'm understanding correctly, I can follow the stack way of setting up a
> project in a directory, then if I start a ghci REPL in that directory, I'm
> in that project's sandbox, true? But if I start a ghci REPL in some
> directory that has no stack project already set up, then that REPL is
> relying on the global "project," so to speak.
>
>
> Yes. The point of Stack is to allow different projects to use different
> versions of GHC and different versions of libraries and have those projects
> never interfere with each other. To do this it’s logically necessary for
> Stack to always run based on a configuration file that tells it which set
> of versions you want to use for this run.
>
> It's somewhat confusing since the project way of doing Haskell is to
> compile with ghc, and run at a shell (same as C) and not have a running
> ghci. Two different cultures.
>
>
> In both cases you are compiling some Haskell code and running it. It’s
> just that in the ghci case it’s doing both of those for you in one step.
> Really ghci is just meant for experimentation.
>
> I think this is similar for most languages I’ve encountered that have a
> REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not
> directly using the REPL, even if the REPL happens to be built into the same
> tool you use to run your program. The REPL is mostly a tool for quick
> experimentation.
>
> Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a
> loop around compiling and running some code. From that perspective, the
> compile and run steps are the fundamental steps and the REPL is just a bit
> of automation around those. It’s not the fundamental thing.
>
> It's difficult for me as a Haskell beginner to understand why beginner
> tutorials all have me working with the ghci REPL
>
>
> It’s because that’s the way to run small experiments quickly. They are
> trying to teach you the language as concisely as possible, and not the
> overall development environment. (Also, as a practical matter, the
> instructions for setting up a development environment change and printed
> books don’t, so including detailed setup instructions would be a waste
> because they’d become out of date.)
>
> -- but then that's apparently not how real-world Haskell works. Or is it?
>
>
> Correct; you don’t use the REPL to run large programs. You use it to try
> things out.
>
> So Emacs is a running ball of C and Elisp code with an Elisp REPL that
> gives you control over the running system.
>
>
> Right. The Emacs case is different than others in that in this case your
> elisp programs are (typically) extending the functionality of this
> particular text editor, basically acting as plugin, rather than functioning
> as separate programs that have nothing to do with a text editor. I wouldn’t
> use Emacs as a model for conceptualizing other languages; it’s quite a
> special case.
>
> Jeff
>
> On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <travis.cardwell at extrema.is>
> wrote:
>
>> Sorry to hear that it is still not working for you yet.
>>
>> On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
>> > I installed stack on my Windows computer using chocolatey, which went
>> > smoothly. But I had nothing anywhere I could find. On a hunch, at the
>> > prompt I tried to run stack ghci, then it started downloading and
>> > installing stuff. Good. I then was able to track down an example of a
>> > stack.yaml in the ...stack/global-project directory. My whole
>> > motivation was to see an actual global stack.yaml in the wild, and not
>> > have to guess-and-test from the stack docs.
>>
>> Stack provides functionality to initialize a project with a "template"
>> so that you do not have to start from scratch.  For example, if you want
>> to start a new project called "HaskellTest" in your `~/Dropbox/org`
>> directory, run the following commands:
>>
>>     $ cd ~/Dropbox/org
>>     $ stack new HaskellTest
>>
>> The default template provides you with a `stack.yaml` file that includes
>> documentation and examples.  The template also provides you with a
>> `package.yaml` file (used to generate the `.cabal` file using hpack)
>> that has a library, executable, and test suite configured, as well as
>> stub source code and various other files.
>>
>> Note that in cases where you already have a Haskell project (with a
>> `.cabal` or `package.yaml` file), the `stack init` command can be used
>> to add just the `stack.yaml` to the existing project.
>>
>> > Good. I duplicated
>> >
>> > packages: []
>> > resolver: lts-17.15
>> >
>> > on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.
>>
>> Note that this `stack.yaml` file is for the "global-project" as it does
>> not have any packages configured.  The `stack.yaml` file for any (other)
>> project should list at least one package.
>>
>> > Tried running stack ghci from the Ubuntu prompt, and, similarly, it
>> > started installing lots of stuff. (The resolver version I replaced was
>> > lts-17.08. Why that old I don't know.).
>>
>> The resolver snapshot in the "global-project" is set when you first run
>> Stack.  After that, it is up to you to update it *if/when* you would
>> like to use a different snapshot.
>>
>> Similarly, the resolver snapshot for a project `stack.yaml` is set when
>> you run `stack new` or `stack init`, and then it is up to you to
>> maintain it as desired.
>>
>> > But then I got a cryptic error as it seemed to clash or not like
>> > something it saw in some obscure github directory I had cloned ages
>> > ago with Haskell example code. I deleted everything in the github
>> > directory that looked stack/cabal-ish and tried stack ghci again. Now
>> > it says
>> >
>> > Warning (added by new or init): Some packages were found to have names
>> conflicting with others and have been commented out in the packages section.
>> > Warning (added by new or init): Some packages were found to be
>> incompatible with the resolver and have been left commented out in the
>> packages section.
>> > You can omit this message by removing it from stack.yaml
>> >
>> > Stack looks for packages in the directories configured in
>> > the 'packages' and 'extra-deps' fields defined in your stack.yaml
>> > The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
>> > but no .cabal or package.yaml file could be found there.
>> >
>> > Yes, that was the directory I purged. My
>> > .stack/global-project/stack.yaml contains only
>> >
>> > packages: []
>> > resolver: lts-17.15
>>
>> These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
>> being used.  It is likely that you are running `stack` commands in a
>> directory that contains a `stack.yaml` file which references these other
>> directories, and that file is being used.  Try (re)moving that
>> `stack.yaml` file and trying again.  Do the errors persist?
>>
>> Once you (re)move the project `stack.yaml` configuration, the
>> `stack ghci` will use the `~/.stack/global-project/stack.yaml`
>> configuration.  With the above content, the LTS 17.15 resolver will be
>> used, with no packages configured.  As explained in my previous email,
>> this does *not* expose libraries to GHCi.  If you want to expose
>> libraries in the global project, you need to follow the instructions I
>> gave previously for configuring the global project.
>>
>> > Not sure how to proceed. Seeing how that vast majority of Haskell
>> > intro books don't use projects, just install, start ghci, load code at
>> > the REPL prompt, I'd really like to nail this "global", non-project
>> > stack down.
>>
>> Indeed.  Installation is tricky, particularly across multiple operating
>> systems.  Most book authors avoid writing about it, as writing about it
>> in sufficient detail would likely fill a book itself.  Most beginner
>> books even stick with the `base` package so that readers do not even
>> have to worry about packages.
>>
>> Global installation of packages leads to a *lot* of trouble when you get
>> to more complex development.  When I first learned Haskell, I would
>> occasionally completely remove my package database when I got into a
>> situation that was difficult to resolve.  The situation improved a lot
>> when Cabal introduced sandbox features, allowing dependencies to be
>> managed separately per project.  Stack is project-based for the same
>> reason: allowing each project to use separate sets of packages makes
>> things a lot easier.  The "global-project" is called "global" because
>> it is used when outside of any other Haskell project (determined by the
>> existence of a `stack.yaml` file in the current working directory), but
>> note that it is actually a project.  Following the instructions that I
>> wrote in my previous email, you can configure Stack to work in the way
>> that you want *without* running into the aforementioned trouble even
>> when you start to develop other projects.
>>
>> Good luck!
>>
>> Travis
>>
>
>
> --
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.
>
>

-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210608/ad05e6a0/attachment-0001.html>

From curtis.dalves at gmail.com  Tue Jun  8 18:47:07 2021
From: curtis.dalves at gmail.com (Curtis D'Alves)
Date: Tue, 8 Jun 2021 14:47:07 -0400
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSWmBz4EC1UT6L_GFBwDNnkcRLiSeV27obJ+x0V+pEw-cQ@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
 <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>
 <CAFAhFSVLxjcyLVt03EKAT3Fy07KX4i67W-wuNTxea7RCEUC+6g@mail.gmail.com>
 <70BCE1F1-7031-4469-9998-4335148F91D6@mac.com>
 <CAFAhFSWmBz4EC1UT6L_GFBwDNnkcRLiSeV27obJ+x0V+pEw-cQ@mail.gmail.com>
Message-ID: <CA+RM9KvK_ggsxF_N2a-dsJeoQ7=rPPZA95Ds=zzb9yyF5GVXOw@mail.gmail.com>

No, when you make changes to xmonad you have to reload/recompile it (by
default bound to mod-q) for the changes to take effect

On Tue., Jun. 8, 2021, 2:43 p.m. Galaxy Being, <borgauf at gmail.com> wrote:

> But to my XMonad example. The Emacs world has the Emacs system running
> live, but the REPL capable of tweaking the live, running Emacs world in any
> way imaginable. Lisp and Scheme are this way too. (PicoLisp only this way.)
> Something similar must be happening with XMonad. After all, if I make
> configuration changes to xmonad.hs, somehow they must go into effect on a
> live, running XMonad, right? I don't log out of XMonad to a system shell,
> then compile the new executable with my config tweaks, then restart this
> new XMonad. No, I must be in some sort of Emacs-like situation -- or like a
> shell with C forking -- or some sort of event management device of XMonad
> where the "meta" XMonad is always running, but treating my config changes
> as hot-swappable plugins. Or like Unix/Linux with bootstrapping of a sort.
> Or am I missing something? I think this is very basic information, but I
> sure can't find it anywhere. As I have come to understand the REPL from the
> Lisp world, it's a running virtual machine that allows live tweaking and
> programming. An executable, OTOH, is an independent agent living as a
> process on the host OS. In Emacs, with some languages you can even have
> separate org mode babel REPL sessions. But back to XMonad, I'm guessing
> it's a Haskell executable that then acts like a virtual machine that allows
> hot-swapping plug-and-play....
>
> On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites <jclites at mac.com> wrote:
>
>> On Jun 8, 2021, at 9:20 AM, Galaxy Being <borgauf at gmail.com> wrote:
>>
>> If I'm understanding correctly, I can follow the stack way of setting up
>> a project in a directory, then if I start a ghci REPL in that directory,
>> I'm in that project's sandbox, true? But if I start a ghci REPL in some
>> directory that has no stack project already set up, then that REPL is
>> relying on the global "project," so to speak.
>>
>>
>> Yes. The point of Stack is to allow different projects to use different
>> versions of GHC and different versions of libraries and have those projects
>> never interfere with each other. To do this it’s logically necessary for
>> Stack to always run based on a configuration file that tells it which set
>> of versions you want to use for this run.
>>
>> It's somewhat confusing since the project way of doing Haskell is to
>> compile with ghc, and run at a shell (same as C) and not have a running
>> ghci. Two different cultures.
>>
>>
>> In both cases you are compiling some Haskell code and running it. It’s
>> just that in the ghci case it’s doing both of those for you in one step.
>> Really ghci is just meant for experimentation.
>>
>> I think this is similar for most languages I’ve encountered that have a
>> REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not
>> directly using the REPL, even if the REPL happens to be built into the same
>> tool you use to run your program. The REPL is mostly a tool for quick
>> experimentation.
>>
>> Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a
>> loop around compiling and running some code. From that perspective, the
>> compile and run steps are the fundamental steps and the REPL is just a bit
>> of automation around those. It’s not the fundamental thing.
>>
>> It's difficult for me as a Haskell beginner to understand why beginner
>> tutorials all have me working with the ghci REPL
>>
>>
>> It’s because that’s the way to run small experiments quickly. They are
>> trying to teach you the language as concisely as possible, and not the
>> overall development environment. (Also, as a practical matter, the
>> instructions for setting up a development environment change and printed
>> books don’t, so including detailed setup instructions would be a waste
>> because they’d become out of date.)
>>
>> -- but then that's apparently not how real-world Haskell works. Or is it?
>>
>>
>> Correct; you don’t use the REPL to run large programs. You use it to try
>> things out.
>>
>> So Emacs is a running ball of C and Elisp code with an Elisp REPL that
>> gives you control over the running system.
>>
>>
>> Right. The Emacs case is different than others in that in this case your
>> elisp programs are (typically) extending the functionality of this
>> particular text editor, basically acting as plugin, rather than functioning
>> as separate programs that have nothing to do with a text editor. I wouldn’t
>> use Emacs as a model for conceptualizing other languages; it’s quite a
>> special case.
>>
>> Jeff
>>
>> On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <
>> travis.cardwell at extrema.is> wrote:
>>
>>> Sorry to hear that it is still not working for you yet.
>>>
>>> On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
>>> > I installed stack on my Windows computer using chocolatey, which went
>>> > smoothly. But I had nothing anywhere I could find. On a hunch, at the
>>> > prompt I tried to run stack ghci, then it started downloading and
>>> > installing stuff. Good. I then was able to track down an example of a
>>> > stack.yaml in the ...stack/global-project directory. My whole
>>> > motivation was to see an actual global stack.yaml in the wild, and not
>>> > have to guess-and-test from the stack docs.
>>>
>>> Stack provides functionality to initialize a project with a "template"
>>> so that you do not have to start from scratch.  For example, if you want
>>> to start a new project called "HaskellTest" in your `~/Dropbox/org`
>>> directory, run the following commands:
>>>
>>>     $ cd ~/Dropbox/org
>>>     $ stack new HaskellTest
>>>
>>> The default template provides you with a `stack.yaml` file that includes
>>> documentation and examples.  The template also provides you with a
>>> `package.yaml` file (used to generate the `.cabal` file using hpack)
>>> that has a library, executable, and test suite configured, as well as
>>> stub source code and various other files.
>>>
>>> Note that in cases where you already have a Haskell project (with a
>>> `.cabal` or `package.yaml` file), the `stack init` command can be used
>>> to add just the `stack.yaml` to the existing project.
>>>
>>> > Good. I duplicated
>>> >
>>> > packages: []
>>> > resolver: lts-17.15
>>> >
>>> > on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.
>>>
>>> Note that this `stack.yaml` file is for the "global-project" as it does
>>> not have any packages configured.  The `stack.yaml` file for any (other)
>>> project should list at least one package.
>>>
>>> > Tried running stack ghci from the Ubuntu prompt, and, similarly, it
>>> > started installing lots of stuff. (The resolver version I replaced was
>>> > lts-17.08. Why that old I don't know.).
>>>
>>> The resolver snapshot in the "global-project" is set when you first run
>>> Stack.  After that, it is up to you to update it *if/when* you would
>>> like to use a different snapshot.
>>>
>>> Similarly, the resolver snapshot for a project `stack.yaml` is set when
>>> you run `stack new` or `stack init`, and then it is up to you to
>>> maintain it as desired.
>>>
>>> > But then I got a cryptic error as it seemed to clash or not like
>>> > something it saw in some obscure github directory I had cloned ages
>>> > ago with Haskell example code. I deleted everything in the github
>>> > directory that looked stack/cabal-ish and tried stack ghci again. Now
>>> > it says
>>> >
>>> > Warning (added by new or init): Some packages were found to have names
>>> conflicting with others and have been commented out in the packages section.
>>> > Warning (added by new or init): Some packages were found to be
>>> incompatible with the resolver and have been left commented out in the
>>> packages section.
>>> > You can omit this message by removing it from stack.yaml
>>> >
>>> > Stack looks for packages in the directories configured in
>>> > the 'packages' and 'extra-deps' fields defined in your stack.yaml
>>> > The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
>>> > but no .cabal or package.yaml file could be found there.
>>> >
>>> > Yes, that was the directory I purged. My
>>> > .stack/global-project/stack.yaml contains only
>>> >
>>> > packages: []
>>> > resolver: lts-17.15
>>>
>>> These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
>>> being used.  It is likely that you are running `stack` commands in a
>>> directory that contains a `stack.yaml` file which references these other
>>> directories, and that file is being used.  Try (re)moving that
>>> `stack.yaml` file and trying again.  Do the errors persist?
>>>
>>> Once you (re)move the project `stack.yaml` configuration, the
>>> `stack ghci` will use the `~/.stack/global-project/stack.yaml`
>>> configuration.  With the above content, the LTS 17.15 resolver will be
>>> used, with no packages configured.  As explained in my previous email,
>>> this does *not* expose libraries to GHCi.  If you want to expose
>>> libraries in the global project, you need to follow the instructions I
>>> gave previously for configuring the global project.
>>>
>>> > Not sure how to proceed. Seeing how that vast majority of Haskell
>>> > intro books don't use projects, just install, start ghci, load code at
>>> > the REPL prompt, I'd really like to nail this "global", non-project
>>> > stack down.
>>>
>>> Indeed.  Installation is tricky, particularly across multiple operating
>>> systems.  Most book authors avoid writing about it, as writing about it
>>> in sufficient detail would likely fill a book itself.  Most beginner
>>> books even stick with the `base` package so that readers do not even
>>> have to worry about packages.
>>>
>>> Global installation of packages leads to a *lot* of trouble when you get
>>> to more complex development.  When I first learned Haskell, I would
>>> occasionally completely remove my package database when I got into a
>>> situation that was difficult to resolve.  The situation improved a lot
>>> when Cabal introduced sandbox features, allowing dependencies to be
>>> managed separately per project.  Stack is project-based for the same
>>> reason: allowing each project to use separate sets of packages makes
>>> things a lot easier.  The "global-project" is called "global" because
>>> it is used when outside of any other Haskell project (determined by the
>>> existence of a `stack.yaml` file in the current working directory), but
>>> note that it is actually a project.  Following the instructions that I
>>> wrote in my previous email, you can configure Stack to work in the way
>>> that you want *without* running into the aforementioned trouble even
>>> when you start to develop other projects.
>>>
>>> Good luck!
>>>
>>> Travis
>>>
>>
>>
>> --
>> ⨽
>> Lawrence Bottorff
>> Grand Marais, MN, USA
>> borgauf at gmail.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.
>>
>>
>
> --
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210608/5651c4bf/attachment.html>

From jclites at mac.com  Tue Jun  8 18:48:47 2021
From: jclites at mac.com (Jeff Clites)
Date: Tue, 8 Jun 2021 11:48:47 -0700
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSWmBz4EC1UT6L_GFBwDNnkcRLiSeV27obJ+x0V+pEw-cQ@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
 <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>
 <CAFAhFSVLxjcyLVt03EKAT3Fy07KX4i67W-wuNTxea7RCEUC+6g@mail.gmail.com>
 <70BCE1F1-7031-4469-9998-4335148F91D6@mac.com>
 <CAFAhFSWmBz4EC1UT6L_GFBwDNnkcRLiSeV27obJ+x0V+pEw-cQ@mail.gmail.com>
Message-ID: <7058A69B-09DB-45BE-BCE9-EF0A2AAC40E1@mac.com>

I don’t know how XMonad works. Presumably it involves some dynamic loading of code, perhaps like dlopen in C. But that’s not an activity inherent or fundamental or common in Haskell programs.

Jeff

> On Jun 8, 2021, at 11:38 AM, Galaxy Being <borgauf at gmail.com> wrote:
> 
> But to my XMonad example. The Emacs world has the Emacs system running live, but the REPL capable of tweaking the live, running Emacs world in any way imaginable. Lisp and Scheme are this way too. (PicoLisp only this way.) Something similar must be happening with XMonad. After all, if I make configuration changes to xmonad.hs, somehow they must go into effect on a live, running XMonad, right? I don't log out of XMonad to a system shell, then compile the new executable with my config tweaks, then restart this new XMonad. No, I must be in some sort of Emacs-like situation -- or like a shell with C forking -- or some sort of event management device of XMonad where the "meta" XMonad is always running, but treating my config changes as hot-swappable plugins. Or like Unix/Linux with bootstrapping of a sort. Or am I missing something? I think this is very basic information, but I sure can't find it anywhere. As I have come to understand the REPL from the Lisp world, it's a running virtual machine that allows live tweaking and programming. An executable, OTOH, is an independent agent living as a process on the host OS. In Emacs, with some languages you can even have separate org mode babel REPL sessions. But back to XMonad, I'm guessing it's a Haskell executable that then acts like a virtual machine that allows hot-swapping plug-and-play....
> 
>> On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites <jclites at mac.com> wrote:
>>> On Jun 8, 2021, at 9:20 AM, Galaxy Being <borgauf at gmail.com> wrote:
>>> 
>>> If I'm understanding correctly, I can follow the stack way of setting up a project in a directory, then if I start a ghci REPL in that directory, I'm in that project's sandbox, true? But if I start a ghci REPL in some directory that has no stack project already set up, then that REPL is relying on the global "project," so to speak.
>> 
>> Yes. The point of Stack is to allow different projects to use different versions of GHC and different versions of libraries and have those projects never interfere with each other. To do this it’s logically necessary for Stack to always run based on a configuration file that tells it which set of versions you want to use for this run.
>> 
>>> It's somewhat confusing since the project way of doing Haskell is to compile with ghc, and run at a shell (same as C) and not have a running ghci. Two different cultures.
>> 
>> In both cases you are compiling some Haskell code and running it. It’s just that in the ghci case it’s doing both of those for you in one step. Really ghci is just meant for experimentation.
>> 
>> I think this is similar for most languages I’ve encountered that have a REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not directly using the REPL, even if the REPL happens to be built into the same tool you use to run your program. The REPL is mostly a tool for quick experimentation.
>> 
>> Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a loop around compiling and running some code. From that perspective, the compile and run steps are the fundamental steps and the REPL is just a bit of automation around those. It’s not the fundamental thing.
>> 
>>> It's difficult for me as a Haskell beginner to understand why beginner tutorials all have me working with the ghci REPL
>> 
>> It’s because that’s the way to run small experiments quickly. They are trying to teach you the language as concisely as possible, and not the overall development environment. (Also, as a practical matter, the instructions for setting up a development environment change and printed books don’t, so including detailed setup instructions would be a waste because they’d become out of date.)
>> 
>>> -- but then that's apparently not how real-world Haskell works. Or is it?
>> 
>> Correct; you don’t use the REPL to run large programs. You use it to try things out.
>> 
>>> So Emacs is a running ball of C and Elisp code with an Elisp REPL that gives you control over the running system.
>> 
>> Right. The Emacs case is different than others in that in this case your elisp programs are (typically) extending the functionality of this particular text editor, basically acting as plugin, rather than functioning as separate programs that have nothing to do with a text editor. I wouldn’t use Emacs as a model for conceptualizing other languages; it’s quite a special case.
>> 
>> Jeff
>> 
>>>> On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <travis.cardwell at extrema.is> wrote:
>>>> Sorry to hear that it is still not working for you yet.
>>>> 
>>>> On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
>>>> > I installed stack on my Windows computer using chocolatey, which went
>>>> > smoothly. But I had nothing anywhere I could find. On a hunch, at the
>>>> > prompt I tried to run stack ghci, then it started downloading and
>>>> > installing stuff. Good. I then was able to track down an example of a
>>>> > stack.yaml in the ...stack/global-project directory. My whole
>>>> > motivation was to see an actual global stack.yaml in the wild, and not
>>>> > have to guess-and-test from the stack docs.
>>>> 
>>>> Stack provides functionality to initialize a project with a "template"
>>>> so that you do not have to start from scratch.  For example, if you want
>>>> to start a new project called "HaskellTest" in your `~/Dropbox/org`
>>>> directory, run the following commands:
>>>> 
>>>>     $ cd ~/Dropbox/org
>>>>     $ stack new HaskellTest
>>>> 
>>>> The default template provides you with a `stack.yaml` file that includes
>>>> documentation and examples.  The template also provides you with a
>>>> `package.yaml` file (used to generate the `.cabal` file using hpack)
>>>> that has a library, executable, and test suite configured, as well as
>>>> stub source code and various other files.
>>>> 
>>>> Note that in cases where you already have a Haskell project (with a
>>>> `.cabal` or `package.yaml` file), the `stack init` command can be used
>>>> to add just the `stack.yaml` to the existing project.
>>>> 
>>>> > Good. I duplicated
>>>> >
>>>> > packages: []
>>>> > resolver: lts-17.15
>>>> >
>>>> > on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.
>>>> 
>>>> Note that this `stack.yaml` file is for the "global-project" as it does
>>>> not have any packages configured.  The `stack.yaml` file for any (other)
>>>> project should list at least one package.
>>>> 
>>>> > Tried running stack ghci from the Ubuntu prompt, and, similarly, it
>>>> > started installing lots of stuff. (The resolver version I replaced was
>>>> > lts-17.08. Why that old I don't know.).
>>>> 
>>>> The resolver snapshot in the "global-project" is set when you first run
>>>> Stack.  After that, it is up to you to update it *if/when* you would
>>>> like to use a different snapshot.
>>>> 
>>>> Similarly, the resolver snapshot for a project `stack.yaml` is set when
>>>> you run `stack new` or `stack init`, and then it is up to you to
>>>> maintain it as desired.
>>>> 
>>>> > But then I got a cryptic error as it seemed to clash or not like
>>>> > something it saw in some obscure github directory I had cloned ages
>>>> > ago with Haskell example code. I deleted everything in the github
>>>> > directory that looked stack/cabal-ish and tried stack ghci again. Now
>>>> > it says
>>>> >
>>>> > Warning (added by new or init): Some packages were found to have names conflicting with others and have been commented out in the packages section.
>>>> > Warning (added by new or init): Some packages were found to be incompatible with the resolver and have been left commented out in the packages section.
>>>> > You can omit this message by removing it from stack.yaml
>>>> >
>>>> > Stack looks for packages in the directories configured in
>>>> > the 'packages' and 'extra-deps' fields defined in your stack.yaml
>>>> > The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
>>>> > but no .cabal or package.yaml file could be found there.
>>>> >
>>>> > Yes, that was the directory I purged. My
>>>> > .stack/global-project/stack.yaml contains only
>>>> >
>>>> > packages: []
>>>> > resolver: lts-17.15
>>>> 
>>>> These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
>>>> being used.  It is likely that you are running `stack` commands in a
>>>> directory that contains a `stack.yaml` file which references these other
>>>> directories, and that file is being used.  Try (re)moving that
>>>> `stack.yaml` file and trying again.  Do the errors persist?
>>>> 
>>>> Once you (re)move the project `stack.yaml` configuration, the
>>>> `stack ghci` will use the `~/.stack/global-project/stack.yaml`
>>>> configuration.  With the above content, the LTS 17.15 resolver will be
>>>> used, with no packages configured.  As explained in my previous email,
>>>> this does *not* expose libraries to GHCi.  If you want to expose
>>>> libraries in the global project, you need to follow the instructions I
>>>> gave previously for configuring the global project.
>>>> 
>>>> > Not sure how to proceed. Seeing how that vast majority of Haskell
>>>> > intro books don't use projects, just install, start ghci, load code at
>>>> > the REPL prompt, I'd really like to nail this "global", non-project
>>>> > stack down.
>>>> 
>>>> Indeed.  Installation is tricky, particularly across multiple operating
>>>> systems.  Most book authors avoid writing about it, as writing about it
>>>> in sufficient detail would likely fill a book itself.  Most beginner
>>>> books even stick with the `base` package so that readers do not even
>>>> have to worry about packages.
>>>> 
>>>> Global installation of packages leads to a *lot* of trouble when you get
>>>> to more complex development.  When I first learned Haskell, I would
>>>> occasionally completely remove my package database when I got into a
>>>> situation that was difficult to resolve.  The situation improved a lot
>>>> when Cabal introduced sandbox features, allowing dependencies to be
>>>> managed separately per project.  Stack is project-based for the same
>>>> reason: allowing each project to use separate sets of packages makes
>>>> things a lot easier.  The "global-project" is called "global" because
>>>> it is used when outside of any other Haskell project (determined by the
>>>> existence of a `stack.yaml` file in the current working directory), but
>>>> note that it is actually a project.  Following the instructions that I
>>>> wrote in my previous email, you can configure Stack to work in the way
>>>> that you want *without* running into the aforementioned trouble even
>>>> when you start to develop other projects.
>>>> 
>>>> Good luck!
>>>> 
>>>> Travis
>>> 
>>> 
>>> -- 
>>> ⨽
>>> Lawrence Bottorff
>>> Grand Marais, MN, USA
>>> borgauf at gmail.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.
> 
> 
> -- 
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210608/e6b83887/attachment.html>

From allbery.b at gmail.com  Tue Jun  8 19:43:20 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 8 Jun 2021 15:43:20 -0400
Subject: [Haskell-cafe] Using stack outside the project box
In-Reply-To: <CAFAhFSWmBz4EC1UT6L_GFBwDNnkcRLiSeV27obJ+x0V+pEw-cQ@mail.gmail.com>
References: <CAFAhFSX_ezq0qpBBJpt30gBy219Z8C=zN8ccLoog10DCc3AMyw@mail.gmail.com>
 <0E7C397F-43AE-4098-AD2A-3028FDB30A71@mac.com>
 <CAFAhFSUN9--7c0nc3x7dRGNatUHgXhoPBANGhfDrfooPgtrbUw@mail.gmail.com>
 <CACaJP_SY2HkCY-E6zLgqDNTwSiCVMbzg0-uxT+rAgv-jhqke_A@mail.gmail.com>
 <CAFAhFSVcAY=JZ9e7EXAyBDOZug4C4Z3NHCPn3tbMcDfx+HxgbA@mail.gmail.com>
 <CACaJP_T+obn-uqEu0Q88-cj1ETFiBqEN=6iycV2zrHrYv5DUtQ@mail.gmail.com>
 <CAFAhFSVLxjcyLVt03EKAT3Fy07KX4i67W-wuNTxea7RCEUC+6g@mail.gmail.com>
 <70BCE1F1-7031-4469-9998-4335148F91D6@mac.com>
 <CAFAhFSWmBz4EC1UT6L_GFBwDNnkcRLiSeV27obJ+x0V+pEw-cQ@mail.gmail.com>
Message-ID: <CAKFCL4UWzgAt8Q+zq-+bmpLw=uJgrgtCej6aaYfwPGcQ+d0iNw@mail.gmail.com>

XMonad recompiles your config and then exec()s it, passing it some current
state. It's not the same as elisp.

On Tue, Jun 8, 2021 at 2:41 PM Galaxy Being <borgauf at gmail.com> wrote:

> But to my XMonad example. The Emacs world has the Emacs system running
> live, but the REPL capable of tweaking the live, running Emacs world in any
> way imaginable. Lisp and Scheme are this way too. (PicoLisp only this way.)
> Something similar must be happening with XMonad. After all, if I make
> configuration changes to xmonad.hs, somehow they must go into effect on a
> live, running XMonad, right? I don't log out of XMonad to a system shell,
> then compile the new executable with my config tweaks, then restart this
> new XMonad. No, I must be in some sort of Emacs-like situation -- or like a
> shell with C forking -- or some sort of event management device of XMonad
> where the "meta" XMonad is always running, but treating my config changes
> as hot-swappable plugins. Or like Unix/Linux with bootstrapping of a sort.
> Or am I missing something? I think this is very basic information, but I
> sure can't find it anywhere. As I have come to understand the REPL from the
> Lisp world, it's a running virtual machine that allows live tweaking and
> programming. An executable, OTOH, is an independent agent living as a
> process on the host OS. In Emacs, with some languages you can even have
> separate org mode babel REPL sessions. But back to XMonad, I'm guessing
> it's a Haskell executable that then acts like a virtual machine that allows
> hot-swapping plug-and-play....
>
> On Tue, Jun 8, 2021 at 12:29 PM Jeff Clites <jclites at mac.com> wrote:
>
>> On Jun 8, 2021, at 9:20 AM, Galaxy Being <borgauf at gmail.com> wrote:
>>
>> If I'm understanding correctly, I can follow the stack way of setting up
>> a project in a directory, then if I start a ghci REPL in that directory,
>> I'm in that project's sandbox, true? But if I start a ghci REPL in some
>> directory that has no stack project already set up, then that REPL is
>> relying on the global "project," so to speak.
>>
>>
>> Yes. The point of Stack is to allow different projects to use different
>> versions of GHC and different versions of libraries and have those projects
>> never interfere with each other. To do this it’s logically necessary for
>> Stack to always run based on a configuration file that tells it which set
>> of versions you want to use for this run.
>>
>> It's somewhat confusing since the project way of doing Haskell is to
>> compile with ghc, and run at a shell (same as C) and not have a running
>> ghci. Two different cultures.
>>
>>
>> In both cases you are compiling some Haskell code and running it. It’s
>> just that in the ghci case it’s doing both of those for you in one step.
>> Really ghci is just meant for experimentation.
>>
>> I think this is similar for most languages I’ve encountered that have a
>> REPL (Haskell, Scala, Ruby, Python)—when you run a full program it’s not
>> directly using the REPL, even if the REPL happens to be built into the same
>> tool you use to run your program. The REPL is mostly a tool for quick
>> experimentation.
>>
>> Remember what “REPL” stands for: Read-Evaluate-Print-Loop. It’s just a
>> loop around compiling and running some code. From that perspective, the
>> compile and run steps are the fundamental steps and the REPL is just a bit
>> of automation around those. It’s not the fundamental thing.
>>
>> It's difficult for me as a Haskell beginner to understand why beginner
>> tutorials all have me working with the ghci REPL
>>
>>
>> It’s because that’s the way to run small experiments quickly. They are
>> trying to teach you the language as concisely as possible, and not the
>> overall development environment. (Also, as a practical matter, the
>> instructions for setting up a development environment change and printed
>> books don’t, so including detailed setup instructions would be a waste
>> because they’d become out of date.)
>>
>> -- but then that's apparently not how real-world Haskell works. Or is it?
>>
>>
>> Correct; you don’t use the REPL to run large programs. You use it to try
>> things out.
>>
>> So Emacs is a running ball of C and Elisp code with an Elisp REPL that
>> gives you control over the running system.
>>
>>
>> Right. The Emacs case is different than others in that in this case your
>> elisp programs are (typically) extending the functionality of this
>> particular text editor, basically acting as plugin, rather than functioning
>> as separate programs that have nothing to do with a text editor. I wouldn’t
>> use Emacs as a model for conceptualizing other languages; it’s quite a
>> special case.
>>
>> Jeff
>>
>> On Mon, Jun 7, 2021 at 6:45 PM Travis Cardwell <
>> travis.cardwell at extrema.is> wrote:
>>
>>> Sorry to hear that it is still not working for you yet.
>>>
>>> On Tue, Jun 8, 2021 at 6:22 AM Galaxy Being wrote:
>>> > I installed stack on my Windows computer using chocolatey, which went
>>> > smoothly. But I had nothing anywhere I could find. On a hunch, at the
>>> > prompt I tried to run stack ghci, then it started downloading and
>>> > installing stuff. Good. I then was able to track down an example of a
>>> > stack.yaml in the ...stack/global-project directory. My whole
>>> > motivation was to see an actual global stack.yaml in the wild, and not
>>> > have to guess-and-test from the stack docs.
>>>
>>> Stack provides functionality to initialize a project with a "template"
>>> so that you do not have to start from scratch.  For example, if you want
>>> to start a new project called "HaskellTest" in your `~/Dropbox/org`
>>> directory, run the following commands:
>>>
>>>     $ cd ~/Dropbox/org
>>>     $ stack new HaskellTest
>>>
>>> The default template provides you with a `stack.yaml` file that includes
>>> documentation and examples.  The template also provides you with a
>>> `package.yaml` file (used to generate the `.cabal` file using hpack)
>>> that has a library, executable, and test suite configured, as well as
>>> stub source code and various other files.
>>>
>>> Note that in cases where you already have a Haskell project (with a
>>> `.cabal` or `package.yaml` file), the `stack init` command can be used
>>> to add just the `stack.yaml` to the existing project.
>>>
>>> > Good. I duplicated
>>> >
>>> > packages: []
>>> > resolver: lts-17.15
>>> >
>>> > on my Ubuntu 21.04 in the .stack/global-project/stack.yaml.
>>>
>>> Note that this `stack.yaml` file is for the "global-project" as it does
>>> not have any packages configured.  The `stack.yaml` file for any (other)
>>> project should list at least one package.
>>>
>>> > Tried running stack ghci from the Ubuntu prompt, and, similarly, it
>>> > started installing lots of stuff. (The resolver version I replaced was
>>> > lts-17.08. Why that old I don't know.).
>>>
>>> The resolver snapshot in the "global-project" is set when you first run
>>> Stack.  After that, it is up to you to update it *if/when* you would
>>> like to use a different snapshot.
>>>
>>> Similarly, the resolver snapshot for a project `stack.yaml` is set when
>>> you run `stack new` or `stack init`, and then it is up to you to
>>> maintain it as desired.
>>>
>>> > But then I got a cryptic error as it seemed to clash or not like
>>> > something it saw in some obscure github directory I had cloned ages
>>> > ago with Haskell example code. I deleted everything in the github
>>> > directory that looked stack/cabal-ish and tried stack ghci again. Now
>>> > it says
>>> >
>>> > Warning (added by new or init): Some packages were found to have names
>>> conflicting with others and have been commented out in the packages section.
>>> > Warning (added by new or init): Some packages were found to be
>>> incompatible with the resolver and have been left commented out in the
>>> packages section.
>>> > You can omit this message by removing it from stack.yaml
>>> >
>>> > Stack looks for packages in the directories configured in
>>> > the 'packages' and 'extra-deps' fields defined in your stack.yaml
>>> > The current entry points to /home/galaxybeing/Dropbox/org/HaskellRoad/,
>>> > but no .cabal or package.yaml file could be found there.
>>> >
>>> > Yes, that was the directory I purged. My
>>> > .stack/global-project/stack.yaml contains only
>>> >
>>> > packages: []
>>> > resolver: lts-17.15
>>>
>>> These errors indicate that `~/.stack/global-project/stack.yaml` is *not*
>>> being used.  It is likely that you are running `stack` commands in a
>>> directory that contains a `stack.yaml` file which references these other
>>> directories, and that file is being used.  Try (re)moving that
>>> `stack.yaml` file and trying again.  Do the errors persist?
>>>
>>> Once you (re)move the project `stack.yaml` configuration, the
>>> `stack ghci` will use the `~/.stack/global-project/stack.yaml`
>>> configuration.  With the above content, the LTS 17.15 resolver will be
>>> used, with no packages configured.  As explained in my previous email,
>>> this does *not* expose libraries to GHCi.  If you want to expose
>>> libraries in the global project, you need to follow the instructions I
>>> gave previously for configuring the global project.
>>>
>>> > Not sure how to proceed. Seeing how that vast majority of Haskell
>>> > intro books don't use projects, just install, start ghci, load code at
>>> > the REPL prompt, I'd really like to nail this "global", non-project
>>> > stack down.
>>>
>>> Indeed.  Installation is tricky, particularly across multiple operating
>>> systems.  Most book authors avoid writing about it, as writing about it
>>> in sufficient detail would likely fill a book itself.  Most beginner
>>> books even stick with the `base` package so that readers do not even
>>> have to worry about packages.
>>>
>>> Global installation of packages leads to a *lot* of trouble when you get
>>> to more complex development.  When I first learned Haskell, I would
>>> occasionally completely remove my package database when I got into a
>>> situation that was difficult to resolve.  The situation improved a lot
>>> when Cabal introduced sandbox features, allowing dependencies to be
>>> managed separately per project.  Stack is project-based for the same
>>> reason: allowing each project to use separate sets of packages makes
>>> things a lot easier.  The "global-project" is called "global" because
>>> it is used when outside of any other Haskell project (determined by the
>>> existence of a `stack.yaml` file in the current working directory), but
>>> note that it is actually a project.  Following the instructions that I
>>> wrote in my previous email, you can configure Stack to work in the way
>>> that you want *without* running into the aforementioned trouble even
>>> when you start to develop other projects.
>>>
>>> Good luck!
>>>
>>> Travis
>>>
>>
>>
>> --
>> ⨽
>> Lawrence Bottorff
>> Grand Marais, MN, USA
>> borgauf at gmail.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.
>>
>>
>
> --
> ⨽
> Lawrence Bottorff
> Grand Marais, MN, USA
> borgauf at gmail.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.



-- 
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/20210608/a5592fbf/attachment.html>

From dreixel at gmail.com  Wed Jun  9 16:39:44 2021
From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=)
Date: Wed, 9 Jun 2021 17:39:44 +0100
Subject: [Haskell-cafe] Hiring two Haskell devs at Standard Chartered bank
Message-ID: <CA+ZFbn-i+BAHrVz_aVc1DaQvtxTB+4pAvSZj-MiiH-942DQrtw@mail.gmail.com>

Hello,

I'm hiring two Haskell devs for my team at Standard Chartered bank, in
London, Singapore, or Hong Kong.

My team sits in front office and has about 20 Haskell devs (well,
technically Mu, our in-house variant). We work in close collaboration with
trading, sales, and structuring to build diverse software, from desktop GUI
applications to server-side financial analytics reports and services. The
current roles are at a relatively junior level -- 2 to 5 years industrial
experience expected, or a relevant PhD.

Feel free to reach out to me directly if you're interested and have any
questions, but applications should go via the links below.
Singapore:
https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014272
Hong Kong:
https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014571
London: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100012204

Standard Chartered supports (practically fully) remote working, but only
from the country of payroll. We will cover visa and relocation costs for
successful applicants.


Cheers,
Pedro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210609/a8a74549/attachment.html>

From carter.schonwald at gmail.com  Fri Jun 11 12:36:28 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 11 Jun 2021 08:36:28 -0400
Subject: [Haskell-cafe] A matrix.org client library proposal
In-Reply-To: <878s3o3rvb.tristanC@fedora>
References: <878s3o3rvb.tristanC@fedora>
Message-ID: <CAHYVw0zCBRR3ZRMAtPrRfhkAX7n1Hsojzmyiq2Fe62zeRWYL_A@mail.gmail.com>

Very cool! How are you tracking the protocol revisions?

On Sat, Jun 5, 2021 at 5:52 PM Tristan Cacqueray <tdecacqu at redhat.com>
wrote:

>
> Dear Café,
>
> I'd like to publish a rather simple `matrix-client` package on hackage
> based on this implementation:
>   https://github.com/softwarefactory-project/matrix-client-haskell
>
> Please let me know if you are interested or if you have a similar
> implementation we could collaborate on.
>
> Kind Regards,
> -Tristan
> _______________________________________________
> 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/20210611/7f9772d7/attachment.html>

From tdecacqu at redhat.com  Fri Jun 11 12:45:49 2021
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Fri, 11 Jun 2021 12:45:49 +0000
Subject: [Haskell-cafe] A matrix.org client library proposal
In-Reply-To: <CAHYVw0zCBRR3ZRMAtPrRfhkAX7n1Hsojzmyiq2Fe62zeRWYL_A@mail.gmail.com>
References: <878s3o3rvb.tristanC@fedora>
 <CAHYVw0zCBRR3ZRMAtPrRfhkAX7n1Hsojzmyiq2Fe62zeRWYL_A@mail.gmail.com>
Message-ID: <87wnr0muwy.tristanC@fedora>


I am hoping we could stick to the lastest revision.
If that is not possible, I guess we could provide a case-by-case
compat version when needed, or for the whole module, e.g.

  Network.Matrix.Client.V0_5_0
  Network.Matrix.Client.V0_6_1

Kind Regards,
-Tristan

On Fri, Jun 11, 2021 at 08:36 Carter Schonwald wrote:
> Very cool! How are you tracking the protocol revisions?
>
> On Sat, Jun 5, 2021 at 5:52 PM Tristan Cacqueray <tdecacqu at redhat.com>
> wrote:
>
>>
>> Dear Café,
>>
>> I'd like to publish a rather simple `matrix-client` package on hackage
>> based on this implementation:
>>   https://github.com/softwarefactory-project/matrix-client-haskell
>>
>> Please let me know if you are interested or if you have a similar
>> implementation we could collaborate on.
>>
>> Kind Regards,
>> -Tristan
>> _______________________________________________
>> 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: 515 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210611/5375e1b2/attachment.sig>

From simon.jakobi at googlemail.com  Fri Jun 11 14:26:09 2021
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Fri, 11 Jun 2021 16:26:09 +0200
Subject: [Haskell-cafe] Optimizing Eq instances with
	reallyUnsafePtrEquality#
In-Reply-To: <CABhTcUswv_QZ4fNQ8-6scAAYxzhLfGxMzvNGr9a2hJJ95mV1bA@mail.gmail.com>
References: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
 <56835f17-1372-b355-8d19-e98c8f7384fc@durchholz.org>
 <CABhTcUswv_QZ4fNQ8-6scAAYxzhLfGxMzvNGr9a2hJJ95mV1bA@mail.gmail.com>
Message-ID: <CAGtp2SiJPDRAw4_VVHS+pyn=bdgLydgAGJ+Qgd5WuAfvQAxfUQ@mail.gmail.com>

Thanks for the feedback everyone! :)

The gist I get is that using pointer equality is not free, but it can
make sense when

1. two objects are particularly likely to be the same;
2. establishing equality by other means (e.g. structural equality) is
particularly expensive

The usecases I now have in mind are:

* Lookups in unordered-containers: Since keys are only ==-d when their
hashes are equal, it seems that the likelihood that they are in fact
the same object should be fairly good. I think we can ignore the issue
of irreflexive instances here, because the lookup logic already
requires reflexivity.

* The Eq instances of containers' Set and IntSet types and of HashSet
from unordered-containers. These instances seem particularly
expensive, and Set and HashSet already require reflexivity. I don't
think we can apply the same optimizations to the Eq instances of the
various Map types, because we might run into irreflexive values there.

* Eq for lazy ByteStrings – another expensive instance. The instance
for strict ByteStrings already makes use of pointer equality.

Cheers,
Simon








Am Di., 8. Juni 2021 um 18:51 Uhr schrieb Sebastiaan Joosten
<sjcjoosten+haskell at gmail.com>:
>
> The containers library uses this trick:
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Utils/Containers/Internal/PtrEquality.hs
> It mentions the useful hint to evaluate the arguments to WHNF before calling PtrEquality.
> The function ptrEq is used here (for instance):
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L532
> The places where ptrEq is used in that file, its purpose seems to be to reduce memory by reusing existing data-structures, which I suppose also helps with performance.
> Surprisingly enough (at least to me) ptrEq is not used in the Eq instance there:
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L1141
>
> Outside of GHC, there are some (pure) languages that extensively make use of this principle and it's too cool not to mention:
> The programming language Elm does this in its generated code (at least when generating JavaScript): https://github.com/elm/compiler/
> The theorem proving environment ACL2 uses this principle for memoizing functions, fast 'Map's ('dictionaries' in python lingo, 'alist' or association-list in ACL2 lingo), as well as fast equality. As a LISP dialect, all data-structures are pairs (called CONS). In ACL2, the function 'HONS' (hashed CONS) will construct a pair if it does not already exist, and otherwise it returns a pointer to the already existing object. The point of using HONS in ACL2 is to only perform pointer comparison, without needing to do any other equality check.
> General background information: https://www.cs.utexas.edu/~ragerdl/acl2-manual/index.html?topic=ACL2____HONS-AND-MEMOIZATION
> The equality test: https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-EQUAL
> And there is of course a function to create a 'normed object': https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-COPY
> Note that the ACL2 approach only works because it is supported by the run time system (the implementation needs to access 'all data in memory') so it won't work in Haskell (assuming you're not writing your own RTS).
>
> Hope this helps.
>
> On Tue, Jun 8, 2021 at 10:47 AM Joachim Durchholz <jo at durchholz.org> wrote:
>>
>> Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
>> > Hi everyone!
>> >
>> > In https://github.com/haskell-unordered-containers/unordered-containers/issues/77
>> > we're wondering whether certain Eq instances, for example record types
>> > or strings, could be optimized by including a pointer equality check
>> > that detects when an object is compared with itself.
>>
>> You have to be aware that the pointer comparison itself does not come
>> for free. Execution prediction means that the "happy path" may be so
>> rare it's not loaded into the CPU cache and you might end with a slower
>> system - the case is somewhat pathological but not so rare that you can
>> just assume that it will not happen to you.
>> A lot also depends on whether the data to be compared needs to be loaded
>> anyway. If yes, the pointer comparison won't give you any gains, it will
>> be just one instruction more to execute, creating more execution unit
>> contention inside the CPU. If no, then obviously the pointer comparison
>> will help.
>>
>> In the end, you need to benchmark to see if it helps you.
>> And you cannot usefully benchmark unless you have also nailed down all
>> performance-relevant compiler and runtime options, which you do only if
>> you have exhausted all other optimization possibilities.
>>
>> IOW if it complicates your code, don't do it - unless you are already
>> long past the point where code reusability has taken a back seat to raw
>> optimization.
>>
>> Regards,
>> Jo
>> _______________________________________________
>> 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 simon.jakobi at googlemail.com  Fri Jun 11 14:27:00 2021
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Fri, 11 Jun 2021 16:27:00 +0200
Subject: [Haskell-cafe] Optimizing Eq instances with
	reallyUnsafePtrEquality#
In-Reply-To: <CAGtp2SiJPDRAw4_VVHS+pyn=bdgLydgAGJ+Qgd5WuAfvQAxfUQ@mail.gmail.com>
References: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
 <56835f17-1372-b355-8d19-e98c8f7384fc@durchholz.org>
 <CABhTcUswv_QZ4fNQ8-6scAAYxzhLfGxMzvNGr9a2hJJ95mV1bA@mail.gmail.com>
 <CAGtp2SiJPDRAw4_VVHS+pyn=bdgLydgAGJ+Qgd5WuAfvQAxfUQ@mail.gmail.com>
Message-ID: <CAGtp2Sgb7H99rjvc2c5PjVc+0E+x+uBk9LGyU=ProR7HnSdrBQ@mail.gmail.com>

(CC'ing the libraries list again)

Am Fr., 11. Juni 2021 um 16:26 Uhr schrieb Simon Jakobi
<simon.jakobi at googlemail.com>:
>
> Thanks for the feedback everyone! :)
>
> The gist I get is that using pointer equality is not free, but it can
> make sense when
>
> 1. two objects are particularly likely to be the same;
> 2. establishing equality by other means (e.g. structural equality) is
> particularly expensive
>
> The usecases I now have in mind are:
>
> * Lookups in unordered-containers: Since keys are only ==-d when their
> hashes are equal, it seems that the likelihood that they are in fact
> the same object should be fairly good. I think we can ignore the issue
> of irreflexive instances here, because the lookup logic already
> requires reflexivity.
>
> * The Eq instances of containers' Set and IntSet types and of HashSet
> from unordered-containers. These instances seem particularly
> expensive, and Set and HashSet already require reflexivity. I don't
> think we can apply the same optimizations to the Eq instances of the
> various Map types, because we might run into irreflexive values there.
>
> * Eq for lazy ByteStrings – another expensive instance. The instance
> for strict ByteStrings already makes use of pointer equality.
>
> Cheers,
> Simon
>
>
>
>
>
>
>
>
> Am Di., 8. Juni 2021 um 18:51 Uhr schrieb Sebastiaan Joosten
> <sjcjoosten+haskell at gmail.com>:
> >
> > The containers library uses this trick:
> > https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Utils/Containers/Internal/PtrEquality.hs
> > It mentions the useful hint to evaluate the arguments to WHNF before calling PtrEquality.
> > The function ptrEq is used here (for instance):
> > https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L532
> > The places where ptrEq is used in that file, its purpose seems to be to reduce memory by reusing existing data-structures, which I suppose also helps with performance.
> > Surprisingly enough (at least to me) ptrEq is not used in the Eq instance there:
> > https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L1141
> >
> > Outside of GHC, there are some (pure) languages that extensively make use of this principle and it's too cool not to mention:
> > The programming language Elm does this in its generated code (at least when generating JavaScript): https://github.com/elm/compiler/
> > The theorem proving environment ACL2 uses this principle for memoizing functions, fast 'Map's ('dictionaries' in python lingo, 'alist' or association-list in ACL2 lingo), as well as fast equality. As a LISP dialect, all data-structures are pairs (called CONS). In ACL2, the function 'HONS' (hashed CONS) will construct a pair if it does not already exist, and otherwise it returns a pointer to the already existing object. The point of using HONS in ACL2 is to only perform pointer comparison, without needing to do any other equality check.
> > General background information: https://www.cs.utexas.edu/~ragerdl/acl2-manual/index.html?topic=ACL2____HONS-AND-MEMOIZATION
> > The equality test: https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-EQUAL
> > And there is of course a function to create a 'normed object': https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-COPY
> > Note that the ACL2 approach only works because it is supported by the run time system (the implementation needs to access 'all data in memory') so it won't work in Haskell (assuming you're not writing your own RTS).
> >
> > Hope this helps.
> >
> > On Tue, Jun 8, 2021 at 10:47 AM Joachim Durchholz <jo at durchholz.org> wrote:
> >>
> >> Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
> >> > Hi everyone!
> >> >
> >> > In https://github.com/haskell-unordered-containers/unordered-containers/issues/77
> >> > we're wondering whether certain Eq instances, for example record types
> >> > or strings, could be optimized by including a pointer equality check
> >> > that detects when an object is compared with itself.
> >>
> >> You have to be aware that the pointer comparison itself does not come
> >> for free. Execution prediction means that the "happy path" may be so
> >> rare it's not loaded into the CPU cache and you might end with a slower
> >> system - the case is somewhat pathological but not so rare that you can
> >> just assume that it will not happen to you.
> >> A lot also depends on whether the data to be compared needs to be loaded
> >> anyway. If yes, the pointer comparison won't give you any gains, it will
> >> be just one instruction more to execute, creating more execution unit
> >> contention inside the CPU. If no, then obviously the pointer comparison
> >> will help.
> >>
> >> In the end, you need to benchmark to see if it helps you.
> >> And you cannot usefully benchmark unless you have also nailed down all
> >> performance-relevant compiler and runtime options, which you do only if
> >> you have exhausted all other optimization possibilities.
> >>
> >> IOW if it complicates your code, don't do it - unless you are already
> >> long past the point where code reusability has taken a back seat to raw
> >> optimization.
> >>
> >> Regards,
> >> Jo
> >> _______________________________________________
> >> 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 david.feuer at gmail.com  Fri Jun 11 14:35:20 2021
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 11 Jun 2021 10:35:20 -0400
Subject: [Haskell-cafe] Optimizing Eq instances with
	reallyUnsafePtrEquality#
In-Reply-To: <CAGtp2SiJPDRAw4_VVHS+pyn=bdgLydgAGJ+Qgd5WuAfvQAxfUQ@mail.gmail.com>
References: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
 <56835f17-1372-b355-8d19-e98c8f7384fc@durchholz.org>
 <CABhTcUswv_QZ4fNQ8-6scAAYxzhLfGxMzvNGr9a2hJJ95mV1bA@mail.gmail.com>
 <CAGtp2SiJPDRAw4_VVHS+pyn=bdgLydgAGJ+Qgd5WuAfvQAxfUQ@mail.gmail.com>
Message-ID: <CAMgWh9v=GUTANSK8azUfiF=UMZiz6szQL9FSDD7fWhapH=bhGA@mail.gmail.com>

As far as I'm concerned, nonreflexive instances are not supported by
`containers` at all. If your == isn't reflexive, you just need to assume
that anything with an Eq constraint might behave arbitrarily badly.

On Fri, Jun 11, 2021, 10:27 AM Simon Jakobi via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Thanks for the feedback everyone! :)
>
> The gist I get is that using pointer equality is not free, but it can
> make sense when
>
> 1. two objects are particularly likely to be the same;
> 2. establishing equality by other means (e.g. structural equality) is
> particularly expensive
>
> The usecases I now have in mind are:
>
> * Lookups in unordered-containers: Since keys are only ==-d when their
> hashes are equal, it seems that the likelihood that they are in fact
> the same object should be fairly good. I think we can ignore the issue
> of irreflexive instances here, because the lookup logic already
> requires reflexivity.
>
> * The Eq instances of containers' Set and IntSet types and of HashSet
> from unordered-containers. These instances seem particularly
> expensive, and Set and HashSet already require reflexivity. I don't
> think we can apply the same optimizations to the Eq instances of the
> various Map types, because we might run into irreflexive values there.
>
> * Eq for lazy ByteStrings – another expensive instance. The instance
> for strict ByteStrings already makes use of pointer equality.
>
> Cheers,
> Simon
>
>
>
>
>
>
>
>
> Am Di., 8. Juni 2021 um 18:51 Uhr schrieb Sebastiaan Joosten
> <sjcjoosten+haskell at gmail.com>:
> >
> > The containers library uses this trick:
> >
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Utils/Containers/Internal/PtrEquality.hs
> > It mentions the useful hint to evaluate the arguments to WHNF before
> calling PtrEquality.
> > The function ptrEq is used here (for instance):
> >
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L532
> > The places where ptrEq is used in that file, its purpose seems to be to
> reduce memory by reusing existing data-structures, which I suppose also
> helps with performance.
> > Surprisingly enough (at least to me) ptrEq is not used in the Eq
> instance there:
> >
> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L1141
> >
> > Outside of GHC, there are some (pure) languages that extensively make
> use of this principle and it's too cool not to mention:
> > The programming language Elm does this in its generated code (at least
> when generating JavaScript): https://github.com/elm/compiler/
> > The theorem proving environment ACL2 uses this principle for memoizing
> functions, fast 'Map's ('dictionaries' in python lingo, 'alist' or
> association-list in ACL2 lingo), as well as fast equality. As a LISP
> dialect, all data-structures are pairs (called CONS). In ACL2, the function
> 'HONS' (hashed CONS) will construct a pair if it does not already exist,
> and otherwise it returns a pointer to the already existing object. The
> point of using HONS in ACL2 is to only perform pointer comparison, without
> needing to do any other equality check.
> > General background information:
> https://www.cs.utexas.edu/~ragerdl/acl2-manual/index.html?topic=ACL2____HONS-AND-MEMOIZATION
> > The equality test:
> https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-EQUAL
> > And there is of course a function to create a 'normed object':
> https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-COPY
> > Note that the ACL2 approach only works because it is supported by the
> run time system (the implementation needs to access 'all data in memory')
> so it won't work in Haskell (assuming you're not writing your own RTS).
> >
> > Hope this helps.
> >
> > On Tue, Jun 8, 2021 at 10:47 AM Joachim Durchholz <jo at durchholz.org>
> wrote:
> >>
> >> Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
> >> > Hi everyone!
> >> >
> >> > In
> https://github.com/haskell-unordered-containers/unordered-containers/issues/77
> >> > we're wondering whether certain Eq instances, for example record types
> >> > or strings, could be optimized by including a pointer equality check
> >> > that detects when an object is compared with itself.
> >>
> >> You have to be aware that the pointer comparison itself does not come
> >> for free. Execution prediction means that the "happy path" may be so
> >> rare it's not loaded into the CPU cache and you might end with a slower
> >> system - the case is somewhat pathological but not so rare that you can
> >> just assume that it will not happen to you.
> >> A lot also depends on whether the data to be compared needs to be loaded
> >> anyway. If yes, the pointer comparison won't give you any gains, it will
> >> be just one instruction more to execute, creating more execution unit
> >> contention inside the CPU. If no, then obviously the pointer comparison
> >> will help.
> >>
> >> In the end, you need to benchmark to see if it helps you.
> >> And you cannot usefully benchmark unless you have also nailed down all
> >> performance-relevant compiler and runtime options, which you do only if
> >> you have exhausted all other optimization possibilities.
> >>
> >> IOW if it complicates your code, don't do it - unless you are already
> >> long past the point where code reusability has taken a back seat to raw
> >> optimization.
> >>
> >> Regards,
> >> Jo
> >> _______________________________________________
> >> 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.
> _______________________________________________
> 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/20210611/6127f31a/attachment.html>

From mail at joachim-breitner.de  Fri Jun 11 19:54:30 2021
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 11 Jun 2021 21:54:30 +0200
Subject: [Haskell-cafe] Could optimize attoparsec if GHC would collapse
 `runParser (Parser parser)` to `parser`
In-Reply-To: <CAJbx2R5G7b39Q05mw2hT4_zp1XC44ZQ1MW4NmaVvFKZcArNkuA@mail.gmail.com>
References: <CAJbx2R5G7b39Q05mw2hT4_zp1XC44ZQ1MW4NmaVvFKZcArNkuA@mail.gmail.com>
Message-ID: <dc2308a041400cc97e14dfc5dc8bf8be17068ceb.camel@joachim-breitner.de>

Hi Tyson,

Am Donnerstag, den 27.05.2021, 14:31 -0400 schrieb Tyson Whitehead:
> Hi. I'm hoping someone with some knowledge about GHC optimizations can
> weigh in and help out here.

did you get any help with this? It’s an interesting question and a
well-written request for help, too bad it seems it went unnoticed.
Maybe it would have gotten better answers on
<glasgow-haskell-users at haskell.org>?

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



From han.joosten.han at gmail.com  Fri Jun 11 21:16:43 2021
From: han.joosten.han at gmail.com (Han Joosten)
Date: Fri, 11 Jun 2021 23:16:43 +0200
Subject: [Haskell-cafe] Need advise with using Quickcheck
Message-ID: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>

Dear café,

I want to implement a roundtrip test for a parser/prettyprinter
combination. Let me try to explain what I am struggling with. I start with
some type definitions of functions I have


*data Guarded a =*


*      Errors (NE.NonEmpty CtxError)     | Checked a [Warning]*

*parseFoo :: Text -> Guarded Foo*
*prettyFoo :: Foo -> Text*

The idea is that for all foo :: Foo, the following holds:
    *parseFoo . prettyFoo $ foo*  should be equal to  *Checked foo []*

Now, if there is a counterexample, I would like to see prettyFoo foo as
output, folowed by the show of the Errors part.

I have been struggling to get this working, but without luck so far. I am
not very familiar with Quickcheck, so that could be the problem too.

Any help would be appreciated!

Thanks
Han
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210611/10358e27/attachment.html>

From ruben.astud at gmail.com  Fri Jun 11 21:31:28 2021
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Fri, 11 Jun 2021 17:31:28 -0400
Subject: [Haskell-cafe] Need advise with using Quickcheck
In-Reply-To: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>
References: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>
Message-ID: <290de44c-96d8-096a-8504-5a300b42a1cb@gmail.com>

Hello Han

On 11-06-21 17:16, Han Joosten wrote:
> [..]
> *parseFoo :: Text -> Guarded Foo*
> *prettyFoo :: Foo -> Text*
> 
> The idea is that for all foo :: Foo, the following holds:
>     *parseFoo . prettyFoo $ foo*  should be equal to  *Checked foo []*
> 
> Now, if there is a counterexample, I would like to see prettyFoo foo as
> output, folowed by the show of the Errors part.

It seems you know what property should hold for `parseFoo` and `prettyFoo`.
Per the QuickCheck manual [1] this could be written as

    import Test.QuickCheck

    propOnAllFooText :: Property
    propOnAllFooText = forAll (arbitrary :: Gen Foo) $ \exFoo ->
        parseFoo (prettyFoo exFoo) == Checked exFoo []

What you are missing is a way to generate the test cases (the `arbitrary'
generator above). You need a way to declare this instance

    instance Arbitrary Foo where
        -- arbitrary :: Gen Foo
        arbitrary = <something>

You can see example on how to define it on the manual [1]. Good luck.

[1]: http://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html

-- 
-- Rubén
-- pgp: 4EE9 28F7 932E F4AD

From carter.schonwald at gmail.com  Fri Jun 11 22:04:32 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 11 Jun 2021 18:04:32 -0400
Subject: [Haskell-cafe] Optimizing Eq instances with
	reallyUnsafePtrEquality#
In-Reply-To: <CAMgWh9v=GUTANSK8azUfiF=UMZiz6szQL9FSDD7fWhapH=bhGA@mail.gmail.com>
References: <CAGtp2Si5U7YoA2AR=Q9aeRJ6P+eeFjpTtfqa-wuooN_pGBYXig@mail.gmail.com>
 <56835f17-1372-b355-8d19-e98c8f7384fc@durchholz.org>
 <CABhTcUswv_QZ4fNQ8-6scAAYxzhLfGxMzvNGr9a2hJJ95mV1bA@mail.gmail.com>
 <CAGtp2SiJPDRAw4_VVHS+pyn=bdgLydgAGJ+Qgd5WuAfvQAxfUQ@mail.gmail.com>
 <CAMgWh9v=GUTANSK8azUfiF=UMZiz6szQL9FSDD7fWhapH=bhGA@mail.gmail.com>
Message-ID: <CAHYVw0w73LfGDsZBiamenwVG7-EaQVpNmUS+hj7xFcsWGB==HA@mail.gmail.com>

Yup!

;)
Filter your floats for nans!

On Fri, Jun 11, 2021 at 10:38 AM David Feuer <david.feuer at gmail.com> wrote:

> As far as I'm concerned, nonreflexive instances are not supported by
> `containers` at all. If your == isn't reflexive, you just need to assume
> that anything with an Eq constraint might behave arbitrarily badly.
>
> On Fri, Jun 11, 2021, 10:27 AM Simon Jakobi via Haskell-Cafe <
> haskell-cafe at haskell.org> wrote:
>
>> Thanks for the feedback everyone! :)
>>
>> The gist I get is that using pointer equality is not free, but it can
>> make sense when
>>
>> 1. two objects are particularly likely to be the same;
>> 2. establishing equality by other means (e.g. structural equality) is
>> particularly expensive
>>
>> The usecases I now have in mind are:
>>
>> * Lookups in unordered-containers: Since keys are only ==-d when their
>> hashes are equal, it seems that the likelihood that they are in fact
>> the same object should be fairly good. I think we can ignore the issue
>> of irreflexive instances here, because the lookup logic already
>> requires reflexivity.
>>
>> * The Eq instances of containers' Set and IntSet types and of HashSet
>> from unordered-containers. These instances seem particularly
>> expensive, and Set and HashSet already require reflexivity. I don't
>> think we can apply the same optimizations to the Eq instances of the
>> various Map types, because we might run into irreflexive values there.
>>
>> * Eq for lazy ByteStrings – another expensive instance. The instance
>> for strict ByteStrings already makes use of pointer equality.
>>
>> Cheers,
>> Simon
>>
>>
>>
>>
>>
>>
>>
>>
>> Am Di., 8. Juni 2021 um 18:51 Uhr schrieb Sebastiaan Joosten
>> <sjcjoosten+haskell at gmail.com>:
>> >
>> > The containers library uses this trick:
>> >
>> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Utils/Containers/Internal/PtrEquality.hs
>> > It mentions the useful hint to evaluate the arguments to WHNF before
>> calling PtrEquality.
>> > The function ptrEq is used here (for instance):
>> >
>> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L532
>> > The places where ptrEq is used in that file, its purpose seems to be to
>> reduce memory by reusing existing data-structures, which I suppose also
>> helps with performance.
>> > Surprisingly enough (at least to me) ptrEq is not used in the Eq
>> instance there:
>> >
>> https://github.com/haskell/containers/blob/30ccbaa201043109bf1ee905c66ccd0dbe24422f/containers/src/Data/Set/Internal.hs#L1141
>> >
>> > Outside of GHC, there are some (pure) languages that extensively make
>> use of this principle and it's too cool not to mention:
>> > The programming language Elm does this in its generated code (at least
>> when generating JavaScript): https://github.com/elm/compiler/
>> > The theorem proving environment ACL2 uses this principle for memoizing
>> functions, fast 'Map's ('dictionaries' in python lingo, 'alist' or
>> association-list in ACL2 lingo), as well as fast equality. As a LISP
>> dialect, all data-structures are pairs (called CONS). In ACL2, the function
>> 'HONS' (hashed CONS) will construct a pair if it does not already exist,
>> and otherwise it returns a pointer to the already existing object. The
>> point of using HONS in ACL2 is to only perform pointer comparison, without
>> needing to do any other equality check.
>> > General background information:
>> https://www.cs.utexas.edu/~ragerdl/acl2-manual/index.html?topic=ACL2____HONS-AND-MEMOIZATION
>> > The equality test:
>> https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-EQUAL
>> > And there is of course a function to create a 'normed object':
>> https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____HONS-COPY
>> > Note that the ACL2 approach only works because it is supported by the
>> run time system (the implementation needs to access 'all data in memory')
>> so it won't work in Haskell (assuming you're not writing your own RTS).
>> >
>> > Hope this helps.
>> >
>> > On Tue, Jun 8, 2021 at 10:47 AM Joachim Durchholz <jo at durchholz.org>
>> wrote:
>> >>
>> >> Am 08.06.21 um 16:25 schrieb Simon Jakobi via Haskell-Cafe:
>> >> > Hi everyone!
>> >> >
>> >> > In
>> https://github.com/haskell-unordered-containers/unordered-containers/issues/77
>> >> > we're wondering whether certain Eq instances, for example record
>> types
>> >> > or strings, could be optimized by including a pointer equality check
>> >> > that detects when an object is compared with itself.
>> >>
>> >> You have to be aware that the pointer comparison itself does not come
>> >> for free. Execution prediction means that the "happy path" may be so
>> >> rare it's not loaded into the CPU cache and you might end with a slower
>> >> system - the case is somewhat pathological but not so rare that you can
>> >> just assume that it will not happen to you.
>> >> A lot also depends on whether the data to be compared needs to be
>> loaded
>> >> anyway. If yes, the pointer comparison won't give you any gains, it
>> will
>> >> be just one instruction more to execute, creating more execution unit
>> >> contention inside the CPU. If no, then obviously the pointer comparison
>> >> will help.
>> >>
>> >> In the end, you need to benchmark to see if it helps you.
>> >> And you cannot usefully benchmark unless you have also nailed down all
>> >> performance-relevant compiler and runtime options, which you do only if
>> >> you have exhausted all other optimization possibilities.
>> >>
>> >> IOW if it complicates your code, don't do it - unless you are already
>> >> long past the point where code reusability has taken a back seat to raw
>> >> optimization.
>> >>
>> >> Regards,
>> >> Jo
>> >> _______________________________________________
>> >> 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.
>> _______________________________________________
>> 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/20210611/62ec44ee/attachment.html>

From safinaskar at mail.ru  Fri Jun 11 22:18:30 2021
From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=)
Date: Sat, 12 Jun 2021 01:18:30 +0300
Subject: [Haskell-cafe] =?utf-8?q?Pearl!_I_just_proved_theorem_about_impos?=
 =?utf-8?q?sibility_of_monad_transformer_for_parsing_with_=281=29_unbiased?=
 =?utf-8?q?_choice_and_=282=29_ambiguity_checking_before_running_embedded_?=
 =?utf-8?q?monadic_action_=28also=2C_I_THREAT_I_will_create_another_parsin?=
 =?utf-8?q?g_lib=29?=
Message-ID: <1623449910.725986714@f337.i.mail.ru>

Hi. I hope people here, at haskell-cafe, like various theorem, pearls on parsing, monads, monad transformers and anything like that, right? So, I just proved something interesting for you!
Theorem about impossibility of monad transformer for parsing with (1) unbiased choice and (2) ambiguity checking before running embedded monadic action.
I already presented it on #haskell in Libera chat, now let me send it here. This is not quite theorem, i. e. I would not say that it keeps with mathematical standards of rigor.
---------------------------
I want monad transformer (let's name it ParserT) with following properties (hint: I proved such transformer doesn't exist):

- it has unbiased choice (i. e. (<|>) :: ParserT m a -> ParserT m a -> ParserT m a) (this means running parser can give you multiple results)
- you can run parser without executing embedded monadic actions. i. e. "run" function should look like this:

run :: ParserT m a -> String -> [m a] {- Not m [a] -}

I want such function, because I want to do this: run parser, then count number of possible parses, then (if count is equal to one) actually execute embedded monadic action. I. e. I want something like this:

parser :: ParserT (Either String) ()
parser = .....

main :: IO ()
main = do {
  input <- ....;
  case run parser input of {
    [res] -> do {
      -- Cool! we got exactly one result! Let's run it
      case res of {
        Left e -> putStr $ "Parsing succeed, but we have semantic error: " ++ e;
        Right () -> putStr "Everything OK";
      };
    };
    _ -> putStr "Cannot parse. 0 parse trees or >1 parse trees";
  };
}

Now let me state theorem.

Theorem. Such transformer doesn't exist. Moreover, even if I replace arbitrary monad "m" with particular monad "Maybe" (or "Either String") the task is still unsolvable. But the task seems achievable using arrows

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

Proof. Let's imagine such "ParsecT Maybe" exists. Let's imagine we have such function:

char :: Char -> ParserT Maybe Char {- matches supplied char -}

Also, keep in mind we have "lift":

lift :: Maybe a -> ParserT Maybe a

Now let's write this:

parseA = char 'a'
parseAorA = char 'a' <|> char 'a'
contr = do {
  a <- lift $ Nothing;
  if a > 5 then parseA else parseAorA;
  return ();
}

Now, please, say, what is (run contr "a")? How many elements will (run contr "a") have? If "a > 5", then (run contr "a") will contain one element. If "a <= 5", then (run contr "a") will contain two elements. But we cannot know whether "a > 5", because we cannot extract "a" from "Nothing". So, we got contradiction. QED
-----------------
In other words, function "run" with type "ParserT m a -> String -> [m a]" means that we should somehow be able to know count of parses before executing monadic action. But this is impossible, because our parser can contain code like this: (do { a <- lift $ ...; if a then ... else ...; }). I. e. count of parses can depend on value, embedded in inner monad, so we cannot know count of parses before we run embedded inner monadic action.

This theorem is not simply out of curiosity. I actually need parsing lib with this properties.

1. I need unbiased choice, because it is compatible with CFGs, and I love CFGs (as opposed to PEG)
2. I need embedding monads, because this allows me to check semantic errors (such as "type mismatch") in time of parsing. I. e. I can simply embed (Either String) monad into parsing monad, and use this (Either String) monad for checking semantic errors
3. I need to know number of parse trees before executing monadic actions (i. e. i need ([m a]) as opposed to (m [a])), because I want to check that number of parses is equal to 1 (if not, then print error), and then extract inner monad (which will contain information about semantic errors). In other words, I want check the input for ambiguity (and print error if it is ambiguous), and if it is not ambiguous, then print possible semantic errors (if any). The possibility of ambiguity detection is whole point of using CFGs as opposed to PEGs (which are always unambiguous, but this unambiguity is simply trick).
4. Every terminal and nonterminal should carry location info (i. e. begin and end of this string). And this location info should be passed implicitly. And it should not be embedded deeply in ASTs I will use. (This means that "happy" is not for me. As well as I understand it cannot implicitly pass location info. In https://github.com/ghc/ghc/blob/master/compiler/GHC/Parser.y I see explicit location management all the time.)
5. Left recursion is not needed

So, does such lib exist? Well, I already know such lib should be arrow based (as opposed to monad). So, is there such arrow parsing lib? Embedding arbitrary inner monad is not needed, just embedding (Either String) will go.

If there is no such lib, I plan to create my own. This is threat! :)

Also, I wrote letter long ago asking for parsing lib with different properties. I included desire for reversibility, among others. Well, this was other task. For my current task I don't need reversibility.

==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

From cdsmith at gmail.com  Fri Jun 11 23:12:17 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Fri, 11 Jun 2021 19:12:17 -0400
Subject: [Haskell-cafe] Pearl! I just proved theorem about impossibility
 of monad transformer for parsing with (1) unbiased choice and (2) ambiguity
 checking before running embedded monadic action (also,
 I THREAT I will create another parsing lib)
In-Reply-To: <1623449910.725986714@f337.i.mail.ru>
References: <1623449910.725986714@f337.i.mail.ru>
Message-ID: <CAPq5PvJnAQntH0C_QE=cJOaBni6PDd5sBbUg+T69pwkUmT87Gw@mail.gmail.com>

Details aside, this sounds like an instance of the common relationship
between Monad and Applicative: namely, analysis is possible on Applicative
structures without executing effects, while Monad structures cannot be
analyzed without executing its effects in a specific instance and looking
at their results.  That's less specific than your result and uses some
fuzzy language, but it's a pattern that comes up a lot.  As far as Arrow,
in the absence of ArrowApply it occupies a space similar to Applicative.  I
imagine an ArrowApply instance would interfere with your desired properties
in the same way that a Monad instance does.

People have definitely talked about using Applicative for parsing in
this way (e.g., see
https://jobjo.github.io/2019/05/19/applicative-parsing.html), but I'm not
familiar with a specific parsing library that meets your needs.  Maybe
someone else can jump in there. I just wanted to suggest that you broaden
your search to include Applicative-based parsers as well as Arrow-based.

Good luck!

Chris

On Fri, Jun 11, 2021 at 6:22 PM Askar Safin via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> Hi. I hope people here, at haskell-cafe, like various theorem, pearls on
> parsing, monads, monad transformers and anything like that, right? So, I
> just proved something interesting for you!
> Theorem about impossibility of monad transformer for parsing with (1)
> unbiased choice and (2) ambiguity checking before running embedded monadic
> action.
> I already presented it on #haskell in Libera chat, now let me send it
> here. This is not quite theorem, i. e. I would not say that it keeps with
> mathematical standards of rigor.
> ---------------------------
> I want monad transformer (let's name it ParserT) with following properties
> (hint: I proved such transformer doesn't exist):
>
> - it has unbiased choice (i. e. (<|>) :: ParserT m a -> ParserT m a ->
> ParserT m a) (this means running parser can give you multiple results)
> - you can run parser without executing embedded monadic actions. i. e.
> "run" function should look like this:
>
> run :: ParserT m a -> String -> [m a] {- Not m [a] -}
>
> I want such function, because I want to do this: run parser, then count
> number of possible parses, then (if count is equal to one) actually execute
> embedded monadic action. I. e. I want something like this:
>
> parser :: ParserT (Either String) ()
> parser = .....
>
> main :: IO ()
> main = do {
>   input <- ....;
>   case run parser input of {
>     [res] -> do {
>       -- Cool! we got exactly one result! Let's run it
>       case res of {
>         Left e -> putStr $ "Parsing succeed, but we have semantic error: "
> ++ e;
>         Right () -> putStr "Everything OK";
>       };
>     };
>     _ -> putStr "Cannot parse. 0 parse trees or >1 parse trees";
>   };
> }
>
> Now let me state theorem.
>
> Theorem. Such transformer doesn't exist. Moreover, even if I replace
> arbitrary monad "m" with particular monad "Maybe" (or "Either String") the
> task is still unsolvable. But the task seems achievable using arrows
>
> -------------------------------------
>
> Proof. Let's imagine such "ParsecT Maybe" exists. Let's imagine we have
> such function:
>
> char :: Char -> ParserT Maybe Char {- matches supplied char -}
>
> Also, keep in mind we have "lift":
>
> lift :: Maybe a -> ParserT Maybe a
>
> Now let's write this:
>
> parseA = char 'a'
> parseAorA = char 'a' <|> char 'a'
> contr = do {
>   a <- lift $ Nothing;
>   if a > 5 then parseA else parseAorA;
>   return ();
> }
>
> Now, please, say, what is (run contr "a")? How many elements will (run
> contr "a") have? If "a > 5", then (run contr "a") will contain one element.
> If "a <= 5", then (run contr "a") will contain two elements. But we cannot
> know whether "a > 5", because we cannot extract "a" from "Nothing". So, we
> got contradiction. QED
> -----------------
> In other words, function "run" with type "ParserT m a -> String -> [m a]"
> means that we should somehow be able to know count of parses before
> executing monadic action. But this is impossible, because our parser can
> contain code like this: (do { a <- lift $ ...; if a then ... else ...; }).
> I. e. count of parses can depend on value, embedded in inner monad, so we
> cannot know count of parses before we run embedded inner monadic action.
>
> This theorem is not simply out of curiosity. I actually need parsing lib
> with this properties.
>
> 1. I need unbiased choice, because it is compatible with CFGs, and I love
> CFGs (as opposed to PEG)
> 2. I need embedding monads, because this allows me to check semantic
> errors (such as "type mismatch") in time of parsing. I. e. I can simply
> embed (Either String) monad into parsing monad, and use this (Either
> String) monad for checking semantic errors
> 3. I need to know number of parse trees before executing monadic actions
> (i. e. i need ([m a]) as opposed to (m [a])), because I want to check that
> number of parses is equal to 1 (if not, then print error), and then extract
> inner monad (which will contain information about semantic errors). In
> other words, I want check the input for ambiguity (and print error if it is
> ambiguous), and if it is not ambiguous, then print possible semantic errors
> (if any). The possibility of ambiguity detection is whole point of using
> CFGs as opposed to PEGs (which are always unambiguous, but this unambiguity
> is simply trick).
> 4. Every terminal and nonterminal should carry location info (i. e. begin
> and end of this string). And this location info should be passed
> implicitly. And it should not be embedded deeply in ASTs I will use. (This
> means that "happy" is not for me. As well as I understand it cannot
> implicitly pass location info. In
> https://github.com/ghc/ghc/blob/master/compiler/GHC/Parser.y I see
> explicit location management all the time.)
> 5. Left recursion is not needed
>
> So, does such lib exist? Well, I already know such lib should be arrow
> based (as opposed to monad). So, is there such arrow parsing lib? Embedding
> arbitrary inner monad is not needed, just embedding (Either String) will go.
>
> If there is no such lib, I plan to create my own. This is threat! :)
>
> Also, I wrote letter long ago asking for parsing lib with different
> properties. I included desire for reversibility, among others. Well, this
> was other task. For my current task I don't need reversibility.
>
> ==
> Askar Safin
> http://safinaskar.com
> https://sr.ht/~safinaskar
> https://github.com/safinaskar
> _______________________________________________
> 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/20210611/64ba2946/attachment-0001.html>

From safinaskar at mail.ru  Sat Jun 12 00:24:16 2021
From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=)
Date: Sat, 12 Jun 2021 03:24:16 +0300
Subject: [Haskell-cafe]
 =?utf-8?q?Pearl!_I_just_proved_theorem_about_impos?=
 =?utf-8?q?sibility_of_monad_transformer_for_parsing_with_=281=29_unbiased?=
 =?utf-8?q?_choice_and_=282=29_ambiguity_checking_before_running_embedded_?=
 =?utf-8?q?monadic_action_=28also=2C_I_THREAT_I_will_create_another_parsin?=
 =?utf-8?q?g_lib=29?=
In-Reply-To: <CAPq5PvJnAQntH0C_QE=cJOaBni6PDd5sBbUg+T69pwkUmT87Gw@mail.gmail.com>
References: <1623449910.725986714@f337.i.mail.ru>
 <CAPq5PvJnAQntH0C_QE=cJOaBni6PDd5sBbUg+T69pwkUmT87Gw@mail.gmail.com>
Message-ID: <1623457456.570972111@f163.i.mail.ru>

> Details aside, this sounds like an instance of the common relationship between
Hi. Thanks for answer! Applicative is not for me. Let's imagine hypothetical "Parser", which is instance of Applicative, but not Monad. It can fail with some error message.
This is how expressions like (1+(1+1)) can be parsed with it:
--------
{-# LANGUAGE ApplicativeDo #-}
char :: Char -> Parser Char
char = ...
p :: Parser Int
p = do { -- applicative do
  char '1';
  pure 1;
} <|> do {
  char '(';
  a <- p;
  char '+';
  b <- p;
  char ')';
  pure $ a + b;
}
-------
Okey, everything is OK, but how to fail with message? Let's imagine we have such function:

failWith :: String -> Parser a

How to use it? Let's try:
-----
q :: Parser Int
q = do {
  char '(';
  a <- p;
  char '/';
  b <- p;
  char ')';
  if b == 0 then failWith "division by zero" else pure (a / b);
}
-----
Unfortunately, this cannot be desugared as Applicative. So, we need this function instead:

fromEither :: Parser (Either String a) -> Parser a

Now we can write this:
-----
q :: Parser Int
q = fromEither $ do { -- applicative do
  char '(';
  a <- p;
  char '/';
  b <- p;
  char ')';
  pure $ do { -- normal monadic do
    when (b == 0) $ Left "division by zero";
    return $ a / b;
  };
}
------
Yay! Now everything works with Applicative. Moreover, it seems we can embed arbitrary Monad this way. But this is ugly. Because:
1. We use two-level do. One applicative and one monadic
2. We need to prepend "fromEither" before each parser, in which we plan to fail with error messages.

So, I think arrow parsing will be more natural

==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

From han.joosten.han at gmail.com  Sat Jun 12 10:49:47 2021
From: han.joosten.han at gmail.com (Han Joosten)
Date: Sat, 12 Jun 2021 12:49:47 +0200
Subject: [Haskell-cafe] Need advise with using Quickcheck
In-Reply-To: <290de44c-96d8-096a-8504-5a300b42a1cb@gmail.com>
References: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>
 <290de44c-96d8-096a-8504-5a300b42a1cb@gmail.com>
Message-ID: <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>

Thanks for this respons, Rubén. I might not have explained what I am
looking for very well.
I already have
instance Arbitrary Foo
That is not the problem. The problem is, that when a counterexample is
found, it is dumped to the output with the `show` function. I would like to
be able to use another function for that, say show'. In order to do so, I
need to obtain the counterexample itself in some way, so I can use it to
generate a useful message after the tests are done.

Op vr 11 jun. 2021 om 23:31 schreef Ruben Astudillo <ruben.astud at gmail.com>:

> Hello Han
>
> On 11-06-21 17:16, Han Joosten wrote:
> > [..]
> > *parseFoo :: Text -> Guarded Foo*
> > *prettyFoo :: Foo -> Text*
> >
> > The idea is that for all foo :: Foo, the following holds:
> >     *parseFoo . prettyFoo $ foo*  should be equal to  *Checked foo []*
> >
> > Now, if there is a counterexample, I would like to see prettyFoo foo as
> > output, folowed by the show of the Errors part.
>
> It seems you know what property should hold for `parseFoo` and `prettyFoo`.
> Per the QuickCheck manual [1] this could be written as
>
>     import Test.QuickCheck
>
>     propOnAllFooText :: Property
>     propOnAllFooText = forAll (arbitrary :: Gen Foo) $ \exFoo ->
>         parseFoo (prettyFoo exFoo) == Checked exFoo []
>
> What you are missing is a way to generate the test cases (the `arbitrary'
> generator above). You need a way to declare this instance
>
>     instance Arbitrary Foo where
>         -- arbitrary :: Gen Foo
>         arbitrary = <something>
>
> You can see example on how to define it on the manual [1]. Good luck.
>
> [1]: http://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html
>
> --
> -- Rubén
> -- pgp: 4EE9 28F7 932E F4AD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210612/dcc0818c/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sat Jun 12 10:57:28 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 12 Jun 2021 11:57:28 +0100
Subject: [Haskell-cafe] Need advise with using Quickcheck
In-Reply-To: <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>
References: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>
 <290de44c-96d8-096a-8504-5a300b42a1cb@gmail.com>
 <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>
Message-ID: <20210612105728.GA21348@cloudinit-builder>

You say you have another function show' :: Foo -> String.  Then how
about defining

newtype AnotherFoo = AnotherFoo Foo

instance Show AnotherFoo where
    show (AnotherFoo foo) = show' food

instance Arbitrary AnotherFoo where
    arbitrary = AnotherFoo <$> arbitrary

etc.?

On Sat, Jun 12, 2021 at 12:49:47PM +0200, Han Joosten wrote:
> Thanks for this respons, Rubén. I might not have explained what I am
> looking for very well.
> I already have
> instance Arbitrary Foo
> That is not the problem. The problem is, that when a counterexample is
> found, it is dumped to the output with the `show` function. I would like to
> be able to use another function for that, say show'. In order to do so, I
> need to obtain the counterexample itself in some way, so I can use it to
> generate a useful message after the tests are done.
> 
> Op vr 11 jun. 2021 om 23:31 schreef Ruben Astudillo <ruben.astud at gmail.com>:
> 
> > Hello Han
> >
> > On 11-06-21 17:16, Han Joosten wrote:
> > > [..]
> > > *parseFoo :: Text -> Guarded Foo*
> > > *prettyFoo :: Foo -> Text*
> > >
> > > The idea is that for all foo :: Foo, the following holds:
> > >     *parseFoo . prettyFoo $ foo*  should be equal to  *Checked foo []*
> > >
> > > Now, if there is a counterexample, I would like to see prettyFoo foo as
> > > output, folowed by the show of the Errors part.
> >
> > It seems you know what property should hold for `parseFoo` and `prettyFoo`.
> > Per the QuickCheck manual [1] this could be written as
> >
> >     import Test.QuickCheck
> >
> >     propOnAllFooText :: Property
> >     propOnAllFooText = forAll (arbitrary :: Gen Foo) $ \exFoo ->
> >         parseFoo (prettyFoo exFoo) == Checked exFoo []
> >
> > What you are missing is a way to generate the test cases (the `arbitrary'
> > generator above). You need a way to declare this instance
> >
> >     instance Arbitrary Foo where
> >         -- arbitrary :: Gen Foo
> >         arbitrary = <something>
> >
> > You can see example on how to define it on the manual [1]. Good luck.
> >
> > [1]: http://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html
> >
> > --
> > -- Rubén
> > -- pgp: 4EE9 28F7 932E F4AD

From coot at coot.me  Sat Jun 12 11:00:43 2021
From: coot at coot.me (coot at coot.me)
Date: Sat, 12 Jun 2021 11:00:43 +0000
Subject: [Haskell-cafe] Need advise with using Quickcheck
In-Reply-To: <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>
References: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>
 <290de44c-96d8-096a-8504-5a300b42a1cb@gmail.com>
 <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>
Message-ID: <Y2hnIPCqHKaLbw5HTYQlykscSYjr7NKoi0QS1hnxEtd9gCOoc3h6IAxeVH0UCc9S7mcb5o1rrg0jWmoVNIiMN--MHbtX46yeSgJ6_YSjnoA=@coot.me>

I think you're looking for something like this:

```

prop_parser :: Foo -> Property

prop_parser foo  =

   case parserFoo pretty of

      Checked foo' [] | foo == foo' -> property True

      a  -> counterexample (show a ++ "\n" ++ show pretty) False

  where

    pretty = prettyFoo foo

```

Sent with ProtonMail Secure Email.

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

On Saturday, June 12th, 2021 at 12:49, Han Joosten <han.joosten.han at gmail.com> wrote:

> Thanks for this respons, Rubén. I might not have explained what I am looking for very well. I already have instance Arbitrary Foo That is not the problem. The problem is, that when a counterexample is found, it is dumped to the output with the `show` function. I would like to be able to use another function for that, say show'. In order to do so, I need to obtain the counterexample itself in some way, so I can use it to generate a useful message after the tests are done. 
> 

> Op vr 11 jun. 2021 om 23:31 schreef Ruben Astudillo <ruben.astud at gmail.com>:
> 

> > Hello Han
> > 

> > On 11-06-21 17:16, Han Joosten wrote:
> > 

> > > [..]
> > 

> > > *parseFoo :: Text -> Guarded Foo*
> > 

> > > *prettyFoo :: Foo -> Text*
> > 

> > >
> > 

> > > The idea is that for all foo :: Foo, the following holds:
> > 

> > >     *parseFoo . prettyFoo $ foo*  should be equal to  *Checked foo []*
> > 

> > >
> > 

> > > Now, if there is a counterexample, I would like to see prettyFoo foo as
> > 

> > > output, folowed by the show of the Errors part.
> > 

> > It seems you know what property should hold for `parseFoo` and `prettyFoo`.
> > 

> > Per the QuickCheck manual [1] this could be written as
> > 

> >     import Test.QuickCheck
> > 

> >     propOnAllFooText :: Property
> > 

> >     propOnAllFooText = forAll (arbitrary :: Gen Foo) $ \exFoo ->
> > 

> >         parseFoo (prettyFoo exFoo) == Checked exFoo []
> > 

> > What you are missing is a way to generate the test cases (the `arbitrary'
> > 

> > generator above). You need a way to declare this instance
> > 

> >     instance Arbitrary Foo where
> > 

> >         -- arbitrary :: Gen Foo
> > 

> >         arbitrary = <something>
> > 

> > You can see example on how to define it on the manual [1]. Good luck.
> > 

> > [1]: http://www.cse.chalmers.se/~rjmh/QuickCheck/manual.html
> > 

> > --
> > 

> > -- Rubén
> > 

> > -- pgp: 4EE9 28F7 932E F4AD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210612/23f80213/attachment.html>
-------------- 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/20210612/23f80213/attachment.sig>

From lemming at henning-thielemann.de  Sat Jun 12 11:27:57 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 12 Jun 2021 13:27:57 +0200 (CEST)
Subject: [Haskell-cafe] Need advise with using Quickcheck
In-Reply-To: <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>
References: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>
 <290de44c-96d8-096a-8504-5a300b42a1cb@gmail.com>
 <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>
Message-ID: <59efd245-f689-1478-86f8-8e379a613ba3@henning-thielemann.de>


On Sat, 12 Jun 2021, Han Joosten wrote:

> Thanks for this respons, Rubén. I might not have explained what I am looking for very well. I already have 
> instance Arbitrary Foo 
> That is not the problem. The problem is, that when a counterexample is found, it is dumped to the output with the `show` function.
> I would like to be able to use another function for that, say show'. In order to do so, I need to obtain the counterexample itself
> in some way, so I can use it to generate a useful message after the tests are done. 

https://hackage.haskell.org/package/QuickCheck-2.14.2/docs/Test-QuickCheck.html#v:forAllShow

From m at jaspervdj.be  Sat Jun 12 11:42:12 2021
From: m at jaspervdj.be (Jasper Van der Jeugt)
Date: Sat, 12 Jun 2021 13:42:12 +0200
Subject: [Haskell-cafe] ZuriHac 2021 is happening in a week!
Message-ID: <20210612114212.GA4933@taiyaki>

Hey folks,

This is a final reminder that ZuriHac is taking place next weekend,
Friday 18 June - Sunday 20 June 2021.

Here are a couple of things to know:

 -  You can register and join the Discord server through the
    following link: https://zureg.zfoh.ch/register/
 -  There will be the traditional pre-event socializing on Thursday,
    starting at
    19:00 CEST.
 -  We finalised the schedule, and there have been a couple of really
    cool additions.  You can seee the calendar at
    https://zfoh.ch/zurihac2021/#schedule

If you submitted a project, please ping us anytime on Discord in the
#helpdesk channel, and we'll set up text and video channels for you.

Happy hacking!
The Zurich Friends of Haskell - https://zfoh.ch/

From cdsmith at gmail.com  Sat Jun 12 11:57:58 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Sat, 12 Jun 2021 07:57:58 -0400
Subject: [Haskell-cafe] Pearl! I just proved theorem about impossibility
 of monad transformer for parsing with (1) unbiased choice and (2) ambiguity
 checking before running embedded monadic action (also,
 I THREAT I will create another parsing lib)
In-Reply-To: <1623457456.570972111@f163.i.mail.ru>
References: <1623449910.725986714@f337.i.mail.ru>
 <CAPq5PvJnAQntH0C_QE=cJOaBni6PDd5sBbUg+T69pwkUmT87Gw@mail.gmail.com>
 <1623457456.570972111@f163.i.mail.ru>
Message-ID: <CAPq5PvJn8dEhqL68NLvjS8qHSz3Lz6mO3kOjP-EzgNKH7t9Esw@mail.gmail.com>

On Fri, Jun 11, 2021 at 8:24 PM Askar Safin <safinaskar at mail.ru> wrote:

> So, we need this function instead:
>
> fromEither :: Parser (Either String a) -> Parser a

Now we can write this:
> -----
> q :: Parser Int
> q = fromEither $ do { -- applicative do
>   char '(';
>   a <- p;
>   char '/';
>   b <- p;
>   char ')';
>   pure $ do { -- normal monadic do
>     when (b == 0) $ Left "division by zero";
>     return $ a / b;
>   };
> }
> ------
> Yay! Now everything works with Applicative. Moreover, it seems we can
> embed arbitrary Monad this way. But this is ugly. Because:
> 1. We use two-level do. One applicative and one monadic
> 2. We need to prepend "fromEither" before each parser, in which we plan to
> fail with error messages.
>

Indeed.  You can see this as a clear expression of the two-phase nature of
the problem at hand.  You want monadic effects (such as Either String) to
be executed for type checking, but not during parsing, so that you can
check for an ambiguous parse prior to performing type checking.  Then you
must have a separation between non-determinism in parsing (the Parser
functor) and type checking failures (the nested Either monad).  This
appears in your types and code, by saying that a type checking failure
counts as a successful parse, whose associated value is an error from the
type checker.

So, I think arrow parsing will be more natural
>

That's an interesting hypothesis.  I'm not familiar with any arrow-based
parsing libraries, so if you try and find a better way to express this
there, I hope you'll share your findings with us.

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

From han.joosten.han at gmail.com  Sat Jun 12 21:53:50 2021
From: han.joosten.han at gmail.com (Han Joosten)
Date: Sat, 12 Jun 2021 23:53:50 +0200
Subject: [Haskell-cafe] Need advise with using Quickcheck
In-Reply-To: <59efd245-f689-1478-86f8-8e379a613ba3@henning-thielemann.de>
References: <CAKzCsfhLuvfj9Hp=ekT_NH45pZnVokgEcqVkC9AEBQZtB15G-Q@mail.gmail.com>
 <290de44c-96d8-096a-8504-5a300b42a1cb@gmail.com>
 <CAKzCsfjT0VnSBdsWT6qgAeTBY6SXiv0EmkXFcWF4ViYT98Tdbg@mail.gmail.com>
 <59efd245-f689-1478-86f8-8e379a613ba3@henning-thielemann.de>
Message-ID: <CAKzCsfgkNoEepTfd99CWxg2rbWhofXNgb_ktWMYDYu_n6qXT7w@mail.gmail.com>

Thanks all for the responses. I managed to put them all together and I [got
it all to work](
https://github.com/AmpersandTarski/Ampersand/blob/cefbc08ad8fb3152ce1a55dce5f6334cfc732d46/src/Ampersand/Test/Parser/QuickChecks.hs
).

Cheers,
Han.

Op za 12 jun. 2021 om 13:28 schreef Henning Thielemann <
lemming at henning-thielemann.de>:

>
> On Sat, 12 Jun 2021, Han Joosten wrote:
>
> > Thanks for this respons, Rubén. I might not have explained what I am
> looking for very well. I already have
> > instance Arbitrary Foo
> > That is not the problem. The problem is, that when a counterexample is
> found, it is dumped to the output with the `show` function.
> > I would like to be able to use another function for that, say show'. In
> order to do so, I need to obtain the counterexample itself
> > in some way, so I can use it to generate a useful message after the
> tests are done.
>
>
> https://hackage.haskell.org/package/QuickCheck-2.14.2/docs/Test-QuickCheck.html#v:forAllShow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210612/d561acc6/attachment.html>

From hasufell at hasufell.de  Sun Jun 13 21:18:42 2021
From: hasufell at hasufell.de (Julian Ospald)
Date: Sun, 13 Jun 2021 23:18:42 +0200
Subject: [Haskell-cafe] ccall vs capi
Message-ID: <20210613211842.googmnmlr4edyi63@localhost.localdomain>

Hi,

recently during a ghcup release, we stumbled over yet another `ccall`
bug on Darwin: https://github.com/biegunka/terminal-size/pull/16

This took Ben some time to debug (thanks again) and it isn't always
clear with such
bugs whether something is wrong with GHC/RTS/GC or a library, so this
can be a time-sink.

It's also not the first time it happened:
* https://github.com/haskell/unix/pull/110#issuecomment-613384845
* https://github.com/hasufell/hpath/commit/74d686547e67da3eeae327c84c63f83833205890

I can't say that I fully understood what the exact difference here is
and why it seems to matter much more on Darwin than on other systems. So
I think it would be helpful if we could come up with:

1. a clear description of the differences of ccall vs capi
2. an explanation why ccall can lead to terrible bugs on darwin
3. a guideline of when using one over the other is appropriate

Not everyone deals with ffi on a regular basis, so I hope the experts
here can shed some light!

Cheers,
Julian

From allbery.b at gmail.com  Sun Jun 13 21:47:10 2021
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 13 Jun 2021 17:47:10 -0400
Subject: [Haskell-cafe] ccall vs capi
In-Reply-To: <20210613211842.googmnmlr4edyi63@localhost.localdomain>
References: <20210613211842.googmnmlr4edyi63@localhost.localdomain>
Message-ID: <CAKFCL4W_U_zrxKcptYCjmYv6OyKCzfXZ3oqbpG615JiMDrBZ_Q@mail.gmail.com>

capi uses the C compiler to make the call, requiring ghc to write out and
compile a C stub file for each import. This guarantees C compatibility and
also works with cpp-defined symbols.

ccall attempts to emulate what the C compiler does with generated assembly
language, but may get it wrong on Darwin; I recall Moritz Angermann saying
someone would have to dump out the generated assembly from both cases to
see what's different and what needs to change for ccall to work on Darwin.

Possible differences include not zeroing the upper parts of registers with
32-bit values in them and not treating other registers properly (for
example, getting caller-saved registers wrong). It's also conceivable that
there's a cpp macro involved normally and there's a hidden bug in a
fallback libSystem version of a function. Someone will have to examine the
generated assembly as above to see what's actually wrong.

On Sun, Jun 13, 2021 at 5:21 PM Julian Ospald <hasufell at hasufell.de> wrote:

> Hi,
>
> recently during a ghcup release, we stumbled over yet another `ccall`
> bug on Darwin: https://github.com/biegunka/terminal-size/pull/16
>
> This took Ben some time to debug (thanks again) and it isn't always
> clear with such
> bugs whether something is wrong with GHC/RTS/GC or a library, so this
> can be a time-sink.
>
> It's also not the first time it happened:
> * https://github.com/haskell/unix/pull/110#issuecomment-613384845
> *
> https://github.com/hasufell/hpath/commit/74d686547e67da3eeae327c84c63f83833205890
>
> I can't say that I fully understood what the exact difference here is
> and why it seems to matter much more on Darwin than on other systems. So
> I think it would be helpful if we could come up with:
>
> 1. a clear description of the differences of ccall vs capi
> 2. an explanation why ccall can lead to terrible bugs on darwin
> 3. a guideline of when using one over the other is appropriate
>
> Not everyone deals with ffi on a regular basis, so I hope the experts
> here can shed some light!
>
> Cheers,
> Julian
> _______________________________________________
> 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.



-- 
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/20210613/032f7031/attachment.html>

From oleg.grenrus at iki.fi  Mon Jun 14 07:44:10 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Mon, 14 Jun 2021 10:44:10 +0300
Subject: [Haskell-cafe] ccall vs capi
In-Reply-To: <CAKFCL4W_U_zrxKcptYCjmYv6OyKCzfXZ3oqbpG615JiMDrBZ_Q@mail.gmail.com>
References: <20210613211842.googmnmlr4edyi63@localhost.localdomain>
 <CAKFCL4W_U_zrxKcptYCjmYv6OyKCzfXZ3oqbpG615JiMDrBZ_Q@mail.gmail.com>
Message-ID: <f04622db-d08f-409b-9b67-981bb09aebc1@iki.fi>

https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/ffi.html?highlight=capiffi#extension-CApiFFI

I see very little reason to not use CApiFFI if your project doesn't need
to work on old GHCs.

It also checks that foreign imports have compatible types - very nice
feature.

- Oleg

On 14.6.2021 0.47, Brandon Allbery wrote:
> capi uses the C compiler to make the call, requiring ghc to write out
> and compile a C stub file for each import. This guarantees C
> compatibility and also works with cpp-defined symbols.
>
> ccall attempts to emulate what the C compiler does with generated
> assembly language, but may get it wrong on Darwin; I recall Moritz
> Angermann saying someone would have to dump out the generated assembly
> from both cases to see what's different and what needs to change for
> ccall to work on Darwin.
>
> Possible differences include not zeroing the upper parts of registers
> with 32-bit values in them and not treating other registers properly
> (for example, getting caller-saved registers wrong). It's also
> conceivable that there's a cpp macro involved normally and there's a
> hidden bug in a fallback libSystem version of a function. Someone will
> have to examine the generated assembly as above to see what's actually
> wrong.
>
> On Sun, Jun 13, 2021 at 5:21 PM Julian Ospald <hasufell at hasufell.de
> <mailto:hasufell at hasufell.de>> wrote:
>
>     Hi,
>
>     recently during a ghcup release, we stumbled over yet another `ccall`
>     bug on Darwin: https://github.com/biegunka/terminal-size/pull/16
>
>     This took Ben some time to debug (thanks again) and it isn't always
>     clear with such
>     bugs whether something is wrong with GHC/RTS/GC or a library, so this
>     can be a time-sink.
>
>     It's also not the first time it happened:
>     * https://github.com/haskell/unix/pull/110#issuecomment-613384845
>     *
>     https://github.com/hasufell/hpath/commit/74d686547e67da3eeae327c84c63f83833205890
>
>     I can't say that I fully understood what the exact difference here is
>     and why it seems to matter much more on Darwin than on other
>     systems. So
>     I think it would be helpful if we could come up with:
>
>     1. a clear description of the differences of ccall vs capi
>     2. an explanation why ccall can lead to terrible bugs on darwin
>     3. a guideline of when using one over the other is appropriate
>
>     Not everyone deals with ffi on a regular basis, so I hope the experts
>     here can shed some light!
>
>     Cheers,
>     Julian
>     _______________________________________________
>     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.
>
>
>
> -- 
> brandon s allbery kf8nh
> allbery.b at gmail.com <mailto:allbery.b at gmail.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 ifl21.publicity at gmail.com  Tue Jun 15 15:29:08 2021
From: ifl21.publicity at gmail.com (Pieter Koopman)
Date: Tue, 15 Jun 2021 17:29:08 +0200
Subject: [Haskell-cafe] IFL2021 second call for papers
Message-ID: <CAGtcRvCkmFCPYyD6VYZiR9b8iu-NHBSykaXpFKWYsoRjYpM-+A@mail.gmail.com>

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

                                IFL 2021

    33rd Symposium on Implementation and Application of Functional Languages


                             venue: online
                          1 - 3 September 2021

                         https://ifl21.cs.ru.nl
<https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpmlYX_0BVua0V5yyanFkJBhfIIDW1X2vaVQE-123424015&key=YAMMID-70947561&link=https%3A%2F%2Fifl21.cs.ru.nl>

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

News


   - Paper submission is now open:
   https://easychair.org/conferences/?conf=ifl21
   <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpmlYX_0BVua0V5yyanFkJBhfIIDW1X2vaVQE-123424015&key=YAMMID-70947561&link=https%3A%2F%2Feasychair.org%2Fconferences%2F%3Fconf%3Difl21>
   .
   - Invited speakers are added: Stephanie Weirich and John Hughes
   - Sponsor added:  Facebook Research
   <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpmlYX_0BVua0V5yyanFkJBhfIIDW1X2vaVQE-123424015&key=YAMMID-70947561&link=http%3A%2F%2Fwww.research.fb.com%2F>



Scope

The goal of the IFL symposia is to bring together researchers actively
engaged
in the implementation and application of functional and function-based
programming languages. IFL 2021 will be a venue for researchers to present
and
discuss new ideas and concepts, work in progress, and publication-ripe
results
related to the implementation and application of functional languages and
function-based programming.


Industrial track and topics of interest

This year's edition of IFL explicitly solicits original work concerning
*applications*
of functional programming in industry and academia. These contributions
will be reviewed by experts with an industrial background.

Topics of interest to IFL include, but are not limited to:

* language concepts
* type systems, type checking, type inferencing
* compilation techniques
* staged compilation
* run-time function specialisation
* run-time code generation
* partial evaluation
* (abstract) interpretation
* meta-programming
* generic programming
* automatic program generation
* array processing
* concurrent/parallel programming
* concurrent/parallel program execution
* embedded systems
* web applications
* (embedded) domain-specific languages
* security
* novel memory management techniques
* run-time profiling performance measurements
* debugging and tracing
* testing and proofing
* virtual/abstract machine architectures
* validation, verification of functional programs
* tools and programming techniques
* applications of functional programming in the industry, including
** functional programming techniques for large applications
** successes of the application functional programming
** challenges for functional programming encountered
** any topic related to the application of functional programming that is
interesting for the IFL community


Post-symposium peer-review

Following IFL tradition, IFL 2021 will use a post-symposium review process
to
produce the formal proceedings.

Before the symposium authors submit draft papers. These draft papers will
be
screened by the program chairs to make sure that they are within the scope
of
IFL. The draft papers will be made available to all participants at the
symposium.
Each draft paper is presented by one of the authors at the symposium.

After the symposium every presenter is invited to submit a full paper,
incorporating feedback from discussions at the symposium. Work submitted to
IFL
may not be simultaneously submitted to other venues; submissions must
adhere to ACM SIGPLAN's republication policy. The program committee will
evaluate these submissions according to their correctness, novelty,
originality,
relevance, significance, and clarity, and will thereby determine whether
the
paper is accepted or rejected for the formal proceedings. We plan to
publish
these proceedings in the International Conference Proceedings Series of the
ACM Digital Library, as in previous years. Moreover, the proceedings will
also
be made publicly available as open access.


Important dates

Submission deadline of draft papers:           17 August 2021
Notification of acceptance for presentation:   19 August 2021
Registration deadline:                         30 August 2021
IFL Symposium:                                 1-3 September 2021
Submission of papers for proceedings:          6 December 2021
Notification of acceptance:                    3 February 2022
Camera-ready version:                          15 March 2022


Submission details

All contributions must be written in English. Papers must use the ACM two
columns conference format, which can be found at:

              http://www.acm.org/publications/proceedings-template
<https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpmlYX_0BVua0V5yyanFkJBhfIIDW1X2vaVQE-123424015&key=YAMMID-70947561&link=http%3A%2F%2Fwww.acm.org%2Fpublications%2Fproceedings-template>

The submission Web page for IFL21 is
https://easychair.org/conferences/?conf=ifl21
<https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpmlYX_0BVua0V5yyanFkJBhfIIDW1X2vaVQE-123424015&key=YAMMID-70947561&link=https%3A%2F%2Feasychair.org%2Fconferences%2F%3Fconf%3Difl21>
.

Peter Landin Prize

The Peter Landin Prize is awarded to the best paper presented at the
symposium every year. The honoured article is selected by the program
committee
based on the submissions received for the formal review process. The prize
carries a cash award equivalent to 150 Euros.

Organisation

IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The
Netherlands

IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands

PC:
Peter Achten (co-chair)   - Radboud University, Netherlands
Thomas van Binsbergen     - University of Amsterdam, Netherlands
Edwin Brady               - University of St. Andrews, Scotland
Laura Castro              - University of A Coruña, Spain
Youyou Cong               - Tokyo Institute of Technology, Japan
Olaf Chitil               - University of Kent, England
Andy Gill                 - University of Kansas, USA
Clemens Grelck            - University of Amsterdam, Netherlands
John Hughes               - Chalmers University, Sweden
Pieter Koopman (co-chair) - Radboud University, Netherlands
Cynthia Kop               - Radboud University, Netherlands
Jay McCarthey             - University of Massachussetts Lowell, USA
Neil Mitchell             - Facebook, England
Jan De Muijnck-Hughes     - Glasgow University, Scotland
Keiko Nakata              - SAP Innovation Center Potsdam, Germany
Jurriën Stutterheim       - Standard Chartered, Singapore
Simon Thompson            - University of Kent, England
Melinda Tóth              - Eötvos Loránd University, Hungary
Phil Trinder              - Glasgow University, Scotland
Meng Wang                 - University of Bristol, England
Viktória Zsók             - Eötvos Loránd University, Hungary


Virtual symposium

Because of the Covid-19 pandemic, this year IFL 2021 will be an online
event,
consisting of paper presentations, discussions and virtual social
gatherings.
Registered participants can take part from anywhere in the world.


[image: beacon]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210615/c82b3468/attachment.html>

From lysxia at gmail.com  Wed Jun 16 06:45:22 2021
From: lysxia at gmail.com (Li-yao Xia)
Date: Wed, 16 Jun 2021 02:45:22 -0400
Subject: [Haskell-cafe] Haskell grammar ambiguity
Message-ID: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>

Hello Café,

With the BlockArguments proposal[1], the formal grammar of Haskell has 
become much nicer, with all of the "boring" expression constructs (i.e., 
other than function or operator application) under one non-terminal:

https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-block-arguments.rst#proposed-change-specification

Its one flaw, inherited from Haskell2010, is ambiguity. I wonder whether 
that ambiguity is necessary.

Currently, a meta-rule fixes that flaw:

 > The grammar is ambiguous regarding the extent of lambda abstractions, 
let expressions, and conditionals. The ambiguity is resolved by the 
meta-rule that each of these constructs extends as far to the right as 
possible.

That is quite informal, so interpreting it takes a bit of thinking.

1. Does the rule make sense? That seems quite likely, but at the same 
time it seems to depend on some good behavior of the grammar. Like, 
aren't there grammars where such an "extend far to the right" meta-rule 
would itself be ambiguous? What's the key criterion for that meta-rule 
to make sense?

2. How to implement this rule? It might be obvious, with shift-reduce 
parsing ("shift always"). It also seems feasible with Earley parsing 
(the only other technique I am familiar with). But, either way, you have 
to dig into the internals of the chosen parsing method to resolve 
ambiguities.

Instead, what if the grammar were unambiguous to start with? I share an 
attempt at the bottom of this email. Which brings me to my main two 
questions:

3. Is this grammar unambiguous?

4. Does it match the meta-rule?

I also can't help but think about how it might look like in a 
hypothetical language report.

5. What are the pros and cons of using a ambiguous or unambiguous 
grammar for a programming language standard?

A plausible starting point is thus:

- An ambiguous grammar may be more readable (since there are strictly 
more choices available), especially if you care more about the AST than 
the concrete syntax.
- An unambiguous grammar is easier to implement: just throw it into an 
Earley parser.

This unambiguous grammar can somewhat easily be "flattened" into the 
ambiguous one from the report. That challenges the assumption that 
ambiguous grammars are generally more readable. In fact, the current 
ambiguous grammar already exposes other concrete syntax concerns (via 
the distinction between exp, infixexp, fexp, and aexp). In contrast, 
turning an ambiguous grammar into an unambiguous one takes a bit of 
effort (when it's possible at all). So if there are ambiguities worth 
keeping, is there a clear threshold?

One other possible issue is that non-ambiguity is a fragile property, so 
extending the grammar requires extra care. Furthermore, even if the 
updated grammar is unambiguous, it might not be obvious that it still 
encodes the intent behind the meta-rule. That meta-rule may still be 
worth clarifying as a requirement for language extensions at least.

Haskell syntax can be pretty, but the process behind it is a wee bit 
complicated.

Regards,
Li-yao

---

# Unambiguous grammar for expressions (some rules omitted for brevity)

# Compared to Haskell2010+BlockArguments, we move the rules for if, 
lambdas and lets into their own non-terminal rexp, and add four extra 
rules in exp, ensuring that rexp occurs only to the right end of 
function/operator applications.

# Possibly simplifiable more

# * and + represent repetition.

# Expressions.
exp ->
     iexp "::" type
   | iexp
   # EXTRA RULES with rexp
   | rexp
   | iexp qop rexp
   | iexp qop frexp
   | frexp

# EXTRA SYMBOL rexp
# Expressions with right-recursive syntax.
rexp ->
     "if" exp "then" exp "else" exp
   | "\\" var "->" exp
   | "let" decls "in" exp

# EXTRA (AUXILIARY) SYMBOL frexp
# Function application with a trailing block argument.
frexp -> aexp aexp* rexp

# Infix expression (was infixexp). OLD
iexp -> fexp (qop fexp)*

# Optional function applications. OLD
fexp -> aexp
   | aexp aexp+

# Atomic expressions. OLD with removed if/lambda/let
aexp -> qvar
   | "[" "]"
   | "(" ")"
   | qcon
   | "(" exp ")"
   | "do" "{" stmts "}"
   | "case" exp "of" "{" alts "}"

From svenpanne at gmail.com  Wed Jun 16 07:48:06 2021
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 16 Jun 2021 09:48:06 +0200
Subject: [Haskell-cafe] Haskell grammar ambiguity
In-Reply-To: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
Message-ID: <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>

Am Mi., 16. Juni 2021 um 08:47 Uhr schrieb Li-yao Xia <lysxia at gmail.com>:

> [...] - An ambiguous grammar may be more readable (since there are
> strictly
> more choices available), especially if you care more about the AST than
> the concrete syntax. [...]
>

IMHO it is exactly the other way around: I consider ambiguous grammars a
serious usability bug. Even if you hack around the ambiguities via meta
rules and/or technical tricks like "prefer shift" in (LA)LR parsers, you as
a poor human have to do the disambiguation for yourself. This makes it
*harder* to read code following the grammar, not easier. The BlockArguments
proposal introduced lots of additional ambiguities, and that's the reason
why I'm still opposed to it. I'm too lazy to dig out the old discussions,
but I gave a few examples where it was *highly* unclear/confusing what the
right parse should be with BlockArguments. This has been totally ignored,
and that ship has sailed...

In general, I consider it a very bad idea to give more and more strings a
meaning as a program: Some redundancy, like keywords and/or punctuation, is
highly useful as a human reader. Remember the old saying "A good language
should not make it easy to write correct programs, it should make it hard
to write incorrect ones", and BlockArguments was IMHO a step into the wrong
direction.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210616/ec676938/attachment.html>

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Wed Jun 16 09:00:41 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 16 Jun 2021 10:00:41 +0100
Subject: [Haskell-cafe] Haskell grammar ambiguity
In-Reply-To: <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
 <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>
Message-ID: <20210616090041.GE13413@cloudinit-builder>

On Wed, Jun 16, 2021 at 09:48:06AM +0200, Sven Panne wrote:
> Am Mi., 16. Juni 2021 um 08:47 Uhr schrieb Li-yao Xia <lysxia at gmail.com>:
> > [...] - An ambiguous grammar may be more readable (since there are
> > strictly
> > more choices available), especially if you care more about the AST than
> > the concrete syntax. [...]
> 
> IMHO it is exactly the other way around: I consider ambiguous
> grammars a serious usability bug. [...] The BlockArguments proposal
> introduced lots of additional ambiguities, and that's the reason why
> I'm still opposed to it.
>
> [...]
>
> In general, I consider it a very bad idea to give more and more strings a
> meaning as a program: Some redundancy, like keywords and/or punctuation, is
> highly useful as a human reader. Remember the old saying "A good language
> should not make it easy to write correct programs, it should make it hard
> to write incorrect ones", and BlockArguments was IMHO a step into the wrong
> direction.

Entirely agreed.  The additional difficulty in parsing means that
BlockArguments provides *negative* value to me, even if I don't enable
it:

http://h2.jaguarpaw.co.uk/posts/unhelpful-ghc-error-messages/

Tom

From lysxia at gmail.com  Wed Jun 16 13:07:40 2021
From: lysxia at gmail.com (Li-yao Xia)
Date: Wed, 16 Jun 2021 09:07:40 -0400
Subject: [Haskell-cafe] Haskell grammar ambiguity
In-Reply-To: <20210616090041.GE13413@cloudinit-builder>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
 <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>
 <20210616090041.GE13413@cloudinit-builder>
Message-ID: <e03933d6-e64c-1d5f-f160-d5371146fcc1@gmail.com>

On 6/16/2021 5:00 AM, Tom Ellis wrote:
 > [...]
 >
 > Entirely agreed.  The additional difficulty in parsing means that
 > BlockArguments provides *negative* value to me, even if I don't enable
 > it:
 >
 > http://h2.jaguarpaw.co.uk/posts/unhelpful-ghc-error-messages/
 >

Ouch, that error message is terrible.

But isn't that an argument against BlockArguments more than against 
ambiguity? By that I mean that the current ambiguities for function 
applications were already present in a similar form for infix 
expressions in Haskell2010 (replacing a space with an operator).

In a parallel world, the Haskell2010 grammar could be unambiguous, 
BlockArguments would keep the extended grammar unambiguous. But since 
the intended meaning is the same, GHC would be the same as in this 
world, and you would still be having the same issues with BlockArguments.


> On Wed, Jun 16, 2021 at 09:48:06AM +0200, Sven Panne wrote:
>> Am Mi., 16. Juni 2021 um 08:47 Uhr schrieb Li-yao Xia <lysxia at gmail.com>:
>>> [...] - An ambiguous grammar may be more readable (since there are
>>> strictly
>>> more choices available), especially if you care more about the AST than
>>> the concrete syntax. [...]
>>
>> IMHO it is exactly the other way around: I consider ambiguous
>> grammars a serious usability bug. [...] The BlockArguments proposal
>> introduced lots of additional ambiguities, and that's the reason why
>> I'm still opposed to it.
>>
>> [...]
>>
>> In general, I consider it a very bad idea to give more and more strings a
>> meaning as a program: Some redundancy, like keywords and/or punctuation, is
>> highly useful as a human reader. Remember the old saying "A good language
>> should not make it easy to write correct programs, it should make it hard
>> to write incorrect ones", and BlockArguments was IMHO a step into the wrong
>> direction.
> 

> 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.
> 

From safinaskar at mail.ru  Wed Jun 16 14:22:01 2021
From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=)
Date: Wed, 16 Jun 2021 17:22:01 +0300
Subject: [Haskell-cafe] =?utf-8?q?Haskell_grammar_ambiguity?=
In-Reply-To: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
Message-ID: <1623853321.852471864@f395.i.mail.ru>

> 3. Is this grammar unambiguous?
It is unambiguous.

I converted in into happy grammar ( https://www.haskell.org/happy/ ). Here is result: https://paste.debian.net/1201427/ . Then I run "happy" binary on it and got no output. This means that "happy" was able to check that this CFG is element of particular class of grammars (as well as I understand this is LALR(1) class), and thus is unambiguous.

But this result is useless, because I simply assumed that symbols "type", "qvar" and others are unique terminals (I listed them as tokens in happy grammar). This is not true. For example, string "a" can be "type" and in the same time "qvar". So I suggest writing proper happy grammar with unique terminals.

(Also, I converted your grammar to happy's manually, it is possible I did some mistake.)

Some additional notes (with a bit of advertisement).

Checking whether given CFG is ambiguous is in general impossible to do on Turing machine, this is theorem. So none of existing tools will give you answer for any grammar.

Happy checks whether a grammar is element of particular class (as well as I understand, LALR(1)). If it is, happy prints nothing, this means, this is LALR(1) grammar, and thus unambiguous. If not, happy reports conflicts. But this doesn't mean the grammar is ambiguous. It can be ambiguous or unambiguous.

My package http://hackage.haskell.org/package/check-cfg-ambiguity can check grammar, too. It reports given CFG either as certainly ambiguous or as possibly unambiguous. Still I was unable to find grammar, arising from practice, which can fool my package. Setting count of steps as 20 will give you very low probability of mistake. (Again: "probability of mistake" means probability of answer "it is unambiguous" being false, answer "it is ambiguous" is always certainly true.)

Also you can try this package: https://www.brics.dk/grammar/ for checking ambiguity.

I spent lot of time learning various methods of checking ambiguity, feel free to ask me questions. Add me to CC in case i will unsubscribe from this list.

I like your desire to give proper grammar for Haskell. What you want? Fixing Haskell Report? Well, this would be very good, unfortunately Haskell Report process is staled ( https://reasonablypolymorphic.com/blog/haskell202x/ ). Of course, I hope it will resurrect.

Also, I agree that BlockArguments was mistake.

Also, grammar given in Haskell Report 2010 and grammar from ghc source tree are 2 completely different things, see here: https://mail.haskell.org/pipermail/haskell-cafe/2021-April/133847.html

==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

From safinaskar at mail.ru  Wed Jun 16 14:38:37 2021
From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=)
Date: Wed, 16 Jun 2021 17:38:37 +0300
Subject: [Haskell-cafe] =?utf-8?q?Haskell_grammar_ambiguity?=
In-Reply-To: <20210616090041.GE13413@cloudinit-builder>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
 <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>
 <20210616090041.GE13413@cloudinit-builder>
Message-ID: <1623854317.926841178@f436.i.mail.ru>

> Entirely agreed.  The additional difficulty in parsing means that
> BlockArguments provides *negative* value to me, even if I don't enable
> it:
> 
> http://h2.jaguarpaw.co.uk/posts/unhelpful-ghc-error-messages/
I agree. I always use curly braces with "do" and "case", i. e.:
do {
  ...;
  ...;
}

==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

From ietf-dane at dukhovni.org  Wed Jun 16 15:01:01 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 16 Jun 2021 11:01:01 -0400
Subject: [Haskell-cafe] Haskell grammar ambiguity
In-Reply-To: <1623854317.926841178@f436.i.mail.ru>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
 <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>
 <20210616090041.GE13413@cloudinit-builder>
 <1623854317.926841178@f436.i.mail.ru>
Message-ID: <FC72D7D2-395E-4E83-B655-86D21EA0E73C@dukhovni.org>

> On 16 Jun 2021, at 10:38 am, Askar Safin via Haskell-Cafe <haskell-cafe at haskell.org> wrote:
> 
> I agree. I always use curly braces with "do" and "case", i. e.:
> do {
>  ...;
>  ...;
> }

I, on the other hand find, e.g., BlockArguments and ApplicativeDo
to be useful decluttering extensions.  These are not without their
"pockets of support".  Perhaps some of the error messages could be
less optimistic in suggesting "BlockArguments", the user who meant
to use them would typically deduce the forgotten pragma even without
an explicit hint when the hint degrades error quality for others.

The specific error message choices are not inherent to the extension.

-- 
	Viktor.


From svenpanne at gmail.com  Wed Jun 16 15:23:00 2021
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 16 Jun 2021 17:23:00 +0200
Subject: [Haskell-cafe] Haskell grammar ambiguity
In-Reply-To: <FC72D7D2-395E-4E83-B655-86D21EA0E73C@dukhovni.org>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
 <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>
 <20210616090041.GE13413@cloudinit-builder>
 <1623854317.926841178@f436.i.mail.ru>
 <FC72D7D2-395E-4E83-B655-86D21EA0E73C@dukhovni.org>
Message-ID: <CANBN=muOFd42wAVtjX6dH5czSqx9ogr-f13OOqMdvVO2WedUQA@mail.gmail.com>

Am Mi., 16. Juni 2021 um 17:06 Uhr schrieb Viktor Dukhovni <
ietf-dane at dukhovni.org>:

> I, on the other hand find, e.g., BlockArguments and ApplicativeDo
> to be useful decluttering extensions. [...]


Some people call this "decluttering", other people call this "obfuscating"
and/or "reducing readability". ;-) Haskell already had a very lightweight
syntax right from the beginning, making it even lighter transforms it
slowly into https://en.wikipedia.org/wiki/Whitespace_(programming_language).
..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210616/651719e8/attachment.html>

From lysxia at gmail.com  Wed Jun 16 16:04:06 2021
From: lysxia at gmail.com (Li-yao Xia)
Date: Wed, 16 Jun 2021 12:04:06 -0400
Subject: [Haskell-cafe] Haskell grammar ambiguity
In-Reply-To: <1623853321.852471864@f395.i.mail.ru>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
 <1623853321.852471864@f395.i.mail.ru>
Message-ID: <0a12099c-d4f4-af7e-1b09-5e5182976fd7@gmail.com>

Thanks for your great answer, Askar. Using happy to optimistically test 
for ambiguity is a great idea, and I'll be sure to check your other 
references.


 > I like your desire to give proper grammar for Haskell. What you want? 
Fixing Haskell Report? Well, this would be very good, unfortunately 
Haskell Report process is staled ( 
https://reasonablypolymorphic.com/blog/haskell202x/ ). Of course, I hope 
it will resurrect.


Right now I'm trying to understand Haskell's concrete syntax enough to

1. Teach it (with "better parser error messages" as a potential subgoal)
2. Implement it (as a concrete lower bound for the abstract goal of 
"completely understand it")

And right now it seems reading the Haskell2010 report and also 
GHC/Parser.y is not enough. One also has to think hard on top of that. 
This can usually be fixed by producing a better reference document.

Li-yao


On 6/16/2021 10:22 AM, Askar Safin wrote:
>> 3. Is this grammar unambiguous?
> It is unambiguous.
> 
> I converted in into happy grammar ( https://www.haskell.org/happy/ ). Here is result: https://paste.debian.net/1201427/ . Then I run "happy" binary on it and got no output. This means that "happy" was able to check that this CFG is element of particular class of grammars (as well as I understand this is LALR(1) class), and thus is unambiguous.
> 
> But this result is useless, because I simply assumed that symbols "type", "qvar" and others are unique terminals (I listed them as tokens in happy grammar). This is not true. For example, string "a" can be "type" and in the same time "qvar". So I suggest writing proper happy grammar with unique terminals.
> 
> (Also, I converted your grammar to happy's manually, it is possible I did some mistake.)
> 
> Some additional notes (with a bit of advertisement).
> 
> Checking whether given CFG is ambiguous is in general impossible to do on Turing machine, this is theorem. So none of existing tools will give you answer for any grammar.
> 
> Happy checks whether a grammar is element of particular class (as well as I understand, LALR(1)). If it is, happy prints nothing, this means, this is LALR(1) grammar, and thus unambiguous. If not, happy reports conflicts. But this doesn't mean the grammar is ambiguous. It can be ambiguous or unambiguous.
> 
> My package http://hackage.haskell.org/package/check-cfg-ambiguity can check grammar, too. It reports given CFG either as certainly ambiguous or as possibly unambiguous. Still I was unable to find grammar, arising from practice, which can fool my package. Setting count of steps as 20 will give you very low probability of mistake. (Again: "probability of mistake" means probability of answer "it is unambiguous" being false, answer "it is ambiguous" is always certainly true.)
> 
> Also you can try this package: https://www.brics.dk/grammar/ for checking ambiguity.
> 
> I spent lot of time learning various methods of checking ambiguity, feel free to ask me questions. Add me to CC in case i will unsubscribe from this list.
> 
> I like your desire to give proper grammar for Haskell. What you want? Fixing Haskell Report? Well, this would be very good, unfortunately Haskell Report process is staled ( https://reasonablypolymorphic.com/blog/haskell202x/ ). Of course, I hope it will resurrect.
> 
> Also, I agree that BlockArguments was mistake.
> 
> Also, grammar given in Haskell Report 2010 and grammar from ghc source tree are 2 completely different things, see here: https://mail.haskell.org/pipermail/haskell-cafe/2021-April/133847.html
> 
> ==
> Askar Safin
> http://safinaskar.com
> https://sr.ht/~safinaskar
> https://github.com/safinaskar
> 

From evincarofautumn at gmail.com  Wed Jun 16 20:37:48 2021
From: evincarofautumn at gmail.com (Jon Purdy)
Date: Wed, 16 Jun 2021 13:37:48 -0700
Subject: [Haskell-cafe] Fwd:  Haskell grammar ambiguity
In-Reply-To: <CAE3FWBs9q-bfPpCuw+1SiCkGL8wCa2RGpYet3cRHfdxa2ceh2w@mail.gmail.com>
References: <488cf7d6-2314-5695-82c5-7820f17bf1f5@gmail.com>
 <CANBN=msB5N2C-SqgcOYxRBuUjD_B8aPfgzZDRa9oBZb8KmbtOw@mail.gmail.com>
 <CAE3FWBs9q-bfPpCuw+1SiCkGL8wCa2RGpYet3cRHfdxa2ceh2w@mail.gmail.com>
Message-ID: <CAE3FWBudrFz3bcfe5gwNHjUWFB2f1pjr7na6SC-2bN0JVbBFXg@mail.gmail.com>

Email fail, pardon the noise; original message below.

---------- Forwarded message ---------
From: Jon Purdy <evincarofautumn at gmail.com>
Date: Wed, Jun 16, 2021 at 1:35 PM
Subject: Re: [Haskell-cafe] Haskell grammar ambiguity
To: Sven Panne <svenpanne at gmail.com>


On Wed, Jun 16, 2021 at 12:49 AM Sven Panne <svenpanne at gmail.com> wrote:

> I consider ambiguous grammars a serious usability bug.
>

I agree. I always make a point of telling ‘%expect 0’ to Happy. (“More
often than not the grammar you write will have conflicts”? Excuse you!)


> The BlockArguments proposal introduced lots of additional ambiguities, and
> that's the reason why I'm still opposed to it.
>

I consider BlockArguments a fix for a bug in the Haskell grammar, namely, a
redundant production, requiring an unnecessary operator, which causes
confusion for some people coming from other languages. In being fixed,
however, it exposed other serious grammar issues. So I’d be strongly in
favour of fixing those unclear/ambiguous parses by further (incremental)
simplification of the grammar.

It would be very nice if the extent of lambda/if/&c. were unambiguous, so I
think this idea is a step in the right direction. I would also be very
pleased if the layout rule were reformulated as a simpler desugaring step,
from a token stream annotated with source locations to such a stream with
explicit braces and semicolons inserted, rather than being defined in terms
of parse errors and papering over edge cases.

My ideal would be a simple formal grammar (LALR, PEG, or even
operator-precedence) which is machine-validated as unambiguous, with an
implementation written by hand to produce nice contextual error messages,
which is typed to prove that it accepts the same language as the formal
grammar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210616/cf9adeef/attachment.html>

From cdsmith at gmail.com  Thu Jun 17 01:16:42 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Wed, 16 Jun 2021 21:16:42 -0400
Subject: [Haskell-cafe] An emotional retrospective on my Haskell journey so
	far
Message-ID: <CAPq5PvJQgxUPRjRZyMZo2Xud-hq2T_D3eNF7c=chtbfdHswtRQ@mail.gmail.com>

Hi everyone,

I started out writing a blog post about why I chose to become a contributor
to the Haskell Foundation.  It ended up being a bit of a bigger picture
recap of my whole Haskell journey.  I would like to share it with you,
since many of the people here have been really influential to me over the
past 15 years.  Thank you all so much.

Link:
https://cdsmithus.medium.com/why-i-support-the-haskell-foundation-1ac3cda1f82f

Yes, it's Medium, but it isn't part of their soft paywall, so please don't
be afraid to click on it.

Cheers,
Chris Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210616/4d53f232/attachment.html>

From icfp.publicity at googlemail.com  Thu Jun 17 02:41:03 2021
From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt)
Date: Wed, 16 Jun 2021 22:41:03 -0400
Subject: [Haskell-cafe] ICFP 2021 Student Research Competition: Call for
	Submissions
Message-ID: <60cab63f8e9f7_4e48e2941463@homer.mail>

ICFP 2021 Student Research Competition
       Call for Submissions

ICFP invites students to participate in the Student Research
Competition, which will be held virtually alongside the main
conference, in order to present their research and receive
feedback from prominent members of the programming language
research community.

As usual, the SRC consists of three rounds:

* Extended abstract
* Poster session at ICFP 2021
* ICFP presentation

To make the virtual competition fruitful, we will make sure
that every student will have an "invited audience" during the
poster session.  We are also planning to organize a social event
for the students.  Please visit the SRC website for updates.

### Important Dates

Submissions due: 2 July 2021 (Friday)
   https://icfp21src.hotcrp.com
Notification: 16 July 2021 (Friday)
Conference: 22 August (Sunday) - 27 August (Friday)

### Submission Details

Each submission (referred to as "abstract" below) should include the
student author’s name and e-mail address; institutional affiliation;
research advisor’s name; ACM student member number; category
(undergraduate or graduate); research title; and an extended abstract
addressing the following:

* Problem and Motivation: Clearly state the problem being addressed and
explain the reasons for seeking a solution to this problem.

* Background and Related Work: Describe the specialized (but
pertinent) background necessary to appreciate the work in the
context of ICFP areas of interest. Include references to the
literature where appropriate, and briefly explain where your work
departs from that done by others.

* Approach and Uniqueness: Describe your approach in addressing the
problem and clearly state how your approach is novel.

* Results and Contributions: Clearly show how the results of your work
contribute to programming language design and implementation in
particular and to computer science in general; explain the
significance of those results.

* Submissions must be original research that is not already published
at ICFP or another conference or journal. One of the goals of the
SRC is to give students feedback on ongoing, unpublished
work. Furthermore, the abstract must be authored solely by the
student. If the work is collaborative with others and*or part of a
larger group project, the abstract should make clear what the
student’s role was and should focus on that portion of the work.

* 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. For authors
using LaTeX, a lighter-weight package, including only the essential
files, is available from
http://sigplan.org/Resources/Author/#acmart-format. The submission
must not exceed 3 pages in PDF format. Reference lists do not count
towards the 3-page limit.

Further information is available at the ICFP SRC website:
https://icfp21.sigplan.org/track/icfp-2021-Student-Research-Competition

Program Committee:
Chair: Anders Miltner (UT Austin)
Andreea Costea (NUS Singapore)
Andrew Hirsch (MPI-SWS)
Liam O'Connor (University of Edinburgh)
Lionel Parreaux (HKUST)
Daming Zou (ETH Zurich)

From effectfully at gmail.com  Thu Jun 17 13:20:41 2021
From: effectfully at gmail.com (Roman)
Date: Thu, 17 Jun 2021 16:20:41 +0300
Subject: [Haskell-cafe] Pearl! I just proved theorem about impossibility
 of monad transformer for parsing with (1) unbiased choice and (2) ambiguity
 checking before running embedded monadic action (also,
 I THREAT I will create another parsing lib)
In-Reply-To: <CAPq5PvJn8dEhqL68NLvjS8qHSz3Lz6mO3kOjP-EzgNKH7t9Esw@mail.gmail.com>
References: <1623449910.725986714@f337.i.mail.ru>
 <CAPq5PvJnAQntH0C_QE=cJOaBni6PDd5sBbUg+T69pwkUmT87Gw@mail.gmail.com>
 <1623457456.570972111@f163.i.mail.ru>
 <CAPq5PvJn8dEhqL68NLvjS8qHSz3Lz6mO3kOjP-EzgNKH7t9Esw@mail.gmail.com>
Message-ID: <CAGg1QxF_GW9vvH2iQ5g5cFDS4tokO6M0c1xSS1N95C6MVmoPdA@mail.gmail.com>

Askar,

> 2. We need to prepend "fromEither" before each parser, in which we plan to fail with error messages.

Are you familiar with selective functors [1]? That library might be
helpful in your case.

[1] https://hackage.haskell.org/package/selective-0.4.2

From safinaskar at mail.ru  Thu Jun 17 16:02:05 2021
From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=)
Date: Thu, 17 Jun 2021 19:02:05 +0300
Subject: [Haskell-cafe]
 =?utf-8?q?Pearl!_I_just_proved_theorem_about_impos?=
 =?utf-8?q?sibility_of_monad_transformer_for_parsing_with_=281=29_unbiased?=
 =?utf-8?q?_choice_and_=282=29_ambiguity_checking_before_running_embedded_?=
 =?utf-8?q?monadic_action_=28also=2C_I_THREAT_I_will_create_another_parsin?=
 =?utf-8?q?g_lib=29?=
In-Reply-To: <CAGg1QxF_GW9vvH2iQ5g5cFDS4tokO6M0c1xSS1N95C6MVmoPdA@mail.gmail.com>
References: <1623449910.725986714@f337.i.mail.ru>
 <CAPq5PvJn8dEhqL68NLvjS8qHSz3Lz6mO3kOjP-EzgNKH7t9Esw@mail.gmail.com>
 <CAGg1QxF_GW9vvH2iQ5g5cFDS4tokO6M0c1xSS1N95C6MVmoPdA@mail.gmail.com>
Message-ID: <1623945725.407240679@f323.i.mail.ru>

> Are you familiar with selective functors [1]? That library might be
> helpful in your case.

Thanks for link. This lib is not for me. It allows choosing next computation based on result of previous computation. This is exactly that think, which is forbidden in my task. Because number of possible parses should not depend on results of embedded monadic actions.

I already wrote lib based on arrows. It works. I will share code when it is done.

==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

From harendra.kumar at gmail.com  Sat Jun 19 19:34:03 2021
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sun, 20 Jun 2021 01:04:03 +0530
Subject: [Haskell-cafe] Fwd: Haskell colour package repository
In-Reply-To: <CAPW+kkb5mox+e4ZXCAfFJ=_Js8FMg_+C5m1dXvjZAwrDxWWLjg@mail.gmail.com>
References: <CAPW+kkb5mox+e4ZXCAfFJ=_Js8FMg_+C5m1dXvjZAwrDxWWLjg@mail.gmail.com>
Message-ID: <CAPW+kkYvnqmEz_tGOBW9LPyO=83-Vgrt6mXCStSyqvUVvusamA@mail.gmail.com>

Does anyone know who maintains the "colour" package or where the repository
is hosted? I tried to contact Russell O'Connor but did not get a response.

-harendra

---------- Forwarded message ---------
From: Harendra Kumar <harendra.kumar at gmail.com>
Date: Mon, 17 May 2021 at 05:38
Subject: Haskell colour package repository
To: <roconnor at theorem.ca>


Hi,

I was building something that depends on
https://hackage.haskell.org/package/colour package using GHC-9.3, and it's
failing to build. I was wondering if it is possible to add a URL to the
package repository in the cabal file of the package so that I can
clone/fix/send a PR? Or maybe a URL for reporting issues/bugs?

Thanks,
Harendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210620/6a2e320c/attachment.html>

From migmit at gmail.com  Sat Jun 19 19:38:59 2021
From: migmit at gmail.com (MigMit)
Date: Sat, 19 Jun 2021 21:38:59 +0200
Subject: [Haskell-cafe] Haskell colour package repository
In-Reply-To: <CAPW+kkYvnqmEz_tGOBW9LPyO=83-Vgrt6mXCStSyqvUVvusamA@mail.gmail.com>
References: <CAPW+kkb5mox+e4ZXCAfFJ=_Js8FMg_+C5m1dXvjZAwrDxWWLjg@mail.gmail.com>
 <CAPW+kkYvnqmEz_tGOBW9LPyO=83-Vgrt6mXCStSyqvUVvusamA@mail.gmail.com>
Message-ID: <EDE4C8ED-A324-4BA6-A969-EEB743615BFD@gmail.com>

I found this: https://github.com/haasn/colour — which says "This is a fork of http://hackage.haskell.org/package/colour which is not github or any other public code sharing site".

> On 19 Jun 2021, at 21:34, Harendra Kumar <harendra.kumar at gmail.com> wrote:
> 
> 
> Does anyone know who maintains the "colour" package or where the repository is hosted? I tried to contact Russell O'Connor but did not get a response.
> 
> -harendra
> 
> ---------- Forwarded message ---------
> From: Harendra Kumar <harendra.kumar at gmail.com>
> Date: Mon, 17 May 2021 at 05:38
> Subject: Haskell colour package repository
> To: <roconnor at theorem.ca>
> 
> 
> Hi,
> 
> I was building something that depends on https://hackage.haskell.org/package/colour package using GHC-9.3, and it's failing to build. I was wondering if it is possible to add a URL to the package repository in the cabal file of the package so that I can clone/fix/send a PR? Or maybe a URL for reporting issues/bugs?
> 
> Thanks,
> Harendra
> _______________________________________________
> 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 capn.freako at gmail.com  Sat Jun 19 19:53:35 2021
From: capn.freako at gmail.com (David Banas)
Date: Sat, 19 Jun 2021 12:53:35 -0700
Subject: [Haskell-cafe] Tips for debugging seg. faults?
Message-ID: <F28D6441-AFEA-4F3E-BE58-8EDBCFB192F3@gmail.com>

Does anyone have any helpful tips for debugging seg. faults in a Haskell program that calls out to a C library, via the FFI?

From lemming at henning-thielemann.de  Sat Jun 19 20:13:25 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sat, 19 Jun 2021 22:13:25 +0200 (CEST)
Subject: [Haskell-cafe] Tips for debugging seg. faults?
In-Reply-To: <F28D6441-AFEA-4F3E-BE58-8EDBCFB192F3@gmail.com>
References: <F28D6441-AFEA-4F3E-BE58-8EDBCFB192F3@gmail.com>
Message-ID: <152a17b-965-d85-1412-12254345264@henning-thielemann.de>


On Sat, 19 Jun 2021, David Banas wrote:

> Does anyone have any helpful tips for debugging seg. faults in a Haskell program that calls out to a C library, via the FFI?

Running the program with valgrind might help.

From ietf-dane at dukhovni.org  Sat Jun 19 22:46:53 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 19 Jun 2021 18:46:53 -0400
Subject: [Haskell-cafe] Tips for debugging seg. faults?
In-Reply-To: <F28D6441-AFEA-4F3E-BE58-8EDBCFB192F3@gmail.com>
References: <F28D6441-AFEA-4F3E-BE58-8EDBCFB192F3@gmail.com>
Message-ID: <YM5z3WGBGDJAwmC1@straasha.imrryr.org>

On Sat, Jun 19, 2021 at 12:53:35PM -0700, David Banas wrote:

> Does anyone have any helpful tips for debugging seg. faults in a
> Haskell program that calls out to a C library, via the FFI?

The question would ideally be more specific.  What kind of data is being
passed to the C FFI function?  The most common issue is that the
structure passed may no longer have any live references on the Haskell
side, and may be freed before the C FFI is done with it.

Thus functions like `withForeignPtr` which try to make sure the the
referenced memory is not released too early.

Buffer pointers should be to pinned memory, ...

Sure, build your program with "-Og -g -ggdb3" and use "gdb" to see more
context for the crash, but typically the problem is a simple misuse of
pointers that are not guaranteed to be valid.

Therefore, what is the FFI signature, and how is it called?

-- 
    Viktor.

From capn.freako at gmail.com  Sun Jun 20 13:54:32 2021
From: capn.freako at gmail.com (David Banas)
Date: Sun, 20 Jun 2021 06:54:32 -0700
Subject: [Haskell-cafe] Tips for debugging seg. faults?
In-Reply-To: <mailman.1.1624190401.24091.haskell-cafe@haskell.org>
References: <mailman.1.1624190401.24091.haskell-cafe@haskell.org>
Message-ID: <9BBA7E2E-592F-4072-BCAE-7A1D735D9B58@gmail.com>

Thank you, Viktor!

Wrt/ `withForeignPtr`, you are suggesting that I use it, not that I avoid it; correct?

Wrt/ “pinned memory”, could you give me a little more explanation?

Thanks,
-db
:)

> On Jun 20, 2021, at 5:00 AM, haskell-cafe-request at haskell.org wrote:
> 
> Thus functions like `withForeignPtr` which try to make sure the the
> referenced memory is not released too early.
> 
> Buffer pointers should be to pinned memory, ...

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

From kindaro at gmail.com  Sun Jun 20 16:46:40 2021
From: kindaro at gmail.com (Ignat Insarov)
Date: Sun, 20 Jun 2021 21:46:40 +0500
Subject: [Haskell-cafe] Fwd: Haskell colour package repository
In-Reply-To: <CAPW+kkYvnqmEz_tGOBW9LPyO=83-Vgrt6mXCStSyqvUVvusamA@mail.gmail.com>
References: <CAPW+kkb5mox+e4ZXCAfFJ=_Js8FMg_+C5m1dXvjZAwrDxWWLjg@mail.gmail.com>
 <CAPW+kkYvnqmEz_tGOBW9LPyO=83-Vgrt6mXCStSyqvUVvusamA@mail.gmail.com>
Message-ID: <CAB-2Q0-LmpdhJQ6A3rrQ4AwVojttommETMXHxi7dcLVxS+GL7g@mail.gmail.com>

Hello Harendra!

I sent a letter to Russell concerning an issue I had with `colour` and
eventually he replied. _(Possibly after a follow up letter.)_ This was
maybe two months ago. You might try writing him again!

On Sun, 20 Jun 2021 at 00:35, Harendra Kumar <harendra.kumar at gmail.com> wrote:
>
>
> Does anyone know who maintains the "colour" package or where the repository is hosted? I tried to contact Russell O'Connor but did not get a response.
>
> -harendra
>
> ---------- Forwarded message ---------
> From: Harendra Kumar <harendra.kumar at gmail.com>
> Date: Mon, 17 May 2021 at 05:38
> Subject: Haskell colour package repository
> To: <roconnor at theorem.ca>
>
>
> Hi,
>
> I was building something that depends on https://hackage.haskell.org/package/colour package using GHC-9.3, and it's failing to build. I was wondering if it is possible to add a URL to the package repository in the cabal file of the package so that I can clone/fix/send a PR? Or maybe a URL for reporting issues/bugs?
>
> Thanks,
> Harendra
> _______________________________________________
> 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 lemming at henning-thielemann.de  Sun Jun 20 17:35:16 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 20 Jun 2021 19:35:16 +0200 (CEST)
Subject: [Haskell-cafe] Tips for debugging seg. faults?
In-Reply-To: <9BBA7E2E-592F-4072-BCAE-7A1D735D9B58@gmail.com>
References: <mailman.1.1624190401.24091.haskell-cafe@haskell.org>
 <9BBA7E2E-592F-4072-BCAE-7A1D735D9B58@gmail.com>
Message-ID: <bf29cf4d-2859-9620-4595-a8e19914574b@henning-thielemann.de>


On Sun, 20 Jun 2021, David Banas wrote:

> Thank you, Viktor!
> Wrt/ `withForeignPtr`, you are suggesting that I use it, not that I avoid it; correct?

Yes, withForeignPtr should be used and unsafeForeignPtrToPtr should be 
avoided.

From ietf-dane at dukhovni.org  Sun Jun 20 22:08:52 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sun, 20 Jun 2021 18:08:52 -0400
Subject: [Haskell-cafe] Tips for debugging seg. faults?
In-Reply-To: <9BBA7E2E-592F-4072-BCAE-7A1D735D9B58@gmail.com>
References: <mailman.1.1624190401.24091.haskell-cafe@haskell.org>
 <9BBA7E2E-592F-4072-BCAE-7A1D735D9B58@gmail.com>
Message-ID: <YM+8dMwTx9Q99tt/@straasha.imrryr.org>

On Sun, Jun 20, 2021 at 06:54:32AM -0700, David Banas wrote:

> Wrt/ `withForeignPtr`, you are suggesting that I use it, not that I
> avoid it; correct?

Yes, it tries to ensure that memory is not released too early.

> Wrt/ “pinned memory”, could you give me a little more explanation?

I'd like to repeat my suggestion that you should post more details about
your use-case.  The abstract discussion may waste your time on topics
that are not relevant to you.

-- 
    Viktor.

From matteo at confscience.com  Mon Jun 21 07:19:00 2021
From: matteo at confscience.com (matteo at confscience.com)
Date: Mon, 21 Jun 2021 09:19:00 +0200
Subject: [Haskell-cafe] International Conference on Recent Theories and
	Applications in Transportation and Mobility - (RTATM 2021) Prague
Message-ID: <006501d7666d$b5832c20$20898460$@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/  

All papers accepted in RTATM 2021 will be published in Springer CCIS (Communications in Computer and Information Science). 

CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings)

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

IMPORTANT DATES:

- Paper Submission: June 30, 2021 (extended) 

- Acceptance Notification: July 15, 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/20210621/a239c061/attachment.html>

From matteo at confscience.com  Mon Jun 21 07:33:28 2021
From: matteo at confscience.com (matteo at confscience.com)
Date: Mon, 21 Jun 2021 09:33:28 +0200
Subject: [Haskell-cafe] International Conference on Applied Data Science and
	Intelligence - (ADSI 2021) Prague
Message-ID: <002c01d7666f$babd9a70$3038cf50$@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/  

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: June 30, 2021 (extended) 

- Acceptance Notification: July 15, 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/20210621/1207e117/attachment.html>

From compl.yue at icloud.com  Mon Jun 21 11:44:27 2021
From: compl.yue at icloud.com (YueCompl)
Date: Mon, 21 Jun 2021 19:44:27 +0800
Subject: [Haskell-cafe] Is `MonadBaseControl` dead?
Message-ID: <E039DCC8-7D46-4BA5-9B5B-A92A2F1BCC17@icloud.com>

Greetings!

This is also posted at https://www.reddit.com/r/haskell/comments/o4sggi/is_monadbasecontrol_dead/ <https://www.reddit.com/r/haskell/comments/o4sggi/is_monadbasecontrol_dead/> but I'd like to also seek wider help here.

(Background issue I'm facing: https://github.com/snapframework/snap-core/issues/309)

I think the functionality of [MonadUnliftIO](https://hackage.haskell.org/package/unliftio-core-0.2.0.1/docs/Control-Monad-IO-Unlift.html#t:MonadUnliftIO) is exactly what I want, but unfortunately [Snap](https://hackage.haskell.org/package/snap-core-1.0.4.2/docs/Snap-Core.html#t:Snap) appears not eligible for:

> the intuition is that a monad must have no monadic state, but may have monadic context. This essentially limits MonadUnliftIO to ReaderT and IdentityT transformers on top of IO.

Then I found `Snap` [has a MonadBaseControl instance](https://hackage.haskell.org/package/snap-core-1.0.4.2/docs/src/Snap.Internal.Core.html#line-347), and thought it should work for me. But sadly to find it [losing states](https://github.com/snapframework/snap-core/issues/309). Also I failed to find a user side example of `MonadBaseControl` on Github ([as there're only instance impl. hits](https://github.com/search?l=Haskell&q=org%3Asnapframework+liftBaseWith&type=Code)), so I have not way to verify whether that's due to my incorrect usage.

Any way quoting u/snoyberg : https://github.com/fpco/unliftio/issues/17#issuecomment-363655106
> Continuation-based monads cannot have instances of MonadUnliftIO, the same as MonadBaseControl and MonadMask. 

Then I'm not sure `Snap`'s `MonadBaseControl` instance shall really work.

Also seems there had been debates I'm not aware of with clue at: https://github.com/fpco/unliftio/tree/master/unliftio#monad-control
> 
> The main contention until now is that unlifting in a transformer like
> `StateT` is unsafe. This is not universally true: if only one action
> is being unlifted, no ambiguity exists. So, for example, `try :: IO a
> -> IO (Either e a)` can safely be unlifted in `StateT`, while `finally
> :: IO a -> IO b -> IO a` cannot.
> 
> `monad-control` allows us to unlift both styles. In theory, we could
> write a variant of `lifted-base` that never does state discards, and
> let `try` be more general than `finally`. In other words, this is an
> advantage of `monad-control` over `MonadUnliftIO`. We've avoided
> providing any such extra typeclass in this package though, for two
> reasons:
> 
> * `MonadUnliftIO` is a simple typeclass, easy to explain. We don't
>   want to complicated matters (`MonadBaseControl` is a notoriously
>   difficult to understand typeclass). This simplicity
>   is captured by the laws for `MonadUnliftIO`, which make the
>   behavior of the run functions close to that of the already familiar
>   `lift` and `liftIO`.
> * Having this kind of split would be confusing in user code, when
>   suddenly `finally` is not available to us. We would rather encourage
>   [good practices](https://www.fpcomplete.com/blog/2017/06/readert-design-pattern)
>   from the beginning.
> 
> Another distinction is that `monad-control` uses the `MonadBase`
> style, allowing unlifting to arbitrary base monads. In this package,
> we've elected to go with `MonadIO` style. This limits what we can do
> (e.g., no unlifting to `STM`), but we went this way because:
> 
> * In practice, we've found that the vast majority of cases are dealing
>   with `IO`
> * The split in the ecosystem between constraints like `MonadBase IO`
>   and `MonadIO` leads to significant confusion, and `MonadIO` is by
>   far the more common constraints (with the typeclass existing in
>   `base`)
>

So is `MonadBaseControl` dead or alive? Any user side example for it?

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

From safinaskar at mail.ru  Tue Jun 22 12:44:06 2021
From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=)
Date: Tue, 22 Jun 2021 15:44:06 +0300
Subject: [Haskell-cafe]
 =?utf-8?q?Pearl!_I_just_proved_theorem_about_impos?=
 =?utf-8?q?sibility_of_monad_transformer_for_parsing_with_=281=29_unbiased?=
 =?utf-8?q?_choice_and_=282=29_ambiguity_checking_before_running_embedded_?=
 =?utf-8?q?monadic_action_=28also=2C_I_THREAT_I_will_create_another_parsin?=
 =?utf-8?q?g_lib=29?=
In-Reply-To: <d0fa9641a1b5c26c928f2ddd53b32fce088fa477.camel@aatal-apotheke.de>
References: <d0fa9641a1b5c26c928f2ddd53b32fce088fa477.camel@aatal-apotheke.de>
Message-ID: <1624365846.292641423@f308.i.mail.ru>

Hi. Thanks for answer! I already wrote arrow parsing lib. I will publish it when I was done. Also, you forgot to add haskell-cafe at haskell.org to CC.

Понедельник, 21 июня 2021, 21:53 +03:00 от "Olaf Klinke" <olf at aatal-apotheke.de>:
> Dear Askar, 
> 
> your theorem is convincing. While a counterexample is sufficient for a
> rigorous proof, I'll try to add some mathematical theory to this. Many
> monad transformers are of the form FooT m a = g (m (f a)) where (f,g)
> is an adjoint pair of functors. The Kleisli lifting operation (=<<) for
> such a composite monad uses the Kleisli lifting of m. For your
> application that means that you can not use monadic actions of your
> monad transformer without executing the monadic actions of the
> transformed monad m. I conjecture that any transformer FooT with the
> property that FooT m is a monad provided m is a monad necessarily runs
> m-actions. 
> 
> A transformer that does not require m to be a monad is the continuation
> transformer ContT m r a = (a -> m r) -> m r. However, for this
> transformer the lift operation is interdefinable with an operation m (m
> r) -> m r so it seems that at least lift will run m-actions. 
> 
> As Chris Smith pointed out, this does not rule out that Applicative-
> style parsing code may be able to prevent executing the m-actions. 
> 
> Olaf
> 


==
Askar Safin
http://safinaskar.com
https://sr.ht/~safinaskar
https://github.com/safinaskar

From carter.schonwald at gmail.com  Tue Jun 22 20:35:58 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 22 Jun 2021 16:35:58 -0400
Subject: [Haskell-cafe] Tips for debugging seg. faults?
In-Reply-To: <YM+8dMwTx9Q99tt/@straasha.imrryr.org>
References: <mailman.1.1624190401.24091.haskell-cafe@haskell.org>
 <9BBA7E2E-592F-4072-BCAE-7A1D735D9B58@gmail.com>
 <YM+8dMwTx9Q99tt/@straasha.imrryr.org>
Message-ID: <CAHYVw0w1hAZkqjRc6GBxXd5aKWWSUWX7EAQ716beMOE1AKpCoQ@mail.gmail.com>

Agreed. For low level crashes any ambiguity leads to a lot of erroneous
tail chasing

On Sun, Jun 20, 2021 at 6:13 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Sun, Jun 20, 2021 at 06:54:32AM -0700, David Banas wrote:
>
> > Wrt/ `withForeignPtr`, you are suggesting that I use it, not that I
> > avoid it; correct?
>
> Yes, it tries to ensure that memory is not released too early.
>
> > Wrt/ “pinned memory”, could you give me a little more explanation?
>
> I'd like to repeat my suggestion that you should post more details about
> your use-case.  The abstract discussion may waste your time on topics
> that are not relevant to you.
>
> --
>     Viktor.
> _______________________________________________
> 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/20210622/9a3666a9/attachment.html>

From cdsmith at gmail.com  Wed Jun 23 04:06:22 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Wed, 23 Jun 2021 00:06:22 -0400
Subject: [Haskell-cafe] Is anyone running regular virtual Haskell hacking
	events?
Message-ID: <CAPq5Pv+MMu9Y=EGAE0aDujS1PoPHq+KrwXUg55nSQQrcMXLWKg@mail.gmail.com>

I'm thinking of ideas, and wondering if anyone's beat me to this one.

Before COVID-19, I organized a "co-hack" with the New York Haskell User
Group one Saturday per month, where people would get together and write or
discuss Haskell for several hours.  I always had a great time, but... then
COVID-19.

Does something like this exist online?

If not, I was just looking at Zoom, and realized they have breakout rooms
where people can divide up and separately talk in groups.  I was thinking
of setting up an event something like this:

Start: 9am Pacific / 12pm Eastern / 4pm GMT / 6pm CET
- 15 minute intro and logistics
- 30 minute Small group intros.  Divide people up randomly into small
groups to introduce themselves and talk about their Haskell stories and
what they are working on.  About 4-5 people per group (because 2 people
feels too small, but too many people means shy people are afraid to speak
up.)
- 30 minute lightning talks and project pitches: Maybe 5 minutes / 3 slides
max, sign up in advance or jump in and do a talk impulsively
- 2.5 hours project time.  Use for working together on projects, pair
programming, teach and learn Haskell, etc.  Use Zoom breakout groups and
let people hop from room to room as desired.  Pre-create some rooms for
common activities (like "Beginner Questions", "Project Euler", etc.)
Create some generic rooms people can jump in as they like for short
collaborations.  Create persistent project-specific rooms on demand.
- 15 minute wrap-up.
Finish: 1pm Pacific / 4pm Eastern / 8pm GMT / 10pm CET

What does everyone think?  I don't see any reason this couldn't go really
well.  The Cohack in New York was really fun, and I'd like to give it a
shot.

Anyone else motivated to help run this?  If I can get at least one
co-facilitator, I'll jump in and make it happen.  I'll spring for the Zoom
account.  Probably use Meetup to take signups and manage scheduling, unless
someone has another preference.

Thanks,
Chris Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210623/4a3a26a7/attachment.html>

From carter.schonwald at gmail.com  Wed Jun 23 16:41:51 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 23 Jun 2021 12:41:51 -0400
Subject: [Haskell-cafe] Is anyone running regular virtual Haskell
	hacking events?
In-Reply-To: <CAPq5Pv+MMu9Y=EGAE0aDujS1PoPHq+KrwXUg55nSQQrcMXLWKg@mail.gmail.com>
References: <CAPq5Pv+MMu9Y=EGAE0aDujS1PoPHq+KrwXUg55nSQQrcMXLWKg@mail.gmail.com>
Message-ID: <CAHYVw0yubg80tr+6DDVHjkV3kLeAK5z3D=Pp60SztQRGReG7MQ@mail.gmail.com>

I really enjoyed the cohack events you ran!

On Wed, Jun 23, 2021 at 12:07 AM Chris Smith <cdsmith at gmail.com> wrote:

> I'm thinking of ideas, and wondering if anyone's beat me to this one.
>
> Before COVID-19, I organized a "co-hack" with the New York Haskell User
> Group one Saturday per month, where people would get together and write or
> discuss Haskell for several hours.  I always had a great time, but... then
> COVID-19.
>
> Does something like this exist online?
>
> If not, I was just looking at Zoom, and realized they have breakout rooms
> where people can divide up and separately talk in groups.  I was thinking
> of setting up an event something like this:
>
> Start: 9am Pacific / 12pm Eastern / 4pm GMT / 6pm CET
> - 15 minute intro and logistics
> - 30 minute Small group intros.  Divide people up randomly into small
> groups to introduce themselves and talk about their Haskell stories and
> what they are working on.  About 4-5 people per group (because 2 people
> feels too small, but too many people means shy people are afraid to speak
> up.)
> - 30 minute lightning talks and project pitches: Maybe 5 minutes / 3
> slides max, sign up in advance or jump in and do a talk impulsively
> - 2.5 hours project time.  Use for working together on projects, pair
> programming, teach and learn Haskell, etc.  Use Zoom breakout groups and
> let people hop from room to room as desired.  Pre-create some rooms for
> common activities (like "Beginner Questions", "Project Euler", etc.)
> Create some generic rooms people can jump in as they like for short
> collaborations.  Create persistent project-specific rooms on demand.
> - 15 minute wrap-up.
> Finish: 1pm Pacific / 4pm Eastern / 8pm GMT / 10pm CET
>
> What does everyone think?  I don't see any reason this couldn't go really
> well.  The Cohack in New York was really fun, and I'd like to give it a
> shot.
>
> Anyone else motivated to help run this?  If I can get at least one
> co-facilitator, I'll jump in and make it happen.  I'll spring for the Zoom
> account.  Probably use Meetup to take signups and manage scheduling, unless
> someone has another preference.
>
> Thanks,
> Chris Smith
> _______________________________________________
> 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/20210623/bec33fe3/attachment.html>

From cdsmith at gmail.com  Wed Jun 23 18:19:27 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Wed, 23 Jun 2021 14:19:27 -0400
Subject: [Haskell-cafe] Is anyone running regular virtual Haskell
	hacking events?
In-Reply-To: <CAHYVw0yubg80tr+6DDVHjkV3kLeAK5z3D=Pp60SztQRGReG7MQ@mail.gmail.com>
References: <CAPq5Pv+MMu9Y=EGAE0aDujS1PoPHq+KrwXUg55nSQQrcMXLWKg@mail.gmail.com>
 <CAHYVw0yubg80tr+6DDVHjkV3kLeAK5z3D=Pp60SztQRGReG7MQ@mail.gmail.com>
Message-ID: <CAPq5Pv+7JmKa01Rr_-NkoGG0Lywui15XC1zzcv769JGZRZ=edA@mail.gmail.com>

Thanks Carter.  I really enjoyed it as well.  There are definitely some
parts of the experience that won't translate well into a virtual setting,
but I hope we can balance that with some unique virtual advantages;
especially that we can open it up to a lot more people than just the New
York area.

I'm hoping someone is up for helping me with organizing the online events?
Anyone?

On Wed, Jun 23, 2021 at 12:42 PM Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> I really enjoyed the cohack events you ran!
>
> On Wed, Jun 23, 2021 at 12:07 AM Chris Smith <cdsmith at gmail.com> wrote:
>
>> I'm thinking of ideas, and wondering if anyone's beat me to this one.
>>
>> Before COVID-19, I organized a "co-hack" with the New York Haskell User
>> Group one Saturday per month, where people would get together and write or
>> discuss Haskell for several hours.  I always had a great time, but... then
>> COVID-19.
>>
>> Does something like this exist online?
>>
>> If not, I was just looking at Zoom, and realized they have breakout rooms
>> where people can divide up and separately talk in groups.  I was thinking
>> of setting up an event something like this:
>>
>> Start: 9am Pacific / 12pm Eastern / 4pm GMT / 6pm CET
>> - 15 minute intro and logistics
>> - 30 minute Small group intros.  Divide people up randomly into small
>> groups to introduce themselves and talk about their Haskell stories and
>> what they are working on.  About 4-5 people per group (because 2 people
>> feels too small, but too many people means shy people are afraid to speak
>> up.)
>> - 30 minute lightning talks and project pitches: Maybe 5 minutes / 3
>> slides max, sign up in advance or jump in and do a talk impulsively
>> - 2.5 hours project time.  Use for working together on projects, pair
>> programming, teach and learn Haskell, etc.  Use Zoom breakout groups and
>> let people hop from room to room as desired.  Pre-create some rooms for
>> common activities (like "Beginner Questions", "Project Euler", etc.)
>> Create some generic rooms people can jump in as they like for short
>> collaborations.  Create persistent project-specific rooms on demand.
>> - 15 minute wrap-up.
>> Finish: 1pm Pacific / 4pm Eastern / 8pm GMT / 10pm CET
>>
>> What does everyone think?  I don't see any reason this couldn't go really
>> well.  The Cohack in New York was really fun, and I'd like to give it a
>> shot.
>>
>> Anyone else motivated to help run this?  If I can get at least one
>> co-facilitator, I'll jump in and make it happen.  I'll spring for the Zoom
>> account.  Probably use Meetup to take signups and manage scheduling, unless
>> someone has another preference.
>>
>> Thanks,
>> Chris Smith
>> _______________________________________________
>> 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/20210623/27902806/attachment.html>

From xnningxie at gmail.com  Wed Jun 23 18:27:50 2021
From: xnningxie at gmail.com (Ningning Xie)
Date: Wed, 23 Jun 2021 14:27:50 -0400
Subject: [Haskell-cafe] Final Call for Talks: Haskell Implementors' Workshop
	@ ICFP'21
Message-ID: <CABjRk3m5z2cZU4aPUuuCrJ9uzDk+UJaKa_JkpXjifGPHEmnTqA@mail.gmail.com>

                         Final Call for Talks
               ACM SIGPLAN Haskell Implementors' Workshop

                https://icfp21.sigplan.org/home/hiw-2021
                         Virtual, 22 Aug, 2021

                      Co-located with ICFP 2021
                     https://icfp21.sigplan.org/

New: Invited Speaker
--------------------

Title: Haskell reinterpreted – large-scale real-world experience with the Mu
compiler in Financial Markets
Speaker: Bengt Marten Agren, Standard Chartered Bank


Important dates
---------------

Deadline:       Wednesday, 30 June, 2021 (AoE)
Notification:   Wednesday, 14 July, 2021
Workshop:       Sunday, 22 August, 2021

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

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with
open spaces in the timetable and room for ad-hoc discussion, demos,
and lightning short talks.

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

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

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are specially encouraged to share their work.

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

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

Talks
-----

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

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

We will also have lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Logistics
---------

Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW)
will be held remotely this year. However, the organizers are still
working hard to provide for a great workshop experience.

While we are sad that this year will lack the robust hallway track that
is often the highlight of HIW, we believe that this remote workshop
presents a unique opportunity to include more of the Haskell community
in our discussion and explore new modes of communicating with our
colleagues. We hope that you will join us in making this HIW as
vibrant as any other.


Program Committee
-----------------

  * Dominique Devriese (Vrije Universiteit Brussel)
  * Daan Leijen (Microsoft Research)
  * Andres Löh (Well-Typed LLP)
  * Julie Moronuki (Typeclass Consulting)
  * John Wiegley (DFINITY)
  * Ningning Xie (the University of Hong Kong)
  * Edward Z. Yang (Facebook AI Research)

Contact
-------

  * Ningning Xie <xnning at hku.hk>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210623/837dc9bd/attachment.html>

From jeffbrown.the at gmail.com  Wed Jun 23 18:29:48 2021
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Wed, 23 Jun 2021 13:29:48 -0500
Subject: [Haskell-cafe] Is anyone running regular virtual Haskell
	hacking events?
In-Reply-To: <CAPq5Pv+7JmKa01Rr_-NkoGG0Lywui15XC1zzcv769JGZRZ=edA@mail.gmail.com>
References: <CAPq5Pv+MMu9Y=EGAE0aDujS1PoPHq+KrwXUg55nSQQrcMXLWKg@mail.gmail.com>
 <CAHYVw0yubg80tr+6DDVHjkV3kLeAK5z3D=Pp60SztQRGReG7MQ@mail.gmail.com>
 <CAPq5Pv+7JmKa01Rr_-NkoGG0Lywui15XC1zzcv769JGZRZ=edA@mail.gmail.com>
Message-ID: <CAEc4Ma0Y8VFQT50rR_rLXZfiVVeX5MaByw1fiLXbmiPngusXug@mail.gmail.com>

I think it's a great idea. What would helping you organize involve?

On Wed, Jun 23, 2021 at 1:21 PM Chris Smith <cdsmith at gmail.com> wrote:

> Thanks Carter.  I really enjoyed it as well.  There are definitely some
> parts of the experience that won't translate well into a virtual setting,
> but I hope we can balance that with some unique virtual advantages;
> especially that we can open it up to a lot more people than just the New
> York area.
>
> I'm hoping someone is up for helping me with organizing the online
> events?  Anyone?
>
> On Wed, Jun 23, 2021 at 12:42 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> I really enjoyed the cohack events you ran!
>>
>> On Wed, Jun 23, 2021 at 12:07 AM Chris Smith <cdsmith at gmail.com> wrote:
>>
>>> I'm thinking of ideas, and wondering if anyone's beat me to this one.
>>>
>>> Before COVID-19, I organized a "co-hack" with the New York Haskell User
>>> Group one Saturday per month, where people would get together and write or
>>> discuss Haskell for several hours.  I always had a great time, but... then
>>> COVID-19.
>>>
>>> Does something like this exist online?
>>>
>>> If not, I was just looking at Zoom, and realized they have breakout
>>> rooms where people can divide up and separately talk in groups.  I was
>>> thinking of setting up an event something like this:
>>>
>>> Start: 9am Pacific / 12pm Eastern / 4pm GMT / 6pm CET
>>> - 15 minute intro and logistics
>>> - 30 minute Small group intros.  Divide people up randomly into small
>>> groups to introduce themselves and talk about their Haskell stories and
>>> what they are working on.  About 4-5 people per group (because 2 people
>>> feels too small, but too many people means shy people are afraid to speak
>>> up.)
>>> - 30 minute lightning talks and project pitches: Maybe 5 minutes / 3
>>> slides max, sign up in advance or jump in and do a talk impulsively
>>> - 2.5 hours project time.  Use for working together on projects, pair
>>> programming, teach and learn Haskell, etc.  Use Zoom breakout groups and
>>> let people hop from room to room as desired.  Pre-create some rooms for
>>> common activities (like "Beginner Questions", "Project Euler", etc.)
>>> Create some generic rooms people can jump in as they like for short
>>> collaborations.  Create persistent project-specific rooms on demand.
>>> - 15 minute wrap-up.
>>> Finish: 1pm Pacific / 4pm Eastern / 8pm GMT / 10pm CET
>>>
>>> What does everyone think?  I don't see any reason this couldn't go
>>> really well.  The Cohack in New York was really fun, and I'd like to give
>>> it a shot.
>>>
>>> Anyone else motivated to help run this?  If I can get at least one
>>> co-facilitator, I'll jump in and make it happen.  I'll spring for the Zoom
>>> account.  Probably use Meetup to take signups and manage scheduling, unless
>>> someone has another preference.
>>>
>>> Thanks,
>>> Chris Smith
>>> _______________________________________________
>>> 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.



-- 
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/20210623/5f7a0948/attachment.html>

From capn.freako at gmail.com  Wed Jun 23 20:47:05 2021
From: capn.freako at gmail.com (David Banas)
Date: Wed, 23 Jun 2021 13:47:05 -0700
Subject: [Haskell-cafe] How to debug HSC to HS conversion failure?
Message-ID: <D5FF01CD-33A9-4C8D-951B-8AD1C0B5F680@gmail.com>

I’m getting the following error in response to `cabal build`:

running {pros_dir}/dist-newstyle/build/x86_64-osx/ghc-8.8.4/haskarchpriv-0.1.0.0/build/HaskArch/TLM2_hsc_make failed (exit code -11)
rsp file was: “{proj_dir}/dist-newstyle/build/x86_64-osx/ghc-8.8.4/haskarchpriv-0.1.0.0/build/HaskArch/hsc2hscall86171-3.rsp"

My project contains one *.hsc file, which is the target of the error above.

How can I debug the cause of this?

The “rsp” file is nowhere to be found; what is(was) it?
And, is it a helpful debugging aid?
If so, is there an option I can give, to preserve it?

Thanks!
-db

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

From oleg.grenrus at iki.fi  Wed Jun 23 21:01:41 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Thu, 24 Jun 2021 00:01:41 +0300
Subject: [Haskell-cafe] How to debug HSC to HS conversion failure?
In-Reply-To: <D5FF01CD-33A9-4C8D-951B-8AD1C0B5F680@gmail.com>
References: <D5FF01CD-33A9-4C8D-951B-8AD1C0B5F680@gmail.com>
Message-ID: <902d3ba0-3e6e-bbec-6730-fd422e46f6b7@iki.fi>

I think it's https://github.com/haskell/hsc2hs/issues/47 issue which is
fixed but AFAIK not released.

- Oleg

On 23.6.2021 23.47, David Banas wrote:
> I’m getting the following error in response to `cabal build`:
>
>     running
>     {pros_dir}/dist-newstyle/build/x86_64-osx/ghc-8.8.4/haskarchpriv-0.1.0.0/build/HaskArch/TLM2_hsc_make
>     failed (exit code -11)
>     rsp file was:
>     “{proj_dir}/dist-newstyle/build/x86_64-osx/ghc-8.8.4/haskarchpriv-0.1.0.0/build/HaskArch/hsc2hscall86171-3.rsp"
>
>
> My project contains one *.hsc file, which is the target of the error
> above.
>
> How can I debug the cause of this?
>
> The “rsp” file is nowhere to be found; what is(was) it?
> And, is it a helpful debugging aid?
> If so, is there an option I can give, to preserve it?
>
> Thanks!
> -db
>
>
> _______________________________________________
> 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/20210624/7c40d933/attachment.html>

From cdsmith at gmail.com  Thu Jun 24 01:22:03 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Wed, 23 Jun 2021 21:22:03 -0400
Subject: [Haskell-cafe] Fwd: Is anyone running regular virtual Haskell
	hacking events?
In-Reply-To: <CAPq5PvJ-26XdREkpG_Rq3_rosivdCxXx-Z35Fjeo1FdSMNbcpw@mail.gmail.com>
References: <CAPq5Pv+MMu9Y=EGAE0aDujS1PoPHq+KrwXUg55nSQQrcMXLWKg@mail.gmail.com>
 <CAHYVw0yubg80tr+6DDVHjkV3kLeAK5z3D=Pp60SztQRGReG7MQ@mail.gmail.com>
 <CAPq5Pv+7JmKa01Rr_-NkoGG0Lywui15XC1zzcv769JGZRZ=edA@mail.gmail.com>
 <CAEc4Ma0Y8VFQT50rR_rLXZfiVVeX5MaByw1fiLXbmiPngusXug@mail.gmail.com>
 <CAPq5PvJ-26XdREkpG_Rq3_rosivdCxXx-Z35Fjeo1FdSMNbcpw@mail.gmail.com>
Message-ID: <CAPq5PvLJd+J8x69kk-RSYBmbKQ9Kpq-UhoHFMJre4+wk+5PYeA@mail.gmail.com>

Forwarding as I forgot to include the mailing list in my reply.

---------- Forwarded message ---------
From: Chris Smith <cdsmith at gmail.com>
Date: Wed, Jun 23, 2021 at 9:21 PM
Subject: Re: [Haskell-cafe] Is anyone running regular virtual Haskell
hacking events?
To: Jeffrey Brown <jeffbrown.the at gmail.com>


Jeffrey Brown <jeffbrown.the at gmail.com> wrote:

> I think it's a great idea. What would helping you organize involve?
>

Great question.  I think what I need most is:

1. Well before the event: a second brain to look at the plan and help think
of things that can go wrong for some attendees, and what we might do to
mitigate these factors, or anything else that should be done differently
from what's in my head.
2. Shortly before the event: advertise!  Make sure people know about it and
are excited to come.
3. During the event: someone to play host a bit and help people find
something to do, and generally be helpful to anyone who is lost or
confused.  That's not a role that I'm very good at, and I think it's more
than a one-person job anyway.

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

From amin.saffari at gmail.com  Thu Jun 24 08:23:23 2021
From: amin.saffari at gmail.com (amin saffari)
Date: Thu, 24 Jun 2021 10:23:23 +0200
Subject: [Haskell-cafe] Fwd: Is anyone running regular virtual Haskell
 hacking events?
In-Reply-To: <CAPq5PvLJd+J8x69kk-RSYBmbKQ9Kpq-UhoHFMJre4+wk+5PYeA@mail.gmail.com>
References: <CAPq5Pv+MMu9Y=EGAE0aDujS1PoPHq+KrwXUg55nSQQrcMXLWKg@mail.gmail.com>
 <CAHYVw0yubg80tr+6DDVHjkV3kLeAK5z3D=Pp60SztQRGReG7MQ@mail.gmail.com>
 <CAPq5Pv+7JmKa01Rr_-NkoGG0Lywui15XC1zzcv769JGZRZ=edA@mail.gmail.com>
 <CAEc4Ma0Y8VFQT50rR_rLXZfiVVeX5MaByw1fiLXbmiPngusXug@mail.gmail.com>
 <CAPq5PvJ-26XdREkpG_Rq3_rosivdCxXx-Z35Fjeo1FdSMNbcpw@mail.gmail.com>
 <CAPq5PvLJd+J8x69kk-RSYBmbKQ9Kpq-UhoHFMJre4+wk+5PYeA@mail.gmail.com>
Message-ID: <CAERD60QZ-Ajz6NRZbDVjSkajw79bHTeKJ0kiuMDnHjxczosYLg@mail.gmail.com>

This is indeed a great idea, If I'm not mistaken Chris Goldammer was
hosting a series of sessions with the name "Remote Haskell Learners'' (in
its practical term) in BFPG (
https://www.meetup.com/Berlin-Functional-Programming-Group). Also, not sure
if you wanna make a new meetup group, but I am sure you can host and
advertise your sessions in BFPG, they have a great (and talented) community
and close to all of its members are familiar with the pros&cons of virtual
events, as they frequently have a virtual sessions.

Cheers,
Amin

On Thu, Jun 24, 2021 at 3:23 AM Chris Smith <cdsmith at gmail.com> wrote:

> Forwarding as I forgot to include the mailing list in my reply.
>
> ---------- Forwarded message ---------
> From: Chris Smith <cdsmith at gmail.com>
> Date: Wed, Jun 23, 2021 at 9:21 PM
> Subject: Re: [Haskell-cafe] Is anyone running regular virtual Haskell
> hacking events?
> To: Jeffrey Brown <jeffbrown.the at gmail.com>
>
>
> Jeffrey Brown <jeffbrown.the at gmail.com> wrote:
>
>> I think it's a great idea. What would helping you organize involve?
>>
>
> Great question.  I think what I need most is:
>
> 1. Well before the event: a second brain to look at the plan and help
> think of things that can go wrong for some attendees, and what we might do
> to mitigate these factors, or anything else that should be done differently
> from what's in my head.
> 2. Shortly before the event: advertise!  Make sure people know about it
> and are excited to come.
> 3. During the event: someone to play host a bit and help people find
> something to do, and generally be helpful to anyone who is lost or
> confused.  That's not a role that I'm very good at, and I think it's more
> than a one-person job anyway.
>
>> _______________________________________________
> 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.



-- 
Amin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210624/27a867c7/attachment.html>

From capn.freako at gmail.com  Thu Jun 24 12:29:59 2021
From: capn.freako at gmail.com (David Banas)
Date: Thu, 24 Jun 2021 05:29:59 -0700
Subject: [Haskell-cafe] Cabal v misses changes to cxx-files: files?
Message-ID: <CADz=fO2mUa3DmGQRT8dc3pTkGi2iFx=m_y2AuM6fUimOdtZB=Q@mail.gmail.com>

Using Cabal v3.2.0.0 and with the following stanza in my *.cabal file:

executable ex9
  import: shared-properties
  main-is: src/ex/ex9.hs
  cxx-sources: src/ex/ex9.cpp
{snip}

if I edit the file: `src/ex/ex9.cpp`, and then execute: `cabal build`, I'm
told:

$ cabal build
Up to date

Is this a known issue?
Is there a workaround?

Thanks,
-db
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210624/95d871eb/attachment.html>

From mikolaj at well-typed.com  Thu Jun 24 12:47:12 2021
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Thu, 24 Jun 2021 14:47:12 +0200
Subject: [Haskell-cafe] Cabal v misses changes to cxx-files: files?
In-Reply-To: <CADz=fO2mUa3DmGQRT8dc3pTkGi2iFx=m_y2AuM6fUimOdtZB=Q@mail.gmail.com>
References: <CADz=fO2mUa3DmGQRT8dc3pTkGi2iFx=m_y2AuM6fUimOdtZB=Q@mail.gmail.com>
Message-ID: <CAHFo2uqQ8GLq04H+QE+RN_pFWM1iCvm0tOc+PHu0DqiaThPPXg@mail.gmail.com>

HI David,

It wouldn't hurt to try a newer cabal. I know a similar problem with
`extra-source-files` has been fixed recently.

If it still doesn't work in cabal 3.4, please search the issues and
file one or add a suitable emoji to an existing one.

Cheers,
Mikolaj

On Thu, Jun 24, 2021 at 2:30 PM David Banas <capn.freako at gmail.com> wrote:
>
> Using Cabal v3.2.0.0 and with the following stanza in my *.cabal file:
>
> executable ex9
>   import: shared-properties
>   main-is: src/ex/ex9.hs
>   cxx-sources: src/ex/ex9.cpp
> {snip}
>
> if I edit the file: `src/ex/ex9.cpp`, and then execute: `cabal build`, I'm told:
>
> $ cabal build
> Up to date
>
> Is this a known issue?
> Is there a workaround?
>
> Thanks,
> -db
>
> _______________________________________________
> 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 hjm0901 at gmail.com  Thu Jun 24 13:30:33 2021
From: hjm0901 at gmail.com (Jaemin Hong)
Date: Thu, 24 Jun 2021 22:30:33 +0900
Subject: [Haskell-cafe] ICFP 2021: Second Call for Students Volunteers
Message-ID: <ACE99F84-BD89-4742-A911-3E6987EFB0C5@gmail.com>

Please don't hesitate to share this information with your students,
classmates or colleagues!

ICFP'21 SECOND CALL FOR STUDENT VOLUNTEERS
=========================================

ICFP provides a forum for researchers and developers to hear about the
latest work on the design, implementations, principles, and uses of
functional programming. The conference covers the entire spectrum of work,
from practice to theory, including its peripheries. In order to smoothly
run the conference, associated workshops, and tutorials, we need student
volunteers to help out on the practical aspect of the organization. All the
events associated with ICFP'21 will take place **virtually** from Sun 22 -
Fri 27 August 2021.

Even though the event will be virtual, we will more than ever need the help
of student volunteers to make sure everything runs smoothly.
In return, as an ICFP 2021 student volunteer, you will get more visibility
and be able to interact closely with researchers, academics and
practitioners from various disciplines and discuss with other students from
around the world.

While the exact structure of the conference is still being discussed, job
assignments for student volunteers will probably include:
1- Assisting with technical sessions, workshops, tutorials, Q&A sessions,
social activities, and panels.
2- Helping to get authors' videos prepped and ready for broadcast.
3- Managing channels on a virtual event platform.

To be considered as a student volunteer for ICFP, please fill in the
following application form.

https://forms.gle/cEXE4GfXzm24f6mF6 <https://forms.gle/cEXE4GfXzm24f6mF6>

The permanent link to this form can be found on the official conference
website.

https://icfp21.sigplan.org/track/icfp-2021-student-volunteers <https://icfp21.sigplan.org/track/icfp-2021-student-volunteers>

There is one remaining round of a call with the following deadline:

* deadline for second round: July 16th, 2021 AoE (notification: July 20th)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210624/f70972cc/attachment.html>

From merijn at inconsistent.nl  Fri Jun 25 08:31:36 2021
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Fri, 25 Jun 2021 10:31:36 +0200
Subject: [Haskell-cafe] Cabal v misses changes to cxx-files: files?
In-Reply-To: <CAHFo2uqQ8GLq04H+QE+RN_pFWM1iCvm0tOc+PHu0DqiaThPPXg@mail.gmail.com>
References: <CADz=fO2mUa3DmGQRT8dc3pTkGi2iFx=m_y2AuM6fUimOdtZB=Q@mail.gmail.com>
 <CAHFo2uqQ8GLq04H+QE+RN_pFWM1iCvm0tOc+PHu0DqiaThPPXg@mail.gmail.com>
Message-ID: <BE72BEA7-5A9D-45BC-A284-1278C61D6D6B@inconsistent.nl>

Word of warning: The support for C++ in both cabal and GHC is currently at a level were it cannot be sanely used.

You can use it in the "mad cackling, slowly losing your mind too Lovecraftian horrors"-way, but if you care about things like "actually using the right C++ compiler" or "using the same C++ stdlib your other code was built with", you are as the professionals put it SOL.

- Merijn

> On 24 Jun 2021, at 14:47, Mikolaj Konarski <mikolaj at well-typed.com> wrote:
> 
> HI David,
> 
> It wouldn't hurt to try a newer cabal. I know a similar problem with
> `extra-source-files` has been fixed recently.
> 
> If it still doesn't work in cabal 3.4, please search the issues and
> file one or add a suitable emoji to an existing one.
> 
> Cheers,
> Mikolaj
> 
> On Thu, Jun 24, 2021 at 2:30 PM David Banas <capn.freako at gmail.com> wrote:
>> 
>> Using Cabal v3.2.0.0 and with the following stanza in my *.cabal file:
>> 
>> executable ex9
>>  import: shared-properties
>>  main-is: src/ex/ex9.hs
>>  cxx-sources: src/ex/ex9.cpp
>> {snip}
>> 
>> if I edit the file: `src/ex/ex9.cpp`, and then execute: `cabal build`, I'm told:
>> 
>> $ cabal build
>> Up to date
>> 
>> Is this a known issue?
>> Is there a workaround?
>> 
>> Thanks,
>> -db
>> 
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210625/2985122d/attachment.sig>

From cdsmith at gmail.com  Sat Jun 26 02:48:10 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Fri, 25 Jun 2021 22:48:10 -0400
Subject: [Haskell-cafe] Invitation: Virtual Haskell Cohack,
	July 10 (Saturday)
Message-ID: <CAPq5PvLzHBsEyQMzObWpmpequj5e+sF_m_wGVdFf2kRZFB=HHg@mail.gmail.com>

Hello everyone,

I'd like to formally invite you to the Virtual Haskell Cohack, which will
be running monthly beginning Saturday, July 10.  Please review times and
RSVP at https://www.meetup.com/NY-Haskell/events/279067287/ so that I know
how many people are coming.  I would need to upgrade my Zoom account if we
exceed 100 people, but that would be amazing.  Please make that happen!

This is an event for the Haskell community to get together and work on
collaborative projects.  This could mean:

   - Teaching or learning Haskell
   - Writing code or docs on your favorite project and introducing it to
   others
   - Learning about other people's projects and getting some mentorship to
   contribute.
   - Pair programming on programming challenges like Advent of Code or
   Project Euler.
   - Just hanging out and geeking out talking category theory or GHC
   profiling techniques or whatever.

The full agenda is listed at the link above, but it also includes lightning
talks, which you can propose when you RSVP or just wait and volunteer to
give one at the event.  If you want to be sure you make it on the list,
mention that you'd like to give a talk in your RSVP and you'll get priority
on the signup list.

Haskell-adjacent technologies are also welcome, so if you'd like to come
hack in Elm, Idris, Agda, Coq, Ocaml, or whatever, you are welcome.  The
only rule we have is to be kind and welcoming to others.

Thanks, and hope to see you there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210625/3e7ae567/attachment.html>

From cdsmith at gmail.com  Sat Jun 26 03:21:18 2021
From: cdsmith at gmail.com (Chris Smith)
Date: Fri, 25 Jun 2021 23:21:18 -0400
Subject: [Haskell-cafe] Invitation: Virtual Haskell Cohack,
	July 10 (Saturday)
In-Reply-To: <CAPq5PvLzHBsEyQMzObWpmpequj5e+sF_m_wGVdFf2kRZFB=HHg@mail.gmail.com>
References: <CAPq5PvLzHBsEyQMzObWpmpequj5e+sF_m_wGVdFf2kRZFB=HHg@mail.gmail.com>
Message-ID: <CAPq5PvLX=Z+nmLzZ7JFu7fBAiDn=SV4BEKe2t9g3U+ysJM_Ajg@mail.gmail.com>

I guess I should have said up-front that the scheduled times are likely to
work best for people in the Americas and Europe.  I'd love to see someone
set up an Asia/Australia friendly time, but I wouldn't be able to be there
as it would be in the middle of the night for me.

On Fri, Jun 25, 2021 at 10:48 PM Chris Smith <cdsmith at gmail.com> wrote:

> Hello everyone,
>
> I'd like to formally invite you to the Virtual Haskell Cohack, which will
> be running monthly beginning Saturday, July 10.  Please review times and
> RSVP at https://www.meetup.com/NY-Haskell/events/279067287/ so that I
> know how many people are coming.  I would need to upgrade my Zoom account
> if we exceed 100 people, but that would be amazing.  Please make that
> happen!
>
> This is an event for the Haskell community to get together and work on
> collaborative projects.  This could mean:
>
>    - Teaching or learning Haskell
>    - Writing code or docs on your favorite project and introducing it to
>    others
>    - Learning about other people's projects and getting some mentorship
>    to contribute.
>    - Pair programming on programming challenges like Advent of Code or
>    Project Euler.
>    - Just hanging out and geeking out talking category theory or GHC
>    profiling techniques or whatever.
>
> The full agenda is listed at the link above, but it also includes
> lightning talks, which you can propose when you RSVP or just wait and
> volunteer to give one at the event.  If you want to be sure you make it on
> the list, mention that you'd like to give a talk in your RSVP and you'll
> get priority on the signup list.
>
> Haskell-adjacent technologies are also welcome, so if you'd like to come
> hack in Elm, Idris, Agda, Coq, Ocaml, or whatever, you are welcome.  The
> only rule we have is to be kind and welcoming to others.
>
> Thanks, and hope to see you there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210625/77814aa2/attachment.html>

From capn.freako at gmail.com  Sat Jun 26 17:27:51 2021
From: capn.freako at gmail.com (David Banas)
Date: Sat, 26 Jun 2021 10:27:51 -0700
Subject: [Haskell-cafe] Why can't I seem to use environment variables in my
	cabal file?
Message-ID: <FA3DF2DA-67A8-4DB7-B542-8A13C88C19BB@gmail.com>

I’m trying to make use of an environment variable in my cabal file: ${ENV_VAR}, but I don’t think its value is getting used correctly. Is this a known issue? Workaround?

From mikolaj at well-typed.com  Sat Jun 26 18:04:52 2021
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Sat, 26 Jun 2021 20:04:52 +0200
Subject: [Haskell-cafe] Why can't I seem to use environment variables in
 my cabal file?
In-Reply-To: <FA3DF2DA-67A8-4DB7-B542-8A13C88C19BB@gmail.com>
References: <FA3DF2DA-67A8-4DB7-B542-8A13C88C19BB@gmail.com>
Message-ID: <CAHFo2up8ixkWrWRhSPe6vKoaJbPECXo=bEbssn3a=8A1Zfy11A@mail.gmail.com>

Hi David,

> I’m trying to make use of an environment variable in my cabal file: ${ENV_VAR}, but I don’t think its value is getting used correctly. Is this a known issue? Workaround?

I'd guess this was never implemented. A workaround would be running
your cabal files through a preprocessor, as part of your workflow.

I think the current effort to design and implement exact-print for
cabal files and the implied overhaul of cabal files AST and handling
will make this feature easier to implement:
https://github.com/haskell/cabal/projects/9

There is also a not entirely unrelated effort to affect cabal
behaviour via hooks: https://github.com/haskell/cabal/issues/7394

Contributions are very welcome.

Best regards,
Mikolaj

From capn.freako at gmail.com  Sat Jun 26 22:40:40 2021
From: capn.freako at gmail.com (David Banas)
Date: Sat, 26 Jun 2021 15:40:40 -0700
Subject: [Haskell-cafe] How to eliminate Cabal warning message,
 re: internal library version number?
Message-ID: <FBE085D4-C2B1-48B1-9D86-1F473CF981A2@gmail.com>

How do I eliminate these messages from my `cabal build` output?

Warning: The package has an extraneous version range for a dependency on an
internal library: {proj_name} >=0 && ==0.1.0.0. This version range includes the
current package but isn't needed as the current package's library will always
be used.


From capn.freako at gmail.com  Sat Jun 26 22:47:08 2021
From: capn.freako at gmail.com (David Banas)
Date: Sat, 26 Jun 2021 15:47:08 -0700
Subject: [Haskell-cafe] How to fix linker error on MacOS
Message-ID: <0A51BAB3-CD41-4C36-9D98-585E5ABB6F32@gmail.com>

How do I fix this (from `cabal build`)?

Undefined symbols for architecture x86_64:
  "___darwin_check_fd_set_overflow", referenced from:
      _awaitEvent in libHSrts.a(Select.o)

System Info:
=========

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.10.5

$ cabal --version
cabal-install version 3.4.0.0
compiled using version 3.4.0.0 of the Cabal library 

dbanas at Davids-MBP-2:~/Documents/Luminous/Projects/haskarch
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.6
BuildVersion:   18G9216


From ietf-dane at dukhovni.org  Sat Jun 26 22:52:43 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 26 Jun 2021 18:52:43 -0400
Subject: [Haskell-cafe] How to fix linker error on MacOS
In-Reply-To: <0A51BAB3-CD41-4C36-9D98-585E5ABB6F32@gmail.com>
References: <0A51BAB3-CD41-4C36-9D98-585E5ABB6F32@gmail.com>
Message-ID: <00C09D02-CF71-49DA-9213-D0349E769160@dukhovni.org>

from a recent rts/rts.cabal.in:

-- Note [fd_set_overflow]
-- ~~~~~~~~~~~~~~~~~~~~~~
-- In this note is the very sad tale of __darwin_fd_set_overflow.
-- The 8.10.5 release was broken because it was built in an environment
-- where the libraries were provided by XCode 12.*, these libraries introduced
-- a reference to __darwin_fd_set_overflow via the FD_SET macro which is used in
-- Select.c. Unfortunately, this symbol is not available with XCode 11.* which
-- led to a linker error when trying to link anything. This is almost certainly
-- a bug in XCode but we still have to work around it.
      
-- Undefined symbols for architecture x86_64:
--  "___darwin_check_fd_set_overflow", referenced from:
--      _awaitEvent in libHSrts.a(Select.o)
-- ld: symbol(s) not found for architecture x86_64

-- One way to fix this is to upgrade your version of xcode, but this would
-- force the upgrade on users prematurely. Fortunately it also seems safe to pass
-- the linker option "-Wl,-U,___darwin_check_fd_set_overflow" because the usage of
-- the symbol is guarded by a guard to check if it's defined.



> On 26 Jun 2021, at 6:47 pm, David Banas <capn.freako at gmail.com> wrote:
> 
> How do I fix this (from `cabal build`)?
> 
> Undefined symbols for architecture x86_64:
>  "___darwin_check_fd_set_overflow", referenced from:
>      _awaitEvent in libHSrts.a(Select.o)
> 
> System Info:
> =========
> 
> $ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 8.10.5
> 
> $ cabal --version
> cabal-install version 3.4.0.0
> compiled using version 3.4.0.0 of the Cabal library 
> 
> dbanas at Davids-MBP-2:~/Documents/Luminous/Projects/haskarch
> $ sw_vers
> ProductName:    Mac OS X
> ProductVersion: 10.14.6
> BuildVersion:   18G9216

-- 
	Viktor.


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sun Jun 27 07:24:30 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 27 Jun 2021 08:24:30 +0100
Subject: [Haskell-cafe] How to eliminate Cabal warning message,
 re: internal library version number?
In-Reply-To: <FBE085D4-C2B1-48B1-9D86-1F473CF981A2@gmail.com>
References: <FBE085D4-C2B1-48B1-9D86-1F473CF981A2@gmail.com>
Message-ID: <20210627072430.GA5616@cloudinit-builder>

On Sat, Jun 26, 2021 at 03:40:40PM -0700, David Banas wrote:
> How do I eliminate these messages from my `cabal build` output?
> 
> Warning: The package has an extraneous version range for a dependency on an
> internal library: {proj_name} >=0 && ==0.1.0.0. This version range includes the
> current package but isn't needed as the current package's library will always
> be used.

Presumably you remove the version bounds on that dependency.

From lemming at henning-thielemann.de  Sun Jun 27 07:52:13 2021
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 27 Jun 2021 09:52:13 +0200 (CEST)
Subject: [Haskell-cafe] How to eliminate Cabal warning message,
 re: internal library version number?
In-Reply-To: <20210627072430.GA5616@cloudinit-builder>
References: <FBE085D4-C2B1-48B1-9D86-1F473CF981A2@gmail.com>
 <20210627072430.GA5616@cloudinit-builder>
Message-ID: <82e4e290-aef7-e8bc-59bd-b10eba5562@henning-thielemann.de>


On Sun, 27 Jun 2021, Tom Ellis wrote:

> On Sat, Jun 26, 2021 at 03:40:40PM -0700, David Banas wrote:
>> How do I eliminate these messages from my `cabal build` output?
>> 
>> Warning: The package has an extraneous version range for a dependency on an
>> internal library: {proj_name} >=0 && ==0.1.0.0. This version range includes the
>> current package but isn't needed as the current package's library will always
>> be used.
>
> Presumably you remove the version bounds on that dependency.

That does not always help.

From lysxia at gmail.com  Sun Jun 27 12:13:22 2021
From: lysxia at gmail.com (Li-yao Xia)
Date: Sun, 27 Jun 2021 08:13:22 -0400
Subject: [Haskell-cafe] How to eliminate Cabal warning message,
 re: internal library version number?
In-Reply-To: <FBE085D4-C2B1-48B1-9D86-1F473CF981A2@gmail.com>
References: <FBE085D4-C2B1-48B1-9D86-1F473CF981A2@gmail.com>
Message-ID: <19d2a40d-bc86-97c2-a035-b0f3b69f6f7e@gmail.com>

This might be this known bug https://github.com/haskell/cabal/issues/5119

On 6/26/2021 6:40 PM, David Banas wrote:
> How do I eliminate these messages from my `cabal build` output?
> 
> Warning: The package has an extraneous version range for a dependency on an
> internal library: {proj_name} >=0 && ==0.1.0.0. This version range includes the
> current package but isn't needed as the current package's library will always
> be used.
> 
> _______________________________________________
> 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 leah at vuxu.org  Sun Jun 27 16:09:02 2021
From: leah at vuxu.org (Leah Neukirchen)
Date: Sun, 27 Jun 2021 18:09:02 +0200
Subject: [Haskell-cafe] Munich Virtual Haskell Meeting, 2021-06-29 @ 19:30
Message-ID: <87wnqfqogx.fsf@vuxu.org>

Dear all,

Next week, our monthly Munich Haskell Meeting will take place again
on Tuesday, June 29 on Jitsi at 19:30 CEST.

**Due to bad weather for meetings outside this meeting will take place online!**

For details see here:

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

A Jitsi 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 anthony.d.clayden at gmail.com  Mon Jun 28 06:17:42 2021
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Mon, 28 Jun 2021 18:17:42 +1200
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <CABU_mxjn-J8HsNP2VienZOrA4hsuDmN5vRbxpXjY3gfSPWY5mg@mail.gmail.com>
References: <CABU_mxjn-J8HsNP2VienZOrA4hsuDmN5vRbxpXjY3gfSPWY5mg@mail.gmail.com>
Message-ID: <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>

One of the annoying (to me) inconsistencies with Haskell syntax is that `[
]` means 'here comes a list'; but for the most common way to write a list,
you can't use `[  ]`:

>    elem x []        = False
>    elem x ( y: ys ) = ...

Prolog syntax has lists, signalled by `[   ]`: [], [1], [2, 3], [4, 5, 6],
[[7, 8], [9, 10, 11]] are all valid list literals. For cons it also uses
`[   ]` syntax

>    elem x [y | ys ] = ...

`[ x, y, z | zs ]` is also valid; pattern match or build a list with at
least 3 elements, where `zs` is the tail -- 4th element onwards (if any).
That structure is particularly ugly in Haskell syntax.

Neither `|` inside `[   ]` in a pattern nor a comma-list with `|` inside
`[   ]` is valid H98 syntax, nor valid in GHC extensions AFAICT.

In an expression, `[ x | xs ]` could be taken as a list comprehension,
which is I guess why Haskell didn't follow Prolog. I've come across another
theorem-prover that follows Prolog style, except it uses `:` instead of `|`
inside `[   ]`. Unfortunately ...

>    elem x [ y: ys ] = ...

Is valid syntax, where `:` is cons, so this is a nested list. I'm thinking
that's relatively uncommon, and means the same as `[ ( y: ys ) ]`.

Would anyone be violently pro or anti changing the meaning of `:` appearing
at top level in `[   ]` to mean cons-tail?

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

From isaace71295 at gmail.com  Mon Jun 28 06:30:04 2021
From: isaace71295 at gmail.com (Isaac Elliott)
Date: Mon, 28 Jun 2021 16:30:04 +1000
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>
References: <CABU_mxjn-J8HsNP2VienZOrA4hsuDmN5vRbxpXjY3gfSPWY5mg@mail.gmail.com>
 <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>
Message-ID: <CADNFHyNWLRHMb+PQWynQLtXoU0efKG1yXNk3zkpVhCSjeg5Jkw@mail.gmail.com>

I'd definitely be against what you propose; as you pointed out it
introduces a syntax ambiguity, which I think should be avoided where
possible.

On Mon, 28 Jun 2021, 4:19 pm Anthony Clayden, <anthony.d.clayden at gmail.com>
wrote:

>
> One of the annoying (to me) inconsistencies with Haskell syntax is that
> `[  ]` means 'here comes a list'; but for the most common way to write a
> list, you can't use `[  ]`:
>
> >    elem x []        = False
> >    elem x ( y: ys ) = ...
>
> Prolog syntax has lists, signalled by `[   ]`: [], [1], [2, 3], [4, 5, 6],
> [[7, 8], [9, 10, 11]] are all valid list literals. For cons it also uses
> `[   ]` syntax
>
> >    elem x [y | ys ] = ...
>
> `[ x, y, z | zs ]` is also valid; pattern match or build a list with at
> least 3 elements, where `zs` is the tail -- 4th element onwards (if any).
> That structure is particularly ugly in Haskell syntax.
>
> Neither `|` inside `[   ]` in a pattern nor a comma-list with `|` inside
> `[   ]` is valid H98 syntax, nor valid in GHC extensions AFAICT.
>
> In an expression, `[ x | xs ]` could be taken as a list comprehension,
> which is I guess why Haskell didn't follow Prolog. I've come across another
> theorem-prover that follows Prolog style, except it uses `:` instead of `|`
> inside `[   ]`. Unfortunately ...
>
> >    elem x [ y: ys ] = ...
>
> Is valid syntax, where `:` is cons, so this is a nested list. I'm thinking
> that's relatively uncommon, and means the same as `[ ( y: ys ) ]`.
>
> Would anyone be violently pro or anti changing the meaning of `:`
> appearing at top level in `[   ]` to mean cons-tail?
>
> AntC
> _______________________________________________
> 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/20210628/a27a69fa/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Mon Jun 28 11:09:59 2021
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 28 Jun 2021 13:09:59 +0200
Subject: [Haskell-cafe] Prolog-style list syntax?
Message-ID: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>

> `[ x, y, z | zs ]` is also valid; [...]
> That structure is particularly ugly in Haskell syntax.

how so?  `x : y : z : zs`

Prolog list syntax is ugly here because
the "cons" operator (|) needs special parentheses.

Well, a similar thing in Haskell ist the ".."
(enumFromTo) operator.

For syntactic generality, you could go full Agda
https://agda.readthedocs.io/en/v2.6.0.1/language/mixfix-operators.html
but I'm not sure whether brackets could be "name parts"

- J.W.

From migmit at gmail.com  Mon Jun 28 11:26:38 2021
From: migmit at gmail.com (MigMit)
Date: Mon, 28 Jun 2021 13:26:38 +0200
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
Message-ID: <1BC23326-CFEC-4453-BA6C-06EE2F42BF2E@gmail.com>

I did some work with Erlang, which uses Prolog-style syntax. I've always found this [H|T] to be confusing, since T is not an element of that list. But it could be because I've learned Haskell before Erlang.

> On 28 Jun 2021, at 13:09, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:
> 
>> `[ x, y, z | zs ]` is also valid; [...]
>> That structure is particularly ugly in Haskell syntax.
> 
> how so?  `x : y : z : zs`
> 
> Prolog list syntax is ugly here because
> the "cons" operator (|) needs special parentheses.
> 
> Well, a similar thing in Haskell ist the ".."
> (enumFromTo) operator.
> 
> For syntactic generality, you could go full Agda
> https://agda.readthedocs.io/en/v2.6.0.1/language/mixfix-operators.html
> but I'm not sure whether brackets could be "name parts"
> 
> - J.W.
> _______________________________________________
> 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 hecate at glitchbra.in  Mon Jun 28 11:31:02 2021
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 28 Jun 2021 13:31:02 +0200
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <1BC23326-CFEC-4453-BA6C-06EE2F42BF2E@gmail.com>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
 <1BC23326-CFEC-4453-BA6C-06EE2F42BF2E@gmail.com>
Message-ID: <ab595ed1-5f63-3301-fb9f-c8365fa42d21@glitchbra.in>

Having learned Erlang before Haskell, I recall having the opposite 
opinion at first. ;)

Le 28/06/2021 à 13:26, MigMit a écrit :
> I did some work with Erlang, which uses Prolog-style syntax. I've always found this [H|T] to be confusing, since T is not an element of that list. But it could be because I've learned Haskell before Erlang.
>
>> On 28 Jun 2021, at 13:09, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:
>>
>>> `[ x, y, z | zs ]` is also valid; [...]
>>> That structure is particularly ugly in Haskell syntax.
>> how so?  `x : y : z : zs`
>>
>> Prolog list syntax is ugly here because
>> the "cons" operator (|) needs special parentheses.
>>
>> Well, a similar thing in Haskell ist the ".."
>> (enumFromTo) operator.
>>
>> For syntactic generality, you could go full Agda
>> https://agda.readthedocs.io/en/v2.6.0.1/language/mixfix-operators.html
>> but I'm not sure whether brackets could be "name parts"
>>
>> - J.W.
>> _______________________________________________
>> 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.

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


From trebla at vex.net  Mon Jun 28 16:06:39 2021
From: trebla at vex.net (Albert Y. C. Lai)
Date: Mon, 28 Jun 2021 12:06:39 -0400
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>
References: <CABU_mxjn-J8HsNP2VienZOrA4hsuDmN5vRbxpXjY3gfSPWY5mg@mail.gmail.com>
 <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>
Message-ID: <ccc545ca-ec1e-54a2-7206-96c9c1f512a1@vex.net>

On 2021-06-28 2:17 a.m., Anthony Clayden wrote:
> Prolog syntax has lists, signalled by `[   ]`: [], [1], [2, 3], [4, 5, 
> 6], [[7, 8], [9, 10, 11]] are all valid list literals. For cons it also 
> uses `[   ]` syntax
> 
>  >    elem x [y | ys ] = ...
> 
> `[ x, y, z | zs ]` is also valid; pattern match or build a list with at 
> least 3 elements, where `zs` is the tail -- 4th element onwards (if 
> any). That structure is particularly ugly in Haskell syntax.

Prolog list syntax is the annoying one to me because it is watered down 
Hungarian notation again but with symbols instead of letters.  "If it's 
a string, prefix with sz; if it's a list, surround with []".

The logical conclusion of "elem : list" is

e1 : e2 : e3 : e4 : list

without needing a 2nd notation to make it nicer.

The logical conclusion of "[elem | list]" is

[e1 | [e2 | [e3 | [e4 | list]]]]

That's not nice. That explains why someone had to invent a 2nd notation, 
[e1, e2, e3, e4 | list].  Ironically, the need for a 2nd notation proves 
that the original "[elem | list]" design was ill-conceived.


From ietf-dane at dukhovni.org  Mon Jun 28 17:02:53 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 28 Jun 2021 13:02:53 -0400
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>
References: <CABU_mxjn-J8HsNP2VienZOrA4hsuDmN5vRbxpXjY3gfSPWY5mg@mail.gmail.com>
 <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>
Message-ID: <YNoAvUXKvd4DLC+F@straasha.imrryr.org>

On Mon, Jun 28, 2021 at 06:17:42PM +1200, Anthony Clayden wrote:

> One of the annoying (to me) inconsistencies with Haskell syntax is
> that `[]` means 'here comes a list'; but for the most common way to
> write a list, you can't use `[]`:
> 
> >    elem x []        = False
> >    elem x ( y : ys ) = ...

Yes, there's presently no way to pattern-match a list tail inside `[]`.

> Unfortunately ...
> 
> >    elem x [ y: ys ] = ...
> 
> Is valid syntax, where `:` is cons, so this is a nested list. I'm thinking
> that's relatively uncommon, and means the same as `[ ( y: ys ) ]`.
> 
> Would anyone be violently pro or anti changing the meaning of `:` appearing
> at top level in `[   ]` to mean cons-tail?

I'm on the violently against side on the question of `[x : ys]` being
reinterpreted as `(x : ys)`.  For any expression `e1, we have a
singleton `[e]`, and there should not be any surprising exceptions to
that rule.

If something new is to pattern match as `x : ys` inside `[]` it would
have to be invalid syntax presently.  So it could in principle be:

    [x,,ys]

but I'm concerned that this is too likely to be an inadvertent typo,
as in:

    [ x,
    , y ]

It is probably more useful to catch this sort of error, than to overload
the syntax for head + tail pattern matches.

So on the whole, I'm inclined to accept the status quo.  The annoyance,
if any, of having to use `(x : ys)` in pattern matches would not be
solved by adding a third syntax for lists.

-- 
    Viktor.

From jclites at mac.com  Mon Jun 28 18:04:46 2021
From: jclites at mac.com (Jeff Clites)
Date: Mon, 28 Jun 2021 11:04:46 -0700
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
Message-ID: <DD431AC5-8509-49C0-9377-EC7E45AC0A17@mac.com>

On Jun 28, 2021, at 4:09 AM, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> wrote:

>> `[ x, y, z | zs ]` is also valid; [...]
>> That structure is particularly ugly in Haskell syntax.
> 
> how so?  `x : y : z : zs`

I don’t mind the existing either, but it would be interesting if this worked:

    [x, y, z] ++ zs = list

But really, it redefines (++), so it has a different meaning already.

But you could imagine some special syntax “outside” the brackets, instead of inside.

Jeff

From ietf-dane at dukhovni.org  Mon Jun 28 18:15:49 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 28 Jun 2021 14:15:49 -0400
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <DD431AC5-8509-49C0-9377-EC7E45AC0A17@mac.com>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
 <DD431AC5-8509-49C0-9377-EC7E45AC0A17@mac.com>
Message-ID: <YNoR1Wu/JDCxiViJ@straasha.imrryr.org>

On Mon, Jun 28, 2021 at 11:04:46AM -0700, Jeff Clites via Haskell-Cafe wrote:

> > how so?  `x : y : z : zs`
> 
> I don’t mind the existing either, but it would be interesting if this worked:
> 
>     [x, y, z] ++ zs = list

It is far from clear why this or any similar pattern would be more
ergonomic than:

    x : y : z : zs

--
    Viktor.

From jaro.reinders at gmail.com  Mon Jun 28 18:22:00 2021
From: jaro.reinders at gmail.com (Jaro Reinders)
Date: Mon, 28 Jun 2021 20:22:00 +0200
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <YNoR1Wu/JDCxiViJ@straasha.imrryr.org>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
 <DD431AC5-8509-49C0-9377-EC7E45AC0A17@mac.com>
 <YNoR1Wu/JDCxiViJ@straasha.imrryr.org>
Message-ID: <58be7bf5-32e8-cdc6-a52b-a89c8f161413@gmail.com>

I have definitely wanted this for strings:

     "prefix" ++ xs = string

Is much better than:

     'p' : 'r' : 'e' : 'f' : 'i' : 'x' : xs = string


   Jaro

On 28-06-2021 20:15, Viktor Dukhovni wrote:
> On Mon, Jun 28, 2021 at 11:04:46AM -0700, Jeff Clites via Haskell-Cafe wrote:
> 
>>> how so?  `x : y : z : zs`
>>
>> I don’t mind the existing either, but it would be interesting if this worked:
>>
>>      [x, y, z] ++ zs = list
> 
> It is far from clear why this or any similar pattern would be more
> ergonomic than:
> 
>      x : y : z : zs
> 
> --
>      Viktor.
> _______________________________________________
> 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  Mon Jun 28 18:27:54 2021
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 28 Jun 2021 19:27:54 +0100
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <58be7bf5-32e8-cdc6-a52b-a89c8f161413@gmail.com>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
 <DD431AC5-8509-49C0-9377-EC7E45AC0A17@mac.com>
 <YNoR1Wu/JDCxiViJ@straasha.imrryr.org>
 <58be7bf5-32e8-cdc6-a52b-a89c8f161413@gmail.com>
Message-ID: <20210628182754.GA29903@cloudinit-builder>

Me too, but is it really worth breaking language consistency for
something that can be done as a library?

    Just xs = stripPrefix "prefix"

On Mon, Jun 28, 2021 at 08:22:00PM +0200, Jaro Reinders wrote:
> I have definitely wanted this for strings:
> 
>     "prefix" ++ xs = string
> 
> Is much better than:
> 
>     'p' : 'r' : 'e' : 'f' : 'i' : 'x' : xs = string
> 
> On 28-06-2021 20:15, Viktor Dukhovni wrote:
> > On Mon, Jun 28, 2021 at 11:04:46AM -0700, Jeff Clites via Haskell-Cafe wrote:
> > 
> > > > how so?  `x : y : z : zs`
> > > 
> > > I don’t mind the existing either, but it would be interesting if this worked:
> > > 
> > >      [x, y, z] ++ zs = list
> > 
> > It is far from clear why this or any similar pattern would be more
> > ergonomic than:
> > 
> >      x : y : z : zs

From capn.freako at gmail.com  Mon Jun 28 19:37:34 2021
From: capn.freako at gmail.com (David Banas)
Date: Mon, 28 Jun 2021 12:37:34 -0700
Subject: [Haskell-cafe] How to debug stack build failure?
Message-ID: <639BA03E-5270-4D5F-81BC-6C162B396A6E@gmail.com>

Anyone know how to start debugging this?

$ stack build
comonad       > configure
comonad       > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../haskeline-0.7.5.0/libHShaskeline-0.7.5.0-ghc8.8.4.so)
comonad       > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../ghc-8.8.4/libHSghc-8.8.4-ghc8.8.4.so)
comonad       > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../terminfo-0.4.1.4/libHSterminfo-0.4.1.4-ghc8.8.4.so)
comonad       > [1 of 2] Compiling Main             ( /tmp/stack-038db506ab1301e1/comonad-5.0.6/Setup.lhs, /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/Main.o )
comonad       > [2 of 2] Compiling StackSetupShim   ( /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/StackSetupShim.o )
comonad       > Linking /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup ...
Progress 1/10
Did not find executable at specified path: /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup


From whosekiteneverfly at gmail.com  Mon Jun 28 23:25:32 2021
From: whosekiteneverfly at gmail.com (YAMAMOTO Yuji)
Date: Tue, 29 Jun 2021 08:25:32 +0900
Subject: [Haskell-cafe] How to debug stack build failure?
In-Reply-To: <639BA03E-5270-4D5F-81BC-6C162B396A6E@gmail.com>
References: <639BA03E-5270-4D5F-81BC-6C162B396A6E@gmail.com>
Message-ID: <CA+6J5GGk9+EjsR+Po8WSeh84kAnqhNk8UyBqA7s19cJM9TpXdw@mail.gmail.com>

Try stack build -v firstable.

2021年6月29日(火) 4:38 David Banas <capn.freako at gmail.com>:

> Anyone know how to start debugging this?
>
> $ stack build
> comonad       > configure
> comonad       >
> /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc:
> /lib64/libtinfo.so.5: no version information available (required by
> /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../haskeline-0.7.5.0/
> libHShaskeline-0.7.5.0-ghc8.8.4.so)
> comonad       >
> /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc:
> /lib64/libtinfo.so.5: no version information available (required by
> /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../ghc-8.8.4/
> libHSghc-8.8.4-ghc8.8.4.so)
> comonad       >
> /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc:
> /lib64/libtinfo.so.5: no version information available (required by
> /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../terminfo-0.4.1.4/
> libHSterminfo-0.4.1.4-ghc8.8.4.so)
> comonad       > [1 of 2] Compiling Main             (
> /tmp/stack-038db506ab1301e1/comonad-5.0.6/Setup.lhs,
> /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/Main.o
> )
> comonad       > [2 of 2] Compiling StackSetupShim   (
> /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs,
> /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/StackSetupShim.o
> )
> comonad       > Linking
> /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup
> ...
> Progress 1/10
> Did not find executable at specified path:
> /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup
>
> _______________________________________________
> 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/20210629/52e4076f/attachment.html>

From jclites at mac.com  Tue Jun 29 05:57:16 2021
From: jclites at mac.com (Jeff Clites)
Date: Mon, 28 Jun 2021 22:57:16 -0700
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <YNoR1Wu/JDCxiViJ@straasha.imrryr.org>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
 <DD431AC5-8509-49C0-9377-EC7E45AC0A17@mac.com>
 <YNoR1Wu/JDCxiViJ@straasha.imrryr.org>
Message-ID: <F8F05EB0-5054-4D32-97D0-2F367AA83D0C@mac.com>

> On Jun 28, 2021, at 11:15 AM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Mon, Jun 28, 2021 at 11:04:46AM -0700, Jeff Clites via Haskell-Cafe wrote:
> 
>>> how so?  `x : y : z : zs`
>> 
>> I don’t mind the existing either, but it would be interesting if this worked:
>> 
>>    [x, y, z] ++ zs = list
> 
> It is far from clear why this or any similar pattern would be more
> ergonomic than:
> 
>    x : y : z : zs

The thread started with:

> One of the annoying (to me) inconsistencies with Haskell syntax is that `[  ]` means 'here comes a list'; but for the most common way to write a list, you can't use `[  ]`:
> 
> >    elem x []        = False
> >    elem x ( y: ys ) = ...

I sympathize with that observation, that there’s a special syntax for constructing lists, but you can’t use a similar syntax for the most common pattern-matching case (you can only use it for matching all elements of the list), and the special syntax is a nice visual signal that you are working with lists.

It’s not that x : y : z : zs is bad, it’s just not as distinctive. Someone thought it was worth inventing [a, b, c] even though you could just have written a : b : c : Nil, so similar motivations apply.

Something like this might work:

    [x, y, z, zs*] = list

But I actually like this the best:

    [x, y, z, zs...] = list

(The overlap with existing range syntax might actually be beneficial.)

Jeff

From johannes.waldmann at htwk-leipzig.de  Tue Jun 29 09:25:38 2021
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 29 Jun 2021 11:25:38 +0200
Subject: [Haskell-cafe] Prolog-style list syntax?
Message-ID: <5d4719a4-f011-e413-876a-676da1c4bcb9@htwk-leipzig.de>

>> but it would be interesting if this worked:
>>
>>    [x, y, z] ++ zs = list

this works in Curry; a functional-logic PL,
very roughly: Prolog semantics (in a sane way)
with Haskell syntax and typing

https://curry.pages.ps.informatik.uni-kiel.de/curry-lang.org/

- J.W.

From matthew at mattleach.net  Tue Jun 29 10:54:21 2021
From: matthew at mattleach.net (Matthew Leach)
Date: Tue, 29 Jun 2021 11:54:21 +0100
Subject: [Haskell-cafe] Help Improving Conduit Performance
Message-ID: <m25yxx4olo.fsf@matthews-air.1e0.uk>

Hi there!

I'm currently trying to write a program for the creation of IQ samples
from various sound files; AM is my current focus. This seems like a
really good application for the conduit library. I've so far got:

--8<---------------cut here---------------start------------->8---
run :: AMOptions -> IO ()
run opts = do
  (info, Just (aSamps :: SV.Buffer Float)) <- SF.readFile $ inputFile opts

  putStr "Processing samples... "
  hFlush stdout

  runConduitRes $ yieldMany (SV.fromBuffer aSamps)
               .| modulateAM (modIndex opts)
               .| zeroStuff (upsample opts)
               .| mapC renderSample
               .| unsafeBuilderToByteString
               .| sinkFile (outputFile opts)
--8<---------------cut here---------------end--------------->8---

However, this is *slow*. It takes over 40 seconds to run; I've
previously implemented the above without using streaming and this code
took approx 3 seconds to run with the same input.

I compiled the code for profiling and it appears as though the main
culprit is the function `injectLeftovers':

--8<---------------cut here---------------start------------->8---
        Mon Jun 28 22:55 2021 Time and Allocation Profiling Report  (Final)

           ayeQ +RTS -p -RTS am -i /Users/matthew/40.flac -o /Users/matthew/out.cfile -u 15 -m 150

        total time  =       76.32 secs   (76322 ticks @ 1000 us, 1 processor)
        total alloc = 445,275,685,456 bytes  (excludes profiling overheads)

COST CENTRE     MODULE                        SRC                                                    %time %alloc

injectLeftovers Data.Conduit.Internal.Pipe    src/Data/Conduit/Internal/Pipe.hs:(410,1)-(418,38)      79.5   81.6
runPipe         Data.Conduit.Internal.Pipe    src/Data/Conduit/Internal/Pipe.hs:(395,1)-(399,33)       7.1    5.0
awaitForever    Data.Conduit.Internal.Conduit src/Data/Conduit/Internal/Conduit.hs:(950,1)-(952,10)    5.3    3.7
run             AM                            AM.hs:(62,1)-(77,88)                                     4.4    7.0
renderSample    Render                        Render.hs:8:1-58                                         3.5    2.5
--8<---------------cut here---------------end--------------->8---

I'm at a bit of a loss as to where to start looking for why this
particlar function is using so many resources, or which part of the
pipeline is causing the issue. The custom pieces of code that I've got
in the pipeline are:

--8<---------------cut here---------------start------------->8---
modulateAM' :: Int -> Float -> IQ
modulateAM' modIdx s = (base + amp) :+ 0.0
  where x = fromIntegral modIdx / 200
        amp = s * x
        base = 1 - x

modulateAM :: Monad m => Int -> ConduitT Float IQ m ()
modulateAM = mapC . modulateAM'
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
zeroStuff :: Monad m => Int -> ConduitT IQ  IQ  m ()
zeroStuff factor = awaitForever (\v -> yield v >>
                                  replicateM_ (factor - 1) (yield zero))
  where zero = 0 :+ 0
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
renderSample :: IQ -> Builder
renderSample (real :+ imag) = floatLE real <> floatLE imag
--8<---------------cut here---------------end--------------->8---

Any help would be appreciated!

Regards,
-- 
Matt

From anthony.d.clayden at gmail.com  Tue Jun 29 11:01:29 2021
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Tue, 29 Jun 2021 23:01:29 +1200
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
Message-ID: <CABU_mxhS=EEtXEPUKuZ-EZMX8kYKUQo+bd30nydXQ03irms=eA@mail.gmail.com>

On Mon, 28 Jun 2021 at 23:20, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> > `[ x, y, z | zs ]` is also valid; [...]
> > That structure is particularly ugly in Haskell syntax.
>
> how so?  `x : y : z : zs`
>
>
Because almost always you need to put parens round -- certainly in a
pattern match.

And it's not square brackets, which would say 'here comes a list'.


> Prolog list syntax is ugly here because
> the "cons" operator (|) needs special parentheses.
>

Exactly! Special list-heralding brackets.


>
> Well, a similar thing in Haskell ist the ".."
> (enumFromTo) operator.
>
>
@Jeff But I actually like this the best:
> [x, y, z, zs...] = list
>

Or maybe

>   [x, y, z, zs at ..] = list

Could be an as-pattern binding to the tail. But now it's getting
heavyweight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210629/f80c15d4/attachment.html>

From anthony.d.clayden at gmail.com  Tue Jun 29 11:18:02 2021
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Tue, 29 Jun 2021 23:18:02 +1200
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <ccc545ca-ec1e-54a2-7206-96c9c1f512a1@vex.net>
References: <CABU_mxjn-J8HsNP2VienZOrA4hsuDmN5vRbxpXjY3gfSPWY5mg@mail.gmail.com>
 <CABU_mxgDLWt56gGKs0mnOPjv9bxGOfPgoibUiidRXzK=GWwHBg@mail.gmail.com>
 <ccc545ca-ec1e-54a2-7206-96c9c1f512a1@vex.net>
Message-ID: <CABU_mxiMrRfOezdZKaPOa3RMc3FtUnv9PXtkMzz4cZa0Z6zjpQ@mail.gmail.com>

On Tue, 29 Jun 2021 at 04:07, Albert Y. C. Lai <trebla at vex.net> wrote:

>
> The logical conclusion of "elem : list" is
>
> e1 : e2 : e3 : e4 : list
>
> without needing a 2nd notation to make it nicer.
>
>
(As I said up-thread you almost always need to add the parens notation --
not to make it "nicer", but to make it parse correctly.)

I appreciate syntax is a matter of personal taste, but my taste prefers the
brackets and commas.


> The logical conclusion of "[elem | list]" is
>
> [e1 | [e2 | [e3 | [e4 | list]]]]
>
> That's not nice.


Quite often `e1:e2:e3:e4:list` won't work, because the expressions have
infix operators. So you end up with

>    (e1: (e2: (e3: (e4: list))))

So you still have to squint to make sure the parens balance.


> That explains why someone had to invent a 2nd notation,
> [e1, e2, e3, e4 | list].


Sure. The commas form is a shorthand. Just like

>    (e1, e2, e3, e4)    is shorthand for (,,,) e1 e2 e3 e4
>    e1 + e2 * e3           is shorthand for  (+) e1 ((*) e2 e3)


> Ironically, the need for a 2nd notation proves
> that the original "[elem | list]" design was ill-conceived.
>
>
So which form of tuple syntax do you think is ill-conceived?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210629/fa321beb/attachment.html>

From capn.freako at gmail.com  Tue Jun 29 13:11:09 2021
From: capn.freako at gmail.com (David Banas)
Date: Tue, 29 Jun 2021 06:11:09 -0700
Subject: [Haskell-cafe] [Haskell Cafe] How to debug stack build failure?
	(YAMAMOTO Yuji)
In-Reply-To: <mailman.1.1624968001.6773.haskell-cafe@haskell.org>
References: <mailman.1.1624968001.6773.haskell-cafe@haskell.org>
Message-ID: <194840E8-5E77-499E-9E59-782B487D466B@gmail.com>

$ stack build -v
Version 2.7.1, Git revision 8afe0c2932716b0441cf4440d6942c59568b6b19 x86_64 hpack-0.34.4
{snip}
2021-06-28 16:20:17.903335: [info] comonad       > configure
2021-06-28 16:20:17.905709: [debug] Run process within /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/: /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/bin/ghc-8.8.4 --make -odir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -hidir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -i -i. -clear-package-db -global-package-db -package-db=/home/david/.stack/snapshots/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -package-db=/home/david/prj/haskarch/.stack-work/install/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -hide-all-packages -package-id=Cabal-3.0.1.0 -package-id=base-4.13.0.0 -package-id=cabal-doctest-1.0.8-2wQRz9ec1yB5lMDRmEgBWB -optP-include -optP/tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup_macros.h /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/Setup.lhs /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup -threaded
2021-06-28 16:20:17.943489: [warn] comonad       > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../haskeline-0.7.5.0/libHShaskeline-0.7.5.0-ghc8.8.4.so)
2021-06-28 16:20:17.944049: [warn] comonad       > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../ghc-8.8.4/libHSghc-8.8.4-ghc8.8.4.so)
2021-06-28 16:20:17.944266: [warn] comonad       > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../terminfo-0.4.1.4/libHSterminfo-0.4.1.4-ghc8.8.4.so)
2021-06-28 16:20:18.075957: [info] comonad       > [1 of 2] Compiling Main             ( /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/Setup.lhs, /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/Main.o )
2021-06-28 16:20:18.195209: [info] comonad       > [2 of 2] Compiling StackSetupShim   ( /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/StackSetupShim.o )
2021-06-28 16:20:18.353001: [info] comonad       > Linking /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup ...
2021-06-28 16:20:20.173612: [debug] Process finished in 2267ms: /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/bin/ghc-8.8.4 --make -odir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -hidir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -i -i. -clear-package-db -global-package-db -package-db=/home/david/.stack/snapshots/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -package-db=/home/david/prj/haskarch/.stack-work/install/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -hide-all-packages -package-id=Cabal-3.0.1.0 -package-id=base-4.13.0.0 -package-id=cabal-doctest-1.0.8-2wQRz9ec1yB5lMDRmEgBWB -optP-include -optP/tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup_macros.h /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/Setup.lhs /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup -threaded
Progress 1/10
2021-06-28 16:20:20.191005: [error] Did not find executable at specified path: /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup



> On Jun 29, 2021, at 5:00 AM, haskell-cafe-request at haskell.org wrote:
> 
> Try stack build -v firstable.

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

From sjcjoosten+haskell at gmail.com  Tue Jun 29 16:01:43 2021
From: sjcjoosten+haskell at gmail.com (Sebastiaan Joosten)
Date: Tue, 29 Jun 2021 12:01:43 -0400
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <CABU_mxhS=EEtXEPUKuZ-EZMX8kYKUQo+bd30nydXQ03irms=eA@mail.gmail.com>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
 <CABU_mxhS=EEtXEPUKuZ-EZMX8kYKUQo+bd30nydXQ03irms=eA@mail.gmail.com>
Message-ID: <CABhTcUu-ucDaasC3wxBynSk=Fwh5Lk9-CKTj4BZxYPXQY_sypw@mail.gmail.com>

On Tue, Jun 29, 2021 at 7:05 AM Anthony Clayden <anthony.d.clayden at gmail.com>
wrote:

>
> Because almost always you need to put parens round -- certainly in a
> pattern match.
>
>
This is an interesting point, and for the sake of having an
unambiguous parser, I don't think this requirement is needed: The arity of
all constructors is known, all constructors must have all of its arguments
(no currying in patterns), so Polish notation should suffice and
parentheses could be optional (an implementer would need to delay parsing
of anything to the lhs of an <- or = until all constructors are known).
With infix operators (`a:b:c` should not be parsed as `(a:b):c`) we simply
take fixity into. To a certain extent Haskell already does this, the
following works:

infixr 3 `member`

a `member` []                  = False

a `member` b : bs | b==a       = True

                  | otherwise  = a `member` bs

To make this work in general, any function symbols on the lhs of an = (and
their respective function application) should have the lowest precedence,
and constructor 'application' through spaces would seem to go in the
opposite direction of what is common. Following this convention, we could
have this amusing looking definition in the Prelude:
x:xs++ys = x:xs++ys
On the lhs, since ++ is not a constructor, it is the symbol that is being
defined and therefore of lowest precedence, so the lhs would read
(x:xs)++ys. On the rhs, (:) and (++) are infixr 5, so the rhs reads as
x:(xs++ys).
Just to be clear: none of this is a proposal, I would not be in favor of
this as I prefer consistency.

As to the original question: I see no technical issues in allowing
something like `[ x, y || ys]` as syntax for `(x:y:ys)`, or using any new
symbol in place of ||. As others have pointed out, we cannot have all three
of:
- `[ expr ]` stands for singleton list elements (as currently the case)
- keep the current meaning of `x : xs`
- let `[ x : xs ]` be 'shorthand' for `x:xs`
>From a Prolog perspective, dropping `x : xs` may seem the way to go
(arguments like: "in many patterns we need parentheses anyways" seem to
agree with this view), but Haskell code has `foo x y` instead of
`foo(x,y)`, and infix syntax follows the same principle: outer parentheses
are optional. Prolog follows the same principle for +, *, -, =, etc, just
not for relations.

Would I be violently against even something mild like the introduction of
`[ x,y || ys ]`? Not violently so but definitely fiercely, unless this is
tucked away behind a flag. I see it as pointless, wouldn't use it, and I
don't care to explain it to my students (or at least those who don't know
Prolog) either, and it would reduce 3rd party code readability because
there would now be two ways of writing the same thing, neither of which is
entirely obvious. In a new / different language I'd love to see all these
weird ideas tried out. Sometimes odd conventions (such as writing `foo x y`
instead of `foo(x,y)`) grow on me and I start to like them. A good place to
start might be to add outer parentheses to your language to distinguish `[x
: xs]` from `[(x : xs)]`, forbidding `x : xs`. This would be LISP with
infix notations and static typing... that actually sounds like it could be
nice.

While we're on the topic of changing list syntax, some more ideas that
might make sense (but are not a proposal!!):
 `[ x,y | binders ]`  as syntax for:  `concat [ [x,y] | binders ]`
 `[ x ..< y ]` as syntax for `FromEnumToExclusive x y` (i.e. `if x==y then
[] else [x..pred y]` by default), Isabelle/HOL has this.
 A keyword `get` in addition to `let` s.t. `[x | get Just x = y]` is syntax
for `[x | Just x <- [y]]` (using let produces a pattern match failure if
y=Nothing).
 While we're at it: `do {get Just x = ys; continuation}` as syntax for `do
{Just x <- return ys; continuation}`.
 `[ x | xs <- as; x <- xs]` as syntax for: `[x | xs <- as, x <- xs]` (the ;
would have the binders behave like `do-syntax`).
 While we're at it: `[ expr | binders]` as syntax for: `do {binders;return
expr} :: (Listlike f => f b)` with `default Listlike ([])`.
 Finally, `do {(binders1 | binders2) ; continuation}` could be syntax for:
`Data.Zip.zipWith (\x y -> continuation) (do binders1;return x) (do
binders2; return y)` (as inspired by parallel list comprehensions).

It's fun to think about these things, but each of these ideas comes with
syntactic change and therefore yet another language construct to learn.
Since syntax cannot be found on hoogle
<https://hoogle.haskell.org/?hoogle=..> and even google <http://what does
.. mean in haskell>, all of these things generally increase the burden to
the reader of your code, which is why none of this is a proposal.

Best,
Sebastiaan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210629/7219a27b/attachment.html>

From ietf-dane at dukhovni.org  Tue Jun 29 17:36:13 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 29 Jun 2021 13:36:13 -0400
Subject: [Haskell-cafe] Prolog-style list syntax?
In-Reply-To: <F8F05EB0-5054-4D32-97D0-2F367AA83D0C@mac.com>
References: <2ed87bea-af02-61f5-e086-c3117d6db2ba@htwk-leipzig.de>
 <DD431AC5-8509-49C0-9377-EC7E45AC0A17@mac.com>
 <YNoR1Wu/JDCxiViJ@straasha.imrryr.org>
 <F8F05EB0-5054-4D32-97D0-2F367AA83D0C@mac.com>
Message-ID: <YNtaDeF3/Zgbs7ZC@straasha.imrryr.org>

On Mon, Jun 28, 2021 at 10:57:16PM -0700, Jeff Clites via Haskell-Cafe wrote:

> Something like this might work:
> 
>     [x, y, z, zs*] = list

But it could be that "*" in this context is defined as a postfix unary
operator, and "zs*" is just another element.

> But I actually like this the best:
> 
>     [x, y, z, zs...] = list

Same here with "...".  Neither "*" nor "..." is built in to Haskell
as a reserved operator.

-- 
    Viktor.

From borgauf at gmail.com  Tue Jun 29 22:39:42 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Tue, 29 Jun 2021 17:39:42 -0500
Subject: [Haskell-cafe] Using Data.String.Conversions
Message-ID: <CAFAhFSXUp71cROuBq2xwvJjooiUDctquJQKYBkY5WzxburkqYg@mail.gmail.com>

I would simply like to use Data.String.Conversions, specifically the
cs function
while I'm in my global ghci REPL. Here's the code I'm working on (from here
<https://zacwood.me/posts/2020-12-29-dates-ihp/>)

parseDay' :: String -> Maybe Day
parseDay' = parseTimeM True defaultTimeLocale "%Y-%m-%d"

then

mydate = getCurrentTime

(Data.Time imported just fine.)

parseDay' $ takeWhile ('T' /=) (cs mydate)

My problem is I can import and expose Data.Time, but Data.String.Conversions
will not import to my global REPL. Any tips on doing this project-based
would be enlightening too.


⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210629/7c66f3ca/attachment.html>

From ietf-dane at dukhovni.org  Tue Jun 29 23:38:29 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 29 Jun 2021 19:38:29 -0400
Subject: [Haskell-cafe] Using Data.String.Conversions
In-Reply-To: <CAFAhFSXUp71cROuBq2xwvJjooiUDctquJQKYBkY5WzxburkqYg@mail.gmail.com>
References: <CAFAhFSXUp71cROuBq2xwvJjooiUDctquJQKYBkY5WzxburkqYg@mail.gmail.com>
Message-ID: <YNuu9WV/Psyu85WQ@straasha.imrryr.org>

On Tue, Jun 29, 2021 at 05:39:42PM -0500, Galaxy Being wrote:

> My problem is I can import and expose Data.Time, but
> Data.String.Conversions will not import to my global REPL. Any tips on
> doing this project-based would be enlightening too.

One thing that works is:

    $ cabal -z install --lib string-conversions
    Resolving dependencies...
    ...
    In order, the following will be built (use -v for more details):
     - utf8-string-1.0.2 (lib) (requires build)
     - string-conversions-0.4.0.1 (lib) (requires download & build)
    Completed    utf8-string-1.0.2 (lib)
    ...
    Completed    string-conversions-0.4.0.1 (lib)

    $ cabal repl -z
    λ> :set -package string-conversions
    package flags have changed, resetting and loading new packages...
    λ> import Data.String.Conversions as CS
    λ> :t cs
    cs :: ConvertibleStrings a b => a -> b
    λ>

There are surely other ways, that you might prefer, but this should get
you started.

-- 
    Viktor.

From borgauf at gmail.com  Wed Jun 30 03:18:47 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Tue, 29 Jun 2021 22:18:47 -0500
Subject: [Haskell-cafe] Using Data.String.Conversions
In-Reply-To: <YNuu9WV/Psyu85WQ@straasha.imrryr.org>
References: <CAFAhFSXUp71cROuBq2xwvJjooiUDctquJQKYBkY5WzxburkqYg@mail.gmail.com>
 <YNuu9WV/Psyu85WQ@straasha.imrryr.org>
Message-ID: <CAFAhFSXPR_vCzKp6X4uKZpPk7Zkzf38FrxVhY0bw97Am==WFrg@mail.gmail.com>

Sorry, but this didn't work for me. First,

$ cabal -z install --lib string-conversions
cabal: unrecognized 'install' option `-z'

however, without -z it does run and performs an install as you indicate . .
. but then the rest doesn't work, i.e.,

$ cabal repl -z
> :set -package string-conversions
<no location info>: error:
    Could not load module ‘Data.String.Conversions’
    It is a member of the hidden package ‘string-conversions-0.4.0.1’.
    Perhaps you need to add ‘string-conversions’ to the build-depends in
your .cabal file.

However, this did work

$ stack install string-conversions
tf8-string       > using precompiled package
string-conversions> configure
string-conversions> Configuring string-conversions-0.4.0.1...
string-conversions> build
string-conversions> Preprocessing library for string-conversions-0.4.0.1..
string-conversions> Building library for string-conversions-0.4.0.1..
string-conversions> [1 of 2] Compiling Data.String.Conversions
...

then

$ stack ghci --package string-conversions
...

Prelude> import Data.String.Conversions as CS

Prelude CS> :t cs
cs :: ConvertibleStrings a b => a -> b

*But*, now I am able to follow your cabal way and it does work.

So this is very confusing for a beginner. But happy ending this time. Any
lessons I can learn from this? For example, why was this so difficult?


On Tue, Jun 29, 2021 at 6:44 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Tue, Jun 29, 2021 at 05:39:42PM -0500, Galaxy Being wrote:
>
> > My problem is I can import and expose Data.Time, but
> > Data.String.Conversions will not import to my global REPL. Any tips on
> > doing this project-based would be enlightening too.
>
> One thing that works is:
>
>     $ cabal -z install --lib string-conversions
>     Resolving dependencies...
>     ...
>     In order, the following will be built (use -v for more details):
>      - utf8-string-1.0.2 (lib) (requires build)
>      - string-conversions-0.4.0.1 (lib) (requires download & build)
>     Completed    utf8-string-1.0.2 (lib)
>     ...
>     Completed    string-conversions-0.4.0.1 (lib)
>
>     $ cabal repl -z
>     λ> :set -package string-conversions
>     package flags have changed, resetting and loading new packages...
>     λ> import Data.String.Conversions as CS
>     λ> :t cs
>     cs :: ConvertibleStrings a b => a -> b
>     λ>
>
> There are surely other ways, that you might prefer, but this should get
> you started.
>
> --
>     Viktor.
> _______________________________________________
> 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.



-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210629/99b0f2be/attachment.html>

From ietf-dane at dukhovni.org  Wed Jun 30 03:35:50 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 29 Jun 2021 23:35:50 -0400
Subject: [Haskell-cafe] Using Data.String.Conversions
In-Reply-To: <CAFAhFSXPR_vCzKp6X4uKZpPk7Zkzf38FrxVhY0bw97Am==WFrg@mail.gmail.com>
References: <CAFAhFSXUp71cROuBq2xwvJjooiUDctquJQKYBkY5WzxburkqYg@mail.gmail.com>
 <YNuu9WV/Psyu85WQ@straasha.imrryr.org>
 <CAFAhFSXPR_vCzKp6X4uKZpPk7Zkzf38FrxVhY0bw97Am==WFrg@mail.gmail.com>
Message-ID: <YNvmloEVKAeIJgIu@straasha.imrryr.org>

On Tue, Jun 29, 2021 at 10:18:47PM -0500, Galaxy Being wrote:

> Sorry, but this didn't work for me. First,
> 
> $ cabal -z install --lib string-conversions
> cabal: unrecognized 'install' option `-z'

You must have a materially older version of cabal-install than I do.
The "-z" option makes "cabal" ignore any local ".cabal" or
"cabal.project" files, and operate in the "global" project.

>From "cabal install --help":

     ...
     -z --ignore-project           Ignore local project configuration
     ...

If I previously wrote "cabal -z install ...", the more strictly correct
syntax would probably be "cabal install -z ...", perhaps your version
of cabal supports the latter (but quite possibly neither).

> $ cabal repl -z
> > :set -package string-conversions
> <no location info>: error:
>     Could not load module ‘Data.String.Conversions’
>     It is a member of the hidden package ‘string-conversions-0.4.0.1’.
>     Perhaps you need to add ‘string-conversions’ to the build-depends in your .cabal file.

Something is missing from the above.  I see no attempt to load the
module, and yet an error about failure to load it.  If "cabal repl" did
accept the "-z" option,

> $ stack install string-conversions
> 
> then
> 
> $ stack ghci --package string-conversions
>
> [...]
>
> *But*, now I am able to follow your cabal way and it does work.
> 
> So this is very confusing for a beginner. But happy ending this time. Any
> lessons I can learn from this? For example, why was this so difficult?

It is tricky because cabal operates in a sanboxed mode by default, and
because GHC and GHCi don't by default have any knowledge of cabal's
package store.  The Haskell tool chain is somewhat fragmented, but IIRC
there are plans afoot to reduce some of the friction.

I use Cabal 3.4, and it does what I need.  Others use stack which meets
their needs.  GHC is agnostic, and ghci mostly knows just about the
packages bundled with GHC, except when cabal or stack create GHC
"environment" files that specify the package-db locations which GHC
is then able to use.

Someone else who understands the space better may be able to give a more
detailed answer, and perhaps share any plans to improve toolchain
integration.

-- 
    Viktor.

From borgauf at gmail.com  Wed Jun 30 04:37:01 2021
From: borgauf at gmail.com (Galaxy Being)
Date: Tue, 29 Jun 2021 23:37:01 -0500
Subject: [Haskell-cafe] Using Data.String.Conversions
In-Reply-To: <YNvmloEVKAeIJgIu@straasha.imrryr.org>
References: <CAFAhFSXUp71cROuBq2xwvJjooiUDctquJQKYBkY5WzxburkqYg@mail.gmail.com>
 <YNuu9WV/Psyu85WQ@straasha.imrryr.org>
 <CAFAhFSXPR_vCzKp6X4uKZpPk7Zkzf38FrxVhY0bw97Am==WFrg@mail.gmail.com>
 <YNvmloEVKAeIJgIu@straasha.imrryr.org>
Message-ID: <CAFAhFSVv4LDb6E=abOY98sRRXp0_zwdRNkMUEYQgUwNz6hZYCw@mail.gmail.com>

There's this devilish thing where an initial install of cabal goes to
/usr/bin/cabal, but then a subsequent update

$ cabal install cabal-install

puts things in my ~/.cabal/bin/

Once I adjusted my PATH to go to ~/.cabal/bin/cabal first, then

cabal -z install --lib string-conversions

works with the -z. And now everything works accordingly. My /usr/bin/cabal
was version 3.0...



On Tue, Jun 29, 2021 at 10:40 PM Viktor Dukhovni <ietf-dane at dukhovni.org>
wrote:

> On Tue, Jun 29, 2021 at 10:18:47PM -0500, Galaxy Being wrote:
>
> > Sorry, but this didn't work for me. First,
> >
> > $ cabal -z install --lib string-conversions
> > cabal: unrecognized 'install' option `-z'
>
> You must have a materially older version of cabal-install than I do.
> The "-z" option makes "cabal" ignore any local ".cabal" or
> "cabal.project" files, and operate in the "global" project.
>
> From "cabal install --help":
>
>      ...
>      -z --ignore-project           Ignore local project configuration
>      ...
>
> If I previously wrote "cabal -z install ...", the more strictly correct
> syntax would probably be "cabal install -z ...", perhaps your version
> of cabal supports the latter (but quite possibly neither).
>
> > $ cabal repl -z
> > > :set -package string-conversions
> > <no location info>: error:
> >     Could not load module ‘Data.String.Conversions’
> >     It is a member of the hidden package ‘string-conversions-0.4.0.1’.
> >     Perhaps you need to add ‘string-conversions’ to the build-depends in
> your .cabal file.
>
> Something is missing from the above.  I see no attempt to load the
> module, and yet an error about failure to load it.  If "cabal repl" did
> accept the "-z" option,
>
> > $ stack install string-conversions
> >
> > then
> >
> > $ stack ghci --package string-conversions
> >
> > [...]
> >
> > *But*, now I am able to follow your cabal way and it does work.
> >
> > So this is very confusing for a beginner. But happy ending this time. Any
> > lessons I can learn from this? For example, why was this so difficult?
>
> It is tricky because cabal operates in a sanboxed mode by default, and
> because GHC and GHCi don't by default have any knowledge of cabal's
> package store.  The Haskell tool chain is somewhat fragmented, but IIRC
> there are plans afoot to reduce some of the friction.
>
> I use Cabal 3.4, and it does what I need.  Others use stack which meets
> their needs.  GHC is agnostic, and ghci mostly knows just about the
> packages bundled with GHC, except when cabal or stack create GHC
> "environment" files that specify the package-db locations which GHC
> is then able to use.
>
> Someone else who understands the space better may be able to give a more
> detailed answer, and perhaps share any plans to improve toolchain
> integration.
>
> --
>     Viktor.
> _______________________________________________
> 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.



-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borgauf at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210629/db3d4358/attachment.html>

From anthony.d.clayden at gmail.com  Wed Jun 30 07:00:45 2021
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Wed, 30 Jun 2021 19:00:45 +1200
Subject: [Haskell-cafe] Prolog-style list syntax?
Message-ID: <CABU_mxgyrTQqz7aTNNubFtp5wQhqD7WN_V0Q2Qio_0f1K3di+Q@mail.gmail.com>

Ok thank you for the feedback, I get the message not to re-purpose
currently valid syntax.

For that reason, this won't fly:

I see no technical issues in allowing
> something like `[ x, y || ys]`


`||` is already an operator in the Prelude.

>    [x, y ,: ys ]           -- ? not currently valid

We could make list syntax work harder

>    [x, y ,:+ ys ]

Means desugar the commas by applying constructor `:+` instead of `:`. That
could be in general any constructor starting `:`.

Or indeed could be a pattern synonym starting `:`, which is a 'smart
constructor' to build the list maintaining some invariant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210630/3c06b1fd/attachment.html>

From jclites at mac.com  Wed Jun 30 07:45:05 2021
From: jclites at mac.com (Jeff Clites)
Date: Wed, 30 Jun 2021 00:45:05 -0700
Subject: [Haskell-cafe] Using Data.String.Conversions
In-Reply-To: <CAFAhFSXPR_vCzKp6X4uKZpPk7Zkzf38FrxVhY0bw97Am==WFrg@mail.gmail.com>
References: <CAFAhFSXUp71cROuBq2xwvJjooiUDctquJQKYBkY5WzxburkqYg@mail.gmail.com>
 <YNuu9WV/Psyu85WQ@straasha.imrryr.org>
 <CAFAhFSXPR_vCzKp6X4uKZpPk7Zkzf38FrxVhY0bw97Am==WFrg@mail.gmail.com>
Message-ID: <E2C2995D-C82E-4F29-ADC1-98277795E33A@mac.com>

> On Jun 29, 2021, at 8:18 PM, Galaxy Being <borgauf at gmail.com> wrote:
> 
> So this is very confusing for a beginner. But happy ending this time. Any lessons I can learn from this? For example, why was this so difficult?

All you needed to do is the following, and nothing else (no directly invoking cabal, etc.):

> $ stack ghci --package string-conversions

I tried it just now and it works.

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

From gershomb at gmail.com  Wed Jun 30 12:31:56 2021
From: gershomb at gmail.com (Gershom B)
Date: Wed, 30 Jun 2021 08:31:56 -0400
Subject: [Haskell-cafe] Spam Control
In-Reply-To: <CACZKWELWYcauDTa37g7AN-xUjps-t5nU+=SgOuSMk7ASjvoC=g@mail.gmail.com>
References: <008901d76caf$8c756760$a5603620$@confscience.com>
 <CACZKWELWYcauDTa37g7AN-xUjps-t5nU+=SgOuSMk7ASjvoC=g@mail.gmail.com>
Message-ID: <9724f79b-4157-4610-8e26-e6e723c76cfe@Spark>

On Jun 29, 2021, 4:57 AM -0400, Ivan Perez <ivanperezdominguez at gmail.com>, wrote:
> Can we please permanently ban this person and everyone from the confscience.com domain?
>
> Thanks,
>
> Ivan

Done.

—Gershom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210630/2205d77a/attachment.html>