From onepoint at starurchin.org  Sun Dec  3 00:29:27 2017
From: onepoint at starurchin.org (Jeremy Henty)
Date: Sun, 3 Dec 2017 00:29:27 +0000
Subject: [Haskell-cafe] ghc-8.2.2 downloads: missing checksums
In-Reply-To: <87o9nl87i8.fsf@ben-laptop.smart-cactus.org>
References: <20171127151321.GJ23883@omphalos.singularity>
 <87o9nl87i8.fsf@ben-laptop.smart-cactus.org>
Message-ID: <20171203002927.GO23883@omphalos.singularity>


Ben Gamari wrote:

> Jeremy Henty <onepoint at starurchin.org> writes:
> 
> > The SHA1SUMS and SHA256SUMS files in https://downloads.haskell.org/~ghc/8.2.2/
> > do not have checksums for ghc-8.2.2-x86_64-unknown-linux.tar.xz .
> >

> Thanks for noticing this. Fixed.

Unfortunately it  looks like it is  only a partial fix.   Some missing
checksums have been added but there  are still none in either file for
ghc-8.2.2-x86_64-unknown-linux.tar.xz .

Regards,

Jeremy Henty

From fis at etc-network.de  Mon Dec  4 08:36:33 2017
From: fis at etc-network.de (Matthias Fischmann)
Date: Mon, 4 Dec 2017 09:36:33 +0100
Subject: [Haskell-cafe] Call for Participation: BOB 2018 (February 23,
	Berlin)
Message-ID: <20171204083633.5rcvnfbpqclrb42h@localhost.localdomain>


                   BOB 2018
                  Conference
    “What happens if we simply use what’s best?”
            February 23, 2018, Berlin
             http://bobkonf.de/2018/
                   Program:
      http://bobkonf.de/2018/en/program.html
                Registration:
    http://bobkonf.de/2018/en/registration.html

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

BOB is the conference for developers, architects and decision-makers
to explore technologies beyond the mainstream in software development,
and to find the best tools available to software developers today. Our
goal is for all participants of BOB to return home with new insights
that enable them to improve their own software development
experiences.

The program features 14 talks and 8 tutorials on current topics:

http://bobkonf.de/2018/en/program.html

The subject range of talks includes functional programming,
verticalization, formal methods, and data analytics.

The tutorials feature introductions to Haskell, Clojure, Livecoding,
terminal programming, Liquid Haskell, functional reactive programming,
and domain-driven design.

Leif Andersen will give the keynote talk.

Registration is open online:

http://bobkonf.de/2018/en/registration.html

NOTE: The early-bird rates expire on January 22, 2018!

BOB cooperates with the :clojured conference on the following
day. There is a registration discount available for participants of
both events.

http://www.clojured.de/

From Graham.Hutton at nottingham.ac.uk  Mon Dec  4 09:40:48 2017
From: Graham.Hutton at nottingham.ac.uk (Graham Hutton)
Date: Mon, 4 Dec 2017 09:40:48 +0000
Subject: [Haskell-cafe] 10 PhD studentships in Nottingham
Message-ID: <85CC2F32-D286-479D-B54D-946C9B7C4C6E@exmail.nottingham.ac.uk>

Dear all,

The School of Computer Science in Nottingham is advertising 10
fully-funded PhD studentships.  Applicants in the area of the
Functional Programming Lab (https://tinyurl.com/fp-notts) are
encouraged!  If you are interested in applying, please contact a
potential supervisor prior to submitting your application:

  Thorsten Altenkirch - constructive logic, proof assistants,
  homotopy type theory, category theory, lambda calculus.

  Venanzio Capretta - type theory, mathematical logic, corecursive
  structures, proof assistants, dependently-typed programming.

  Graham Hutton - program calculation and verification, category
  theory, recursion operators, coinductive types.

  Henrik Nilsson - functional reactive programming, modelling and
  simulation, domain-specific languages, probabilistic languages.

Best wishes,

Graham 

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

               10 Fully-Funded PhD Studentships

                   School of Computer Science
                  University of Nottingham, UK

                https://tinyurl.com/10-phds-2018

Applications are invited for up to ten fully-funded PhD
studentships in the School of Computer Science at the
University of Nottingham, starting on 1 October 2018.

The topics for the studentships are open, but should relate to
the interests of one of the School's research groups: Agents
Lab; Automated Scheduling, Optimisation and Planning; Computer
Vision Lab; Functional Programming Lab; Intelligent Modelling
and Analysis; Mixed Reality Lab; Data Driven Algorithms, Systems
and Design and Uncertainty in Data and Decision Making.

The studentships are for three years and include a stipend
of £14,553 per year and tuition fees, and are available to
students of any nationality. Applicants are normally expected
to have a first-class Masters or Bachelors degree in Computer
Science or a related discipline, and must obtain the support of
a potential supervisor in the School prior to submitting their
application.  Initial contact with supervisors should be made
at least two weeks prior to the closing date for applications.
Informal enquiries may be addressed to SS-PGR-JC at nottingham.ac.uk

To apply, please submit the following items by email to:
Christine.Fletcher at nottingham.ac.uk: (1) a brief covering
letter that describes your reasons for wishing to pursue a
PhD, your proposed research area and topic, and the name of
a potential supervisor; (2) a copy of your CV, including your
actual or expected degree class(es), and results of all
University examinations; (3) an example of your technical
writing, such as a project report or dissertation; (4)
contact details for two academic referees.  

Closing date for applications: 19th January 2018

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





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

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

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


From k-bx at k-bx.com  Mon Dec  4 15:18:26 2017
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Mon, 4 Dec 2017 17:18:26 +0200
Subject: [Haskell-cafe] Taking over a maintainership on hsyslog-udp
Message-ID: <CAAbahfSjoz5CWP0Xe-G2u2sdGmHnp2qAHMa78hT_Tdyz8m15kw@mail.gmail.com>

I'd like to take over a maintainership of the hsyslog-udp package [0]. I
wrote Jon few days ago and got no response, so I'm acting as per the
"taking over" instructions [1]

Thanks

[0]: http://hackage.haskell.org/package/hsyslog-udp
[1]: https://wiki.haskell.org/Taking_over_a_package
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171204/4103717a/attachment.html>

From svenpanne at gmail.com  Mon Dec  4 17:07:43 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 4 Dec 2017 18:07:43 +0100
Subject: [Haskell-cafe] Taking over a maintainership on hsyslog-udp
In-Reply-To: <CAAbahfSjoz5CWP0Xe-G2u2sdGmHnp2qAHMa78hT_Tdyz8m15kw@mail.gmail.com>
References: <CAAbahfSjoz5CWP0Xe-G2u2sdGmHnp2qAHMa78hT_Tdyz8m15kw@mail.gmail.com>
Message-ID: <CANBN=msEP_r0V=SignBUVVviYPKnZnRKd1s2WYkEGS6VoJQk_g@mail.gmail.com>

2017-12-04 16:18 GMT+01:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:

> I'd like to take over a maintainership of the hsyslog-udp package [0]. I
> wrote Jon few days ago and got no response, so I'm acting as per the
> "taking over" instructions [1]
>

The last commits on the project's GitHub page were done just 3 days ago,
and the project is part of an organization (ThoughtLeadr). So the right
first step would be contacting the organization via GitHub, e.g. the issue
tracker. Furthermore, I don't think that "a few days" count as "a
reasonable time to respond". Taking over maintainership is a sledgehammer,
which should be used cautiously. I don't think anybody would be happy to
see their projects hijacked after e.g. a longer vacation...

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

From k-bx at k-bx.com  Mon Dec  4 20:41:30 2017
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Mon, 4 Dec 2017 22:41:30 +0200
Subject: [Haskell-cafe] Taking over a maintainership on hsyslog-udp
In-Reply-To: <CANBN=msEP_r0V=SignBUVVviYPKnZnRKd1s2WYkEGS6VoJQk_g@mail.gmail.com>
References: <CAAbahfSjoz5CWP0Xe-G2u2sdGmHnp2qAHMa78hT_Tdyz8m15kw@mail.gmail.com>
 <CANBN=msEP_r0V=SignBUVVviYPKnZnRKd1s2WYkEGS6VoJQk_g@mail.gmail.com>
Message-ID: <CAAbahfQ87=epi9Ac9-GwxxCuLcCxFmcvO9TujDwJqng2M+Zbxg@mail.gmail.com>

I'm a VP of Eng in that organization and Jon worked for us previously
actually :) We do have a commit access to the repo but not to the hackage.

Anyways, Jon responded today, so the issue is resolved, I've been added to
the maintainers list.

On Mon, Dec 4, 2017 at 7:07 PM, Sven Panne <svenpanne at gmail.com> wrote:

> 2017-12-04 16:18 GMT+01:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>
>> I'd like to take over a maintainership of the hsyslog-udp package [0]. I
>> wrote Jon few days ago and got no response, so I'm acting as per the
>> "taking over" instructions [1]
>>
>
> The last commits on the project's GitHub page were done just 3 days ago,
> and the project is part of an organization (ThoughtLeadr). So the right
> first step would be contacting the organization via GitHub, e.g. the issue
> tracker. Furthermore, I don't think that "a few days" count as "a
> reasonable time to respond". Taking over maintainership is a
> sledgehammer, which should be used cautiously. I don't think anybody would
> be happy to see their projects hijacked after e.g. a longer vacation...
>
> Cheers,
>    S.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171204/cbf18b98/attachment.html>

From aquagnu at gmail.com  Tue Dec  5 10:47:48 2017
From: aquagnu at gmail.com (Baa)
Date: Tue, 5 Dec 2017 12:47:48 +0200
Subject: [Haskell-cafe] How to match on such type
Message-ID: <20171205124748.3924e81c@Pavel>

Hello, All!

I have type:

  infixr 9 |||
  data a ||| b = A a|B b deriving (Eq, Data, Show)

and usually I wraps into it values which are instances of my class
IsTag:

  class IsTag a where
    anyTag :: a

So, I need to check if some value wrapping by `a|||b` is equal to
`anyTag`, i.e.:

  A (B (A x)) == (anyTag::TypeOf_x)
  ==> True

This function must be generic, ie, it can not know anything about
concreate TypeOf_x, only: `a|||b` and `IsTag`. How to do it???

I added `Data` to `a|||b` and even to values which I "wrap" with
`a|||b` (I assumed to use `gmap*` and Co), but this does not help me.
Is it even possible??

==
Best regadrs, Paul


From ivan.miljenovic at gmail.com  Tue Dec  5 11:16:51 2017
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Tue, 5 Dec 2017 22:16:51 +1100
Subject: [Haskell-cafe] How to match on such type
In-Reply-To: <20171205124748.3924e81c@Pavel>
References: <20171205124748.3924e81c@Pavel>
Message-ID: <CA+u6gbzY+m_dwHA_dHEyjUg_7Qu-vAvmy2LpO9ZZ9MK0242L3g@mail.gmail.com>

On 5 December 2017 at 21:47, Baa <aquagnu at gmail.com> wrote:
> Hello, All!
>
> I have type:
>
>   infixr 9 |||
>   data a ||| b = A a|B b deriving (Eq, Data, Show)
>
> and usually I wraps into it values which are instances of my class
> IsTag:
>
>   class IsTag a where
>     anyTag :: a
>
> So, I need to check if some value wrapping by `a|||b` is equal to
> `anyTag`, i.e.:
>
>   A (B (A x)) == (anyTag::TypeOf_x)
>   ==> True

Do you:

a) know whether it should be wrapped as A or B?

b) how many layers down it is?

One solution is to use something like (untested):

-- | Is type @a@ equivalent to @anyTag :: x@ ?
class EquivToTag a x where
  tagEquiv :: a -> Proxy x -> Bool

instance {-# OVERLAPPABLE #-} EquivToTag x x where
  tagEquiv _ _ = True

instance {-# OVERLAPPABLE #-} (EquivToTag a x) => EquivToTag (a ||| b) x where
  tagEquiv _ _ = True

instance {-# OVERLAPPABLE #-} (EquivToTag b x) => EquivToTag (a ||| b) x where
  tagEquiv _ _ = True

... Except there's no way of having False here, and the two |||
instances can't really both be there (which to pick?).

I'm not sure what the intent of this is, but would it make more sense
to use a type family which resolves to a Constraint?

>
> This function must be generic, ie, it can not know anything about
> concreate TypeOf_x, only: `a|||b` and `IsTag`. How to do it???
>
> I added `Data` to `a|||b` and even to values which I "wrap" with
> `a|||b` (I assumed to use `gmap*` and Co), but this does not help me.
> Is it even possible??
>
> ==
> Best regadrs, Paul
>
> _______________________________________________
> 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.



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From aquagnu at gmail.com  Tue Dec  5 12:15:57 2017
From: aquagnu at gmail.com (Baa)
Date: Tue, 5 Dec 2017 14:15:57 +0200
Subject: [Haskell-cafe] How to match on such type
In-Reply-To: <CA+u6gbzY+m_dwHA_dHEyjUg_7Qu-vAvmy2LpO9ZZ9MK0242L3g@mail.gmail.com>
References: <20171205124748.3924e81c@Pavel>
 <CA+u6gbzY+m_dwHA_dHEyjUg_7Qu-vAvmy2LpO9ZZ9MK0242L3g@mail.gmail.com>
Message-ID: <20171205141557.6cf355e0@Pavel>

Hello, Ivan!

Little context, no I don't know. I have:

  instance (Read a, Read b) => Read (a ||| b) where
    readPrec = parens $ (A <$> readPrec) <|> (B <$> readPrec)

with it I read in generic way combination of types, like:

  read "something" :: T1|||T2|||T3|||T4

I have already matching function, so I can check if some tag exists in
this tags combination. Nested layers number can be any - it's passed by
client of the library like `T1|||T2` or `T1|||T2|||T3|||T4`...

This task emerged from the fact that I can have lift of lists of tags
(already implemented) and want to match list on this list-of-lists:

  "tag1, tag2"  MATCH [ "tag1, tag3"
                      , "tag2, tag3"
                      , "tag1, tag2"
                      , "tag1, tag*" ]

/in pseudo-code/

So, I have 2 matches: ["tag1, tag2", "tag1, tag*"]. To distinguish them
I added match-weight, so more specialized will be "tag1, tag2" with
weight > than "tag1, tag*". But to be done, I need to know that "tag*"
is `anyTag`. Actually "tag1, tag*" as Haskell type is `Tags [a|||b]`,
where `Tags` is newtype-wrapper, `a|||b` is my generic type. Client
will pass this `a|||b` as some `T1|||T2|||T3...|||Tn`. So, somewhere in
this `a|||b` will be value which can be equal to `anyTag` and be
represented as "tag*". Sure, I don't know what type is it exactly (I
have not T1/T2/Tn in the library). I'm not sure is it possible even. I
added `Data` instances anywhere and now I'm trying to done it with
`gmapQ` but I have not experience with `Data` and `Typeable`.


===
Best regards, Paul

> On 5 December 2017 at 21:47, Baa <aquagnu at gmail.com> wrote:
> > Hello, All!
> >
> > I have type:
> >
> >   infixr 9 |||
> >   data a ||| b = A a|B b deriving (Eq, Data, Show)
> >
> > and usually I wraps into it values which are instances of my class
> > IsTag:
> >
> >   class IsTag a where
> >     anyTag :: a
> >
> > So, I need to check if some value wrapping by `a|||b` is equal to
> > `anyTag`, i.e.:
> >
> >   A (B (A x)) == (anyTag::TypeOf_x)  
> >   ==> True  
> 
> Do you:
> 
> a) know whether it should be wrapped as A or B?
> 
> b) how many layers down it is?
> 
> One solution is to use something like (untested):
> 
> -- | Is type @a@ equivalent to @anyTag :: x@ ?
> class EquivToTag a x where
>   tagEquiv :: a -> Proxy x -> Bool
> 
> instance {-# OVERLAPPABLE #-} EquivToTag x x where
>   tagEquiv _ _ = True
> 
> instance {-# OVERLAPPABLE #-} (EquivToTag a x) => EquivToTag (a |||
> b) x where tagEquiv _ _ = True
> 
> instance {-# OVERLAPPABLE #-} (EquivToTag b x) => EquivToTag (a |||
> b) x where tagEquiv _ _ = True
> 
> ... Except there's no way of having False here, and the two |||
> instances can't really both be there (which to pick?).
> 
> I'm not sure what the intent of this is, but would it make more sense
> to use a type family which resolves to a Constraint?
> 
> >
> > This function must be generic, ie, it can not know anything about
> > concreate TypeOf_x, only: `a|||b` and `IsTag`. How to do it???
> >
> > I added `Data` to `a|||b` and even to values which I "wrap" with
> > `a|||b` (I assumed to use `gmap*` and Co), but this does not help
> > me. Is it even possible??
> >
> > ==
> > Best regadrs, Paul
> >
> > _______________________________________________
> > 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 aquagnu at gmail.com  Tue Dec  5 13:20:54 2017
From: aquagnu at gmail.com (Baa)
Date: Tue, 5 Dec 2017 15:20:54 +0200
Subject: [Haskell-cafe] How to match on such type
In-Reply-To: <CA+u6gbzY+m_dwHA_dHEyjUg_7Qu-vAvmy2LpO9ZZ9MK0242L3g@mail.gmail.com>
References: <20171205124748.3924e81c@Pavel>
 <CA+u6gbzY+m_dwHA_dHEyjUg_7Qu-vAvmy2LpO9ZZ9MK0242L3g@mail.gmail.com>
Message-ID: <20171205152054.6367b6d0@Pavel>

Done it by implementing own `Eqn` class and all instances:

  class Eqn a where
    eqn :: a -> a -> Int -- ^ returns weight

auto-deriving `Eq` instances help to make exact comparison, `eqn` -
with weight.

===
Best regards, Paul

> On 5 December 2017 at 21:47, Baa <aquagnu at gmail.com> wrote:
> > Hello, All!
> >
> > I have type:
> >
> >   infixr 9 |||
> >   data a ||| b = A a|B b deriving (Eq, Data, Show)
> >
> > and usually I wraps into it values which are instances of my class
> > IsTag:
> >
> >   class IsTag a where
> >     anyTag :: a
> >
> > So, I need to check if some value wrapping by `a|||b` is equal to
> > `anyTag`, i.e.:
> >
> >   A (B (A x)) == (anyTag::TypeOf_x)  
> >   ==> True  
> 
> Do you:
> 
> a) know whether it should be wrapped as A or B?
> 
> b) how many layers down it is?
> 
> One solution is to use something like (untested):
> 
> -- | Is type @a@ equivalent to @anyTag :: x@ ?
> class EquivToTag a x where
>   tagEquiv :: a -> Proxy x -> Bool
> 
> instance {-# OVERLAPPABLE #-} EquivToTag x x where
>   tagEquiv _ _ = True
> 
> instance {-# OVERLAPPABLE #-} (EquivToTag a x) => EquivToTag (a |||
> b) x where tagEquiv _ _ = True
> 
> instance {-# OVERLAPPABLE #-} (EquivToTag b x) => EquivToTag (a |||
> b) x where tagEquiv _ _ = True
> 
> ... Except there's no way of having False here, and the two |||
> instances can't really both be there (which to pick?).
> 
> I'm not sure what the intent of this is, but would it make more sense
> to use a type family which resolves to a Constraint?
> 
> >
> > This function must be generic, ie, it can not know anything about
> > concreate TypeOf_x, only: `a|||b` and `IsTag`. How to do it???
> >
> > I added `Data` to `a|||b` and even to values which I "wrap" with
> > `a|||b` (I assumed to use `gmap*` and Co), but this does not help
> > me. Is it even possible??
> >
> > ==
> > Best regadrs, Paul
> >
> > _______________________________________________
> > 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 alex at centromere.net  Wed Dec  6 14:12:03 2017
From: alex at centromere.net (alex at centromere.net)
Date: Wed, 06 Dec 2017 09:12:03 -0500
Subject: [Haskell-cafe] Hackage / Stackage Idea
Message-ID: <ed9d50e45d13b834f0e5697a63a0d181@centromere.net>

Hi all,

I use Haskell in production, and when choosing a library I wonder, "Is
this package production-ready?". In addition to evaluating the quality
of the code, I consider various factors such as the most recent upload
date, number of downloads, the age of the last commit, the author's
reputation, the number of packages which depend on that package, and the
number of issues open and closed.

I think it would be interesting to add a feature to Hackage and/or
Stackage which allows companies to advertise that they use a package
in production. If they elect to be anonymous, only the count would
increase. I believe that this data would not only help inform my library
choices, but also help communicate Haskell's merits to industry.

What do you all think?

Alex

From m at jaspervdj.be  Wed Dec  6 14:24:00 2017
From: m at jaspervdj.be (Jasper Van der Jeugt)
Date: Wed, 6 Dec 2017 15:24:00 +0100
Subject: [Haskell-cafe] [Announce] ZuriHac 2018: Registration now open
Message-ID: <20171206142400.GA12712@colony6.localdomain>

We are happy to announce that registration for ZuriHac 2018 is now open.
Participation is free but limited to 300 attendees.  You can register
at:

    http://zurihac.info/register

This year, the Haskell Hackathon will take place Friday June 8th to
Sunday the 10th.  It will be hosted at the Hochschule Rapperswil right
besides the beautiful lake Zurich, like last year.

The Zurich Haskell Hackathon is a free (as in beer), international,
grassroots collaborative coding festival whose goal is to expand the
community and to build and improve Haskell libraries, tools, and
infrastructure.  This is already the 7th Haskell Hackathon in Zurich!

This year, we will enjoy keynotes from:

- Niki Vazou
- Edward Kmett
- Stephen Diehl

More keynote speakers will be announced.

This event is open to any experience level, from beginners to gurus.
This year, Julie Moronuki, co-author of Haskell Programming from first
principles [1], has kindly agreed to teach a beginners course in one of
the classrooms we have available.  Additionally, there will be mentors
on site whom you can directly approach during the whole event with any
Haskell-related question you have.

This is a great opportunity to meet your fellow Haskellers in real life,
find new contributors for your project, improve existing libraries and
tools or even start new ones!

More information about ZuriHac can be found on our website [2].

We would also like to thank our sponsors Adjoint [3], Digital Asset [4],
HSR [5] for supporting this great event!

Looking forward to see you there,
the Zurich HaskellerZ meetup group

[1]: https://www.goodreads.com/book/show/25587599-haskell-programming
[2]: https://zurihac.info/
[3]: https://www.adjoint.io/
[4]: https://digitalasset.com/careers.html
[5]: https://www.hsr.ch/

From szymonpajzert at gmail.com  Wed Dec  6 23:12:23 2017
From: szymonpajzert at gmail.com (Szymon Pajzert)
Date: Wed, 06 Dec 2017 23:12:23 +0000
Subject: [Haskell-cafe] [Announce] ZuriHac 2018: Registration now open
In-Reply-To: <20171206142400.GA12712@colony6.localdomain>
References: <20171206142400.GA12712@colony6.localdomain>
Message-ID: <CAFux-B_wU9r1uwp1aTsvFU+JzRXHVmUqvxKcBMnSnTB1cnF3nw@mail.gmail.com>

Hi Jasper,

Are there any Haskell events happening in Zurich from July to September?
I'll be visiting your lovely city then and I hoped to do some pure (as in
functional) programming as well.

Best,
Szymon

On Wed, Dec 6, 2017, 15:26 Jasper Van der Jeugt <m at jaspervdj.be> wrote:

> We are happy to announce that registration for ZuriHac 2018 is now open.
> Participation is free but limited to 300 attendees.  You can register
> at:
>
>     http://zurihac.info/register
>
> This year, the Haskell Hackathon will take place Friday June 8th to
> Sunday the 10th.  It will be hosted at the Hochschule Rapperswil right
> besides the beautiful lake Zurich, like last year.
>
> The Zurich Haskell Hackathon is a free (as in beer), international,
> grassroots collaborative coding festival whose goal is to expand the
> community and to build and improve Haskell libraries, tools, and
> infrastructure.  This is already the 7th Haskell Hackathon in Zurich!
>
> This year, we will enjoy keynotes from:
>
> - Niki Vazou
> - Edward Kmett
> - Stephen Diehl
>
> More keynote speakers will be announced.
>
> This event is open to any experience level, from beginners to gurus.
> This year, Julie Moronuki, co-author of Haskell Programming from first
> principles [1], has kindly agreed to teach a beginners course in one of
> the classrooms we have available.  Additionally, there will be mentors
> on site whom you can directly approach during the whole event with any
> Haskell-related question you have.
>
> This is a great opportunity to meet your fellow Haskellers in real life,
> find new contributors for your project, improve existing libraries and
> tools or even start new ones!
>
> More information about ZuriHac can be found on our website [2].
>
> We would also like to thank our sponsors Adjoint [3], Digital Asset [4],
> HSR [5] for supporting this great event!
>
> Looking forward to see you there,
> the Zurich HaskellerZ meetup group
>
> [1]: https://www.goodreads.com/book/show/25587599-haskell-programming
> [2]: https://zurihac.info/
> [3]: https://www.adjoint.io/
> [4]: https://digitalasset.com/careers.html
> [5]: https://www.hsr.ch/
> _______________________________________________
> 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/20171206/58538545/attachment.html>

From manny at fpcomplete.com  Thu Dec  7 05:37:06 2017
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Wed, 6 Dec 2017 21:37:06 -0800
Subject: [Haskell-cafe] ANN: stack-1.6.1
Message-ID: <BDEBCBBB-3CF5-40F5-B9EE-3B04B553B969@fpcomplete.com>

See https://haskellstack.org <https://haskellstack.org/> for installation and upgrade instructions.

Note: we are releasing a bit earlier than planned due to #3624 <https://github.com/commercialhaskell/stack/issues/3624>. As such, not all the binaries have been built yet, but the commonly used 64-bit binaries of Linux static, macOS, and Windows are available.

In addition, the Windows installer and binary has not been codesigned (we are awaiting validation of a new codesign certificate), and you may see a "Windows Defender SmartScreen prevented an unrecognized app from starting" warning when you try to run them. If so, click on More info, and then click on the Run anyway button that appears.

Changes since v1.5.1

Major changes:

Complete overhaul of how snapshots are defined, the packages and
extra-deps fields, and a number of related items. For full
details, please see
the writeup on these changes <https://www.fpcomplete.com/blog/2017/07/stacks-new-extensible-snapshots>. PR #3249 <https://github.com/commercialhaskell/stack/pull/3249>,
see the PR description for a number of related issues.
Upgraded to version 2.0 of the Cabal library.
Behavior changes:

The --install-ghc flag is now on by default. For example, if you
run stack build in a directory requiring a GHC that you do not
currently have, Stack will automatically download and install that
GHC. You can explicitly set install-ghc: false or pass the flag
--no-install-ghc to regain the previous behavior.
stack ghci no longer loads modules grouped by package. This is
always an improvement for plain ghci - it makes loading faster and
less noisy. For intero, this has the side-effect that it will no
longer load multiple packages that depend on TH loading relative
paths. TH relative paths will still work when loading a single
package into intero. See
#3309 <https://github.com/commercialhaskell/stack/issues/3309>
Setting GHC options for a package via ghc-options: in your
stack.yaml will promote it to a local package, providing for more
consistency with flags and better reproducibility. See:
#849 <https://github.com/commercialhaskell/stack/issues/849>
The package-indices setting with Hackage no longer works with the
00-index.tar.gz tarball, but must use the 01-index.tar.gz file
to allow revised packages to be found.
Options passsed via --ghci-options are now passed to the end of the
invocation of ghci, instead of the middle. This allows using +RTS
without an accompanying -RTS.
When auto-detecting --ghc-build, tinfo6 is now preferred over
standard if both versions of libtinfo are installed
Addition of stack build --copy-compiler-tool, to allow tools like
intero to be installed globally for a particular compiler.
#2643 <https://github.com/commercialhaskell/stack/issues/2643>
Stack will ask before saving hackage credentials to file. This new
prompt can be avoided by using the save-hackage-creds setting. Please
see #2159 <https://github.com/commercialhaskell/stack/issues/2159>.
The GHCRTS environment variable will no longer be passed through to
every program stack runs. Instead, it will only be passed through
commands like exec, runghc, script, ghci, etc.
See #3444 <https://github.com/commercialhaskell/stack/issues/3444>.
ghc-options: for specific packages will now come after the options
specified for all packages / particular sets of packages. See
#3573 <https://github.com/commercialhaskell/stack/issues/3573>.
The pvp-bounds feature is no longer fully functional, due to some
issues with the Cabal library's printer. See
#3550 <https://github.com/commercialhaskell/stack/issues/3550>.
Other enhancements:

The with-hpack configuration option specifies an Hpack executable to use
instead of the Hpack bundled with Stack. Please
see #3179 <https://github.com/commercialhaskell/stack/issues/3179>.
It's now possible to skip tests and benchmarks using --skip
flag
GitSHA1 is now StaticSHA256 and is implemented using the StaticSize 64 ByteString for improved performance.
See #3006 <https://github.com/commercialhaskell/stack/issues/3006>
Dependencies via HTTP(S) archives have been generalized to allow
local file path archives, as well as to support setting a
cryptographic hash (SHA256) of the contents for better
reproducibility.
Allow specifying --git-branch when upgrading
When running stack upgrade from a file which is different from the
default executable path (e.g., on POSIX systems,
~/.local/bin/stack), it will now additionally copy the new
executable over the currently running stack executable. If
permission is denied (such as in /usr/local/bin/stack), the user
will be prompted to try again using sudo. This is intended to
assist with the user experience when the PATH environment variable
has not been properly configured, see
#3232 <https://github.com/commercialhaskell/stack/issues/3232>.
stack setup for ghcjs will now install alex and happy if
they are not present. See
#3109 <https://github.com/commercialhaskell/stack/issues/3232>.
Added stack ghci --only-main flag, to skip loading / importing
all but main modules. See the ghci documentation page
for further info.
Allow GHC's colored output to show through. GHC colors output
starting with version 8.2.1, for older GHC this does nothing.
Sometimes GHC's heuristics would work fine even before this change,
for example in stack ghci, but this override's GHC's heuristics
when they're broken by our collecting and processing GHC's output.
Extended the ghc-options field to support $locals, $targets,
and $everything. See:
#3329 <https://github.com/commercialhaskell/stack/issues/3329>
Better error message for case that stack ghci file targets are
combined with invalid package targets. See:
#3342 <https://github.com/commercialhaskell/stack/issues/3342>
For profiling now uses -fprof-auto -fprof-cafs instead of
the deprecated -auto-all -caf-all. See:
#3360 <https://github.com/commercialhaskell/stack/issues/3360>
Better descriptions are now available for stack upgrade --help. See:
#3070 <https://github.com/commercialhaskell/stack/issues/3070>
When using Nix, nix-shell now depends always on gcc to prevent build errors
when using the FFI. As ghc depends on gcc anyway, this doesn't increase the
dependency footprint.
--cwd DIR can now be passed to stack exec in order to execute the
program in a different directory. See:
#3264 <https://github.com/commercialhaskell/stack/issues/3264>
Plan construction will detect if you add an executable-only package
as a library dependency, resulting in much clearer error
messages. See:
#2195 <https://github.com/commercialhaskell/stack/issues/2195>.
Addition of --ghc-options to stack script to pass options directly
to GHC. See:
#3454 <https://github.com/commercialhaskell/stack/issues/3454>
Add hpack package.yaml to build Stack itself
Add ignore-revision-mismatch setting. See:
#3520 <https://github.com/commercialhaskell/stack/issues/3520>.
Log when each individual test suite finishes. See:
#3552 <https://github.com/commercialhaskell/stack/issues/3552>.
Avoid spurious rebuilds when using --file-watch by not watching files for
executable, test and benchmark components that aren't a target. See:
#3483 <https://github.com/commercialhaskell/stack/issues/3483>.
Stack will now try to detect the width of the running terminal
(only on POSIX for the moment) and use that to better display
output messages. Work is ongoing, so some messages will not
be optimal yet. The terminal width can be overriden with the
new --terminal-width command-line option (this works even on
non-POSIX).
Passing non local packages as targets to stack ghci will now
cause them to be used as -package args along with package
hiding.
Detect when user changed .cabal file instead of package.yaml. This
was implemented upstream in hpack. See
#3383 <https://github.com/commercialhaskell/stack/issues/3383>.
Automatically run autoreconf -i as necessary when a configure
script is missing. See
#3534 <https://github.com/commercialhaskell/stack/issues/3534>
GHC bindists can now be identified by their SHA256 checksum in addition to
their SHA1 checksum, allowing for more security in download.
For filesystem setup-info paths, it's no longer assumed that the
directory is writable, instead a temp dir is used. See
#3188 <https://github.com/commercialhaskell/stack/issues/3188>.
Bug fixes:

stack hoogle correctly generates Hoogle databases. See:
#3362 <https://github.com/commercialhaskell/stack/issues/3362>
stack --docker-help is now clearer about --docker implying
system-ghc: true, rather than both --docker and --no-docker.
stack haddock now includes package names for all modules in the
Haddock index page. See:
#2886 <https://github.com/commercialhaskell/stack/issues/2886>
Fixed an issue where Stack wouldn't detect missing Docker images
properly with newer Docker versions.
#3171 <https://github.com/commercialhaskell/stack/pull/3171>
Previously, cabal files with just test-suite could cause build to fail
(#2862 <https://github.com/commercialhaskell/stack/issues/2862>)
If an invalid snapshot file has been detected (usually due to
mismatched hashes), Stack will delete the downloaded file and
recommend either retrying or filing an issue upstream. See
#3319 <https://github.com/commercialhaskell/stack/issues/3319>.
Modified the flag parser within Stack to match the behavior of
Cabal's flag parser, which allows multiple sequential dashes. See
#3345 <https://github.com/commercialhaskell/stack/issues/3345>
Now clears the hackage index cache if it is older than the
downloaded index. Fixes potential issue if stack was interrupted when
updating index.
See #3033 <https://github.com/commercialhaskell/stack/issues/3033>
The Stack install script now respects the -d option.
See #3366 <https://github.com/commercialhaskell/stack/pull/3366>.
stack script can now handle relative paths to source files.
See #3372 <https://github.com/commercialhaskell/stack/issues/3372>.
Fixes explanation of why a target is needed by the build plan, when the
target is an extra dependency from the commandline.
See #3378 <https://github.com/commercialhaskell/stack/issues/3378>.
Previously, if you delete a yaml file from ~/.stack/build-plan, it would
trust the etag and not re-download. Fixed in this version.
Invoking stack --docker in parallel now correctly locks the sqlite database.
See #3400 <https://github.com/commercialhaskell/stack/issues/3400>.
docs.haskellstack.org RTD documentation search is replaced by the mkdocs
search. Please see
#3376 <https://github.com/commercialhaskell/stack/issues/3376>.
stack clean now works with nix. See
#3468 <https://github.com/commercialhaskell/stack/issues/3376>.
stack build --only-dependencies no longer builds local project packages
that are depended on. See
#3476 <https://github.com/commercialhaskell/stack/issues/3476>.
Properly handle relative paths stored in the precompiled cache files. See
#3431 <https://github.com/commercialhaskell/stack/issues/3431>.
In some cases, Cabal does not realize that it needs to reconfigure, and must
be told to do so automatically. This would manifest as a "shadowed
dependency" error message. We now force a reconfigure whenever a dependency is
built, even if the package ID remained the same. See
#2781 <https://github.com/commercialhaskell/stack/issues/2781>.
When --pvp-bounds is enabled for sdist or upload, internal
dependencies could cause errors when uploaded to hackage. This is
fixed, see #3290 <https://github.com/commercialhaskell/stack/issues/3290>
Fixes a bug where nonexistent hackage versions would cause stack to
suggest the same package name, without giving version info. See
#3562 <https://github.com/commercialhaskell/stack/issues/3562>
Fixes a bug that has existed since 1.5.0, where
stack setup --upgrade-cabal would say that Cabal is already the latest
version, when it wasn't.
Ensure that an extra-dep from a local directory is not treated as
a $locals for GHC options purposes. See
#3574 <https://github.com/commercialhaskell/stack/issues/3574>.
Building all executables only happens once instead of every
time. See
#3229 <https://github.com/commercialhaskell/stack/issues/3229> for
more info.
Thanks to all our contributors for this release:

Aaron McDaid
Adam McCullough
Alexey Zabelin
Andy
Ashley Towns
Chris Done
Chris Martin
d-dorazio
Deni Bertovic
Dmitry Ivanov
Echo Nolan
Emanuel Borsboom
Felix Yan
Filippo Vitale
Gábor Lipták
Ivan Lazar Miljenovic
Joshua Simmons
Judah Jacobson
Khan Thompson
Lizao Li
Luke Murphy
Martin Kolinek
Mathieu Boespflug
Matt Audesse
Matthias Heinzel
Michael Sloan
Michael Snoyman
mrkkrp
Neil Mitchell
Oleg Grenrus
OvermindDL1
Paolo G. Giarrusso
Rafe
Reuben D'Netto
Roman Cheplyaka
Samuli Thomasson
Schlueter
Scott Fleischman
Shea Levy
Simon Jakobi
Tom Sydney Kerckhove
tswelsh
Walter Franzini

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

From neil_mayhew at users.sourceforge.net  Thu Dec  7 06:09:30 2017
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Wed, 6 Dec 2017 23:09:30 -0700
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
Message-ID: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>

I was writing a simple utility and I decided to use regexps to parse 
filenames. (I know, now I have two problems :-) )

I was surprised at how slow it ran, so I did a profiling build. The 
profiled code runs reasonably quickly, and is 7x faster, which makes it 
a bit hard to figure out where the slowdown is happening in the 
non-profiled code. I’m wondering if I’m doing something wrong, or if 
there’s a bug in |regex-tdfa| or in ghc.

I’ve pared my code down to just the following:

|import Text.Regex.TDFA ((=~)) main :: IO () main = do entries <- map 
parseFilename . lines <$> getContents let check (Right (_, t)) = last t 
== 'Z' check _ = False print $ all check entries parseFilename :: String 
-> Either String (String, String) parseFilename fn = case (fn =~ pattern 
:: [[String]]) of [[_, full, _, time]] -> Right $ (full, time) _ -> Left 
fn where pattern = "^\\./duplicity-(full|inc|new)(-signatures)?\\.\ 
\([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\." 
|

The relevant part of my |.cabal| file looks like this:

|executable DuplicityAnalyzer main-is: DuplicityAnalyzer.hs 
build-depends: base >=4.6 && <4.11, regex-tdfa >= 1.0 && <1.3 
default-language: Haskell2010 ghc-options: -Wall -rtsopts |

To run the profiling, I do:

|cabal clean cabal configure --enable-profiling cabal build 
dist/build/DuplicityAnalyzer/DuplicityAnalyzer <names.in +RTS 
-sprofiling-summary.out -p |

The |MUT| time in the non-profiling build is 7x bigger, and the |%GC| 
time goes from 8% to 21%. I’ve put the actual output in a gist 
<https://gist.github.com/neilmayhew/247a30738c0e294902e7c2830ca2c6f5>. 
I’ve also put my test input file there, in case anyone wants to try this 
themselves.

I’ve done my testing with NixOS (ghc 8.0.2) and Debian with the Haskell 
Platform (ghc 8.2.1) and the results are basically the same. I even 
tried using Docker containers with Debian Jessie and Debian Stretch, 
just to eliminate any OS influence, and the results are still the same. 
I’ve tried it on an i5-2500K, i5-3317U and Xeon E5-1620.

I also wrote a dummy implementation of |=~| that ignores the regex 
pattern and does a hard-coded manual parse, and that produces times just 
slightly better than the profiled ones. So I don’t think there’s a 
problem in my outer code that uses |=~|.

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

From clintonmead at gmail.com  Thu Dec  7 07:16:07 2017
From: clintonmead at gmail.com (Clinton Mead)
Date: Thu, 7 Dec 2017 18:16:07 +1100
Subject: [Haskell-cafe] Serialising both data and functions
Message-ID: <CAFDVgwH1oufDYyrd3ppZKQWOhT-V_5tV2LrC919Ne9U7UaAf7Q@mail.gmail.com>

The cereal <https://hackage.haskell.org/package/cereal> package contains a
useful framework for serialising data. I've also noticed that the static
pointers
<https://ocharles.org.uk/blog/guest-posts/2014-12-23-static-pointers.html>
extension
could be useful for serialising functions, at least those which are
statically applied (I understand the caveat that this breaks if the
executable is recompiled).

But it occurred to me that I might want to serialise a combination of these
two things, for example, a static function call with a number of arguments,
but the first of those arguments being non-static data.

Is there a package to that combines these two use cases, namely static
functions with non-static data? I'm happy to start writing one myself, but
I don't want to reinvent the wheel.

My ultimate aim is to combine this with acid-state
<https://hackage.haskell.org/package/acid-state> so the current requirement
to effectively pre-declare all possible operations on your data is relaxed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171207/d7964167/attachment.html>

From anselm.scholl at tu-harburg.de  Thu Dec  7 07:49:42 2017
From: anselm.scholl at tu-harburg.de (Jonas Scholl)
Date: Thu, 7 Dec 2017 08:49:42 +0100
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
Message-ID: <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>

Looking at the produced core of both versions reveals that in the
profiled build a closure of type Regex is floated to top level. The
non-profiled build doesn't do this, thus it recompiles the regex for
every iteration. This is most likely the source of the slowdown of the
non-profiled build.

On 12/07/2017 07:09 AM, Neil Mayhew wrote:
> I was writing a simple utility and I decided to use regexps to parse
> filenames. (I know, now I have two problems :-) )
> 
> I was surprised at how slow it ran, so I did a profiling build. The
> profiled code runs reasonably quickly, and is 7x faster, which makes it
> a bit hard to figure out where the slowdown is happening in the
> non-profiled code. I’m wondering if I’m doing something wrong, or if
> there’s a bug in |regex-tdfa| or in ghc.
> 
> I’ve pared my code down to just the following:
> 
> |import Text.Regex.TDFA ((=~)) main :: IO () main = do entries <- map
> parseFilename . lines <$> getContents let check (Right (_, t)) = last t
> == 'Z' check _ = False print $ all check entries parseFilename :: String
> -> Either String (String, String) parseFilename fn = case (fn =~ pattern
> :: [[String]]) of [[_, full, _, time]] -> Right $ (full, time) _ -> Left
> fn where pattern = "^\\./duplicity-(full|inc|new)(-signatures)?\\.\
> \([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\."
> |
> 
> The relevant part of my |.cabal| file looks like this:
> 
> |executable DuplicityAnalyzer main-is: DuplicityAnalyzer.hs
> build-depends: base >=4.6 && <4.11, regex-tdfa >= 1.0 && <1.3
> default-language: Haskell2010 ghc-options: -Wall -rtsopts |
> 
> To run the profiling, I do:
> 
> |cabal clean cabal configure --enable-profiling cabal build
> dist/build/DuplicityAnalyzer/DuplicityAnalyzer <names.in +RTS
> -sprofiling-summary.out -p |
> 
> The |MUT| time in the non-profiling build is 7x bigger, and the |%GC|
> time goes from 8% to 21%. I’ve put the actual output in a gist
> <https://gist.github.com/neilmayhew/247a30738c0e294902e7c2830ca2c6f5>.
> I’ve also put my test input file there, in case anyone wants to try this
> themselves.
> 
> I’ve done my testing with NixOS (ghc 8.0.2) and Debian with the Haskell
> Platform (ghc 8.2.1) and the results are basically the same. I even
> tried using Docker containers with Debian Jessie and Debian Stretch,
> just to eliminate any OS influence, and the results are still the same.
> I’ve tried it on an i5-2500K, i5-3317U and Xeon E5-1620.
> 
> I also wrote a dummy implementation of |=~| that ignores the regex
> pattern and does a hard-coded manual parse, and that produces times just
> slightly better than the profiled ones. So I don’t think there’s a
> problem in my outer code that uses |=~|.
> 
> ​
> 
> 
> _______________________________________________
> 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: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171207/8df68542/attachment.sig>

From neil_mayhew at users.sourceforge.net  Thu Dec  7 21:25:49 2017
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Thu, 7 Dec 2017 14:25:49 -0700
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
Message-ID: <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>

On 2017-12-07 12:49 AM, Jonas Scholl wrote:

    Looking at the produced core of both versions reveals that in the
    profiled build a closure of type Regex is floated to top level. The
    non-profiled build doesn’t do this, thus it recompiles the regex for
    every iteration. This is most likely the source of the slowdown of
    the non-profiled build.

Thanks, Jonas. This does indeed seem to be the problem. I changed the 
code to use a compiled regex (with |makeRegex| and |match| instead of 
|=~|) but in the non-profiling case the run-time doesn’t improve unless 
I float the compiled regex myself:

|parseFilename :: String -> Either String (String, String) parseFilename 
fn = case (pattern `match` fn :: [[String]]) of [[_, full, _, time]] -> 
Right $ (full, time) _ -> Left fn pattern :: Regex pattern = makeRegex 
"^\\./duplicity-(full|inc|new)(-signatures)?\\.\ 
\([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\." 
|

Then it runs 2-3x faster than the profiled code.

The question remains, however: why doesn’t the ghc optimizer spot this 
fairly obvious loop-invariant in the non-profiled build when it does 
manage to spot it in the profiled one? In other words, when I make 
|pattern| a local definition of |parseFilename|, why isn’t it treated as 
a CAF that’s evaluated only once (‘floated to the top level’)? Enabling 
profiling shouldn’t change the meaning of a program.

I remember back in the day having to be careful with regexes in Python 
to make sure they were always precompiled outside of loops and 
functions, but one of the nice things about Haskell is that one can 
usually let the compiler take care of this. (Nowadays Python gets around 
this by caching compiled regexes, but I prefer Haskell’s 
statically-optimized approach.)

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171207/7bb7527c/attachment.html>

From will.yager at gmail.com  Thu Dec  7 21:40:18 2017
From: will.yager at gmail.com (Will Yager)
Date: Thu, 7 Dec 2017 16:40:18 -0500
Subject: [Haskell-cafe] Serialising both data and functions
In-Reply-To: <CAFDVgwH1oufDYyrd3ppZKQWOhT-V_5tV2LrC919Ne9U7UaAf7Q@mail.gmail.com>
References: <CAFDVgwH1oufDYyrd3ppZKQWOhT-V_5tV2LrC919Ne9U7UaAf7Q@mail.gmail.com>
Message-ID: <FE58E216-C16A-44A0-A13B-FEBE2689C9F0@gmail.com>



> On Dec 7, 2017, at 2:16 AM, Clinton Mead <clintonmead at gmail.com> wrote:
> 
> 
> Is there a package to that combines these two use cases, namely static functions with non-static data? I'm happy to start writing one myself, but I don't want to reinvent the wheel.
> 

I believe Cloud Haskell does something like this. 

-Will

From allbery.b at gmail.com  Thu Dec  7 22:05:44 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 7 Dec 2017 17:05:44 -0500
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
Message-ID: <CAKFCL4U_fZDdg56Emg7bmtqao4=RagdHKzDajL6iB3ZYwu+bkw@mail.gmail.com>

Bugs, usually. I think there was one such in 8.2.1 and if so it may not
have been completely fixed (trying to read around the edges of some dev
discussion, since I'm kinda far from expert when it comes to ghc internals).

On Thu, Dec 7, 2017 at 4:25 PM, Neil Mayhew <
neil_mayhew at users.sourceforge.net> wrote:

> On 2017-12-07 12:49 AM, Jonas Scholl wrote:
>
> Looking at the produced core of both versions reveals that in the profiled
> build a closure of type Regex is floated to top level. The non-profiled
> build doesn’t do this, thus it recompiles the regex for every iteration.
> This is most likely the source of the slowdown of the non-profiled build.
>
> Thanks, Jonas. This does indeed seem to be the problem. I changed the code
> to use a compiled regex (with makeRegex and match instead of =~) but in
> the non-profiling case the run-time doesn’t improve unless I float the
> compiled regex myself:
>
> parseFilename :: String -> Either String (String, String)parseFilename fn = case (pattern `match` fn :: [[String]]) of
>     [[_, full, _, time]] -> Right $ (full, time)
>     _ -> Left fn
> pattern :: Regexpattern = makeRegex
>     "^\\./duplicity-(full|inc|new)(-signatures)?\\.\
>     \([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\."
>
> Then it runs 2-3x faster than the profiled code.
>
> The question remains, however: why doesn’t the ghc optimizer spot this
> fairly obvious loop-invariant in the non-profiled build when it does manage
> to spot it in the profiled one? In other words, when I make pattern a
> local definition of parseFilename, why isn’t it treated as a CAF that’s
> evaluated only once (‘floated to the top level’)? Enabling profiling
> shouldn’t change the meaning of a program.
>
> I remember back in the day having to be careful with regexes in Python to
> make sure they were always precompiled outside of loops and functions, but
> one of the nice things about Haskell is that one can usually let the
> compiler take care of this. (Nowadays Python gets around this by caching
> compiled regexes, but I prefer Haskell’s statically-optimized approach.)
> ​
>
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171207/7c1a798d/attachment.html>

From neil_mayhew at users.sourceforge.net  Thu Dec  7 22:12:03 2017
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Thu, 7 Dec 2017 15:12:03 -0700
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <CAKFCL4U_fZDdg56Emg7bmtqao4=RagdHKzDajL6iB3ZYwu+bkw@mail.gmail.com>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
 <CAKFCL4U_fZDdg56Emg7bmtqao4=RagdHKzDajL6iB3ZYwu+bkw@mail.gmail.com>
Message-ID: <072d4fc2-6838-dafb-9539-676449b5a9c1@users.sourceforge.net>

On 2017-12-07 03:05 PM, Brandon Allbery wrote:
 > Bugs, usually. I think there was one such in 8.2.1 and if so it may 
not have been completely fixed

So if I was being a good citizen I'd try this out with ghc master built 
from source and report a bug if it's not fixed? Or do you thin it would 
be sufficient to use a binary installer of ghc 8.2.2?

From allbery.b at gmail.com  Thu Dec  7 22:33:07 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 7 Dec 2017 17:33:07 -0500
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <072d4fc2-6838-dafb-9539-676449b5a9c1@users.sourceforge.net>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
 <CAKFCL4U_fZDdg56Emg7bmtqao4=RagdHKzDajL6iB3ZYwu+bkw@mail.gmail.com>
 <072d4fc2-6838-dafb-9539-676449b5a9c1@users.sourceforge.net>
Message-ID: <CAKFCL4V9BZ2w6stJWC3QcF-J56Wh-GqCAHrx9GXfrQJJu_K3-A@mail.gmail.com>

I'd do both, both to get information on what it looks like in the latest
release and to verify something hasn't changed in 8.3/future 8.4 (which is
moving forward). Certainly the behavior here sounds wrong and should be
reported.

On Thu, Dec 7, 2017 at 5:12 PM, Neil Mayhew <
neil_mayhew at users.sourceforge.net> wrote:

> On 2017-12-07 03:05 PM, Brandon Allbery wrote:
> > Bugs, usually. I think there was one such in 8.2.1 and if so it may not
> have been completely fixed
>
> So if I was being a good citizen I'd try this out with ghc master built
> from source and report a bug if it's not fixed? Or do you thin it would be
> sufficient to use a binary installer of ghc 8.2.2?
>
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171207/e0cb899f/attachment.html>

From svenpanne at gmail.com  Fri Dec  8 08:52:06 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Fri, 8 Dec 2017 09:52:06 +0100
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
Message-ID: <CANBN=msv9OTqjseHrRR8hXU2Yf-2D1vRFrHMueeZgZZY6GVSVQ@mail.gmail.com>

2017-12-07 22:25 GMT+01:00 Neil Mayhew <neil_mayhew at users.sourceforge.net>:

> [...] The question remains, however: why doesn’t the ghc optimizer spot
> this fairly obvious loop-invariant in the non-profiled build when it does
> manage to spot it in the profiled one? In other words, when I make pattern
> a local definition of parseFilename, why isn’t it treated as a CAF that’s
> evaluated only once (‘floated to the top level’)?
>
Because making something a CAF is not always an optimization: If your
evaluated CAF uses e.g. hundreds of MB it might be preferable to *not* have
it as a CAF, but to to recompute it instead. If I haven't missed something
recently, CAFs can't be garbage collected, but I would be happy to be
corrected here. :-)



> Enabling profiling shouldn’t change the meaning of a program.
>
It doesn't change the meaning, that would really be a desaster, it just
changes the performance characteristics. This is still not nice, but not
much different from using different levels of optimization: Doing or not
doing e.g. strictness analysis might change the space complexity etc.


> I remember back in the day having to be careful with regexes in Python to
> make sure they were always precompiled outside of loops and functions, but
> one of the nice things about Haskell is that one can usually let the
> compiler take care of this. (Nowadays Python gets around this by caching
> compiled regexes, but I prefer Haskell’s statically-optimized approach.)
>
I think totally relying on the compiler for performance is a common
misconception, because things are often more tricky than initially thought.
In our example: Time vs. space tradeoff, and there is no universally
"right" solution.

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

From neil_mayhew at users.sourceforge.net  Fri Dec  8 13:58:12 2017
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Fri, 8 Dec 2017 06:58:12 -0700
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <CAKFCL4V9BZ2w6stJWC3QcF-J56Wh-GqCAHrx9GXfrQJJu_K3-A@mail.gmail.com>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
 <CAKFCL4U_fZDdg56Emg7bmtqao4=RagdHKzDajL6iB3ZYwu+bkw@mail.gmail.com>
 <072d4fc2-6838-dafb-9539-676449b5a9c1@users.sourceforge.net>
 <CAKFCL4V9BZ2w6stJWC3QcF-J56Wh-GqCAHrx9GXfrQJJu_K3-A@mail.gmail.com>
Message-ID: <000280ea-2a1c-aba1-a27c-e114219f8bd4@users.sourceforge.net>

On 2017-12-07 03:33 PM, Brandon Allbery wrote:

    Certainly the behavior here sounds wrong and should be reported.

https://ghc.haskell.org/trac/ghc/ticket/14564 - there’s already been a 
response (from Simon P-J) and it is being treated as a bug.

I get the slowdown with 8.0.2, 8.2.1 and 8.2.2 but 7.10.3 is OK.

Since 8.2.2 is very recent (20 Nov) I didn’t go to the trouble of 
building ghc from source.

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171208/238561c6/attachment.html>

From neil_mayhew at users.sourceforge.net  Fri Dec  8 14:18:42 2017
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Fri, 8 Dec 2017 07:18:42 -0700
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <CANBN=msv9OTqjseHrRR8hXU2Yf-2D1vRFrHMueeZgZZY6GVSVQ@mail.gmail.com>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
 <CANBN=msv9OTqjseHrRR8hXU2Yf-2D1vRFrHMueeZgZZY6GVSVQ@mail.gmail.com>
Message-ID: <1e7c3f48-b45f-db46-75f8-a5f11e12e792@users.sourceforge.net>

On 2017-12-08 01:52 AM, Sven Panne wrote:

    … making something a CAF is not always an optimization: If your
    evaluated CAF uses e.g. hundreds of MB it might be preferable to
    /not/ have it as a CAF, but to to recompute it instead.

Good point. However, I think it would be very hard for the compiler to 
detect which CAFs use a lot of memory and aren’t referred to very often.

    If I haven’t missed something recently, CAFs can’t be garbage
    collected, but I would be happy to be corrected here. :-)

There’s a helpful discussion on the Haskell Wiki here 
<https://wiki.haskell.org/Constant_applicative_form>. In particular, it 
says:

    A CAF … may only be accessible from within the code of one or more
    functions. In order for the garbage collector to be able to reclaim
    such structures, we associate with each function a list of the CAFs
    to which it refers. When garbage collecting a reference to the
    function we collect the CAFs on its list.

In my case, since the function itself is top-level, I assume the CAF 
can’t be garbage-collected.

        Enabling profiling shouldn’t change the meaning of a program.

    It doesn’t change the meaning, that would really be a desaster, it
    just changes the performance characteristics. This is still not
    nice, but not much different from using different levels of
    optimization: Doing or not doing e.g. strictness analysis might
    change the space complexity etc.

Yes, I see you’re right. However, I guess I was using ‘meaning’ loosely 
to mean ‘is a CAF’ and I assumed a CAF would always be floated. The 
above-mentioned wiki page says, “A CAF can always be lifted to the top 
level of the program.” However, I realize “can” is not the same as “should”.

        I remember back in the day having to be careful with regexes in
        Python to make sure they were always precompiled outside of
        loops and functions, but one of the nice things about Haskell is
        that one can usually let the compiler take care of this.
        (Nowadays Python gets around this by caching compiled regexes,
        but I prefer Haskell’s statically-optimized approach.)

    I think totally relying on the compiler for performance is a common
    misconception, because things are often more tricky than initially
    thought. In our example: Time vs. space tradeoff, and there is no
    universally “right” solution.

Good point. Having great optimization isn’t a justification for complete 
mental laziness on the part of the programmer! However, I did find the 
behaviour in this case surprising and unintuitive, given ghc’s usual 
ability to optimize things, and having it change on me when I enabled 
profiling left me wondering where to go next. The code I presented here 
is considerably simplified from the original program, and represents a 
lot of work already expended trying to get to the root of the problem.

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

From hexagoxel at hexagoxel.de  Fri Dec  8 21:02:59 2017
From: hexagoxel at hexagoxel.de (lennart spitzner)
Date: Fri, 8 Dec 2017 22:02:59 +0100
Subject: [Haskell-cafe] [ANN] brittany-0.9.0.0 (on both hackage&stackage)
In-Reply-To: <3cb91c7e-3350-7560-e1de-c3b40ec4765e@hexagoxel.de>
References: <3cb91c7e-3350-7560-e1de-c3b40ec4765e@hexagoxel.de>
Message-ID: <6a0e1eca-ee47-8a8f-a904-0e52ea7bc248@hexagoxel.de>

- Implement `IndentPolicyLeft`: A layouting setting that disables "hanging
  indentation". This indentation mode may become default in the future.
  Only configurable via config-file for the time being.
- (!) commandline interface is reworked slightly to support multiple
  inputs/outputs (`brittany --write-mode=inplace *.hs`).
  This removes the --input/--output flags.
- Ensure compatibility with stackage
- Change default global config path (old configs are still respected)
- Improve support for per-project config
- Fix several bugs and Improve language extension support

full changelog at https://hackage.haskell.org/package/brittany-0.9.0.0/changelog

brittany was recently added to stackage, and should hopefully be included in
the next LTS release.


-- lennart


From allbery.b at gmail.com  Fri Dec  8 23:59:01 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 8 Dec 2017 18:59:01 -0500
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <1e7c3f48-b45f-db46-75f8-a5f11e12e792@users.sourceforge.net>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
 <CANBN=msv9OTqjseHrRR8hXU2Yf-2D1vRFrHMueeZgZZY6GVSVQ@mail.gmail.com>
 <1e7c3f48-b45f-db46-75f8-a5f11e12e792@users.sourceforge.net>
Message-ID: <CAKFCL4XZXKLbpEy6O+RhyYSUVtOP=r3wcmyc91NgCZcEscu+xg@mail.gmail.com>

On Fri, Dec 8, 2017 at 9:18 AM, Neil Mayhew <
neil_mayhew at users.sourceforge.net> wrote:

> Good point. Having great optimization isn’t a justification for complete
> mental laziness on the part of the programmer! However, I did find the
> behaviour in this case surprising and unintuitive, given ghc’s usual
> ability to optimize things, and having it change on me when I enabled
> profiling left me wondering where to go next. The code I presented here is
> considerably simplified from the original program, and represents a lot of
> work already expended trying to get to the root of the problem.
>
This is actually why I (and likely SPJ) am inclined to consider it a bug;
while it might be arguable as Sven does, the counterintuitive effect when
you turn on profiling suggests that it's not intended or expected.
(Although maybe it should be; the intuition is "profiling disables
optimization" but what it really does is a bit more subtle than that overly
simplistic notion.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171208/a2bea59a/attachment.html>

From strake888 at gmail.com  Sat Dec  9 07:36:20 2017
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Fri, 8 Dec 2017 23:36:20 -0800
Subject: [Haskell-cafe] Taking over mtl-tf
Message-ID: <2a7c6bfd-1baf-714d-aef0-26c955d94517@gmail.com>

The maintainer e-mail <trevor at galois.com> seems defunct. Ergo, i mean to take over the package, unless a maintainer comes forth.

From alan.zimm at gmail.com  Sat Dec  9 15:19:44 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sat, 9 Dec 2017 17:19:44 +0200
Subject: [Haskell-cafe] Haskell IDE Engine logo poll
Message-ID: <CANma=H8nH6xFvjGjeMQv=1CGujxUF7kmNxKMOBst0BbsGavUHQ@mail.gmail.com>

Hi

Thanks to Damien Flament we have some logo proposals for the
haskell-ide-engine[1] logo.

Please take a moment to vote for the options at [2].

If there are alternative designs, please feel free to put them forward too,
the issue tracking this is at [3]

We will keep the poll open until Friday noon UTC.

Alan

[1] https://github.com/haskell/haskell-ide-engine
[2] http://www.anonvote.com/poll/dr587990y
[3] https://github.com/haskell/haskell-ide-engine/issues/267
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171209/0d9b235c/attachment.html>

From simon.jakobi at googlemail.com  Sat Dec  9 21:24:57 2017
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sat, 9 Dec 2017 22:24:57 +0100
Subject: [Haskell-cafe] Taking over mtl-tf
In-Reply-To: <2a7c6bfd-1baf-714d-aef0-26c955d94517@gmail.com>
References: <2a7c6bfd-1baf-714d-aef0-26c955d94517@gmail.com>
Message-ID: <CAGtp2SjqgZqQMra4E=nejpLoy3mQ-x=h_EFCc=dNXKntfhYaeg@mail.gmail.com>

CC'ing what appears to be the same Trevor's (https://github.com/elliottt)
current email address.

2017-12-09 8:36 GMT+01:00 M Farkas-Dyck <strake888 at gmail.com>:

> The maintainer e-mail <trevor at galois.com> seems defunct. Ergo, i mean to
> take over the package, unless a maintainer comes forth.
> _______________________________________________
> 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/20171209/4e688976/attachment.html>

From strake888 at gmail.com  Sun Dec 10 09:38:44 2017
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Sun, 10 Dec 2017 01:38:44 -0800
Subject: [Haskell-cafe] Taking over mtl-tf
In-Reply-To: <CAG6R0obMRx-wn8UHh5a3AM2TzmODZZXbmz5=mxr_n8aUoyJy3Q@mail.gmail.com>
References: <2a7c6bfd-1baf-714d-aef0-26c955d94517@gmail.com>
 <CAGtp2SjqgZqQMra4E=nejpLoy3mQ-x=h_EFCc=dNXKntfhYaeg@mail.gmail.com>
 <CAG6R0obMRx-wn8UHh5a3AM2TzmODZZXbmz5=mxr_n8aUoyJy3Q@mail.gmail.com>
Message-ID: <CAL3m8eDPE0=yp=fcJcZgwiNSo7Uyu_8nWKAKG6_XsB6r1WnPEA@mail.gmail.com>

On 09/12/2017, Trevor Elliott <awesomelyawesome at gmail.com> wrote:
> I'm happy to transfer the package to someone else. The old darcs repository
> is long gone and I don't think that I ever migrated it over to github, so
> the package source on hackage is probably all that remains.

Thanks! My Hackage user name is "MatthewFarkasDyck"; would you please
add me to maintainers?

From gershomb at gmail.com  Mon Dec 11 06:36:50 2017
From: gershomb at gmail.com (Gershom B)
Date: Mon, 11 Dec 2017 01:36:50 -0500
Subject: [Haskell-cafe] ANN: New Haskell.org Committee Members
Message-ID: <CAM8RHpGY+Z_kG0cM=usFDEqX4UNgabWecMv_ZEiP85WmgritOg@mail.gmail.com>

Following the self-nomination period and discussion, the Haskell.org
committee has selected the following members for a new three-year
term, expiring 2020:

  * Tikhon Jelvis
  * Ryan Trinkle (reappointment)
  * George Wilson

As per the rules of the committee, this discussion was held among the
current members of the committee, and the outgoing members of the
committee who were not seeking reappointment.

Thank you to all the many candidates who submitted a self-nomination.
We received a number of strong nominations. We would encourage all
those who nominated themselves to consider self-nominating again in
the future.

The outgoing members are: John Wiegley and Alan Zimmerman. Thanks both
for your service!

Regards,
Gershom

From aquagnu at gmail.com  Mon Dec 11 12:03:48 2017
From: aquagnu at gmail.com (Baa)
Date: Mon, 11 Dec 2017 14:03:48 +0200
Subject: [Haskell-cafe] How to call constructor from Template Haskell
Message-ID: <20171211140348.2a1610b1@Pavel>

Hello All!
May be topic is not for Haskell beginners, so I'll re-send it to Cafe.


I have function which constructs some data type. It has signature `Name -> Q [Dec]`.
Somewhere in its body I'm extracting constructors of another type with
pattern-matching:

  case tyCons of
    DataD ctx nm tyVars mbKind cs derivs -> ...
 
Type of those constructors `cs` instantiates some class like this:
 
   class MyClass a where
     specialValue :: a
     
So, I'm iterating over those `cs` but I want to skip one of them which is
equal to `specialValue`. Something like this:
 
   [c | c <- cs, c /= specialValue]
 
How to do this with Template Haskell's `Con` type (`c`::Con)? I can't
simply call it to compare created value with a `specialValue`.
 
===
Best regards, Paul


From takenobu.hs at gmail.com  Mon Dec 11 12:16:25 2017
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Mon, 11 Dec 2017 21:16:25 +0900
Subject: [Haskell-cafe] Who can send a patche to vim project?
Message-ID: <CAPB_NvzMGZS3OYEAXuqRCXyx_hsXYf8JaCj0S6cJ=VJeH-KwtQ@mail.gmail.com>

Hi cafe,

Who can send a patche to vim project?

I'd like to update vim syntax file (haskell.vim) to fix numeric literals.
I read the vim `CONTRIBUTING.md` file [1].
It instructs me to contact the maintainer of each files.
In the header of `haskell.vim`, the maintainor of `haskell.vim` is
haskell-cafe at ML. [2]
Who is the maintainer of `haskell.vim`?

I'd like to make fix on numeric literals extension: [3]
  * BinaryLiterals
  * HexFloatLiterals
  * NumericUnderscores

I prepared two kinds of patches.
  * Exact pattern version [4]
  * Fast (but approximate) pattern version [5]

I visually checked patches with the these files [6][7].

Could you send a patch of [4] or [5] to vim project?


P.S.
I have already sent patches to two projects.

  * `language-haskell` for atom and linguist [8]
      You can already use it on atom.
      Linghist (which is used from github) will apply it soon.

  * `pygments` [9]
      It is pending review.


[1]:
https://github.com/vim/vim/blob/master/CONTRIBUTING.md#syntax-indent-and-other-runtime-files
[2]: https://github.com/vim/vim/blob/master/runtime/syntax/haskell.vim#L3
[3]:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009-numeric-underscores.rst#new-syntax-this-proposal
[4]:
https://github.com/vim/vim/compare/master...takenobu-hs:syntax-haskell-literal-exact
[5]:
https://github.com/vim/vim/compare/master...takenobu-hs:syntax-haskell-literal-fast

[6]:
https://github.com/takenobu-hs/ghc/blob/squashed-numeric-underscores/testsuite/tests/parser/should_run/NumericUnderscores0.hs
[7]:
https://github.com/takenobu-hs/ghc/blob/squashed-numeric-underscores/testsuite/tests/parser/should_run/NumericUnderscores1.hs

[8]:
https://github.com/atom-haskell/language-haskell/commit/f90eb7d8662493536f54898e52b4c7b1dc96de41
[9]:
https://bitbucket.org/birkenfeld/pygments-main/issues/1399/update-haskell-with-lexer-for-numeric

Regards,
Takenobu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171211/865ff7bf/attachment.html>

From alan.zimm at gmail.com  Mon Dec 11 12:17:54 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 11 Dec 2017 14:17:54 +0200
Subject: [Haskell-cafe] Haskell IDE Engine logo poll
In-Reply-To: <CANma=H8nH6xFvjGjeMQv=1CGujxUF7kmNxKMOBst0BbsGavUHQ@mail.gmail.com>
References: <CANma=H8nH6xFvjGjeMQv=1CGujxUF7kmNxKMOBst0BbsGavUHQ@mail.gmail.com>
Message-ID: <CANma=H_PaqbirxKdE=Q78614gC3yABCNi9-hQ3uLRG4g+wtUkQ@mail.gmail.com>

As noted in the reddit thread [1], we are open to new suggestions too, and
have already received some


"As some new logo proposals have been made, a new poll will be launched
when the current poll ends (next Friday).

Candidates will be the winner of the current poll and other proposals made
until Friday considered pertinent by the HIE team.

You can submit new proposal here or in the GitHub related issue ticket
<https://github.com/haskell/haskell-ide-engine/issues/267>.

*Feel free to submit your logo "*

Alan

[1]
https://www.reddit.com/r/haskell/comments/7in9ab/haskellcafe_haskell_ide_engine_logo_poll/dr2yes5/




On 9 December 2017 at 17:19, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> Hi
>
> Thanks to Damien Flament we have some logo proposals for the
> haskell-ide-engine[1] logo.
>
> Please take a moment to vote for the options at [2].
>
> If there are alternative designs, please feel free to put them forward
> too, the issue tracking this is at [3]
>
> We will keep the poll open until Friday noon UTC.
>
> Alan
>
> [1] https://github.com/haskell/haskell-ide-engine
> [2] http://www.anonvote.com/poll/dr587990y
> [3] https://github.com/haskell/haskell-ide-engine/issues/267
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171211/1fbe5041/attachment.html>

From david.feuer at gmail.com  Mon Dec 11 13:04:50 2017
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 11 Dec 2017 08:04:50 -0500
Subject: [Haskell-cafe] Maintenance of streaming and streaming-bytestring
In-Reply-To: <CAJ0eudpxjwsU_B5JhEOvdo74PqkxJxaeuYmbUU_YmYHX_uOiTw@mail.gmail.com>
References: <CABNC7ePqjnTYpNMOuGC=QhUph_Rs5DaNkXmgTbZwtDsLdVKvFA@mail.gmail.com>
 <CABNC7eN=QbV8bSDQ7CZNA-WO2t2eBdG-u3PrFJ2v99F8v-ax4w@mail.gmail.com>
 <CAPeieQEDbNtDHk5eNYfQM03eHAuM2w3iMmpG6zL28-YzWyeRkg@mail.gmail.com>
 <CABNC7eMyJf=uo=_pAvPrRX400sjTP5pymgmsszdJHSA=4PFNfQ@mail.gmail.com>
 <CABNC7eOPDUJHNPpSR7ZjAoNaZu5Ci5MjimxuAFSh96rBUdo=PQ@mail.gmail.com>
 <CA+u6gbwM2-gEThseHfNAGi_Fgdk-V43nAVV3XVCHAU5y0HNvwQ@mail.gmail.com>
 <CAMgWh9t6VJ1eQQQ0bh0a2T2hUh9di4D+t5GYtYnLO3WUXjqaaw@mail.gmail.com>
 <CAHYVw0zTaBiKGEitqYa1f4pV0zDHXcNqchJ_PGRjpdT-5i5nng@mail.gmail.com>
 <CAMgWh9v11pX+xyLyhy05yQKt05gwLqh4ABxwQJwY8uhUaohVkw@mail.gmail.com>
 <CAJ0eudpxjwsU_B5JhEOvdo74PqkxJxaeuYmbUU_YmYHX_uOiTw@mail.gmail.com>
Message-ID: <CAMgWh9tcHcb3-25WOLN9n99ENuOus5Ez8MXyOrT3i303pSE=tQ@mail.gmail.com>

I've added you as a member of haskell-streaming. Feel free to transfer the repo.

On Sat, Dec 9, 2017 at 10:10 AM, Boespflug, Mathieu <m at tweag.io> wrote:
> I'd like to contributed streaming-binary to the streaming GitHub org, if
> you're up for it.
>
> http://hackage.haskell.org/package/streaming-binary
>
> Best,
>
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
> On 17 September 2017 at 01:24, David Feuer <david.feuer at gmail.com> wrote:
>>
>> Ah, right. Then yes, that sounds like a great approach.
>>
>> On Sep 15, 2017 1:23 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
>> wrote:
>>>
>>> GitHub has a transfer repo ownership toggle you can do to move the main
>>> repo and it's assets
>>>
>>> On Fri, Sep 15, 2017 at 1:05 PM David Feuer <david.feuer at gmail.com>
>>> wrote:
>>>>
>>>> Having an organization (with multiple owners and members) makes for much
>>>> smoother transitions when maintainers change. That goes triple for
>>>> unexpected changes. There's (still!) no really good way to migrate an issue
>>>> tracker or PRs from one repository to another. Unfortunately, for that same
>>>> reason, I believe that actually moving your project to the organization will
>>>> be quite unpleasant if there are more than a few open tickets. And if there
>>>> are more than a few closed tickets, then preserving history in a useful
>>>> history seems hard too. Maybe someone else knows a reason this isn't
>>>> actually terrible.
>>>>
>>>> David
>>>>
>>>> On Sep 14, 2017 1:10 AM, "Ivan Lazar Miljenovic"
>>>> <ivan.miljenovic at gmail.com> wrote:
>>>>
>>>> Since you've seem to set this up as an organisation, would you be
>>>> interested in my moving over the various streaming libraries I have
>>>> there as well?
>>>>
>>>> On 14 September 2017 at 03:31, Andrew Martin <andrew.thaddeus at gmail.com>
>>>> wrote:
>>>> > The streaming and streaming-bytestring libraries are now being
>>>> > maintained
>>>> > here: https://github.com/haskell-streaming
>>>> >
>>>> > On Tue, Sep 12, 2017 at 4:50 PM, Andrew Martin
>>>> > <andrew.thaddeus at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Thanks adding me as a maintainer. I'm new to this process, so I
>>>> >> appreciate
>>>> >> the tip about admin at hackage.haskell.org as well.
>>>> >>
>>>> >> -Andrew Martin
>>>> >>
>>>> >> On Tue, Sep 12, 2017 at 3:57 PM, Erik Hesselink <hesselink at gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> Hi Andrew,
>>>> >>>
>>>> >>> We usually allow about 3 weeks for the maintainer to respond. Since
>>>> >>> that
>>>> >>> time has now passed I've added you as a maintainer for streaming and
>>>> >>> streaming-bytestring. Let me know if there's anything else you need.
>>>> >>>
>>>> >>> For others looking to take over a package in the future, please CC
>>>> >>> admin at hackage.haskell.org, there's a higher chance I'll see it there
>>>> >>> than
>>>> >>> just on the email lists.
>>>> >>>
>>>> >>> Regards,
>>>> >>>
>>>> >>> Erik (hackage admin)
>>>> >>>
>>>> >>> On 12 September 2017 at 20:18, Andrew Martin
>>>> >>> <andrew.thaddeus at gmail.com>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> Are there any further steps that I can take?
>>>> >>>>
>>>> >>>> On Thu, Sep 7, 2017 at 11:07 AM, Andrew Martin
>>>> >>>> <andrew.thaddeus at gmail.com> wrote:
>>>> >>>>>
>>>> >>>>> David Feuer brought this up two weeks ago [0]. The maintainer of
>>>> >>>>> streaming and streaming-bytestring has been unreachable, and
>>>> >>>>> provided his
>>>> >>>>> continued absence, I would like to become a maintainer of these
>>>> >>>>> two
>>>> >>>>> libraries. I have put up PRs fixing issues [1] and I've offered on
>>>> >>>>> the issue
>>>> >>>>> tracker to become a comaintainer [2]. I use this library a lot at
>>>> >>>>> work, so I
>>>> >>>>> have an interest in keeping it in good shape.
>>>> >>>>>
>>>> >>>>> [0]
>>>> >>>>>
>>>> >>>>> https://mail.haskell.org/pipermail/libraries/2017-August/028141.html
>>>> >>>>> [1] https://github.com/michaelt/streaming-bytestring/pull/11
>>>> >>>>> [2] https://github.com/michaelt/streaming-bytestring/issues/19
>>>> >>>>>
>>>> >>>>> --
>>>> >>>>> -Andrew Thaddeus Martin
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> -Andrew Thaddeus Martin
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> Libraries mailing list
>>>> >>>> Libraries at haskell.org
>>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> -Andrew Thaddeus Martin
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > -Andrew Thaddeus Martin
>>>> >
>>>> > _______________________________________________
>>>> > 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.
>>>>
>>>>
>>>>
>>>> --
>>>> Ivan Lazar Miljenovic
>>>> Ivan.Miljenovic at gmail.com
>>>> http://IvanMiljenovic.wordpress.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.
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>

From althainz at gmail.com  Mon Dec 11 17:13:16 2017
From: althainz at gmail.com (Peter Althainz)
Date: Mon, 11 Dec 2017 18:13:16 +0100
Subject: [Haskell-cafe] Unsubscribe
In-Reply-To: <CAKS-SOmi_qKf-3-ZnBwMmisGk4iyF7-PPfvnSETNf7pvVvUchw@mail.gmail.com>
References: <CAKS-SOkmcTPHEeWNcmZuMSEKL5OfmccBpgkLOBxGmOf5vmoY2Q@mail.gmail.com>
 <CAKS-SOmi_qKf-3-ZnBwMmisGk4iyF7-PPfvnSETNf7pvVvUchw@mail.gmail.com>
Message-ID: <CAKS-SOk-kunjJJgv8Jumzv+_sLjPiPTYBEK+n0S7Huzzhu+Ocw@mail.gmail.com>

Am 11.12.2017 1:32 nachm. schrieb <haskell-cafe-request at haskell.org>:

Send Haskell-Cafe mailing list submissions to
        haskell-cafe at haskell.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
or, via email, send a message with subject or body 'help' to
        haskell-cafe-request at haskell.org

You can reach the person managing the list at
        haskell-cafe-owner at haskell.org

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


Today's Topics:

   1. ANN: New Haskell.org Committee Members (Gershom B)
   2. How to call constructor from Template Haskell (Baa)
   3. Who can send a patche to vim project? (Takenobu Tani)
   4. Re: Haskell IDE Engine logo poll (Alan & Kim Zimmerman)


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

Message: 1
Date: Mon, 11 Dec 2017 01:36:50 -0500
From: Gershom B <gershomb at gmail.com>
To: haskell-cafe <haskell-cafe at haskell.org>,
        haskell-community at haskell.org,  Tikhon Jelvis <tikhon at jelv.is>, Ryan
        Trinkle <ryan.trinkle at gmail.com>, george at wils.online
Subject: [Haskell-cafe] ANN: New Haskell.org Committee Members
Message-ID:
        <CAM8RHpGY+Z_kG0cM=usFDEqX4UNgabWecMv_ZEiP85WmgritOg at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Following the self-nomination period and discussion, the Haskell.org
committee has selected the following members for a new three-year
term, expiring 2020:

  * Tikhon Jelvis
  * Ryan Trinkle (reappointment)
  * George Wilson

As per the rules of the committee, this discussion was held among the
current members of the committee, and the outgoing members of the
committee who were not seeking reappointment.

Thank you to all the many candidates who submitted a self-nomination.
We received a number of strong nominations. We would encourage all
those who nominated themselves to consider self-nominating again in
the future.

The outgoing members are: John Wiegley and Alan Zimmerman. Thanks both
for your service!

Regards,
Gershom


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

Message: 2
Date: Mon, 11 Dec 2017 14:03:48 +0200
From: Baa <aquagnu at gmail.com>
To: Haskell Cafe <haskell-cafe at haskell.org>
Subject: [Haskell-cafe] How to call constructor from Template Haskell
Message-ID: <20171211140348.2a1610b1 at Pavel>
Content-Type: text/plain; charset=US-ASCII

Hello All!
May be topic is not for Haskell beginners, so I'll re-send it to Cafe.


I have function which constructs some data type. It has signature `Name ->
Q [Dec]`.
Somewhere in its body I'm extracting constructors of another type with
pattern-matching:

  case tyCons of
    DataD ctx nm tyVars mbKind cs derivs -> ...

Type of those constructors `cs` instantiates some class like this:

   class MyClass a where
     specialValue :: a

So, I'm iterating over those `cs` but I want to skip one of them which is
equal to `specialValue`. Something like this:

   [c | c <- cs, c /= specialValue]

How to do this with Template Haskell's `Con` type (`c`::Con)? I can't
simply call it to compare created value with a `specialValue`.

===
Best regards, Paul



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

Message: 3
Date: Mon, 11 Dec 2017 21:16:25 +0900
From: Takenobu Tani <takenobu.hs at gmail.com>
To: haskell-cafe <haskell-cafe at haskell.org>
Subject: [Haskell-cafe] Who can send a patche to vim project?
Message-ID:
        <CAPB_NvzMGZS3OYEAXuqRCXyx_hsXYf8JaCj0S6cJ=VJeH-KwtQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi cafe,

Who can send a patche to vim project?

I'd like to update vim syntax file (haskell.vim) to fix numeric literals.
I read the vim `CONTRIBUTING.md` file [1].
It instructs me to contact the maintainer of each files.
In the header of `haskell.vim`, the maintainor of `haskell.vim` is
haskell-cafe at ML. [2]
Who is the maintainer of `haskell.vim`?

I'd like to make fix on numeric literals extension: [3]
  * BinaryLiterals
  * HexFloatLiterals
  * NumericUnderscores

I prepared two kinds of patches.
  * Exact pattern version [4]
  * Fast (but approximate) pattern version [5]

I visually checked patches with the these files [6][7].

Could you send a patch of [4] or [5] to vim project?


P.S.
I have already sent patches to two projects.

  * `language-haskell` for atom and linguist [8]
      You can already use it on atom.
      Linghist (which is used from github) will apply it soon.

  * `pygments` [9]
      It is pending review.


[1]:
https://github.com/vim/vim/blob/master/CONTRIBUTING.md#
syntax-indent-and-other-runtime-files
[2]: https://github.com/vim/vim/blob/master/runtime/syntax/haskell.vim#L3
[3]:
https://github.com/ghc-proposals/ghc-proposals/blob/
master/proposals/0009-numeric-underscores.rst#new-syntax-this-proposal
[4]:
https://github.com/vim/vim/compare/master...takenobu-hs:
syntax-haskell-literal-exact
[5]:
https://github.com/vim/vim/compare/master...takenobu-hs:
syntax-haskell-literal-fast

[6]:
https://github.com/takenobu-hs/ghc/blob/squashed-numeric-
underscores/testsuite/tests/parser/should_run/NumericUnderscores0.hs
[7]:
https://github.com/takenobu-hs/ghc/blob/squashed-numeric-
underscores/testsuite/tests/parser/should_run/NumericUnderscores1.hs

[8]:
https://github.com/atom-haskell/language-haskell/commit/
f90eb7d8662493536f54898e52b4c7b1dc96de41
[9]:
https://bitbucket.org/birkenfeld/pygments-main/issues/1399/update-haskell-
with-lexer-for-numeric

Regards,
Takenobu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/
attachments/20171211/865ff7bf/attachment-0001.html>

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

Message: 4
Date: Mon, 11 Dec 2017 14:17:54 +0200
From: "Alan & Kim Zimmerman" <alan.zimm at gmail.com>
To: haskell <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Haskell IDE Engine logo poll
Message-ID:
        <CANma=H_PaqbirxKdE=Q78614gC3yABCNi9-hQ3uLRG4g+wtUkQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

As noted in the reddit thread [1], we are open to new suggestions too, and
have already received some


"As some new logo proposals have been made, a new poll will be launched
when the current poll ends (next Friday).

Candidates will be the winner of the current poll and other proposals made
until Friday considered pertinent by the HIE team.

You can submit new proposal here or in the GitHub related issue ticket
<https://github.com/haskell/haskell-ide-engine/issues/267>.

*Feel free to submit your logo "*

Alan

[1]
https://www.reddit.com/r/haskell/comments/7in9ab/haskellcafe_haskell_ide_
engine_logo_poll/dr2yes5/




On 9 December 2017 at 17:19, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> Hi
>
> Thanks to Damien Flament we have some logo proposals for the
> haskell-ide-engine[1] logo.
>
> Please take a moment to vote for the options at [2].
>
> If there are alternative designs, please feel free to put them forward
> too, the issue tracking this is at [3]
>
> We will keep the poll open until Friday noon UTC.
>
> Alan
>
> [1] https://github.com/haskell/haskell-ide-engine
> [2] http://www.anonvote.com/poll/dr587990y
> [3] https://github.com/haskell/haskell-ide-engine/issues/267
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/
attachments/20171211/1fbe5041/attachment-0001.html>

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

Subject: Digest Footer

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


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

End of Haskell-Cafe Digest, Vol 172, Issue 11
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171211/810dc21b/attachment.html>

From takenobu.hs at gmail.com  Tue Dec 12 12:29:30 2017
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 12 Dec 2017 21:29:30 +0900
Subject: [Haskell-cafe] Who can send a patche to vim project?
In-Reply-To: <CAPB_NvzMGZS3OYEAXuqRCXyx_hsXYf8JaCj0S6cJ=VJeH-KwtQ@mail.gmail.com>
References: <CAPB_NvzMGZS3OYEAXuqRCXyx_hsXYf8JaCj0S6cJ=VJeH-KwtQ@mail.gmail.com>
Message-ID: <CAPB_NvxDWMg_6zQsBBoocvGPvrxGNLq-TNPy5d4LUEL=0Fq79Q@mail.gmail.com>

Hi cafe,

I'll directly contact the vim-dev maillist :)

Thanks,
Takenobu


2017-12-11 21:16 GMT+09:00 Takenobu Tani <takenobu.hs at gmail.com>:

> Hi cafe,
>
> Who can send a patche to vim project?
>
> I'd like to update vim syntax file (haskell.vim) to fix numeric literals.
> I read the vim `CONTRIBUTING.md` file [1].
> It instructs me to contact the maintainer of each files.
> In the header of `haskell.vim`, the maintainor of `haskell.vim` is
> haskell-cafe at ML. [2]
> Who is the maintainer of `haskell.vim`?
>
> I'd like to make fix on numeric literals extension: [3]
>   * BinaryLiterals
>   * HexFloatLiterals
>   * NumericUnderscores
>
> I prepared two kinds of patches.
>   * Exact pattern version [4]
>   * Fast (but approximate) pattern version [5]
>
> I visually checked patches with the these files [6][7].
>
> Could you send a patch of [4] or [5] to vim project?
>
>
> P.S.
> I have already sent patches to two projects.
>
>   * `language-haskell` for atom and linguist [8]
>       You can already use it on atom.
>       Linghist (which is used from github) will apply it soon.
>
>   * `pygments` [9]
>       It is pending review.
>
>
> [1]: https://github.com/vim/vim/blob/master/CONTRIBUTING.md#
> syntax-indent-and-other-runtime-files
> [2]: https://github.com/vim/vim/blob/master/runtime/syntax/haskell.vim#L3
> [3]: https://github.com/ghc-proposals/ghc-proposals/blob/
> master/proposals/0009-numeric-underscores.rst#new-syntax-this-proposal
> [4]: https://github.com/vim/vim/compare/master...takenobu-hs:
> syntax-haskell-literal-exact
> [5]: https://github.com/vim/vim/compare/master...takenobu-hs:
> syntax-haskell-literal-fast
>
> [6]: https://github.com/takenobu-hs/ghc/blob/squashed-numeric-
> underscores/testsuite/tests/parser/should_run/NumericUnderscores0.hs
> [7]: https://github.com/takenobu-hs/ghc/blob/squashed-numeric-
> underscores/testsuite/tests/parser/should_run/NumericUnderscores1.hs
>
> [8]: https://github.com/atom-haskell/language-haskell/commit/
> f90eb7d8662493536f54898e52b4c7b1dc96de41
> [9]: https://bitbucket.org/birkenfeld/pygments-main/
> issues/1399/update-haskell-with-lexer-for-numeric
>
> Regards,
> Takenobu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171212/c06a89a7/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Tue Dec 12 13:20:11 2017
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 12 Dec 2017 14:20:11 +0100
Subject: [Haskell-cafe] how to run in bounded space?
Message-ID: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>

Dear Cafe.

is there an easy way (in GHC Haskell)
to run a computation until it (times out or)
requires more than X  MB of heap?

(the main program  has a larger heap,
but the computation should use some part of it only)

This would be nice for automated tests
with predictable resources (time and space).

There is Control.Timeout.
I guess I want Control.Spaceout.

- J.


From ollie at ocharles.org.uk  Tue Dec 12 13:58:57 2017
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Tue, 12 Dec 2017 13:58:57 +0000
Subject: [Haskell-cafe] how to run in bounded space?
In-Reply-To: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
References: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
Message-ID: <CAGRp5RkEz9z_SB0UBUdaPNX1NJERmM1OFQvGzmbfmfiGhzFwAQ@mail.gmail.com>

This can be done using RTS options I believe. Compile with -rtsopts and
then run your program with +RTS -help and look for the heap options.

If you want to scope it within your program, I'm not sure about that.

Ollie

On 12 Dec 2017 1:24 pm, "Johannes Waldmann" <
johannes.waldmann at htwk-leipzig.de> wrote:

> Dear Cafe.
>
> is there an easy way (in GHC Haskell)
> to run a computation until it (times out or)
> requires more than X  MB of heap?
>
> (the main program  has a larger heap,
> but the computation should use some part of it only)
>
> This would be nice for automated tests
> with predictable resources (time and space).
>
> There is Control.Timeout.
> I guess I want Control.Spaceout.
>
> - J.
>
> _______________________________________________
> 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/20171212/d3825eaa/attachment.html>

From benjamin.peter.doyle at gmail.com  Tue Dec 12 14:21:54 2017
From: benjamin.peter.doyle at gmail.com (Ben Doyle)
Date: Tue, 12 Dec 2017 14:21:54 +0000
Subject: [Haskell-cafe] how to run in bounded space?
In-Reply-To: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
References: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
Message-ID: <CANhNgPGZLKv_RdZG4Lo5S4bX75A5uT46rcYLE7BKoJBTea+JbQ@mail.gmail.com>

This sounds like Edward Yang’s work on resource limits:
http://ezyang.com/papers/ezyang13-rlimits.pdf

I don’t think the relevant patches ever made it into GHC.
https://ghc.haskell.org/trac/ghc/ticket/7763 They weren’t rejected either.
It seems like a case that just needs more interested people.

On Tue, Dec 12, 2017 at 5:23 AM Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Dear Cafe.
>
> is there an easy way (in GHC Haskell)
> to run a computation until it (times out or)
> requires more than X  MB of heap?
>
> (the main program  has a larger heap,
> but the computation should use some part of it only)
>
> This would be nice for automated tests
>
with predictable resources especially  (time and space).


>
> There is Control.Timeout.
> I guess I want Control.Spaceout.
>
> - J.
>
> _______________________________________________
> 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/20171212/f1859e50/attachment.html>

From allbery.b at gmail.com  Tue Dec 12 16:38:48 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 12 Dec 2017 11:38:48 -0500
Subject: [Haskell-cafe] how to run in bounded space?
In-Reply-To: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
References: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
Message-ID: <CAKFCL4V2q0FH6GThJhw6VPBYqQr1st6K6EdJ+Jza8bQRdRH0tw@mail.gmail.com>

Currently the heap overflow exception is not catchable. IIRC this is
planned to be at least looked at for 8.6 (I don't think it made 8.4rc
branch).

On Tue, Dec 12, 2017 at 8:20 AM, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Dear Cafe.
>
> is there an easy way (in GHC Haskell)
> to run a computation until it (times out or)
> requires more than X  MB of heap?
>
> (the main program  has a larger heap,
> but the computation should use some part of it only)
>
> This would be nice for automated tests
> with predictable resources (time and space).
>
> There is Control.Timeout.
> I guess I want Control.Spaceout.
>
> - J.
>
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171212/54c6dc20/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Tue Dec 12 18:52:26 2017
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 12 Dec 2017 19:52:26 +0100
Subject: [Haskell-cafe] how to run in bounded space?
In-Reply-To: <CAKFCL4V2q0FH6GThJhw6VPBYqQr1st6K6EdJ+Jza8bQRdRH0tw@mail.gmail.com>
References: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
 <CAKFCL4V2q0FH6GThJhw6VPBYqQr1st6K6EdJ+Jza8bQRdRH0tw@mail.gmail.com>
Message-ID: <30b802b8-b145-b7c4-6964-45d5fdacc022@htwk-leipzig.de>

Thanks for the replies.

> Currently the heap overflow exception is not catchable.

um, perhaps I can use this:
https://hackage.haskell.org/package/base-4.10.1.0/docs/GHC-Conc.html#v:enableAllocationLimit

- J

From allbery.b at gmail.com  Tue Dec 12 18:57:28 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 12 Dec 2017 13:57:28 -0500
Subject: [Haskell-cafe] how to run in bounded space?
In-Reply-To: <30b802b8-b145-b7c4-6964-45d5fdacc022@htwk-leipzig.de>
References: <b6d8d455-5e0e-bd50-fb1d-215a0b70540d@htwk-leipzig.de>
 <CAKFCL4V2q0FH6GThJhw6VPBYqQr1st6K6EdJ+Jza8bQRdRH0tw@mail.gmail.com>
 <30b802b8-b145-b7c4-6964-45d5fdacc022@htwk-leipzig.de>
Message-ID: <CAKFCL4XYXvJ5+BgN4S2ryr+f_qLB0xWt5VkQS05gx8a7iUgXeA@mail.gmail.com>

IIRC that has some weird caveats. Might work for your use case, might not.

On Tue, Dec 12, 2017 at 1:52 PM, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Thanks for the replies.
>
> > Currently the heap overflow exception is not catchable.
>
> um, perhaps I can use this:
> https://hackage.haskell.org/package/base-4.10.1.0/docs/GHC-Conc.html#v:
> enableAllocationLimit
>
> - J
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171212/961e9597/attachment.html>

From kyrab at mail.ru  Wed Dec 13 12:19:12 2017
From: kyrab at mail.ru (kyra)
Date: Wed, 13 Dec 2017 15:19:12 +0300
Subject: [Haskell-cafe] [ANN] Experimental Windows GHC 8.2.2+ 64-bit binary
 release. Binary compatible with Visual C/Native Windows SDK.
Message-ID: <9a6acfc5-69df-b1bc-c04d-c0705484d4cd@mail.ru>

An experimental Windows GHC 8.2.2+ 64-bit Visual C/Native Windows SDK 
binary compatible distribution is released.

The distro is based on and targets Microsoft Visual C runtime and native 
Windows SDK.

The code it produces is statically linkable with Microsoft Visual C and 
native Windows SDK libraries.

Both Visual Studio 2013 and 2017/2015 are supported.

Distribution site: https://awson.github.io/ghc-nw/.

Cheers,
K. Briantsev (aka awson)


From hjgtuyl at chello.nl  Thu Dec 14 03:20:00 2017
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Thu, 14 Dec 2017 04:20:00 +0100
Subject: [Haskell-cafe] 25th Anniversary of GHC
Message-ID: <op.za7vjr0xpz0j5l@alquantor>


L.S.,

The eleventh of this month was the 25th anniversary of GHC: the first full  
release of GHC was announced at 1992-12-11; the version number was 0.10  
and a Sun 4 workstation was needed to run GHC.
The announcement can be read at:
     http://code.haskell.org/~dons/haskell-1990-2000/msg00960.html

Regards,
Henk-Jan van Tuyl


-- 
Message from Stanford University:

Folding at home

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

--
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From kc1956 at gmail.com  Thu Dec 14 03:48:43 2017
From: kc1956 at gmail.com (KC)
Date: Wed, 13 Dec 2017 19:48:43 -0800
Subject: [Haskell-cafe] 25th Anniversary of GHC
In-Reply-To: <op.za7vjr0xpz0j5l@alquantor>
References: <op.za7vjr0xpz0j5l@alquantor>
Message-ID: <CAMLKXyk9a+fdLJmuFb=QD1RCdoXqFHXkKbgZUk8xtu6Ump_fWQ@mail.gmail.com>

Please let us compile our good wishes 😁

--
Sent from an expensive device which will be obsolete in a few months
Casey

On Dec 13, 2017 7:20 PM, "Henk-Jan van Tuyl" <hjgtuyl at chello.nl> wrote:

>
> L.S.,
>
> The eleventh of this month was the 25th anniversary of GHC: the first full
> release of GHC was announced at 1992-12-11; the version number was 0.10 and
> a Sun 4 workstation was needed to run GHC.
> The announcement can be read at:
>     http://code.haskell.org/~dons/haskell-1990-2000/msg00960.html
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Message from Stanford University:
>
> Folding at home
>
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://foldingathome.stanford.edu/
>
> --
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --
> _______________________________________________
> 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/20171213/a6cb0acd/attachment.html>

From gershomb at gmail.com  Thu Dec 14 04:42:22 2017
From: gershomb at gmail.com (Gershom B)
Date: Wed, 13 Dec 2017 23:42:22 -0500
Subject: [Haskell-cafe] Announce: Haskell Platform 8.2.2
Message-ID: <CAM8RHpGFk8iiz-WTvR9uhVNs-3h7hx0x-zBWC=Kp-XVnZMrVrQ@mail.gmail.com>

On behalf of the Haskell Platform team, I'm happy to announce the release of

Haskell Platform 8.2.2

Now available at

https://www.haskell.org/platform/

This includes GHC 8.2.2, cabal-install 2.0.0.1, and stack 1.6.1, all
with many bugfixes since the last platform release.

A full list of contents is available at
https://www.haskell.org/platform/contents.html

Thanks to all the contributors to this release, thanks to all the
package and tool maintainers and authors, and a big thanks to the GHC
team for all their hard work.

There are currently no 32 bit Windows builds available. We expect to
have those out in short order.

A list of new GHC changes is available at:
https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.2-released

A list of cabal changes is available at:
https://hackage.haskell.org/package/cabal-install-2.0.0.1/changelog

The cabal documentation page is at:
https://www.haskell.org/cabal/users-guide/

A list of stack changes is at:
https://docs.haskellstack.org/en/stable/ChangeLog/

The stack documentation page is at:
https://docs.haskellstack.org/en/stable/README/

Happy Haskell Hacking all,
Gershom

From qdunkan at gmail.com  Thu Dec 14 05:34:13 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed, 13 Dec 2017 21:34:13 -0800
Subject: [Haskell-cafe] coercing D a to D b
Message-ID: <CACbaDy6JF7tCz5ONv2Z7uWG+q1kSU+QUHTMN=4P1WxofNSMs1A@mail.gmail.com>

Given:

data D a = A a | B Int Char

dmapNoCoerce :: (a -> b) -> D a -> D b
dmapNoCoerce f (A a) = A (f a)
dmapNoCoerce _ (B i c) = B i c

I have to reconstruct a B change it from D a to D b.  But at the lower level,
couldn't this be implemented as a type cast?  What prevents such an
optimization?

I can write this as

dmapCoerce :: (a -> b) -> D a -> D b
dmapCoerce f (A a) = A (f a)
dmapCoerce _ b@(B {}) = Unsafe.Coerce.unsafeCoerce b

>From the core, it looks like dmapCoerce indeed has a cast with no allocation,
while dmapNoCoerce allocates a new B.

It seems to work, but is it safe?  Is there a more principled way to do it?
I can't convince Data.Coerce to cooperate, presumably because 'a' and 'b' are
not coercible themselves, and it doesn't believe me if I try to tell it the
type role is phantom.

From mail at joachim-breitner.de  Thu Dec 14 15:16:10 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 14 Dec 2017 10:16:10 -0500
Subject: [Haskell-cafe] coercing D a to D b
In-Reply-To: <CACbaDy6JF7tCz5ONv2Z7uWG+q1kSU+QUHTMN=4P1WxofNSMs1A@mail.gmail.com>
References: <CACbaDy6JF7tCz5ONv2Z7uWG+q1kSU+QUHTMN=4P1WxofNSMs1A@mail.gmail.com>
Message-ID: <1513264570.4583.1.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 13.12.2017, 21:34 -0800 schrieb Evan Laforge:
> Given:
> 
> data D a = A a | B Int Char
> 
> dmapNoCoerce :: (a -> b) -> D a -> D b
> dmapNoCoerce f (A a) = A (f a)
> dmapNoCoerce _ (B i c) = B i c
> 
> I have to reconstruct a B change it from D a to D b.  But at the lower level,
> couldn't this be implemented as a type cast?  What prevents such an
> optimization?
> 
> I can write this as
> 
> dmapCoerce :: (a -> b) -> D a -> D b
> dmapCoerce f (A a) = A (f a)
> dmapCoerce _ b@(B {}) = Unsafe.Coerce.unsafeCoerce b
> 
> From the core, it looks like dmapCoerce indeed has a cast with no allocation,
> while dmapNoCoerce allocates a new B.
> 
> It seems to work, but is it safe?  Is there a more principled way to do it?
> I can't convince Data.Coerce to cooperate, presumably because 'a' and 'b' are
> not coercible themselves, and it doesn't believe me if I try to tell it the
> type role is phantom.


this coercion is not possible in Core, because Core’s type system is
not expressive enough (at least now…). But luckily, at the STG level
this optimization is possible, see
https://git.haskell.org/ghc.git/commitdiff/19d5c7312bf0ad9ae764168132aecf3696d5410b

This is probably in 8.2.

Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171214/d53749eb/attachment.sig>

From qdunkan at gmail.com  Fri Dec 15 00:53:27 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu, 14 Dec 2017 16:53:27 -0800
Subject: [Haskell-cafe] coercing D a to D b
In-Reply-To: <1513264570.4583.1.camel@joachim-breitner.de>
References: <CACbaDy6JF7tCz5ONv2Z7uWG+q1kSU+QUHTMN=4P1WxofNSMs1A@mail.gmail.com>
 <1513264570.4583.1.camel@joachim-breitner.de>
Message-ID: <CACbaDy5OR023sYq6vPmVGhAQ_sJXO-=aWJB=GX-zVdGGQW1-Qg@mail.gmail.com>

Nice, it looks like "Note [Case 2: CSEing case binders]" applies to
what I was talking about.

I assume once I can upgrade to 8.2 (or 8.4 more likely) then both my
examples should wind up looking different at the core level, but then
both be a coerce in STG?  Well, I guess implicitly a coerce since STG
doesn't have types like that.


On Thu, Dec 14, 2017 at 7:16 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Mittwoch, den 13.12.2017, 21:34 -0800 schrieb Evan Laforge:
>> Given:
>>
>> data D a = A a | B Int Char
>>
>> dmapNoCoerce :: (a -> b) -> D a -> D b
>> dmapNoCoerce f (A a) = A (f a)
>> dmapNoCoerce _ (B i c) = B i c
>>
>> I have to reconstruct a B change it from D a to D b.  But at the lower level,
>> couldn't this be implemented as a type cast?  What prevents such an
>> optimization?
>>
>> I can write this as
>>
>> dmapCoerce :: (a -> b) -> D a -> D b
>> dmapCoerce f (A a) = A (f a)
>> dmapCoerce _ b@(B {}) = Unsafe.Coerce.unsafeCoerce b
>>
>> From the core, it looks like dmapCoerce indeed has a cast with no allocation,
>> while dmapNoCoerce allocates a new B.
>>
>> It seems to work, but is it safe?  Is there a more principled way to do it?
>> I can't convince Data.Coerce to cooperate, presumably because 'a' and 'b' are
>> not coercible themselves, and it doesn't believe me if I try to tell it the
>> type role is phantom.
>
>
> this coercion is not possible in Core, because Core’s type system is
> not expressive enough (at least now…). But luckily, at the STG level
> this optimization is possible, see
> https://git.haskell.org/ghc.git/commitdiff/19d5c7312bf0ad9ae764168132aecf3696d5410b
>
> This is probably in 8.2.
>
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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 mail at joachim-breitner.de  Fri Dec 15 01:28:08 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 14 Dec 2017 20:28:08 -0500
Subject: [Haskell-cafe] coercing D a to D b
In-Reply-To: <CACbaDy5OR023sYq6vPmVGhAQ_sJXO-=aWJB=GX-zVdGGQW1-Qg@mail.gmail.com>
References: <CACbaDy6JF7tCz5ONv2Z7uWG+q1kSU+QUHTMN=4P1WxofNSMs1A@mail.gmail.com>
 <1513264570.4583.1.camel@joachim-breitner.de>
 <CACbaDy5OR023sYq6vPmVGhAQ_sJXO-=aWJB=GX-zVdGGQW1-Qg@mail.gmail.com>
Message-ID: <1513301288.7536.5.camel@joachim-breitner.de>

Hi,


Am Donnerstag, den 14.12.2017, 16:53 -0800 schrieb Evan Laforge:
> Nice, it looks like "Note [Case 2: CSEing case binders]" applies to
> what I was talking about.
> 
> I assume once I can upgrade to 8.2 (or 8.4 more likely) then both my
> examples should wind up looking different at the core level, but then
> both be a coerce in STG?  Well, I guess implicitly a coerce since STG
> doesn't have types like that.


precisely:
$ ghc-8.2  -O -ddump-stg test.hs 
[1 of 1] Compiling Foo              ( test.hs, test.o )

…

==================== STG syntax: ====================
Foo.dmapNoCoerce :: forall a b. (a -> b) -> Foo.D a -> Foo.D b
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=<L,1*C1(U)><S,1*U>,
 Unf=OtherCon []] =
    \r [f_s15C ds_s15D]
        case ds_s15D of {
          Foo.A a1_s15F [Occ=Once] ->
              let {
                sat_s15G [Occ=Once] :: b_aTu
                [LclId] =
                    \u [] f_s15C a1_s15F;
              } in  Foo.A [sat_s15G];
          Foo.B i_s15H [Occ=Once] c_s15I [Occ=Once] -> wild_s15E;
        };

…


The pretty-printing is actually a bit broken, but the wild_s15E is the
case-binder of the "case ds_s15D" construct.

Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171214/c53e08b4/attachment.sig>

From lemming at henning-thielemann.de  Fri Dec 15 17:27:18 2017
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 15 Dec 2017 18:27:18 +0100 (CET)
Subject: [Haskell-cafe] Is Haskell the best programming language?
Message-ID: <alpine.DEB.2.20.1712151826020.11637@sputnik>


I just got to know that there is a card game (code quartett) that lets 
players find out what language is the best:
    http://codequartett.de/index-en.html

:-)

From fa-ml at ariis.it  Fri Dec 15 17:46:48 2017
From: fa-ml at ariis.it (Francesco Ariis)
Date: Fri, 15 Dec 2017 18:46:48 +0100
Subject: [Haskell-cafe] Is Haskell the best programming language?
In-Reply-To: <alpine.DEB.2.20.1712151826020.11637@sputnik>
References: <alpine.DEB.2.20.1712151826020.11637@sputnik>
Message-ID: <20171215174648.x4poaoiss7cu3e2y@x60s.casa>

On Fri, Dec 15, 2017 at 06:27:18PM +0100, Henning Thielemann wrote:
> 
> I just got to know that there is a card game (code quartett) that lets
> players find out what language is the best:
>    http://codequartett.de/index-en.html
> 
> :-)

Ehehe nice find Henning. For anyone curious:

https://github.com/Suplanus/CodeQuartett/blob/master/Images/JPG/cards/Haskell.jpg

I would challenge the "dialects" number, which is actually

    2 ^ length ghc_extensions

From twilson at csufresno.edu  Sun Dec 17 04:43:42 2017
From: twilson at csufresno.edu (Todd Wilson)
Date: Sun, 17 Dec 2017 04:43:42 +0000
Subject: [Haskell-cafe] The Definition of Haskell
Message-ID: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>

Why doesn't Haskell (or at least "core" Haskell) have a formal definition
and safety result the way Standard ML does [1], [2]? Is it just that no one
has gotten around to producing them, or because there are fundamental
difficulties that stand in the way of completing such a project?

Todd Wilson

[1] Robin Milner, Mads Tofte, Robert Harper, and David MacQueen. The
Definition of Standard ML (Revised). MIT Press, 1997.
[2] Daniel K. Lee , Karl Crary , Robert Harper, "Mechanizing the Metatheory
of Standard ML", http://www.cs.cmu.edu/~dklee/tslf/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171217/f2227c3b/attachment.html>

From allbery.b at gmail.com  Sun Dec 17 05:14:08 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 17 Dec 2017 00:14:08 -0500
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
Message-ID: <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>

Dunno about safety results, but
https://www.haskell.org/onlinereport/haskell2010/ exists (next revision
expected in 2020 iirc).
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/lang.html
documents ghc's extensions to the standard, and
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#haskell-standards-vs-glasgow-haskell-language-non-compliance
its deviations from the standard, some of which will likely be in the next
standard.

Some things, such as how typeclasses are implemented, are not specified in
the standard so that alternative implementations can choose to implement
them differently. ghc uses dictionary / record parameters; jhc did whole
program compilation, so all non-polymorphically-recursive typeclass methods
could be resolved at compile time (I don't know offhand how it handled
polymorphic recursion).

On Sat, Dec 16, 2017 at 11:43 PM, Todd Wilson <twilson at csufresno.edu> wrote:

> Why doesn't Haskell (or at least "core" Haskell) have a formal definition
> and safety result the way Standard ML does [1], [2]? Is it just that no one
> has gotten around to producing them, or because there are fundamental
> difficulties that stand in the way of completing such a project?
>
> Todd Wilson
>
> [1] Robin Milner, Mads Tofte, Robert Harper, and David MacQueen. The
> Definition of Standard ML (Revised). MIT Press, 1997.
> [2] Daniel K. Lee , Karl Crary , Robert Harper, "Mechanizing the
> Metatheory of Standard ML", http://www.cs.cmu.edu/~dklee/tslf/
>
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171217/2138c6fb/attachment.html>

From wangbj at gmail.com  Sun Dec 17 05:22:31 2017
From: wangbj at gmail.com (Baojun Wang)
Date: Sun, 17 Dec 2017 05:22:31 +0000
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
Message-ID: <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>

SPJ may answered part of it in his talk Escape from the ivory tower:
https://www.youtube.com/watch?v=re96UgMk6GQ&feature=share from about 29
minutes.

On Sat, Dec 16, 2017 at 21:17 Brandon Allbery <allbery.b at gmail.com> wrote:

> Dunno about safety results, but
> https://www.haskell.org/onlinereport/haskell2010/ exists (next revision
> expected in 2020 iirc).
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/lang.html
> documents ghc's extensions to the standard, and
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#haskell-standards-vs-glasgow-haskell-language-non-compliance
> its deviations from the standard, some of which will likely be in the next
> standard.
>
> Some things, such as how typeclasses are implemented, are not specified in
> the standard so that alternative implementations can choose to implement
> them differently. ghc uses dictionary / record parameters; jhc did whole
> program compilation, so all non-polymorphically-recursive typeclass methods
> could be resolved at compile time (I don't know offhand how it handled
> polymorphic recursion).
>
> On Sat, Dec 16, 2017 at 11:43 PM, Todd Wilson <twilson at csufresno.edu>
> wrote:
>
>> Why doesn't Haskell (or at least "core" Haskell) have a formal definition
>> and safety result the way Standard ML does [1], [2]? Is it just that no one
>> has gotten around to producing them, or because there are fundamental
>> difficulties that stand in the way of completing such a project?
>>
>> Todd Wilson
>>
>> [1] Robin Milner, Mads Tofte, Robert Harper, and David MacQueen. The
>> Definition of Standard ML (Revised). MIT Press, 1997.
>> [2] Daniel K. Lee , Karl Crary , Robert Harper, "Mechanizing the
>> Metatheory of Standard ML", http://www.cs.cmu.edu/~dklee/tslf/
>>
>> _______________________________________________
>> 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                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> _______________________________________________
> 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/20171217/97757833/attachment.html>

From clintonmead at gmail.com  Sun Dec 17 14:27:20 2017
From: clintonmead at gmail.com (Clinton Mead)
Date: Mon, 18 Dec 2017 01:27:20 +1100
Subject: [Haskell-cafe] Managing package release workflow
Message-ID: <CAFDVgwEQ5mrS=w=rPP2vKsuJvBG2JqvMpDJ2xmw+szmoa7EHVw@mail.gmail.com>

Hi All

I've already got a few packages on hackage
<https://hackage.haskell.org/user/clinton>, but I'd like to upload a few
more, but I'm finding the workflow management particularly excessive.
Here's what I'd like to do roughly:

1. Choose a number of stack snapshots I'd like my package to successfully
build and test against.
2. Automatically apply appropriate version bounds to dependencies in my
cabal file based on those snapshots.
3. When these changes are pushed to Github, attempt to compile them using
Travis CI, against all the stack snapshots chosen.
4. If we do a push to a particular branch or with particular tag, this
signifies we're attempting a release. Attempt to compile using Travis CI,
perform the tests. If the compile and tests are successful, push a separate
commit, adjust the "source-repository" field in github to point to that
release commit (not to master) and upload to hackage.

I'm currently doing all of this manually but it's increasingly a bit of a
pain. Is there tooling to help me automate this?

Thanks,

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

From twilson at csufresno.edu  Sun Dec 17 19:53:06 2017
From: twilson at csufresno.edu (Todd Wilson)
Date: Sun, 17 Dec 2017 19:53:06 +0000
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
 <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
Message-ID: <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>

On Sat, Dec 16, 2017 at 9:14 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> Dunno about safety results, but
> https://www.haskell.org/onlinereport/haskell2010/ exists (next revision
> expected in 2020 iirc).
>

Although this can be considered a definition of the language, it is by no
means a formal definition of the static and dynamic semantics of the
language in a form amenable to representation in systems like Coq, where
metatheory might be checked.

On Sat, Dec 16, 2017 at 9:22 PM Baojun Wang <wangbj at gmail.com> wrote:

> SPJ may answered part of it in his talk Escape from the ivory tower:
> https://www.youtube.com/watch?v=re96UgMk6GQ&feature=share from about 29
> minutes.
>

Nice talk; thanks for the reference. To summarize: formalization, which is
a lot of work, leads to standardization and the reluctance to change the
language, and one of Haskell's strong points is that it is constantly
evolving.

I see SPJ's point, but he makes another point in the same video, which is
that Haskell has a small, internal core language to which everything must
elaborate, so this would seem to make formalization even more attractive:
formalize and prove safety for the core language once and for all, and then
specify the elaborations and check their properties modularly, which should
work well even in the face of language evolution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171217/89e6732d/attachment.html>

From jeremy128 at gmail.com  Sun Dec 17 21:03:44 2017
From: jeremy128 at gmail.com (Jeremy Mikkola)
Date: Sun, 17 Dec 2017 13:03:44 -0800
Subject: [Haskell-cafe] Writing an interpreter for a language with mutability
Message-ID: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>

I am quite certain I am not the first to try to do this, but my google-fu
is failing me today.

How does one go about interpreting a language with mutable objects in
Haskell?


The best approach I can think of is to represent the language's memory as a
`Data.Map.Map RefID LanguageObject` where RefID is some type (probably Int)
used as a reference. The LanguageObject structure might contain some values
of type RefID to refer to other objects. Mutating an object involves simply
replacing the value in the map at a given RefID.


I don't like this approach for two reasons:

1. Map lookups aren't very efficient compared with actual references to the
value.

2. I have to re-invent garbage collection, removing objects from the map
when they no longer have incoming references. (Unlike simple interpreters
for languages with immutable values, I can't rely on Haskell's garbage
collector to do the work for me.)


Is there a better approach?


- Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171217/6745642b/attachment.html>

From jpaugh at gmx.com  Sun Dec 17 22:02:16 2017
From: jpaugh at gmx.com (Jonathan Paugh)
Date: Sun, 17 Dec 2017 16:02:16 -0600
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
 <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
 <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
Message-ID: <89571390-04D2-4D0B-B225-9CB9629AA5BC@gmx.com>

Hello,

Many parts of the language are formally specified in papers written by SPJ, or someone else who worked closely on that feature. For example, certain modifications to the type system are described here [1].

Check out SPJ's Microsoft Research page for other papers [2]. I seem to recall reading a formal definition of Haskell Core, but can't recall whether it was in one of these papers or not.

Cheers,
Jon

[1]: https://www.microsoft.com/en-us/research/publication/practical-aspects-evidence-based-compilation-system-fc/
[2]: https://www.microsoft.com/en-us/research/people/simonpj/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fpeople%2Fsimonpj%2F

On December 17, 2017 1:53:06 PM CST, Todd Wilson <twilson at csufresno.edu> wrote:
>On Sat, Dec 16, 2017 at 9:14 PM Brandon Allbery <allbery.b at gmail.com>
>wrote:
>
>> Dunno about safety results, but
>> https://www.haskell.org/onlinereport/haskell2010/ exists (next
>revision
>> expected in 2020 iirc).
>>
>
>Although this can be considered a definition of the language, it is by
>no
>means a formal definition of the static and dynamic semantics of the
>language in a form amenable to representation in systems like Coq,
>where
>metatheory might be checked.
>
>On Sat, Dec 16, 2017 at 9:22 PM Baojun Wang <wangbj at gmail.com> wrote:
>
>> SPJ may answered part of it in his talk Escape from the ivory tower:
>> https://www.youtube.com/watch?v=re96UgMk6GQ&feature=share from about
>29
>> minutes.
>>
>
>Nice talk; thanks for the reference. To summarize: formalization, which
>is
>a lot of work, leads to standardization and the reluctance to change
>the
>language, and one of Haskell's strong points is that it is constantly
>evolving.
>
>I see SPJ's point, but he makes another point in the same video, which
>is
>that Haskell has a small, internal core language to which everything
>must
>elaborate, so this would seem to make formalization even more
>attractive:
>formalize and prove safety for the core language once and for all, and
>then
>specify the elaborations and check their properties modularly, which
>should
>work well even in the face of language evolution.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171217/2bae1f7d/attachment.html>

From lysxia at gmail.com  Mon Dec 18 03:13:46 2017
From: lysxia at gmail.com (Li-yao Xia)
Date: Sun, 17 Dec 2017 22:13:46 -0500
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
 <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
 <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
Message-ID: <e832a44b-53d8-3ecd-4d1d-a5e2b52d105c@gmail.com>

Hi Todd,

The GHC repository includes a PDF, with its source, formalizing the Core 
language (no proofs); the rules are notably written in the parseable 
.ott format.

https://github.com/ghc/ghc/blob/master/docs/core-spec

Li-yao


On 12/17/2017 02:53 PM, Todd Wilson wrote:
> On Sat, Dec 16, 2017 at 9:14 PM Brandon Allbery <allbery.b at gmail.com 
> <mailto:allbery.b at gmail.com>> wrote:
> 
>     Dunno about safety results, but
>     https://www.haskell.org/onlinereport/haskell2010/ exists (next
>     revision expected in 2020 iirc).
> 
> 
> Although this can be considered a definition of the language, it is by 
> no means a formal definition of the static and dynamic semantics of the 
> language in a form amenable to representation in systems like Coq, where 
> metatheory might be checked.
> 
> On Sat, Dec 16, 2017 at 9:22 PM Baojun Wang <wangbj at gmail.com 
> <mailto:wangbj at gmail.com>> wrote:
> 
>     SPJ may answered part of it in his talk Escape from the ivory tower:
>     https://www.youtube.com/watch?v=re96UgMk6GQ&feature=share from about
>     29 minutes.
> 
> 
> Nice talk; thanks for the reference. To summarize: formalization, which 
> is a lot of work, leads to standardization and the reluctance to change 
> the language, and one of Haskell's strong points is that it is 
> constantly evolving.
> 
> I see SPJ's point, but he makes another point in the same video, which 
> is that Haskell has a small, internal core language to which everything 
> must elaborate, so this would seem to make formalization even more 
> attractive: formalize and prove safety for the core language once and 
> for all, and then specify the elaborations and check their properties 
> modularly, which should work well even in the face of language evolution.
> 
> 
> 
> _______________________________________________
> 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 aquagnu at gmail.com  Mon Dec 18 09:06:33 2017
From: aquagnu at gmail.com (Baa)
Date: Mon, 18 Dec 2017 11:06:33 +0200
Subject: [Haskell-cafe] Writing an interpreter for a language with
 mutability
In-Reply-To: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
References: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
Message-ID: <20171218110633.6290907c@Pavel>

Hello,

IMHO interpretor written in any language will need collection of
mappings. What is the mutation?

  x = 1
  x = 2

is this a mutation? `x` is a member of some collection (dict/map) and
last line remap/rebind its value. Sure, you need collection to access
all values by name. But `x` can be complex value, for example
record/structure with fields. So, we should talk about map of maps. Is
it effective? May be you need one big tree? What kind of trees are
effective we know from RDBMS. So, obviously you need some collection.
In Python any object has ID (it can be address in virtual memory) and
reference counter - for GC. It's very common scheme.
But you can implement another scheme too: to compile tree, allocate
objects in some memory storage structure (pool/pools of objects with the
same size) and to translate names to indexes - how in done in usual
compiled languages like C, Pascal, etc. VM-based languages uses
different schemes but sometimes the same. You can allocate objects in
stack, in registers and sure heap. And you need to translate names into
indexes in those storages.

But you are right, simplest way is to allocate them in some collection
and to use hash/index/etc to access them. May be one big tree will be
good solution. So, interesting is to choose right kind of tree.

It's my IMHO :)

As idea, I can only say: it is better to check implementations of
ddifferent classical interpreting languages: Tcl, Lisp/Scheme, Basic,
Python, IO, Lua, etc. You can find many interesting ideas there

===
Best regards, Paul

> I am quite certain I am not the first to try to do this, but my
> google-fu is failing me today.
> 
> How does one go about interpreting a language with mutable objects in
> Haskell?
> 
> 
> The best approach I can think of is to represent the language's
> memory as a `Data.Map.Map RefID LanguageObject` where RefID is some
> type (probably Int) used as a reference. The LanguageObject structure
> might contain some values of type RefID to refer to other objects.
> Mutating an object involves simply replacing the value in the map at
> a given RefID.
> 
> 
> I don't like this approach for two reasons:
> 
> 1. Map lookups aren't very efficient compared with actual references
> to the value.
> 
> 2. I have to re-invent garbage collection, removing objects from the
> map when they no longer have incoming references. (Unlike simple
> interpreters for languages with immutable values, I can't rely on
> Haskell's garbage collector to do the work for me.)
> 
> 
> Is there a better approach?
> 
> 
> - Jeremy


From simonpj at microsoft.com  Mon Dec 18 09:42:19 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 18 Dec 2017 09:42:19 +0000
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
 <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
 <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
Message-ID: <AM4PR83MB0033728423B8CEEEC14BE90BAD0E0@AM4PR83MB0033.EURPRD83.prod.outlook.com>

I see SPJ's point, but he makes another point in the same video, which is that Haskell has a small, internal core language to which everything must elaborate, so this would seem to make formalization even more attractive: formalize and prove safety for the core language once and for all, and then specify the elaborations and check their properties modularly, which should work well even in the face of language evolution.

Yes – and Core is indeed formalised quite carefully (by Richard Eisenberg).  See https://ghc.haskell.org/trac/ghc/ticket/14572#comment:8

Simon

From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Todd Wilson
Sent: 17 December 2017 19:53
To: Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] The Definition of Haskell

On Sat, Dec 16, 2017 at 9:14 PM Brandon Allbery <allbery.b at gmail.com<mailto:allbery.b at gmail.com>> wrote:
Dunno about safety results, but https://www.haskell.org/onlinereport/haskell2010/ exists (next revision expected in 2020 iirc).

Although this can be considered a definition of the language, it is by no means a formal definition of the static and dynamic semantics of the language in a form amenable to representation in systems like Coq, where metatheory might be checked.

On Sat, Dec 16, 2017 at 9:22 PM Baojun Wang <wangbj at gmail.com<mailto:wangbj at gmail.com>> wrote:
SPJ may answered part of it in his talk Escape from the ivory tower: https://www.youtube.com/watch?v=re96UgMk6GQ&feature=share<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dre96UgMk6GQ%26feature%3Dshare&data=02%7C01%7Csimonpj%40microsoft.com%7C6fb497b3f6c94c81876e08d545882101%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636491373335007410&sdata=5WnVwESDGAotRmeUq6wevSmwgsg6hFFGe6c90YYFv6E%3D&reserved=0> from about 29 minutes.

Nice talk; thanks for the reference. To summarize: formalization, which is a lot of work, leads to standardization and the reluctance to change the language, and one of Haskell's strong points is that it is constantly evolving.

I see SPJ's point, but he makes another point in the same video, which is that Haskell has a small, internal core language to which everything must elaborate, so this would seem to make formalization even more attractive: formalize and prove safety for the core language once and for all, and then specify the elaborations and check their properties modularly, which should work well even in the face of language evolution.

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

From lambda.fairy at gmail.com  Mon Dec 18 10:25:15 2017
From: lambda.fairy at gmail.com (Chris Wong)
Date: Mon, 18 Dec 2017 23:25:15 +1300
Subject: [Haskell-cafe] Writing an interpreter for a language with
	mutability
In-Reply-To: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
References: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
Message-ID: <CANQO64+ChHLe5cRWJxhbd3041hhe8khCSm4aKBqhdSXguSXDxg@mail.gmail.com>

Hi Jeremy,

I'm on my phone right now so I can't link, but try searching for "IORef"
and the "ST monad".

Chris

On Dec 18, 2017 10:06, "Jeremy Mikkola" <jeremy128 at gmail.com> wrote:

> I am quite certain I am not the first to try to do this, but my google-fu
> is failing me today.
>
> How does one go about interpreting a language with mutable objects in
> Haskell?
>
>
> The best approach I can think of is to represent the language's memory as
> a `Data.Map.Map RefID LanguageObject` where RefID is some type (probably
> Int) used as a reference. The LanguageObject structure might contain some
> values of type RefID to refer to other objects. Mutating an object involves
> simply replacing the value in the map at a given RefID.
>
>
> I don't like this approach for two reasons:
>
> 1. Map lookups aren't very efficient compared with actual references to
> the value.
>
> 2. I have to re-invent garbage collection, removing objects from the map
> when they no longer have incoming references. (Unlike simple interpreters
> for languages with immutable values, I can't rely on Haskell's garbage
> collector to do the work for me.)
>
>
> Is there a better approach?
>
>
> - Jeremy
>
> _______________________________________________
> 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/20171218/4f5a94b9/attachment.html>

From takenobu.hs at gmail.com  Mon Dec 18 13:17:05 2017
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Mon, 18 Dec 2017 22:17:05 +0900
Subject: [Haskell-cafe] Who can send a patche to vim project?
In-Reply-To: <CAPB_NvxDWMg_6zQsBBoocvGPvrxGNLq-TNPy5d4LUEL=0Fq79Q@mail.gmail.com>
References: <CAPB_NvzMGZS3OYEAXuqRCXyx_hsXYf8JaCj0S6cJ=VJeH-KwtQ@mail.gmail.com>
 <CAPB_NvxDWMg_6zQsBBoocvGPvrxGNLq-TNPy5d4LUEL=0Fq79Q@mail.gmail.com>
Message-ID: <CAPB_Nvy76-uPQZvARXMEOj-cTyYbwGrkanpTKWpOG30gV1mD3Q@mail.gmail.com>

Hi cafe,

I share the results of the patch for numeric literal extensions to vim
porject.

This patch has been released in v.8.0.1402 [1][2][3].
Since v.8.0.1402, you can use syntax highlighting for `BinaryLiterals`,
`HexFloatLiterals` and `NumericUnderscores`.


To the person who sends the next patch.
The patch submit procedure of `haskell.vim` is as follows:
  1. Share the contents of the patch to haskell-cafe ML (maintainer).
  2. Send pull-request to vim project on github.

P.S.
This syntax highlight on Atom, VScode and Vim are already ready.
Linghist (which is used from github) will apply it at new year release.
Pygments (which is used from trac, readthedocs, pandoc, ...) is pending
review.

[1]: https://github.com/vim/vim/releases/tag/v8.0.1402
[2]:
https://github.com/vim/vim/commit/f0b03c4e98f8a7184d8b4a5d702cbcd602426923#diff-6f4249d02b81f2e8cbd2b0927aad21ce
[3]: https://github.com/vim/vim/pull/2455

Regards,
Takenobu


2017-12-12 21:29 GMT+09:00 Takenobu Tani <takenobu.hs at gmail.com>:

> Hi cafe,
>
> I'll directly contact the vim-dev maillist :)
>
> Thanks,
> Takenobu
>
>
> 2017-12-11 21:16 GMT+09:00 Takenobu Tani <takenobu.hs at gmail.com>:
>
>> Hi cafe,
>>
>> Who can send a patche to vim project?
>>
>> I'd like to update vim syntax file (haskell.vim) to fix numeric literals.
>> I read the vim `CONTRIBUTING.md` file [1].
>> It instructs me to contact the maintainer of each files.
>> In the header of `haskell.vim`, the maintainor of `haskell.vim` is
>> haskell-cafe at ML. [2]
>> Who is the maintainer of `haskell.vim`?
>>
>> I'd like to make fix on numeric literals extension: [3]
>>   * BinaryLiterals
>>   * HexFloatLiterals
>>   * NumericUnderscores
>>
>> I prepared two kinds of patches.
>>   * Exact pattern version [4]
>>   * Fast (but approximate) pattern version [5]
>>
>> I visually checked patches with the these files [6][7].
>>
>> Could you send a patch of [4] or [5] to vim project?
>>
>>
>> P.S.
>> I have already sent patches to two projects.
>>
>>   * `language-haskell` for atom and linguist [8]
>>       You can already use it on atom.
>>       Linghist (which is used from github) will apply it soon.
>>
>>   * `pygments` [9]
>>       It is pending review.
>>
>>
>> [1]: https://github.com/vim/vim/blob/master/CONTRIBUTING.md#synta
>> x-indent-and-other-runtime-files
>> [2]: https://github.com/vim/vim/blob/master/runtime/syntax/haskell.vim#L3
>> [3]: https://github.com/ghc-proposals/ghc-proposals/blob/master/
>> proposals/0009-numeric-underscores.rst#new-syntax-this-proposal
>> [4]: https://github.com/vim/vim/compare/master...takenobu-hs:synt
>> ax-haskell-literal-exact
>> [5]: https://github.com/vim/vim/compare/master...takenobu-hs:synt
>> ax-haskell-literal-fast
>>
>> [6]: https://github.com/takenobu-hs/ghc/blob/squashed-numeric-und
>> erscores/testsuite/tests/parser/should_run/NumericUnderscores0.hs
>> [7]: https://github.com/takenobu-hs/ghc/blob/squashed-numeric-und
>> erscores/testsuite/tests/parser/should_run/NumericUnderscores1.hs
>>
>> [8]: https://github.com/atom-haskell/language-haskell/commit/f90e
>> b7d8662493536f54898e52b4c7b1dc96de41
>> [9]: https://bitbucket.org/birkenfeld/pygments-main/issues/1399/
>> update-haskell-with-lexer-for-numeric
>>
>> Regards,
>> Takenobu
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171218/b0e8d1c3/attachment.html>

From daniel.trstenjak at gmail.com  Mon Dec 18 13:45:48 2017
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Mon, 18 Dec 2017 14:45:48 +0100
Subject: [Haskell-cafe] Managing package release workflow
In-Reply-To: <CAFDVgwEQ5mrS=w=rPP2vKsuJvBG2JqvMpDJ2xmw+szmoa7EHVw@mail.gmail.com>
References: <CAFDVgwEQ5mrS=w=rPP2vKsuJvBG2JqvMpDJ2xmw+szmoa7EHVw@mail.gmail.com>
Message-ID: <20171218134548.GA25412@octa>

Hi Clinton,

> 2. Automatically apply appropriate version bounds to dependencies in my cabal
> file based on those snapshots. 

I've never used 'stack', but I think it mostly boils down to setting the
appropriate snapshot dependency constraints and ghc version for the 'cabal'
run and therefore 'cabal-bounds'[1] should work in the same way as for
a direct 'cabal' run.

'cabal-bounds' only widdens the version bounds of a dependency, so
calling it for builds of multiple 'stack' snapshots should work.

So building your package for each snapshot and just calling
'cabal-bounds update' might just work.

Greetings,
Daniel

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

From twilson at csufresno.edu  Mon Dec 18 17:27:35 2017
From: twilson at csufresno.edu (Todd Wilson)
Date: Mon, 18 Dec 2017 17:27:35 +0000
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <AM4PR83MB0033728423B8CEEEC14BE90BAD0E0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
 <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
 <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
 <AM4PR83MB0033728423B8CEEEC14BE90BAD0E0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CA+-99oJP6iYjM_G9O8j=+EWahBPQwZAQhk+9CJfNvYgyOiT7FA@mail.gmail.com>

Thanks, all, this was indeed what I was looking for, with the reference to
Ott as an added bonus. It looks like formalizing and proving safety for
this system in a proof assistant would make a good project.

--Todd

On Mon, Dec 18, 2017 at 1:42 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I see SPJ's point, but he makes another point in the same video, which is
> that Haskell has a small, internal core language to which everything must
> elaborate, so this would seem to make formalization even more attractive:
> formalize and prove safety for the core language once and for all, and then
> specify the elaborations and check their properties modularly, which should
> work well even in the face of language evolution.
>
>
>
> Yes – and Core is indeed formalised quite carefully (by Richard
> Eisenberg).  See https://ghc.haskell.org/trac/ghc/ticket/14572#comment:8
>
>
>
> Simon
>
>
>
> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On Behalf
> Of *Todd Wilson
> *Sent:* 17 December 2017 19:53
> *To:* Haskell Cafe <haskell-cafe at haskell.org>
> *Subject:* Re: [Haskell-cafe] The Definition of Haskell
>
>
>
> On Sat, Dec 16, 2017 at 9:14 PM Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
> Dunno about safety results, but
> https://www.haskell.org/onlinereport/haskell2010/ exists (next revision
> expected in 2020 iirc).
>
>
>
> Although this can be considered a definition of the language, it is by no
> means a formal definition of the static and dynamic semantics of the
> language in a form amenable to representation in systems like Coq, where
> metatheory might be checked.
>
>
>
> On Sat, Dec 16, 2017 at 9:22 PM Baojun Wang <wangbj at gmail.com> wrote:
>
> SPJ may answered part of it in his talk Escape from the ivory tower:
> https://www.youtube.com/watch?v=re96UgMk6GQ&feature=share
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dre96UgMk6GQ%26feature%3Dshare&data=02%7C01%7Csimonpj%40microsoft.com%7C6fb497b3f6c94c81876e08d545882101%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636491373335007410&sdata=5WnVwESDGAotRmeUq6wevSmwgsg6hFFGe6c90YYFv6E%3D&reserved=0> from
> about 29 minutes.
>
>
>
> Nice talk; thanks for the reference. To summarize: formalization, which is
> a lot of work, leads to standardization and the reluctance to change the
> language, and one of Haskell's strong points is that it is constantly
> evolving.
>
>
>
> I see SPJ's point, but he makes another point in the same video, which is
> that Haskell has a small, internal core language to which everything must
> elaborate, so this would seem to make formalization even more attractive:
> formalize and prove safety for the core language once and for all, and then
> specify the elaborations and check their properties modularly, which should
> work well even in the face of language evolution.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171218/17750796/attachment.html>

From rae at cs.brynmawr.edu  Mon Dec 18 18:08:13 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 18 Dec 2017 13:08:13 -0500
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <CA+-99oJP6iYjM_G9O8j=+EWahBPQwZAQhk+9CJfNvYgyOiT7FA@mail.gmail.com>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
 <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
 <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
 <AM4PR83MB0033728423B8CEEEC14BE90BAD0E0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CA+-99oJP6iYjM_G9O8j=+EWahBPQwZAQhk+9CJfNvYgyOiT7FA@mail.gmail.com>
Message-ID: <86FAC343-5192-42CA-9D42-4C01250873B3@cs.brynmawr.edu>


> On Dec 18, 2017, at 12:27 PM, Todd Wilson <twilson at csufresno.edu> wrote:
> 
>  It looks like formalizing and proving safety for this system in a proof assistant would make a good project.

It would, but formalizing a variant is already underway. See https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1076&context=compsci_pubs for a recent paper discussing (among other things) a formalization of a dependently-typed version of Core. Much more development in the formalization has taken place since that paper was written, but you’ll have to contact Stephanie Weirich (sweirich at cis.upenn.edu) for the latest, as I’m not involved at the ground level of the formalization.

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

From neil_mayhew at users.sourceforge.net  Mon Dec 18 18:27:14 2017
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Mon, 18 Dec 2017 11:27:14 -0700
Subject: [Haskell-cafe] The Definition of Haskell
In-Reply-To: <86FAC343-5192-42CA-9D42-4C01250873B3@cs.brynmawr.edu>
References: <CA+-99o+6-oDrojJExDVhXkqZDASzZrTu0EqSSku07fx0a_rreA@mail.gmail.com>
 <CAKFCL4W7mVQVFaSBLFK1mxRyfpEz-zRdTgODx4eY4eBPujzzQw@mail.gmail.com>
 <CAC+a-TZ58DC6kHK6FHR0aTESqgeLmRXhg-bT8gVVok-WhZkC5Q@mail.gmail.com>
 <CA+-99o+JvSye1OCbDXzOZcGPeSsHBWNv7OdrbSZpfFi=+oMgyg@mail.gmail.com>
 <AM4PR83MB0033728423B8CEEEC14BE90BAD0E0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CA+-99oJP6iYjM_G9O8j=+EWahBPQwZAQhk+9CJfNvYgyOiT7FA@mail.gmail.com>
 <86FAC343-5192-42CA-9D42-4C01250873B3@cs.brynmawr.edu>
Message-ID: <5c4e0b12-2ddd-7068-888e-70962eda5320@users.sourceforge.net>

On 2017-12-18 11:08 AM, Richard Eisenberg wrote:
> … formalizing a variant is already underway.
> See https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1076&context=compsci_pubs
> for a recent paper discussing (among other things) a formalization of
> a dependently-typed version of Core. Much more development in the
> formalization has taken place since that paper was written, but you’ll
> have to contact Stephanie Weirich (sweirich at cis.upenn.edu
> <mailto:sweirich at cis.upenn.edu>) for the latest, as I’m not involved
> at the ground level of the formalization.

The past two issues of Haskell Weekly News <https://haskellweekly.news/>
have mentioned research from some of the same people:

Total Haskell is reasonable Coq <https://arxiv.org/abs/1711.09286>

We would like to use the Coq proof assistant to mechanically verify
properties of Haskell programs. To that end, we present a tool, named
hs-to-coq, that translates total Haskell programs into Coq programs via
a shallow embedding.

Finding bugs in Haskell code by proving it
<https://www.joachim-breitner.de/blog/734-Finding_bugs_in_Haskell_code_by_proving_it>

We have used hs-to-coq on various examples, as described in our CPP’18
paper, but it is high-time to use it for real.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171218/59c56167/attachment.html>

From damien.flament at gmx.com  Mon Dec 18 18:38:46 2017
From: damien.flament at gmx.com (Damien Flament)
Date: Mon, 18 Dec 2017 19:38:46 +0100
Subject: [Haskell-cafe]  Haskell IDE Engine logo poll
Message-ID: <f7fb3ef2-2c28-d501-f7da-5fa6006bd84f@gmx.com>

Hi !

The final poll is available featuring all logos submitted until last Friday.

Please vote for your favourite*s* here: 
http://freeonlinesurveys.com/p/Cw1FRJ2G?qid=1017541

Thanks.

Damien.

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

From jo at durchholz.org  Mon Dec 18 20:31:50 2017
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 18 Dec 2017 21:31:50 +0100
Subject: [Haskell-cafe] Writing an interpreter for a language with
 mutability
In-Reply-To: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
References: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
Message-ID: <d6056299-d7dc-9e10-e8fd-2cbf53d04ef3@durchholz.org>

Am 17.12.2017 um 22:03 schrieb Jeremy Mikkola:
> How does one go about interpreting a language with mutable objects in 
> Haskell?
> 
> 
> The best approach I can think of is to represent the language's memory 
> as a `Data.Map.Map RefID LanguageObject` where RefID is some type 
> (probably Int) used as a reference.

It depends on how data is addressed in the language.
If you wanto interpret a C-style language where every address can be 
cast to an int, then that's the most straightforward (though not 
necessarily best) approach.
If it is just references to objects as in most, erm, "more modern" 
languages, the Id can be any type. E.g. something based on the 
language's data model - Int | Real | Record | Array, with type 
parameters as appropriate. Upside is that you leverage the Haskell GC 
that way, downside is that you'll need a recursive type (Array is really 
Array RefId, and my Haskell-fu is hilariously inadequate to properly 
flesh out that recursion).

From qdunkan at gmail.com  Mon Dec 18 21:10:32 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 18 Dec 2017 13:10:32 -0800
Subject: [Haskell-cafe] error terminated list
Message-ID: <CACbaDy7xaqU_j6OS3XYs0MTuLQ65qdLr1RibuabRHi6oq+cmug@mail.gmail.com>

I've been using this lately to represent a process which can fail but
still produce data:

data UntilFail err a = a :+ UntilFail err a | Done | Fail err

I know there's been discussion of this type before, but I don't
remember what it was called and I can't find the right search terms to
turn it up.  Ring any bells?  I have some awkward names for it, but
maybe someone else thought of something more elegant.

I have some ad-hoc functions for it:

mapUntilFail :: (a -> Either err b) -> UntilFail err a -> UntilFail err b
concatMapUntilFail :: (a -> UntilFail err b) -> UntilFail err a ->
UntilFail err b

-- | Like 'concatMapUntilFail', but consume a variable number of results.
--
-- A more precise type would end with @Done [a]@.
processUntilFail :: (a -> [a] -> (UntilFail err b, [a])) -> [a] ->
UntilFail err b

Maybe someone who has thought more deeply about it has come up with
more elegant abstractions.

From david.feuer at gmail.com  Tue Dec 19 04:32:07 2017
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 18 Dec 2017 23:32:07 -0500
Subject: [Haskell-cafe] coercing D a to D b
In-Reply-To: <1513264570.4583.1.camel@joachim-breitner.de>
References: <CACbaDy6JF7tCz5ONv2Z7uWG+q1kSU+QUHTMN=4P1WxofNSMs1A@mail.gmail.com>
 <1513264570.4583.1.camel@joachim-breitner.de>
Message-ID: <CAMgWh9v3aFfHsZe6tBBktY+VpKfu6w+rT=YCkQ378rp0CkV3Bw@mail.gmail.com>

Joachim, in the commit message you remark that

> This CSE pass only targets data constructor applications. This is
> probably the best we can do, as function calls and primitive operations
> might have side-effects.


While it's true that function calls may have side effects, I imagine
you can probably
dig up the has_side_effects values for primops and use those.

On Thu, Dec 14, 2017 at 10:16 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Mittwoch, den 13.12.2017, 21:34 -0800 schrieb Evan Laforge:
>> Given:
>>
>> data D a = A a | B Int Char
>>
>> dmapNoCoerce :: (a -> b) -> D a -> D b
>> dmapNoCoerce f (A a) = A (f a)
>> dmapNoCoerce _ (B i c) = B i c
>>
>> I have to reconstruct a B change it from D a to D b.  But at the lower level,
>> couldn't this be implemented as a type cast?  What prevents such an
>> optimization?
>>
>> I can write this as
>>
>> dmapCoerce :: (a -> b) -> D a -> D b
>> dmapCoerce f (A a) = A (f a)
>> dmapCoerce _ b@(B {}) = Unsafe.Coerce.unsafeCoerce b
>>
>> From the core, it looks like dmapCoerce indeed has a cast with no allocation,
>> while dmapNoCoerce allocates a new B.
>>
>> It seems to work, but is it safe?  Is there a more principled way to do it?
>> I can't convince Data.Coerce to cooperate, presumably because 'a' and 'b' are
>> not coercible themselves, and it doesn't believe me if I try to tell it the
>> type role is phantom.
>
>
> this coercion is not possible in Core, because Core’s type system is
> not expressive enough (at least now…). But luckily, at the STG level
> this optimization is possible, see
> https://git.haskell.org/ghc.git/commitdiff/19d5c7312bf0ad9ae764168132aecf3696d5410b
>
> This is probably in 8.2.
>
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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 siddharth.bhat at research.iiit.ac.in  Tue Dec 19 06:47:03 2017
From: siddharth.bhat at research.iiit.ac.in ((IIIT) Siddharth Bhat)
Date: Tue, 19 Dec 2017 06:47:03 +0000
Subject: [Haskell-cafe] Are bottoms ever natural?
Message-ID: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>

I've been thinking about the issue of purity and speculation lately, and
from what little I have read, it looks like the presence of bottom hiding
inside a lazy value is a huge issue.

How "natural" is it for bottoms to exist? If one were to change Haskell and
declare that any haskell value can be speculated upon, what ramifications
does this have?

Is it totally broken? Is it "correct" but makes programming unpleasant?
What's the catch?

Thanks,
Siddharth
-- 
Sending this from my phone, please excuse any typos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/8e735d70/attachment.html>

From allbery.b at gmail.com  Tue Dec 19 07:06:49 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 19 Dec 2017 02:06:49 -0500
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>
References: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>
Message-ID: <CAKFCL4VasL3TE9Zhd+jcN93dzfuQi+6mM4f0uQUrLU0mKJaR3w@mail.gmail.com>

Define "natural".

You might want to look into the concept of Turing completeness. One could
define a subset of Haskell in which bottoms cannot occur... but it turns
out there's a lot of useful things you can't do in such a language. (In
strict languages, these often are expressed as infinite loops of one kind
or another. Note also that any dependency on external input is an infinite
loop from the perspective of the language, since it can only be broken by
the external entity providing the input.)

On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat <
siddharth.bhat at research.iiit.ac.in> wrote:

> I've been thinking about the issue of purity and speculation lately, and
> from what little I have read, it looks like the presence of bottom hiding
> inside a lazy value is a huge issue.
>
> How "natural" is it for bottoms to exist? If one were to change Haskell
> and declare that any haskell value can be speculated upon, what
> ramifications does this have?
>
> Is it totally broken? Is it "correct" but makes programming unpleasant?
> What's the catch?
>
> Thanks,
> Siddharth
> --
> Sending this from my phone, please excuse any typos!
>
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/68e3c5df/attachment.html>

From siddharth.bhat at research.iiit.ac.in  Tue Dec 19 07:20:07 2017
From: siddharth.bhat at research.iiit.ac.in ((IIIT) Siddharth Bhat)
Date: Tue, 19 Dec 2017 07:20:07 +0000
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAKFCL4VasL3TE9Zhd+jcN93dzfuQi+6mM4f0uQUrLU0mKJaR3w@mail.gmail.com>
References: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>
 <CAKFCL4VasL3TE9Zhd+jcN93dzfuQi+6mM4f0uQUrLU0mKJaR3w@mail.gmail.com>
Message-ID: <CAPipc=1zo0ky3PxofGVBLFiG5vjFmK4Cg88s_emuS_69qV8v_A@mail.gmail.com>

Is that really true, though?
Usually when you have an infinite loop, you have progress of some sort.
Infinite loops with no side effects can be removed from the program
according to the C standard, for example. So, in general, we should allow
programmers to express termination / progress, right? At that point, no
computation ever "bottoms out"?

Shouldn't a hypothetical purely functional programming language better
control this (by eg. Forcing totality?) It seems like we lose much of the
benefits of purity by muddying the waters with divergence.

>From an optimising compiler perspective, Haskell is on some weird lose-lose
space, where you lose out on traditional compiler techniques that work on
strict code, but it also does not allow the awesome stuff you could do with
"pure" computation because bottom lurks everywhere.

What neat optimisations can be done on Haskell that can't be done in a
traditional imperative language? I genuinely want to know.

What are your thoughts on this?

Cheers
Siddharth

On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com> wrote:

> Define "natural".
>
> You might want to look into the concept of Turing completeness. One could
> define a subset of Haskell in which bottoms cannot occur... but it turns
> out there's a lot of useful things you can't do in such a language. (In
> strict languages, these often are expressed as infinite loops of one kind
> or another. Note also that any dependency on external input is an infinite
> loop from the perspective of the language, since it can only be broken by
> the external entity providing the input.)
>
> On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat <
> siddharth.bhat at research.iiit.ac.in> wrote:
>
>> I've been thinking about the issue of purity and speculation lately, and
>> from what little I have read, it looks like the presence of bottom hiding
>> inside a lazy value is a huge issue.
>>
>> How "natural" is it for bottoms to exist? If one were to change Haskell
>> and declare that any haskell value can be speculated upon, what
>> ramifications does this have?
>>
>> Is it totally broken? Is it "correct" but makes programming unpleasant?
>> What's the catch?
>>
>> Thanks,
>> Siddharth
>> --
>> Sending this from my phone, please excuse any typos!
>>
>> _______________________________________________
>> 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                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> _______________________________________________
> 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.

-- 
Sending this from my phone, please excuse any typos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/b112dd29/attachment.html>

From siddharth.bhat at research.iiit.ac.in  Tue Dec 19 07:21:23 2017
From: siddharth.bhat at research.iiit.ac.in ((IIIT) Siddharth Bhat)
Date: Tue, 19 Dec 2017 07:21:23 +0000
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAPipc=1zo0ky3PxofGVBLFiG5vjFmK4Cg88s_emuS_69qV8v_A@mail.gmail.com>
References: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>
 <CAKFCL4VasL3TE9Zhd+jcN93dzfuQi+6mM4f0uQUrLU0mKJaR3w@mail.gmail.com>
 <CAPipc=1zo0ky3PxofGVBLFiG5vjFmK4Cg88s_emuS_69qV8v_A@mail.gmail.com>
Message-ID: <CAPipc=02_f9AYxL_71kJi5L9VSbFJqULPG6hwx+4gDHRbCTTew@mail.gmail.com>

Also, I'm sorry if the tone of the email is hostile, I don't mean it that
way :) I just want to start a discussion about compiler and language design
around lazy languages that permit bottom as an inhabitant.

On Tue 19 Dec, 2017, 08:20 (IIIT) Siddharth Bhat, <
siddharth.bhat at research.iiit.ac.in> wrote:

> Is that really true, though?
> Usually when you have an infinite loop, you have progress of some sort.
> Infinite loops with no side effects can be removed from the program
> according to the C standard, for example. So, in general, we should allow
> programmers to express termination / progress, right? At that point, no
> computation ever "bottoms out"?
>
> Shouldn't a hypothetical purely functional programming language better
> control this (by eg. Forcing totality?) It seems like we lose much of the
> benefits of purity by muddying the waters with divergence.
>
> From an optimising compiler perspective, Haskell is on some weird
> lose-lose space, where you lose out on traditional compiler techniques that
> work on strict code, but it also does not allow the awesome stuff you could
> do with "pure" computation because bottom lurks everywhere.
>
> What neat optimisations can be done on Haskell that can't be done in a
> traditional imperative language? I genuinely want to know.
>
> What are your thoughts on this?
>
> Cheers
>
>
> Siddharth
>
> On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com> wrote:
>
>> Define "natural".
>>
>> You might want to look into the concept of Turing completeness. One could
>> define a subset of Haskell in which bottoms cannot occur... but it turns
>> out there's a lot of useful things you can't do in such a language. (In
>> strict languages, these often are expressed as infinite loops of one kind
>> or another. Note also that any dependency on external input is an infinite
>> loop from the perspective of the language, since it can only be broken by
>> the external entity providing the input.)
>>
>> On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat <
>> siddharth.bhat at research.iiit.ac.in> wrote:
>>
>>> I've been thinking about the issue of purity and speculation lately, and
>>> from what little I have read, it looks like the presence of bottom hiding
>>> inside a lazy value is a huge issue.
>>>
>>> How "natural" is it for bottoms to exist? If one were to change Haskell
>>> and declare that any haskell value can be speculated upon, what
>>> ramifications does this have?
>>>
>>> Is it totally broken? Is it "correct" but makes programming unpleasant?
>>> What's the catch?
>>>
>>> Thanks,
>>> Siddharth
>>> --
>>> Sending this from my phone, please excuse any typos!
>>>
>>> _______________________________________________
>>> 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                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>> _______________________________________________
>> 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.
>
> --
> Sending this from my phone, please excuse any typos!
>
-- 
Sending this from my phone, please excuse any typos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/5496533a/attachment.html>

From allbery.b at gmail.com  Tue Dec 19 07:29:12 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 19 Dec 2017 02:29:12 -0500
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAPipc=1zo0ky3PxofGVBLFiG5vjFmK4Cg88s_emuS_69qV8v_A@mail.gmail.com>
References: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>
 <CAKFCL4VasL3TE9Zhd+jcN93dzfuQi+6mM4f0uQUrLU0mKJaR3w@mail.gmail.com>
 <CAPipc=1zo0ky3PxofGVBLFiG5vjFmK4Cg88s_emuS_69qV8v_A@mail.gmail.com>
Message-ID: <CAKFCL4V-ouGAYq1bRqaEAyDbKwUHiEJDjaaAnprn7DvFBBqisw@mail.gmail.com>

I'm tempted to refer you to the "Floop and Bloop and Gloop" chapter in
_Gödel, Escher, Bach: an Eternal Golden Braid_.

How exactly do you prove to the compiler that you have made sufficient
progress? It's not enough to assume that doing any particular operation
constitutes progress. And even in cases where you can provide such a proof,
it usually requires dependent types to express because "progress" depends
on some value. Consider that any given action may appear to have no side
effects even in C unless the entire program is considered as a single unit.
And also consider that Haskell expressions usually do not have "side
effects" in this sense at all, unless you are in IO... and now you have to
formalize what an IO "side effect" is in order to prove that you have
actually accomplished something.

On Tue, Dec 19, 2017 at 2:20 AM, (IIIT) Siddharth Bhat <
siddharth.bhat at research.iiit.ac.in> wrote:

> Is that really true, though?
> Usually when you have an infinite loop, you have progress of some sort.
> Infinite loops with no side effects can be removed from the program
> according to the C standard, for example. So, in general, we should allow
> programmers to express termination / progress, right? At that point, no
> computation ever "bottoms out"?
>
> Shouldn't a hypothetical purely functional programming language better
> control this (by eg. Forcing totality?) It seems like we lose much of the
> benefits of purity by muddying the waters with divergence.
>
> From an optimising compiler perspective, Haskell is on some weird
> lose-lose space, where you lose out on traditional compiler techniques that
> work on strict code, but it also does not allow the awesome stuff you could
> do with "pure" computation because bottom lurks everywhere.
>
> What neat optimisations can be done on Haskell that can't be done in a
> traditional imperative language? I genuinely want to know.
>
> What are your thoughts on this?
>
> Cheers
> Siddharth
>
> On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com> wrote:
>
>> Define "natural".
>>
>> You might want to look into the concept of Turing completeness. One could
>> define a subset of Haskell in which bottoms cannot occur... but it turns
>> out there's a lot of useful things you can't do in such a language. (In
>> strict languages, these often are expressed as infinite loops of one kind
>> or another. Note also that any dependency on external input is an infinite
>> loop from the perspective of the language, since it can only be broken by
>> the external entity providing the input.)
>>
>> On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat <
>> siddharth.bhat at research.iiit.ac.in> wrote:
>>
>>> I've been thinking about the issue of purity and speculation lately, and
>>> from what little I have read, it looks like the presence of bottom hiding
>>> inside a lazy value is a huge issue.
>>>
>>> How "natural" is it for bottoms to exist? If one were to change Haskell
>>> and declare that any haskell value can be speculated upon, what
>>> ramifications does this have?
>>>
>>> Is it totally broken? Is it "correct" but makes programming unpleasant?
>>> What's the catch?
>>>
>>> Thanks,
>>> Siddharth
>>> --
>>> Sending this from my phone, please excuse any typos!
>>>
>>> _______________________________________________
>>> 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                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>> _______________________________________________
>> 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.
>
> --
> Sending this from my phone, please excuse any typos!
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/5acb94a2/attachment-0001.html>

From tanuki at gmail.com  Tue Dec 19 08:59:10 2017
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Tue, 19 Dec 2017 00:59:10 -0800
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAKFCL4V-ouGAYq1bRqaEAyDbKwUHiEJDjaaAnprn7DvFBBqisw@mail.gmail.com>
References: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>
 <CAKFCL4VasL3TE9Zhd+jcN93dzfuQi+6mM4f0uQUrLU0mKJaR3w@mail.gmail.com>
 <CAPipc=1zo0ky3PxofGVBLFiG5vjFmK4Cg88s_emuS_69qV8v_A@mail.gmail.com>
 <CAKFCL4V-ouGAYq1bRqaEAyDbKwUHiEJDjaaAnprn7DvFBBqisw@mail.gmail.com>
Message-ID: <CAJoPsuApbKitmNAb6G7yZW60-TVbv2TnyW9Wg+tnzbFSM7-=nA@mail.gmail.com>

Extremely relevant blog (even references Bloop/Floop) about how
distinguishing data from codata addresses this issue:
http://blog.sigfpe.com/2007/07/data-and-codata.html

On Dec 18, 2017 11:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:

> I'm tempted to refer you to the "Floop and Bloop and Gloop" chapter in
> _Gödel, Escher, Bach: an Eternal Golden Braid_.
>
> How exactly do you prove to the compiler that you have made sufficient
> progress? It's not enough to assume that doing any particular operation
> constitutes progress. And even in cases where you can provide such a proof,
> it usually requires dependent types to express because "progress" depends
> on some value. Consider that any given action may appear to have no side
> effects even in C unless the entire program is considered as a single unit.
> And also consider that Haskell expressions usually do not have "side
> effects" in this sense at all, unless you are in IO... and now you have to
> formalize what an IO "side effect" is in order to prove that you have
> actually accomplished something.
>
> On Tue, Dec 19, 2017 at 2:20 AM, (IIIT) Siddharth Bhat <
> siddharth.bhat at research.iiit.ac.in> wrote:
>
>> Is that really true, though?
>> Usually when you have an infinite loop, you have progress of some sort.
>> Infinite loops with no side effects can be removed from the program
>> according to the C standard, for example. So, in general, we should allow
>> programmers to express termination / progress, right? At that point, no
>> computation ever "bottoms out"?
>>
>> Shouldn't a hypothetical purely functional programming language better
>> control this (by eg. Forcing totality?) It seems like we lose much of the
>> benefits of purity by muddying the waters with divergence.
>>
>> From an optimising compiler perspective, Haskell is on some weird
>> lose-lose space, where you lose out on traditional compiler techniques that
>> work on strict code, but it also does not allow the awesome stuff you could
>> do with "pure" computation because bottom lurks everywhere.
>>
>> What neat optimisations can be done on Haskell that can't be done in a
>> traditional imperative language? I genuinely want to know.
>>
>> What are your thoughts on this?
>>
>> Cheers
>> Siddharth
>>
>> On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com> wrote:
>>
>>> Define "natural".
>>>
>>> You might want to look into the concept of Turing completeness. One
>>> could define a subset of Haskell in which bottoms cannot occur... but it
>>> turns out there's a lot of useful things you can't do in such a language.
>>> (In strict languages, these often are expressed as infinite loops of one
>>> kind or another. Note also that any dependency on external input is an
>>> infinite loop from the perspective of the language, since it can only be
>>> broken by the external entity providing the input.)
>>>
>>> On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat <
>>> siddharth.bhat at research.iiit.ac.in> wrote:
>>>
>>>> I've been thinking about the issue of purity and speculation lately,
>>>> and from what little I have read, it looks like the presence of bottom
>>>> hiding inside a lazy value is a huge issue.
>>>>
>>>> How "natural" is it for bottoms to exist? If one were to change Haskell
>>>> and declare that any haskell value can be speculated upon, what
>>>> ramifications does this have?
>>>>
>>>> Is it totally broken? Is it "correct" but makes programming unpleasant?
>>>> What's the catch?
>>>>
>>>> Thanks,
>>>> Siddharth
>>>> --
>>>> Sending this from my phone, please excuse any typos!
>>>>
>>>> _______________________________________________
>>>> 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                               sine nomine
>>> associates
>>> allbery.b at gmail.com
>>> ballbery at sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>> _______________________________________________
>>> 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.
>>
>> --
>> Sending this from my phone, please excuse any typos!
>>
>
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> 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/20171219/90fde52e/attachment.html>

From alexey.muranov at gmail.com  Tue Dec 19 13:21:50 2017
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Tue, 19 Dec 2017 14:21:50 +0100
Subject: [Haskell-cafe] Are bottoms ever natural?
Message-ID: <1513689710.8772.0@smtp.gmail.com>

Siddharth,

how would you deal with functions that terminate for some 
arguments/inputs but do not terminate for the others ?

Alexey.

On Tue, 2017-12-19 at 07:20 +0000, (IIIT) Siddharth Bhat wrote:
> > Is that really true, though?
> > Usually when you have an infinite loop, you have progress of some
> > sort. Infinite loops with no side effects can be removed from the
> > program according to the C standard, for example. So, in general, we
> > should allow programmers to express termination / progress, right? 
> At
> > that point, no computation ever "bottoms out"?
> > Shouldn't a hypothetical purely functional programming language
> > better control this (by eg. Forcing totality?) It seems like we lose
> > much of the benefits of purity by muddying the waters with
> > divergence.
> > From an optimising compiler perspective, Haskell is on some weird
> > lose-lose space, where you lose out on traditional compiler
> > techniques that work on strict code, but it also does not allow the
> > awesome stuff you could do with "pure" computation because bottom
> > lurks everywhere.
> > What neat optimisations can be done on Haskell that can't be done in
> > a traditional imperative language? I genuinely want to know.
> > What are your thoughts on this?
> > Cheers
> > Siddharth
> >
> > On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com>
> > wrote:
>> > > Define "natural".
>> > >
>> > > You might want to look into the concept of Turing completeness. 
>> One
>> > > could define a subset of Haskell in which bottoms cannot occur...
>> > > but it turns out there's a lot of useful things you can't do in
>> > > such a language. (In strict languages, these often are expressed 
>> as
>> > > infinite loops of one kind or another. Note also that any
>> > > dependency on external input is an infinite loop from the
>> > > perspective of the language, since it can only be broken by the
>> > > external entity providing the input.)
>> > >
>> > > On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat 
>> <siddharth.b
>> > > hat at research.iiit.ac.in> wrote:
>>> > > > I've been thinking about the issue of purity and speculation
>>> > > > lately, and from what little I have read, it looks like the
>>> > > > presence of bottom hiding inside a lazy value is a huge issue.
>>> > > >
>>> > > > How "natural" is it for bottoms to exist? If one were to 
>>> change
>>> > > > Haskell and declare that any haskell value can be speculated
>>> > > > upon, what ramifications does this have?
>>> > > >
>>> > > > Is it totally broken? Is it "correct" but makes programming
>>> > > > unpleasant? What's the catch?
>>> > > >
>>> > > > Thanks,
>>> > > > Siddharth


From aquagnu at gmail.com  Tue Dec 19 14:35:57 2017
From: aquagnu at gmail.com (Baa)
Date: Tue, 19 Dec 2017 16:35:57 +0200
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <1513689710.8772.0@smtp.gmail.com>
References: <1513689710.8772.0@smtp.gmail.com>
Message-ID: <20171219163557.3b160890@Pavel>

Pure functions can return "undefined" for some arguments values. So,
such function is partially-defined. Its domain has "gaps". This can be
coded in math, to avoid "undefined" (bottom), like

  x = {-100..100, 105, 107..200}

It's impossible in Haskell, but IMHO its possible in F*, due to DepTypes
and RefTypes ;)

IMHO this is the reason to have bottom: possibility to return
"undefined" w/ simple correct type in signature (hidden bottom). If you
have a way to code arguments domains, no need to have bottom for pure
functions to "signal" gaps - gaps happen in run-time :) This is the one
of reasons for bottom to exist, as far as I understand. May be there are
other reasons :)

===
Best regards, Paul

> Siddharth,
> 
> how would you deal with functions that terminate for some 
> arguments/inputs but do not terminate for the others ?
> 
> Alexey.
> 
> On Tue, 2017-12-19 at 07:20 +0000, (IIIT) Siddharth Bhat wrote:
> > > Is that really true, though?
> > > Usually when you have an infinite loop, you have progress of some
> > > sort. Infinite loops with no side effects can be removed from the
> > > program according to the C standard, for example. So, in general,
> > > we should allow programmers to express termination / progress,
> > > right?   
> > At  
> > > that point, no computation ever "bottoms out"?
> > > Shouldn't a hypothetical purely functional programming language
> > > better control this (by eg. Forcing totality?) It seems like we
> > > lose much of the benefits of purity by muddying the waters with
> > > divergence.
> > > From an optimising compiler perspective, Haskell is on some weird
> > > lose-lose space, where you lose out on traditional compiler
> > > techniques that work on strict code, but it also does not allow
> > > the awesome stuff you could do with "pure" computation because
> > > bottom lurks everywhere.
> > > What neat optimisations can be done on Haskell that can't be done
> > > in a traditional imperative language? I genuinely want to know.
> > > What are your thoughts on this?
> > > Cheers
> > > Siddharth
> > >
> > > On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com>
> > > wrote:  
> >> > > Define "natural".
> >> > >
> >> > > You might want to look into the concept of Turing
> >> > > completeness.   
> >> One  
> >> > > could define a subset of Haskell in which bottoms cannot
> >> > > occur... but it turns out there's a lot of useful things you
> >> > > can't do in such a language. (In strict languages, these often
> >> > > are expressed   
> >> as  
> >> > > infinite loops of one kind or another. Note also that any
> >> > > dependency on external input is an infinite loop from the
> >> > > perspective of the language, since it can only be broken by the
> >> > > external entity providing the input.)
> >> > >
> >> > > On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat   
> >> <siddharth.b  
> >> > > hat at research.iiit.ac.in> wrote:  
> >>> > > > I've been thinking about the issue of purity and speculation
> >>> > > > lately, and from what little I have read, it looks like the
> >>> > > > presence of bottom hiding inside a lazy value is a huge
> >>> > > > issue.
> >>> > > >
> >>> > > > How "natural" is it for bottoms to exist? If one were to   
> >>> change  
> >>> > > > Haskell and declare that any haskell value can be speculated
> >>> > > > upon, what ramifications does this have?
> >>> > > >
> >>> > > > Is it totally broken? Is it "correct" but makes programming
> >>> > > > unpleasant? What's the catch?
> >>> > > >
> >>> > > > Thanks,
> >>> > > > Siddharth  
> 
> _______________________________________________
> 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 jpaugh at gmx.com  Tue Dec 19 16:32:03 2017
From: jpaugh at gmx.com (Jonathan Paugh)
Date: Tue, 19 Dec 2017 10:32:03 -0600
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <20171219163557.3b160890@Pavel>
References: <1513689710.8772.0@smtp.gmail.com> <20171219163557.3b160890@Pavel>
Message-ID: <BBA4993E-6234-4580-B9C0-AD21F623087B@gmx.com>

In the strictest sense, the math will bottom in exactly the same scenarios that Haskell will, but a human is unlikely to make that mistake because the result is nonsensical. If the set x you've provided is the domain for a given function g, then it doesn't make sense to reason about g(106): since 106 isn't in the domain, g(106) cannot exist in the codomain. Yet, if you're trying to graph the function on a plane, you have to deal it somehow, because 106 will exist on the plane.

Getting to the original topic, it is impossible to avoid divergence in general, even in mathematics, which is in no way retrained by a compiler (although it may be limited by the operating environment ;).  Languages (or maths) which eschew divergence are not very powerful.
 Consider that arithmetic diverges, because division is partial. But we humans often learn to deal with bottoms iimplicitly, by eliminating them from consideration in the first place. That might be analogous to refactoring the program to remove all offending cases, and recompiling.

On December 19, 2017 8:35:57 AM CST, Baa <aquagnu at gmail.com> wrote:
>Pure functions can return "undefined" for some arguments values. So,
>such function is partially-defined. Its domain has "gaps". This can be
>coded in math, to avoid "undefined" (bottom), like
>
>  x = {-100..100, 105, 107..200}
>
>It's impossible in Haskell, but IMHO its possible in F*, due to
>DepTypes
>and RefTypes ;)
>
>IMHO this is the reason to have bottom: possibility to return
>"undefined" w/ simple correct type in signature (hidden bottom). If you
>have a way to code arguments domains, no need to have bottom for pure
>functions to "signal" gaps - gaps happen in run-time :) This is the one
>of reasons for bottom to exist, as far as I understand. May be there
>are
>other reasons :)
>
>===
>Best regards, Paul
>
>> Siddharth,
>> 
>> how would you deal with functions that terminate for some 
>> arguments/inputs but do not terminate for the others ?
>> 
>> Alexey.
>> 
>> On Tue, 2017-12-19 at 07:20 +0000, (IIIT) Siddharth Bhat wrote:
>> > > Is that really true, though?
>> > > Usually when you have an infinite loop, you have progress of some
>> > > sort. Infinite loops with no side effects can be removed from the
>> > > program according to the C standard, for example. So, in general,
>> > > we should allow programmers to express termination / progress,
>> > > right?   
>> > At  
>> > > that point, no computation ever "bottoms out"?
>> > > Shouldn't a hypothetical purely functional programming language
>> > > better control this (by eg. Forcing totality?) It seems like we
>> > > lose much of the benefits of purity by muddying the waters with
>> > > divergence.
>> > > From an optimising compiler perspective, Haskell is on some weird
>> > > lose-lose space, where you lose out on traditional compiler
>> > > techniques that work on strict code, but it also does not allow
>> > > the awesome stuff you could do with "pure" computation because
>> > > bottom lurks everywhere.
>> > > What neat optimisations can be done on Haskell that can't be done
>> > > in a traditional imperative language? I genuinely want to know.
>> > > What are your thoughts on this?
>> > > Cheers
>> > > Siddharth
>> > >
>> > > On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com>
>> > > wrote:  
>> >> > > Define "natural".
>> >> > >
>> >> > > You might want to look into the concept of Turing
>> >> > > completeness.   
>> >> One  
>> >> > > could define a subset of Haskell in which bottoms cannot
>> >> > > occur... but it turns out there's a lot of useful things you
>> >> > > can't do in such a language. (In strict languages, these often
>> >> > > are expressed   
>> >> as  
>> >> > > infinite loops of one kind or another. Note also that any
>> >> > > dependency on external input is an infinite loop from the
>> >> > > perspective of the language, since it can only be broken by
>the
>> >> > > external entity providing the input.)
>> >> > >
>> >> > > On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat   
>> >> <siddharth.b  
>> >> > > hat at research.iiit.ac.in> wrote:  
>> >>> > > > I've been thinking about the issue of purity and
>speculation
>> >>> > > > lately, and from what little I have read, it looks like the
>> >>> > > > presence of bottom hiding inside a lazy value is a huge
>> >>> > > > issue.
>> >>> > > >
>> >>> > > > How "natural" is it for bottoms to exist? If one were to   
>> >>> change  
>> >>> > > > Haskell and declare that any haskell value can be
>speculated
>> >>> > > > upon, what ramifications does this have?
>> >>> > > >
>> >>> > > > Is it totally broken? Is it "correct" but makes programming
>> >>> > > > unpleasant? What's the catch?
>> >>> > > >
>> >>> > > > Thanks,
>> >>> > > > Siddharth  
>> 
>> _______________________________________________
>> 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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/29be817c/attachment.html>

From siddu.druid at gmail.com  Tue Dec 19 16:51:08 2017
From: siddu.druid at gmail.com (Siddharth Bhat)
Date: Tue, 19 Dec 2017 16:51:08 +0000
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <BBA4993E-6234-4580-B9C0-AD21F623087B@gmx.com>
References: <1513689710.8772.0@smtp.gmail.com> <20171219163557.3b160890@Pavel>
 <BBA4993E-6234-4580-B9C0-AD21F623087B@gmx.com>
Message-ID: <CAPipc=0+4fq1wvREnNQbRVgvys8Nh8ttGyxi1CRm1yLwKHChyQ@mail.gmail.com>

So, I have two opinions to share on this:
Regarding the plane example, it is wrong to attempt to graph it on a plane,
precisely because the domain is not the plane.

I am confused by your assertion that it is impossible to avoid divergence
in mathematics: we do not define division as a *partial* function. Rather
we define it as a *total* function on a *restricted domain*.

So, what one would need is the ability to create these restricted domains,
which certain languages have as far as I am aware.

At that point, now that we track our domains and codomains correctly, all
should work out?

I would still like an answer to interesting transformations that are
enabled by having purity and laziness and are not encumbered by the
presence of bottoms.

Cheers,
Siddharth

On Tue 19 Dec, 2017, 20:36 Jonathan Paugh, <jpaugh at gmx.com> wrote:

> In the strictest sense, the math will bottom in exactly the same scenarios
> that Haskell will, but a human is unlikely to make that mistake because the
> result is nonsensical. If the set x you've provided is the domain for a
> given function g, then it doesn't make sense to reason about g(106): since
> 106 isn't in the domain, g(106) cannot exist in the codomain. Yet, if
> you're trying to graph the function on a plane, you have to deal it
> somehow, because 106 will exist on the plane.
>
> Getting to the original topic, it is impossible to avoid divergence in
> general, even in mathematics, which is in no way retrained by a compiler
> (although it may be limited by the operating environment ;). Languages (or
> maths) which eschew divergence are not very powerful.
> Consider that arithmetic diverges, because division is partial. But we
> humans often learn to deal with bottoms iimplicitly, by eliminating them
> from consideration in the first place. That might be analogous to
> refactoring the program to remove all offending cases, and recompiling.
>
> On December 19, 2017 8:35:57 AM CST, Baa <aquagnu at gmail.com> wrote:
>
>> Pure functions can return "undefined" for some arguments values. So,
>> such function is partially-defined. Its domain has "gaps". This can be
>> coded in math, to avoid "undefined" (bottom), like
>>
>>   x = {-100..100, 105, 107..200}
>>
>> It's impossible in Haskell, but IMHO its possible in F*, due to DepTypes
>> and RefTypes ;)
>>
>> IMHO this is the reason to have bottom: possibility to return
>> "undefined" w/ simple correct type in signature (hidden bottom). If you
>> have a way to code arguments domains, no need to have bottom for pure
>> functions to "signal" gaps - gaps happen in run-time :) This is the one
>> of reasons for bottom to exist, as far as I understand. May be there are
>> other reasons :)
>>
>> ===
>> Best regards, Paul
>>
>>  Siddharth,
>>>
>>>  how would you deal with functions that terminate for some
>>>  arguments/inputs but do not terminate for the others ?
>>>
>>>  Alexey.
>>>
>>>  On Tue, 2017-12-19 at 07:20 +0000, (IIIT) Siddharth Bhat wrote:
>>>
>>>>  Is that really true, though?
>>>>>  Usually when you have an infinite loop, you have progress of some
>>>>>  sort. Infinite loops with no side effects can be removed from the
>>>>>  program according to the C standard, for example. So, in general,
>>>>>  we should allow programmers to express termination / progress,
>>>>>  right?
>>>>>
>>>>  At
>>>>
>>>>>  that point, no computation ever "bottoms out"?
>>>>>  Shouldn't a hypothetical purely functional programming language
>>>>>  better control this (by eg. Forcing totality?) It seems like we
>>>>>  lose much of the benefits of purity by muddying the waters with
>>>>>  divergence.
>>>>>  From an optimising compiler perspective, Haskell is on some weird
>>>>>  lose-lose space, where you lose out on traditional compiler
>>>>>  techniques that work on strict code, but it also does not allow
>>>>>  the awesome stuff you could do with "pure" computation because
>>>>>  bottom lurks everywhere.
>>>>>  What neat optimisations can be done on Haskell that can't be done
>>>>>  in a traditional imperative language? I genuinely want to know.
>>>>>  What are your thoughts on this?
>>>>>  Cheers
>>>>>  Siddharth
>>>>>
>>>>>  On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com>
>>>>>  wrote:
>>>>>
>>>>>>  Define "natural".
>>>>>>>
>>>>>>>  You might want to look into the concept of Turing
>>>>>>>  completeness.
>>>>>>>
>>>>>>  One
>>>>>
>>>>>>  could define a subset of Haskell in which bottoms cannot
>>>>>>>  occur... but it turns out there's a lot of useful things you
>>>>>>>  can't do in such a language. (In strict languages, these often
>>>>>>>  are expressed
>>>>>>>
>>>>>>  as
>>>>>
>>>>>>  infinite loops of one kind or another. Note also that any
>>>>>>>  dependency on external input is an infinite loop from the
>>>>>>>  perspective of the language, since it can only be broken by the
>>>>>>>  external entity providing the input.)
>>>>>>>
>>>>>>>  On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat
>>>>>>>
>>>>>>  <siddharth.b
>>>>>
>>>>>>  hat at research.iiit.ac.in> wrote:
>>>>>>>
>>>>>>>>  I've been thinking about the issue of purity and speculation
>>>>>>>>>  lately, and from what little I have read, it looks like the
>>>>>>>>>  presence of bottom hiding inside a lazy value is a huge
>>>>>>>>>  issue.
>>>>>>>>>
>>>>>>>>>  How "natural" is it for bottoms to exist? If one were to
>>>>>>>>>
>>>>>>>>  change
>>>>>>
>>>>>>>  Haskell and declare that any haskell value can be speculated
>>>>>>>>>  upon, what ramifications does this have?
>>>>>>>>>
>>>>>>>>>  Is it totally broken? Is it "correct" but makes programming
>>>>>>>>>  unpleasant? What's the catch?
>>>>>>>>>
>>>>>>>>>  Thanks,
>>>>>>>>>  Siddharth
>>>>>>>>>
>>>>>>>>
>>> ------------------------------
>>>
>>>  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.
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> 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.

-- 
Sending this from my phone, please excuse any typos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/19c65e44/attachment.html>

From allbery.b at gmail.com  Tue Dec 19 17:26:29 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 19 Dec 2017 12:26:29 -0500
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAPipc=0+4fq1wvREnNQbRVgvys8Nh8ttGyxi1CRm1yLwKHChyQ@mail.gmail.com>
References: <1513689710.8772.0@smtp.gmail.com> <20171219163557.3b160890@Pavel>
 <BBA4993E-6234-4580-B9C0-AD21F623087B@gmx.com>
 <CAPipc=0+4fq1wvREnNQbRVgvys8Nh8ttGyxi1CRm1yLwKHChyQ@mail.gmail.com>
Message-ID: <CAKFCL4W=GCac=SqnquiAbXi1ZhzDxVZ7u=Zr6uvF6DmAJE9YhA@mail.gmail.com>

Programs interface with the real world if they are to be useful, and the
real world contains bottoms (including literal ones, ultimately: black
holes). Mathematics is our cognitive tool, not the real world, and can
reject bottoms at least up to a point.

On Tue, Dec 19, 2017 at 11:51 AM, Siddharth Bhat <siddu.druid at gmail.com>
wrote:

> So, I have two opinions to share on this:
> Regarding the plane example, it is wrong to attempt to graph it on a
> plane, precisely because the domain is not the plane.
>
> I am confused by your assertion that it is impossible to avoid divergence
> in mathematics: we do not define division as a *partial* function. Rather
> we define it as a *total* function on a *restricted domain*.
>
> So, what one would need is the ability to create these restricted domains,
> which certain languages have as far as I am aware.
>
> At that point, now that we track our domains and codomains correctly, all
> should work out?
>
> I would still like an answer to interesting transformations that are
> enabled by having purity and laziness and are not encumbered by the
> presence of bottoms.
>
> Cheers,
> Siddharth
>
> On Tue 19 Dec, 2017, 20:36 Jonathan Paugh, <jpaugh at gmx.com> wrote:
>
>> In the strictest sense, the math will bottom in exactly the same
>> scenarios that Haskell will, but a human is unlikely to make that mistake
>> because the result is nonsensical. If the set x you've provided is the
>> domain for a given function g, then it doesn't make sense to reason about
>> g(106): since 106 isn't in the domain, g(106) cannot exist in the codomain.
>> Yet, if you're trying to graph the function on a plane, you have to deal it
>> somehow, because 106 will exist on the plane.
>>
>> Getting to the original topic, it is impossible to avoid divergence in
>> general, even in mathematics, which is in no way retrained by a compiler
>> (although it may be limited by the operating environment ;). Languages (or
>> maths) which eschew divergence are not very powerful.
>> Consider that arithmetic diverges, because division is partial. But we
>> humans often learn to deal with bottoms iimplicitly, by eliminating them
>> from consideration in the first place. That might be analogous to
>> refactoring the program to remove all offending cases, and recompiling.
>>
>> On December 19, 2017 8:35:57 AM CST, Baa <aquagnu at gmail.com> wrote:
>>
>>> Pure functions can return "undefined" for some arguments values. So,
>>> such function is partially-defined. Its domain has "gaps". This can be
>>> coded in math, to avoid "undefined" (bottom), like
>>>
>>>   x = {-100..100, 105, 107..200}
>>>
>>> It's impossible in Haskell, but IMHO its possible in F*, due to DepTypes
>>> and RefTypes ;)
>>>
>>> IMHO this is the reason to have bottom: possibility to return
>>> "undefined" w/ simple correct type in signature (hidden bottom). If you
>>> have a way to code arguments domains, no need to have bottom for pure
>>> functions to "signal" gaps - gaps happen in run-time :) This is the one
>>> of reasons for bottom to exist, as far as I understand. May be there are
>>> other reasons :)
>>>
>>> ===
>>> Best regards, Paul
>>>
>>>  Siddharth,
>>>>
>>>>  how would you deal with functions that terminate for some
>>>>  arguments/inputs but do not terminate for the others ?
>>>>
>>>>  Alexey.
>>>>
>>>>  On Tue, 2017-12-19 at 07:20 +0000, (IIIT) Siddharth Bhat wrote:
>>>>
>>>>>  Is that really true, though?
>>>>>>  Usually when you have an infinite loop, you have progress of some
>>>>>>  sort. Infinite loops with no side effects can be removed from the
>>>>>>  program according to the C standard, for example. So, in general,
>>>>>>  we should allow programmers to express termination / progress,
>>>>>>  right?
>>>>>>
>>>>>  At
>>>>>
>>>>>>  that point, no computation ever "bottoms out"?
>>>>>>  Shouldn't a hypothetical purely functional programming language
>>>>>>  better control this (by eg. Forcing totality?) It seems like we
>>>>>>  lose much of the benefits of purity by muddying the waters with
>>>>>>  divergence.
>>>>>>  From an optimising compiler perspective, Haskell is on some weird
>>>>>>  lose-lose space, where you lose out on traditional compiler
>>>>>>  techniques that work on strict code, but it also does not allow
>>>>>>  the awesome stuff you could do with "pure" computation because
>>>>>>  bottom lurks everywhere.
>>>>>>  What neat optimisations can be done on Haskell that can't be done
>>>>>>  in a traditional imperative language? I genuinely want to know.
>>>>>>  What are your thoughts on this?
>>>>>>  Cheers
>>>>>>  Siddharth
>>>>>>
>>>>>>  On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com>
>>>>>>  wrote:
>>>>>>
>>>>>>>  Define "natural".
>>>>>>>>
>>>>>>>>  You might want to look into the concept of Turing
>>>>>>>>  completeness.
>>>>>>>>
>>>>>>>  One
>>>>>>
>>>>>>>  could define a subset of Haskell in which bottoms cannot
>>>>>>>>  occur... but it turns out there's a lot of useful things you
>>>>>>>>  can't do in such a language. (In strict languages, these often
>>>>>>>>  are expressed
>>>>>>>>
>>>>>>>  as
>>>>>>
>>>>>>>  infinite loops of one kind or another. Note also that any
>>>>>>>>  dependency on external input is an infinite loop from the
>>>>>>>>  perspective of the language, since it can only be broken by the
>>>>>>>>  external entity providing the input.)
>>>>>>>>
>>>>>>>>  On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat
>>>>>>>>
>>>>>>>  <siddharth.b
>>>>>>
>>>>>>>  hat at research.iiit.ac.in> wrote:
>>>>>>>>
>>>>>>>>>  I've been thinking about the issue of purity and speculation
>>>>>>>>>>  lately, and from what little I have read, it looks like the
>>>>>>>>>>  presence of bottom hiding inside a lazy value is a huge
>>>>>>>>>>  issue.
>>>>>>>>>>
>>>>>>>>>>  How "natural" is it for bottoms to exist? If one were to
>>>>>>>>>>
>>>>>>>>>  change
>>>>>>>
>>>>>>>>  Haskell and declare that any haskell value can be speculated
>>>>>>>>>>  upon, what ramifications does this have?
>>>>>>>>>>
>>>>>>>>>>  Is it totally broken? Is it "correct" but makes programming
>>>>>>>>>>  unpleasant? What's the catch?
>>>>>>>>>>
>>>>>>>>>>  Thanks,
>>>>>>>>>>  Siddharth
>>>>>>>>>>
>>>>>>>>>
>>>> ------------------------------
>>>>
>>>>  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.
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> 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.
>
> --
> Sending this from my phone, please excuse any typos!
>
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171219/5a026814/attachment.html>

From jeremy128 at gmail.com  Tue Dec 19 17:37:33 2017
From: jeremy128 at gmail.com (Jeremy Mikkola)
Date: Tue, 19 Dec 2017 09:37:33 -0800
Subject: [Haskell-cafe] Writing an interpreter for a language with
	mutability
In-Reply-To: <d6056299-d7dc-9e10-e8fd-2cbf53d04ef3@durchholz.org>
References: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
 <d6056299-d7dc-9e10-e8fd-2cbf53d04ef3@durchholz.org>
Message-ID: <CAKG4SKunm_YFW+QoQy4zXMq8vGcJJu3Z1OEMGvhVj1+DR13viA@mail.gmail.com>

Hi all, thank you for the replies!

The language this will interpret does not expose pointers (so it acts like
the more modern languages).

I have started to try to wrap my head around IORef and that monad (anyone
know of a "for dummies" guide to those?). I think that they will likely be
exactly what I need.

Thanks again,

- Jeremy Mikkola

On Mon, Dec 18, 2017 at 12:31 PM, Joachim Durchholz <jo at durchholz.org>
wrote:

> Am 17.12.2017 um 22:03 schrieb Jeremy Mikkola:
>
>> How does one go about interpreting a language with mutable objects in
>> Haskell?
>>
>>
>> The best approach I can think of is to represent the language's memory as
>> a `Data.Map.Map RefID LanguageObject` where RefID is some type (probably
>> Int) used as a reference.
>>
>
> It depends on how data is addressed in the language.
> If you wanto interpret a C-style language where every address can be cast
> to an int, then that's the most straightforward (though not necessarily
> best) approach.
> If it is just references to objects as in most, erm, "more modern"
> languages, the Id can be any type. E.g. something based on the language's
> data model - Int | Real | Record | Array, with type parameters as
> appropriate. Upside is that you leverage the Haskell GC that way, downside
> is that you'll need a recursive type (Array is really Array RefId, and my
> Haskell-fu is hilariously inadequate to properly flesh out that recursion).
>
> _______________________________________________
> 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/20171219/8afa2443/attachment.html>

From tikhon at jelv.is  Tue Dec 19 17:55:37 2017
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Tue, 19 Dec 2017 09:55:37 -0800
Subject: [Haskell-cafe] Writing an interpreter for a language with
	mutability
In-Reply-To: <CAKG4SKunm_YFW+QoQy4zXMq8vGcJJu3Z1OEMGvhVj1+DR13viA@mail.gmail.com>
References: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
 <d6056299-d7dc-9e10-e8fd-2cbf53d04ef3@durchholz.org>
 <CAKG4SKunm_YFW+QoQy4zXMq8vGcJJu3Z1OEMGvhVj1+DR13viA@mail.gmail.com>
Message-ID: <CAJN5CVKM_KM7JiUoNXJhpdEjqL8aKbwg8keA3JzH9+gORCDGeg@mail.gmail.com>

"Write Yourself a Scheme in 48 Hours"[1] is a tutorial about implementing
Scheme in Haskell. It takes the approach of modeling mutable variables in
Scheme using IORefs. It's a good place to start learning about these
ideas—in fact, it's pretty much how I learned Haskell.

Looking back at it now I'm not sure I would make the same decisions as the
author any more, but it worked and the tutorial does a good job of guiding
you through what the code does. After you follow that, you should have a
good feeling for how IORefs work in Haskell and how they fit into an
interpreter for a mutable language.

[1]: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours

On Tue, Dec 19, 2017 at 9:37 AM, Jeremy Mikkola <jeremy128 at gmail.com> wrote:

> Hi all, thank you for the replies!
>
> The language this will interpret does not expose pointers (so it acts like
> the more modern languages).
>
> I have started to try to wrap my head around IORef and that monad (anyone
> know of a "for dummies" guide to those?). I think that they will likely be
> exactly what I need.
>
> Thanks again,
>
> - Jeremy Mikkola
>
> On Mon, Dec 18, 2017 at 12:31 PM, Joachim Durchholz <jo at durchholz.org>
> wrote:
>
>> Am 17.12.2017 um 22:03 schrieb Jeremy Mikkola:
>>
>>> How does one go about interpreting a language with mutable objects in
>>> Haskell?
>>>
>>>
>>> The best approach I can think of is to represent the language's memory
>>> as a `Data.Map.Map RefID LanguageObject` where RefID is some type (probably
>>> Int) used as a reference.
>>>
>>
>> It depends on how data is addressed in the language.
>> If you wanto interpret a C-style language where every address can be cast
>> to an int, then that's the most straightforward (though not necessarily
>> best) approach.
>> If it is just references to objects as in most, erm, "more modern"
>> languages, the Id can be any type. E.g. something based on the language's
>> data model - Int | Real | Record | Array, with type parameters as
>> appropriate. Upside is that you leverage the Haskell GC that way, downside
>> is that you'll need a recursive type (Array is really Array RefId, and my
>> Haskell-fu is hilariously inadequate to properly flesh out that recursion).
>>
>> _______________________________________________
>> 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/20171219/f1e0d24f/attachment.html>

From brucker at spamfence.net  Tue Dec 19 20:13:01 2017
From: brucker at spamfence.net (Achim D. Brucker)
Date: Tue, 19 Dec 2017 20:13:01 +0000
Subject: [Haskell-cafe] Cybersecurity Posts (2) at the University of
	Sheffield
Message-ID: <20171219201301.GA9824@fujikawa.home.brucker.ch>

(Apologies for duplicates)



-- 
Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield
               https://www.brucker.ch | https://logicalhacking.com/blog
                           @adbrucker | @logicalhacking 

From brucker at spamfence.net  Tue Dec 19 20:35:17 2017
From: brucker at spamfence.net (Achim D. Brucker)
Date: Tue, 19 Dec 2017 20:35:17 +0000
Subject: [Haskell-cafe] Cybersecurity Posts (2) at the University of
	Sheffield
Message-ID: <20171219203517.GA13701@fujikawa.home.brucker.ch>

(Apologies for duplicates - resending after I forgot to attach the body of the mail ...)


Dear all,
As part of an ambitious strategy for growth, the Department of
Computer Science is seeking to appoint two Lecturers/Senior
Lecturers/Readers with outstanding expertise in the field of
cybersecurity.

Computer and information security is a rapidly growing interest at
Sheffield. In the Department of Computer Science we have recently
established a Security of Advanced Systems group, led by Professor
John Clark. There is related expertise in other departments such as
Law, Mathematics and Statistics, and Politics. Furthermore,
Sheffiield’s strength in engineering brings many opportunities for
collaborative research in cybersecurity, in areas such as robotics and
advanced manufacturing. To drive our research agenda in cybersecurity
forward, we are now seeking to make two appointments at Lecturer,
Senior Lecturer or Reader Level.

Candidates will demonstrate an excellent research record in
cybersecurity.  Suitable areas of expertise include (but are not
limited to): security policies, threat modelling, authentication,
access control, malware and malware detection, network security,
secure protocols, intrusion detection, and human factors and
security. Candidates who work at the interface of artificial
intelligence and cybersecurity are particularly encouraged to apply.

In 2016 we were recognised for our work on diversity and equality with
a Silver Athena Swan award.  Interested candidates may find details of
these (and other) posts at: https://www.sheffield.ac.uk/dcs/jobs/index

Best,
	Achim 

-- 
Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield
               https://www.brucker.ch | https://logicalhacking.com/blog
                           @adbrucker | @logicalhacking 

From will.yager at gmail.com  Tue Dec 19 20:52:01 2017
From: will.yager at gmail.com (Will Yager)
Date: Tue, 19 Dec 2017 15:52:01 -0500
Subject: [Haskell-cafe] Writing an interpreter for a language with
	mutability
In-Reply-To: <CAJN5CVKM_KM7JiUoNXJhpdEjqL8aKbwg8keA3JzH9+gORCDGeg@mail.gmail.com>
References: <CAKG4SKv8T7R84W0=MJCny5i2mgbmf5Tk7ACeduCj5ZCJF1S_XQ@mail.gmail.com>
 <d6056299-d7dc-9e10-e8fd-2cbf53d04ef3@durchholz.org>
 <CAKG4SKunm_YFW+QoQy4zXMq8vGcJJu3Z1OEMGvhVj1+DR13viA@mail.gmail.com>
 <CAJN5CVKM_KM7JiUoNXJhpdEjqL8aKbwg8keA3JzH9+gORCDGeg@mail.gmail.com>
Message-ID: <128E50A6-47F1-4EE8-A047-FAC539085D18@gmail.com>


>  After you follow that, you should have a good feeling for how IORefs work in Haskell and how they fit into an interpreter for a mutable language.

I’m not sure why people jumped to IORefs so quickly. Since you need to look up variable names to get to the IORef underlying the variable anyway, it seems like you might as well avoid IO and just use a (hash)map from variable names to values. 

If you really need the speed boost, you will probably want to instrument different mutable  implementations anyway, so you will probably want an interpreter that’s generic over the choice of mutable variable representation. 

I would make a monad typeclass that encapsulates whatever operations you need on variables, and test it with “StateT (HashMap VarName VarVal)” (pure baseline), something with IORefs, something with ST (preferable to IO), etc. 

—Will



From alexey.muranov at gmail.com  Tue Dec 19 21:23:21 2017
From: alexey.muranov at gmail.com (Alexey Muranov)
Date: Tue, 19 Dec 2017 22:23:21 +0100
Subject: [Haskell-cafe] Are bottoms ever natural?
Message-ID: <1513718601.5509.0@smtp.gmail.com>

Siddharth,

are you aware that the question whether a given element belongs to the 
domain of a given computable function is algorithmically undecidable?

Alexey.

On Tue, 2017-12-19 at 16:51 +0000, Siddharth Bhat wrote:
> > So, I have two opinions to share on this:
> > Regarding the plane example, it is wrong to attempt to graph it on a
> > plane, precisely because the domain is not the plane.
> > I am confused by your assertion that it is impossible to avoid
> > divergence in mathematics: we do not define division as a *partial*
> > function. Rather we define it as a *total* function on a *restricted
> > domain*.
> > So, what one would need is the ability to create these restricted
> > domains, which certain languages have as far as I am aware.
> > At that point, now that we track our domains and codomains 
> correctly,
> > all should work out?
> > I would still like an answer to interesting transformations that are
> > enabled by having purity and laziness and are not encumbered by the
> > presence of bottoms.
> > Cheers,
> > Siddharth
> >




From qdunkan at gmail.com  Tue Dec 19 22:56:05 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 19 Dec 2017 14:56:05 -0800
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAPipc=0+4fq1wvREnNQbRVgvys8Nh8ttGyxi1CRm1yLwKHChyQ@mail.gmail.com>
References: <1513689710.8772.0@smtp.gmail.com> <20171219163557.3b160890@Pavel>
 <BBA4993E-6234-4580-B9C0-AD21F623087B@gmx.com>
 <CAPipc=0+4fq1wvREnNQbRVgvys8Nh8ttGyxi1CRm1yLwKHChyQ@mail.gmail.com>
Message-ID: <CACbaDy6SzcodSuu=BRiQ74wM5nyw-VE2YE8c2seN-jpf4Si8yw@mail.gmail.com>

Dependently typed languages usually have a totality checker and notion of
codata.  Idris seems most likely to have exploited that for optimizations,
but I haven't seen anything about interesting transformations. Its strict
of course but presumably if you're total you could play with that.

On Dec 19, 2017 8:53 AM, "Siddharth Bhat" <siddu.druid at gmail.com> wrote:

> So, I have two opinions to share on this:
> Regarding the plane example, it is wrong to attempt to graph it on a
> plane, precisely because the domain is not the plane.
>
> I am confused by your assertion that it is impossible to avoid divergence
> in mathematics: we do not define division as a *partial* function. Rather
> we define it as a *total* function on a *restricted domain*.
>
> So, what one would need is the ability to create these restricted domains,
> which certain languages have as far as I am aware.
>
> At that point, now that we track our domains and codomains correctly, all
> should work out?
>
> I would still like an answer to interesting transformations that are
> enabled by having purity and laziness and are not encumbered by the
> presence of bottoms.
>
> Cheers,
> Siddharth
>
> On Tue 19 Dec, 2017, 20:36 Jonathan Paugh, <jpaugh at gmx.com> wrote:
>
>> In the strictest sense, the math will bottom in exactly the same
>> scenarios that Haskell will, but a human is unlikely to make that mistake
>> because the result is nonsensical. If the set x you've provided is the
>> domain for a given function g, then it doesn't make sense to reason about
>> g(106): since 106 isn't in the domain, g(106) cannot exist in the codomain.
>> Yet, if you're trying to graph the function on a plane, you have to deal it
>> somehow, because 106 will exist on the plane.
>>
>> Getting to the original topic, it is impossible to avoid divergence in
>> general, even in mathematics, which is in no way retrained by a compiler
>> (although it may be limited by the operating environment ;). Languages (or
>> maths) which eschew divergence are not very powerful.
>> Consider that arithmetic diverges, because division is partial. But we
>> humans often learn to deal with bottoms iimplicitly, by eliminating them
>> from consideration in the first place. That might be analogous to
>> refactoring the program to remove all offending cases, and recompiling.
>>
>> On December 19, 2017 8:35:57 AM CST, Baa <aquagnu at gmail.com> wrote:
>>
>>> Pure functions can return "undefined" for some arguments values. So,
>>> such function is partially-defined. Its domain has "gaps". This can be
>>> coded in math, to avoid "undefined" (bottom), like
>>>
>>>   x = {-100..100, 105, 107..200}
>>>
>>> It's impossible in Haskell, but IMHO its possible in F*, due to DepTypes
>>> and RefTypes ;)
>>>
>>> IMHO this is the reason to have bottom: possibility to return
>>> "undefined" w/ simple correct type in signature (hidden bottom). If you
>>> have a way to code arguments domains, no need to have bottom for pure
>>> functions to "signal" gaps - gaps happen in run-time :) This is the one
>>> of reasons for bottom to exist, as far as I understand. May be there are
>>> other reasons :)
>>>
>>> ===
>>> Best regards, Paul
>>>
>>>  Siddharth,
>>>>
>>>>  how would you deal with functions that terminate for some
>>>>  arguments/inputs but do not terminate for the others ?
>>>>
>>>>  Alexey.
>>>>
>>>>  On Tue, 2017-12-19 at 07:20 +0000, (IIIT) Siddharth Bhat wrote:
>>>>
>>>>>  Is that really true, though?
>>>>>>  Usually when you have an infinite loop, you have progress of some
>>>>>>  sort. Infinite loops with no side effects can be removed from the
>>>>>>  program according to the C standard, for example. So, in general,
>>>>>>  we should allow programmers to express termination / progress,
>>>>>>  right?
>>>>>>
>>>>>  At
>>>>>
>>>>>>  that point, no computation ever "bottoms out"?
>>>>>>  Shouldn't a hypothetical purely functional programming language
>>>>>>  better control this (by eg. Forcing totality?) It seems like we
>>>>>>  lose much of the benefits of purity by muddying the waters with
>>>>>>  divergence.
>>>>>>  From an optimising compiler perspective, Haskell is on some weird
>>>>>>  lose-lose space, where you lose out on traditional compiler
>>>>>>  techniques that work on strict code, but it also does not allow
>>>>>>  the awesome stuff you could do with "pure" computation because
>>>>>>  bottom lurks everywhere.
>>>>>>  What neat optimisations can be done on Haskell that can't be done
>>>>>>  in a traditional imperative language? I genuinely want to know.
>>>>>>  What are your thoughts on this?
>>>>>>  Cheers
>>>>>>  Siddharth
>>>>>>
>>>>>>  On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com>
>>>>>>  wrote:
>>>>>>
>>>>>>>  Define "natural".
>>>>>>>>
>>>>>>>>  You might want to look into the concept of Turing
>>>>>>>>  completeness.
>>>>>>>>
>>>>>>>  One
>>>>>>
>>>>>>>  could define a subset of Haskell in which bottoms cannot
>>>>>>>>  occur... but it turns out there's a lot of useful things you
>>>>>>>>  can't do in such a language. (In strict languages, these often
>>>>>>>>  are expressed
>>>>>>>>
>>>>>>>  as
>>>>>>
>>>>>>>  infinite loops of one kind or another. Note also that any
>>>>>>>>  dependency on external input is an infinite loop from the
>>>>>>>>  perspective of the language, since it can only be broken by the
>>>>>>>>  external entity providing the input.)
>>>>>>>>
>>>>>>>>  On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat
>>>>>>>>
>>>>>>>  <siddharth.b
>>>>>>
>>>>>>>  hat at research.iiit.ac.in> wrote:
>>>>>>>>
>>>>>>>>>  I've been thinking about the issue of purity and speculation
>>>>>>>>>>  lately, and from what little I have read, it looks like the
>>>>>>>>>>  presence of bottom hiding inside a lazy value is a huge
>>>>>>>>>>  issue.
>>>>>>>>>>
>>>>>>>>>>  How "natural" is it for bottoms to exist? If one were to
>>>>>>>>>>
>>>>>>>>>  change
>>>>>>>
>>>>>>>>  Haskell and declare that any haskell value can be speculated
>>>>>>>>>>  upon, what ramifications does this have?
>>>>>>>>>>
>>>>>>>>>>  Is it totally broken? Is it "correct" but makes programming
>>>>>>>>>>  unpleasant? What's the catch?
>>>>>>>>>>
>>>>>>>>>>  Thanks,
>>>>>>>>>>  Siddharth
>>>>>>>>>>
>>>>>>>>>
>>>> ------------------------------
>>>>
>>>>  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.
>>>
>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> _______________________________________________
>> 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.
>
> --
> Sending this from my phone, please excuse any typos!
>
> _______________________________________________
> 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/20171219/b35d3042/attachment.html>

From aquagnu at gmail.com  Wed Dec 20 09:31:06 2017
From: aquagnu at gmail.com (Baa)
Date: Wed, 20 Dec 2017 11:31:06 +0200
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAPipc=02_f9AYxL_71kJi5L9VSbFJqULPG6hwx+4gDHRbCTTew@mail.gmail.com>
References: <CAPipc=3j324n4Cpm-PeJRnXbuOtNdyppKhE5ue1_d3MAUOSoOQ@mail.gmail.com>
 <CAKFCL4VasL3TE9Zhd+jcN93dzfuQi+6mM4f0uQUrLU0mKJaR3w@mail.gmail.com>
 <CAPipc=1zo0ky3PxofGVBLFiG5vjFmK4Cg88s_emuS_69qV8v_A@mail.gmail.com>
 <CAPipc=02_f9AYxL_71kJi5L9VSbFJqULPG6hwx+4gDHRbCTTew@mail.gmail.com>
Message-ID: <20171220113106.6b86549c@Pavel>

Also I want to point out to interesting and powerful language Shen:

     http://shenlanguage.org/learn-shen/index.html

which supports lazy evaluation, dependent types and many other things:
you can construct own rules in type-system level translator. I'm not
familiar with Shen but I suppose it's possible to programming without
"botton" in Shen. It supports Haskell too. By default partial functions
are "tracked" and can be traced, but w/ Dep. types this can be avoided
as I understand...

So, such languages exists ;)

===
Best regards, Paul

> Also, I'm sorry if the tone of the email is hostile, I don't mean it
> that way :) I just want to start a discussion about compiler and
> language design around lazy languages that permit bottom as an
> inhabitant.
> 
> On Tue 19 Dec, 2017, 08:20 (IIIT) Siddharth Bhat, <
> siddharth.bhat at research.iiit.ac.in> wrote:  
> 
> > Is that really true, though?
> > Usually when you have an infinite loop, you have progress of some
> > sort. Infinite loops with no side effects can be removed from the
> > program according to the C standard, for example. So, in general,
> > we should allow programmers to express termination / progress,
> > right? At that point, no computation ever "bottoms out"?
> >
> > Shouldn't a hypothetical purely functional programming language
> > better control this (by eg. Forcing totality?) It seems like we
> > lose much of the benefits of purity by muddying the waters with
> > divergence.
> >
> > From an optimising compiler perspective, Haskell is on some weird
> > lose-lose space, where you lose out on traditional compiler
> > techniques that work on strict code, but it also does not allow the
> > awesome stuff you could do with "pure" computation because bottom
> > lurks everywhere.
> >
> > What neat optimisations can be done on Haskell that can't be done
> > in a traditional imperative language? I genuinely want to know.
> >
> > What are your thoughts on this?
> >
> > Cheers
> >
> >
> > Siddharth
> >
> > On Tue 19 Dec, 2017, 08:09 Brandon Allbery, <allbery.b at gmail.com>
> > wrote: 
> >> Define "natural".
> >>
> >> You might want to look into the concept of Turing completeness.
> >> One could define a subset of Haskell in which bottoms cannot
> >> occur... but it turns out there's a lot of useful things you can't
> >> do in such a language. (In strict languages, these often are
> >> expressed as infinite loops of one kind or another. Note also that
> >> any dependency on external input is an infinite loop from the
> >> perspective of the language, since it can only be broken by the
> >> external entity providing the input.)
> >>
> >> On Tue, Dec 19, 2017 at 1:47 AM, (IIIT) Siddharth Bhat <  
> >> siddharth.bhat at research.iiit.ac.in> wrote:  
> >>  
> >>> I've been thinking about the issue of purity and speculation
> >>> lately, and from what little I have read, it looks like the
> >>> presence of bottom hiding inside a lazy value is a huge issue.
> >>>
> >>> How "natural" is it for bottoms to exist? If one were to change
> >>> Haskell and declare that any haskell value can be speculated
> >>> upon, what ramifications does this have?
> >>>
> >>> Is it totally broken? Is it "correct" but makes programming
> >>> unpleasant? What's the catch?
> >>>
> >>> Thanks,
> >>> Siddharth
> >>> --
> >>> Sending this from my phone, please excuse any typos!
> >>>
> >>> _______________________________________________
> >>> 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                               sine nomine
> >> associates
> >> allbery.b at gmail.com
> >> ballbery at sinenomine.net
> >> unix, openafs, kerberos, infrastructure, xmonad
> >> http://sinenomine.net
> >> _______________________________________________
> >> 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.  
> >
> > --
> > Sending this from my phone, please excuse any typos!
> >  


From jo at durchholz.org  Wed Dec 20 17:50:14 2017
From: jo at durchholz.org (Joachim Durchholz)
Date: Wed, 20 Dec 2017 18:50:14 +0100
Subject: [Haskell-cafe] Are bottoms ever natural?
In-Reply-To: <CAPipc=0+4fq1wvREnNQbRVgvys8Nh8ttGyxi1CRm1yLwKHChyQ@mail.gmail.com>
References: <1513689710.8772.0@smtp.gmail.com> <20171219163557.3b160890@Pavel>
 <BBA4993E-6234-4580-B9C0-AD21F623087B@gmx.com>
 <CAPipc=0+4fq1wvREnNQbRVgvys8Nh8ttGyxi1CRm1yLwKHChyQ@mail.gmail.com>
Message-ID: <d1be0b06-9f4a-e34b-ed6a-e52642fad627@durchholz.org>

Am 19.12.2017 um 17:51 schrieb Siddharth Bhat:
> So, I have two opinions to share on this:
> Regarding the plane example, it is wrong to attempt to graph it on a 
> plane, precisely because the domain is not the plane.

People graph partial functions all the time, e.g. the cotangent:
https://upload.wikimedia.org/wikipedia/commons/b/bf/Cotangent.svg
They simply do not graph the places where the function is undefined.

> I am confused by your assertion that it is impossible to avoid 
> divergence in mathematics: we do not define division as a *partial* 
> function. Rather we define it as a *total* function on a *restricted 
> domain*.

Which amounts to the same thing in practice.
You still need to check that your denominator is non-zero in a division. 
Whether you do that by a type check or a runtime check amounts to 
roughly the same amount of work for the programmer.

> So, what one would need is the ability to create these restricted 
> domains, which certain languages have as far as I am aware.

Yes, but type systems are usually more clunky than assertions.
You can take apart assertions if they are connected by AND, OR, etc. 
Type systems usually do not have that, and those that do are no more 
decidable, which is a no-go for most language designers.

> At that point, now that we track our domains and codomains correctly, 
> all should work out?

Not much better than what we have right now, I fear.

> I would still like an answer to interesting transformations that are 
> enabled by having purity and laziness and are not encumbered by the 
> presence of bottoms.
If you have laziness, you do not know whether the computation will 
terminate before you try, and no amount of type checking will change that.
Unless your type language is powerful enough to express the difference 
between a terminating and a nonterminating computation. Which means that 
now it's the compiler that needs to deal with potentially-bottom values, 
instead of the runtime. Which is a slightly different point on the 
trade-off spectrum, but still just a trade-off.

Regards,
Jo

From ben at well-typed.com  Wed Dec 20 20:48:00 2017
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 20 Dec 2017 15:48:00 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
Message-ID: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>


The GHC development team is pleased to announce the first alpha release
of the 8.4.1 release. The usual release artifacts are available from

    https://downloads.haskell.org/~ghc/8.4.1-alpha1

Note that this release drops compatibility with GCC 4.6 and earlier.
While we generally try to place as few constraints on system toolchain
as possible, this release depends upon the __atomic__ builtins provided
by GCC 4.7 and later (see #14244).


=== Notes on release scheduling ===

The 8.4.1 release marks the first release where GHC will be adhering to
its new, higher-cadence release schedule [1]. Under this new scheme,
major releases will be made in 6-month intervals with interstitial minor
releases as necessary.

In order to minimize the likelihood of schedule slippage and to ensure
adequate testing, each major release will be preceeded by a number of
regular alpha releases. We will begin issuing these releases roughly
three months before the final date of the major release and will issue
roughly one every two weeks during this period. This high release
cadence will allow us to quickly get fixes in to users hands and allow
better feedback on the status of the release.

GHC 8.4 is slated to be released in mid-February but, due to technical
constraints, we are starting the alpha-release cycle a bit later than
planned under the above schedule. For this reason, it would be greatly
appreciated if users could put this alpha through its paces to make up
for lost time.

As always, do let us know if you encounter any trouble in the course of
testing. Thanks for your help!

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171220/b0c856e8/attachment.sig>

From icfp.publicity at googlemail.com  Thu Dec 21 07:19:34 2017
From: icfp.publicity at googlemail.com (Lindsey Kuper)
Date: Wed, 20 Dec 2017 23:19:34 -0800
Subject: [Haskell-cafe] Call for Papers: PACMPL issue ICFP 2018
Message-ID: <5a3b6086873ee_2ce43fdc19055bec821cf@landin.local.mail>

                         PACMPL issue ICFP 2018
                            Call for Papers 

            accepted papers to be invited for presentation at
 The 23rd ACM SIGPLAN International Conference on Functional Programming 
                        St. Louis, Missouri, USA 
                       http://icfp18.sigplan.org/

### Important dates 

Submissions due:    16 March 2018 (Friday) Anywhere on Earth 
                    https://icfp18.hotcrp.com 
Author response:    2 May (Wednesday) - 4 May (Friday) 14:00 UTC
Notification:       18 May (Friday)
Final copy due:     22 June (Friday)
Conference:         24 September (Monday) - 26 September (Wednesday)

### About PACMPL

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

### Scope

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

  * *Language Design*: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming.

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

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

  * *Foundations*: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types.

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

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

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

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

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

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

### Preparation of submissions

**Deadline**: The deadline for submissions is Friday, March 16, 2018, Anywhere on Earth (<https://en.wikipedia.org/wiki/Anywhere_on_Earth>).  This deadline will be strictly enforced.

**Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from <https://www.acm.org/publications/authors/submissions>.  For authors using LaTeX, a lighter-weight package, including only the essential files, is available from <http://sigplan.org/Resources/Author/#acmart-format>.

There is a limit of 27 pages for a full paper or 14 pages for an Experience Report; in either case, the bibliography will not be counted against these limits. These page limits have been chosen to allow essentially the same amount of content with the new single-column format as was possible with the two-column format used in past ICFP conferences. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected.

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

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

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

**Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on Wednesday, May 2, 2018, to read reviews and respond to them.

**Supplementary Materials**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of the paper and learned the identity of the author(s).

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

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

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

### Review Process

This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2018.  We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns.
 
**PACMPL issue ICFP 2018 will employ a two-stage review process.**  The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected.  Authors will be notified of these decisions on May 18, 2018.

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

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

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

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

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

### Information for Authors of Accepted Papers

* As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limits for final versions of papers will be increased to ensure that authors have space to respond to reviewer comments and mandatory revisions.

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

* At least one author of each accepted submissions will be expected to attend and present their paper at the conference.  The schedule for presentations will be determined and shared with authors after the full program has been selected.  Presentations will be videotaped and released online if the presenter consents.

* We intend that the proceedings will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism.

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

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

### Artifact Evaluation

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

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

Further information about the motivations and expectations for Artifact Evaluation can be found at <https://icfp18.sigplan.org/track/icfp-2018-Artifacts>.

### Special categories of papers

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

#### Functional Pearls

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

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

  * an instructive example of program calculation or proof

  * a nifty presentation of an old or new data structure

  * an interesting application of functional programming techniques

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

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

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

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

#### Experience Reports

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

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

  * insights gained from real-world projects using functional programming

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

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

  * curricular issues encountered when using functional programming in education

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

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

  * Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words "Experience Report" followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers.
  
  * Experience Report submissions can be at most 12 pages long, excluding bibliography.

  * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks.
  
  * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel.

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

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

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


### ICFP Organizers 

General Chair: Robby Findler (Northwestern University, USA)

Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) 
                               Ryan R. Newton (Indiana University, USA)
Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) 
Programming Contest Organiser: Matthew Fluet (Rochester Institute of Technology, USA) 
Publicity and Web Chair: Lindsey Kuper (Intel Labs, USA) 
Student Research Competition Chair: Ilya Sergey (University College London, UK) 
Video Co-Chairs: Jose Calderon (Galois, Inc., USA)
                 Nicolas Wu (University of Bristol, UK)
Workshops Co-Chair: David Christiansen (Indiana University, USA)
                    Christophe Scholliers (Universiteit Gent, Belgium)


### PACMPL issue ICFP 2018

Principal Editor: Matthew Flatt (Univesity of Utah, USA)

Review Committee: 

Sandrine Blazy (IRISA, University of Rennes 1, France)
David Christiansen (Indiana University, USA)
Martin Elsman (University of Copenhagen, Denmark)
Marco Gaboardi (University at Buffalo, CUNY, USA)
Sam Lindley (University of Edinburgh, UK)
Heather Miller (Northweastern University, USA / EPFL, Switzerland)
J. Garrett Morris (University of Kansas, USA)
Henrik Nilsson (University of Nottingham, UK)
François Pottier (Inria, France)
Alejandro Russo (Chalmers University of Technology, Sweden)
Ilya Sergey (University College London, UK)
Michael Sperber (Active Group GmbH, Germany)
Wouter Swierstra (Utrecht University, UK)
Éric Tanter (University of Chile, Chile)
Katsuhiro Ueno (Tohoku University, Japan)
Niki Vazou (University of Maryland, USA)
Jeremy Yallop (University of Cambridge, UK)

External Review Committee:

Michael D. Adams (University of Utah, USA)
Amal Ahmed (Northeastern University, USA)
Nada Amin (University of Cambridge, USA)
Zena Ariola (University of Oregon)
Lars Bergstrom (Mozilla Research)
Lars Birkedal (Aarhus University, Denmark)
Edwin Brady ( University of St. Andrews, UK)
William Byrd (University of Alabama at Birmingham, USA)
Giuseppe Castagna (CRNS / University of Paris Diderot, France)
Sheng Chen (University of Louisiana at Lafayette, USA)
Koen Claessen (Chalmers University ot Technology, Sweden)
Ugo Dal Lago (University of Bologna, Italy / Inria, France)
David Darais (University of Vermont, USA)
Joshua Dunfield (Queen’s University, Canada)
Richard Eisenberg (Bryn Mawr College, USA)
Matthew Fluet (Rochester Institute of Technology, USA)
Nate Foster (Cornell University, USA)
Jurriaan Hage (Utrecht University, Netherlands)
David Van Horn (University of Maryland, USA)
Zhenjiang Hu (National Institute of Informatics, Japan)
Suresh Jagannathan (Purdue University, USA)
Simon Peyton Jones (Microsoft Research, UK)
Naoki Kobayashi (University of Tokyo, Japan)
Neelakantan Krishnaswami (University of Cambridge, UK)
Kazutaka Matsuda (Tohoku University, Japan)
Trevor McDonell (University of New South Wales, Australia)
Hernan Melgratti (University of Buenos Aires, Argentina)
Akimasa Morihata (University of Tokyo, Japan)
Aleksandar Nanevski (IMDEA Software Institute, Spain)
Kim Nguyễn (University of Paris-Sud, France)
Cosmin Oancea (DIKU, University of Copenhagen, Denmark)
Bruno C. d. S. Oliveira (University of Hong Kong, China)
Tomas Petricek (University of Cambridge, UK)
Benjamin Pierce (University of Pennsylvania, USA)
Christine Rizkallah (University of Pennsylvania, USA)
Tom Schrijvers (KU Leuven, Belgium)
Manuel Serrano (Inria, France)
Jeremy Siek (Indiana University, USA)
Josef Svenningsson (Chalmers University of Technology, Sweden)
Nicolas Tabareau (Inria, France)
Dimitrios Vytiniotis (Microsoft Research, UK)
Philip Wadler (University of Edinburgh, UK)
Meng Wang (University of Kent, UK)

From oleg.grenrus at iki.fi  Thu Dec 21 20:48:45 2017
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Thu, 21 Dec 2017 22:48:45 +0200
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <CAB-d4A6A9dq5Y=4L+Gu6c9xA=B1khv5fifjWJ4rgsv+gdbBmBQ@mail.gmail.com>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A6A9dq5Y=4L+Gu6c9xA=B1khv5fifjWJ4rgsv+gdbBmBQ@mail.gmail.com>
Message-ID: <8a344c58-3a9b-944e-baa2-d4e10827136d@iki.fi>

I copy & paste Hervert's reddit answer here [1], for ones who don't
follow it:

As the suffix "alpha" implies, this is a very bleeding edge release with
very little guarantees regarding API stability (c.f. new GHC schedule
[2]
<https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedule>).

Put differently, a package that works now with GHC 8.4.1-alpha1 may not
necessarily work with the final GHC 8.4.1 release.

In order to support early adopters in testing GHC 8.4.1-alpha, there's a
new Overlay Hackage Package Index <https://github.com/hvr/head.hackage>
[3] which provides packages patched for unreleased GHCs (currently GHC
8.4.1-alpha1 & GHC 8.5/HEAD). See its README
<https://github.com/hvr/head.hackage#README> [4] for instructions on how
to use it; there's also a shell script included which automates common
workflows; finally there's also support for HEAD.hackage in
themake-travis-yml Travis CI script generator
<https://github.com/haskell-hvr/multi-ghc-travis>. [5] Don't hesitate to
ask if you have questions!

As usual, there's already an (incomplete & work-in-progress) GHC 8.4.x
Migration Guide <https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4>
[6] you can consult and maybe even help complete.


Links:
- [1]:
https://www.reddit.com/r/haskell/comments/7l4b19/announce_ghc_841alpha1_available/drjlc3w/
- [2]:
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedule

- [3]: https://github.com/hvr/head.hackage
- [4]: https://github.com/hvr/head.hackage#README
- [5]: https://github.com/haskell-hvr/multi-ghc-travis
- [6]: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4

Cheers, Oleg


On 21.12.2017 22:16, George Colpitts wrote:
> Thanks Ben. I installed the Mac binaries.
>
> For others who are wondering, you need llvm 5 if you want to use llvm
> with this.
>
> Needless to say, many libraries, e.g. haskell-src-exts, primitive, and
> intero won't compile with this even with --allow-newer
>
> I'll notify those libraries about that in case they want to get
> started on 8.4.1
>
> Cheers
> George
>
> On Wed, Dec 20, 2017 at 4:48 PM Ben Gamari <ben at well-typed.com
> <mailto:ben at well-typed.com>> wrote:
>
>
>     The GHC development team is pleased to announce the first alpha
>     release
>     of the 8.4.1 release. The usual release artifacts are available from
>
>         https://downloads.haskell.org/~ghc/8.4.1-alpha1
>     <https://downloads.haskell.org/%7Eghc/8.4.1-alpha1>
>
>     Note that this release drops compatibility with GCC 4.6 and earlier.
>     While we generally try to place as few constraints on system toolchain
>     as possible, this release depends upon the __atomic__ builtins
>     provided
>     by GCC 4.7 and later (see #14244).
>
>
>     === Notes on release scheduling ===
>
>     The 8.4.1 release marks the first release where GHC will be
>     adhering to
>     its new, higher-cadence release schedule [1]. Under this new scheme,
>     major releases will be made in 6-month intervals with interstitial
>     minor
>     releases as necessary.
>
>     In order to minimize the likelihood of schedule slippage and to ensure
>     adequate testing, each major release will be preceeded by a number of
>     regular alpha releases. We will begin issuing these releases roughly
>     three months before the final date of the major release and will issue
>     roughly one every two weeks during this period. This high release
>     cadence will allow us to quickly get fixes in to users hands and allow
>     better feedback on the status of the release.
>
>     GHC 8.4 is slated to be released in mid-February but, due to technical
>     constraints, we are starting the alpha-release cycle a bit later than
>     planned under the above schedule. For this reason, it would be greatly
>     appreciated if users could put this alpha through its paces to make up
>     for lost time.
>
>     As always, do let us know if you encounter any trouble in the
>     course of
>     testing. Thanks for your help!
>
>     Cheers,
>
>     - Ben
>
>
>     [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
>     _______________________________________________
>     Glasgow-haskell-users mailing list
>     Glasgow-haskell-users at haskell.org
>     <mailto:Glasgow-haskell-users at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


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

From tab at snarc.org  Thu Dec 21 21:57:49 2017
From: tab at snarc.org (Vincent Hanquez)
Date: Thu, 21 Dec 2017 21:57:49 +0000
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <8a344c58-3a9b-944e-baa2-d4e10827136d@iki.fi>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A6A9dq5Y=4L+Gu6c9xA=B1khv5fifjWJ4rgsv+gdbBmBQ@mail.gmail.com>
 <8a344c58-3a9b-944e-baa2-d4e10827136d@iki.fi>
Message-ID: <c5b0e320-117a-1b6b-1016-13ad698f02e2@snarc.org>



On 21/12/17 20:48, Oleg Grenrus wrote:
> I copy & paste Hervert's reddit answer here [1], for ones who don't
> follow it:
>
> As the suffix "alpha" implies, this is a very bleeding edge release with
> very little guarantees regarding API stability (c.f. new GHC schedule
> [2]
> <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Releases/NewSchedule>).
>
> Put differently, a package that works now with GHC 8.4.1-alpha1 may not
> necessarily work with the final GHC 8.4.1 release.

A package that works now with -alpha1 doesn't have to be the same as
the one that work with the final release.

(And that's only in the unlikely case that an alpha->final break API
which in most cases it really shouldn't)

Resorting to another system than the common system for testing, means 
much less
people are actually going to have the opportunity to integrate it in 
their test suite,
which ultimately reduces GHC QA at large.

-- 
Vincent

From hjgtuyl at chello.nl  Fri Dec 22 14:31:59 2017
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Fri, 22 Dec 2017 15:31:59 +0100
Subject: [Haskell-cafe] Happy National Mathematics Day
Message-ID: <op.zbnjzlpbpz0j5l@alquantor>


L.S.,

Happy National Mathematics Day to everyone in India!

Regards,
Henk-Jan van Tuyl


-- 
Message from Stanford University:

Folding at home

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

--
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From ben at well-typed.com  Fri Dec 22 17:08:47 2017
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 22 Dec 2017 12:08:47 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <CAB-d4A63sSrYSBVhrEOO6EcBnZGGdtAcfhvz_TzchC60O4y38w@mail.gmail.com>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A6A9dq5Y=4L+Gu6c9xA=B1khv5fifjWJ4rgsv+gdbBmBQ@mail.gmail.com>
 <CAB-d4A63sSrYSBVhrEOO6EcBnZGGdtAcfhvz_TzchC60O4y38w@mail.gmail.com>
Message-ID: <871sjmd71h.fsf@ben-laptop.smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Probably stating what is obvious and well-know but anyways:
>
>    - On the status page
>    <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1> it would be
>    good to have a link for "Phase 2 of the Semigroup-Monoid Proposal (Herbert
>    Riedel)"

Good catch. I've added a link.

>    - Also IIRC we normally have a page on porting to the new release. It
>    would be good to have that also when we have a chance.
>
Indeed, the migration page can be found here:
https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4. I've added a link
to the 8.4 status page.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171222/85a265f0/attachment.sig>

From mail at nh2.me  Sat Dec 23 01:57:16 2017
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Sat, 23 Dec 2017 02:57:16 +0100
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <CAKFCL4XZXKLbpEy6O+RhyYSUVtOP=r3wcmyc91NgCZcEscu+xg@mail.gmail.com>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
 <CANBN=msv9OTqjseHrRR8hXU2Yf-2D1vRFrHMueeZgZZY6GVSVQ@mail.gmail.com>
 <1e7c3f48-b45f-db46-75f8-a5f11e12e792@users.sourceforge.net>
 <CAKFCL4XZXKLbpEy6O+RhyYSUVtOP=r3wcmyc91NgCZcEscu+xg@mail.gmail.com>
Message-ID: <16500088-ed4e-bb13-df38-067210602a65@nh2.me>

Has anybody filed a bug about this yet?
I think we really should.

I recently observed a similar behaviour in code of a client.
It looked like

main = do
  l <- getSomeList
  let m = buildExpensiveHashMap l
  for_ l $ \element -> do
    print (... lookup l m ...)

And it inlined the `buildExpensiveHashMap`, making the whole thing 100x
slower. A bang on `m` fixed it to keep it outside the loop, but I found
it weird that GHC considered that expression cheap enough to inline.

Niklas

On 09/12/2017 00:59, Brandon Allbery wrote:
> On Fri, Dec 8, 2017 at 9:18 AM, Neil Mayhew
> <neil_mayhew at users.sourceforge.net
> <mailto:neil_mayhew at users.sourceforge.net>> wrote:
> 
>     Good point. Having great optimization isn’t a justification for
>     complete mental laziness on the part of the programmer! However, I
>     did find the behaviour in this case surprising and unintuitive,
>     given ghc’s usual ability to optimize things, and having it change
>     on me when I enabled profiling left me wondering where to go next.
>     The code I presented here is considerably simplified from the
>     original program, and represents a lot of work already expended
>     trying to get to the root of the problem.
> 
> This is actually why I (and likely SPJ) am inclined to consider it a
> bug; while it might be arguable as Sven does, the counterintuitive
> effect when you turn on profiling suggests that it's not intended or
> expected. (Although maybe it should be; the intuition is "profiling
> disables optimization" but what it really does is a bit more subtle than
> that overly simplistic notion.)
> 
> -- 
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com <mailto:allbery.b at gmail.com>                        
>          ballbery at sinenomine.net <mailto:ballbery at sinenomine.net>
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> 
> _______________________________________________
> 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 joshchia at gmail.com  Sat Dec 23 13:36:07 2017
From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=)
Date: Sat, 23 Dec 2017 21:36:07 +0800
Subject: [Haskell-cafe] Shadowing record field names
Message-ID: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>

Quite often, I need to use record types like this:

data Whole1 = Whole1 { part :: Part, ... }
data Whole2 = Whole2 { part :: Part, ... }

Where Whole1 & Whole2 are types of things that have a Part and some other
things. E.g. a Book has an Author, a Title, etc and so does an Article.

The problem is that I'm not actually allowed to use the same name
(author/part) in two different record types. Some people use lens to solve
this. You can have a lens called 'author' for dealing with the Author in
both Book and Article (e.g. using makeClassy).

That's fine, but there's yet another problem. Let's say I have a function
that takes an Author and a [Library] and returns all the Libraries that
have Books or Articles matching the Author. So:

findAuthorLibraries :: Author -> [Library] -> [Library]
findAuthorLibraries author libraries = ...

But I already have a lens called 'author' and ghc will complain about
shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of
'author' for the function argument? Or, should I name the lens
'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with
'the' is quite unreadable because whether or not an argument has that
prefix depends on whether there's a lens with a conflicting name so it adds
noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems
quite an overbearing eyesore because for consistency I would have to use
the prefix for all my field-accessing lenses.

Maybe I should use Lens.Control.TH.makeClassy and then define:

findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
findAuthorLibraries hasAuthor libraries = ...

But that may be making my function more complicated and general than I
want, affecting readability, simplicity, compilation time and maybe even
performance.

In summary, I find that there are ways around the problem but they really
affect readability.

I could also disable the warning about shadowing but that seems pretty
dangerous. It may be OK to disable the warning for the specific cases where
a function argument shadows something from the topmost scope, but GHC does
not allow such selective disabling of that warning.

In a code base that deals mainly with concrete business logic, this problem
probably crops up more than in a code base that deals mainly with more
abstract things.

What do people do to address this problem? Any recommendations or best
practices?

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

From mtesseract at silverratio.net  Sat Dec 23 14:06:45 2017
From: mtesseract at silverratio.net (Moritz Schulte)
Date: Sat, 23 Dec 2017 15:06:45 +0100
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
Message-ID: <20171223140645.GA1650@blackbox.localdomain>

Hi Josh,

the current record-situation is not entirely satisfying, I agree.

Some time ago I wrote down the approach I currently use in this gist:
https://gist.github.com/mtesseract/1b69087b0aeeb6ddd7023ff05f7b7e68.

In a nutshell:

* I use -XDuplicateRecordFields such that I can in fact do this:

> data Whole1 = Whole1 { part :: Part, ... }
> data Whole2 = Whole2 { part :: Part, ... }

* I prefix all record fields with an underscore.

* I use lens' makeFieldsNoPrefix to generate lenses for the fields
  without the need to do any prefixing.

* I import lenses qualified as 'L'.

This means:

* Different records can have the field _author (which I basically only
  use directly during record construction).

* I usually access the author field of a record using record^.L.author.

* I can use a local binding named 'author' just fine, as it clashes
  neither with the record field (_author), nor with the lens
  (L.author).

Not perfect, but so far it's working fine for me.

Best,
Moritz

From lysxia at gmail.com  Sat Dec 23 14:41:29 2017
From: lysxia at gmail.com (Li-yao Xia)
Date: Sat, 23 Dec 2017 09:41:29 -0500
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
Message-ID: <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>

I don't think "authorL" hurts readability. It just seems the logical 
choice if "author" is already taken.

Have you seen generic-lens? The lens for the "author" field is  (field 
@"author") so there is some added noise compared to "authorL", but it 
can be used as a TH-free alternative to makeClassy.

type Field name a = forall s. HasField name s s a a => Lens s s a a

authorL :: Field "author" Author
authorL = field @"author"

Cheers,
Li-yao

On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
> Quite often, I need to use record types like this:
> 
> data Whole1 = Whole1 { part :: Part, ... }
> data Whole2 = Whole2 { part :: Part, ... }
> 
> Where Whole1 & Whole2 are types of things that have a Part and some 
> other things. E.g. a Book has an Author, a Title, etc and so does an 
> Article.
> 
> The problem is that I'm not actually allowed to use the same name 
> (author/part) in two different record types. Some people use lens to 
> solve this. You can have a lens called 'author' for dealing with the 
> Author in both Book and Article (e.g. using makeClassy).
> 
> That's fine, but there's yet another problem. Let's say I have a 
> function that takes an Author and a [Library] and returns all the 
> Libraries that have Books or Articles matching the Author. So:
> 
> findAuthorLibraries :: Author -> [Library] -> [Library]
> findAuthorLibraries author libraries = ...
> 
> But I already have a lens called 'author' and ghc will complain about 
> shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of 
> 'author' for the function argument? Or, should I name the lens 
> 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with 
> 'the' is quite unreadable because whether or not an argument has that 
> prefix depends on whether there's a lens with a conflicting name so it 
> adds noise to the code. Adding a 'Lens' prefix to the 'author' lens also 
> seems quite an overbearing eyesore because for consistency I would have 
> to use the prefix for all my field-accessing lenses.
> 
> Maybe I should use Lens.Control.TH.makeClassy and then define:
> 
> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
> findAuthorLibraries hasAuthor libraries = ...
> 
> But that may be making my function more complicated and general than I 
> want, affecting readability, simplicity, compilation time and maybe even 
> performance.
> 
> In summary, I find that there are ways around the problem but they 
> really affect readability.
> 
> I could also disable the warning about shadowing but that seems pretty 
> dangerous. It may be OK to disable the warning for the specific cases 
> where a function argument shadows something from the topmost scope, but 
> GHC does not allow such selective disabling of that warning.
> 
> In a code base that deals mainly with concrete business logic, this 
> problem probably crops up more than in a code base that deals mainly 
> with more abstract things.
> 
> What do people do to address this problem? Any recommendations or best 
> practices?
> 
> Josh
> 
> 
> _______________________________________________
> 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 neil_mayhew at users.sourceforge.net  Sat Dec 23 16:27:16 2017
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Sat, 23 Dec 2017 09:27:16 -0700
Subject: [Haskell-cafe] Code runs 7x FASTER with profiling
In-Reply-To: <16500088-ed4e-bb13-df38-067210602a65@nh2.me>
References: <782b69b5-bf8c-742f-54a0-d7aabca0c85c@users.sourceforge.net>
 <288a5c9a-94a4-d174-4bd4-153630591447@tu-harburg.de>
 <5e4d64fe-fc7a-2a97-cb0f-d7b1c0ffe86f@users.sourceforge.net>
 <CANBN=msv9OTqjseHrRR8hXU2Yf-2D1vRFrHMueeZgZZY6GVSVQ@mail.gmail.com>
 <1e7c3f48-b45f-db46-75f8-a5f11e12e792@users.sourceforge.net>
 <CAKFCL4XZXKLbpEy6O+RhyYSUVtOP=r3wcmyc91NgCZcEscu+xg@mail.gmail.com>
 <16500088-ed4e-bb13-df38-067210602a65@nh2.me>
Message-ID: <f203881a-66e7-ccb6-1c45-84a3033bfc0e@users.sourceforge.net>

On 2017-12-22 06:57 PM, Niklas Hambüchen wrote:
> Has anybody filed a bug about this yet? I think we really should.
On 2017-12-08 06:58 AM, Neil Mayhew wrote:
> https://ghc.haskell.org/trac/ghc/ticket/14564 - there’s already been > a response (from Simon P-J) and it is being treated as a bug.
Maybe you should add your example to the ticket, Niklas.

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

From andreas.abel at ifi.lmu.de  Sat Dec 23 17:44:12 2017
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Sat, 23 Dec 2017 18:44:12 +0100
Subject: [Haskell-cafe] Hackage / Stackage Idea
In-Reply-To: <ed9d50e45d13b834f0e5697a63a0d181@centromere.net>
References: <ed9d50e45d13b834f0e5697a63a0d181@centromere.net>
Message-ID: <bb82f553-e4f3-6805-35b6-e7addbf5b5f9@ifi.lmu.de>

I agree some kind of quality certificates should exist on Hackage. 
--Andreas

On 06.12.2017 15:12, alex at centromere.net wrote:
> Hi all,
> 
> I use Haskell in production, and when choosing a library I wonder, "Is
> this package production-ready?". In addition to evaluating the quality
> of the code, I consider various factors such as the most recent upload
> date, number of downloads, the age of the last commit, the author's
> reputation, the number of packages which depend on that package, and the
> number of issues open and closed.
> 
> I think it would be interesting to add a feature to Hackage and/or
> Stackage which allows companies to advertise that they use a package
> in production. If they elect to be anonymous, only the count would
> increase. I believe that this data would not only help inform my library
> choices, but also help communicate Haskell's merits to industry.
> 
> What do you all think?
> 
> Alex
> _______________________________________________
> 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.


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www.cse.chalmers.se/~abela/

From tikhon at jelv.is  Sat Dec 23 19:47:22 2017
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Sat, 23 Dec 2017 11:47:22 -0800
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
 <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
Message-ID: <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>

This is a real pain point with records in Haskell.

The fundamental problem is that unlike most languages with records or
object, field names are treated as normal identifiers in Haskell. Other
languages make fields special—you can only use them with the . operator or
in other select contexts. The advantage is that you can do things like
`a.author == author`; the disadvantage is that fields become a second-class
citizen.

At work, we have a solution that's really nice to use built on top of
DuplicateRecordFields and OverloadedLabels. Our approach follows the ideas
in the OverloadedRecordFields proposal but with a lens flavor—very similar
to the overloaded-records[1] package. (We don't use that package directly
because I wrote our own version before I knew about it and I like the
ergonomics of our internal version a bit more.)

We have a couple of typeclasses for reading and writing fields:

class HasField (field :: Symbol) s a | s -> a where
  getField :: s -> a

class UpdatesField (field :: Symbol) s t b | name t -> b, name s b -> t
where
  updateField :: s -> b -> t

A record field can be both read and updated:

type Field field s t a b = (HasField field s a, UpdatesField field name s t
b)

field :: forall (name :: Symbol) s t a b. Field name s t a b => Lens s t a b
field = lens (getField @name) (updateField @name)

Then we have some Template Haskell for generating instances of these
classes. Here's a contrived example:

data Foo a = Foo { bar :: [a] }

record ''Foo

which generates:

instance HasField "bar" (Foo a) a where
  getField = bar

instance UpdatesField "bar" (Foo a) (Foo b) b where
  updateField foo bar' = foo { bar = bar' }

Given these, we can already write code looking up fields as lenses:

> Foo [1,2,3] ^. field @"bar"
[1,2,3]

Now fields aren't normal identifiers any more, the names can be shared over
different records (with DuplicateRecordFields) and you can write functions
polymorphic over any record with a given field.

The names and details here are a bit different, but I believe this is
otherwise exactly what overloaded-records gives you. You could also replace
the TH to generate instances with generics in the style of the generic-lens
library.

However, the field @"bar" is painfully verbose. We solve this using
OverloadedLabels and a somewhat shady orphan instance for IsLabel:

instance (Functor f, Field name s t a b, a' ~ (a -> f b), b' ~ (s -> f t))
=> IsLabel name (a' -> b') where
  fromLabel = field @name

The details are a bit fiddly, but this is what we need to make type
inference work correctly. This lets us replace field @"name" with #name:

> Foo [1,2,3] ^. #bar
[1,2,3]
> Foo [1,2,3] & #bar . each %~ show
Foo { bar = ["1","2","3"] }

The downside is that this is an orphan instance for IsLabel for *all
functions*. You would not want to use this in a library but it's fine in an
executable as long as you don't mind potentially needing to reword things
if a similar IsLabel instance is added to base. (A risk I'm willing to take
for better syntax :))

Apart from that (somewhat serious) downside, the final result is pretty
much perfect: fields are first-class citizens (as lenses) and are not in
the same scope as identifiers. We've been using this extensively throughout
our whole project and it's been perfect—perhaps surprisingly, we haven't
run into any issues with type inference or type error messages (beyond what
you normally get with lens).

With this addition, Haskell records went from being a real blemish on the
language to being the best I've ever used. The orphan instance is a
definite red flag and you should absolutely *not* have that instance in a
library, but if you're working on a standalone executable or some extensive
internal code, I think it's absolutely worth it.

[1]: https://hackage.haskell.org/package/overloaded-records

[2]: https://hackage.haskell.org/package/generic-lens


On Sat, Dec 23, 2017 at 6:41 AM, Li-yao Xia <lysxia at gmail.com> wrote:

> I don't think "authorL" hurts readability. It just seems the logical
> choice if "author" is already taken.
>
> Have you seen generic-lens? The lens for the "author" field is  (field
> @"author") so there is some added noise compared to "authorL", but it can
> be used as a TH-free alternative to makeClassy.
>
> type Field name a = forall s. HasField name s s a a => Lens s s a a
>
> authorL :: Field "author" Author
> authorL = field @"author"
>
> Cheers,
> Li-yao
>
>
> On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
>
>> Quite often, I need to use record types like this:
>>
>> data Whole1 = Whole1 { part :: Part, ... }
>> data Whole2 = Whole2 { part :: Part, ... }
>>
>> Where Whole1 & Whole2 are types of things that have a Part and some other
>> things. E.g. a Book has an Author, a Title, etc and so does an Article.
>>
>> The problem is that I'm not actually allowed to use the same name
>> (author/part) in two different record types. Some people use lens to solve
>> this. You can have a lens called 'author' for dealing with the Author in
>> both Book and Article (e.g. using makeClassy).
>>
>> That's fine, but there's yet another problem. Let's say I have a function
>> that takes an Author and a [Library] and returns all the Libraries that
>> have Books or Articles matching the Author. So:
>>
>> findAuthorLibraries :: Author -> [Library] -> [Library]
>> findAuthorLibraries author libraries = ...
>>
>> But I already have a lens called 'author' and ghc will complain about
>> shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of
>> 'author' for the function argument? Or, should I name the lens
>> 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with
>> 'the' is quite unreadable because whether or not an argument has that
>> prefix depends on whether there's a lens with a conflicting name so it adds
>> noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems
>> quite an overbearing eyesore because for consistency I would have to use
>> the prefix for all my field-accessing lenses.
>>
>> Maybe I should use Lens.Control.TH.makeClassy and then define:
>>
>> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
>> findAuthorLibraries hasAuthor libraries = ...
>>
>> But that may be making my function more complicated and general than I
>> want, affecting readability, simplicity, compilation time and maybe even
>> performance.
>>
>> In summary, I find that there are ways around the problem but they really
>> affect readability.
>>
>> I could also disable the warning about shadowing but that seems pretty
>> dangerous. It may be OK to disable the warning for the specific cases where
>> a function argument shadows something from the topmost scope, but GHC does
>> not allow such selective disabling of that warning.
>>
>> In a code base that deals mainly with concrete business logic, this
>> problem probably crops up more than in a code base that deals mainly with
>> more abstract things.
>>
>> What do people do to address this problem? Any recommendations or best
>> practices?
>>
>> Josh
>>
>>
>> _______________________________________________
>> 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/20171223/8a116e9a/attachment.html>

From siddu.druid at gmail.com  Sat Dec 23 20:01:12 2017
From: siddu.druid at gmail.com (Siddharth Bhat)
Date: Sat, 23 Dec 2017 20:01:12 +0000
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
 <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
 <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>
Message-ID: <CAPipc=2MyBeXakyRuNQAoajQM20b0U+Xu72shkYkqT94hMVOCQ@mail.gmail.com>

At the risk of derailing the thread, what exactly does it mean to be an
"orphan instance"? And where does "#bar" come from, I've never seen that
syntax before :) I followed the exposition up to that point, if it helps.

Thanks,
Siddharth

On Sun 24 Dec, 2017, 01:23 Tikhon Jelvis, <tikhon at jelv.is> wrote:

> This is a real pain point with records in Haskell.
>
> The fundamental problem is that unlike most languages with records or
> object, field names are treated as normal identifiers in Haskell. Other
> languages make fields special—you can only use them with the . operator
> or in other select contexts. The advantage is that you can do things like
> `a.author == author`; the disadvantage is that fields become a second-class
> citizen.
>
> At work, we have a solution that's really nice to use built on top of
> DuplicateRecordFields and OverloadedLabels. Our approach follows the ideas
> in the OverloadedRecordFields proposal but with a lens flavor—very
> similar to the overloaded-records[1] package. (We don't use that package
> directly because I wrote our own version before I knew about it and I like
> the ergonomics of our internal version a bit more.)
>
> We have a couple of typeclasses for reading and writing fields:
>
> class HasField (field :: Symbol) s a | s -> a where
>   getField :: s -> a
>
> class UpdatesField (field :: Symbol) s t b | name t -> b, name s b -> t
> where
>   updateField :: s -> b -> t
>
> A record field can be both read and updated:
>
> type Field field s t a b = (HasField field s a, UpdatesField field name s
> t b)
>
> field :: forall (name :: Symbol) s t a b. Field name s t a b => Lens s t a
> b
> field = lens (getField @name) (updateField @name)
>
> Then we have some Template Haskell for generating instances of these
> classes. Here's a contrived example:
>
> data Foo a = Foo { bar :: [a] }
>
> record ''Foo
>
> which generates:
>
> instance HasField "bar" (Foo a) a where
>   getField = bar
>
> instance UpdatesField "bar" (Foo a) (Foo b) b where
>   updateField foo bar' = foo { bar = bar' }
>
> Given these, we can already write code looking up fields as lenses:
>
> > Foo [1,2,3] ^. field @"bar"
> [1,2,3]
>
> Now fields aren't normal identifiers any more, the names can be shared
> over different records (with DuplicateRecordFields) and you can write
> functions polymorphic over any record with a given field.
>
> The names and details here are a bit different, but I believe this is
> otherwise exactly what overloaded-records gives you. You could also replace
> the TH to generate instances with generics in the style of the generic-lens
> library.
>
> However, the field @"bar" is painfully verbose. We solve this using
> OverloadedLabels and a somewhat shady orphan instance for IsLabel:
>
> instance (Functor f, Field name s t a b, a' ~ (a -> f b), b' ~ (s -> f t))
> => IsLabel name (a' -> b') where
>   fromLabel = field @name
>
> The details are a bit fiddly, but this is what we need to make type
> inference work correctly. This lets us replace field @"name" with #name:
>
> > Foo [1,2,3] ^. #bar
> [1,2,3]
> > Foo [1,2,3] & #bar . each %~ show
> Foo { bar = ["1","2","3"] }
>
> The downside is that this is an orphan instance for IsLabel for *all
> functions*. You would not want to use this in a library but it's fine in an
> executable as long as you don't mind potentially needing to reword things
> if a similar IsLabel instance is added to base. (A risk I'm willing to take
> for better syntax :))
>
> Apart from that (somewhat serious) downside, the final result is pretty
> much perfect: fields are first-class citizens (as lenses) and are not in
> the same scope as identifiers. We've been using this extensively throughout
> our whole project and it's been perfect—perhaps surprisingly, we haven't
> run into any issues with type inference or type error messages (beyond what
> you normally get with lens).
>
> With this addition, Haskell records went from being a real blemish on the
> language to being the best I've ever used. The orphan instance is a
> definite red flag and you should absolutely *not* have that instance in a
> library, but if you're working on a standalone executable or some extensive
> internal code, I think it's absolutely worth it.
>
> [1]: https://hackage.haskell.org/package/overloaded-records
>
> [2]: https://hackage.haskell.org/package/generic-lens
>
>
> On Sat, Dec 23, 2017 at 6:41 AM, Li-yao Xia <lysxia at gmail.com> wrote:
>
>> I don't think "authorL" hurts readability. It just seems the logical
>> choice if "author" is already taken.
>>
>> Have you seen generic-lens? The lens for the "author" field is  (field
>> @"author") so there is some added noise compared to "authorL", but it can
>> be used as a TH-free alternative to makeClassy.
>>
>> type Field name a = forall s. HasField name s s a a => Lens s s a a
>>
>> authorL :: Field "author" Author
>> authorL = field @"author"
>>
>> Cheers,
>> Li-yao
>>
>>
>> On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
>>
>>> Quite often, I need to use record types like this:
>>>
>>> data Whole1 = Whole1 { part :: Part, ... }
>>> data Whole2 = Whole2 { part :: Part, ... }
>>>
>>> Where Whole1 & Whole2 are types of things that have a Part and some
>>> other things. E.g. a Book has an Author, a Title, etc and so does an
>>> Article.
>>>
>>> The problem is that I'm not actually allowed to use the same name
>>> (author/part) in two different record types. Some people use lens to solve
>>> this. You can have a lens called 'author' for dealing with the Author in
>>> both Book and Article (e.g. using makeClassy).
>>>
>>> That's fine, but there's yet another problem. Let's say I have a
>>> function that takes an Author and a [Library] and returns all the Libraries
>>> that have Books or Articles matching the Author. So:
>>>
>>> findAuthorLibraries :: Author -> [Library] -> [Library]
>>> findAuthorLibraries author libraries = ...
>>>
>>> But I already have a lens called 'author' and ghc will complain about
>>> shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of
>>> 'author' for the function argument? Or, should I name the lens
>>> 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with
>>> 'the' is quite unreadable because whether or not an argument has that
>>> prefix depends on whether there's a lens with a conflicting name so it adds
>>> noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems
>>> quite an overbearing eyesore because for consistency I would have to use
>>> the prefix for all my field-accessing lenses.
>>>
>>> Maybe I should use Lens.Control.TH.makeClassy and then define:
>>>
>>> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
>>> findAuthorLibraries hasAuthor libraries = ...
>>>
>>> But that may be making my function more complicated and general than I
>>> want, affecting readability, simplicity, compilation time and maybe even
>>> performance.
>>>
>>> In summary, I find that there are ways around the problem but they
>>> really affect readability.
>>>
>>> I could also disable the warning about shadowing but that seems pretty
>>> dangerous. It may be OK to disable the warning for the specific cases where
>>> a function argument shadows something from the topmost scope, but GHC does
>>> not allow such selective disabling of that warning.
>>>
>>> In a code base that deals mainly with concrete business logic, this
>>> problem probably crops up more than in a code base that deals mainly with
>>> more abstract things.
>>>
>>> What do people do to address this problem? Any recommendations or best
>>> practices?
>>>
>>> Josh
>>>
>>>
>>> _______________________________________________
>>> 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.

-- 
Sending this from my phone, please excuse any typos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171223/3a4d4d74/attachment.html>

From tikhon at jelv.is  Sat Dec 23 20:16:35 2017
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Sat, 23 Dec 2017 12:16:35 -0800
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CAPipc=2MyBeXakyRuNQAoajQM20b0U+Xu72shkYkqT94hMVOCQ@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
 <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
 <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>
 <CAPipc=2MyBeXakyRuNQAoajQM20b0U+Xu72shkYkqT94hMVOCQ@mail.gmail.com>
Message-ID: <CAJN5CVKs=QOt-mVXVP9U32GP_nu_F0KTNNvUFDy4jHJ1ZOE+5A@mail.gmail.com>

Please don't worry about derailing—if you had the question, I'm sure a lot
of other people reading did as well.

An "orphan instance" is a typeclass instance defined in a module that
doesn't also define the class or the type. In my example, it's an instance
of the IsLabel class (from GHC.OverloadedLabels) for the function type (a
-> b). This is a problem because Haskell typeclass instances are not
module—a type can only have one instance of a given class *in the entire
program*. This means that if two libraries defined the instance I gave,
*you would not be able to use them together in the same project*. This is
why you should absolutely not define this instance in a library.

An alternative design here would be to define a new type for lenses that
does not overlap with (a -> b). Something like ReifiedLens, defined
specifically to have this instance:

newtype FieldLens s t a b = FieldLens (Lens s t a b)

instance (...) => IsLabel (FieldLens s t a b) where
  ...

Unfortunately, this would make FieldLens incompatible with normal lenses,
leading to a bit of boilerplate each time you had to call a field.

The other alternative is to use RebindableSyntax which lets you substitute
your own IsLabel class in place of the one defined in GHC.OverloadedLabels.
This is probably the neatest solution, but RebindableSyntax feels like a
really heavyweight extension to use. That said, my guess is that we'll use
it in our internal code at work if there is ever a conflict with the
current IsLabel instance we're using. The current experience with records
is too nice to pass up without a fight :).

The #bar syntax uses the OverloadedLabels extension. This adds the IsLabel
class and desugars #bar into fromLabel @"bar"

The @ is type application, so the "bar" in fromLabel @"bar" is a type-level
symbol, not a normal string. This is how we get the name of the field into
the typeclass instance.



On Sat, Dec 23, 2017 at 12:01 PM, Siddharth Bhat <siddu.druid at gmail.com>
wrote:

> At the risk of derailing the thread, what exactly does it mean to be an
> "orphan instance"? And where does "#bar" come from, I've never seen that
> syntax before :) I followed the exposition up to that point, if it helps.
>
> Thanks,
> Siddharth
>
> On Sun 24 Dec, 2017, 01:23 Tikhon Jelvis, <tikhon at jelv.is> wrote:
>
>> This is a real pain point with records in Haskell.
>>
>> The fundamental problem is that unlike most languages with records or
>> object, field names are treated as normal identifiers in Haskell. Other
>> languages make fields special—you can only use them with the . operator
>> or in other select contexts. The advantage is that you can do things like
>> `a.author == author`; the disadvantage is that fields become a second-class
>> citizen.
>>
>> At work, we have a solution that's really nice to use built on top of
>> DuplicateRecordFields and OverloadedLabels. Our approach follows the ideas
>> in the OverloadedRecordFields proposal but with a lens flavor—very
>> similar to the overloaded-records[1] package. (We don't use that package
>> directly because I wrote our own version before I knew about it and I like
>> the ergonomics of our internal version a bit more.)
>>
>> We have a couple of typeclasses for reading and writing fields:
>>
>> class HasField (field :: Symbol) s a | s -> a where
>>   getField :: s -> a
>>
>> class UpdatesField (field :: Symbol) s t b | name t -> b, name s b -> t
>> where
>>   updateField :: s -> b -> t
>>
>> A record field can be both read and updated:
>>
>> type Field field s t a b = (HasField field s a, UpdatesField field name s
>> t b)
>>
>> field :: forall (name :: Symbol) s t a b. Field name s t a b => Lens s t
>> a b
>> field = lens (getField @name) (updateField @name)
>>
>> Then we have some Template Haskell for generating instances of these
>> classes. Here's a contrived example:
>>
>> data Foo a = Foo { bar :: [a] }
>>
>> record ''Foo
>>
>> which generates:
>>
>> instance HasField "bar" (Foo a) a where
>>   getField = bar
>>
>> instance UpdatesField "bar" (Foo a) (Foo b) b where
>>   updateField foo bar' = foo { bar = bar' }
>>
>> Given these, we can already write code looking up fields as lenses:
>>
>> > Foo [1,2,3] ^. field @"bar"
>> [1,2,3]
>>
>> Now fields aren't normal identifiers any more, the names can be shared
>> over different records (with DuplicateRecordFields) and you can write
>> functions polymorphic over any record with a given field.
>>
>> The names and details here are a bit different, but I believe this is
>> otherwise exactly what overloaded-records gives you. You could also replace
>> the TH to generate instances with generics in the style of the generic-lens
>> library.
>>
>> However, the field @"bar" is painfully verbose. We solve this using
>> OverloadedLabels and a somewhat shady orphan instance for IsLabel:
>>
>> instance (Functor f, Field name s t a b, a' ~ (a -> f b), b' ~ (s -> f
>> t)) => IsLabel name (a' -> b') where
>>   fromLabel = field @name
>>
>> The details are a bit fiddly, but this is what we need to make type
>> inference work correctly. This lets us replace field @"name" with #name:
>>
>> > Foo [1,2,3] ^. #bar
>> [1,2,3]
>> > Foo [1,2,3] & #bar . each %~ show
>> Foo { bar = ["1","2","3"] }
>>
>> The downside is that this is an orphan instance for IsLabel for *all
>> functions*. You would not want to use this in a library but it's fine in an
>> executable as long as you don't mind potentially needing to reword things
>> if a similar IsLabel instance is added to base. (A risk I'm willing to take
>> for better syntax :))
>>
>> Apart from that (somewhat serious) downside, the final result is pretty
>> much perfect: fields are first-class citizens (as lenses) and are not in
>> the same scope as identifiers. We've been using this extensively throughout
>> our whole project and it's been perfect—perhaps surprisingly, we haven't
>> run into any issues with type inference or type error messages (beyond what
>> you normally get with lens).
>>
>> With this addition, Haskell records went from being a real blemish on the
>> language to being the best I've ever used. The orphan instance is a
>> definite red flag and you should absolutely *not* have that instance in a
>> library, but if you're working on a standalone executable or some extensive
>> internal code, I think it's absolutely worth it.
>>
>> [1]: https://hackage.haskell.org/package/overloaded-records
>>
>> [2]: https://hackage.haskell.org/package/generic-lens
>>
>>
>> On Sat, Dec 23, 2017 at 6:41 AM, Li-yao Xia <lysxia at gmail.com> wrote:
>>
>>> I don't think "authorL" hurts readability. It just seems the logical
>>> choice if "author" is already taken.
>>>
>>> Have you seen generic-lens? The lens for the "author" field is  (field
>>> @"author") so there is some added noise compared to "authorL", but it can
>>> be used as a TH-free alternative to makeClassy.
>>>
>>> type Field name a = forall s. HasField name s s a a => Lens s s a a
>>>
>>> authorL :: Field "author" Author
>>> authorL = field @"author"
>>>
>>> Cheers,
>>> Li-yao
>>>
>>>
>>> On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
>>>
>>>> Quite often, I need to use record types like this:
>>>>
>>>> data Whole1 = Whole1 { part :: Part, ... }
>>>> data Whole2 = Whole2 { part :: Part, ... }
>>>>
>>>> Where Whole1 & Whole2 are types of things that have a Part and some
>>>> other things. E.g. a Book has an Author, a Title, etc and so does an
>>>> Article.
>>>>
>>>> The problem is that I'm not actually allowed to use the same name
>>>> (author/part) in two different record types. Some people use lens to solve
>>>> this. You can have a lens called 'author' for dealing with the Author in
>>>> both Book and Article (e.g. using makeClassy).
>>>>
>>>> That's fine, but there's yet another problem. Let's say I have a
>>>> function that takes an Author and a [Library] and returns all the Libraries
>>>> that have Books or Articles matching the Author. So:
>>>>
>>>> findAuthorLibraries :: Author -> [Library] -> [Library]
>>>> findAuthorLibraries author libraries = ...
>>>>
>>>> But I already have a lens called 'author' and ghc will complain about
>>>> shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of
>>>> 'author' for the function argument? Or, should I name the lens
>>>> 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with
>>>> 'the' is quite unreadable because whether or not an argument has that
>>>> prefix depends on whether there's a lens with a conflicting name so it adds
>>>> noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems
>>>> quite an overbearing eyesore because for consistency I would have to use
>>>> the prefix for all my field-accessing lenses.
>>>>
>>>> Maybe I should use Lens.Control.TH.makeClassy and then define:
>>>>
>>>> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
>>>> findAuthorLibraries hasAuthor libraries = ...
>>>>
>>>> But that may be making my function more complicated and general than I
>>>> want, affecting readability, simplicity, compilation time and maybe even
>>>> performance.
>>>>
>>>> In summary, I find that there are ways around the problem but they
>>>> really affect readability.
>>>>
>>>> I could also disable the warning about shadowing but that seems pretty
>>>> dangerous. It may be OK to disable the warning for the specific cases where
>>>> a function argument shadows something from the topmost scope, but GHC does
>>>> not allow such selective disabling of that warning.
>>>>
>>>> In a code base that deals mainly with concrete business logic, this
>>>> problem probably crops up more than in a code base that deals mainly with
>>>> more abstract things.
>>>>
>>>> What do people do to address this problem? Any recommendations or best
>>>> practices?
>>>>
>>>> Josh
>>>>
>>>>
>>>> _______________________________________________
>>>> 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.
>
> --
> Sending this from my phone, please excuse any typos!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171223/0fd8f1cf/attachment-0001.html>

From siddu.druid at gmail.com  Sat Dec 23 20:21:55 2017
From: siddu.druid at gmail.com (Siddharth Bhat)
Date: Sat, 23 Dec 2017 20:21:55 +0000
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CAJN5CVKs=QOt-mVXVP9U32GP_nu_F0KTNNvUFDy4jHJ1ZOE+5A@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
 <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
 <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>
 <CAPipc=2MyBeXakyRuNQAoajQM20b0U+Xu72shkYkqT94hMVOCQ@mail.gmail.com>
 <CAJN5CVKs=QOt-mVXVP9U32GP_nu_F0KTNNvUFDy4jHJ1ZOE+5A@mail.gmail.com>
Message-ID: <CAPipc=09p4dpNrOCdX81-CGFb4Ja8OOzbkcFEMSvaFz-vwxCSw@mail.gmail.com>

Ah, thank you! I was unaware of the  "OverloadedLabels" extension.

So, orphan instances are an anti-pattern because their scope is hard to
control? As in, when we import a module, we cannot "choose" to import
typeclass definitions on types, right?

Thanks,
Siddharth

On Sun 24 Dec, 2017, 01:46 Tikhon Jelvis, <tikhon at jelv.is> wrote:

> Please don't worry about derailing—if you had the question, I'm sure a lot
> of other people reading did as well.
>
> An "orphan instance" is a typeclass instance defined in a module that
> doesn't also define the class or the type. In my example, it's an instance
> of the IsLabel class (from GHC.OverloadedLabels) for the function type (a
> -> b). This is a problem because Haskell typeclass instances are not
> module—a type can only have one instance of a given class *in the entire
> program*. This means that if two libraries defined the instance I gave,
> *you would not be able to use them together in the same project*. This is
> why you should absolutely not define this instance in a library.
>
> An alternative design here would be to define a new type for lenses that
> does not overlap with (a -> b). Something like ReifiedLens, defined
> specifically to have this instance:
>
> newtype FieldLens s t a b = FieldLens (Lens s t a b)
>
> instance (...) => IsLabel (FieldLens s t a b) where
>   ...
>
> Unfortunately, this would make FieldLens incompatible with normal lenses,
> leading to a bit of boilerplate each time you had to call a field.
>
> The other alternative is to use RebindableSyntax which lets you substitute
> your own IsLabel class in place of the one defined in GHC.OverloadedLabels.
> This is probably the neatest solution, but RebindableSyntax feels like a
> really heavyweight extension to use. That said, my guess is that we'll use
> it in our internal code at work if there is ever a conflict with the
> current IsLabel instance we're using. The current experience with records
> is too nice to pass up without a fight :).
>
> The #bar syntax uses the OverloadedLabels extension. This adds the IsLabel
> class and desugars #bar into fromLabel @"bar"
>
> The @ is type application, so the "bar" in fromLabel @"bar" is a
> type-level symbol, not a normal string. This is how we get the name of the
> field into the typeclass instance.
>
>
>
> On Sat, Dec 23, 2017 at 12:01 PM, Siddharth Bhat <siddu.druid at gmail.com>
> wrote:
>
>> At the risk of derailing the thread, what exactly does it mean to be an
>> "orphan instance"? And where does "#bar" come from, I've never seen that
>> syntax before :) I followed the exposition up to that point, if it helps.
>>
>> Thanks,
>> Siddharth
>>
>> On Sun 24 Dec, 2017, 01:23 Tikhon Jelvis, <tikhon at jelv.is> wrote:
>>
>>> This is a real pain point with records in Haskell.
>>>
>>> The fundamental problem is that unlike most languages with records or
>>> object, field names are treated as normal identifiers in Haskell. Other
>>> languages make fields special—you can only use them with the . operator
>>> or in other select contexts. The advantage is that you can do things like
>>> `a.author == author`; the disadvantage is that fields become a second-class
>>> citizen.
>>>
>>> At work, we have a solution that's really nice to use built on top of
>>> DuplicateRecordFields and OverloadedLabels. Our approach follows the ideas
>>> in the OverloadedRecordFields proposal but with a lens flavor—very
>>> similar to the overloaded-records[1] package. (We don't use that package
>>> directly because I wrote our own version before I knew about it and I like
>>> the ergonomics of our internal version a bit more.)
>>>
>>> We have a couple of typeclasses for reading and writing fields:
>>>
>>> class HasField (field :: Symbol) s a | s -> a where
>>>   getField :: s -> a
>>>
>>> class UpdatesField (field :: Symbol) s t b | name t -> b, name s b -> t
>>> where
>>>   updateField :: s -> b -> t
>>>
>>> A record field can be both read and updated:
>>>
>>> type Field field s t a b = (HasField field s a, UpdatesField field name
>>> s t b)
>>>
>>> field :: forall (name :: Symbol) s t a b. Field name s t a b => Lens s t
>>> a b
>>> field = lens (getField @name) (updateField @name)
>>>
>>> Then we have some Template Haskell for generating instances of these
>>> classes. Here's a contrived example:
>>>
>>> data Foo a = Foo { bar :: [a] }
>>>
>>> record ''Foo
>>>
>>> which generates:
>>>
>>> instance HasField "bar" (Foo a) a where
>>>   getField = bar
>>>
>>> instance UpdatesField "bar" (Foo a) (Foo b) b where
>>>   updateField foo bar' = foo { bar = bar' }
>>>
>>> Given these, we can already write code looking up fields as lenses:
>>>
>>> > Foo [1,2,3] ^. field @"bar"
>>> [1,2,3]
>>>
>>> Now fields aren't normal identifiers any more, the names can be shared
>>> over different records (with DuplicateRecordFields) and you can write
>>> functions polymorphic over any record with a given field.
>>>
>>> The names and details here are a bit different, but I believe this is
>>> otherwise exactly what overloaded-records gives you. You could also replace
>>> the TH to generate instances with generics in the style of the generic-lens
>>> library.
>>>
>>> However, the field @"bar" is painfully verbose. We solve this using
>>> OverloadedLabels and a somewhat shady orphan instance for IsLabel:
>>>
>>> instance (Functor f, Field name s t a b, a' ~ (a -> f b), b' ~ (s -> f
>>> t)) => IsLabel name (a' -> b') where
>>>   fromLabel = field @name
>>>
>>> The details are a bit fiddly, but this is what we need to make type
>>> inference work correctly. This lets us replace field @"name" with #name:
>>>
>>> > Foo [1,2,3] ^. #bar
>>> [1,2,3]
>>> > Foo [1,2,3] & #bar . each %~ show
>>> Foo { bar = ["1","2","3"] }
>>>
>>> The downside is that this is an orphan instance for IsLabel for *all
>>> functions*. You would not want to use this in a library but it's fine in an
>>> executable as long as you don't mind potentially needing to reword things
>>> if a similar IsLabel instance is added to base. (A risk I'm willing to take
>>> for better syntax :))
>>>
>>> Apart from that (somewhat serious) downside, the final result is pretty
>>> much perfect: fields are first-class citizens (as lenses) and are not in
>>> the same scope as identifiers. We've been using this extensively throughout
>>> our whole project and it's been perfect—perhaps surprisingly, we haven't
>>> run into any issues with type inference or type error messages (beyond what
>>> you normally get with lens).
>>>
>>> With this addition, Haskell records went from being a real blemish on
>>> the language to being the best I've ever used. The orphan instance is a
>>> definite red flag and you should absolutely *not* have that instance in a
>>> library, but if you're working on a standalone executable or some extensive
>>> internal code, I think it's absolutely worth it.
>>>
>>> [1]: https://hackage.haskell.org/package/overloaded-records
>>>
>>> [2]: https://hackage.haskell.org/package/generic-lens
>>>
>>>
>>> On Sat, Dec 23, 2017 at 6:41 AM, Li-yao Xia <lysxia at gmail.com> wrote:
>>>
>>>> I don't think "authorL" hurts readability. It just seems the logical
>>>> choice if "author" is already taken.
>>>>
>>>> Have you seen generic-lens? The lens for the "author" field is  (field
>>>> @"author") so there is some added noise compared to "authorL", but it can
>>>> be used as a TH-free alternative to makeClassy.
>>>>
>>>> type Field name a = forall s. HasField name s s a a => Lens s s a a
>>>>
>>>> authorL :: Field "author" Author
>>>> authorL = field @"author"
>>>>
>>>> Cheers,
>>>> Li-yao
>>>>
>>>>
>>>> On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
>>>>
>>>>> Quite often, I need to use record types like this:
>>>>>
>>>>> data Whole1 = Whole1 { part :: Part, ... }
>>>>> data Whole2 = Whole2 { part :: Part, ... }
>>>>>
>>>>> Where Whole1 & Whole2 are types of things that have a Part and some
>>>>> other things. E.g. a Book has an Author, a Title, etc and so does an
>>>>> Article.
>>>>>
>>>>> The problem is that I'm not actually allowed to use the same name
>>>>> (author/part) in two different record types. Some people use lens to solve
>>>>> this. You can have a lens called 'author' for dealing with the Author in
>>>>> both Book and Article (e.g. using makeClassy).
>>>>>
>>>>> That's fine, but there's yet another problem. Let's say I have a
>>>>> function that takes an Author and a [Library] and returns all the Libraries
>>>>> that have Books or Articles matching the Author. So:
>>>>>
>>>>> findAuthorLibraries :: Author -> [Library] -> [Library]
>>>>> findAuthorLibraries author libraries = ...
>>>>>
>>>>> But I already have a lens called 'author' and ghc will complain about
>>>>> shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of
>>>>> 'author' for the function argument? Or, should I name the lens
>>>>> 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with
>>>>> 'the' is quite unreadable because whether or not an argument has that
>>>>> prefix depends on whether there's a lens with a conflicting name so it adds
>>>>> noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems
>>>>> quite an overbearing eyesore because for consistency I would have to use
>>>>> the prefix for all my field-accessing lenses.
>>>>>
>>>>> Maybe I should use Lens.Control.TH.makeClassy and then define:
>>>>>
>>>>> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
>>>>> findAuthorLibraries hasAuthor libraries = ...
>>>>>
>>>>> But that may be making my function more complicated and general than I
>>>>> want, affecting readability, simplicity, compilation time and maybe even
>>>>> performance.
>>>>>
>>>>> In summary, I find that there are ways around the problem but they
>>>>> really affect readability.
>>>>>
>>>>> I could also disable the warning about shadowing but that seems pretty
>>>>> dangerous. It may be OK to disable the warning for the specific cases where
>>>>> a function argument shadows something from the topmost scope, but GHC does
>>>>> not allow such selective disabling of that warning.
>>>>>
>>>>> In a code base that deals mainly with concrete business logic, this
>>>>> problem probably crops up more than in a code base that deals mainly with
>>>>> more abstract things.
>>>>>
>>>>> What do people do to address this problem? Any recommendations or best
>>>>> practices?
>>>>>
>>>>> Josh
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>
>> --
>> Sending this from my phone, please excuse any typos!
>>
>
> --
Sending this from my phone, please excuse any typos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171223/e2568bcf/attachment.html>

From tikhon at jelv.is  Sat Dec 23 20:31:06 2017
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Sat, 23 Dec 2017 12:31:06 -0800
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CAPipc=09p4dpNrOCdX81-CGFb4Ja8OOzbkcFEMSvaFz-vwxCSw@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
 <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
 <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>
 <CAPipc=2MyBeXakyRuNQAoajQM20b0U+Xu72shkYkqT94hMVOCQ@mail.gmail.com>
 <CAJN5CVKs=QOt-mVXVP9U32GP_nu_F0KTNNvUFDy4jHJ1ZOE+5A@mail.gmail.com>
 <CAPipc=09p4dpNrOCdX81-CGFb4Ja8OOzbkcFEMSvaFz-vwxCSw@mail.gmail.com>
Message-ID: <CAJN5CVLarQFtiYbWhxyeWM23VRPQisaV3kpzfoMzut8zxROqqQ@mail.gmail.com>

Yes, that is a good summary. Typeclass instances are inherently not
modular. There are some tradeoffs to this design—if you want to see an
alternative, take a look at how Scala deals with implicits.

On Sat, Dec 23, 2017 at 12:21 PM, Siddharth Bhat <siddu.druid at gmail.com>
wrote:

> Ah, thank you! I was unaware of the  "OverloadedLabels" extension.
>
> So, orphan instances are an anti-pattern because their scope is hard to
> control? As in, when we import a module, we cannot "choose" to import
> typeclass definitions on types, right?
>
> Thanks,
> Siddharth
>
> On Sun 24 Dec, 2017, 01:46 Tikhon Jelvis, <tikhon at jelv.is> wrote:
>
>> Please don't worry about derailing—if you had the question, I'm sure a
>> lot of other people reading did as well.
>>
>> An "orphan instance" is a typeclass instance defined in a module that
>> doesn't also define the class or the type. In my example, it's an instance
>> of the IsLabel class (from GHC.OverloadedLabels) for the function type (a
>> -> b). This is a problem because Haskell typeclass instances are not
>> module—a type can only have one instance of a given class *in the entire
>> program*. This means that if two libraries defined the instance I gave,
>> *you would not be able to use them together in the same project*. This is
>> why you should absolutely not define this instance in a library.
>>
>> An alternative design here would be to define a new type for lenses that
>> does not overlap with (a -> b). Something like ReifiedLens, defined
>> specifically to have this instance:
>>
>> newtype FieldLens s t a b = FieldLens (Lens s t a b)
>>
>> instance (...) => IsLabel (FieldLens s t a b) where
>>   ...
>>
>> Unfortunately, this would make FieldLens incompatible with normal lenses,
>> leading to a bit of boilerplate each time you had to call a field.
>>
>> The other alternative is to use RebindableSyntax which lets you
>> substitute your own IsLabel class in place of the one defined in
>> GHC.OverloadedLabels. This is probably the neatest solution, but
>> RebindableSyntax feels like a really heavyweight extension to use. That
>> said, my guess is that we'll use it in our internal code at work if there
>> is ever a conflict with the current IsLabel instance we're using. The
>> current experience with records is too nice to pass up without a fight :).
>>
>> The #bar syntax uses the OverloadedLabels extension. This adds the
>> IsLabel class and desugars #bar into fromLabel @"bar"
>>
>> The @ is type application, so the "bar" in fromLabel @"bar" is a
>> type-level symbol, not a normal string. This is how we get the name of the
>> field into the typeclass instance.
>>
>>
>>
>> On Sat, Dec 23, 2017 at 12:01 PM, Siddharth Bhat <siddu.druid at gmail.com>
>> wrote:
>>
>>> At the risk of derailing the thread, what exactly does it mean to be an
>>> "orphan instance"? And where does "#bar" come from, I've never seen that
>>> syntax before :) I followed the exposition up to that point, if it helps.
>>>
>>> Thanks,
>>> Siddharth
>>>
>>> On Sun 24 Dec, 2017, 01:23 Tikhon Jelvis, <tikhon at jelv.is> wrote:
>>>
>>>> This is a real pain point with records in Haskell.
>>>>
>>>> The fundamental problem is that unlike most languages with records or
>>>> object, field names are treated as normal identifiers in Haskell. Other
>>>> languages make fields special—you can only use them with the .
>>>> operator or in other select contexts. The advantage is that you can do
>>>> things like `a.author == author`; the disadvantage is that fields become a
>>>> second-class citizen.
>>>>
>>>> At work, we have a solution that's really nice to use built on top of
>>>> DuplicateRecordFields and OverloadedLabels. Our approach follows the ideas
>>>> in the OverloadedRecordFields proposal but with a lens flavor—very
>>>> similar to the overloaded-records[1] package. (We don't use that package
>>>> directly because I wrote our own version before I knew about it and I like
>>>> the ergonomics of our internal version a bit more.)
>>>>
>>>> We have a couple of typeclasses for reading and writing fields:
>>>>
>>>> class HasField (field :: Symbol) s a | s -> a where
>>>>   getField :: s -> a
>>>>
>>>> class UpdatesField (field :: Symbol) s t b | name t -> b, name s b -> t
>>>> where
>>>>   updateField :: s -> b -> t
>>>>
>>>> A record field can be both read and updated:
>>>>
>>>> type Field field s t a b = (HasField field s a, UpdatesField field name
>>>> s t b)
>>>>
>>>> field :: forall (name :: Symbol) s t a b. Field name s t a b => Lens s
>>>> t a b
>>>> field = lens (getField @name) (updateField @name)
>>>>
>>>> Then we have some Template Haskell for generating instances of these
>>>> classes. Here's a contrived example:
>>>>
>>>> data Foo a = Foo { bar :: [a] }
>>>>
>>>> record ''Foo
>>>>
>>>> which generates:
>>>>
>>>> instance HasField "bar" (Foo a) a where
>>>>   getField = bar
>>>>
>>>> instance UpdatesField "bar" (Foo a) (Foo b) b where
>>>>   updateField foo bar' = foo { bar = bar' }
>>>>
>>>> Given these, we can already write code looking up fields as lenses:
>>>>
>>>> > Foo [1,2,3] ^. field @"bar"
>>>> [1,2,3]
>>>>
>>>> Now fields aren't normal identifiers any more, the names can be shared
>>>> over different records (with DuplicateRecordFields) and you can write
>>>> functions polymorphic over any record with a given field.
>>>>
>>>> The names and details here are a bit different, but I believe this is
>>>> otherwise exactly what overloaded-records gives you. You could also replace
>>>> the TH to generate instances with generics in the style of the generic-lens
>>>> library.
>>>>
>>>> However, the field @"bar" is painfully verbose. We solve this using
>>>> OverloadedLabels and a somewhat shady orphan instance for IsLabel:
>>>>
>>>> instance (Functor f, Field name s t a b, a' ~ (a -> f b), b' ~ (s -> f
>>>> t)) => IsLabel name (a' -> b') where
>>>>   fromLabel = field @name
>>>>
>>>> The details are a bit fiddly, but this is what we need to make type
>>>> inference work correctly. This lets us replace field @"name" with #name:
>>>>
>>>> > Foo [1,2,3] ^. #bar
>>>> [1,2,3]
>>>> > Foo [1,2,3] & #bar . each %~ show
>>>> Foo { bar = ["1","2","3"] }
>>>>
>>>> The downside is that this is an orphan instance for IsLabel for *all
>>>> functions*. You would not want to use this in a library but it's fine in an
>>>> executable as long as you don't mind potentially needing to reword things
>>>> if a similar IsLabel instance is added to base. (A risk I'm willing to take
>>>> for better syntax :))
>>>>
>>>> Apart from that (somewhat serious) downside, the final result is pretty
>>>> much perfect: fields are first-class citizens (as lenses) and are not in
>>>> the same scope as identifiers. We've been using this extensively throughout
>>>> our whole project and it's been perfect—perhaps surprisingly, we haven't
>>>> run into any issues with type inference or type error messages (beyond what
>>>> you normally get with lens).
>>>>
>>>> With this addition, Haskell records went from being a real blemish on
>>>> the language to being the best I've ever used. The orphan instance is a
>>>> definite red flag and you should absolutely *not* have that instance in a
>>>> library, but if you're working on a standalone executable or some extensive
>>>> internal code, I think it's absolutely worth it.
>>>>
>>>> [1]: https://hackage.haskell.org/package/overloaded-records
>>>>
>>>> [2]: https://hackage.haskell.org/package/generic-lens
>>>>
>>>>
>>>> On Sat, Dec 23, 2017 at 6:41 AM, Li-yao Xia <lysxia at gmail.com> wrote:
>>>>
>>>>> I don't think "authorL" hurts readability. It just seems the logical
>>>>> choice if "author" is already taken.
>>>>>
>>>>> Have you seen generic-lens? The lens for the "author" field is  (field
>>>>> @"author") so there is some added noise compared to "authorL", but it can
>>>>> be used as a TH-free alternative to makeClassy.
>>>>>
>>>>> type Field name a = forall s. HasField name s s a a => Lens s s a a
>>>>>
>>>>> authorL :: Field "author" Author
>>>>> authorL = field @"author"
>>>>>
>>>>> Cheers,
>>>>> Li-yao
>>>>>
>>>>>
>>>>> On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
>>>>>
>>>>>> Quite often, I need to use record types like this:
>>>>>>
>>>>>> data Whole1 = Whole1 { part :: Part, ... }
>>>>>> data Whole2 = Whole2 { part :: Part, ... }
>>>>>>
>>>>>> Where Whole1 & Whole2 are types of things that have a Part and some
>>>>>> other things. E.g. a Book has an Author, a Title, etc and so does an
>>>>>> Article.
>>>>>>
>>>>>> The problem is that I'm not actually allowed to use the same name
>>>>>> (author/part) in two different record types. Some people use lens to solve
>>>>>> this. You can have a lens called 'author' for dealing with the Author in
>>>>>> both Book and Article (e.g. using makeClassy).
>>>>>>
>>>>>> That's fine, but there's yet another problem. Let's say I have a
>>>>>> function that takes an Author and a [Library] and returns all the Libraries
>>>>>> that have Books or Articles matching the Author. So:
>>>>>>
>>>>>> findAuthorLibraries :: Author -> [Library] -> [Library]
>>>>>> findAuthorLibraries author libraries = ...
>>>>>>
>>>>>> But I already have a lens called 'author' and ghc will complain about
>>>>>> shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of
>>>>>> 'author' for the function argument? Or, should I name the lens
>>>>>> 'authorLens', 'authorL' or 'lAuthor' instead of 'author'? Prefixing with
>>>>>> 'the' is quite unreadable because whether or not an argument has that
>>>>>> prefix depends on whether there's a lens with a conflicting name so it adds
>>>>>> noise to the code. Adding a 'Lens' prefix to the 'author' lens also seems
>>>>>> quite an overbearing eyesore because for consistency I would have to use
>>>>>> the prefix for all my field-accessing lenses.
>>>>>>
>>>>>> Maybe I should use Lens.Control.TH.makeClassy and then define:
>>>>>>
>>>>>> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
>>>>>> findAuthorLibraries hasAuthor libraries = ...
>>>>>>
>>>>>> But that may be making my function more complicated and general than
>>>>>> I want, affecting readability, simplicity, compilation time and maybe even
>>>>>> performance.
>>>>>>
>>>>>> In summary, I find that there are ways around the problem but they
>>>>>> really affect readability.
>>>>>>
>>>>>> I could also disable the warning about shadowing but that seems
>>>>>> pretty dangerous. It may be OK to disable the warning for the specific
>>>>>> cases where a function argument shadows something from the topmost scope,
>>>>>> but GHC does not allow such selective disabling of that warning.
>>>>>>
>>>>>> In a code base that deals mainly with concrete business logic, this
>>>>>> problem probably crops up more than in a code base that deals mainly with
>>>>>> more abstract things.
>>>>>>
>>>>>> What do people do to address this problem? Any recommendations or
>>>>>> best practices?
>>>>>>
>>>>>> Josh
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>
>>> --
>>> Sending this from my phone, please excuse any typos!
>>>
>>
>> --
> Sending this from my phone, please excuse any typos!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171223/8ed595bc/attachment.html>

From qdunkan at gmail.com  Sat Dec 23 21:21:08 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Sat, 23 Dec 2017 13:21:08 -0800
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CAJN5CVLarQFtiYbWhxyeWM23VRPQisaV3kpzfoMzut8zxROqqQ@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
 <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
 <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>
 <CAPipc=2MyBeXakyRuNQAoajQM20b0U+Xu72shkYkqT94hMVOCQ@mail.gmail.com>
 <CAJN5CVKs=QOt-mVXVP9U32GP_nu_F0KTNNvUFDy4jHJ1ZOE+5A@mail.gmail.com>
 <CAPipc=09p4dpNrOCdX81-CGFb4Ja8OOzbkcFEMSvaFz-vwxCSw@mail.gmail.com>
 <CAJN5CVLarQFtiYbWhxyeWM23VRPQisaV3kpzfoMzut8zxROqqQ@mail.gmail.com>
Message-ID: <CACbaDy4UMGUAy0oaYBYW69MhkM5tSB=wPsdmm0fSDpdUn4r7hA@mail.gmail.com>

Here's another semi-derail: how can you do get/set with side-effects?
This would necessarily be for a record in StateM or something.  For
instance, say to preserve an invariant on a field:

    import qualified Control.Monad.State as State

    data R { _int :: Int }

    modifyInt :: (R -> R) -> State.State R ()
    modifyInt modify = do
        int <- modify <$> State.gets _int
        if even int then State.modify \r -> r { _int = int }
            else Except.throwError "odd"

I couldn't figure out how to get this sort of thing to cooperate with
lenses.  I can make a lens with effects easily enough, but you have to
invoke it via 'State.modify $ ...', at which point you're exposing
State.modify which defeats the idea of trying to enforce invariants.

On Sat, Dec 23, 2017 at 12:31 PM, Tikhon Jelvis <tikhon at jelv.is> wrote:
> Yes, that is a good summary. Typeclass instances are inherently not modular.
> There are some tradeoffs to this design—if you want to see an alternative,
> take a look at how Scala deals with implicits.
>
> On Sat, Dec 23, 2017 at 12:21 PM, Siddharth Bhat <siddu.druid at gmail.com>
> wrote:
>>
>> Ah, thank you! I was unaware of the  "OverloadedLabels" extension.
>>
>> So, orphan instances are an anti-pattern because their scope is hard to
>> control? As in, when we import a module, we cannot "choose" to import
>> typeclass definitions on types, right?
>>
>> Thanks,
>> Siddharth
>>
>>
>> On Sun 24 Dec, 2017, 01:46 Tikhon Jelvis, <tikhon at jelv.is> wrote:
>>>
>>> Please don't worry about derailing—if you had the question, I'm sure a
>>> lot of other people reading did as well.
>>>
>>> An "orphan instance" is a typeclass instance defined in a module that
>>> doesn't also define the class or the type. In my example, it's an instance
>>> of the IsLabel class (from GHC.OverloadedLabels) for the function type (a ->
>>> b). This is a problem because Haskell typeclass instances are not module—a
>>> type can only have one instance of a given class *in the entire program*.
>>> This means that if two libraries defined the instance I gave, *you would not
>>> be able to use them together in the same project*. This is why you should
>>> absolutely not define this instance in a library.
>>>
>>> An alternative design here would be to define a new type for lenses that
>>> does not overlap with (a -> b). Something like ReifiedLens, defined
>>> specifically to have this instance:
>>>
>>> newtype FieldLens s t a b = FieldLens (Lens s t a b)
>>>
>>> instance (...) => IsLabel (FieldLens s t a b) where
>>>   ...
>>>
>>> Unfortunately, this would make FieldLens incompatible with normal lenses,
>>> leading to a bit of boilerplate each time you had to call a field.
>>>
>>> The other alternative is to use RebindableSyntax which lets you
>>> substitute your own IsLabel class in place of the one defined in
>>> GHC.OverloadedLabels. This is probably the neatest solution, but
>>> RebindableSyntax feels like a really heavyweight extension to use. That
>>> said, my guess is that we'll use it in our internal code at work if there is
>>> ever a conflict with the current IsLabel instance we're using. The current
>>> experience with records is too nice to pass up without a fight :).
>>>
>>> The #bar syntax uses the OverloadedLabels extension. This adds the
>>> IsLabel class and desugars #bar into fromLabel @"bar"
>>>
>>> The @ is type application, so the "bar" in fromLabel @"bar" is a
>>> type-level symbol, not a normal string. This is how we get the name of the
>>> field into the typeclass instance.
>>>
>>>
>>>
>>> On Sat, Dec 23, 2017 at 12:01 PM, Siddharth Bhat <siddu.druid at gmail.com>
>>> wrote:
>>>>
>>>> At the risk of derailing the thread, what exactly does it mean to be an
>>>> "orphan instance"? And where does "#bar" come from, I've never seen that
>>>> syntax before :) I followed the exposition up to that point, if it helps.
>>>>
>>>> Thanks,
>>>> Siddharth
>>>>
>>>>
>>>> On Sun 24 Dec, 2017, 01:23 Tikhon Jelvis, <tikhon at jelv.is> wrote:
>>>>>
>>>>> This is a real pain point with records in Haskell.
>>>>>
>>>>> The fundamental problem is that unlike most languages with records or
>>>>> object, field names are treated as normal identifiers in Haskell. Other
>>>>> languages make fields special—you can only use them with the . operator or
>>>>> in other select contexts. The advantage is that you can do things like
>>>>> `a.author == author`; the disadvantage is that fields become a second-class
>>>>> citizen.
>>>>>
>>>>> At work, we have a solution that's really nice to use built on top of
>>>>> DuplicateRecordFields and OverloadedLabels. Our approach follows the ideas
>>>>> in the OverloadedRecordFields proposal but with a lens flavor—very similar
>>>>> to the overloaded-records[1] package. (We don't use that package directly
>>>>> because I wrote our own version before I knew about it and I like the
>>>>> ergonomics of our internal version a bit more.)
>>>>>
>>>>> We have a couple of typeclasses for reading and writing fields:
>>>>>
>>>>> class HasField (field :: Symbol) s a | s -> a where
>>>>>   getField :: s -> a
>>>>>
>>>>> class UpdatesField (field :: Symbol) s t b | name t -> b, name s b -> t
>>>>> where
>>>>>   updateField :: s -> b -> t
>>>>>
>>>>> A record field can be both read and updated:
>>>>>
>>>>> type Field field s t a b = (HasField field s a, UpdatesField field name
>>>>> s t b)
>>>>>
>>>>> field :: forall (name :: Symbol) s t a b. Field name s t a b => Lens s
>>>>> t a b
>>>>> field = lens (getField @name) (updateField @name)
>>>>>
>>>>> Then we have some Template Haskell for generating instances of these
>>>>> classes. Here's a contrived example:
>>>>>
>>>>> data Foo a = Foo { bar :: [a] }
>>>>>
>>>>> record ''Foo
>>>>>
>>>>> which generates:
>>>>>
>>>>> instance HasField "bar" (Foo a) a where
>>>>>   getField = bar
>>>>>
>>>>> instance UpdatesField "bar" (Foo a) (Foo b) b where
>>>>>   updateField foo bar' = foo { bar = bar' }
>>>>>
>>>>> Given these, we can already write code looking up fields as lenses:
>>>>>
>>>>> > Foo [1,2,3] ^. field @"bar"
>>>>> [1,2,3]
>>>>>
>>>>> Now fields aren't normal identifiers any more, the names can be shared
>>>>> over different records (with DuplicateRecordFields) and you can write
>>>>> functions polymorphic over any record with a given field.
>>>>>
>>>>> The names and details here are a bit different, but I believe this is
>>>>> otherwise exactly what overloaded-records gives you. You could also replace
>>>>> the TH to generate instances with generics in the style of the generic-lens
>>>>> library.
>>>>>
>>>>> However, the field @"bar" is painfully verbose. We solve this using
>>>>> OverloadedLabels and a somewhat shady orphan instance for IsLabel:
>>>>>
>>>>> instance (Functor f, Field name s t a b, a' ~ (a -> f b), b' ~ (s -> f
>>>>> t)) => IsLabel name (a' -> b') where
>>>>>   fromLabel = field @name
>>>>>
>>>>> The details are a bit fiddly, but this is what we need to make type
>>>>> inference work correctly. This lets us replace field @"name" with #name:
>>>>>
>>>>> > Foo [1,2,3] ^. #bar
>>>>> [1,2,3]
>>>>> > Foo [1,2,3] & #bar . each %~ show
>>>>> Foo { bar = ["1","2","3"] }
>>>>>
>>>>> The downside is that this is an orphan instance for IsLabel for *all
>>>>> functions*. You would not want to use this in a library but it's fine in an
>>>>> executable as long as you don't mind potentially needing to reword things if
>>>>> a similar IsLabel instance is added to base. (A risk I'm willing to take for
>>>>> better syntax :))
>>>>>
>>>>> Apart from that (somewhat serious) downside, the final result is pretty
>>>>> much perfect: fields are first-class citizens (as lenses) and are not in the
>>>>> same scope as identifiers. We've been using this extensively throughout our
>>>>> whole project and it's been perfect—perhaps surprisingly, we haven't run
>>>>> into any issues with type inference or type error messages (beyond what you
>>>>> normally get with lens).
>>>>>
>>>>> With this addition, Haskell records went from being a real blemish on
>>>>> the language to being the best I've ever used. The orphan instance is a
>>>>> definite red flag and you should absolutely *not* have that instance in a
>>>>> library, but if you're working on a standalone executable or some extensive
>>>>> internal code, I think it's absolutely worth it.
>>>>>
>>>>> [1]: https://hackage.haskell.org/package/overloaded-records
>>>>>
>>>>> [2]: https://hackage.haskell.org/package/generic-lens
>>>>>
>>>>>
>>>>> On Sat, Dec 23, 2017 at 6:41 AM, Li-yao Xia <lysxia at gmail.com> wrote:
>>>>>>
>>>>>> I don't think "authorL" hurts readability. It just seems the logical
>>>>>> choice if "author" is already taken.
>>>>>>
>>>>>> Have you seen generic-lens? The lens for the "author" field is  (field
>>>>>> @"author") so there is some added noise compared to "authorL", but it can be
>>>>>> used as a TH-free alternative to makeClassy.
>>>>>>
>>>>>> type Field name a = forall s. HasField name s s a a => Lens s s a a
>>>>>>
>>>>>> authorL :: Field "author" Author
>>>>>> authorL = field @"author"
>>>>>>
>>>>>> Cheers,
>>>>>> Li-yao
>>>>>>
>>>>>>
>>>>>> On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
>>>>>>>
>>>>>>> Quite often, I need to use record types like this:
>>>>>>>
>>>>>>> data Whole1 = Whole1 { part :: Part, ... }
>>>>>>> data Whole2 = Whole2 { part :: Part, ... }
>>>>>>>
>>>>>>> Where Whole1 & Whole2 are types of things that have a Part and some
>>>>>>> other things. E.g. a Book has an Author, a Title, etc and so does an
>>>>>>> Article.
>>>>>>>
>>>>>>> The problem is that I'm not actually allowed to use the same name
>>>>>>> (author/part) in two different record types. Some people use lens to solve
>>>>>>> this. You can have a lens called 'author' for dealing with the Author in
>>>>>>> both Book and Article (e.g. using makeClassy).
>>>>>>>
>>>>>>> That's fine, but there's yet another problem. Let's say I have a
>>>>>>> function that takes an Author and a [Library] and returns all the Libraries
>>>>>>> that have Books or Articles matching the Author. So:
>>>>>>>
>>>>>>> findAuthorLibraries :: Author -> [Library] -> [Library]
>>>>>>> findAuthorLibraries author libraries = ...
>>>>>>>
>>>>>>> But I already have a lens called 'author' and ghc will complain about
>>>>>>> shadowing. So, to avoid shadowing, should I use 'theAuthor' instead of
>>>>>>> 'author' for the function argument? Or, should I name the lens 'authorLens',
>>>>>>> 'authorL' or 'lAuthor' instead of 'author'? Prefixing with 'the' is quite
>>>>>>> unreadable because whether or not an argument has that prefix depends on
>>>>>>> whether there's a lens with a conflicting name so it adds noise to the code.
>>>>>>> Adding a 'Lens' prefix to the 'author' lens also seems quite an overbearing
>>>>>>> eyesore because for consistency I would have to use the prefix for all my
>>>>>>> field-accessing lenses.
>>>>>>>
>>>>>>> Maybe I should use Lens.Control.TH.makeClassy and then define:
>>>>>>>
>>>>>>> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
>>>>>>> findAuthorLibraries hasAuthor libraries = ...
>>>>>>>
>>>>>>> But that may be making my function more complicated and general than
>>>>>>> I want, affecting readability, simplicity, compilation time and maybe even
>>>>>>> performance.
>>>>>>>
>>>>>>> In summary, I find that there are ways around the problem but they
>>>>>>> really affect readability.
>>>>>>>
>>>>>>> I could also disable the warning about shadowing but that seems
>>>>>>> pretty dangerous. It may be OK to disable the warning for the specific cases
>>>>>>> where a function argument shadows something from the topmost scope, but GHC
>>>>>>> does not allow such selective disabling of that warning.
>>>>>>>
>>>>>>> In a code base that deals mainly with concrete business logic, this
>>>>>>> problem probably crops up more than in a code base that deals mainly with
>>>>>>> more abstract things.
>>>>>>>
>>>>>>> What do people do to address this problem? Any recommendations or
>>>>>>> best practices?
>>>>>>>
>>>>>>> Josh
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>
>>>> --
>>>> Sending this from my phone, please excuse any typos!
>>>
>>>
>> --
>> Sending this from my phone, please excuse any typos!
>
>
>
> _______________________________________________
> 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 parsonsmatt at gmail.com  Sat Dec 23 22:26:00 2017
From: parsonsmatt at gmail.com (Matt)
Date: Sat, 23 Dec 2017 15:26:00 -0700
Subject: [Haskell-cafe] Shadowing record field names
In-Reply-To: <CACbaDy4UMGUAy0oaYBYW69MhkM5tSB=wPsdmm0fSDpdUn4r7hA@mail.gmail.com>
References: <CALxtSbRgUJdhZcFAGxZEzh0MKNWvzOXmBZzn0_UQNJDGJ2euJw@mail.gmail.com>
 <7a31cf92-d596-5107-5cb9-db4fde790239@gmail.com>
 <CAJN5CVLfuT29cppAVjye1J0aC5eRzVk+UYgHm2p=TOdcY5bHsg@mail.gmail.com>
 <CAPipc=2MyBeXakyRuNQAoajQM20b0U+Xu72shkYkqT94hMVOCQ@mail.gmail.com>
 <CAJN5CVKs=QOt-mVXVP9U32GP_nu_F0KTNNvUFDy4jHJ1ZOE+5A@mail.gmail.com>
 <CAPipc=09p4dpNrOCdX81-CGFb4Ja8OOzbkcFEMSvaFz-vwxCSw@mail.gmail.com>
 <CAJN5CVLarQFtiYbWhxyeWM23VRPQisaV3kpzfoMzut8zxROqqQ@mail.gmail.com>
 <CACbaDy4UMGUAy0oaYBYW69MhkM5tSB=wPsdmm0fSDpdUn4r7hA@mail.gmail.com>
Message-ID: <CA+4qU95eBH2wMQ7U3yhDhjrPbxML1o4MbOKi_DRFVFt97wUk=A@mail.gmail.com>

Any function with type `State s ()` is essentially `s -> s`. So you'd
really have:

    modifyR :: R -> Maybe R
    modifyR = ...

Alternatively, you can push the requirement down into the `_int` field by
making the type `Even Int` for a newtype `Even` with relevant safe
operations. Then, your function looks like:

    modifyR :: (Even Int -> Maybe (Even Int)) -> R -> Maybe R

Which looks an awful lot like a `Traversal`:

    type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s ->
f t
    type Traversal' s a = Traversal s s a a
    modifyR :: Traversal (Even Int) R



Matt Parsons

On Sat, Dec 23, 2017 at 2:21 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> Here's another semi-derail: how can you do get/set with side-effects?
> This would necessarily be for a record in StateM or something.  For
> instance, say to preserve an invariant on a field:
>
>     import qualified Control.Monad.State as State
>
>     data R { _int :: Int }
>
>     modifyInt :: (R -> R) -> State.State R ()
>     modifyInt modify = do
>         int <- modify <$> State.gets _int
>         if even int then State.modify \r -> r { _int = int }
>             else Except.throwError "odd"
>
> I couldn't figure out how to get this sort of thing to cooperate with
> lenses.  I can make a lens with effects easily enough, but you have to
> invoke it via 'State.modify $ ...', at which point you're exposing
> State.modify which defeats the idea of trying to enforce invariants.
>
> On Sat, Dec 23, 2017 at 12:31 PM, Tikhon Jelvis <tikhon at jelv.is> wrote:
> > Yes, that is a good summary. Typeclass instances are inherently not
> modular.
> > There are some tradeoffs to this design—if you want to see an
> alternative,
> > take a look at how Scala deals with implicits.
> >
> > On Sat, Dec 23, 2017 at 12:21 PM, Siddharth Bhat <siddu.druid at gmail.com>
> > wrote:
> >>
> >> Ah, thank you! I was unaware of the  "OverloadedLabels" extension.
> >>
> >> So, orphan instances are an anti-pattern because their scope is hard to
> >> control? As in, when we import a module, we cannot "choose" to import
> >> typeclass definitions on types, right?
> >>
> >> Thanks,
> >> Siddharth
> >>
> >>
> >> On Sun 24 Dec, 2017, 01:46 Tikhon Jelvis, <tikhon at jelv.is> wrote:
> >>>
> >>> Please don't worry about derailing—if you had the question, I'm sure a
> >>> lot of other people reading did as well.
> >>>
> >>> An "orphan instance" is a typeclass instance defined in a module that
> >>> doesn't also define the class or the type. In my example, it's an
> instance
> >>> of the IsLabel class (from GHC.OverloadedLabels) for the function type
> (a ->
> >>> b). This is a problem because Haskell typeclass instances are not
> module—a
> >>> type can only have one instance of a given class *in the entire
> program*.
> >>> This means that if two libraries defined the instance I gave, *you
> would not
> >>> be able to use them together in the same project*. This is why you
> should
> >>> absolutely not define this instance in a library.
> >>>
> >>> An alternative design here would be to define a new type for lenses
> that
> >>> does not overlap with (a -> b). Something like ReifiedLens, defined
> >>> specifically to have this instance:
> >>>
> >>> newtype FieldLens s t a b = FieldLens (Lens s t a b)
> >>>
> >>> instance (...) => IsLabel (FieldLens s t a b) where
> >>>   ...
> >>>
> >>> Unfortunately, this would make FieldLens incompatible with normal
> lenses,
> >>> leading to a bit of boilerplate each time you had to call a field.
> >>>
> >>> The other alternative is to use RebindableSyntax which lets you
> >>> substitute your own IsLabel class in place of the one defined in
> >>> GHC.OverloadedLabels. This is probably the neatest solution, but
> >>> RebindableSyntax feels like a really heavyweight extension to use. That
> >>> said, my guess is that we'll use it in our internal code at work if
> there is
> >>> ever a conflict with the current IsLabel instance we're using. The
> current
> >>> experience with records is too nice to pass up without a fight :).
> >>>
> >>> The #bar syntax uses the OverloadedLabels extension. This adds the
> >>> IsLabel class and desugars #bar into fromLabel @"bar"
> >>>
> >>> The @ is type application, so the "bar" in fromLabel @"bar" is a
> >>> type-level symbol, not a normal string. This is how we get the name of
> the
> >>> field into the typeclass instance.
> >>>
> >>>
> >>>
> >>> On Sat, Dec 23, 2017 at 12:01 PM, Siddharth Bhat <
> siddu.druid at gmail.com>
> >>> wrote:
> >>>>
> >>>> At the risk of derailing the thread, what exactly does it mean to be
> an
> >>>> "orphan instance"? And where does "#bar" come from, I've never seen
> that
> >>>> syntax before :) I followed the exposition up to that point, if it
> helps.
> >>>>
> >>>> Thanks,
> >>>> Siddharth
> >>>>
> >>>>
> >>>> On Sun 24 Dec, 2017, 01:23 Tikhon Jelvis, <tikhon at jelv.is> wrote:
> >>>>>
> >>>>> This is a real pain point with records in Haskell.
> >>>>>
> >>>>> The fundamental problem is that unlike most languages with records or
> >>>>> object, field names are treated as normal identifiers in Haskell.
> Other
> >>>>> languages make fields special—you can only use them with the .
> operator or
> >>>>> in other select contexts. The advantage is that you can do things
> like
> >>>>> `a.author == author`; the disadvantage is that fields become a
> second-class
> >>>>> citizen.
> >>>>>
> >>>>> At work, we have a solution that's really nice to use built on top of
> >>>>> DuplicateRecordFields and OverloadedLabels. Our approach follows the
> ideas
> >>>>> in the OverloadedRecordFields proposal but with a lens flavor—very
> similar
> >>>>> to the overloaded-records[1] package. (We don't use that package
> directly
> >>>>> because I wrote our own version before I knew about it and I like the
> >>>>> ergonomics of our internal version a bit more.)
> >>>>>
> >>>>> We have a couple of typeclasses for reading and writing fields:
> >>>>>
> >>>>> class HasField (field :: Symbol) s a | s -> a where
> >>>>>   getField :: s -> a
> >>>>>
> >>>>> class UpdatesField (field :: Symbol) s t b | name t -> b, name s b
> -> t
> >>>>> where
> >>>>>   updateField :: s -> b -> t
> >>>>>
> >>>>> A record field can be both read and updated:
> >>>>>
> >>>>> type Field field s t a b = (HasField field s a, UpdatesField field
> name
> >>>>> s t b)
> >>>>>
> >>>>> field :: forall (name :: Symbol) s t a b. Field name s t a b => Lens
> s
> >>>>> t a b
> >>>>> field = lens (getField @name) (updateField @name)
> >>>>>
> >>>>> Then we have some Template Haskell for generating instances of these
> >>>>> classes. Here's a contrived example:
> >>>>>
> >>>>> data Foo a = Foo { bar :: [a] }
> >>>>>
> >>>>> record ''Foo
> >>>>>
> >>>>> which generates:
> >>>>>
> >>>>> instance HasField "bar" (Foo a) a where
> >>>>>   getField = bar
> >>>>>
> >>>>> instance UpdatesField "bar" (Foo a) (Foo b) b where
> >>>>>   updateField foo bar' = foo { bar = bar' }
> >>>>>
> >>>>> Given these, we can already write code looking up fields as lenses:
> >>>>>
> >>>>> > Foo [1,2,3] ^. field @"bar"
> >>>>> [1,2,3]
> >>>>>
> >>>>> Now fields aren't normal identifiers any more, the names can be
> shared
> >>>>> over different records (with DuplicateRecordFields) and you can write
> >>>>> functions polymorphic over any record with a given field.
> >>>>>
> >>>>> The names and details here are a bit different, but I believe this is
> >>>>> otherwise exactly what overloaded-records gives you. You could also
> replace
> >>>>> the TH to generate instances with generics in the style of the
> generic-lens
> >>>>> library.
> >>>>>
> >>>>> However, the field @"bar" is painfully verbose. We solve this using
> >>>>> OverloadedLabels and a somewhat shady orphan instance for IsLabel:
> >>>>>
> >>>>> instance (Functor f, Field name s t a b, a' ~ (a -> f b), b' ~ (s ->
> f
> >>>>> t)) => IsLabel name (a' -> b') where
> >>>>>   fromLabel = field @name
> >>>>>
> >>>>> The details are a bit fiddly, but this is what we need to make type
> >>>>> inference work correctly. This lets us replace field @"name" with
> #name:
> >>>>>
> >>>>> > Foo [1,2,3] ^. #bar
> >>>>> [1,2,3]
> >>>>> > Foo [1,2,3] & #bar . each %~ show
> >>>>> Foo { bar = ["1","2","3"] }
> >>>>>
> >>>>> The downside is that this is an orphan instance for IsLabel for *all
> >>>>> functions*. You would not want to use this in a library but it's
> fine in an
> >>>>> executable as long as you don't mind potentially needing to reword
> things if
> >>>>> a similar IsLabel instance is added to base. (A risk I'm willing to
> take for
> >>>>> better syntax :))
> >>>>>
> >>>>> Apart from that (somewhat serious) downside, the final result is
> pretty
> >>>>> much perfect: fields are first-class citizens (as lenses) and are
> not in the
> >>>>> same scope as identifiers. We've been using this extensively
> throughout our
> >>>>> whole project and it's been perfect—perhaps surprisingly, we haven't
> run
> >>>>> into any issues with type inference or type error messages (beyond
> what you
> >>>>> normally get with lens).
> >>>>>
> >>>>> With this addition, Haskell records went from being a real blemish on
> >>>>> the language to being the best I've ever used. The orphan instance
> is a
> >>>>> definite red flag and you should absolutely *not* have that instance
> in a
> >>>>> library, but if you're working on a standalone executable or some
> extensive
> >>>>> internal code, I think it's absolutely worth it.
> >>>>>
> >>>>> [1]: https://hackage.haskell.org/package/overloaded-records
> >>>>>
> >>>>> [2]: https://hackage.haskell.org/package/generic-lens
> >>>>>
> >>>>>
> >>>>> On Sat, Dec 23, 2017 at 6:41 AM, Li-yao Xia <lysxia at gmail.com>
> wrote:
> >>>>>>
> >>>>>> I don't think "authorL" hurts readability. It just seems the logical
> >>>>>> choice if "author" is already taken.
> >>>>>>
> >>>>>> Have you seen generic-lens? The lens for the "author" field is
> (field
> >>>>>> @"author") so there is some added noise compared to "authorL", but
> it can be
> >>>>>> used as a TH-free alternative to makeClassy.
> >>>>>>
> >>>>>> type Field name a = forall s. HasField name s s a a => Lens s s a a
> >>>>>>
> >>>>>> authorL :: Field "author" Author
> >>>>>> authorL = field @"author"
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Li-yao
> >>>>>>
> >>>>>>
> >>>>>> On 12/23/2017 08:36 AM, ☂Josh Chia (謝任中) wrote:
> >>>>>>>
> >>>>>>> Quite often, I need to use record types like this:
> >>>>>>>
> >>>>>>> data Whole1 = Whole1 { part :: Part, ... }
> >>>>>>> data Whole2 = Whole2 { part :: Part, ... }
> >>>>>>>
> >>>>>>> Where Whole1 & Whole2 are types of things that have a Part and some
> >>>>>>> other things. E.g. a Book has an Author, a Title, etc and so does
> an
> >>>>>>> Article.
> >>>>>>>
> >>>>>>> The problem is that I'm not actually allowed to use the same name
> >>>>>>> (author/part) in two different record types. Some people use lens
> to solve
> >>>>>>> this. You can have a lens called 'author' for dealing with the
> Author in
> >>>>>>> both Book and Article (e.g. using makeClassy).
> >>>>>>>
> >>>>>>> That's fine, but there's yet another problem. Let's say I have a
> >>>>>>> function that takes an Author and a [Library] and returns all the
> Libraries
> >>>>>>> that have Books or Articles matching the Author. So:
> >>>>>>>
> >>>>>>> findAuthorLibraries :: Author -> [Library] -> [Library]
> >>>>>>> findAuthorLibraries author libraries = ...
> >>>>>>>
> >>>>>>> But I already have a lens called 'author' and ghc will complain
> about
> >>>>>>> shadowing. So, to avoid shadowing, should I use 'theAuthor'
> instead of
> >>>>>>> 'author' for the function argument? Or, should I name the lens
> 'authorLens',
> >>>>>>> 'authorL' or 'lAuthor' instead of 'author'? Prefixing with 'the'
> is quite
> >>>>>>> unreadable because whether or not an argument has that prefix
> depends on
> >>>>>>> whether there's a lens with a conflicting name so it adds noise to
> the code.
> >>>>>>> Adding a 'Lens' prefix to the 'author' lens also seems quite an
> overbearing
> >>>>>>> eyesore because for consistency I would have to use the prefix for
> all my
> >>>>>>> field-accessing lenses.
> >>>>>>>
> >>>>>>> Maybe I should use Lens.Control.TH.makeClassy and then define:
> >>>>>>>
> >>>>>>> findAuthorLibraries :: HasAuthor a => a -> [Library] -> [Library]
> >>>>>>> findAuthorLibraries hasAuthor libraries = ...
> >>>>>>>
> >>>>>>> But that may be making my function more complicated and general
> than
> >>>>>>> I want, affecting readability, simplicity, compilation time and
> maybe even
> >>>>>>> performance.
> >>>>>>>
> >>>>>>> In summary, I find that there are ways around the problem but they
> >>>>>>> really affect readability.
> >>>>>>>
> >>>>>>> I could also disable the warning about shadowing but that seems
> >>>>>>> pretty dangerous. It may be OK to disable the warning for the
> specific cases
> >>>>>>> where a function argument shadows something from the topmost
> scope, but GHC
> >>>>>>> does not allow such selective disabling of that warning.
> >>>>>>>
> >>>>>>> In a code base that deals mainly with concrete business logic, this
> >>>>>>> problem probably crops up more than in a code base that deals
> mainly with
> >>>>>>> more abstract things.
> >>>>>>>
> >>>>>>> What do people do to address this problem? Any recommendations or
> >>>>>>> best practices?
> >>>>>>>
> >>>>>>> Josh
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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.
> >>>>
> >>>> --
> >>>> Sending this from my phone, please excuse any typos!
> >>>
> >>>
> >> --
> >> Sending this from my phone, please excuse any typos!
> >
> >
> >
> > _______________________________________________
> > 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/20171223/6db74262/attachment-0001.html>

From eric at metricspace.net  Sun Dec 24 16:04:32 2017
From: eric at metricspace.net (Eric McCorkle)
Date: Sun, 24 Dec 2017 11:04:32 -0500
Subject: [Haskell-cafe] Trouble building happy/alex with Stack lts-9.20
Message-ID: <489c302f-72e6-a97f-e31b-214ab229fade@metricspace.net>

Hi folks,

I'm trying to update my language project to happy >= 9.16, so I can use
typeclass-based parsers.  Unfortunately, I'm running into build errors
after switching to lts-9.20.  The log file is attached.

I see similar problems when trying to build alex (the lexer generator).

It seems to be claiming that there is no cabal file, which is odd, as
there clearly is one (in the source at least).

Has anyone else seen this problem, and if so, what is the workaround?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: happy-1.19.8.log
Type: text/x-log
Size: 5776 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171224/7d660e89/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171224/7d660e89/attachment.sig>

From tikhon at jelv.is  Sun Dec 24 23:03:38 2017
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Sun, 24 Dec 2017 15:03:38 -0800
Subject: [Haskell-cafe] Supporting Haskell.org
Message-ID: <CAJN5CVK3rUzPPYQLV_wcRyaw9WN+q7DYxazAgoguRaiA8p4_ZA@mail.gmail.com>

A significant part of the Haskell community infrastructure—including the
haskell.org website, Hackage, Hoogle and the build infrastructure for
GHC—runs on donations from the Haskell community administered by haskell.org
.

You can donate right now using several methods including PayPal and check:

https://wiki.haskell.org/Donate_to_Haskell.org

Haskell.org can also accept donations through employers via Benevity using
the unique ID 475236502.

As Haskell.org is a 501(c)(3) non-profit, donations are tax-deductible.

This year marked the second Haskell Summer of Code program which provided
grants for 15 students working on open source Haskell projects over the
summer. The projects improved Haskell tooling and libraries as well as
supporting Haskell education through improvements to code.world. A detailed
retrospective can be found on summer.haskell.org:

https://summer.haskell.org/news/2017-09-15-final-results.html

With look forward to continuing this work with your support in 2018 as well
as exploring new projects to improve the Haskell community infrastructure.

Best wishes, Tikhon Jelvis on behalf of the haskell.org committee.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171224/8562c67e/attachment.html>

From esz at posteo.de  Mon Dec 25 01:15:11 2017
From: esz at posteo.de (Ertugrul =?utf-8?Q?S=C3=B6ylemez?=)
Date: Mon, 25 Dec 2017 02:15:11 +0100
Subject: [Haskell-cafe] ANN: progress-meter 1.0.0
Message-ID: <877etb8v6o.fsf@posteo.de>

Hi everybody,

I have just released a complete API rewrite of the `progress-meter`
package:

  * <https://hackage.haskell.org/package/progress-meter>
  * <https://github.com/esoeylemez/progress-meter>

With this package you can easily add live diagnostics to any
long-running application from a simple progress bar to full task
monitoring.  The `System.Progress` module contains a tutorial.
Features:

  * update progress from multiple threads,

  * non-progress diagnostics that just scroll by (e.g. logging),

  * breaking the state apart for individual threads, so they can update
    their relevant portion of the progress bar without interfering with
    each other ("zooming"),

  * smart throttling (no updates drawn when nothing is happening, and
    only ever drawn at a maximum rate).

Here is a very simple example:

    import Control.Concurrent
    import System.Progress

    main = withProgress_ "" id $ \pm -> do
        -- Set the progress bar:
        setMeter pm "Working..."

        -- Do some "work":
        threadDelay 3000000

        -- Print something while temporarily hiding the progress bar:
        putMsgLn pm "Some extra diagnostics that scrolls by"

        setMeter pm "Almost done..."
        threadDelay 1000000
        putMsgLn pm "Done."

The first argument of 'withProgress_' is the initial state and the
second is a renderer for the current state:

    render :: Int -> String
    render p = "Progress: " ++ show p ++ "%"

    withProgress_ 0 render $ \pm -> do
        threadDelay 1000000
        setMeter pm 10
        threadDelay 8900000
        setMeter pm 99
        -- The famous last percent:
        threadDelay 10000000
        putMsgLn pm "Done."

Progress-meter will do The Right Thing when you update the state or
produce log messages from multiple threads.


Happy holidays
ertes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171225/a8278719/attachment.sig>

From tanuki at gmail.com  Mon Dec 25 02:22:30 2017
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Sun, 24 Dec 2017 18:22:30 -0800
Subject: [Haskell-cafe] Supporting Haskell.org
In-Reply-To: <CAJN5CVK3rUzPPYQLV_wcRyaw9WN+q7DYxazAgoguRaiA8p4_ZA@mail.gmail.com>
References: <CAJN5CVK3rUzPPYQLV_wcRyaw9WN+q7DYxazAgoguRaiA8p4_ZA@mail.gmail.com>
Message-ID: <CAJoPsuD7z7Mgg5mRYFrZkJEaMpNVz-LmGaypUyfVqPojiZ7eSw@mail.gmail.com>

haskell.org is also one of the charities you can donate to via
smile.amazon.com!

On Sun, Dec 24, 2017 at 3:03 PM, Tikhon Jelvis <tikhon at jelv.is> wrote:

> A significant part of the Haskell community infrastructure—including the
> haskell.org website, Hackage, Hoogle and the build infrastructure for
> GHC—runs on donations from the Haskell community administered by
> haskell.org.
>
> You can donate right now using several methods including PayPal and check:
>
> https://wiki.haskell.org/Donate_to_Haskell.org
>
> Haskell.org can also accept donations through employers via Benevity using
> the unique ID 475236502.
>
> As Haskell.org is a 501(c)(3) non-profit, donations are tax-deductible.
>
> This year marked the second Haskell Summer of Code program which provided
> grants for 15 students working on open source Haskell projects over the
> summer. The projects improved Haskell tooling and libraries as well as
> supporting Haskell education through improvements to code.world. A detailed
> retrospective can be found on summer.haskell.org:
>
> https://summer.haskell.org/news/2017-09-15-final-results.html
>
> With look forward to continuing this work with your support in 2018 as
> well as exploring new projects to improve the Haskell community
> infrastructure.
>
> Best wishes, Tikhon Jelvis on behalf of the haskell.org committee.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171224/0d934c6d/attachment.html>

From danburton.email at gmail.com  Mon Dec 25 05:29:13 2017
From: danburton.email at gmail.com (Dan Burton)
Date: Sun, 24 Dec 2017 21:29:13 -0800
Subject: [Haskell-cafe] Trouble building happy/alex with Stack lts-9.20
In-Reply-To: <489c302f-72e6-a97f-e31b-214ab229fade@metricspace.net>
References: <489c302f-72e6-a97f-e31b-214ab229fade@metricspace.net>
Message-ID: <CALSygwfbmNAoZE0kC7Fp=vDD4hTrWapj3kV6oKcU-Db0yTAcvw@mail.gmail.com>

/cc the haskell-stack mailing list.

On Dec 24, 2017 9:08 AM, "Eric McCorkle" <eric at metricspace.net> wrote:

> Hi folks,
>
> I'm trying to update my language project to happy >= 9.16, so I can use
> typeclass-based parsers.  Unfortunately, I'm running into build errors
> after switching to lts-9.20.  The log file is attached.
>
> I see similar problems when trying to build alex (the lexer generator).
>
> It seems to be claiming that there is no cabal file, which is odd, as
> there clearly is one (in the source at least).
>
> Has anyone else seen this problem, and if so, what is the workaround?
>
> _______________________________________________
> 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/20171224/551893f5/attachment.html>

From michael at snoyman.com  Mon Dec 25 12:53:04 2017
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 25 Dec 2017 14:53:04 +0200
Subject: [Haskell-cafe] Trouble building happy/alex with Stack lts-9.20
In-Reply-To: <CALSygwfbmNAoZE0kC7Fp=vDD4hTrWapj3kV6oKcU-Db0yTAcvw@mail.gmail.com>
References: <489c302f-72e6-a97f-e31b-214ab229fade@metricspace.net>
 <CALSygwfbmNAoZE0kC7Fp=vDD4hTrWapj3kV6oKcU-Db0yTAcvw@mail.gmail.com>
Message-ID: <CAKT9ecM=oKf5tJ+-52YMd7=xeAa13Tt2aQt12V5pPdci5vxSEA@mail.gmail.com>

What command are you running to generate this output? Are you able to
`stack unpack happy && cd happy-* && stack init && stack build`
successfully?

On Mon, Dec 25, 2017 at 7:29 AM, Dan Burton <danburton.email at gmail.com>
wrote:

> /cc the haskell-stack mailing list.
>
> On Dec 24, 2017 9:08 AM, "Eric McCorkle" <eric at metricspace.net> wrote:
>
>> Hi folks,
>>
>> I'm trying to update my language project to happy >= 9.16, so I can use
>> typeclass-based parsers.  Unfortunately, I'm running into build errors
>> after switching to lts-9.20.  The log file is attached.
>>
>> I see similar problems when trying to build alex (the lexer generator).
>>
>> It seems to be claiming that there is no cabal file, which is odd, as
>> there clearly is one (in the source at least).
>>
>> Has anyone else seen this problem, and if so, what is the workaround?
>>
>> _______________________________________________
>> 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/20171225/51c50c87/attachment.html>

From eric at metricspace.net  Mon Dec 25 13:40:31 2017
From: eric at metricspace.net (Eric McCorkle)
Date: Mon, 25 Dec 2017 08:40:31 -0500
Subject: [Haskell-cafe] Trouble building happy/alex with Stack lts-9.20
In-Reply-To: <CAKT9ecM=oKf5tJ+-52YMd7=xeAa13Tt2aQt12V5pPdci5vxSEA@mail.gmail.com>
References: <489c302f-72e6-a97f-e31b-214ab229fade@metricspace.net>
 <CALSygwfbmNAoZE0kC7Fp=vDD4hTrWapj3kV6oKcU-Db0yTAcvw@mail.gmail.com>
 <CAKT9ecM=oKf5tJ+-52YMd7=xeAa13Tt2aQt12V5pPdci5vxSEA@mail.gmail.com>
Message-ID: <07e2752c-388e-f29a-b1ad-3c86b237f00a@metricspace.net>

Can unpack, and happy.cabal is definitely there.  Unfortunately, stack
init or stack build seems to fail with an aeson exception:

AesonException "Error in
$.packages.cassava.constraints.flags['bytestring--lt-0_10_4']: Invalid
flag name: \"bytestring--lt-0_10_4\""


On 12/25/2017 07:53, Michael Snoyman wrote:
> What command are you running to generate this output? Are you able to
> `stack unpack happy && cd happy-* && stack init && stack build`
> successfully?
> 
> On Mon, Dec 25, 2017 at 7:29 AM, Dan Burton <danburton.email at gmail.com
> <mailto:danburton.email at gmail.com>> wrote:
> 
>     /cc the haskell-stack mailing list.
> 
>     On Dec 24, 2017 9:08 AM, "Eric McCorkle" <eric at metricspace.net
>     <mailto:eric at metricspace.net>> wrote:
> 
>         Hi folks,
> 
>         I'm trying to update my language project to happy >= 9.16, so I
>         can use
>         typeclass-based parsers.  Unfortunately, I'm running into build
>         errors
>         after switching to lts-9.20.  The log file is attached.
> 
>         I see similar problems when trying to build alex (the lexer
>         generator).
> 
>         It seems to be claiming that there is no cabal file, which is
>         odd, as
>         there clearly is one (in the source at least).
> 
>         Has anyone else seen this problem, and if so, what is the
>         workaround?
> 
>         _______________________________________________
>         Haskell-Cafe mailing list
>         To (un)subscribe, modify options or view archives go to:
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>         Only members subscribed via the mailman list are allowed to post.
> 
> 
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     <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: 256 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171225/bab39cb6/attachment.sig>

From michael at snoyman.com  Mon Dec 25 13:46:25 2017
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 25 Dec 2017 15:46:25 +0200
Subject: [Haskell-cafe] Trouble building happy/alex with Stack lts-9.20
In-Reply-To: <07e2752c-388e-f29a-b1ad-3c86b237f00a@metricspace.net>
References: <489c302f-72e6-a97f-e31b-214ab229fade@metricspace.net>
 <CALSygwfbmNAoZE0kC7Fp=vDD4hTrWapj3kV6oKcU-Db0yTAcvw@mail.gmail.com>
 <CAKT9ecM=oKf5tJ+-52YMd7=xeAa13Tt2aQt12V5pPdci5vxSEA@mail.gmail.com>
 <07e2752c-388e-f29a-b1ad-3c86b237f00a@metricspace.net>
Message-ID: <CAKT9ecP05S_8ZpBu6CMCtDKrWTgW+LV-ZhiLr5_C8Vs7Vg6nmw@mail.gmail.com>

You'll need to run `stack upgrade` first.

On Mon, Dec 25, 2017 at 3:40 PM, Eric McCorkle <eric at metricspace.net> wrote:

> Can unpack, and happy.cabal is definitely there.  Unfortunately, stack
> init or stack build seems to fail with an aeson exception:
>
> AesonException "Error in
> $.packages.cassava.constraints.flags['bytestring--lt-0_10_4']: Invalid
> flag name: \"bytestring--lt-0_10_4\""
>
>
> On 12/25/2017 07:53, Michael Snoyman wrote:
> > What command are you running to generate this output? Are you able to
> > `stack unpack happy && cd happy-* && stack init && stack build`
> > successfully?
> >
> > On Mon, Dec 25, 2017 at 7:29 AM, Dan Burton <danburton.email at gmail.com
> > <mailto:danburton.email at gmail.com>> wrote:
> >
> >     /cc the haskell-stack mailing list.
> >
> >     On Dec 24, 2017 9:08 AM, "Eric McCorkle" <eric at metricspace.net
> >     <mailto:eric at metricspace.net>> wrote:
> >
> >         Hi folks,
> >
> >         I'm trying to update my language project to happy >= 9.16, so I
> >         can use
> >         typeclass-based parsers.  Unfortunately, I'm running into build
> >         errors
> >         after switching to lts-9.20.  The log file is attached.
> >
> >         I see similar problems when trying to build alex (the lexer
> >         generator).
> >
> >         It seems to be claiming that there is no cabal file, which is
> >         odd, as
> >         there clearly is one (in the source at least).
> >
> >         Has anyone else seen this problem, and if so, what is the
> >         workaround?
> >
> >         _______________________________________________
> >         Haskell-Cafe mailing list
> >         To (un)subscribe, modify options or view archives go to:
> >         http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >         <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> >         Only members subscribed via the mailman list are allowed to post.
> >
> >
> >     _______________________________________________
> >     Haskell-Cafe mailing list
> >     To (un)subscribe, modify options or view archives go to:
> >     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >     <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/20171225/9cbebd0f/attachment.html>

From m at jaspervdj.be  Mon Dec 25 13:59:38 2017
From: m at jaspervdj.be (Jasper Van der Jeugt)
Date: Mon, 25 Dec 2017 14:59:38 +0100
Subject: [Haskell-cafe] [Call for Project Ideas] Haskell.org Google Summer
	of Code 2018
Message-ID: <20171225135938.GA2165@colony6.localdomain>

Google Summer of Code will take place again in 2018 [1].  Last year,
Haskell.org was not selected, and we decided to run our own program [2],
which ended very successfully [3].

This year, we would like to apply to Google Summer of Code again, since
their sponsorship is very significant.  The main feedback we received
from Google last year was that we didn't really have a great homepage
for Summer of Code with ideas for students (things were very rushed and
we ended up submitting a link to an outdated bug tracker -- not ideal!).

We already started fixing that last year by building a nicer webpage to
host ideas [4].  We would now like to call on the community to submit
ideas for the students.

If you are the maintainer or the user of a Haskell project, and you have
an improvement in mind which a student could work on during the summer,
please submit an idea here:

    https://summer.haskell.org/ideas.html

Or contact Niki Vazou (nvazou [AT] cs.umd.edu) or myself (m [AT]
jaspervdj.be) directly.

For context, Google Summer of Code is a program where Google sponsors
students to work on open-source projects during the summer.  Haskell.org
has taken part in this program from 2006 until 2015.  Many important
improvements to the ecosystem have been the direct or indirect result of
Google Summer of Code projects, and it has also connected new people
with the existing community.

Projects should benefit as many people as possible -- e.g. an
improvement to GHC will benefit more people than an update to a specific
library or tool, but both are definitely valid.  New libraries and
applications written in Haskell, rather than improvements to existing
ones, are also accepted.  Projects should be concrete and small enough
in scope such that they can be finished by a student in three months.

Best, Niki Vazou & Jasper Van der Jeugt for the Haskell.org Committee

[1]: https://opensource.googleblog.com/2017/09/announcing-google-summer-of-code-2018.html
[2]: https://summer.haskell.org/news/2017-02-28-2017-announce.html
[3]: https://summer.haskell.org/news/2017-09-15-final-results.html
[4]: https://summer.haskell.org/ideas.html

From jm at alliot.org  Fri Dec 29 14:36:54 2017
From: jm at alliot.org (Jean-Marc Alliot)
Date: Fri, 29 Dec 2017 15:36:54 +0100
Subject: [Haskell-cafe] Question about ST arrays
Message-ID: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>

Hi,

This is my first post to this list so I apologize in advance if I don't 
use it properly, or if my question is too simple or inapropriate.

I come from the Caml world and I am quite new to Haskell (but not to 
functional programming). I am currently trying to get the hang of 
Haskell arrays. I have gone through regular arrays, IO Arrays and I am 
now working with ST Arrays.

This is the problem I am currently stuck with. I write the following code:

arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
get :: Int -> Int
get i = runST (arr >>= (\b -> readArray b i))

Here everything is perfectly OK.

Now I want a more general version that could deal with any array like 
arr. So I write:

get2 :: ST s (STArray s Int Int) -> Int -> Int
get2 tab i = runST (tab >>= (\b -> readArray b i))

And the compiler is clearly very upset by my code:

Couldn't match type ‘s’ with ‘s1’
       ‘s’ is a rigid type variable bound by
         the type signature for:
           get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
         at testst.hs:17:9
       ‘s1’ is a rigid type variable bound by
         a type expected by the context:
           forall s1. ST s1 Int
         at testst.hs:18:14
       Expected type: ST s1 Int
         Actual type: ST s Int
I am pretty sure that the compiler is right and I am wrong, but I don't 
get why... Anyone could help?

Thanks



From aquagnu at gmail.com  Fri Dec 29 15:11:17 2017
From: aquagnu at gmail.com (Baa)
Date: Fri, 29 Dec 2017 17:11:17 +0200
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
Message-ID: <20171229171117.0567b7d2@Pavel>

Hello!

I found this -
https://mail.haskell.org/pipermail/haskell-cafe/2011-May/091622.html

I'm not sure is it helpful.

PS. As I understand, `get2` signature has own `forall s`, but `runST`
is `(forall s. ST s a) -> a` which "escapes" top `s`.

Somebody else? :)

===
Best regards, Paul

> Hi,
> 
> This is my first post to this list so I apologize in advance if I
> don't use it properly, or if my question is too simple or
> inapropriate.
> 
> I come from the Caml world and I am quite new to Haskell (but not to 
> functional programming). I am currently trying to get the hang of 
> Haskell arrays. I have gone through regular arrays, IO Arrays and I
> am now working with ST Arrays.
> 
> This is the problem I am currently stuck with. I write the following
> code:
> 
> arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
> get :: Int -> Int
> get i = runST (arr >>= (\b -> readArray b i))
> 
> Here everything is perfectly OK.
> 
> Now I want a more general version that could deal with any array like 
> arr. So I write:
> 
> get2 :: ST s (STArray s Int Int) -> Int -> Int
> get2 tab i = runST (tab >>= (\b -> readArray b i))
> 
> And the compiler is clearly very upset by my code:
> 
> Couldn't match type ‘s’ with ‘s1’
>        ‘s’ is a rigid type variable bound by
>          the type signature for:
>            get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
>          at testst.hs:17:9
>        ‘s1’ is a rigid type variable bound by
>          a type expected by the context:
>            forall s1. ST s1 Int
>          at testst.hs:18:14
>        Expected type: ST s1 Int
>          Actual type: ST s Int
> I am pretty sure that the compiler is right and I am wrong, but I
> don't get why... Anyone could help?
> 
> Thanks
> 
> 
> _______________________________________________
> 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 aquagnu at gmail.com  Fri Dec 29 15:23:15 2017
From: aquagnu at gmail.com (Baa)
Date: Fri, 29 Dec 2017 17:23:15 +0200
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
Message-ID: <20171229172315.6a391637@Pavel>

Also there is https://en.wikibooks.org/wiki/Haskell/Mutable_objects
May be it will help.

/Regards

> Hi,
> 
> This is my first post to this list so I apologize in advance if I
> don't use it properly, or if my question is too simple or
> inapropriate.
> 
> I come from the Caml world and I am quite new to Haskell (but not to 
> functional programming). I am currently trying to get the hang of 
> Haskell arrays. I have gone through regular arrays, IO Arrays and I
> am now working with ST Arrays.
> 
> This is the problem I am currently stuck with. I write the following
> code:
> 
> arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
> get :: Int -> Int
> get i = runST (arr >>= (\b -> readArray b i))
> 
> Here everything is perfectly OK.
> 
> Now I want a more general version that could deal with any array like 
> arr. So I write:
> 
> get2 :: ST s (STArray s Int Int) -> Int -> Int
> get2 tab i = runST (tab >>= (\b -> readArray b i))
> 
> And the compiler is clearly very upset by my code:
> 
> Couldn't match type ‘s’ with ‘s1’
>        ‘s’ is a rigid type variable bound by
>          the type signature for:
>            get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
>          at testst.hs:17:9
>        ‘s1’ is a rigid type variable bound by
>          a type expected by the context:
>            forall s1. ST s1 Int
>          at testst.hs:18:14
>        Expected type: ST s1 Int
>          Actual type: ST s Int
> I am pretty sure that the compiler is right and I am wrong, but I
> don't get why... Anyone could help?
> 
> Thanks
> 
> 
> _______________________________________________
> 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 jm at alliot.org  Fri Dec 29 15:31:52 2017
From: jm at alliot.org (Jean-Marc Alliot)
Date: Fri, 29 Dec 2017 16:31:52 +0100
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <20171229171117.0567b7d2@Pavel>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
 <20171229171117.0567b7d2@Pavel>
Message-ID: <0e15c2c9-f189-25a8-bbd9-a1e3a8b7c4f9@alliot.org>

Yes, thanks, it's exactly the same question, and the same trick works, 
using:
{-# LANGUAGE RankNTypes #-}
and
get2 :: (forall s.ST s (STArray s Int Int)) -> Int -> Int

In fact, Rank-2 types are enough here, we don't need Rank-N types.
I suppose the ST Array module uses the Rank-N extension, so using them 
requires also enabling Rank-N.

Thanks again.

Le 29/12/2017 à 16:11, Baa a écrit :
> Hello!
>
> I found this -
> https://mail.haskell.org/pipermail/haskell-cafe/2011-May/091622.html
>
> I'm not sure is it helpful.
>
> PS. As I understand, `get2` signature has own `forall s`, but `runST`
> is `(forall s. ST s a) -> a` which "escapes" top `s`.
>
> Somebody else? :)
>
> ===
> Best regards, Paul
>
>> Hi,
>>
>> This is my first post to this list so I apologize in advance if I
>> don't use it properly, or if my question is too simple or
>> inapropriate.
>>
>> I come from the Caml world and I am quite new to Haskell (but not to
>> functional programming). I am currently trying to get the hang of
>> Haskell arrays. I have gone through regular arrays, IO Arrays and I
>> am now working with ST Arrays.
>>
>> This is the problem I am currently stuck with. I write the following
>> code:
>>
>> arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
>> get :: Int -> Int
>> get i = runST (arr >>= (\b -> readArray b i))
>>
>> Here everything is perfectly OK.
>>
>> Now I want a more general version that could deal with any array like
>> arr. So I write:
>>
>> get2 :: ST s (STArray s Int Int) -> Int -> Int
>> get2 tab i = runST (tab >>= (\b -> readArray b i))
>>
>> And the compiler is clearly very upset by my code:
>>
>> Couldn't match type ‘s’ with ‘s1’
>>         ‘s’ is a rigid type variable bound by
>>           the type signature for:
>>             get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
>>           at testst.hs:17:9
>>         ‘s1’ is a rigid type variable bound by
>>           a type expected by the context:
>>             forall s1. ST s1 Int
>>           at testst.hs:18:14
>>         Expected type: ST s1 Int
>>           Actual type: ST s Int
>> I am pretty sure that the compiler is right and I am wrong, but I
>> don't get why... Anyone could help?
>>
>> Thanks
>>
>>
>> _______________________________________________
>> 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 ramin.honary at gmail.com  Fri Dec 29 15:36:27 2017
From: ramin.honary at gmail.com (Ramin Honary)
Date: Sat, 30 Dec 2017 00:36:27 +0900
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
Message-ID: <CAFhnQTQwu8TdUEEQM1n7R0SU2VtNE=0QUcM2xiqbiHgJ-sAMtw@mail.gmail.com>

You should use "runSTArray" or "runSTUArray" instead of "runST" to convert
your STArray to an immutable array:  https://hackage.haskell.
org/package/array-0.5.2.0/docs/Data-Array-ST.html#v:runSTUArray

Or another option is to use "stToIO"  to convert the "STArray" to an
"IOArray."
https://hackage.haskell.org/package/base-4.10.1.0/docs/Control-Monad-ST-Lazy.html#v:stToIO
but if you want to build an IOArray, it is better to just start with an
IOArray rather than converting an STArray to an IOArray.

The design of ST arrays is to allow you to construct them quickly and then
make them immutable once you are done constructing it.

An immutable array must have the whole array copied after every single
update, but ST arrays allow you to make many updates without copying, then
when you have completed constructing the ST array, you must freeze it to an
immutable array using the "runSTUArray" function. Freezing happens without
copying the array, after that it is immutable and may not be made into an
STArray again unless you unfreeze it using "thaw", which creates a copy of
it:
https://hackage.haskell.org/package/array-0.5.2.0/docs/Data-Array-MArray.html#v:thaw

Once you have constructed your immutable array, you can access it
arbitrarily using the immutable operator (!).

If you want to make multiple updates at multiple times, you must use an
IOArray or IOUArray. The ST monad is designed for you to construct pure,
referentially transparent, immutable values in an isolated and strictly
evaluated "environment" that lets you perform strict updates during
construction. Once evaluation of the "ST" monad is complete, the returned
value becomes pure, immutable, and referentially transparent. The for-all'd
"s" parameter of the "runST" function ensures you do not mix separate
"environments," and this is the reason you got your type error. Using
"runSTArray" or "runSTUArray" does not have this restriction.

I am not sure of the reason for this design decision, but I know it has
something to do with the compiler guaranteeing that pure immutable
referentially transparent types are constructed without effecting each
other, preventing race conditions. There is discussion of this on the
Haskell wiki:
https://wiki.haskell.org/Monad/ST#An_explanation_in_Haskell-Cafe


On Fri, Dec 29, 2017 at 11:36 PM, Jean-Marc Alliot <jm at alliot.org> wrote:

> Hi,
>
> This is my first post to this list so I apologize in advance if I don't
> use it properly, or if my question is too simple or inapropriate.
>
> I come from the Caml world and I am quite new to Haskell (but not to
> functional programming). I am currently trying to get the hang of Haskell
> arrays. I have gone through regular arrays, IO Arrays and I am now working
> with ST Arrays.
>
> This is the problem I am currently stuck with. I write the following code:
>
> arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
> get :: Int -> Int
> get i = runST (arr >>= (\b -> readArray b i))
>
> Here everything is perfectly OK.
>
> Now I want a more general version that could deal with any array like arr.
> So I write:
>
> get2 :: ST s (STArray s Int Int) -> Int -> Int
> get2 tab i = runST (tab >>= (\b -> readArray b i))
>
> And the compiler is clearly very upset by my code:
>
> Couldn't match type ‘s’ with ‘s1’
>       ‘s’ is a rigid type variable bound by
>         the type signature for:
>           get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
>         at testst.hs:17:9
>       ‘s1’ is a rigid type variable bound by
>         a type expected by the context:
>           forall s1. ST s1 Int
>         at testst.hs:18:14
>       Expected type: ST s1 Int
>         Actual type: ST s Int
> I am pretty sure that the compiler is right and I am wrong, but I don't
> get why... Anyone could help?
>
> Thanks
>
>
> _______________________________________________
> 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/20171230/d823542e/attachment.html>

From jm at alliot.org  Fri Dec 29 16:05:44 2017
From: jm at alliot.org (Jean-Marc Alliot)
Date: Fri, 29 Dec 2017 17:05:44 +0100
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <CAFhnQTQwu8TdUEEQM1n7R0SU2VtNE=0QUcM2xiqbiHgJ-sAMtw@mail.gmail.com>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
 <CAFhnQTQwu8TdUEEQM1n7R0SU2VtNE=0QUcM2xiqbiHgJ-sAMtw@mail.gmail.com>
Message-ID: <369fded0-f178-2229-0f99-ae923e6754de@alliot.org>

Well I am going to try to explain why I want to use STArrays and the 
runST function (and I am absolutely ready to be proven wrong, and 
directed to a better way to do it).

I have, as a simple way to learn the language, implemented an Awele 
program in Haskell (I have been programming games for years). It was 
easy, elegant (around 70 lines, 150 with the graphical interface) and 
completely functional, but I soon stumbled upon one problem. While 
implementing a vanilla alpha-beta is easy in functional style, 
implementing hash-tables (I mean hash-tables of the kind we use in game 
programming, not exactly regular hash-tables) is not that easy, and hash 
tables are mandatory to have a fast alpha-beta.

Currently, my idea is to create a module which will hide the 
implementation, and have only two functions in its interface:
1) A test_and_retrieve which take as only parameter a position and 
return a Maybe object which contains Nothing if the position has never 
been evaluated or (Just v) if there is already an evaluation for it (I 
know that I need more information than just a value, but for the sake of 
simplicity let's stick with just a value)
2) A store function which will take a position and its evaluation and 
store it in the table.

Now if I use IO Arrays, I will have to live in the IO Monad if I 
understand correctly how the IO Monad works, while using ST Arrays seems 
to give me the possibility to hide all the non functional code in my 
hash module, and keep my main code almost purely functional.

Le 29/12/2017 à 16:36, Ramin Honary a écrit :
> You should use "runSTArray" or "runSTUArray" instead of "runST" to 
> convert your STArray to an immutable array: 
> https://hackage.haskell.org/package/array-0.5.2.0/docs/Data-Array-ST.html#v:runSTUArray 
> <https://hackage.haskell.org/package/array-0.5.2.0/docs/Data-Array-ST.html#v:runSTUArray>
>
> Or another option is to use "stToIO"  to convert the "STArray" to an 
> "IOArray." 
> https://hackage.haskell.org/package/base-4.10.1.0/docs/Control-Monad-ST-Lazy.html#v:stToIO 
> but if you want to build an IOArray, it is better to just start with 
> an IOArray rather than converting an STArray to an IOArray.
>
> The design of ST arrays is to allow you to construct them quickly and 
> then make them immutable once you are done constructing it.
>
> An immutable array must have the whole array copied after every single 
> update, but ST arrays allow you to make many updates without copying, 
> then when you have completed constructing the ST array, you must 
> freeze it to an immutable array using the "runSTUArray" function. 
> Freezing happens without copying the array, after that it is immutable 
> and may not be made into an STArray again unless you unfreeze it using 
> "thaw", which creates a copy of it: 
> https://hackage.haskell.org/package/array-0.5.2.0/docs/Data-Array-MArray.html#v:thaw 
>
>
> Once you have constructed your immutable array, you can access it 
> arbitrarily using the immutable operator (!).
>
> If you want to make multiple updates at multiple times, you must use 
> an IOArray or IOUArray. The ST monad is designed for you to construct 
> pure, referentially transparent, immutable values in an isolated and 
> strictly evaluated "environment" that lets you perform strict updates 
> during construction. Once evaluation of the "ST" monad is complete, 
> the returned value becomes pure, immutable, and referentially 
> transparent. The for-all'd "s" parameter of the "runST" function 
> ensures you do not mix separate "environments," and this is the reason 
> you got your type error. Using "runSTArray" or "runSTUArray" does not 
> have this restriction.
>
> I am not sure of the reason for this design decision, but I know it 
> has something to do with the compiler guaranteeing that pure immutable 
> referentially transparent types are constructed without effecting each 
> other, preventing race conditions. There is discussion of this on the 
> Haskell wiki: 
> https://wiki.haskell.org/Monad/ST#An_explanation_in_Haskell-Cafe
>
>
> On Fri, Dec 29, 2017 at 11:36 PM, Jean-Marc Alliot <jm at alliot.org 
> <mailto:jm at alliot.org>> wrote:
>
>     Hi,
>
>     This is my first post to this list so I apologize in advance if I
>     don't use it properly, or if my question is too simple or
>     inapropriate.
>
>     I come from the Caml world and I am quite new to Haskell (but not
>     to functional programming). I am currently trying to get the hang
>     of Haskell arrays. I have gone through regular arrays, IO Arrays
>     and I am now working with ST Arrays.
>
>     This is the problem I am currently stuck with. I write the
>     following code:
>
>     arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
>     get :: Int -> Int
>     get i = runST (arr >>= (\b -> readArray b i))
>
>     Here everything is perfectly OK.
>
>     Now I want a more general version that could deal with any array
>     like arr. So I write:
>
>     get2 :: ST s (STArray s Int Int) -> Int -> Int
>     get2 tab i = runST (tab >>= (\b -> readArray b i))
>
>     And the compiler is clearly very upset by my code:
>
>     Couldn't match type ‘s’ with ‘s1’
>           ‘s’ is a rigid type variable bound by
>             the type signature for:
>               get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
>             at testst.hs:17:9
>           ‘s1’ is a rigid type variable bound by
>             a type expected by the context:
>               forall s1. ST s1 Int
>             at testst.hs:18:14
>           Expected type: ST s1 Int
>             Actual type: ST s Int
>     I am pretty sure that the compiler is right and I am wrong, but I
>     don't get why... Anyone could help?
>
>     Thanks
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>     Only members subscribed via the mailman list are allowed to post.
>
>

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

From ramin.honary at gmail.com  Fri Dec 29 17:01:22 2017
From: ramin.honary at gmail.com (Ramin Honary)
Date: Sat, 30 Dec 2017 02:01:22 +0900
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <369fded0-f178-2229-0f99-ae923e6754de@alliot.org>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
 <CAFhnQTQwu8TdUEEQM1n7R0SU2VtNE=0QUcM2xiqbiHgJ-sAMtw@mail.gmail.com>
 <369fded0-f178-2229-0f99-ae923e6754de@alliot.org>
Message-ID: <CAFhnQTSaSj6_MhAEfxaSYqVzXfqDYg49CRgRX=xEgS6HxK-9nA@mail.gmail.com>

(re-sending with "reply to all")

If I understand you correctly, you want to create updates to your hash
function throughout execution of your program. If this is the case, based
on my own experience, I believe the ST monad was not designed for this
purpose and so I think it is probably impossible. You must use the IO monad
for a hash table that receives regular updates during program execution.

ST is designed for doing rapid construction of a large immutable data by
evaluating many stateful updates to structure during the time before it is
made immutable. When monad evaluation terminates, the data structure
becomes immutable. Furthermore, you may not use the immutable data
structure until the ST evaluation terminates, producing the pure value.

For something like a game, you need to take input then update a hash in an
event loop. The IO monad is a good model of this sort of behavior, but the
ST monad is not.

Another possibility is that you can use a pure binary tree structure such
as Data.Map, if you would prefer to maintain purity, and pass this Map
structure around in a State monad transformer. If your State monad
transformer is of type (StateT (Map k v) IO a), you can use "liftIO" to
take inputs, and the "modify" function to update the Map state after each
input.


On Sat, Dec 30, 2017 at 1:05 AM, Jean-Marc Alliot <jm at alliot.org> wrote:

> Well I am going to try to explain why I want to use STArrays and the runST
> function (and I am absolutely ready to be proven wrong, and directed to a
> better way to do it).
>
> I have, as a simple way to learn the language, implemented an Awele
> program in Haskell (I have been programming games for years). It was easy,
> elegant (around 70 lines, 150 with the graphical interface) and completely
> functional, but I soon stumbled upon one problem. While implementing a
> vanilla alpha-beta is easy in functional style, implementing hash-tables (I
> mean hash-tables of the kind we use in game programming, not exactly
> regular hash-tables) is not that easy, and hash tables are mandatory to
> have a fast alpha-beta.
>
> Currently, my idea is to create a module which will hide the
> implementation, and have only two functions in its interface:
> 1) A test_and_retrieve which take as only parameter a position and return
> a Maybe object which contains Nothing if the position has never been
> evaluated or (Just v) if there is already an evaluation for it (I know that
> I need more information than just a value, but for the sake of simplicity
> let's stick with just a value)
> 2) A store function which will take a position and its evaluation and
> store it in the table.
>
> Now if I use IO Arrays, I will have to live in the IO Monad if I
> understand correctly how the IO Monad works, while using ST Arrays seems to
> give me the possibility to hide all the non functional code in my hash
> module, and keep my main code almost purely functional.
>
>
> Le 29/12/2017 à 16:36, Ramin Honary a écrit :
>
> You should use "runSTArray" or "runSTUArray" instead of "runST" to convert
> your STArray to an immutable array:  https://hackage.
> haskell.org/package/array-0.5.2.0/docs/Data-Array-ST.html#v:runSTUArray
>
> Or another option is to use "stToIO"  to convert the "STArray" to an
> "IOArray." https://hackage.haskell.org/package/base-4.10.
> 1.0/docs/Control-Monad-ST-Lazy.html#v:stToIO  but if you want to build an
> IOArray, it is better to just start with an IOArray rather than converting
> an STArray to an IOArray.
>
> The design of ST arrays is to allow you to construct them quickly and then
> make them immutable once you are done constructing it.
>
> An immutable array must have the whole array copied after every single
> update, but ST arrays allow you to make many updates without copying, then
> when you have completed constructing the ST array, you must freeze it to an
> immutable array using the "runSTUArray" function. Freezing happens without
> copying the array, after that it is immutable and may not be made into an
> STArray again unless you unfreeze it using "thaw", which creates a copy of
> it:  https://hackage.haskell.org/package/array-0.5.2.0/
> docs/Data-Array-MArray.html#v:thaw
>
> Once you have constructed your immutable array, you can access it
> arbitrarily using the immutable operator (!).
>
> If you want to make multiple updates at multiple times, you must use an
> IOArray or IOUArray. The ST monad is designed for you to construct pure,
> referentially transparent, immutable values in an isolated and strictly
> evaluated "environment" that lets you perform strict updates during
> construction. Once evaluation of the "ST" monad is complete, the returned
> value becomes pure, immutable, and referentially transparent. The for-all'd
> "s" parameter of the "runST" function ensures you do not mix separate
> "environments," and this is the reason you got your type error. Using
> "runSTArray" or "runSTUArray" does not have this restriction.
>
> I am not sure of the reason for this design decision, but I know it has
> something to do with the compiler guaranteeing that pure immutable
> referentially transparent types are constructed without effecting each
> other, preventing race conditions. There is discussion of this on the
> Haskell wiki:  https://wiki.haskell.org/Monad/ST#An_explanation_
> in_Haskell-Cafe
>
>
> On Fri, Dec 29, 2017 at 11:36 PM, Jean-Marc Alliot <jm at alliot.org> wrote:
>
>> Hi,
>>
>> This is my first post to this list so I apologize in advance if I don't
>> use it properly, or if my question is too simple or inapropriate.
>>
>> I come from the Caml world and I am quite new to Haskell (but not to
>> functional programming). I am currently trying to get the hang of Haskell
>> arrays. I have gone through regular arrays, IO Arrays and I am now working
>> with ST Arrays.
>>
>> This is the problem I am currently stuck with. I write the following code:
>>
>> arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
>> get :: Int -> Int
>> get i = runST (arr >>= (\b -> readArray b i))
>>
>> Here everything is perfectly OK.
>>
>> Now I want a more general version that could deal with any array like
>> arr. So I write:
>>
>> get2 :: ST s (STArray s Int Int) -> Int -> Int
>> get2 tab i = runST (tab >>= (\b -> readArray b i))
>>
>> And the compiler is clearly very upset by my code:
>>
>> Couldn't match type ‘s’ with ‘s1’
>>       ‘s’ is a rigid type variable bound by
>>         the type signature for:
>>           get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
>>         at testst.hs:17:9
>>       ‘s1’ is a rigid type variable bound by
>>         a type expected by the context:
>>           forall s1. ST s1 Int
>>         at testst.hs:18:14
>>       Expected type: ST s1 Int
>>         Actual type: ST s Int
>> I am pretty sure that the compiler is right and I am wrong, but I don't
>> get why... Anyone could help?
>>
>> Thanks
>>
>>
>> _______________________________________________
>> 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/20171230/267b4f0b/attachment.html>

From manny at fpcomplete.com  Fri Dec 29 17:58:56 2017
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Fri, 29 Dec 2017 09:58:56 -0800
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <CAB-d4A63sSrYSBVhrEOO6EcBnZGGdtAcfhvz_TzchC60O4y38w@mail.gmail.com>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A6A9dq5Y=4L+Gu6c9xA=B1khv5fifjWJ4rgsv+gdbBmBQ@mail.gmail.com>
 <CAB-d4A63sSrYSBVhrEOO6EcBnZGGdtAcfhvz_TzchC60O4y38w@mail.gmail.com>
Message-ID: <063D5643-88A7-4776-8C58-8662B420588A@fpcomplete.com>

Hi Ben,

Are there any plans to start releasing Linux bindists linked with libncurses.so.6?  A number of Linux distributions have upgraded from 5, including Fedora, Arch and Gentoo, and the currently available official bindists don't work out of the box on those anymore.

-- Manny


From allbery.b at gmail.com  Fri Dec 29 18:06:53 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 29 Dec 2017 13:06:53 -0500
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <0e15c2c9-f189-25a8-bbd9-a1e3a8b7c4f9@alliot.org>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
 <20171229171117.0567b7d2@Pavel>
 <0e15c2c9-f189-25a8-bbd9-a1e3a8b7c4f9@alliot.org>
Message-ID: <CAKFCL4UhK2034zewaDubEyUjQA=qzEu_X31AE5HPkxjdVAgokg@mail.gmail.com>

Rank2Types has been an alias for RankNTypes for several years.

In theory, rank-2 types allow some things that aren't possible for general
rank-N types (e.g. decidable typechecking). In practice, ghc does not and
probably never will implement those as special cases for rank-2 types, so
it no longer distinguishes them.

On Fri, Dec 29, 2017 at 10:31 AM, Jean-Marc Alliot <jm at alliot.org> wrote:

> Yes, thanks, it's exactly the same question, and the same trick works,
> using:
> {-# LANGUAGE RankNTypes #-}
> and
> get2 :: (forall s.ST s (STArray s Int Int)) -> Int -> Int
>
> In fact, Rank-2 types are enough here, we don't need Rank-N types.
> I suppose the ST Array module uses the Rank-N extension, so using them
> requires also enabling Rank-N.
>
> Thanks again.
>
>
> Le 29/12/2017 à 16:11, Baa a écrit :
>
>> Hello!
>>
>> I found this -
>> https://mail.haskell.org/pipermail/haskell-cafe/2011-May/091622.html
>>
>> I'm not sure is it helpful.
>>
>> PS. As I understand, `get2` signature has own `forall s`, but `runST`
>> is `(forall s. ST s a) -> a` which "escapes" top `s`.
>>
>> Somebody else? :)
>>
>> ===
>> Best regards, Paul
>>
>> Hi,
>>>
>>> This is my first post to this list so I apologize in advance if I
>>> don't use it properly, or if my question is too simple or
>>> inapropriate.
>>>
>>> I come from the Caml world and I am quite new to Haskell (but not to
>>> functional programming). I am currently trying to get the hang of
>>> Haskell arrays. I have gone through regular arrays, IO Arrays and I
>>> am now working with ST Arrays.
>>>
>>> This is the problem I am currently stuck with. I write the following
>>> code:
>>>
>>> arr = newArray (-1, 1) 0 :: ST s (STArray s Int Int)
>>> get :: Int -> Int
>>> get i = runST (arr >>= (\b -> readArray b i))
>>>
>>> Here everything is perfectly OK.
>>>
>>> Now I want a more general version that could deal with any array like
>>> arr. So I write:
>>>
>>> get2 :: ST s (STArray s Int Int) -> Int -> Int
>>> get2 tab i = runST (tab >>= (\b -> readArray b i))
>>>
>>> And the compiler is clearly very upset by my code:
>>>
>>> Couldn't match type ‘s’ with ‘s1’
>>>         ‘s’ is a rigid type variable bound by
>>>           the type signature for:
>>>             get2 :: forall s. ST s (STArray s Int Int) -> Int -> Int
>>>           at testst.hs:17:9
>>>         ‘s1’ is a rigid type variable bound by
>>>           a type expected by the context:
>>>             forall s1. ST s1 Int
>>>           at testst.hs:18:14
>>>         Expected type: ST s1 Int
>>>           Actual type: ST s Int
>>> I am pretty sure that the compiler is right and I am wrong, but I
>>> don't get why... Anyone could help?
>>>
>>> Thanks
>>>
>>>
>>> _______________________________________________
>>> 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.
>



-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171229/63f6fb4f/attachment.html>

From will.yager at gmail.com  Fri Dec 29 18:27:10 2017
From: will.yager at gmail.com (Will Yager)
Date: Fri, 29 Dec 2017 13:27:10 -0500
Subject: [Haskell-cafe] Question about ST arrays
In-Reply-To: <369fded0-f178-2229-0f99-ae923e6754de@alliot.org>
References: <61f084bb-e827-150e-0a9b-55f8c48eaf7e@alliot.org>
 <CAFhnQTQwu8TdUEEQM1n7R0SU2VtNE=0QUcM2xiqbiHgJ-sAMtw@mail.gmail.com>
 <369fded0-f178-2229-0f99-ae923e6754de@alliot.org>
Message-ID: <AFA59977-3E0C-4C9D-B12A-C3DE423C44A1@gmail.com>



> On Dec 29, 2017, at 11:05 AM, Jean-Marc Alliot <jm at alliot.org> wrote:
> 
> 
> 
> Now if I use IO Arrays, I will have to live in the IO Monad if I understand correctly how the IO Monad works, while using ST Arrays seems to give me the possibility to hide all the non functional code in my hash module, and keep my main code almost purely functional.

Just as IO arrays require you to live in the IO monad anywhere you want to read/write a mutable IO array, ST arrays require you to live in the ST monad anywhere you want to read/write an ST array. 

Your earlier code of the form

(forall s . ST s (Array Int Int)) -> Int -> Int

Actually runs the ST action which creates the mutable array every time you call the function. So you’re not sharing the same mutable array; you’re creating it from scratch every time. This is probably not what you intend. 

The ST monad is good for when you really need the speed boost of a locally mutable operation in an otherwise immutable program. It is not good for keeping track of a mutable state, which is what you are doing with the hash table. 

What you probably want is the State monad. It takes functions of the form

state -> (state, result)

And provides convenient syntax and abstractions for combining these functions. In this case, the state would be your hash table. So the function that checks for an existing solution would have type

Hashtbl -> (Hashtbl, Maybe Soln)

AKA

State Hashtbl (Maybe Soln)

And the function that writes a new solution would have type 

Soln -> Hashtbl -> (Hashtbl, ())

AKA

Soln -> State Hashtbl ()

Compare these types to those of the functions for reading and writing ST arrays. 

The downside of State is that its state type must be an immutable structure, which will have some overhead compared to a mutable array. However, structures such as the Hashmap are pretty fast even though they’re immutable. 

-Will



From theedge456 at free.fr  Sat Dec 30 14:13:02 2017
From: theedge456 at free.fr (Fabien R)
Date: Sat, 30 Dec 2017 15:13:02 +0100
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
Message-ID: <7177cca3-e80d-64ba-e77d-cbd0361353bb@free.fr>

On 20/12/17 21:48, Ben Gamari wrote:
> 
> The GHC development team is pleased to announce the first alpha release
> of the 8.4.1 release. The usual release artifacts are available from
> 
>     https://downloads.haskell.org/~ghc/8.4.1-alpha1

I tried to build the release from this script [1] which works
straightfully for GHC 8.2.2 on debian jessie.
1) There's a minor glitch showing:
GHC_VERSION = 8.4.1
but the version of the file in the download area is 8.4.0.20171214

2) GHC and cabal library installed successfully whereas cabal-install
failed with this error:

Linking Setup ...
Configuring HTTP-4000.3.7...
Setup: Encountered missing dependencies:
base >=4.3.0.0 && <4.11


Error during cabal-install bootstrap:
Configuring the HTTP package failed.

Any hint ?

--
Fabien


[1] gist.github.com/yantonov/10083524


From allbery.b at gmail.com  Sat Dec 30 14:29:01 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 30 Dec 2017 09:29:01 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <7177cca3-e80d-64ba-e77d-cbd0361353bb@free.fr>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <7177cca3-e80d-64ba-e77d-cbd0361353bb@free.fr>
Message-ID: <CAKFCL4Ug68HVaqemSNdQFecu=TH-_r9Y+EGCChsRLAfTTE9hbg@mail.gmail.com>

If you install over an older version of ghc, you will have a leftover
package cache from the old version which will cause package lookups to
fail. Someone else just tripped over this in IRC after installing a new ghc
over an old one; the Arch 8.2.2 upgrade from 8.2.1 also seems to be
susceptible to this. Rebuilding the package cache (ghc-pkg recache
--global; with sudo if installed as root) will fix this.

On Sat, Dec 30, 2017 at 9:13 AM, Fabien R <theedge456 at free.fr> wrote:

> On 20/12/17 21:48, Ben Gamari wrote:
> >
> > The GHC development team is pleased to announce the first alpha release
> > of the 8.4.1 release. The usual release artifacts are available from
> >
> >     https://downloads.haskell.org/~ghc/8.4.1-alpha1
>
> I tried to build the release from this script [1] which works
> straightfully for GHC 8.2.2 on debian jessie.
> 1) There's a minor glitch showing:
> GHC_VERSION = 8.4.1
> but the version of the file in the download area is 8.4.0.20171214
>
> 2) GHC and cabal library installed successfully whereas cabal-install
> failed with this error:
>
> Linking Setup ...
> Configuring HTTP-4000.3.7...
> Setup: Encountered missing dependencies:
> base >=4.3.0.0 && <4.11
>
>
> Error during cabal-install bootstrap:
> Configuring the HTTP package failed.
>
> Any hint ?
>
> --
> Fabien
>
>
> [1] gist.github.com/yantonov/10083524
>
> _______________________________________________
> 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                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171230/13672df5/attachment.html>

From olshanskydr at gmail.com  Sat Dec 30 19:08:23 2017
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Sat, 30 Dec 2017 22:08:23 +0300
Subject: [Haskell-cafe] singToList
Message-ID: <CAHe9v2KBnCy=+EmAaKiLp7U+A04VhkfqQPVDLTu43UrCwFDZxw@mail.gmail.com>

Hello cafe,

Does a function like `singToList` exist somewhere:

singToList :: Sing (xs :: [k]) -> [SomeSing k]
singToList = \case
  SNil -> []
  SCons x xs -> SomeSing x : singToList xs

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171230/04ec903d/attachment.html>

From ben at well-typed.com  Sun Dec 31 05:14:40 2017
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 31 Dec 2017 00:14:40 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <7177cca3-e80d-64ba-e77d-cbd0361353bb@free.fr>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <7177cca3-e80d-64ba-e77d-cbd0361353bb@free.fr>
Message-ID: <87efnbbhs7.fsf@ben-laptop.smart-cactus.org>

Fabien R <theedge456 at free.fr> writes:

> On 20/12/17 21:48, Ben Gamari wrote:
>> 
>> The GHC development team is pleased to announce the first alpha release
>> of the 8.4.1 release. The usual release artifacts are available from
>> 
>>     https://downloads.haskell.org/~ghc/8.4.1-alpha1
>
Hi Fabien,

Thanks for taking the time to test.

> I tried to build the release from this script [1] which works
> straightfully for GHC 8.2.2 on debian jessie.
> 1) There's a minor glitch showing:
> GHC_VERSION = 8.4.1
> but the version of the file in the download area is 8.4.0.20171214
>
This is expected; pre-releases always have version numbers strictly less
than the final release they lead up to.

> 2) GHC and cabal library installed successfully whereas cabal-install
> failed with this error:
>
> Linking Setup ...
> Configuring HTTP-4000.3.7...
> Setup: Encountered missing dependencies:
> base >=4.3.0.0 && <4.11
>
>
> Error during cabal-install bootstrap:
> Configuring the HTTP package failed.
>
This is due to the upper bound on `base`. You will likely get farther if
you invoke cabal with --allow-newer=base. In general you will likely
want to use something like Herbert's head.hackage [1] patch-set if you
want to build larger projects with this alpha.

Cheers,

- Ben

[1] https://github.com/hvr/head.hackage
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171231/10e83ae8/attachment.sig>

From ben at well-typed.com  Sun Dec 31 05:19:26 2017
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 31 Dec 2017 00:19:26 -0500
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1-alpha1 available
In-Reply-To: <063D5643-88A7-4776-8C58-8662B420588A@fpcomplete.com>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A6A9dq5Y=4L+Gu6c9xA=B1khv5fifjWJ4rgsv+gdbBmBQ@mail.gmail.com>
 <CAB-d4A63sSrYSBVhrEOO6EcBnZGGdtAcfhvz_TzchC60O4y38w@mail.gmail.com>
 <063D5643-88A7-4776-8C58-8662B420588A@fpcomplete.com>
Message-ID: <87d12vbhk3.fsf@ben-laptop.smart-cactus.org>

Emanuel Borsboom <manny at fpcomplete.com> writes:

> Hi Ben,
>
> Are there any plans to start releasing Linux bindists linked with
> libncurses.so.6? A number of Linux distributions have upgraded from 5,
> including Fedora, Arch and Gentoo, and the currently available
> official bindists don't work out of the box on those anymore.
>
Indeed I can add an ncurses.so.6 platform to the build matrix. I'll
start with the next alpha. Thanks for mentioning this!

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171231/54697155/attachment.sig>

From ramin.honary at gmail.com  Sun Dec 31 13:05:01 2017
From: ramin.honary at gmail.com (Ramin Honary)
Date: Sun, 31 Dec 2017 22:05:01 +0900
Subject: [Haskell-cafe] singToList
In-Reply-To: <CAHe9v2KBnCy=+EmAaKiLp7U+A04VhkfqQPVDLTu43UrCwFDZxw@mail.gmail.com>
References: <CAHe9v2KBnCy=+EmAaKiLp7U+A04VhkfqQPVDLTu43UrCwFDZxw@mail.gmail.com>
Message-ID: <CAFhnQTT9U--1aUymAmnsL2gmRb+S4y+O0vWydeWkequVfEV0dw@mail.gmail.com>

I think the closest thing I can think of that describes a "thingToList"
kind of thing you are talking about would be the "Foldable" and
"Traversable" class:

https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Foldable.html
https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Traversable.html

However it is not exactly as you described, there is no direct conversion
of a "Thing" data structure to an actual list data structure.

The problem with converting data structures like Trees into lists
structures is that this can be inefficient. Instead, think of the reason
you want to have a list object: because you want to perform scan through
the list to find an element, or you want to perform a fold, yes?

So instead of converting to a list and then applying a fold or map
function, it is much better to pass a mapping function to a higher-order
function like "mapM," or "sequence," or pass a folding function a
higher-order function like "foldM", and allow these higher-order functions
scan through the data structure without converting it to a list first.



On Sun, Dec 31, 2017 at 4:08 AM, Dmitry Olshansky <olshanskydr at gmail.com>
wrote:

> Hello cafe,
>
> Does a function like `singToList` exist somewhere:
>
> singToList :: Sing (xs :: [k]) -> [SomeSing k]
> singToList = \case
>   SNil -> []
>   SCons x xs -> SomeSing x : singToList xs
>
> ?
>
> _______________________________________________
> 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/20171231/9a952c03/attachment.html>

From olshanskydr at gmail.com  Sun Dec 31 16:09:26 2017
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Sun, 31 Dec 2017 19:09:26 +0300
Subject: [Haskell-cafe] singToList
In-Reply-To: <CAFhnQTT9U--1aUymAmnsL2gmRb+S4y+O0vWydeWkequVfEV0dw@mail.gmail.com>
References: <CAHe9v2KBnCy=+EmAaKiLp7U+A04VhkfqQPVDLTu43UrCwFDZxw@mail.gmail.com>
 <CAFhnQTT9U--1aUymAmnsL2gmRb+S4y+O0vWydeWkequVfEV0dw@mail.gmail.com>
Message-ID: <CAHe9v2L9+2JcnWVpdUHTU=AM8HG8ub3B4VGEOZw0U6V9Uib7EQ@mail.gmail.com>

I have to say that a question about types from singletons package. I am
sorry that didn't say it before.

31 дек. 2017 г. 4:05 PM пользователь "Ramin Honary" <ramin.honary at gmail.com>
написал:

> I think the closest thing I can think of that describes a "thingToList"
> kind of thing you are talking about would be the "Foldable" and
> "Traversable" class:
>
> https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Foldable.html
> https://hackage.haskell.org/package/base-4.10.1.0/docs/
> Data-Traversable.html
>
> However it is not exactly as you described, there is no direct conversion
> of a "Thing" data structure to an actual list data structure.
>
> The problem with converting data structures like Trees into lists
> structures is that this can be inefficient. Instead, think of the reason
> you want to have a list object: because you want to perform scan through
> the list to find an element, or you want to perform a fold, yes?
>
> So instead of converting to a list and then applying a fold or map
> function, it is much better to pass a mapping function to a higher-order
> function like "mapM," or "sequence," or pass a folding function a
> higher-order function like "foldM", and allow these higher-order functions
> scan through the data structure without converting it to a list first.
>
>
>
> On Sun, Dec 31, 2017 at 4:08 AM, Dmitry Olshansky <olshanskydr at gmail.com>
> wrote:
>
>> Hello cafe,
>>
>> Does a function like `singToList` exist somewhere:
>>
>> singToList :: Sing (xs :: [k]) -> [SomeSing k]
>> singToList = \case
>>   SNil -> []
>>   SCons x xs -> SomeSing x : singToList xs
>>
>> ?
>>
>> _______________________________________________
>> 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/20171231/6c281f62/attachment.html>

From simon at joyful.com  Sun Dec 31 20:42:16 2017
From: simon at joyful.com (Simon Michael)
Date: Sun, 31 Dec 2017 12:42:16 -0800
Subject: [Haskell-cafe] ANN: hledger 1.5
Message-ID: <E5A7470C-8914-413A-8070-47B941E66581@joyful.com>

Happy New Year all! I'm very pleased to announce hledger 1.5.

hledger (http://hledger.org) is a reliable, cross-platform program for
tracking money, time or other commodities, using double-entry
accounting and simple plain text file formats. It provides
command-line, curses and web interfaces, and aims to be a pleasant and
practical tool for personal, business or institutional use.

A big thank you to the release contributors:

Dmitry Astapov,
Mykola Orliuk,
Eli Flanagan,
Elijah Caine,
Sam Jeeves,
Matthias Kauer,
Hans-Peter Deifel,
Mick Dekkers,
Nadrieril,
Alvaro Fernando García.

In 2017, four quarter-end releases were shipped on schedule, 
and our feature set, marketing reach and contributor activity 
continue to grow. The next release is scheduled for 2018/03/31.

New users and contributors are always welcome! Give feedback, report
bugs, send pull requests, write about it, etc.  And if you have been
finding hledger useful, consider becoming a sponsor or donor to help
to sustain and accelerate our progress (see home page).
Our IRC channel is #hledger on Freenode (http://irc.hledger.org).

What's new ?
------------

Some highlights from the release notes at http://hledger.org/release-notes#hledger-1.5 :

* Ledger-style automated posting rules to modify transactions, enabled
  with --auto flag

* Ledger-style periodic transaction rules to generate forecast
  transactions (--forecast) and budget goals

* a new budget report (balance --budget) comparing amounts with
  per-period and per-account budget goals

* more expressive period expressions

* space can be used as digit group separator character in numbers

* commodity or default commodity directives give more control over
  display precision and decimal point/digit group separator

Get started
-----------

See http://hledger.org/download for all install methods.  Windows
users can download nightly binaries.  On other platforms, you may need
to build the latest release yourself.  The easiest and most reliable
way is to run the hledger install script.  This requires only bash and
will install the hledger tools in $HOME/.local/bin/.  (It uses an
installed cabal or stack if possible, otherwise installs stack and GHC
in $HOME/.local/bin and $HOME/.stack/).  Here's the responsible way to
run it:

$ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh
$ less hledger-install.sh # (do security review)
$ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run)

or the more convenient, less secure way:

$ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh | bash

or, to install individual tools:

$ stack install hledger-1.5  # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc.

or:

$ cabal update
$ cabal install hledger-1.5  # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc.

Note: building haskell apps can take significant time, memory, and
disk space, especially the first time.  You can kill and restart the
installer without losing progress.  If it fails, please help us
improve it by reporting the full output.

After installation, ensure $HOME/.local/bin is in your $PATH. 
Now try some commands:

$ hledger -h            # quick help
$ hledger help          # list built-in manuals
$ hledger add           # record some transactions
$ hledger               # list available commands

Now perhaps work through the tutorial at http://hledger.org/step-by-step.html

Or review the fine documents, presentations etc. at http://hledger.org
and http://plaintextaccounting.org

Or say hello and ask questions in the #hledger IRC channel on Freenode:
http://irc.hledger.org


Wishing you a highly prosperous and serene 2018,

-Simon
Happy New Year all! I'm very pleased to announce hledger 1.5.

hledger (http://hledger.org) is a reliable, cross-platform program for
tracking money, time or other commodities, using double-entry
accounting and simple plain text file formats. It provides
command-line, curses and web interfaces, and aims to be a pleasant and
practical tool for personal, business or institutional use.

A big thank you to the release contributors:

Dmitry Astapov,
Mykola Orliuk,
Eli Flanagan,
Elijah Caine,
Sam Jeeves,
Matthias Kauer,
Hans-Peter Deifel,
Mick Dekkers,
Nadrieril,
Alvaro Fernando García.

In 2017, four quarter-end releases were shipped on schedule, 
and our feature set, marketing reach and contributor activity 
continue to grow. The next release is scheduled for 2018/03/31.

New users and contributors are always welcome! Give feedback, report
bugs, send pull requests, write about it, etc.  And if you have been
finding hledger useful, consider becoming a sponsor or donor to help
to sustain and accelerate our progress (see home page).
Our IRC channel is #hledger on Freenode (http://irc.hledger.org).

What's new ?
------------

Some highlights from the release notes at http://hledger.org/release-notes#hledger-1.5 :

* Ledger-style automated posting rules to modify transactions, enabled
  with --auto flag

* Ledger-style periodic transaction rules to generate forecast
  transactions (--forecast) and budget goals

* a new budget report (balance --budget) comparing amounts with
  per-period and per-account budget goals

* more expressive period expressions

* space can be used as digit group separator character in numbers

* commodity or default commodity directives give more control over
  display precision and decimal point/digit group separator

Get started
-----------

See http://hledger.org/download for all install methods.  Windows
users can download nightly binaries.  On other platforms, you may need
to build the latest release yourself.  The easiest and most reliable
way is to run the hledger install script.  This requires only bash and
will install the hledger tools in $HOME/.local/bin/.  (It uses an
installed cabal or stack if possible, otherwise installs stack and GHC
in $HOME/.local/bin and $HOME/.stack/).  Here's the responsible way to
run it:

$ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh
$ less hledger-install.sh # (do security review)
$ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run)

or the more convenient, less secure way:

$ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh | bash

or, to install individual tools:

$ stack install hledger-1.5  # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc.

or:

$ cabal update
$ cabal install hledger-1.5  # hledger-ui-1.5 hledger-web-1.5 hledger-api-1.5 etc.

Note: building haskell apps can take significant time, memory, and
disk space, especially the first time.  You can kill and restart the
installer without losing progress.  If it fails, please help us
improve it by reporting the full output.

After installation, ensure $HOME/.local/bin is in your $PATH. 
Now try some commands:

$ hledger -h            # quick help
$ hledger help          # list built-in manuals
$ hledger add           # record some transactions
$ hledger               # list available commands

Now perhaps work through the tutorial at http://hledger.org/step-by-step.html

Or review the fine documents, presentations etc. at http://hledger.org
and http://plaintextaccounting.org

Or say hello and ask questions in the #hledger IRC channel on Freenode:
http://irc.hledger.org


Wishing you a highly prosperous and serene 2018,

-Simon