Volunteer for a panel at HIW 2019

[Iavor Diatchki]

Hello,

I am sending this on behalf of Nikki Vazou, who is organizing this
year's HIW---she is looking for a volunteer to represent Haskell' on a
panel, but the haskell-prime list is restricted to only members.
Details are in her message below.

If you are interested, please respond directly to her.

Cheers,
-Iavor

PS: Niki sorry for the multiple messages, my message also bounced
because apparently I used the wrong e-mail address.


>
>
> -- Forwarded message --
> From: Niki Vazou 
> To: haskell-prime@haskell.org
> Cc:
> Bcc:
> Date: Fri, 26 Jul 2019 14:13:36 +0200
> Subject: Haskell Implementors Working: Looking for Panelists
> Hello,
>
> Haskell Implementors Workshop 2019 will be having a 45 min panel discussion 
> (17.15-18.00 on Fri 23th August).
>
> The goal is to have panelists that represent the following committees:
> - ghc steering committee
> - Devops committee
> - core libraries committee
> - Haskell' committee
> - Haskell.org committee
> - Haskell Symposium & HiW steering committee
>
> Let me know if you
> - want like to be in the panel
> - if there are issues you want to raise in the panel discussion.
>
> Best,
> Niki
> Chair of HiW'19
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Default module header `module Main where`

[Iavor Diatchki]

One potential difference between the two is that the current behavior
allows the `Main` module to import `main` from another module, while the
new behavior would fail in that case.

For example, a file that has only a single line:

import SomeOtherModule(main)

This still seems like a fairly unusual corner case (with an obvious work
around), so I don't think it matters much, but I thought I'd mention it so
that we are aware of it.






On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner 
wrote:

> Hi,
>
> a very small proposal to be considered for Haskell':
>
> Currently, the report states
>
> An abbreviated form of module, consisting only of the module body,
> is permitted. If this is used, the header is assumed to be ‘module
> Main(main) where’.
>
> I propose to change that to
>
> An abbreviated form of module, consisting only of the module body,
> is permitted. If this is used, the header is assumed to be ‘module
> Main where’.
>
> The rationale is that a main-less main module is still useful, e.g.
> when you are working a lot in GHCi, and offload a few extensions to a
> separate file. Currently, tools like hdevtools will complain about a
> missing main function when editing such a file.
>
> It would also work better with GHC’s -main-is flag, and avoid problems
> like the one described in https://ghc.haskell.org/trac/ghc/ticket/13704
>
>
> I don’t see any downsides. When compiling to a binary, implementations
> are still able to detect that a Main module is not imported by any
> other module and only the main function is used, and optimize as if
> only main were exported.
>
> Greetings,
> Joachim
>
>
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Default module header `module Main where`

[Iavor Diatchki]

That seems fairly reasonable to me.

-Iavor

On Tue, May 16, 2017 at 7:18 AM, Joachim Breitner 
wrote:

> Hi,
>
> a very small proposal to be considered for Haskell':
>
> Currently, the report states
>
> An abbreviated form of module, consisting only of the module body,
> is permitted. If this is used, the header is assumed to be ‘module
> Main(main) where’.
>
> I propose to change that to
>
> An abbreviated form of module, consisting only of the module body,
> is permitted. If this is used, the header is assumed to be ‘module
> Main where’.
>
> The rationale is that a main-less main module is still useful, e.g.
> when you are working a lot in GHCi, and offload a few extensions to a
> separate file. Currently, tools like hdevtools will complain about a
> missing main function when editing such a file.
>
> It would also work better with GHC’s -main-is flag, and avoid problems
> like the one described in https://ghc.haskell.org/trac/ghc/ticket/13704
>
>
> I don’t see any downsides. When compiling to a binary, implementations
> are still able to detect that a Main module is not imported by any
> other module and only the main function is used, and optimize as if
> only main were exported.
>
> Greetings,
> Joachim
>
>
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Unused import warning on re-export

[Iavor Diatchki]

Actually, I just tried to make an example of this, and GHC does not seem to
export `f`, just as the report says.  So I'd say GHC is behaving correctly,
both with the exports and the warning.



On Fri, May 12, 2017 at 10:39 AM, Iavor Diatchki <iavor.diatc...@gmail.com>
wrote:

> Hello,
>
> actually, the bug here is that `f` is exported, as omitting the export
> list is not equivalent to writing `module A` in the export list.
>
> This is explicitly stated in Section 5.2 of the Haskell report:
>
>  "If the export list is omitted, all values, types and classes defined in
> the module are exported, but not those that are imported."
>
> -Iavor
>
>
>
>
>
>
>
>
>
> On Thu, May 11, 2017 at 1:23 PM, Simon Peyton Jones via
> Glasgow-haskell-users <glasgow-haskell-users@haskell.org> wrote:
>
>> | Is there a reason GHC considers this case an unused import? It seems
>> that
>> | the use of the import is explicitly stated right within the import
>> | itself. Should I submit a ticket for this?
>>
>> Hmm.  I think you are saying that
>>
>>   module A where
>> import B as A(f)
>> g = True
>>
>> that is equivalent to
>>module A( module A ) where ...
>>
>> which exports all things "x" in scope as "A.x".  So it'll export both f
>> and g.
>>
>> But GHC will report f as unused, but not g. And that's inconsistent.
>> Fair point.  Yes, file a ticket.  Better still, offer a patch :-).
>>
>> Simon
>>
>> | -Original Message-
>> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
>> | boun...@haskell.org] On Behalf Of Yitzchak Gale
>> | Sent: 10 May 2017 13:56
>> | To: GHC users <glasgow-haskell-users@haskell.org>
>> | Subject: Unused import warning on re-export
>> |
>> | I have a module A with no export list, and a function f which from the
>> | API point of view should part of the export list of A. But f must be
>> | defined in module B, not module A, due an import cycle. I added this
>> line
>> | in module A to re-export f from A:
>> |
>> | import B as A (f)
>> |
>> | This resulted in an unused import warning. That is a problem for us - we
>> | keep our large code base clean of warnings as a policy.
>> |
>> | Is there a reason GHC considers this case an unused import? It seems
>> that
>> | the use of the import is explicitly stated right within the import
>> | itself. Should I submit a ticket for this?
>> |
>> | Thanks,
>> | Yitz
>> | ___
>> | Glasgow-haskell-users mailing list
>> | Glasgow-haskell-users@haskell.org
>> | https://na01.safelinks.protection.outlook.com/?url=http%3A%
>> 2F%2Fmail.hask
>> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
>> | users=02%7C01%7Csimonpj%40microsoft.com%7C81b06c9737d54
>> 0a597df08d497
>> | a413d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63630017
>> 8355700119
>> | ata=xHt1FXEF5r4WMaMF3FSW4jFBRlB4OK8DQdcNAxZ7HOc%3D=0
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Unused import warning on re-export

[Iavor Diatchki]

Hello,

actually, the bug here is that `f` is exported, as omitting the export list
is not equivalent to writing `module A` in the export list.

This is explicitly stated in Section 5.2 of the Haskell report:

 "If the export list is omitted, all values, types and classes defined in
the module are exported, but not those that are imported."

-Iavor









On Thu, May 11, 2017 at 1:23 PM, Simon Peyton Jones via
Glasgow-haskell-users  wrote:

> | Is there a reason GHC considers this case an unused import? It seems that
> | the use of the import is explicitly stated right within the import
> | itself. Should I submit a ticket for this?
>
> Hmm.  I think you are saying that
>
>   module A where
> import B as A(f)
> g = True
>
> that is equivalent to
>module A( module A ) where ...
>
> which exports all things "x" in scope as "A.x".  So it'll export both f
> and g.
>
> But GHC will report f as unused, but not g. And that's inconsistent.  Fair
> point.  Yes, file a ticket.  Better still, offer a patch :-).
>
> Simon
>
> | -Original Message-
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Yitzchak Gale
> | Sent: 10 May 2017 13:56
> | To: GHC users 
> | Subject: Unused import warning on re-export
> |
> | I have a module A with no export list, and a function f which from the
> | API point of view should part of the export list of A. But f must be
> | defined in module B, not module A, due an import cycle. I added this line
> | in module A to re-export f from A:
> |
> | import B as A (f)
> |
> | This resulted in an unused import warning. That is a problem for us - we
> | keep our large code base clean of warnings as a policy.
> |
> | Is there a reason GHC considers this case an unused import? It seems that
> | the use of the import is explicitly stated right within the import
> | itself. Should I submit a ticket for this?
> |
> | Thanks,
> | Yitz
> | ___
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users@haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
> | users=02%7C01%7Csimonpj%40microsoft.com%
> 7C81b06c9737d540a597df08d497
> | a413d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C636300178355700119
> | ata=xHt1FXEF5r4WMaMF3FSW4jFBRlB4OK8DQdcNAxZ7HOc%3D=0
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[Haskell] Haskell Symposium deadline in 3 weeks

[Iavor Diatchki]

  2017, Monday
  Notification: 26 June 2017, Monday

Deadlines are valid anywhere on Earth.

Submission
--

Submission should adhere to SIGPLAN's republication policy,
as explained on the web.

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

Papers should be submitted through easychair at:

  https://easychair.org/conferences/?conf=haskell2017


Travel Support
==

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


Proceedings
===

Accepted papers will be included in the ACM Digital Library. Authors must grant
ACM publication rights upon acceptance (http://authors.acm.org/main.html).
Authors are encouraged to publish auxiliary material with their paper (source
code, test data, etc.); they retain copyright of auxiliary material.

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

All accepted papers and proposals will be posted on the conference
website one week before the meeting.

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


Program Committee
=

Adam Gundry   Well-Typed
Ekaterina Komendantskaya  University of Dundee
Henrik NilssonUniversity of Nottingham
Iavor Diatchki (chair)Galois
J. Garrett Morris University of Edinburgh
Joachim Breitner  University of Pennsylvania
Juriaan Hage  Utrecht University
Lennart AugustssonFacebook
Martin Erwig  Oregon State University
Rebekah Leslie-Hurd   Intel
Takayuki MuranushiUniversity of Kyoto
Thomas Hallgren   Chalmers University
Ulf Norrell   Chalmers University

If you have questions, please contact the chair at: diatc...@galois.com


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

Re: Why isn't this Overlapping?

[Iavor Diatchki]

Hello,

these two instances really should be rejected as they violate the FD of the
class: we can derive `TypeEq a a True` using the first instance and `TypeEq
a a False` using the second one.  Unfortunately, the check that we are
using to validate FDs when `UndecidableInstances` is on, is not quite
correct (relevant tickets are #9210 and #10675 where there are similar
examples).

-Iavor



On Sun, Apr 16, 2017 at 12:13 AM, Anthony Clayden <
anthony_clay...@clear.net.nz> wrote:

> --ghc 7.10 or 8.0.1
>
> {-# LANGUAGE DataKinds, KindSignatures, GADTs,
>   MultiParamTypeClasses,
> FunctionalDependencies, FlexibleInstances,
>   UndecidableInstances,
> NoOverlappingInstances   #-}
>
> class TypeEq a a' (b :: Bool) | a a' -> b
>
> instance (b ~ True) => TypeEq a a b
> instance (b ~ False) => TypeEq a a' b
>
> Those two instance heads are nearly identical, surely they
> overlap?
> And for a type-level type equality test, they must be
> unifiable.
> But GHC doesn't complain.
>
> If I take off the FunDep, then GHC complains.
>
> AFAICT none of those extensions imply Overlaps,
> but to be sure I've put NoOverlapping.
>
>
> AntC
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Alternative to importing GHC.TypeLits?

[Iavor Diatchki]

Hi,

the initial plan was that `GHC.TypeLits` should provide just the basic
functionality, and later other libraries would be build to provide more
convenient functions for specific applications.   I don't know of any such
convenience libraries, so at present, people just import `GHC.TypeLits`
directly.

-Iavor

On Fri, Mar 31, 2017 at 7:35 AM, Chris Martin  wrote:

> The GHC manual gives code examples that import GHC.TypeLits. The
> documentation on that module seems to request that users /not/ import it ...
>
> > This module is an internal GHC module. [...] The programmer interface
> for working with type-level naturals should be defined in a separate
> library.
>
> ... although I'm not sure what "what be" means here. Does that mean it's a
> to-do item, and that there will eventually be a separate library, but that
> we should use this "internal" library directly for now?
>
> ---
>
> GHC manual: https://downloads.haskell.org/~ghc/latest/docs/html/users_
> guide/glasgow_exts.html?highlight=typelits#type-level-literals
>
> GHC.TypeLits: https://www.stackage.org/haddock/lts-8.5/base-4.9.1.0/
> GHC-TypeLits.html
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[Haskell] Haskell Symposium Early Deadline in Two Weeks

[Iavor Diatchki]

  2017, Monday
  Notification: 26 June 2017, Monday

Deadlines are valid anywhere on Earth.

Submission
--

Submission should adhere to SIGPLAN's republication policy,
as explained on the web.

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

Papers should be submitted through easychair at:

  https://easychair.org/conferences/?conf=haskell2017


Travel Support
==

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


Proceedings
===

Accepted papers will be included in the ACM Digital Library. Authors must grant
ACM publication rights upon acceptance (http://authors.acm.org/main.html).
Authors are encouraged to publish auxiliary material with their paper (source
code, test data, etc.); they retain copyright of auxiliary material.

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

All accepted papers and proposals will be posted on the conference
website one week before the meeting.

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


Program Committee
=

Adam Gundry   Well-Typed
Ekaterina Komendantskaya  University of Dundee
Henrik NilssonUniversity of Nottingham
Iavor Diatchki (chair)Galois
J. Garrett Morris University of Edinburgh
Joachim Breitner  University of Pennsylvania
Juriaan Hage  Utrecht University
Lennart AugustssonFacebook
Martin Erwig  Oregon State University
Rebekah LeslieIntel
Takayuki MuranushiUniversity of Kyoto
Thomas Hallgren   Chalmers University
Ulf NorrelChalmers University

If you have questions, please contact the chair at: diatc...@galois.com


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

[Haskell] Haskell Symposium 2017, call for submissions

[Iavor Diatchki]

  2017, Monday
  Notification: 26 June 2017, Monday

Deadlines are valid anywhere on Earth.

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

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


Submission Details
==

Early and Regular Track
---

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


Program Committee
=

Adam Gundry   Well-Typed
Ekaterina Komendantskaya  University of Dundee
Henrik NilssonUniversity of Nottingham
Iavor Diatchki (chair)Galois
J. Garrett Morris University of Edinburgh
Joachim Breitner  University of Pennsylvania
Juriaan Hage  Utrecht University
Lennart AugustssonFacebook
Martin Erwig  Oregon State University
Rebekah LeslieIntel
Takayuki MuranushiUniversity of Kyoto
Thomas Hallgren   Chalmers University
Ulf NorrelChalmers University

If you have questions, please contact the chair at: diatc...@galois.com


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

Re: GitHub proposal repo permissions

[Iavor Diatchki]

Hi, I think Herbert added me to the correct group, thanks!

On Tue, Oct 18, 2016 at 10:24 AM, David Luposchainsky via Haskell-prime <
haskell-prime@haskell.org> wrote:

> On 12.10.2016 19:09, Iavor Diatchki wrote:
> > could someone with access fix it, maybe David
>
> I’m just a regular Haskell member (I think), Herbert gave me the access
> rights
> and I didn’t run into any problems yet. Now that I’m back from my holidays
> I
> guess I’m a bit late to answering your issue.
>
> Anyway, I looked at the RFCS settings, and it seems like I could have
> added you.
> Is the issue resolved, or should I give you permissions?
>
> Greetings,
> David
>
> --
> My GPG keys: https://keybase.io/quchen
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

GitHub proposal repo permissions

[Iavor Diatchki]

Hello,

I was just trying to update the `Haskel 2020` project as it is not in sync
with the actual pull-requests, bit I can't see a way to do it.  Am I
missing something, or do I simply not have the required permissions?

If this is indeed a permissions issue, could someone with access fix it
(maybe David?).   Probably the easiest would be to create a group with all
the members and give it access to the repo.

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

Proposal: accept tuple sections

[Iavor Diatchki]

Hello,

it seems that there isn't much controversy over the TupleSections propsal,
so I'd like to move the we accept it for the next language standard.

Does anyone have any objections?

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

Process question

[Iavor Diatchki]

Hello,

Now that we've started with a few proposal, I am realizing that I have no
idea how to proceed from here.  In particular:

1. How would I request I proposal to be rejected
2. How would I request that a proposal be accepted

Ideas?

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

Re: Step-by-step guide for creating a new proposal

[Iavor Diatchki]

OK, I put a section at the top saying that, and then summarizing the
process for people who are familiar with the tools.   I also updated the
last list to say that you should add a link to the rendered version and how
to do it.





On Tue, Oct 4, 2016 at 8:40 AM, David Luposchainsky via Haskell-prime <
haskell-prime@haskell.org> wrote:

> On 04.10.2016 01:27, Iavor Diatchki wrote:
> > During our Haskell Prime lunch meeting at ICFP, I promised to create a
> detailed
> > step-by-step guide for creating Haskell Prime proposals on GitHub.  The
> > instructions are now available here:
> >
> >  https://github.com/yav/rfcs/blob/instructions/step-by-
> step-instructions.md
> >
> > Please have a look and let me know if something is unclear, or if I
> misunderstood
> > something about the process.
>
> The target audience for this document is someone who is unfamiliar with
> Git and
> Github, which we should make clear at the beginning. As an experienced
> user, it
> left me searching for relevant information among all those sub-lists to
> find out
> that it really just is about opening a pull request containing a template.
> We
> might provide a link to the document in the process section [1] of the
> current
> README if others think this amount of detail helps lowering the barrier of
> entry.
>
> One thing we should also mention somewhere is to please provide a link to
> the
> rendered version of the proposal in the ticket, because Git diffs are in a
> very
> reader-unfriendly format.
>
> Greetings,
> David
>
> [1]: https://github.com/yav/rfcs/tree/instructions#proposal-process
>
>
> --
> My GPG keys: https://keybase.io/quchen
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Step-by-step guide for creating a new proposal

[Iavor Diatchki]

Hello,

During our Haskell Prime lunch meeting at ICFP, I promised to create a
detailed step-by-step guide for creating Haskell Prime proposals on
GitHub.  The instructions are now available here:

 https://github.com/yav/rfcs/blob/instructions/step-by-step-instructions.md

Please have a look and let me know if something is unclear, or if I
misunderstood something about the process.

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

Re: minutes from committee meeting at ICFP

[Iavor Diatchki]

Hello,

I just got back to the US, and have started uploading videos in earnest.
Hopefully, I'll get to the Haskell Symposium pretty soon, and the whole
discussion was recorded so that everyone can listen to it.   I started
taking notes at the beginning of the discussion, but then got distracted,
so my notes didn't end up terribly useful.

-Iavor





On Tue, Sep 27, 2016 at 10:10 AM, Richard Eisenberg 
wrote:

> I recall that Iavor took notes from the podium. Iavor?
>
> > On Sep 27, 2016, at 12:58 PM, Ben Gamari  wrote:
> >
> > Richard Eisenberg  writes:
> >
> >> Below are the minutes from last week’s in-person meeting at ICFP among
> >> the attending members of the Haskell Prime committee. The conversation
> >> moved swiftly, and I’ve done my best at capturing the essence of
> >> attendees’ comments. The attendees have had a week to consider these
> >> notes with no suggestions submitted; I thus consider these notes
> >> ratified.
> >>
> > Did anyone take notes from Iavor's Status of Haskell discussion during
> > the Symposium? There were a few points brought up there that shouldn't
> > be forgotten.
> >
> > Cheers,
> >
> > - Ben
> >
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: GHC Performance / Replacement for R?

[Iavor Diatchki]

Hello,

when you parse the CSV fully, you end up creating a lot of small bytestring
objects, and each of these adds some overhead.   The vectors themselves add
up some additional overhead.  All of this adds up when you have as many
fields as you do.   An alternative would be to use a different
representation for the data, which recomputes things when needed.   While
this might be a bit slower in some cases, it could have significant saving
in terms of memory use.   I wrote up a small example to illustrate what I
have in mind, which should be attached to this e-mail.

Basically, instead of parsing the CSV file fully, I just indexed where the
lines are (ref. the "rows" field of "CSV").  This allows me to access each
row quickly, and the when I need to get a specific field, I simply parse
the bytes of the row.
One could play all kinds of games like that, and I imagine R does something
similar, although I have never looked at how it works.   To test the
approach I generated ~200Mb of sample data (generator is also in the
attached file), and I was able to filter it using ~240Mb, which is
comparable to what you reported about R.  One could probably package all
this up in library that supports "R like" operations.

These are the stats I get from -s:

   4,137,632,432 bytes allocated in the heap
 925,200 bytes copied during GC
 200,104,224 bytes maximum residency (2 sample(s))
   6,217,864 bytes maximum slop
 246 MB total memory in use (1 MB lost due to fragmentation)

 Tot time (elapsed)  Avg pause  Max
pause
  Gen  0  7564 colls, 0 par0.024s   0.011s 0.s
 0.0001s
  Gen  1 2 colls, 0 par0.000s   0.001s 0.0003s
 0.0006s

  INITtime0.000s  (  0.000s elapsed)
  MUT time0.364s  (  0.451s elapsed)
  GC  time0.024s  (  0.011s elapsed)
  EXITtime0.000s  (  0.001s elapsed)
  Total   time0.388s  (  0.463s elapsed)

  %GC time   6.2%  (2.5% elapsed)

  Alloc rate11,367,122,065 bytes per MUT second

  Productivity  93.8% of total user, 78.6% of total elapsed

-Iavor




On Thu, Aug 25, 2016 at 3:31 AM, Simon Peyton Jones via
Glasgow-haskell-users  wrote:

> Sounds bad.  But it'll need someone with bytestring expertise to debug.
> Maybe there's a GHC problem underlying; or maybe it's shortcoming of
> bytestring.
>
> Simon
>
> |  -Original Message-
> |  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> |  boun...@haskell.org] On Behalf Of Dominic Steinitz
> |  Sent: 25 August 2016 10:11
> |  To: GHC users 
> |  Subject: GHC Performance / Replacement for R?
> |
> |  I am trying to use Haskell as a replacement for R but running into two
> |  problems which I describe below. Are there any plans to address the
> |  performance issues I have encountered?
> |
> |   1. I seem to have to jump through a lot of hoops just to be able to
> |  select the data I am interested in.
> |
> |  {-# LANGUAGE ScopedTypeVariables #-}
> |
> |  {-# OPTIONS_GHC -Wall #-}
> |
> |  import Data.Csv hiding ( decodeByName )
> |  import qualified Data.Vector as V
> |
> |  import Data.ByteString ( ByteString )
> |  import qualified Data.ByteString.Char8 as B
> |
> |  import qualified Pipes.Prelude as P
> |  import qualified Pipes.ByteString as Bytes import Pipes import
> |  qualified Pipes.Csv as Csv import System.IO
> |
> |  import qualified Control.Foldl as L
> |
> |  main :: IO ()
> |  main = withFile "examples/787338586_T_ONTIME.csv" ReadMode $ \h -> do
> |let csvs :: Producer (V.Vector ByteString) IO ()
> |csvs = Csv.decode HasHeader (Bytes.fromHandle h) >-> P.concat
> |uvectors :: Producer (V.Vector ByteString) IO ()
> |uvectors = csvs  >-> P.map (V.foldr V.cons V.empty)
> |vec_vec <- L.impurely P.foldM  L.vector uvectors
> |print $ (vec_vec :: V.Vector (V.Vector ByteString)) V.! 17
> |print $ V.length vec_vec
> |let rockspring = V.filter (\x -> x V.! 8 == B.pack "RKS") vec_vec
> |print $ V.length rockspring
> |
> |  Here's the equivalent R:
> |
> |  df <- read.csv("787338586_T_ONTIME.csv")
> |  rockspring <- df[df$ORIGIN == "RKS",]
> |
> |   2. Now I think I could improve the above to make an environment that
> |  is more similar to the one my colleagues are used to in R but more
> |  problematical is the memory usage.
> |
> |   * 112.5M file
> |   * Just loading the source into ghci takes 142.7M
> |   * > foo <- readFile "examples/787338586_T_ONTIME.csv" > length foo
> | takes me up to 4.75G. But we probably don't want to do this!
> |   * Let's try again.
> |   * > :set -XScopedTypeVariables
> |   * > h <- openFile "examples/787338586_T_ONTIME.csv" ReadMode
> |   * > let csvs :: Producer (V.Vector ByteString) IO () = Csv.decode
> |  HasHeader (Bytes.fromHandle h) >-> P.concat
> |   * > let uvectors :: Producer (V.Vector ByteString) IO () = csvs  >->

Re: Proposal process status

[Iavor Diatchki]

Hello Ben,

I posted this when you originally asked for feed-back, but perhaps it
got buried among the rest of the e-mails.

I think the proposal sounds fairly reasonable, but it is hard to say how
well it will work in practice until we try it, and we should be ready to
change it if needs be.

Some clarifying questions on the intended process:
   1.  After submitting the initial merge request, is the person making the
proposal to wait for any kind of acknowledgment, or just move on to step 2?
   2. Is the discussion going to happen on one of the mailing lists, if so
which?   Is it the job of the proposing person to involve/notify the
committee about the discussion?  If so, how are they to find out who is on
the committee?
   3. How does one actually perform step 3, another pull request or simply
an e-mail to someone?

Typo: two separate bullets in the proposal are labelled as 4.

Cheers,
-Iavor

On Wed, Jul 20, 2016 at 2:36 AM, Ben Gamari  wrote:

>
> Hello everyone,
>
> As you hopefully know, a few weeks ago we proposed a new process [1] for
> collecting, discussing, and deciding upon changes to GHC and its Haskell
> superset. While we have been happy to see a small contingent of
> contributors join the discussion, the number is significantly smaller
> than the set who took part in the earlier Reddit discussions.
>
> In light of this, we are left a bit uncertain of how to proceed. So,
> we would like to ask you to let us know your feelings regarding the
> proposed process:
>
>   * Do you feel the proposed process is an improvement over the status
> quo?
>
>   * Why? (this needn't be long, just a sentence hitting the major points)
>
>   * What would you like to see changed in the proposed process, if
> anything?
>
> That's all. Again, feel free to reply either on the GitHub pull request
> [1] or this thread if you would prefer. Your response needn't be long;
> we just want to get a sense of how much of the community feels that 1)
> this effort is worth undertaking, and 2) that the proposal before us is
> in fact an improvement over the current state of affairs.
>
> Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ArgumentDo proposal updated

[Iavor Diatchki]

Hello Manuel,

this is exactly the change that is being discussed:  currently a `case`
expression is not considered to be atomic (`aexp`),  which is why it can't
appear in a record update without parens.

The proposed change, as I understand it, is to make `case` (and `do`) into
atomic expressions as they are "parentesized" by the key-word (`case` or
`do`) at the start, and the closing `}` at the end.

Making this change would allow the kind of thing you were expecting, which
to me makes sense.  Others seem to find it confusing :-)

-Iavor




On Wed, Jul 13, 2016 at 10:35 AM, Manuel Gómez  wrote:

> On Wed, Jul 13, 2016 at 5:42 AM, C Maeder  wrote:
> > seeing
> >
> >  aexp -> qvar  (variable)
> >   |  gcon  (general constructor)
> >   ...
> >   |  qcon { fbind1 … fbindn }  (labeled construction)
> >   |  aexp { fbind1 … fbindn }  (labelled update)
> >
> > and
> >
> https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003
> >
> > I realise that the update requires at least one field binding whereas
> > for a construction "C {}" (n = 0) could be used.  ("C {}" makes sense
> > for patterns!)
> >
> > And due to the meta-rule a labelled update is not possible for a lambda
> > abstraction, let expression, or conditional (as aexp), but it is for
> > case (and do if the record type happens to be a monad). So a further
> > less obvious example is:
> >
> >   case e of
> > p -> r
> >   { f = v }
> >
> > that will be parsed as: (case e of p -> r) { f = v }
> >
> > (I'm sure the grammar could be fully disambiguated, but this would not
> > improve readability. Preferring shift over reduce is common and fine for
> > such cases.)
>
> Upon reading this example, I believed this to be simply a matter of
> the layout rule.
>
>   case e of
> p -> r
>   { f = v }
>
> would become
>
>   case e of {
> p -> r
>   } { f = v }
>
> This, on the other hand
>
>   case e of p -> r { f = v }
>
> would be equivalent to
>
>   case e of { p -> (r { f = v }) }
>
> I just tested this after writing the preceding as I was confused about
> what you found confusing, and I am surprised that the example you
> showed does indeed yield a parse error.  I very much expected this to
> be valid Haskell:
>
>   data X = X { x :: Bool }
>   someX = X True
>
>   foo =
> case () of
>   _ -> someX
> { x = False }
>
> Am I alone in my surprise?
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Rethinking GHC's approach to managing proposals

[Iavor Diatchki]

Hello,

I think this sounds fairly reasonable, but it is hard to say how well it
will work in practice until we try it.

Some clarifying questions on the intended process:
   1.  After submitting the initial merge request, is the person making the
proposal to wait for any kind of acknowledgment, or just move on to step 2?
   2. Is the discussion going to happen on one of the mailing lists, if so
which?   Is it the job of the proposing person to involve/notify the
committee about the discussion?  If so, how are they to find out who is on
the committee?
   3. How does one actually perform step 3, another pull request or simply
an e-mail to someone?

Typo: two separate bullets in the proposal are labelled as 4.

Cheers,
-Iavor







On Mon, Jul 11, 2016 at 2:36 PM, Simon Peyton Jones via
Glasgow-haskell-users  wrote:

> Just to be clear:
>
> * We are actively seeking feedback about the proposal [4] below.
>   It's not a fait-accompli.
>
> * You can join the dialogue by (a) replying to this email,
>   (b) via the "Conversations" tab of [4], namely
>   https://github.com/ghc-proposals/ghc-proposals/pull/1
>   Doubtless via reddit too!
>
>   If you don't like something, the more specific and concrete you
>   can be about a better alternative, the better.  E.g. Richard's
>   comments on the "conversations" tab both ask questions and propose
>   answers.  Bravo!
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben
> | Gamari
> | Sent: 09 July 2016 21:46
> | To: GHC developers ; ghc-users  | us...@haskell.org>
> | Subject: Rethinking GHC's approach to managing proposals
> |
> | Hello everyone,
> |
> | Recently there has been a fair bit of discussion[1,2] around the
> | mechanisms by which proposed changes to GHC are evaluated. While we have
> | something of a formal proposal protocol [3], it is not clearly
> | documented, inconsistently applied, and may be failing to serve a
> | significant fraction of GHC's potential contributor pool.
> |
> | Over the last few weeks, I have been doing a fair amount of reading,
> | thinking, and discussing to try to piece together a proposal scheme
> | which better serves our community.
> |
> | The resulting proposal [4] is strongly inspired by the RFC process in
> | place in the Rust community [5], the leaders of which have thought quite
> | hard about fostering community growth and participation. While no
> | process is perfect, I feel like the Rust process is a good starting
> | point for discussion, offering enough structure to guide new
> | contributors through the process while requiring only a modest
> | investment of developer time.
> |
> | To get a sense for how well this will work in our community, I propose
> | that we attempt to self-host the proposed process. To this end I have
> | setup a ghc-proposals repository [6] and opened a pull request for
> | discussion of the process proposal [4].
> |
> | Let's see how this goes.
> |
> | Cheers,
> |
> | - Ben
> |
> |
> | [1]
> | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
> | dit.com%2fr%2fhaskell%2fcomments%2f4oyxo2%2fblog_contributing_to_ghc%2f&
> | data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a6608
> | d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1=Hl6GqRWfu7IOQtpE
> | jpfsNAkv3mmLgNKm2ciQDoMe6HA%3d
> | [2]
> | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red
> | dit.com%2fr%2fhaskell%2fcomments%2f4isua9%2fghc_development_outsidein%2f
> | =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a660
> | 8d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1=bj2AQqQirX3X%2f
> | 4%2fFr05eXFuD4yW0r9Nmrmdg7IGEF%2f8%3d
> | [3]
> | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
> | [4] https://github.com/ghc-proposals/ghc-
> | proposals/pull/1/files?short_path=14d66cd#diff-
> | 14d66cda32248456a5f223b6333c6132
> | [5] https://github.com/rust-lang/rfcs
> | [6] https://github.com/ghc-proposals/ghc-proposals
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Proposal: ArgumentDo

[Iavor Diatchki]

Hello,

while  we are voting here, I kind of like this proposal, so +1 for me.

I understand that some of the examples look strange to Haskell old-timers
but, as Joachim points out, the behavior is very consistent.   Besides, the
"Less Obvious Examples" were selected so that they are, well, less obvious.
  The common use cases (as in ticket #10843) seem quite appealing, at least
to me, and not at all confusing.  But, then, I also like the
records-with-no-parens notation :-)

-Iavor



On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard 
wrote:

> -1 for same reasons.
>
> On 8 July 2016 at 14:00, Henrik Nilsson 
> wrote:
>
>> Hi all,
>>
>> Joachim Breitner wrote:
>>
>> > Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:
>> > > I don't think so: https://ghc.haskell.org/trac/ghc
>> > /wiki/ArgumentDo#Bl
>> > [...]
>> > Where is the outer set of parenthesis coming from?
>> >
>> > This is all not related to the ArgumentDo notation. Note that [...]
>>
>> The very fact that that experts can't easily agree on how a small
>> Haskell fragment is parsed to me just confirms that Haskell already
>> is a syntactically very cumbersome language.
>>
>> The present proposal just makes matters worse. For that reason
>> alone, I don't find it compelling at all. (So -1 from me, then.)
>>
>> I will not repeat the many other strong arguments against that has been
>> made. But I must say I don't find the use cases as documented
>> on the associated web page compelling at all. Maybe there is a tacit
>> desire to be able to pretend functions are keywords for various
>> creative uses in supporting EDSLs and such. But for that to be truly
>> useful, one need to support groups of related keywords. Something
>> like Agda's mixfix syntax springs to mind. But this proposal does
>> not come close, so the benefits are minimal and the drawbacks large.
>>
>> As a final point, the inherent asymmetry of the proposal (the
>> last argument position is special as, for certain kinds of
>> expressions, parentheses may be omitted there but not elsewhere)
>> is also deeply unsettling.
>>
>> Best,
>>
>> /Henrik
>>
>> --
>> Henrik Nilsson
>> School of Computer Science
>> The University of Nottingham
>> n...@cs.nott.ac.uk
>>
>>
>>
>>
>> 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.
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
> --
> *Λ\oïs*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Limber separators

[Iavor Diatchki]

On Sat, May 7, 2016 at 1:44 AM, Jon Fairbairn 
wrote:

>
>
> The one this violates is “never make language design decisions
> to work around deficiencies in tools” The problem is that diff
> does its work in ignorance of the syntax and consequently
> produces poor results.
>
>
I think that this is an excellent principle that we should uphold.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Scope of committee (can we do *new* things?)

[Iavor Diatchki]

I disagree that we should be standardizing language features that have not
been implemented.

I think having an implementation is important because:
   1. the act of implementing a feature forces you to work out details that
you may not have thought of ahead of time.  For example, for a small
syntactic extension, the implementation would have to work out how to fit
it in the grammar, and how to present the new feature in, say, error
messages.
   2. having an implementation allows users to try out the extension and
gain some empirical evidence that the extension is actually useful in
practice (this is hard to quantify, I know, but it is even harder if you
can't even use the extension at all).

If some feature ends up being particularly useful, it could always be
standardized in the next iteration of the language, when we've gained some
experience using it in practice.

-Iavor



On Wed, May 11, 2016 at 11:17 AM, John Wiegley 
wrote:

> > Gershom B  writes:
>
> > While such changes should definitely be in scope, I do think that the
> proper
> > mechanism would be to garner enough interest to get a patch into GHC
> > (whether through discussion on the -prime list or elsewhere) and have an
> > experimental implementation, even for syntax changes, before such
> proposals
> > are considered ready for acceptance into a standard as such.
>
> Just a side note: This is often how the C++ committee proceeds as well: a
> language proposal with an experimental implementation is given much higher
> credence than paperware. However, they don't exclude paperware either.
>
> So I don't think we need to rely on implementation before considering a
> feature we all want, but I do agree that seeing a patch in GHC first allows
> for much testing and experimentation.
>
> --
> John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: The GADT debate

[Iavor Diatchki]

Hello,

what is the state with the semantic specification of GADTs?  I am wondering
if they fit in the usual CPO-style semantics for Haskell, or do we need
some more exotic mathematical structure to give semantics to the language.

-Iavor




On Sun, May 8, 2016 at 8:36 AM, Carter Schonwald  wrote:

>
>
> On Sunday, May 8, 2016, Richard Eisenberg  wrote:
>
>>
>> On May 7, 2016, at 11:05 PM, Gershom B  wrote:
>> >
>> > an attempt (orthogonal to the prime committee at first) to specify an
>> algorithm for inference that is easier to describe and implement than
>> OutsideIn, and which is strictly less powerful. (And indeed whose
>> specification can be given in a page or two of the report).
>>
>> Stephanie Weirich and I indeed considered doing such a thing, which
>> conversation was inspired by my joining the Haskell Prime committee. We
>> concluded that this would indeed be a research question that is, as yet,
>> unanswered in the literature. The best we could come up with based on
>> current knowledge would be to require type signatures on:
>>
>> 1. The scrutinee
>> 2. Every case branch
>> 3. The case as a whole
>>
>> With all of these type signatures in place, GADT type inference is indeed
>> straightforward. As a strawman, I would be open to standardizing GADTs with
>> these requirements in place and the caveat that implementations are welcome
>> to require fewer signatures. Even better would be to do this research and
>> come up with a good answer. I may very well be open to doing such a
>> research project, but not for at least a year. (My research agenda for the
>> next year seems fairly solid at this point.) If someone else wants to
>> spearhead and wants advice / a sounding board / a less active co-author, I
>> may be willing to join.
>>
>> Richard
>
>
>
> This sounds awesome.  One question I'm wondering about is what parts of
> the type inference problem aren't part of the same challenge in equivalent
> dependent data types? I've been doing some Intersting stuff on the latter
> front recently.
>
> It seems that those two are closely related, but I guess there might be
> some complications in Haskell semantics for thst? And or is this alluded to
> in existing work on gadts?
>
>
>
>> ___
>> Haskell-prime mailing list
>> Haskell-prime@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: RFC: Removing the `-hb` profiling option

[Iavor Diatchki]

I think that biographical profiling is quite nice! I wouldn't say that it
is *more* useful than other modes of profiling, but it is certainly
complementary, and helps give you an idea of what's going on.

So I'd very much vote for fixing it rather than removing it.

-Iavor

On Fri, May 6, 2016 at 2:04 AM, Erik de Castro Lopo 
wrote:

> Hi all,
>
> After a bit of rather tedious and frustrating debugging I came to the
> realisation that the code for the `-hb` profiling option is not thread
> safe. See https://ghc.haskell.org/trac/ghc/ticket/12019
>
> This gives us an opportunity to simply remove it instead of fixing it.
> If there is anyone that thinks this future is really useful (ie more
> useful than the other profiling modes) then I'm willing to fix it.
> But if noone would miss it. I'd much rather remove it.
>
> Thoughts?
>
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: Are there GHC extensions we'd like to incorporate wholesale?

[Iavor Diatchki]

Hello,

I think it'd be great to get started by specifying a few simple extensions,
such as the ones Lennart listed.  Even though they are very well
understood, and we have text about them in the GHC manual, we'd still have
to think of how to integrate their descriptions with the rest of the
report, and actually write the text.

I'd be happy to start working on any of these as soon as we've decided what
tools we'd like to use---I didn't follow the other thread closely, and I'd
be happy to use whatever people are comfortable with (as long as it works
on Linux, but I can't imagine that would be an issue).

-Iavor



On Tue, May 3, 2016 at 1:57 AM, Augustsson, Lennart <
lennart.augusts...@sc.com> wrote:

> Then I suggest we keep EmptyDataDecls!
>
> -Original Message-
> From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
> Sent: 03 May 2016 09:50
> To: Augustsson, Lennart
> Cc: John Wiegley; haskell-prime@haskell.org
> Subject: Re: Are there GHC extensions we'd like to incorporate wholesale?
>
> On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:
>
> > I'd say there are extensions we should just adopt wholesale, but they
> > are all of a very simple syntactic kind.
> >
> > E.g., EmptyDataDecls
>
> Btw, I have no idea why EmptyDataDecls keeps getting proposed for
> inclusion in the next report: `EmptyDataDecls` is one of the extensions
> that went into Haskell2010! :-)
>
> To quote Haskell2010, Ch. 12:
>
> | Those implementations are also encouraged to support the following
> | named language features:
> |
> | - PatternGuards,
> | - NoNPlusKPatterns,
> | - RelaxedPolyRec,
> | - EmptyDataDecls,
> | - ForeignFunctionInterface
> |
> | These are the named language extensions supported by some pre-Haskell
> | 2010 implementations, that have been integrated into this report.
>
>
> There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so
>
>  {-# LANGUAGE Haskell2010 #-}
>
> is not equivalent to
>
>  {-# LANGUAGE Haskell98,
>   PatternGuards, NoNPlusKPatterns, RelaxedPolyRec,
>   EmptyDataDecls, ForeignFunctionInterface #-}
>
> But surprisingly this kind of information seems hard to find in the
> H2010 report.
>
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market
> commentary has been prepared by sales and/or trading desk of Standard
> Chartered Bank or its affiliate. It is not and does not constitute research
> material, independent research, recommendation or financial advice. Any
> market commentary is for information purpose only and shall not be relied
> for any other purpose, and is subject to the relevant disclaimers available
> at
> http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx
>
> Insofar as this e-mail contains the term sheet for a proposed transaction,
> by responding affirmatively to this e-mail, you agree that you have
> understood the terms and conditions in the attached term sheet and
> evaluated the merits and risks of the transaction. We may at times also
> request you to sign on the term sheet to acknowledge in respect of the same.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Ambiguity check and type families

[Iavor Diatchki]

Hi,

that's an interesting example.  To me this looks like a bug in GHC,
although the issue is certainly a bit subtle.

The reason I think it is a bug is that, if we name all the type functions
in the signature and apply improvements using the fact that we are working
with functions, then we get:

x :: (F a ~ b, G b ~ a) = b
x = undefined

Now, this should be equivalent, and it is quite clear that there is no
ambiguity here, as the `b` determines the `a` via the `G`.   Interestingly,
GHC accepts the program in this form.  Also, if you ask it for the type of
`x` using `:t` (which means instantiate the type and the generalize it
again), we get another equivalent formulation: `x :: (F (G b) ~ b) = b`,
which is also accepted by GHC.

-Iavor










On Tue, Jun 2, 2015 at 9:28 AM, Wolfgang Jeltsch g9ks1...@acme.softbase.org
 wrote:

 Hi,

 the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1:

  {-# LANGUAGE TypeFamilies #-}
 
  type family F a :: *
 
  type family G b :: *
 
  x :: G (F a) ~ a = F a
  x = undefined

 GHC 7.10.1 reports:

  Could not deduce (F a0 ~ F a)
  from the context (G (F a) ~ a)
bound by the type signature for x :: (G (F a) ~ a) = F a
at Test.hs:7:6-23
  NB: ‘F’ is a type function, and may not be injective
  The type variable ‘a0’ is ambiguous
  In the ambiguity check for the type signature for ‘x’:
x :: forall a. (G (F a) ~ a) = F a
  To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
  In the type signature for ‘x’: x :: G (F a) ~ a = F a

 At a first look, this complaint seems reasonable, and I have already
 wondered why GHC 7.8.3 actually accepts the above code.

 From an intuitive standpoint, however, the code seems actually
 acceptable to me. While it is true that type families are generally not
 injective, it is possible to derive the type a from F a by applying G.

 It would great if this code would be accepted by GHC again and if there
 was a workaround to make it work with GHC 7.10.1. At the moment, this
 change in the type checker from 7.8.3 to 7.10.1 breaks the
 incremental-computing package in a rather fundamental way.

 All the best,
 Wolfgang

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

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

Re: Recursion on TypeNats

[Iavor Diatchki]

Hello,

actually type-level integers are easier to work with than type-level
naturals (e.g., one can cancel things by subtracting at will).   I agree
that ideally we want to have both integers and naturals (probably as
separate kinds).  I just don't know what notation to use to distinguish the
two.

-Iavor



On Mon, Oct 27, 2014 at 2:13 PM, Barney Hilken b.hil...@ntlworld.com
wrote:

 Ok, I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/9731

 Unfortunately I don't know enough about ghc internals to try implementing
 it.

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker plugins

[Iavor Diatchki]

Hi,

It shouldn't be hard to do the merge, but I am not sure that I'll have time
to do it before the weekend---I'll give it a go then.

-Iavor

On Tue, Oct 21, 2014 at 9:40 AM, Adam Gundry a...@well-typed.com wrote:

 Thanks Iavor, this is really helpful!

 If you have a moment to merge Simon's more recent changes on
 wip/new-flatten-skolems-Aug14, I'm keen to try out the new
 unflattening... or I can have a go at the merge if it would help?

 You may be right that flattened constraints are easier to work with in
 some cases, so it would be great if the plugin could choose which it
 sees. Unfortunately I'm not sure we can easily unflatten *some*
 constraints, given the way unflattening will work in the new
 getInertUnsolved. One option might be for tcPluginSolve to be called in
 both places, with a boolean parameter.

 Cheers,

 Adam


 On 18/10/14 23:33, Iavor Diatchki wrote:
  Hello,
 
  Just a heads up, if anyone is playing around with this:  I just updated
  the plugin interface a bit.
 
  Here are the changes:
 - A plugin now gets 3 sets of constraints: given, derived, and wanted
  (in that order)
 - Plugins are now also presented with dictionary constraints (i.e.,
  you may see equalities, function equalities, and dictionaries)
 - A plugin does not need to return all constraints that need to be
  put back in the inert set.  This is both simpler and more efficient, I
  think.  So, now a plugin can return one of these two results:
- All is good:  plugin returns some solved constraints, and some
  new constraints to be processed by the constraint solver. The solved
  constraints are removed from the inert set, and their evidence variables
  are defined.  The new work is added to the work list.
- Found contradiction: plugin returns a list of the conflicting
  constraint; these are removed from the inert set, and re-added as
  insoluable.
 
  Happy hacking,
  -Iavor
 
 
 
 
 
 
  On Fri, Oct 17, 2014 at 3:36 PM, Iavor Diatchki
  iavor.diatc...@gmail.com mailto:iavor.diatc...@gmail.com wrote:
 
  Hello,
 
  On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry a...@well-typed.com
  mailto:a...@well-typed.com wrote:
 
 
 
  One problem I've run into is transforming the flattened
  CFunEqCans into
  unflattened form (so the flatten-skolems don't get in the way of
  AG-unification). Do you know if there is an easy way to do this,
  or do I
  need to rebuild the tree manually in the plugin?
 
 
  One thing that occurred to me about this:  when constraints are
  flattened,
  it is easy for a plugin to pick-out only the one that it cares
  about.  If things were fully
  unflattened, this would not be the case... For example, if I have a
  constraint:
 
  (2 + F a) ~ F a + F a
 
  In the flattened form, this will become:
  (F a ~ f1, 2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~ f3)
 
  So, the type-nats plugin would pick out: (2 + f1 ~ f2, f1 + f2 ~ f3,
  f2 ~ f3),
  and ignore (F a ~ f1), as it knows nothing about arbitrary type
  functions.
 
  So, if we want to do un-flattening, I think we should do it only on
  those constraints
  that are of interest to the plugin.
 
 
 
 
  Also, I notice that you are providing only equality constraints
  to the
  plugin. Is there any reason we can't make other types of
 constraint
  available as well? For example, one might want to introduce a
  typeclass
  with a special solution strategy (cf. Coercible, or the Has
 class in
  OverloadedRecordFields).
 
 
  Yeah, we should probably pass-in all constraints, inlcluding derived
  ones.
  The reason it is not like that is pretty much historical now.
  So I'll have a go at making this change.
 
  -Iavor
 
 
 
 
 
 
 
 - As an example, I've extracted my work on using an SMT
 solver at the
   type level as a separate plugin:
  
 https://github.com/yav/type-nat-solver
  
  - To see how to invoke a module that uses a plugin, have a
 look in
   `examples/A.hs`.
(Currently, the plugin assumes that you have `cvc4`
 installed and
   available in the path).
  
   - Besides this, we don't have much documentation yet.  For
 hackers:
   we tried to use `tcPlugin` on
   `TcPlugin` in the names of all things plugin related, so
 you could
   grep for this.  The basic API
types and functions are defined in `TcRnTypes` and
 `TcRnMonad`.
  
   Happy hacking,
   -Iavor

 --
 Adam Gundry, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker plugins

[Iavor Diatchki]

Hello,

Just a heads up, if anyone is playing around with this:  I just updated the
plugin interface a bit.

Here are the changes:
   - A plugin now gets 3 sets of constraints: given, derived, and wanted
(in that order)
   - Plugins are now also presented with dictionary constraints (i.e., you
may see equalities, function equalities, and dictionaries)
   - A plugin does not need to return all constraints that need to be put
back in the inert set.  This is both simpler and more efficient, I think.
So, now a plugin can return one of these two results:
  - All is good:  plugin returns some solved constraints, and some new
constraints to be processed by the constraint solver. The solved
constraints are removed from the inert set, and their evidence variables
are defined.  The new work is added to the work list.
  - Found contradiction: plugin returns a list of the conflicting
constraint; these are removed from the inert set, and re-added as
insoluable.

Happy hacking,
-Iavor






On Fri, Oct 17, 2014 at 3:36 PM, Iavor Diatchki iavor.diatc...@gmail.com
wrote:

 Hello,

 On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry a...@well-typed.com wrote:



 One problem I've run into is transforming the flattened CFunEqCans into
 unflattened form (so the flatten-skolems don't get in the way of
 AG-unification). Do you know if there is an easy way to do this, or do I
 need to rebuild the tree manually in the plugin?


 One thing that occurred to me about this:  when constraints are
 flattened,
 it is easy for a plugin to pick-out only the one that it cares about.  If
 things were fully
 unflattened, this would not be the case... For example, if I have a
 constraint:

 (2 + F a) ~ F a + F a

 In the flattened form, this will become:
 (F a ~ f1, 2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~ f3)

 So, the type-nats plugin would pick out: (2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~
 f3),
 and ignore (F a ~ f1), as it knows nothing about arbitrary type functions.

 So, if we want to do un-flattening, I think we should do it only on those
 constraints
 that are of interest to the plugin.




 Also, I notice that you are providing only equality constraints to the
 plugin. Is there any reason we can't make other types of constraint
 available as well? For example, one might want to introduce a typeclass
 with a special solution strategy (cf. Coercible, or the Has class in
 OverloadedRecordFields).


 Yeah, we should probably pass-in all constraints, inlcluding derived ones.
 The reason it is not like that is pretty much historical now.
 So I'll have a go at making this change.

 -Iavor







- As an example, I've extracted my work on using an SMT solver at the
  type level as a separate plugin:
 
https://github.com/yav/type-nat-solver
 
 - To see how to invoke a module that uses a plugin, have a look in
  `examples/A.hs`.
   (Currently, the plugin assumes that you have `cvc4` installed and
  available in the path).
 
  - Besides this, we don't have much documentation yet.  For hackers:
  we tried to use `tcPlugin` on
  `TcPlugin` in the names of all things plugin related, so you could
  grep for this.  The basic API
   types and functions are defined in `TcRnTypes` and `TcRnMonad`.
 
  Happy hacking,
  -Iavor


 --
 Adam Gundry, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker plugins

[Iavor Diatchki]

Hello,

On Thu, Oct 16, 2014 at 3:58 AM, Adam Gundry a...@well-typed.com wrote:



 One problem I've run into is transforming the flattened CFunEqCans into
 unflattened form (so the flatten-skolems don't get in the way of
 AG-unification). Do you know if there is an easy way to do this, or do I
 need to rebuild the tree manually in the plugin?


One thing that occurred to me about this:  when constraints are flattened,
it is easy for a plugin to pick-out only the one that it cares about.  If
things were fully
unflattened, this would not be the case... For example, if I have a
constraint:

(2 + F a) ~ F a + F a

In the flattened form, this will become:
(F a ~ f1, 2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~ f3)

So, the type-nats plugin would pick out: (2 + f1 ~ f2, f1 + f2 ~ f3, f2 ~
f3),
and ignore (F a ~ f1), as it knows nothing about arbitrary type functions.

So, if we want to do un-flattening, I think we should do it only on those
constraints
that are of interest to the plugin.




 Also, I notice that you are providing only equality constraints to the
 plugin. Is there any reason we can't make other types of constraint
 available as well? For example, one might want to introduce a typeclass
 with a special solution strategy (cf. Coercible, or the Has class in
 OverloadedRecordFields).


Yeah, we should probably pass-in all constraints, inlcluding derived ones.
The reason it is not like that is pretty much historical now.
So I'll have a go at making this change.

-Iavor







- As an example, I've extracted my work on using an SMT solver at the
  type level as a separate plugin:
 
https://github.com/yav/type-nat-solver
 
 - To see how to invoke a module that uses a plugin, have a look in
  `examples/A.hs`.
   (Currently, the plugin assumes that you have `cvc4` installed and
  available in the path).
 
  - Besides this, we don't have much documentation yet.  For hackers:
  we tried to use `tcPlugin` on
  `TcPlugin` in the names of all things plugin related, so you could
  grep for this.  The basic API
   types and functions are defined in `TcRnTypes` and `TcRnMonad`.
 
  Happy hacking,
  -Iavor


 --
 Adam Gundry, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker plugins

[Iavor Diatchki]

Hello,

We now have an implementation of type-checker with plugin support.   If you
are interested in trying it out:

  - Checkout and build the `wip/tc-plugins` branch of GHC

  - As an example, I've extracted my work on using an SMT solver at the
type level as a separate plugin:

  https://github.com/yav/type-nat-solver

   - To see how to invoke a module that uses a plugin, have a look in
`examples/A.hs`.
 (Currently, the plugin assumes that you have `cvc4` installed and
available in the path).

- Besides this, we don't have much documentation yet.  For hackers: we
tried to use `tcPlugin` on
`TcPlugin` in the names of all things plugin related, so you could grep
for this.  The basic API
 types and functions are defined in `TcRnTypes` and `TcRnMonad`.

Happy hacking,
-Iavor











On Mon, Oct 6, 2014 at 11:53 AM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 yay :)

 On Mon, Oct 6, 2014 at 2:42 PM, Iavor Diatchki iavor.diatc...@gmail.com
 wrote:

 Hi Adam,

 I am back from vacation, and I think I should have some time to try to
 implement something along these lines.

 Cheers,
 -Iavor

 On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry a...@well-typed.com wrote:

 Hi folks,

 Those of you at HIW last week might have been subjected to my lightning
 talk on plugins for the GHC type checker, which should allow us to
 properly implement nifty features like units of measure or type-level
 numbers without recompiling GHC. I've written up a wiki page summarising
 the idea:

 https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker

 Feedback is very welcome, particularly if (a) you have an interesting
 use for this feature or (b) you think this is a terrible idea!

 Thanks,

 Adam


 --
 Adam Gundry, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/



 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type checker plugins

[Iavor Diatchki]

Hi Adam,

I am back from vacation, and I think I should have some time to try to
implement something along these lines.

Cheers,
-Iavor

On Fri, Sep 12, 2014 at 9:41 AM, Adam Gundry a...@well-typed.com wrote:

 Hi folks,

 Those of you at HIW last week might have been subjected to my lightning
 talk on plugins for the GHC type checker, which should allow us to
 properly implement nifty features like units of measure or type-level
 numbers without recompiling GHC. I've written up a wiki page summarising
 the idea:

 https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker

 Feedback is very welcome, particularly if (a) you have an interesting
 use for this feature or (b) you think this is a terrible idea!

 Thanks,

 Adam


 --
 Adam Gundry, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell] ANN: New version of graphmod (1.2.4)

[Iavor Diatchki]

Hello,

I am pleased to announce a new version of `graphmod`---a program that helps
you visualize the import dependencies between the modules in your Haskell
programs.

The new feature in version 1.2.4 is support for pruning the dependency
graph, which is enabled with the flag -p or --prune-edges.When this
option is selected, `graphmod` will ignore imports to modules that are
already imported by some of the dependencies of the module.

For example, consider the following modules:

module A where { import B; import C }
module B where { import C }
module C where { }

When generated with `--prune-edges`, the resulting graph will be:

A - B - C

Note that there is no edge from `A` to `C`, because `C` is already imported
by `B`.

Happy hacking,
-Iavor
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: Aliasing current module qualifier

[Iavor Diatchki]

Hello,

What semantics are you using for recursive modules?  As far as I see, if
you take a least fixed point semantics (e.g. as described in A Formal
Specification for the Haskell 98 Module System,
http://yav.github.io/publications/modules98.pdf ) this program is incorrect
as the module does not export anything.

While this may seem a bit counter intuitive at first, this semantics has
the benefit of being precise, easily specified, and uniform (e.g it does
not require any special treatment of the  current  module).  As an
example, consider the following variation of your program, where I just
moved the definition in a sperate (still recursive) module:

module A (M.x) where
  import B as M

module B (M.x) where
  import A as M
  x = True

I think that it'd be quite confusing if a single recursive module worked
differently then a larger recursive group, but it is not at all obvious why
B should export 'x'.  And for those who like this kind of puzzle: what
should happen if 'A' also had a definition for 'x'?

Iavor
 On Sep 29, 2014 11:02 PM, John Meacham j...@repetae.net wrote:

 You don't need a new language construct, what i do is:

  module AnnoyinglyLongModuleName (M.length, M.null) where

 import AnnoyinglongLongModuleName as M

 I think ghc would need to be extended a little to make this convienient as
 it doesn't handle recursive module imports as transparently.

 John

 On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery allber...@gmail.com
 wrote:

 On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel h...@gnu.org
 wrote:

 Now it'd be great if I could do the following instead:

 module AnnoyinglyLongModuleName (M.length, M.null) where

 import AnnoyinglyLongModuleName as M -- - does not work


 I think if I wanted this syntax, I'd go for:

 module AnnoyinglyLongModuleName as M where ...

 --
 brandon s allbery kf8nh   sine nomine
 associates
 allber...@gmail.com
 ballb...@sinenomine.net
 unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users




 --
 John Meacham - http://notanumber.net/

 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Iavor Diatchki]

Hello,

this is clearly a bug in GHC:  where `B` and `C` are imported, there should
have been an error, saying that there is a duplicate instance of `Foo Int`.
 If there is no ticket for this already, could you please add one?

-Iavor






On Mon, Aug 11, 2014 at 12:35 PM, Dan Doel dan.d...@gmail.com wrote:

 On Mon, Aug 11, 2014 at 11:36 AM, Twan van Laarhoven twa...@gmail.com
 wrote:

 To me, perhaps naively, IncoherentInstances is way more scary than
 OverlappingInstances.


 ​It might be a bit naive. Most things that incoherent instances would
 allow are allowed with overlapping instances so long as you partition your
 code into two modules. So unless such a partitioning is impossible,
 overlapping instances are almost as scary as incoherent instances (unless
 the module separation somehow makes it less scary).

 And actually, with the way GHC handles instances, you can get more
 incoherent behavior than incoherent instances allow without enabling any
 extensions, just using modules:

 module A where
   class Foo a where foo :: a

 module B where
   import A
   instance F​
 ​oo Int where foo = 5
   bar :: Int ; bar = foo

 module C where
   import A
   instance Foo Int where foo = 6
   baz :: Int ; baz = foo

 module D where
   import B
   import C

   quux = bar + baz -- 11​
 ​

 --
 ​ Dan​


 ___
 Libraries mailing list
 librar...@haskell.org
 http://www.haskell.org/mailman/listinfo/libraries


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent and intentionally omitted instances

[Iavor Diatchki]

Hello,

Such a pragma sounds useful, and is very much like the fails instance
from the Instance chains paper.  You may also be interested in ticket
#9334 (https://ghc.haskell.org/trac/ghc/ticket/9334), which proposes an
alternative to overlapping instances, and I just updated it to point to
#7775.

-Iavor


On Sun, Aug 10, 2014 at 7:19 AM, Henning Thielemann 
schlepp...@henning-thielemann.de wrote:

 Am 29.07.2014 um 12:02 schrieb Johan Tibell:

  P.S. For e.g. INLINABLE we require that you mention the function name
 next to the pragma (which means that you can e.g. put the pragma after
 the declaration). What's the rationale to not require

 {-# OVERLAPPING Show [Char] #-}

 here? Perhaps it's too annoying to have to repeat the types?


 Once I proposed a pragma for documenting intentionally unimplemented
 instances. In this case there is no instance you can write a pragma in
 front of. Your OVERLAPPING syntax would be conform with the one of
 NOINSTANCE:

 https://ghc.haskell.org/trac/ghc/ticket/7775

 Maybe NOINSTANCE can be reconsidered in the course of the introduction of
 the OVERLAP pragma?


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overlapping and incoherent instances

[Iavor Diatchki]

Hello,

I have no strong feelings about what words we use, but I wanted to point
out that while we are thinking of names, we may want to consider 3 (and not
just 2).  Currently we have:
  * OVERLAPPING:   This instances may overlap existing instances
  * OVERLAPPABLE: This instance may be overlapped by existing instances
  * OVERLAPS:  This instance is both OVERLAPPING and OVERLAPPABLE

Of course, the 3rd one (OVERLAPS) could be replaced by a comma separated
list of the first two, but I could not see how to make this work easily
with GHC's pragmas.  It would not be hard to simply allow 2 pragmas after
the `instance` keyword, but both of those seem rather long.

Either way, I'll keep an eye on the discussion, and would be happy to
change the names if a consesus is reached.

-Iavor













On Tue, Jul 29, 2014 at 9:57 AM, David Thomas davidleotho...@gmail.com
wrote:

 Honestly, I think OVERLAPS and OVERLAPPED are perfectly clear.

 On Tue, Jul 29, 2014 at 9:52 AM, David Feuer david.fe...@gmail.com
 wrote:
  CAN-OVERLAP and CAN-BE-OVERLAPPED are nice and clear. A little long,
 perhaps.
 
  On Tue, Jul 29, 2014 at 12:29 PM, Simon Peyton Jones
  simo...@microsoft.com wrote:
  CAN_OVERLAP and CAN_BE_OVERLAPPED?
 
 
 
  (instead of OVERLAPPING and OVERLAPPABLE)
 
 
 
  Or CAN-OVERLAP, CAN-BE-OVERLAPPED
 
 
 
  That’s ok with me if that’s what you all want!
 
 
 
  Simon
 
 
 
  From: Glasgow-haskell-users
  [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of
 Krzysztof
  Skrzetnicki
  Sent: 29 July 2014 16:56
  To: Brandon Allbery
  Cc: Simon Peyton Jones; Andreas Abel; GHC users; Haskell Libraries
  (librar...@haskell.org); ghc-devs
 
 
  Subject: Re: Overlapping and incoherent instances
 
 
 
  How about CAN_OVERLAP?
 
  --
  Krzysztof
 
  29-07-2014 15:40, Brandon Allbery allber...@gmail.com napisał(a):
 
  On Tue, Jul 29, 2014 at 8:33 AM, Andreas Abel andreas.a...@ifi.lmu.de
  wrote:
 
  +1. I like Niklas' syntax better.  Also OVERLAPPABLE is a horrible word,
  OVERLAPPING sound less formidable (even though it might be slightly less
  accurrate).
 
 
 
  We already get overlap ok in instance-related type errors, so
 OVERLAP_OK
  wouldn't be particularly alien even if it doesn't quite fit in with
 existing
  pragmas.
 
 
 
  --
 
  brandon s allbery kf8nh   sine nomine
 associates
 
  allber...@gmail.com
 ballb...@sinenomine.net
 
  unix, openafs, kerberos, infrastructure, xmonad
 http://sinenomine.net
 
 
  ___
  Libraries mailing list
  librar...@haskell.org
  http://www.haskell.org/mailman/listinfo/libraries
 
 
  ___
  Libraries mailing list
  librar...@haskell.org
  http://www.haskell.org/mailman/listinfo/libraries
 
  ___
  Libraries mailing list
  librar...@haskell.org
  http://www.haskell.org/mailman/listinfo/libraries
 ___
 Libraries mailing list
 librar...@haskell.org
 http://www.haskell.org/mailman/listinfo/libraries

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: positive type-level naturals

[Iavor Diatchki]

Hi Henning,

I see two separate issues that show in what you describe, so it might be
useful to discuss them separately:

1. The first issue is figuring out that `n  + 1` is always at least 1.  As
others have mentioned, GHC currently only does proofs by evaluation,
which is why it gets stuck here.  We are working on connecting more
sophisticated decision procedures with GHC's type checker, and they seem to
work fairly well for these kinds of problems.

2. The second one is about: `KnownNat (n  + 1)`, and should this be implied
by `KnownNat n`, which is more of a design choice.   The current thinking
is that `KnownNat n` asserts that `n` is a concrete number (i.e., a
literal).  So having a `KnownNat` constraint is like having an extra
integer parameter, which is always evaluated, and never a thunk.  Now, `(n
+ 1)` is not a literal, which is why `KnowNat (n + 1)` is not solved.I
think that it would be entirely possible to add more rules for solving
`KnownNat` constraints but there are trade offs.  For example, consider the
following two types:

f1 :: KnownNat (a + b) = ...
f2 :: (KnownNat a, KnownNat b) = ...

The first function will take a single integer parameter, while the second
one will take two, and then add them, which seems like more work.  Of
course, one might hope that in some cases GHC will optimize this away, so
maybe this is not much of an issue.

Then, there is the issue about situations like this:

f3 :: (a + b ~ c, x + y ~ c, KnownNat c) = ...

If we apply the same thinking, we could replace `KnownNat c` with either
`(KnowNat a, KnownNat b)` or with `(KnownNat x, KnownNat y)` and it is not
clear what is the right choice.  Similarly, it is not clear if `KnowNat (a
* b)`, should be replaced by `(KnownNat a, KnownNat b)`:  what if `a` was
0, then we shouldn't need the `KnowNat b` constraint at all.

It is also possible to compromise:  maybe we should simplify things like
`KnownNat (x + 1)` and `KnownNat (x * 2)`, because these do not increase
the number of constraints, and there is never the possibility of ambiguity?
 This might be an interesting direction to explore...


A general comment:  the function `withVec` is fairly tricky because it
introduces vectors whose length is not known statically.  This tends to
require much more advanced tools because one has to do real mathematical
reasoning about abstract values.  Of course, sometimes there is no way
around this, but on occasion one can avoid it.   For example, in the
expression `withVec 1 [2,3,4]` we know exactly the length of the vectors
involved, so there is no reason to resort to using fancy reasoning.  The
problem is that Haskell's list notation does not tell us the length of the
list literal.  One could imagine writing a little quasi-quoter that will
allow us to write things like `[vec| 1, 2, 3, 4]`, which would generate the
correctly sized vector. Then you can append and manipulate these as usual
and GHC will be able to check the types because it only has to work with
concrete numbers.  This is not a great program verification technique, but
it certainly beats having to do it manually :-)

I hope this helps,
-Iavor




















On Sun, Mar 16, 2014 at 5:44 AM, Henning Thielemann 
lemm...@henning-thielemann.de wrote:

 Am 16.03.2014 09:40, schrieb Christiaan Baaij:

  To answer the second question (under the assumption that you want
 phantom-type style Vectors and not GADT-style):


 Now I like to define non-empty vectors. The phantom parameter for the
 length shall refer to the actual vector length, not to length-1, for
 consistency between possibly empty and non-empty vectors.

 I have modified your code as follows:

 {-# LANGUAGE Rank2Types #-}
 {-# LANGUAGE DataKinds #-}
 {-# LANGUAGE KindSignatures #-}
 {-# LANGUAGE ScopedTypeVariables #-}
 {-# LANGUAGE TypeOperators #-}
 {-# LANGUAGE TypeFamilies #-}
 module PositiveNat where

 import Data.Proxy (Proxy(Proxy))
 import GHC.TypeLits
   (Nat, SomeNat(SomeNat), KnownNat, someNatVal, natVal,
type (=), type (+))

 data Vector (n :: Nat) a = Vector a [a]

 withVector ::
forall a b.
a - [a] -
(forall n . (KnownNat n, 1=n) = Vector n a - b) - b
 withVector x xs f =
case someNatVal $ toInteger $ length xs of
   Nothing - error static/dynamic mismatch
   Just (SomeNat (_ :: Proxy m)) - f (Vector x xs :: Vector (m+1) a)

 vecLen :: forall n . KnownNat n = Vector n Integer - Integer
 vecLen _ = natVal (Proxy :: Proxy n)

 --  withVector vecLen [1,2,3,4]
 -- 4


 GHC-7.8 complains with:

 PositiveNat.hs:23:40:
 Could not deduce ((1 GHC.TypeLits.=? (n + 1)) ~ 'True)
 from the context (KnownNat n)
   bound by a pattern with constructor
  SomeNat :: forall (n :: Nat). KnownNat n = Proxy n -
 SomeNat,
in a case alternative
   at PositiveNat.hs:23:13-34
 In the expression: f (Vector x xs :: Vector (m + 1) a)
 In a case alternative:
 Just (SomeNat (_ :: Proxy m))
   - f 

Re: default roles

[Iavor Diatchki]

Hello,

My preference would be for the following design:

1. The default datatypes for roles are Nominal, but programmers can add
annotations to relax this.
2. Generlized newtype deriving works as follows:  we can coerce a
dictionary for `C R` into `C T`, as long as we can coerce the types of all
methods instantiated with `R`, into the corresponding types instantiated
with `T`.  In other words, we are pretending that we are implementing all
methods by using `coerce`.

As far as I can see this safe, and matches what I'd expect as a programmer.
 It also solves the problem with the `Set` example: because `Set` has a
nominal parameter, we cannot coerce `Set Int` into `Set MyAge` and, hence,
we cannot derive an instance of `MyAge` for `HasSet`.  An added benefit of
this approach is that when newtype deriving fails, we can give a nicer
error saying exactly which method causes the problem.

-Iavor






On Mon, Oct 7, 2013 at 6:26 AM, Richard Eisenberg e...@cis.upenn.edu wrote:

 As you may have heard, /roles/ will be introduced with GHC 7.8. Roles are
 a mechanism to allow for safe 0-cost conversions between newtypes and their
 base types. GeneralizedNewtypeDeriving (GND) already did this for class
 instances, but in an unsafe way -- the feature has essentially been
 retrofitted to work with roles. This means that some uses of GND that
 appear to be unsafe will no longer work. See the wiki page [1] or slides
 from a recent presentation [2] for more info.

 [1] : http://ghc.haskell.org/trac/ghc/wiki/Roles
 [2] : http://www.cis.upenn.edu/~eir/papers/2013/roles/roles-slides.pdf

 I am writing because it's unclear what the *default* role should be --
 that is, should GND be allowed by default? Examples follow, but the
 critical issue is this:

 * If we allow GND by default anywhere it is type-safe, datatypes (even
 those that don't export constructors) will not be abstract by default.
 Library writers would have to use a role annotation everywhere they wish to
 declare a datatype they do not want users to be able to inspect. (Roles
 still keep type-*un*safe GND from happening.)

 * If we disallow GND by default, then perhaps lots of current uses of GND
 will break. Library writers will have to explicitly declare when they wish
 to permit GND involving a datatype.

 Which do we think is better?

 Examples: The chief example demonstrating the problem is (a hypothetical
 implementation of) Set:

  module Set (Set) where   -- note: no constructors exported!
 
  data Set a = MkSet [a]
  insert :: Ord a = a - Set a - Set a
  ...

  {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
  module Client where
 
  import Set
 
  newtype Age = MkAge Int deriving Eq
 
  instance Ord Age where
(MkAge a) `compare` (MkAge b) = b `compare` a   -- flip operands,
 reversing the order
 
  class HasSet a where
getSet :: Set a
 
  instance HasSet Int where
getSet = insert 2 (insert 5 empty)
 
  deriving instance HasSet Age
 
  good :: Set Int
  good = getSet
 
  bad :: Set Age
  bad = getSet

 According to the way GND works, `good` and `bad` will have the same
 runtime representation. But, using Set operations on `bad` would indeed be
 bad -- because the Ord instance for Age is different than that for Int, Set
 operations will fail unexpectedly on `bad`. The problem is that Set should
 really be abstract, but we've been able to break this abstraction with GND.
 Note that there is no type error in these operations, just wrong behavior.

 So, if we default to *no* GND, then the deriving line above would have
 an error and this problem wouldn't happen. If we default to *allowing* GND,
 then the writer of Set would have to include
  type role Set nominal
 in the definition of the Set module to prevent the use of GND. (Why that
 peculiar annotation? See the linked further reading, above.)

 Although it doesn't figure in this example, a library writer who wishes to
 allow GND in the default-no scenario would need a similar annotation
  type role Foo representational
 to allow it.

 There are clearly reasons for and against either decision, but which is
 better? Let the users decide!

 Discussion time: 2 weeks.

 Thanks!
 Richard

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Desugaring do-notation to Applicative

[Iavor Diatchki]

Hello,

I talked to Simon PJ about this at ICFP, and the use case that I'm
interested in is the one where we infer an `Applicative` constraint instead
of `Monad` for things of the form:

do { x1 - e1; x2 - e2; ...; pure (f x1 x2 ...) }

as long as the `xs` do not appear in the `es`.   I am interested in this
because I find it quite natural when writing `Applicative` computations.

I am less keen on the more complex rules where part of the `do` notation is
translated using the `Applicative` operations and part using `Monad` ones,
mostly because explaining the translation is somewhat complex.  Perhaps it
is worth noting that if we just implemented the simple rule, we could still
gain the benefits of using `Applicative` (e.g., efficiency) in a part of a
monadic `do` by simply nesting the `do` blocks.  For example:

do x1 - e1

   -- The following part is `Applicative`
   (x2,x3) - do x2 - e2 x1
 x3 - e3
 pure (x2,x3)

   f x1 x2 x3

Either way, I think that it'd be nice to have some version of this feature,
thanks for implementing it!

-Iavor



On Tue, Oct 1, 2013 at 1:56 PM, Dag Odenhall dag.odenh...@gmail.com wrote:

 At least Control.Category has RULES that exploit the category laws for
 optimization. Whether this counts as *GHC* making assumptions, I don't
 know. :-)


 On Tue, Oct 1, 2013 at 10:39 PM, Richard Eisenberg e...@cis.upenn.eduwrote:

 The soundness of this desugaring depends on the Applicatives and Monads
 following some of the laws. I think that's OK, personally, but this
 assumption should be made loudly somewhere, and the feature should be
 opt-in. As far as I know, GHC currently makes no assumptions about lawful
 class instances, and it might cause very strange failures if this suddenly
 were to change without opting in.

 Richard

 On Oct 1, 2013, at 9:49 AM, Simon Peyton-Jones wrote:

  What happens when there are some monad things that precede the
 applicative bit:
 
  do { x - e1
; y - e2[x]
; z - e3[x]
; h[y]
... }
 
  does this convert to
 
  do { x - e1
; (y,z) - (,) $ e1 * e2
; h[y]
...
 
  I assume so, but it would be good to say.
 
 
  Also worth noting that join can be used to eliminate the tuple in
 arbitrary contexts, not only ones that end in return.  Eg in the above
 example we can desugar to
 
e1 = \x -
join (\y z - do { h[y]; ... })
e2 e3
 
  I think.  Again worth documenting if so.
 
  I don't know whether the tuple-version or join-version would be more
 optimisation friendly.
 
  Simon
 
  | -Original Message-
  | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
  | boun...@haskell.org] On Behalf Of Simon Marlow
  | Sent: 01 October 2013 13:40
  | To: glasgow-haskell-users
  | Subject: Desugaring do-notation to Applicative
  |
  | Following a couple of discussions at ICFP I've put together a proposal
  | for desugaring do-notation to Applicative:
  |
  |http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
  |
  | I plan to implement this following the addition of Applicative as a
  | superclass of Monad, which is due to take place shortly after the 7.8
  | branch is cut.
  |
  | Please discuss here, and I'll update the wiki page as necessary.
  |
  | Cheers,
  | Simon
  | ___
  | Glasgow-haskell-users mailing list
  | Glasgow-haskell-users@haskell.org
  | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
  ___
  Glasgow-haskell-users mailing list
  Glasgow-haskell-users@haskell.org
  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8 Release Update

[Iavor Diatchki]

Hello,

I think that the simple type nats solver (branch type-nats-simple) is
pretty much ready for merging with HEAD.  Should I go ahead and merge it in?

-Iavor


On Thu, Sep 12, 2013 at 1:18 PM, Austin Seipp aus...@well-typed.com wrote:

 I think this can definitely be clarified. I'll update the docs a
 little later today when I get a chance.

 On Thu, Sep 12, 2013 at 1:35 PM, Simon Peyton-Jones
 simo...@microsoft.com wrote:
  Is this something that could be clarified in GHC's documentation?  Patch?
 
  Simon
 
  |  -Original Message-
  |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
 Kazu
  |  Yamamoto
  |  Sent: 12 September 2013 04:43
  |  To: glasgow-haskell-users@haskell.org; ghc-d...@haskell.org
  |  Subject: Re: 7.8 Release Update
  |
  |  Hi,
  |
  |  Now I understand what is right and why I misunderstood.
  |
  |  - GHC 7.8 provides three kinds of libraries:
  |   - static libraries
  |   - dynamic libraries
  |   - static libraries for profiling
  |  - GHCi uses dynamic libraries.
  |  - Programs complied with GHC 7.8 use static libraries.
  |  - When a library package is complied, both static one and dynamic
  |one are created.
  |  - When -p or --enabling-executable-profiling are specified to
  |cabal, static libraries for profiling are also created and used.
  |
  |  So, we don't have to specify --enable-shared/--disable-shared to
  |  cabal in normal situation.
  |
  |  There is no bug. Just I misunderstood.
  |
  |  * Why did I misunderstand that programs are linked dynamically?
  |
  |  I tried to support GHC 7.8 for doctest. Doctest uses GHCi internally.
  |  At the beginning, doctest cannot pass many tests if --enable-shared
  |  is not specified. This was fixed:
  |
  |   https://github.com/sol/doctest-haskell/issues/58
  |
  |  Now, --enable-shared is not necessary even for doctest.
  |
  |  * Why did I misunderstand that compiling programs for profiling fails?
  |
  |  I specified --ghc-options=-prof -fprof-auto. -prof lets GHC 7.8
  |  to produce both static and dynamic libraries for profiling. This
  |  resulted in build failure.
  |
  |  Right procedure for profiling are:
  |
  |  % cabal install -p --enable-executable-profiling
 --ghc-options=-fprof-auto -j3
  |
  |  or
  |
  |  % cabal install -p --ghc-options=-fprof-auto --only-dependencies -j3
  |  % cabal configure --enable-executable-profiling
  |  % cabal build
  |
  |  --Kazu
  |
  |   On 09/09/13 08:14, Edward Z. Yang wrote:
  |   Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08
  |   19:36:19 -0700 2013:
  |   
  |   % make show VALUE=GhcLibWays
  |   make -r --no-print-directory -f ghc.mk show
  |   GhcLibWays=v p dyn
  |   
  |  
  |   Yes, it looks like you are missing p_dyn from this list. I think
  |   this is a bug in the build system.  When I look at ghc.mk
  |   it only verifies that the p way is present, not p_dyn; and I don't
  |   see any knobs which turn on p_dyn.
  |  
  |   However, I must admit to being a little confused; didn't we abandon
  |   dynamic by default and switch to only using dynamic for GHCi (in
 which
  |   case the profiling libraries ought not to matter)?
  |  
  |   I think Kazu is saying that when he builds something with profiling
  |   using cabal-install, it fails because cabal-install tries to build a
  |   dynamic version too.  We don't want dyanmic/profiled libraries
  |   (there's no point, you can't load them into GHCi).  Perhaps this is
  |   something that needs fixing in cabal-install?
  |  
  |   Cheers,
  |  Simon
  |  
  |  ___
  |  ghc-devs mailing list
  |  ghc-d...@haskell.org
  |  http://www.haskell.org/mailman/listinfo/ghc-devs
  ___
  Glasgow-haskell-users mailing list
  Glasgow-haskell-users@haskell.org
  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 



 --
 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: 7.8 Release Update

[Iavor Diatchki]

Hello Austin,


On Sun, Sep 8, 2013 at 4:27 PM, Austin Seipp ase...@pobox.com wrote:


  * Iavor Diatchki and SPJ are working together on the type-nats-simple
 branch. I believe this will hopefully land in time. Iavor, SPJ - can
 you comment here?


I think we are on track to get this done on time.  The type-nats-simple
branch should be working (at least when I build it with no dynamic
libraries) and up to date with HEAD, and there are some tests in a branched
version of the testuite.

One question:  when I try to validate things, my build fails with this
error:

Reachable modules from DynFlags out of date
Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
Extra modules: BinIface BuildTyCl CoreLint FamInst Finder IOEnv IfaceEnv
LoadIface PrelInfo TcIface TcMType TcRnMonad TcRnTypes TcTypeNats

Any advice on what might be going wrong?

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] TypeLits Typeable

[Iavor Diatchki]

Hi guys,

Yep, we know about this and, I believe, the plan is to add custom rules to
the constraint solver to solve `Typable n` constraints (where n is  a
number or symbol).   Just for the record, the other design choice was to
add instance `Typeable (n :: Symbol)`, but that conflicted with some of the
polymorphic instances already present in the library, so we decided to go
for the custom constraint solver rules.

This should not be hard to do, I just need to sit down and do it---my
current priority has been to catch up the type-nats solver with HEAD and
clean up things for merging.

-Iavor





On Mon, Aug 26, 2013 at 1:19 AM, José Pedro Magalhães j...@cs.uu.nl wrote:

 Hi Nicolas,

 It's not intentional, but Iavor is aware of this, and we want to change it.
 I'm CC-ing him as he might know more about what the current plan is.


 Cheers,
 Pedro


 On Sat, Aug 24, 2013 at 3:20 PM, Nicolas Trangez nico...@incubaid.comwrote:

 Hello Cafe,

 I was playing around with TypeLits in combination with Typeable (using
 GHC 7.7.7.20130812 FWIW), but was surprised to find Symbols aren't
 Typeable, and as such the following doesn't work. Is this intentional,
 or am I missing something?

 Thanks,

 Nicolas

 {-# LANGUAGE DataKinds,
  KindSignatures,
  DeriveFunctor,
  DeriveDataTypeable #-}
 module Main where

 import Data.Typeable
 import GHC.TypeLits

 data NoSymbol n a b = NoSymbol a b
   deriving (Typeable)

 data WithSymbol (n :: Symbol) a b = WithSymbol a b
   deriving (Typeable)

 data Sym
   deriving (Typeable)

 main :: IO ()
 main = do
 print $ typeOf (undefined :: NoSymbol Sym Int Int)

 let d = undefined :: WithSymbol sym Int Int
 {-
 print $ typeOf d

 No instance for (Typeable Symbol sym)
   arising from a use of ‛typeOf’
 -}

 return ()


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell] Job opportunities at Galois

[Iavor Diatchki]

Hello,

Galois is hiring!  We're looking for researchers, principal investigators,
and software engineers, including those with expertise in functional
programming, formal methods, computer security, control systems,
informatics, or networking.

For more information, take a look at http://corp.galois.com/careers and
please feel free to drop me an e-mail if you have questions.

Cheers,
-Iavor
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] [Haskell-cafe] Job opportunities at Galois

[Iavor Diatchki]

Hello,
(Alejandro, sorry for the duplicate message but a couple of folks asked the
same, so I thought I'd reply to the list).

We are looking for people to work at our office (i.e., not remotely).
 Unfortunately, H1B visas have run out for this year, so right now we are
looking for folks who are already eligible to work in the US.

-Iavor


On Thu, Jun 27, 2013 at 9:03 AM, Alejandro Serrano Mena
trup...@gmail.comwrote:

 Hello,
 Are there any specific details to consider when applying? For example, is
 living in the US or having a visa required for application?

 Thanks in advance.


 2013/6/27 Iavor Diatchki iavor.diatc...@gmail.com

 Hello,

 Galois is hiring!  We're looking for researchers, principal
 investigators, and software engineers, including those with expertise in
 functional programming, formal methods, computer security, control systems,
 informatics, or networking.

 For more information, take a look at http://corp.galois.com/careers and
 please feel free to drop me an e-mail if you have questions.

 Cheers,
 -Iavor



 ___
 Haskell-Cafe mailing list
 haskell-c...@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell-cafe] Job opportunities at Galois

[Iavor Diatchki]

Hello,

Galois is hiring!  We're looking for researchers, principal investigators,
and software engineers, including those with expertise in functional
programming, formal methods, computer security, control systems,
informatics, or networking.

For more information, take a look at http://corp.galois.com/careers and
please feel free to drop me an e-mail if you have questions.

Cheers,
-Iavor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Job opportunities at Galois

[Iavor Diatchki]

Hello,
(Alejandro, sorry for the duplicate message but a couple of folks asked the
same, so I thought I'd reply to the list).

We are looking for people to work at our office (i.e., not remotely).
 Unfortunately, H1B visas have run out for this year, so right now we are
looking for folks who are already eligible to work in the US.

-Iavor


On Thu, Jun 27, 2013 at 9:03 AM, Alejandro Serrano Mena
trup...@gmail.comwrote:

 Hello,
 Are there any specific details to consider when applying? For example, is
 living in the US or having a visa required for application?

 Thanks in advance.


 2013/6/27 Iavor Diatchki iavor.diatc...@gmail.com

 Hello,

 Galois is hiring!  We're looking for researchers, principal
 investigators, and software engineers, including those with expertise in
 functional programming, formal methods, computer security, control systems,
 informatics, or networking.

 For more information, take a look at http://corp.galois.com/careers and
 please feel free to drop me an e-mail if you have questions.

 Cheers,
 -Iavor



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: relaxing instance declarations

[Iavor Diatchki]

Hello,

I think that if we want something along those lines, we should consider a
more general construct that allows declarations to scope over other
declarations (like SML's `local` construct).  It would be quite arbitrary
to restrict this only to instances.

-Iavor



On Mon, Apr 29, 2013 at 2:41 PM, Max Bolingbroke batterseapo...@hotmail.com
 wrote:

 You could probably get away with just using two where clauses:

 instance Foo a where
 bar = ...
   where
 auxilliary = ...




 On 28 April 2013 18:42, Edward Kmett ekm...@gmail.com wrote:

 Makes sense. I'm not sure what a good syntactic story would be for that
 feature though. Just writing down member names that aren't in the class
 seems to be too brittle and error prone, and new keywords seems uglier than
 the current situation.

 Sent from my iPad

 On Apr 28, 2013, at 1:24 PM, Doug McIlroy d...@cs.dartmouth.edu wrote:

  Not always. For example, you can't mess with the declaration
  of a standard class, such as Num.
 
  On Sun, Apr 28, 2013 at 12:06 PM, Edward Kmett ekm...@gmail.com
 wrote:
 
  You can always put those helper functions in the class and then just
 not
  export them from the module.
 
  On Sun, Apr 28, 2013 at 10:49 AM, Doug McIlroy d...@cs.dartmouth.edu
 wrote:
 
  Is there any strong reason why the where clause in an instance
  declaration cannot declare anything other than class
  operators? If not, I suggest relaxing the restriction.
 
  It is not unusual for declarations of class operators to
  refer to special auxiliary functions. Under current rules
  such functions have to be declared outside the scope in
  which they are used.
 
  Doug McIlroy

 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime



 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: ImplicitParams and MonoLocalBinds

[Iavor Diatchki]

Hi,
This does not appear to be related to ImplicitParameters, rather
`MonoLocalBinds` is not working as expected.

Here is an example without implicit parameters that compiles just fine, but
would be rejected if `p` was monomorphic:

{-# LANGUAGE NoMonomorphismRestriction, MonoLocalBinds #-}

class C a where
  f :: a - ()

instance C Bool where f = const ()
instance C Char where f = const ()

g = let p = f
in (p 'a', p True)

-Iavor




On Fri, Mar 22, 2013 at 1:39 AM, Roman Cheplyaka r...@ro-che.info wrote:

 The value of the following expression

   let ?y = 2  in
   let  p = ?y in
   let ?y = 1  in
   p

 depends on whether the second binding is generalised.

 MonomorphismRestriction makes it not generalise, hence the value is 2.

 What surprises me is that MonoLocalBinds doesn't have this effect.

   Prelude :set -XImplicitParams -XNoMonomorphismRestriction
 -XMonoLocalBinds
   Prelude let ?y = 2 in let p = ?y in let ?y = 1 in p
   1

 What's going on here?

 Roman

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ImplicitParams and MonoLocalBinds

[Iavor Diatchki]

Hi,

Aha! This page explains what is going on:
http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7

The summary is that the definition of what is local is not what one might
expect:  only things that depend
on variables in scope are considered to be locals, other bindings, that
could be lifted out (e.g., like `p` in both examples)
are not considered local and are generalized.  Of course, with implicit
parameters this is not what one might hope for...

A while back there was a discussion about adding a construct for
monomorphic bindings to the language (I think the proposed notation was
something like x := 2).
Perhaps we should revisit it, it seems much simpler than the rather
surprising behavior of `MonoLocalBinds`.

-Iavor






On Thu, Mar 28, 2013 at 4:39 PM, Iavor Diatchki iavor.diatc...@gmail.comwrote:

 Hi,
 This does not appear to be related to ImplicitParameters, rather
 `MonoLocalBinds` is not working as expected.

 Here is an example without implicit parameters that compiles just fine,
 but would be rejected if `p` was monomorphic:

 {-# LANGUAGE NoMonomorphismRestriction, MonoLocalBinds #-}

 class C a where
   f :: a - ()

 instance C Bool where f = const ()
 instance C Char where f = const ()

 g = let p = f
 in (p 'a', p True)

 -Iavor




 On Fri, Mar 22, 2013 at 1:39 AM, Roman Cheplyaka r...@ro-che.info wrote:

 The value of the following expression

   let ?y = 2  in
   let  p = ?y in
   let ?y = 1  in
   p

 depends on whether the second binding is generalised.

 MonomorphismRestriction makes it not generalise, hence the value is 2.

 What surprises me is that MonoLocalBinds doesn't have this effect.

   Prelude :set -XImplicitParams -XNoMonomorphismRestriction
 -XMonoLocalBinds
   Prelude let ?y = 2 in let p = ?y in let ?y = 1 in p
   1

 What's going on here?

 Roman

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Release plans

[Iavor Diatchki]

Hello,

I think that there are a lot of useful features that are in HEAD that would
be useful to a wider audience than GHC devs, so a release before October
would certainly be useful.  I don't think it is that important if it is
called 7.7.1 or 7.8.1 but I think that it needs to be a fixed version, in
the sense that all code (including GHC libraries) is tagged in the repos
and, possibly, we make an entry for it in the track system, so that people
can record bugs against it.

Given that GHC is very actively developed, it might make sense to have one
of these snapshot releases every 3 or so months, as technology preview,
and without any promises about stability or compatibility (in particular,
they should not be considered for inclusion in the HP or standard Linux
distributions).   This would give us a fairly low over-head middle ground
between the volatility of nightly builds, and the long
time between official releases.

-Iavor



On Wed, Mar 20, 2013 at 10:23 AM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 A 7.7 snapshot would be useful for me in a number of ways:

 a) I often spend some time prior to recent GHC releases trying to build
 all the various major packages, and often send in patches to  maintainers
 during that window (or at least the start of patches). Having a fixed
 snapshot release that maintainers can use to validate any such future
 proofing patches would be tremendously helpful

 b) Theres a bunch of engineering i'm currently up where I want to use some
 of the features very soon, and making it easier for other people to use the
 open source subsets of that engineering sooner rather than later would be
 valuable!

 c) lowering the barrier to folks using and stress testing these features
 may catch problems sooner.

 note: i'm ok with compiling ghc from source, but many people who might be
 happy to test those new features might find that a bit daunting the first
 time.

 cheers
 -Carter


 On Wed, Mar 20, 2013 at 6:58 AM, John Wiegley jo...@fpcomplete.comwrote:

  Ian Lynagh i...@well-typed.com writes:

  Would a 7.7.x recommended snapshot be useful to you? Tell us if you want
  one.

 I think that could very useful, sort of like what the Linux kernel did
 before
 they stopped.

 I'm never sure if building from HEAD will produce a compiler I should use
 for
 getting real work done, but I wouldn't have the same reservations
 concerning a
 7.7.x interim developer release.

 --
 John Wiegley
 FP Complete Haskell tools, training and consulting
 http://fpcomplete.com   johnw on #haskell/irc.freenode.net

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Status of GHC type-nats branch

[Iavor Diatchki]

Hello,
I haven't merged the type-nats branch with GHC master recently, so some of
the libraries probably moved forward, which could be the source of the
problem.  I'll make sure to fix it over the next couple of days.
-Iavor


On Mon, Feb 25, 2013 at 6:39 AM, Takayuki Muranushi muranu...@gmail.comwrote:

 Hi, everyone,

 In order to merge two type-level key-value pairs
 (More specifically, to use TypeNats branch of unittyped:

 https://bitbucket.org/xnyhps/haskell-unittyped/commits/all/tip/branch%28%22TypeNats%22%29
 )
 I'd like to use overlapping type families and the type level Naturals
 at the same time.

 However, I couldn't build the type-nats branch of ghc, as I've been
 trying this week.
 I could build that in late 2012, so maybe this is due to updates in
 the git submodules.

 Do you reproduce this? Is there anyone else trying to build the
 type-nats branch?

 Any advice is helpful, including negative ones, if it's temporally
 broken or no more supported. And, I'm particularly glad if anyone has
 a x86-64 linux tarball of type-nats branch, and share it with me :)

 Best regards,

 --
 Takayuki MURANUSHI
 The Hakubi Center for Advanced Research, Kyoto University
 http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Text.JSON and utf8

[Iavor Diatchki]

Hello Martin,

the change that you propose seems to already be in json-0.7.  Perhaps you
just need to 'cabal update' and install the most recent version?

About your other question:  I have not used CouchDB but a common mistake is
to mix up strings and bytes.  Perhaps the `getDoc` function does not do
utf-8 decoding and so it is giving you back list of bytes (as a String)?

In general, the JSON package only converts between JSON and String, and is
agnostic to what encoding is used to represent the strings.   There are
other packages that convert Strings into bytes (e.g.,
http://hackage.haskell.org/package/utf8-string), so typically you want to
encode the string to bytes before you export it (say to CouchDB), and
decode it back into a string just after you've imported it.

-Iavor





On Mon, Feb 11, 2013 at 5:56 AM, Martin Hilbig li...@mhilbig.de wrote:

 hi,

 tl;dr: i propose this patch to Text/JSON/String.hs and would like to
 know why it is needed:

 @@ -375,7 +375,7 @@
where
go s1 =
  case s1 of
 -  (x   :xs) | x  '\x20' || x  '\x7e' - '\\' : encControl x (go xs)
 +  (x   :xs) | x  '\x20' - '\\' : encControl x (go xs)
('' :xs)  - '\\' : ''  : go xs
('\\':xs)  - '\\' : '\\' : go xs
(x   :xs)  - x: go xs


 i recently stumbled upon CouchDB telling me i'm sending invalid json.

 i basically read lines from a utf8 file with german umlauts and send
 them to CouchDB using Text.JSON and Database.CouchDB.

   $ file lines.txt
   lines.txt: UTF-8 Unicode text

 lets take 'ö' as an example. i use LANG=de_DE.utf8

 ghci tells

  'ö'
 '\246'

  putChar '\246'
 ö

  putChar 'ö'
 ö

  :m + Text.JSON Database.CouchDB
  runCouchDB' $ newNamedDoc (db foo) (doc bar) (showJSON $ toJSObject
 [(test,ö)])
 *** Exception: HTTP/1.1 400 Bad Request
 Server: CouchDB/1.2.1 (Erlang OTP/R15B03)
 Date: Mon, 11 Feb 2013 13:24:49 GMT
 Content-Type: text/plain; charset=utf-8
 Content-Length: 48
 Cache-Control: must-revalidate

 couchdb log says:

   Invalid JSON: {{error,{10,lexical error: invalid bytes in UTF8
 string.\n}},{\test\:\**F6\}}

 this is indeed hex ö:

  :m + Numeric
  putChar $ toEnum $ fst $ head $ readHex f6
 ö

 if i apply the above patch and reinstall JSON and CouchDB the doc
 creation works:

  runCouchDB' $ newNamedDoc (db db) (doc foo) (showJSON $ toJSObject
 [(test, ö)])
 Right someRev

 but i dont get back the ö i expected:

  Just (_,_,x) -runCouchDB' $ getDoc (db foo) (doc bar) :: IO (Maybe
 (Doc,Rev,JSObject String))
  let Ok y = valFromObj test = readJSON x :: Result String
  y
 \195\188
  putStrLn y
 ü

 apperently with curl everything works fine:

 $ curl localhost:5984/db/foo -XPUT -d '{test: ö}'
 {ok:true,id:foo,rev:**someOtherRev}
 $ curl localhost:5984/db/foo
 {_id:bars,_rev:**someOtherRev,test:ö}

 so how can i get my precious ö back? what am i doing wrong or does
 Text.JSON need another patch?

 another question: why does encControl in Text/JSON/String.hs handle the
 cases x  '\x100' and x  '\x1000' even though they can never be
 reached with the old predicate in encJSString (x  '\x20')

 finally: is '\x7e' the right literal for the job?

 thanks for reading

 have fun
 martin

 __**_
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[no subject]

[Iavor Diatchki]

Hello,

I was just doing some work with Template Haskell and I noticed that the AST
does not have support for record puns and wild-cards.  I know that these
could be desugared into ordinary record patterns but I think that it would
be more convenient for users (and also more consistent with the rest of the
AST) if we provided direct support for them.

So I propose to change:

type FieldPat = (Name, Pat)

to

data FieldPat = RecordFileldP Name Pat  -- x = P
  | RecordPunP Name -- x
  | RecordWildP -- ..

Would there be any objections to doing so?  If not, I'd be happy to have a
go at making the change.

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Proposal to extend FieldPat in Template Haskell

[Iavor Diatchki]

Hello,
(sorry for the repost, I forgot to add a subject.)

I was just doing some work with Template Haskell and I noticed that the AST
does not have support for record puns and wild-cards.  I know that these
could be desugared into ordinary record patterns but I think that it would
be more convenient for users (and also more consistent with the rest of the
AST) if we provided direct support for them.

So I propose to change:

type FieldPat = (Name, Pat)

to

data FieldPat = RecordFileldP Name Pat  -- x = P
  | RecordPunP Name -- x
  | RecordWildP -- ..

Would there be any objections to doing so?  If not, I'd be happy to have a
go at making the change.

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: data kinds

[Iavor Diatchki]

Hello,

I think that it'd be really useful to be able to just declare a `kind`
without having to promote a datatype.

When we discussed this last time (summarized by the link Pedro sent, I
think) it came up that it might be nice to also
have kind synonyms, which would be analogous to type synonyms, but one
level up.   The natural syntax for that would be to have a type kind
declaration, but this seems a bit confusing...

John, did you implement kind synonyms in jhc, and if so what syntax did you
use?

-Iavor


On Sat, Jan 26, 2013 at 6:11 PM, John Meacham j...@repetae.net wrote:


 On Fri, Jan 25, 2013 at 7:19 AM, Ross Paterson r...@soi.city.ac.ukwrote:

 GHC implements data kinds by promoting data declarations of a certain
 restricted form, but I wonder if it would be better to have a special
 syntax for kind definitions, say

   data kind Nat = Zero | Succ Nat


 This is exactly the syntax jhc uses for user defined kinds.

 John

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Newtype wrappers

[Iavor Diatchki]

Hello,

The general functionality for this seems useful, but we should be careful
exactly what types we allow in the 'newtype wrap/unwrap' declarations.  For
example, would we allow something like this:

newtype wrap cvt :: f a - f (Dual a)

If we just worry about what's in scope, then it should be accepted, however
this function could still be used to break the invariant on `Set` because
it is polymorphic.


In general, I was never comfortable with GHC's choice to add an axiom
equating a newtype and its representation type, because it looks unsound to
me (without any type-functions or newtype deriving).
For example, consider:

newtype T a = MkT Int

Now, if this generates an axiom asserting that `froall a. T a ~ Int`, then
we can derive a contradiction:

T Int ~ Int ~ T Char, and hence `Int ~ Char`.

It looks like what we need is a different concept: one that talks about the
equality of the representations of types, rather then equality of the types
themselves.

-Iavor




















On Mon, Jan 14, 2013 at 10:09 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:

  Friends

 ** **

 I’d like to propose a way to “promote” newtypes over their enclosing
 type.  Here’s the writeup

   http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers

 ** **

 Any comments?  Below is the problem statement, taken from the above page.*
 ***

 ** **

 I’d appreciate

 **· **A sense of whether you care. Does this matter?

 **· **Improvements to the design I propose

 ** **

 Simon

 ** **

 ** **

 ** **

 *The problem*

 Suppose we have 

 newtype Age = MkAge Int

 Then if n :: Int, we can convert n to an Age thus: MkAge n :: Age.
 Moreover, this conversion is a type conversion only, and involves no
 runtime instructions whatsoever. This cost model -- that newtypes are free
 -- is important to Haskell programmers, and encourages them to use newtypes
 freely to express type distinctions without introducing runtime overhead.
 

 Alas, the newtype cost model breaks down when we involve other data
 structures. Suppose we have these declarations 

 data T a   = TLeaf a | TNode (Tree a) (Tree a)

 data S m a = SLeaf (m a) | SNode (S m a) (S m a)

 and we have these variables in scope 

 x1 :: [Int]

 x2 :: Char - Int

 x3 :: T Int

 x4 :: S IO Int

 Can we convert these into the corresponding forms where the Int is
 replaced by Age? Alas, not easily, and certainly not without overhead. ***
 *

- For x1 we can write map MkAge x1 :: [Age]. But this does not follow
the newtype cost model: there will be runtime overhead from executing the
map at runtime, and sharing will be lost too. Could GHC optimise the
map somehow? This is hard; apart from anything else, how would GHC
know that map was special? And it it gets worse. 


- For x2 we'd have to eta-expand: (\y - MkAge (x2 y)) :: Char - Age.
But this isn't good either, because eta exapansion isn't semantically valid
(if x2 was bottom, seq could distinguish the two). See 
 #7542http://hackage.haskell.org/trac/ghc/ticket/7542for a real life example.



- For x3, we'd have to map over T, thus mapT MkAge x3. But what if 
 mapTdidn't exist? We'd have to make it. And not all data types have maps.
S is a harder one: you could only map over S-values if m was a
functor. There's a lot of discussion abou this on 
 #2110http://hackage.haskell.org/trac/ghc/ticket/2110.


 ** **

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Advice on type families and non-injectivity?

[Iavor Diatchki]

Hello Conal,

The issue with your example is that it is ambiguous, so GHC can't figure
out how to instantiate the use of `foo`.   It might be easier to see why
this is if you write it in this form:

 foo :: (F a ~ b) = b
 foo = ...

Now, we can see that only `b` appears on the RHS of the `=`, so there is
really no way for GHC to figure out what is the intended value for `a`.
 Replacing `a` with a concrete type (such as `Bool`) eliminates the
problem, because now GHC does not need to come up with a value for `a`.
Another way to eliminate the ambiguity would be if `F` was injective---then
we'd know that `b` uniquely determines `a` so again there would be no
ambiguity.

If `F` is not injective, however, the only workaround would be to write the
type in such a way that the function arguments appear in the signature
directly (e.g., something like 'a - F a' would be ok).

-Iavor








On Sun, Jan 13, 2013 at 11:10 AM, Conal Elliott co...@conal.net wrote:

 I sometimes run into trouble with lack of injectivity for type families.
 I'm trying to understand what's at the heart of these difficulties and
 whether I can avoid them. Also, whether some of the obstacles could be
 overcome with simple improvements to GHC.

 Here's a simple example:

  {-# LANGUAGE TypeFamilies #-}
 
  type family F a
 
  foo :: F a
  foo = undefined
 
  bar :: F a
  bar = foo

 The error message:

 Couldn't match type `F a' with `F a1'
 NB: `F' is a type function, and may not be injective
 In the expression: foo
 In an equation for `bar': bar = foo

 A terser (but perhaps subtler) example producing the same error:

  baz :: F a
  baz = baz

 Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.

 Does the difficulty here have to do with trying to *infer* the type and
 then compare with the given one? Or is there an issue even with type
 *checking* in such cases?

 Other insights welcome, as well as suggested work-arounds.

 I know about (injective) data families but don't want to lose the
 convenience of type synonym families.

 Thanks,  -- Conal


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Advice on type families and non-injectivity?

[Iavor Diatchki]

Hello,


On Sun, Jan 13, 2013 at 12:05 PM, Conal Elliott co...@conal.net wrote:


 so there is really no way for GHC to figure out what is the intended value
 for `a`.


 Indeed. Though I wonder: does the type-checker really need to find a
 binding for `a` in this case, i.e., given the equation `(forall a. F a) ==
 (forall a'. F a')`?


Wouldn't that make `F` a constant type family, and so one could just skip
the `a` parameter?   Anyway, if there was a way to assert something like
that about a type-function, than there would be no problem.   When
something like that happens (i.e., GHC figures out that it does not know
how to instantiate a type variable, but it is sure that the actual
instantiation does not matter), GHC instantiates the variable a special
type called `Any`, which has a very polymorphic kind.

By the way, Simon recently reworked the ambiguity checker in GHC, and now
HEAD correctly rejects `foo` as being ambiguous (the new ambiguity check
uses exactly what's in your example: a value `f :: S` is ambiguous, if `g
:: S; g = f` results in an error).

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Advice on type families and non-injectivity?

[Iavor Diatchki]

Hello Conal,

The issue with your example is that it is ambiguous, so GHC can't figure
out how to instantiate the use of `foo`.   It might be easier to see why
this is if you write it in this form:

 foo :: (F a ~ b) = b
 foo = ...

Now, we can see that only `b` appears on the RHS of the `=`, so there is
really no way for GHC to figure out what is the intended value for `a`.
 Replacing `a` with a concrete type (such as `Bool`) eliminates the
problem, because now GHC does not need to come up with a value for `a`.
Another way to eliminate the ambiguity would be if `F` was injective---then
we'd know that `b` uniquely determines `a` so again there would be no
ambiguity.

If `F` is not injective, however, the only workaround would be to write the
type in such a way that the function arguments appear in the signature
directly (e.g., something like 'a - F a' would be ok).

-Iavor








On Sun, Jan 13, 2013 at 11:10 AM, Conal Elliott co...@conal.net wrote:

 I sometimes run into trouble with lack of injectivity for type families.
 I'm trying to understand what's at the heart of these difficulties and
 whether I can avoid them. Also, whether some of the obstacles could be
 overcome with simple improvements to GHC.

 Here's a simple example:

  {-# LANGUAGE TypeFamilies #-}
 
  type family F a
 
  foo :: F a
  foo = undefined
 
  bar :: F a
  bar = foo

 The error message:

 Couldn't match type `F a' with `F a1'
 NB: `F' is a type function, and may not be injective
 In the expression: foo
 In an equation for `bar': bar = foo

 A terser (but perhaps subtler) example producing the same error:

  baz :: F a
  baz = baz

 Replacing `a` with a monotype (e.g., `Bool`) eliminates the error.

 Does the difficulty here have to do with trying to *infer* the type and
 then compare with the given one? Or is there an issue even with type
 *checking* in such cases?

 Other insights welcome, as well as suggested work-arounds.

 I know about (injective) data families but don't want to lose the
 convenience of type synonym families.

 Thanks,  -- Conal


 ___
 Glasgow-haskell-users mailing list
 glasgow-haskell-us...@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Advice on type families and non-injectivity?

[Iavor Diatchki]

Hello,


On Sun, Jan 13, 2013 at 12:05 PM, Conal Elliott co...@conal.net wrote:


 so there is really no way for GHC to figure out what is the intended value
 for `a`.


 Indeed. Though I wonder: does the type-checker really need to find a
 binding for `a` in this case, i.e., given the equation `(forall a. F a) ==
 (forall a'. F a')`?


Wouldn't that make `F` a constant type family, and so one could just skip
the `a` parameter?   Anyway, if there was a way to assert something like
that about a type-function, than there would be no problem.   When
something like that happens (i.e., GHC figures out that it does not know
how to instantiate a type variable, but it is sure that the actual
instantiation does not matter), GHC instantiates the variable a special
type called `Any`, which has a very polymorphic kind.

By the way, Simon recently reworked the ambiguity checker in GHC, and now
HEAD correctly rejects `foo` as being ambiguous (the new ambiguity check
uses exactly what's in your example: a value `f :: S` is ambiguous, if `g
:: S; g = f` results in an error).

-Iavor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Documentation operator

[Iavor Diatchki]

Hi,

I think that this is a neat idea that should be explored more!   GHC's
parser has a bunch of awkward duplication to handle attaching documentation
to types, and it'd be cool if we could replace it with an actual language
construct.

Happy holidays!
-Iavor

On Wed, Dec 26, 2012 at 3:27 AM, Christopher Done chrisd...@gmail.comwrote:

 Hello chums,

 I've been playing around with an idea, something that has obvious pros
 and cons, but I'll sell it to you because there might be some positive
 ideas out of it. Consider the following operator:

 {-# LANGUAGE TypeOperators, DataKinds, KindSignatures #-}

 module Docs where

 import GHC.TypeLits

 type a ? (sym :: Symbol) = a

 First I'll describe how I'd want to use this and then what I think
 are the advantages and disadvantages.

 I call this (?) operator “the documentation operator”, to be used for:

 * Things that either don't belong or can't be encoded in the type
   system, or for things need to be in English.
 * Things that cannot be encoded in Haddock.

 The simple case of ye olde days:

 -- | Lorem ipsum dolor sit amet. Suspendisse lacinia nibh et
 --   leo. Aenean auctor aliquam dapibus.
 loremIpsum :: Int - Int - String

 Which has since been somewhat evolved into:

 loremIpsum :: Int-- ^ Lorem ipsum dolor sit amet.
- Int-- ^ Suspendisse lacinia nibh et leo.
- String -- ^ Aenean auctor aliquam dapibus.

 But could now be written:

 loremIpsum :: Int? Lorem ipsum dolor sit amet.
- Int? Suspendisse lacinia nibh et leo.
- String ? Aenean auctor aliquam dapibus.

 Here is a contrived case I'll use later on:

 data Person = Person

 describeAge :: Int ? an age - String ? description of their
 elderliness
 describeAge n = undefined

 personAge :: Person ? a person - Int ? their age
 personAge = undefined

 One could also encode previously informal specifications more formally,
 so that

 -- | The action 'hFlush' @hdl@ causes any items buffered for output
 -- in handle @hdl@ to be sent immediately to the operating system.
 --
 -- This operation may fail with:
 --
 --  * 'isFullError' if the device is full;
 --
 --  * 'isPermissionError' if a system resource limit would be exceeded.
 --It is unspecified whether the characters in the buffer are
 discarded
 --or retained under these circumstances.
 hFlush :: Handle - IO ()
 hFlush handle = wantWritableHandle hFlush handle flushWriteBuffer

 with

 type Throws ex (docs :: Symbol) = docs

 could now be written

 hFlush :: Handle ? flush buffered items for output on this handle -
 IO ()
   ? Throws IsFullError if the device is full
   ? Throws IsPermissionError
if a system resource limit would be exceeded. It is \
\unspecified whether the characters in the  buffer are \
\discarded or retained under these circumstances.
 hFlush handle = wantWritableHandle hFlush handle flushWriteBuffer

 With this in place, in GHCi you get documentation lookup for free:

  :t hFlush
 hFlush
   :: (Handle ? flush buffered items for output on this handle)
  - (IO () ? Throws IsFullError if the device is full)
 ? Throws
 IsPermissionError
 if a system resource limit would be exceeded. It is
 unspecified
  whether the characters in the  buffer are discarded or
 retained
  under these circumstances.

 And you get function composition, or “documentation composition” for free:

  :t describeAge . personAge
 describeAge . personAge
   :: (Person ? a person)
  - String ? description of their elderliness

 We could have a :td command to print it with docs, and otherwise docs
 could be stripped out trivially by removing the ? annotations:

  :t describeAge . personAge
 describeAge . personAge
   :: Person - String
  :td describeAge . personAge
 describeAge . personAge
   :: (Person ? a person)
  - String ? description of their elderliness

 You could even add clever printing of such “documentation types”:

  :t hFlush
 hFlush
   :: Handle — flush buffered items for output on this handle
   - IO ()
 Throws IsFullError if the device is full
 Throws IsPermissionError if a system resource limit would be
   exceeded. It is unspecified whether the characters in the buffer
   are discarded or retained under these circumstances.

 Unfortunately it doesn't work with monadic composition, of course.

 So here are the advantages:

 * You get parsing for free (and anyone using haskell-src-exts).
 * You get checking for free (i.e. GHC can check that IsFullError exists
   for you).
 * You get a continuity of documentation through your operations
   including composition.
 * You can extend the documentation language easily by 

Re: Fundeps and type equality

[Iavor Diatchki]

Hello Conal,

GHC implementation of functional dependencies is incomplete: it will use
functional dependencies during type inference (i.e., to determine the
values of free type variables), but it will not use them in proofs, which
is what is needed in examples like the one you posted.  The reason some
proving is needed is that the compiler needs to figure out that for each
instantiation of the type `ta` and `tb` will be the same (which, of course,
follows directly from the FD on the class).

As far as I understand, the reason that GHC does not construct such proofs
is that it can't express them in its internal proof language (System FC).
 It seems to me that it should be fairly straight-forward to extend FC to
support this sort of proof, but I have not been able to convince folks that
this is the case.  I could elaborate, if there's interest.

In the mean time, the way forward would probably be to express the
dependency using type families, which I find tends to be more verbose but,
at present, is better supported in GHC.

Cheers,
-Iavor
PS: cc-ing the GHC users' list, as there was some talk of closing the
ghc-bugs list, but I am not sure if the transition happened yet.





On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott co...@conal.net wrote:

 I ran into a simple falure with functional dependencies (in GHC 7.4.1):

  class Foo a ta | a - ta
 
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
  foo = (==)

 I expected that the `a - ta` functional dependency would suffice to prove
 that `ta ~ tb`, but

 Pixie/Bug1.hs:9:7:
 Could not deduce (ta ~ tb)
 from the context (Foo a ta, Foo a tb, Eq ta)
   bound by the type signature for
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
   at Pixie/Bug1.hs:9:1-10
   `ta' is a rigid type variable bound by
the type signature for
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
at Pixie/Bug1.hs:9:1
   `tb' is a rigid type variable bound by
the type signature for
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
at Pixie/Bug1.hs:9:1
 Expected type: ta - tb - Bool
   Actual type: ta - ta - Bool
 In the expression: (==)
 In an equation for `foo': foo = (==)
 Failed, modules loaded: none.

 Any insights about what's going wrong here?

 -- Conal

 ___
 Glasgow-haskell-bugs mailing list
 Glasgow-haskell-bugs@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Fundeps and type equality

[Iavor Diatchki]

Hello Conal,

GHC implementation of functional dependencies is incomplete: it will use
functional dependencies during type inference (i.e., to determine the
values of free type variables), but it will not use them in proofs, which
is what is needed in examples like the one you posted.  The reason some
proving is needed is that the compiler needs to figure out that for each
instantiation of the type `ta` and `tb` will be the same (which, of course,
follows directly from the FD on the class).

As far as I understand, the reason that GHC does not construct such proofs
is that it can't express them in its internal proof language (System FC).
 It seems to me that it should be fairly straight-forward to extend FC to
support this sort of proof, but I have not been able to convince folks that
this is the case.  I could elaborate, if there's interest.

In the mean time, the way forward would probably be to express the
dependency using type families, which I find tends to be more verbose but,
at present, is better supported in GHC.

Cheers,
-Iavor
PS: cc-ing the GHC users' list, as there was some talk of closing the
ghc-bugs list, but I am not sure if the transition happened yet.





On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott co...@conal.net wrote:

 I ran into a simple falure with functional dependencies (in GHC 7.4.1):

  class Foo a ta | a - ta
 
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
  foo = (==)

 I expected that the `a - ta` functional dependency would suffice to prove
 that `ta ~ tb`, but

 Pixie/Bug1.hs:9:7:
 Could not deduce (ta ~ tb)
 from the context (Foo a ta, Foo a tb, Eq ta)
   bound by the type signature for
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
   at Pixie/Bug1.hs:9:1-10
   `ta' is a rigid type variable bound by
the type signature for
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
at Pixie/Bug1.hs:9:1
   `tb' is a rigid type variable bound by
the type signature for
  foo :: (Foo a ta, Foo a tb, Eq ta) = ta - tb - Bool
at Pixie/Bug1.hs:9:1
 Expected type: ta - tb - Bool
   Actual type: ta - ta - Bool
 In the expression: (==)
 In an equation for `foo': foo = (==)
 Failed, modules loaded: none.

 Any insights about what's going wrong here?

 -- Conal

 ___
 Glasgow-haskell-bugs mailing list
 glasgow-haskell-b...@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: proposal: separate lists for ghc-cvs commits and ghc-dev chatter

[Iavor Diatchki]

Hello,

I also sometimes wish that GHC developer discussions happened in a single
place, separate from the commits and ticket lists (at present they are
sometimes on ghc-users and sometimes on cvs-ghc).   For what it's worth, I
don't follow the commit and build-bot messages closely, instead I use
various git tools to catch up on what's going on with the development
(mostly I use gitk, git-gub, and our own git-web instance on
darcs.haskell.org).   I do find the trac bug messages useful though, both
as a GHC user and a GHC developer.

-Iavor



On Thu, Dec 6, 2012 at 9:04 AM, Ian Lynagh i...@well-typed.com wrote:

 On Thu, Dec 06, 2012 at 12:29:01PM +, Simon Peyton-Jones wrote:
  My own understanding is this:
 
  A GHC *user* is someone who uses GHC, but doesn't care how it is
 implemented.
  A GHC *developer* is someone who wants to work on GHC itself in some way.
 
  The current mailing lists:
 
  * glasgow-haskell-users: for anything that a GHC *user* cares about
  * glasgow-haskell-bugs: same, but with a focus on bug reporting

 I see glasgow-haskell-bugs as being mainly for developers, who want to
 see what bugs are coming in.

 It's true that we do give e-mailing it as a (less preferred) way for
 users to submit a bug on
 http://hackage.haskell.org/trac/ghc/wiki/ReportABug
 but I wonder if we shouldn't change that. It's rare that we get a bug
 report e-mailed, and normally we ultimately end up creating a trac
 ticket for it anyway. I'm sure that people who really want to submit a
 bug report and for whatever reason can't use trac will e-mail it
 somewhere sensible.


 Thanks
 Ian


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] curl package broken in Windows

[Iavor Diatchki]

Hi,

the curl binding certainly needs some love---if anyone has the time to fix
it up and maintain it, help would be most appreciated.  There is a repo for
it over here: https://github.com/GaloisInc/curl which is the most up-to
date version I know of, but since the last commit there seems to be from 4
years ago, I'm not going to bet that there aren't any additional fixes
floating around.  (cc-ing Don, who is listed as the maintainer, but I'm not
sure if he has time to deal with curl right now)

-Iavor



On Sun, Nov 11, 2012 at 3:34 PM, Erik de Castro Lopo
mle...@mega-nerd.comwrote:

 Kevin Cantu wrote:

  With the curl package on Hackage, I merely need an SSL enabled version
  of libcurl, and every Linux distro I've tried this on has several
  variations of such a package.  (You have a choice of OpenSSL or
  GNUTLS, for example.)

 I tried the CURL bindings on Linux some time ago and I personally
 found the thing pretty much un-usable. The API was incomplete,
 inconsistent and way too close to the C API.

 However, I have had much better luck with Michael Snoyman's http-conduit
 package, which being pure Haskell (ie no C) should be much easier to
 install on windows.

 Erik
 --
 --
 Erik de Castro Lopo
 http://www.mega-nerd.com/

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] curl package broken in Windows

[Iavor Diatchki]

Hi,

Ok, there were only minor differences between the repo and the version on
hackage so I imported the changes into the repo, which should now be the
same as version 1.3.7 on hackage.
Please feel free to submit merge requestsall the folks I know who
worked on this originally are busy with other stuff, so we really need
someone who's using the library to help.

Thanks!
-Iavor



On Mon, Nov 12, 2012 at 2:06 PM, Iustin Pop iu...@k1024.org wrote:

 On Mon, Nov 12, 2012 at 10:57:25PM +0100, Iustin Pop wrote:
  On Mon, Nov 12, 2012 at 01:48:23PM -0800, Iavor Diatchki wrote:
   Hi,
  
   the curl binding certainly needs some love---if anyone has the time to
 fix
   it up and maintain it, help would be most appreciated.  There is a
 repo for
   it over here: https://github.com/GaloisInc/curl which is the most
 up-to
   date version I know of, but since the last commit there seems to be
 from 4
   years ago, I'm not going to bet that there aren't any additional fixes
   floating around.  (cc-ing Don, who is listed as the maintainer, but
 I'm not
   sure if he has time to deal with curl right now)
 
  I've tried to contact Don multiple times over the past month with offers
  of whatever help I can give, but I heard nothing back.
 
  I didn't know about the github repo (it's not listed on the hackage
  page), so thanks a lot for that info, I'll try to send some merge
  requests and file bugs (there is a least one critical bug w.r.t. SSL
  usage on Linux and another small-impact bug with cookie jars usage).

 Hmm, checking again, the github repo is at version 1.3.5 (April 2009),
 whereas hackage is at version 1.3.7 (uploaded in May 2011).

 Still hunting for a correct upstream project page or tracker…

 regards,
 iustin

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

How to use `trace` while debuging GHC

[Iavor Diatchki]

Hello,

While working on GHC sometimes I find it useful to dump the values of
intermediate expressions, perhaps in the middle of pure code, using a
combination of `trace` and `ppr`.  The issue is that `ppr` returns an
`SDoc`, and to turn an `SDoc` into a `String`, I need some `DynFlags`.

There used to be a value called `tracingDynFlags` that I could use to dump
values, but it has disappeared...  Did it get moved somewhere, or is there
a better way to get the same effect?

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Computed promoted natural

[Iavor Diatchki]

Hello Arie,

One way to achieve the additional static checking is to use values of type
`Sing (n :: Nat)` in the places where you've used `Integer` (and
parameterize data structures by the `n`).  If the code is fully polymorphic
in the `n`, then you can use it with values whose types as not statically
know by using an existential.  Here is an example:

{-# LANGUAGE DataKinds, KindSignatures, ExistentialQuantification #-}

import GHC.TypeLits

data SomeNat = forall (n :: Nat). SomeNat (Sing n)

getSomeNat :: IO SomeNat
getSomeNat =
  do x - getLine
 case reads x of
   -- The use of `unsafeSingNat` is OK here because it is wrapped in
`SomeNat`
   -- so we are not assuming anything about the actual number.
   [(n,_)] | n = 0 - return $ SomeNat $ unsafeSingNat n
   _ - putStrLn Invalid number, try again.  getSomeNat

main :: IO ()
main =
  do x - getSomeNat
 case x of
   SomeNat s - polyFun s s

-- The argument of this function are always going to be the same.
-- (just an example, one could probably get more interesting properties)
polyFun :: Sing (n :: Nat) - Sing n - IO ()
polyFun x y = print (x,y)

I can elaborate more, just ask if this does not make sense.   One issue at
the moment is that you have to pass the explicit `Sing` values everywhere,
and it is a lot more convenient to use the `SingI` class in GHC.TypeLits.
 Unfortunately at the moment this only works for types that are statically
known at compile time.  I think that we should be able to find a way to
work around this, but we're not quite there yet.

-Iavor






On Thu, Nov 8, 2012 at 7:54 AM, Arie Peterson ar...@xs4all.nl wrote:

 Hi,


 I'm trying to use data kinds, and in particular promoted naturals, to
 simplify
 an existing program.

 The background is as follows: I have a big computation, that uses a certain
 natural number 'd' throughout, which is computed from the input.
 Previously,
 this number was present as a field in many of my data types, for instance

  data OldA = OldA Integer …

 . There would be many values of this type (and others) floating around,
 with
 all the same value of 'd'. I would like to move this parameter to the type
 level, like this:

  data NewA (d :: Nat) = NewA …

 The advantage would be, that the compiler can verify that the same value of
 'd' is used throughout the computation.

 Also, it would then be possible to make 'NewA' a full instance of 'Num',
 because 'fromInteger :: Integer - NewA d' has a natural meaning (where the
 value of 'd' is provided by the type, i.e. the context in which the
 expression
 is used), while 'fromInteger :: Integer - OldA' does not, because it is
 not
 possible to create the right value of 'd' out of thin air.


 Is this a sane idea? I seem to get stuck when trying to /use/ the
 computation,
 because it is not possible to create 'd :: Nat', at the type level, from
 the
 computed integer.

 Can one somehow instantiate the type variable 'd :: Nat' at an integer
 that is
 not statically known?

 Formulated this way, it sounds like this should not be possible, because
 all
 types are erased at compile time.

 However, it feels as though it might not be unreasonable in this situation,
 because the computation is polymorphic in the type 'd :: Nat'. I just want
 to
 substitute a specific value for 'd'.


 Maybe there is another way to approach this?


 Thanks for any advice,

 Arie


 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Security] Put haskell.org on https

[Iavor Diatchki]

Hello,

I think that getting a certificate is a good idea.  I think this could
probably be arranged by the haskell.org committee, which even has a budget
for things like that, I believe.  I'm cc-ing Jason, who's on the committee
and might have more input on what's the best way to proceed.

Thanks for bringing this up!
-Iavor


On Fri, Nov 2, 2012 at 5:14 AM, Ramana Kumar ramana.ku...@cl.cam.ac.ukwrote:

 Who is the webmaster for haskell.org? Presumably they will be required in
 the process of installing the certificate.

 As far as obtaining goes, one can obtain a free certificate from StartSSL
 - see https://www.startssl.com
 There are other CAs, but if nobody has any strong preferences, I recommend
 going with them.


 On Tue, Oct 30, 2012 at 8:52 PM, Niklas Hambüchen m...@nh2.me wrote:

 So how do we go forward about getting the SSL certificate and installing
 it?

 On 29/10/12 01:06, Patrick Mylund Nielsen wrote:
  Sure. No matter what's done in Cabal, the clients for everything else
  will still be mainly browsers.
 
  On Mon, Oct 29, 2012 at 12:59 AM, Niklas Hambüchen m...@nh2.me
  mailto:m...@nh2.me wrote:
 
  No matter what we do with cabal, it would be great if I could soon
 point
  my browser at https://haskell.org *anyway*.
 
  On 28/10/12 23:55, Patrick Mylund Nielsen wrote:
   Of course, as long as Cabal itself is distributed through this
 same
   https-enabled site, you have the same PKI-backed security as just
  about
   any major website. This model has problems, yes, but it's good
 enough,
   and it's easy to use. If you really want to improve it (without
   impacting usability), have Google/the browser vendors pin the
 public
   cert for haskell.org http://haskell.org http://haskell.org.
  
   On Mon, Oct 29, 2012 at 12:45 AM, Patrick Mylund Nielsen
   hask...@patrickmylund.com mailto:hask...@patrickmylund.com
  mailto:hask...@patrickmylund.com
  mailto:hask...@patrickmylund.com wrote:
  
   PGP tends to present many usability issues, and in this case
 it
   would make more sense/provide a clearer win if there were many
   different, semi-untrusted hackage mirrors. Just enable HTTPS
 and
   have Cabal validate the server certificate against a CA pool
  of one.
   PKI/trusting obscure certificate authorities in Egypt and
 Syria is
   the biggest concern here, not somebody MITMing your initial
 Cabal
   installation (which in a lot of cases happens through apt-get
 or
   yum, anyway.)
  
  
   On Mon, Oct 29, 2012 at 12:34 AM, Changaco
  chang...@changaco.net mailto:chang...@changaco.net
   mailto:chang...@changaco.net mailto:chang...@changaco.net
 
  wrote:
  
   On Sun, 28 Oct 2012 17:07:24 -0400 Patrick Hurst wrote:
How do you get a copy of cabal while making sure that
  somebody
   hasn't MITMed you and replaced the PGP key?
  
   Ultimately it is a DNS problem. To establish a secure
  connection
   with
   haskell.org http://haskell.org http://haskell.org
  you'd have to get the
   certificate from the DNS, but that
   technology is not ready yet, so all you can do is check
  the key
   against
   as many sources as possible like Michael Walker said.
  
   On Sun, 28 Oct 2012 17:46:06 -0400 Patrick Hurst wrote:
So why not use HTTPS?
  
   Because it doesn't solve the problem.
  
   ___
   Haskell-Cafe mailing list
   Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org
 
  mailto:Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org
   http://www.haskell.org/mailman/listinfo/haskell-cafe
  
  
  
  
  
   ___
   Haskell-Cafe mailing list
   Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org
   http://www.haskell.org/mailman/listinfo/haskell-cafe
  
 
  ___
  Haskell-Cafe mailing list
  Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org
  http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type-directed functions with data kinds

[Iavor Diatchki]

Hello Paul,

If you don't want to use the class system, you could write `repeat` with a
type like this:

repeat :: Proxy n - a - Vector n a

(`Proxy` is the singleton family 'data Proxy n = Proxy`).

You can't really do it with a function of type `a - Vector n a` because
there is no way for the function to know how many elements to generate.
You cannot determine the length from the type `n` because polymorphism in
Haskell is _parametric_, which means that the function needs to behave
uniformly for all types.
This is nice because it makes reasoning about programs easier, but also, it
allows for efficient implementation---there is no need to pass
type-representations at run-time.
In contrast, overloaded values may behave differently depending on their
type, just like your implementation of `repeat` below.  This is perfectly
OK, and it is clearly marked in the type.


I hope this helps,
-Iavor



On Thu, Oct 25, 2012 at 8:22 AM, Paul Visschers m...@paulvisschers.netwrote:

 Hello everyone,

 I've been playing around with the data kinds extension to implement
 vectors that have a known length at compile time. Some simple code to
 illustrate:
  {-# LANGUAGE DataKinds, GADTs, KindSignatures #-}
 
  import Prelude hiding (repeat)
 
  data Nat = Zero | Succ Nat
  data Vector (n :: Nat) a where
Nil :: Vector Zero a
Cons :: a - Vector n a - Vector (Succ n) a
 
  class VectorRepeat (n :: Nat) where
repeat :: a - Vector n a
 
  instance VectorRepeat Zero where
repeat _ = Nil
 
  instance VectorRepeat n = VectorRepeat (Succ n) where
repeat x = Cons x (repeat x)

 In this code I have defined a repeat function that works in a similar way
 to the one in the prelude, except that the length of the resulting vector
 is determined by the type of the result. I would have hoped that its type
 would become 'repeat :: a - Vector n a', yet it is 'repeat :: VectorRepeat
 n = a - Vector n a'. As far as I can tell, this class constraint should
 no longer be necessary, as all possible values for 'n' are an instance of
 this class. I actually really just want to define a closed type-directed
 function and would rather not (ab)use the type class system at all.

 Is there a way to write the repeat function so that it has the type
 'repeat :: a - Vector n a' that I've missed? If not, is this just because
 it isn't implemented or are there conceptual caveats?

 Paul Visschers

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type-directed functions with data kinds

[Iavor Diatchki]

Hello,

Sorry, I made a mistake, the version of 'repeat :: Proxy n - a - Vector n
a' won't work either, as Andres noticed, because `Proxy` still won't give
you information about how many times to repeat.
You'd have to use a structured singleton family, where the values are
linked to the types:

data SNat :: Nat - * where
  SZero :: SNat Zero
  SSucc :: SNat n - SNat (Succ n)

repeat :: SNat n - a - Vector n a

Apologies for the confusion,
-Iavor





On Thu, Oct 25, 2012 at 9:03 AM, Andres Löh andres.l...@gmail.com wrote:

 Hi Iavor.

  If you don't want to use the class system, you could write `repeat` with
 a
  type like this:
 
  repeat :: Proxy n - a - Vector n a
 
  (`Proxy` is the singleton family 'data Proxy n = Proxy`).

 How is the polymorphism becoming any less parametric by using this
 particular Proxy type?

 Cheers,
   Andres

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: PolyKind issue in GHC 7.6.1rc1: How to make a kind a functional dependency?

[Iavor Diatchki]

Hello,

I have updated `GHC.TypeLits` to avoid the use of `Any` and also to use
type families instead of functional dependencies.  The new version should
be in `base` on the `master` branch.
I described the basic idea of what I did on this wiki page:

http://hackage.haskell.org/trac/ghc/wiki/TypeNats/SingletonsAndKinds

As usual, feedback is most welcome.
-Iavor




On Mon, Oct 15, 2012 at 6:13 PM, Richard Eisenberg e...@cis.upenn.eduwrote:

 I think there's a decent record of this conversation at
 http://hackage.haskell.org/trac/ghc/ticket/7259

 The comments there skip over some of the discussion in this thread, but I
 think the key ideas are all there.

 Here is how I see things:
 - Yes, I believe Any can be turned back into a type family, and Iavor and
 I will refactor around this change. As for my singletons paper, this
 changes the encoding slightly, but nothing major. I think it's a change for
 the better in the long run.
 - I raised a concern about type inference in the presence of eta-expansion
 in an earlier post to this thread and on the Trac page. Before really
 moving forward here, I think it would good for others to think about these
 issues. Instead of rehashing the idea again, please do visit the Trac page
 and comment there.
 - At one point, this thread included a discussion of injective type
 families. While these would be a nice thing to have, they seem orthogonal
 at this point and are probably best dropped from this discussion (which
 seems to have happened naturally, at any rate).

 Richard

 On Oct 15, 2012, at 8:10 PM, Simon Peyton-Jones simo...@microsoft.com
 wrote:

 I’m afraid I’ve rather lost track of this thread.  Would someone care to
 summarise, on a wiki page perhaps? 

 I think the story is:

 ·Inspired by Nick’s idea, Iavor and Pedro have converged on a
 single, type-family-based style for defining singletons.
 ·This style no longer requires Any to be a data type, so I can
 turn it back into a type family, which is a Good Thing because it paves the
 way for an eta rule.  RSVP and I’ll do that.
 ·Iavor mutters about sketchiness, but I’m not sure what that
 means specifically. 
 ·I’m not sure how, it at all, it affects Richard’s singletons
 paper

 Simon


 *From:* Iavor Diatchki [mailto:diatc...@galois.com]
 *Sent:* 12 October 2012 21:11
 *To:* Richard Eisenberg
 *Cc:* Nicolas Frisby; Simon Peyton-Jones; Stephanie Weirich; Conor
 McBride; glasgow-haskell-users@haskell.org
 *Subject:* Re: PolyKind issue in GHC 7.6.1rc1: How to make a kind a
 functional dependency?
 ** **
 Hello,

 (summary:  I think Nick's idea works for what's in GHC.TypeLits, and it
 would allow us to switch from `Any` as a constructor to `Any` as a
 function.)

 On 10/11/2012 08:47 PM, Richard Eisenberg wrote:

 Iavor and I collaborated on the design of the building blocks of singleton
 types, as we wanted our work to be interoperable. A recent scan through
 TypeLits tells me, though, that somewhere along the way, our designs
 diverged a bit. Somewhere on the to-do list is to re-unify the interfaces,
 and actually just to import TypeLits into Data.Singletons so the
 definitions are one and the same. Iavor, I'm happy to talk about the
 details if you are.


 The module GHC.TypeLits hasn't really changed much since last we talked
 (the Nat1 type is new, but that's only for working with type-level naturals
 and unrelated to this discussion).  I added the SingE class so that my work
 is compatible with Richard's (a simple newtype suffices if we are only
 interested in working with singletons for type-level literals). So we
 should certainly make the two compatible again, let me know what needs to
 change.

 I was just playing around with Nick's idea and here is my version of the
 code, which loads fine (but as I discuss in point 2 bellow I think it is a
 bit sketchy...)

 import GHC.TypeLits hiding (SingE(..), Kind)
 import qualified GHC.TypeLits as Old

 data Kind (k :: *) -- discuessed in point 2 bellow

 class SingE (any :: Kind k) rep | any - rep where
   fromSing :: Sing (a :: k) - rep

 instance SingE (any :: Kind Nat) Integer where
   fromSing = Old.fromSing

 instance SingE (any :: Kind Symbol) String where
   fromSing = Old.fromSing

 I think that there are two interesting points about this code:

 1. It is important that the instances are polymorphic because this tells
 GHC that it is allowed to use the instance in any context as long as the
 kinds match, regardless of the actual type.  Note that this is  not
 the case if we write the instance using the singleton member of the proxy
 kind:

 

 data KindProxy (k :: *) = KindProxy

 ** **

 instance SingE ('KindProxy :: KindProxy Nat) Integer where

   fromSing (SNat n) = n

 Such instances would only work if GHC could see that the type is
 'KindProxy so if we have a type variable of the correct kind, the
 instance would not reduce.   This is related to the eta

[Haskell] ANN: monadLib-3.7.1 on Hackage

[Iavor Diatchki]

Hello,

I am pleased to announce the availability of monadLib-3.7.1 on Hackage.

MonadLib is a library intended to help programmers to quickly and easily
construct various monads.   The library has support for a wide range of
effects:  threading state, read-only variables, collecting output,
exception handling, back-tracking computation, and working with explicit
continuations.  It provides similar functionality to libraries such as MTL,
but it has a simpler interface and improved functionality for a number of
the transformers.

The main change in this version is improved support for working with
continuations:  now we support invoking the same continuation in contexts
that have different types.

Happy hacking!
-Iavor
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell-cafe] ANN: monadLib-3.7.1 on Hackage

[Iavor Diatchki]

Hello,

I am pleased to announce the availability of monadLib-3.7.1 on Hackage.

MonadLib is a library intended to help programmers to quickly and easily
construct various monads.   The library has support for a wide range of
effects:  threading state, read-only variables, collecting output,
exception handling, back-tracking computation, and working with explicit
continuations.  It provides similar functionality to libraries such as MTL,
but it has a simpler interface and improved functionality for a number of
the transformers.

The main change in this version is improved support for working with
continuations:  now we support invoking the same continuation in contexts
that have different types.

Happy hacking!
-Iavor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: How do I build GHC 7.6 from source?

[Iavor Diatchki]

Hello,

perhaps we should have a well-defined place in the repo where we keep the
finger-prints associated with tags and branches in the main repo?
This would make it a lot easier to get to a fully defined
previous/different state.

On this note, could someone send the link to the 7.6 fingerprint?  Ian said
that it is somewhere in the nightly build logs but I don't where to look.

-Iavor



On Thu, Sep 20, 2012 at 7:20 AM, Simon Marlow marlo...@gmail.com wrote:

 On 19/09/2012 02:15, Iavor Diatchki wrote:

 exactly what git's submodule machinery does, so it seems pointless to

   implement the functionality which is already there with a standard
   interface.  Thoughts?

 http://hackage.haskell.org/**trac/ghc/wiki/DarcsConversion#**
 Theperspectiveonsubmoduleshttp://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Theperspectiveonsubmodules


 I have seen this.  Our custom fingerprint solution has the exact same
 drawbacks (because it does the exact same thing as sub-modules), and in
 addition it has the drawback of
1. being a custom non-standard solution,
2. it is not obvious where to find the fingerprint associated with
 a particular branch (which is what lead to my question in the first
 place).



 Well, it doesn't quite have the same drawbacks as submodules, because our
 solution places a burden only on someone who wants to recover a particular
 repository state, rather than on everyone doing development.

 I think it's worth keeping an eye on submodules in case they fix the
 gotchas in the UI, but at the moment it looks like we'd have a lot of
 confused developers, lost work and accidental breakages due to people not
 understanding how submodules work or forgetting to jump through the correct
 hoops.

 I'm not saying fingerprints are a good solution, obviously they only solve
 a part of the problem, but the current tooling for submodules leaves a lot
 to be desired.

 Cheers,
 Simon


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: PolyKind issue in GHC 7.6.1rc1: How to make a kind a functional dependency?

[Iavor Diatchki]

Hello,

On Tue, Sep 18, 2012 at 12:10 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:


 The technically-straightforward thing to do is to add kind application,
 but that's a bit complicated notationally.
 http://hackage.haskell.org/trac/ghc/wiki/ExplicitTypeApplication   Does
 anyone have any other ideas?


I think that the right way to proceed would be to add explicit syntax for
kind abstraction and application (which, I imagine, we already have
internally in GHC).  As for the concrete syntax, I prefer the explicitly
annotated form, even if the :: Kind part is treated completely
syntactically for the moment, because the notation seems compatible with
future generalizations that we might want to do (e.g., the work that
Stephanie, Richard, Connor, and Adam are doing).  So the source Haskell
might look something like this:

type family SingRep (a :: Kind)
type instance SingRep (Nat :: Kind) = Integer

class SingE (a :: Kind) where ...


-Iavor
PS: I just modified the ExplicitTypeApplication wiki page to reflect more
accurately the singletons example.  For those who've seen the old page:  I
changed the 'Sing' data family example, because that family needs an actual
type parameter---it is not enough to just have a kind parameter (the reason
being that we want to write things like Sing 5, where 5 is a type).
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

How do I build GHC 7.6 from source?

[Iavor Diatchki]

Hello,

I was just trying to build the GHC-7.6 branch from source and the build
failed with type-errors, because the libraries used by GHC have moved on
since the release, and sync all just gets the most recent version.

Is there a fingerprint somewhere so that I can checkout the libraries in
a suitable form for building 7.6?

More generally, I run into this problem all the time with people trying to
build the branch I work on, so it really would be nice if we started using
sub-modules to keep track of this dependency.  I talked to folks at ICFP
about this, and one idea was that we could check in the fingerprint for a
branch into the repo, and track the dependencies this way, but this is
exactly what git's submodule machinery does, so it seems pointless to
implement the functionality which is already there with a standard
interface.  Thoughts?

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: How do I build GHC 7.6 from source?

[Iavor Diatchki]

Hello,

On Tue, Sep 18, 2012 at 1:25 PM, Ian Lynagh i...@well-typed.com wrote:

 Why do you want to build 7.6 but not 7.6.1, OOI?

  I was trying to build a different branch which is a fork of 7.6---I
wanted to play around with the profiling suite described in the Core
Diving talk from the Haskell Implementors workshop.


 More generally, I run into this problem all the time with people trying to
  build the branch I work on, so it really would be nice if we started
 using
  sub-modules to keep track of this dependency.  I talked to folks at ICFP
  about this, and one idea was that we could check in the fingerprint
 for a
  branch into the repo, and track the dependencies this way, but this is

 See

 http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate

 The nightly build logs include a fingerprint.


Where are the nightly build logs?


  exactly what git's submodule machinery does, so it seems pointless to

  implement the functionality which is already there with a standard
  interface.  Thoughts?


 http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Theperspectiveonsubmodules


I have seen this.  Our custom fingerprint solution has the exact same
drawbacks (because it does the exact same thing as sub-modules), and in
addition it has the drawback of
  1. being a custom non-standard solution,
  2. it is not obvious where to find the fingerprint associated with a
particular branch (which is what lead to my question in the first place).

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type operators in GHC

[Iavor Diatchki]

Hello,

I think that it would be a mistake to have two pragmas with incompatible
behaviors:  for example, we would not be able to write modules that use
Conal's libraries and, say, the type nats I've been working on.
If the main issue is the notation for arrows, has anoyone played with what
can be done with the current (7.6) system?  I just thought of two
variations that seem to provide a decent notation for writing arrow-ish
programs.  The second one, in particular, mirrors the arrow notation at the
value level, so perhaps that would be enough?

-Iavor


{-# LANGUAGE TypeOperators, KindSignatures #-}
module Test where

import Control.Category

-- Variant 1: Post-fix annotation

type (a --- b) c = c a b

f :: Category c = (x --- y) c - (y --- z) c - (x --- z) c
f = undefined


-- Variant 2: Arrow notation

type a -- (c :: * - * - *) = c a
type c -- b  = c b

infix 2 --
infix 1 --

g :: Category c = (x --c-- y) - (y --c-- z) - (x --c-- z)
g = undefined
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: is this a type lits/nats bug or my incorrect understanding ?

[Iavor Diatchki]

Hello,

the functions on type literals on the master branch are not yet
implemented.   If you want to play around with these kinds of things,
please use the type-nats branch (please note that this is a development
branch so things may occasionally break!).
In the first example, GHC is saying that it can't solve SingI (d :: Nat),
which is because the master branch cannot see that d must be 1.
Similarly, in the second one it does not know about '='.
Both of these should work on the 'type-nats' branch though.

The confusing arity issue in the first example is because of kind a
polymorphism---SingI has one kind argument (e.g., Nat) and one type
argument. (e.g., d) but---at present---GHC renders these in the same way.

Hope this helps, and happy hacking!
-Iavor



On Thu, Aug 23, 2012 at 9:41 PM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 Hello,

 I'm trying to understand how much i can build on top of type literals, so
 as an exercise, i've been trying to see if I can define a type level
 absolute different of two natural numbers

 i have a minimal example that either type checks in a useless way, or
 gives a misleading type errors! (or perhaps i am fundamentally not
 understanding someting)


  here's the gist for the misleading type error version
 (it seems to indicate that SingI arity 2, rather than arity 1)
 https://gist.github.com/3445419

 heres the gist for the version that type checks in a useless way!
 and complains that it doesn't understand that (1=2)
 https://gist.github.com/3445456

 are these bugs in type nats, or am I missing something?

 thanks!
 Carter Schonwald



 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Simple shell scripts

[Iavor Diatchki]

Hello,
this happens because head probably closes the file descriptor after 3
lines, and then the Haskell program tries to write to a closed handle
(i.e., it's stdout is not there anymore).  The best thing to do depends on
the program. One fairly simple option would be to handle the exception, and
do something (perhaps ignore it).
-Iavor

On Mon, Aug 27, 2012 at 10:55 AM, Eric Tanter etan...@dcc.uchile.cl wrote:

 Hi,

 Here is a simple shell script (upper.hs):

 import Data.Char
 main = interact $ map toUpper

 which composes fine with other scripts:

 bash-3.2$ yes | head -n 3 | runghc upper.hs
 Y
 Y
 Y

 but not always:

 bash-3.2$ yes | runghc upper.hs | head -n 3
 Y
 Y
 Y
 stdout: hFlush: resource vanished (Broken pipe)

 Any idea why this error occurs/how to avoid it?

 (running just:
 yes | runghc upper.hs
 gives the expected infinite stream of Ys)

 Thanks!

 -- Éric

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends

[Iavor Diatchki]

Hello,

I also completely agree with Bryan's point which is why I usually don't add
upper bounds on the dependencies of the packages that I maintain---I find
that the large majority of updates to libraries tend to be backward
compatible, so being optimistic seems like a good idea.

By the way, something I encounter quite often is a situation where two
packages both build on Hacakge just fine, but are not compatible with each
other.  Usually it goes like this:

  1. Package A requires library X = V  (typically, because it needs a bug
fix or a new feature).
  2. Package B requires library X  V (typically, because someone added a
conservative upper bound that needs to be updated).

Trying to use A and B together leads to failure, which is usually resolved
by having to install B manually, and remove it's upper bound by hand.  This
is rather unfortunate, because not only it's inconvenient but, also, now
there is no released version of package B that you can explicitly depend on.

-Iavor



On Mon, Aug 20, 2012 at 7:11 AM, Brent Yorgey byor...@seas.upenn.eduwrote:

 On Thu, Aug 16, 2012 at 06:07:06PM -0400, Joey Adams wrote:
  On Wed, Aug 15, 2012 at 3:38 PM, Bryan O'Sullivan b...@serpentine.com
 wrote:
   I propose that the sense of the recommendation around upper bounds in
 the
   PVP be reversed: upper bounds should be specified only when there is a
 known
   problem with a new version of a depended-upon package.
 
  I, too, agree.  Here is my assortment of thoughts on the matter.
 
  Here's some bad news: with cabal 1.14 (released with Haskell Platform
  2012.2), cabal init defaults to bounds like these:
 
build-depends:   base ==4.5.*, bytestring ==0.9.*,
http-types ==0.6.*

 I'm not sure why you think this is bad news.  I designed this to
 conform exactly to the current PVP.  If the PVP is changed then I will
 update cabal init to match.

 -Brent

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Call to arms: lambda-case is stuck and needs your help

[Iavor Diatchki]

Hello,
I am late to the discussion and this is not entirely on topic, for which I
apologize, but I like the multi-branch case syntax someone mentioned
earlier:

Writing:

 case
   | p1 - e1
   | p2 - e2
   | ...

desugars to:

 case () of
   _ | p1 - e2
 | p2 - e2
 | ...

-Iavor
PS:  I think it also makes sense to use if instead of case for this.
 Either way,  I find myself writing these kind of cases quite often, so
having the sugar would be nice.


On Tue, Jul 10, 2012 at 8:55 AM, Chris Smith cdsm...@gmail.com wrote:

 On Tue, Jul 10, 2012 at 5:53 AM, Wolfgang Jeltsch
 g9ks1...@acme.softbase.org wrote:
  If we use \case for functions, we should use proc case for arrows;
  if we use \of for functions, we should use proc of for arrows.
 
  By the way, is proc a layout herald already?

 No, proc is not a layout herald.  The normal pattern is to use a do in
 the command part of the proc syntax, so it's do that introduces the
 layout.  So proc of would fit in cleanly as a way to do proc with
 multiple patterns.  Or proc case, but again that's just a really
 ugly language wart, IMO uglier than just writing out the longhand
 version of proc x - case x of.

 --
 Chris Smith

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Creating stubs statically

[Iavor Diatchki]

Hi Paolo,

I agree that this would be useful.  In fact, a couple of years ago I
implemented this in GHC, but after some discussion folks were not convinced
that it's a good idea.  I don't remember the details but as far as I recall
we agreed to disagree :-)   The e-mail thread is over here:

http://www.haskell.org/pipermail/glasgow-haskell-users/2010-March/018575.html

The patch should be there too, but I suspect that GHC has moved on since
than, but perhaps there's still something useful there.

-Iavor


On Thu, Jul 5, 2012 at 5:13 AM, Paolo Capriotti p.caprio...@gmail.comwrote:

 As explained in detail here:
 http://www.haskell.org/pipermail/ffi/2012-June/001867.html,
 it may be useful to have a form of foreign declaration that creates a
 static stub for a haskell function without exporting a symbol.

 Here is a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/7048
 .

 It is not particularly clear how such a declaration would look like
 syntactically. In the ticket I proposed the following:

 foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback

 but please do suggest better alternatives.

 It would also be useful to see some use cases of this new form of
 declaration. Library binding authors: would this be a welcome addition
 for you?

 BR,
 Paolo

 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Fundeps and overlapping instances

[Iavor Diatchki]

Hello,

There is no problem if an instances uses a type family in it's
assumption---the instances should be accepted only if GHC can see enough of
the definition of the type family to ensure that the functional dependency
holds.  This is exactly the same as what it would do to check that a super
class constraint holds.

-Iavor


On Wed, May 30, 2012 at 11:14 PM, Etienne Laurin etie...@atnnn.com wrote:

 2012/5/31 Iavor Diatchki iavor.diatc...@gmail.com:
  Hello,
 
  the notion of a functional dependency is well established, and it was
 used
  well before it was introduced to Haskell (for example, take a look
  at http://en.wikipedia.org/wiki/Functional_dependency).  So I'd be
 weary to
  redefine it lightly.

 Indeed, GHC's functional dependencies are not the same. I see you have
 already talked about this on the GHC bug tracker.

 http://hackage.haskell.org/trac/ghc/ticket/1241

  1. Check that an instance is consistent with itself.  For example, this
 should be rejected:
 
  instance C a b
 
  because it allows C Int Bool and C Int Char which violate the functional
 dependency.

 This check may not always be as straightforward. When would this be a
 valid instance?

 instance K a b ⇒ C a b

 With a few extra extensions, K could be a type family.

 C currently has the kind (a - b - Constraint), with no mention of
 functional dependencies. Perhaps the kind of C should include the
 functional dependencies of C?

 Etienne Laurin

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Fundeps and overlapping instances

[Iavor Diatchki]

Hello,

On Wed, Jul 7, 2010 at 2:14 PM, Simon Peyton-Jones simo...@microsoft.comwrote:

  We can’t permit overlap for type families because it is *unsound *to do
 so (ie you can break “well typed programs don’t go wrong”). But if it’s
 unsound for type families, it would not be surprising if it was unsound for
 fundeps too.  (I don’t think anyone has done a soundness proof for fundeps
 + local constraints + overlapping instances, have they?)  And indeed I
 think it is.


It would be unsound only if the functional dependencies are not checked
properly (which, as you say, is similar to the check for type families).
 Here is an example of a sound overlap:

class C a b | a - b
instance C String Char
instance C [a] a

Indeed, it would be OK to allow this sort of overlap for type families too,
although there it would not be useful, because the more general case
already provides the same information as the more specific one.   In the
case of overlapping instances, the more specific instance might provide a
different implementation for the class methods, as usual.  (disclaimer:
 I'm not a fan of overlapping instancesI think that some of
the alternative proposals, such as the instance chains work, are nicer, but
one would have to do same sort of checks there too).


**

 Imagine a system “FDL” that has functional dependencies and local type
 constraints.  The big deal about this is that you get to exploit type
 equalities in **given** constraints.  Consider Oleg’s example, cut down a
 bit:

 ** **

 class C a b | a - b

 instance C Int Bool

 newtype N2 a = N2 (forall b. C a b = b)

 ** **

 t2 :: N2 Int

 t2 = N2 True

 ** **

 We end up type-checking (True :: forall b. C Int b = b).   From the
 functional dependency we know that (b~Bool), so the function should
 typecheck.  GHC rejects this program; FDL would not.

 ** **

 But making use of these extra equalities in “given” constraints is quite
 tricky.  To see why look first at Example 1:  

 ** **

 *module* X where

class C a b | a - b

 ** **

data T a where

  MkT :: C a b = b - T a

 ** **

 ** **

 *module* M1 where

   import X

   instance C Int Char where ...

   f :: Char - T Int

   f c = MkT c

 ** **

 *module* M2 where

   import X

   instance C Int Bool

   g :: T Int - Bool

   g (MkT x) = x

 ** **

 *module* Bad where

   import M1

   import M2

   bad :: Char - Bool

   bad = g . f

 ** **

 This program is unsound: it lets you cast an Int to a Bool; result is a
 seg-fault. 


 

 You may say that the problem is the inconsistent functional dependencies
 in M1 and M2.  But GHC won’t spot that.  For type families, to avoid this
 we “*eagerly*” check for conflicts in type-family instances.  In this
 case the conflict would be reported when compiling module Bad, because that
 is the first time when both instances are visible together.

 **

So any FDL system should also make this eager check for conflicts.


I completely agree with this---we should never allow inconsistent instances
to exist in the same scope.



 

 ** **

 What about overlap?  Here’s Example 2: 

 ** **

 {-# LANGUAGE IncoherentInstances #-}

 *module* Bad where

   import X

   -- Overlapping instances

   instance C Int Bool -- Instance 1

   instance C a [a]   -- Instance 2

 ** **

   f :: Char - T Int

   f c = MkT c   -- Uses Instance 1

 ** **

   g :: T a - a

   g (MkT x) = x-- Uses Instance 2

 ** **

   bad :: Char - Int

   bad = g . f

 **


As in the above example, this program violates the functional dependency on
class C and should be rejected, because the two instances are not
consistent with each other.



 But at the moment GHC makes an exception for **existentials**.  Consider
 Example 3:

 ** **

   class C a b | a - b

 ** **

   -- Overlapping instances

   instance C Int Bool -- Instance 1

   instance C a [a]   -- Instance 2

 ** **

   data T where

 MkT :: C a b = a - b - T

 ** **

   f :: Bool - T

   f x = MkT (3::Int) x  -- Uses Instance 1

 ** **

   g :: T - T

   g (MkT n x) = MkT n (reverse x)   -- Uses Instance 2

 ** **

   bad :: Bool - T

   bad = g . f

 ** **

 This program is malformed for the same reason as the previous one: the two
instances violate the functional dependency on the class.



 ** **

 But even nuking IncoherentInstances altogether is not enough.  Consider
 this variant of Example 3, call it Example 4:

  *module* M where

   class C a b | a - b

 ** **

   instance C a [a]   -- Instance 2

 ** **

   data T where

 MkT :: C a b = a - b - T

 ** **

   g :: T - T

   g (MkT n x) = MkT n (reverse x)   -- Uses Instance 2 

 ** **

 *module* 

Re: [Haskell-cafe] Fundeps and overlapping instances

[Iavor Diatchki]

Hello,

the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look at
http://en.wikipedia.org/wiki/Functional_dependency).  So I'd be weary to
redefine it lightly.
Note that placing a functional dependency constraint is just one way to
allow class methods that don't mention all class variables.  If the
instances for the class do not satisfy the functional dependency (as in
your example), you can refactor your class hierarchy, instead.  For example:

class D a where  k :: a
class D a = C a b where  f :: a - b

instance D Int where k = 2
instance C Int b where f _ = Nothing

I hope this helps,
-Iavor



On Wed, May 30, 2012 at 1:31 PM, Etienne Laurin etie...@atnnn.com wrote:

 Hello,

 I disagree with your example.

  1. Check that an instance is consistent with itself.  For example, this
  should be rejected:
 
  instance C a b
 
  because it allows C Int Bool and C Int Char which violate the functional
  dependency.

 Functional dependencies are not used to pick types, they are used to
 pick instances.

 class C a b | a → b where
  k ∷ a
  f ∷ a → Maybe b

 The functional dependency allows you to have a method such as k that
 doesn't use all the arguments of the class.

 I expect to be able to make a instance that works for any b.

 instance C Int b where
  k = 2
  f _ = Nothing

 Etienne Laurin

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data Kinds and superfluous (in my opinion) constraints contexts

[Iavor Diatchki]

Hi,

It is quite likely that the error that you are getting with approach 2 is
because when you are constructing the `Combinator` value, there is not
enough type information to figure out how to solve the constraint (and it
sounds like this happens because there is not enough type information to
reduce the type function).   The fix depends on the concrete program but it
might be something as simple as adding a type signature somewhere.

Note, again, that it is not sufficient to know that the constraint could be
solved for any type of the appropriate kind: we need to actually solve the
constraint so that we can determine what the program should do.

The difference between the two `data` definitions is that the second one
uses a technique called _existential quantification_, which hides the
type `s`.  If this type appears nowhere else in the surrounding expressions
and the constraint could not be solved, then the constraint is ambiguous.
I could explain that in more detail, if it is unclear please ask.

Happy hacking,
-Iavor







On Thu, May 17, 2012 at 4:18 AM, Serguey Zefirov sergu...@gmail.com wrote:

 I can write something like that:

 data Combinator s a where
Combinator :: Class (TypeFamExpr s) = ... - Combinator s a

 And I cannot write something like that:
 data Combinator a where
Combinator :: Class (TypeFamExpr s) = .mentions s.. - Combinator a

 If my TypeFamExpr does have type variables, I get a wild type error
 messages that mentions partially computed TypeFamExpr as an argument
 to constraint.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Data Kinds and superfluous (in my opinion) constraints contexts

[Iavor Diatchki]

Hello,

The context in your example serves an important purpose: it records the
fact that the behavior of the function may differ depending on which type
it is instantiated with.   This is quite different from ordinary
polymorphic functions, such as `const` for example,  which work in exactly
the same way, no matter how you instantiate them.   Note that it doesn't
matter that we can solve the constraint for all types of kind `D`---the
constraint is there because we can't solve it _uniformly_ for all types.

-Iavor
PS: As an aside, these two forms of polymorphism are sometimes called
parametric (when functions work in the same way for all types), and
ad-hoc (when the behavior depends on which type is being used).




On Sun, May 6, 2012 at 9:48 AM, Serguey Zefirov sergu...@gmail.com wrote:

 I decided to take a look at DataKinds extension, which became
 available in GHC 7.4.

 My main concerns is that I cannot close type classes for promoted data
 types. Even if I fix type class argument to a promoted type, the use
 of encoding function still requires specification of context. I
 consider this an omission of potentially very useful feature.

 Example is below.

 -
 {-# LANGUAGE TypeOperators, DataKinds, TemplateHaskell, TypeFamilies,
 UndecidableInstances #-}
 {-# LANGUAGE GADTs #-}

 -- a binary numbers.
 infixl 5 :*
 data D =
D0
|   D1
|   D :* D
deriving Show

 -- encoding for them.
 data EncD :: D - * where
EncD0 :: EncD D0
EncD1 :: EncD D1
EncDStar :: EncD (a :: D) - EncD (b :: D) - EncD (a :* b)

 -- decode of values.
 fromD :: D - Int
 fromD D0 = 0
 fromD D1 = 1
 fromD (d :* d0) = fromD d * 2 + fromD d0

 -- decode of encoded values.
 fromEncD :: EncD d - Int
 fromEncD EncD0 = 0
 fromEncD EncD1 = 1
 fromEncD (EncDStar a b) = fromEncD a * 2 + fromEncD b

 -- constructing encoded values from type.
 -- I've closed possible kinds for class parameter (and GHC
 successfully compiles it).
 -- I fully expect an error if I will try to apply mkD to some type
 that is not D.
 -- (and, actually, GHC goes great lengths to prevent me from doing that)
 -- By extension of argument I expect GHC to stop requiring context
 with MkD a where
 -- I use mkD constant function and it is proven that a :: D.
 class MkD (a :: D) where
mkD :: EncD a
 instance MkD D0 where
mkD = EncD0
 instance MkD D1 where
mkD = EncD1
 -- But I cannot omit context here...
 instance (MkD a, MkD b) = MkD (a :* b) where
mkD = EncDStar mkD mkD

 data BV (size :: D) where
BV :: EncD size - Integer - BV size

 bvSize :: BV (size :: D) - Int
 bvSize (BV size _) = fromEncD size

 -- ...and here.
 -- This is bad, because this context will arise in other places, some of
 which
 -- are autogenerated and context for them is incomprehensible to human
 -- reader.
 -- (they are autogenerated precisely because of that - it is tedious
 and error prone
 -- to satisfy type checker.)
 fromIntgr :: Integer - BV (size :: D) -- doesn't work, but desired.
 -- fromIntgr :: MkD size = Integer - BV (size :: D) -- does work,
 but is not that useful.
 fromIntgr int = BV mkD int

 -

 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: What is a punctuation character?

[Iavor Diatchki]

Hello,

So I looked at what GHC does with Unicode and to me it is seems quite
reasonable:

* The alphabet is Unicode code points, so a valid Haskell program is
simply a list of those.
* Combining characters are not allowed in identifiers, so no need for
complex normalization rules: programs should always use the short
version of a character, or be rejected.
* Combining characters may appear in string literals, and there they
are left as is without any modification (so some string literals may
be longer than what's displayed in a text editor.)

Perhaps this is simply what the report already states (I haven't
checked, for which I apologize) but, if not, perhaps we should clarify
things.

-Iavor
PS:  I don't think that there is any need to specify a particular
representation for the unicode code-points (e.g., utf-8 etc.) in the
language standard.





On Fri, Mar 16, 2012 at 6:23 PM, Iavor Diatchki
iavor.diatc...@gmail.com wrote:
 Hello,
 I am also not an expert but I got curious and did a bit of Wikipedia
 reading.  Based on what I understood, here are two (related) questions
 that it might be nice to clarify in a future version of the report:

 1. What is the alphabet used by the grammar in the Haskell report?  My
 understanding is that the intention is that the alphabet is unicode
 codepoints (sometimes referred to as unicode characters).  There is no
 way to refer to specific code-points by escaping as in Java (the link
 that Gaby shared), you just have to write the code-points directly
 (and there are plenty of encodings for doing that, e.g. UTF-8 etc.)

 2. Do we respect unicode equivalence
 (http://en.wikipedia.org/wiki/Canonical_equivalence) in Haskell source
 code.  The issue here is that, apparently, some sequences of unicode
 code points/characters are supposed to be morally the same.  For
 example, it would appear that there are two different ways to write
 the Spanish letter ñ: it has its own number, but it can also be made
 by writing n followed by a modifier to put the wavy sign on top.

 I would guess that implementing unicode equivalence  would not be
 too hard---supposedly the unicode standard specifies a text
 normalization procedure.  However, this would complicate the report
 specification, because now the alphabet becomes not just unicode
 code-points, but equivalence classes of code points.

 Thoughts?

 -Iavor






 On Fri, Mar 16, 2012 at 4:49 PM, Ian Lynagh ig...@earth.li wrote:

 Hi Gaby,

 On Fri, Mar 16, 2012 at 06:29:24PM -0500, Gabriel Dos Reis wrote:

 OK, thanks!  I guess a take away from this discussion is that what
 is a punctuation is far less well defined than it appears...

 I'm not really sure what you're asking. Haskell's uniSymbol includes all
 Unicode characters (should that be codepoints? I'm not a Unicode expert)
 in the punctuation category; I'm not sure what the best reference is,
 but e.g. table 12 in
    http://www.unicode.org/reports/tr44/tr44-8.html#Property_Values
 lists a number of Px categories, and a meta-category P Punctuation.


 Thanks
 Ian


 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: What is a punctuation character?

[Iavor Diatchki]

Hello,
I am also not an expert but I got curious and did a bit of Wikipedia
reading.  Based on what I understood, here are two (related) questions
that it might be nice to clarify in a future version of the report:

1. What is the alphabet used by the grammar in the Haskell report?  My
understanding is that the intention is that the alphabet is unicode
codepoints (sometimes referred to as unicode characters).  There is no
way to refer to specific code-points by escaping as in Java (the link
that Gaby shared), you just have to write the code-points directly
(and there are plenty of encodings for doing that, e.g. UTF-8 etc.)

2. Do we respect unicode equivalence
(http://en.wikipedia.org/wiki/Canonical_equivalence) in Haskell source
code.  The issue here is that, apparently, some sequences of unicode
code points/characters are supposed to be morally the same.  For
example, it would appear that there are two different ways to write
the Spanish letter ñ: it has its own number, but it can also be made
by writing n followed by a modifier to put the wavy sign on top.

I would guess that implementing unicode equivalence  would not be
too hard---supposedly the unicode standard specifies a text
normalization procedure.  However, this would complicate the report
specification, because now the alphabet becomes not just unicode
code-points, but equivalence classes of code points.

Thoughts?

-Iavor






On Fri, Mar 16, 2012 at 4:49 PM, Ian Lynagh ig...@earth.li wrote:

 Hi Gaby,

 On Fri, Mar 16, 2012 at 06:29:24PM -0500, Gabriel Dos Reis wrote:

 OK, thanks!  I guess a take away from this discussion is that what
 is a punctuation is far less well defined than it appears...

 I'm not really sure what you're asking. Haskell's uniSymbol includes all
 Unicode characters (should that be codepoints? I'm not a Unicode expert)
 in the punctuation category; I'm not sure what the best reference is,
 but e.g. table 12 in
    http://www.unicode.org/reports/tr44/tr44-8.html#Property_Values
 lists a number of Px categories, and a meta-category P Punctuation.


 Thanks
 Ian


 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: [Haskell-cafe] ANN: hp2html, a tool for viewing GHC heap-profiles

[Iavor Diatchki]

Hello,

On Mon, Feb 20, 2012 at 7:03 PM, Johan Tibell johan.tib...@gmail.comwrote:


 Looks really nice.

Thanks!


 The hovering behavior is nice, but I'd like to see
 the legend as well. It makes it quicker when you want to get a quick
 overview of what types there are, as the eye can travel back-and-forth
 between the graph and the legend.


I started with the legend but it was too big on the program that i was
profiling, so i switched to the hovering mode. I agree that it is not
optimal. Perhaps there's a way to instruct flot to show only some of the
entries or, better, order them in some useful way.  I'm no flot expert, so
ideas (or patches) on how to do it would be most appreciated!

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] ANN: hp2html, a tool for viewing GHC heap-profiles

[Iavor Diatchki]

Hello,

On Mon, Feb 20, 2012 at 7:03 PM, Johan Tibell johan.tib...@gmail.comwrote:


 Looks really nice.

Thanks!


 The hovering behavior is nice, but I'd like to see
 the legend as well. It makes it quicker when you want to get a quick
 overview of what types there are, as the eye can travel back-and-forth
 between the graph and the legend.


I started with the legend but it was too big on the program that i was
profiling, so i switched to the hovering mode. I agree that it is not
optimal. Perhaps there's a way to instruct flot to show only some of the
entries or, better, order them in some useful way.  I'm no flot expert, so
ideas (or patches) on how to do it would be most appreciated!

-Iavor
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Changes to Typeable

[Iavor Diatchki]

Hello,

On Mon, Feb 13, 2012 at 5:32 PM, Edward Kmett ekm...@gmail.com wrote:

 There are fewer combinators from commonly used classes for working with
 the left argument of a bifunctor, however.


I think that the bifunctor part of Bas's version is a bit of a red herring.
 What I like about it is that it overloads exactly what needs to be
overloaded---the representation of the type---without the need for any fake
parameters.  To make things concrete, here is some code:

 newtype TypeRepT t = TR TypeRep

 class Typeable t where
   typeRep :: TypeRepT t

 instacne Typeable Int where typeRep = TR type_rep_for_int
 instance Typeable []  where typeRep = TR type_rep_for_list

The two formulations support exactly the same interface (you can define
`Proxy` and the proxied `typeRep` in terms of this class) so I wouldn't say
that the one is easier to use that the other, but I think that this
formulation is slightly simpler because it avoids the dummy parameter to
typeRep.

-Iavor
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Changes to Typeable

[Iavor Diatchki]

Hello,

I like Bas's variation on the design (except, perhaps, for the name
Tagged ;)  It captures exactly what we are trying to do: the
dictionary for Typeable becomes simply the run-time representation of
the type.  Coincidentally, this is exactly the same as what I am using
to link value level numbers/strings to type-level numbers/symbols, on
the type-nats branch of GHC.  I wonder if it might make sense to unify
the two designs?

-Iavor
PS: I wouldn't worry too much about breaking existing code, as long as
derived Typeable instances continue to work---I never provide custom
ones and, in fact, I think that GHC should no allow them or, at least,
give a stern warning when it sees one.

On Fri, Feb 10, 2012 at 4:35 PM, Bas van Dijk v.dijk@gmail.com wrote:
 Or don't use an argument at all:

 class Typeable t where
  typeRep :: Tagged t TypeRep

 newtype Tagged s b = Tagged { unTagged :: b }

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Holes in GHC

[Iavor Diatchki]

Hello,

On Wed, Jan 25, 2012 at 7:21 AM, Thijs Alkemade thijsalkem...@gmail.com wrote:
 Also, we have a confusing problem when type checking a module. Above,
 we showed the result of :t map __ __ in ghci. However, if we put f
 = map __ __ in a module, we get:

 tcRnModule: [(f.hs:1:9-10, GHC.Prim.Any * - b),
 (f.hs:1:12-13, [GHC.Prim.Any *])]

 If I read GHC.Prim.Any * as forall a. a, then this is not correct: the
 GHC.Prim.Any * in both holes should have the same type. We assume it
 shows up because the type that should be there does not occur in the
 type signature of f (as it's just [b]), but so far we've been unable
 to figure out why this behavior is different in interactive mode. Does
 someone have an idea about what to do to avoid the introduction of
 these GHC.Prim.Any * types?

The type `Any` is just an ordinary monomorphic type, (e.g., like
Int`).  It is used to stand in for types that do not matter and may
be thought of a special case of defaulting (i.e. resolving type
ambiguity be selecting concrete types).  How it is used  is probably
best illustrated with an example (you've found one, but I'll use a
slightly simpler one).  Consider the expression `null []`.  It clearly
has the type Bool, because `null` takes a list and returns a Bool, and
`[]` is a list.  However, there is nothing that forces the list
elements to be of one type or another, so we cannot infer the full
type of `[]`---in some sense, the expression `null []` is of type
`forall a. Bool` where `a` is the type of the list elements.
Inferring this type would not be useful because we have no way to
specify what the `a` should be, and furthermore, it does not matter!
So, whenever GHC infers a type `forall a. P = t` where `a` does not
appear in `P` or `t`, it knows that the `a` does not matter, so t
simply defaults it to `Any`.


 Examples:

 *Main :t [__, ()]
 tcRnExpr2: [(interactive:1:2-3, ())]
 [__, ()] :: [()]

 *Main :t map __ __
 tcRnExpr2: [(interactive:1:5-6, a0 - b), (interactive:1:8-9, [a0])]
 map __ __ :: [b]

 Any feedback on this design would be appreciated. We would like to
 know if this is something that could be considered to be added to GHC,
 and what your requirements for that are.

I was just wondering if you could get the same behavior by using
`undefined`?  For example,

:t [undefined, ()]
[()]

-Iavor

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Type operators in GHC

[Iavor Diatchki]

Hello,

My preference would be to change the behavior of the TypeOperator
flag.  Here is my reasoning:
  * Having two operators with slightly different meanings would be
very confusing, not just for beginners but for everyone.
  * The two behaviors are not compatible in the sense that they can't
co-exist in the same language standard.  So something is bound to
break later on, and it'd be better to update packages now, before we
have grown a bigger code base that uses two incompatible extensions.
  * As I see it, having type-operator variables is useful in (some)
APIs (e.g., the parameters of the arrow classes), while type-operator
constructors are useful in defining concrete types/type-functions
(e.g., concrete implementations of arrows).  I expect that there are a
lot more concrete implementations than APIs (this is the whole point
of abstraction, after all!) so I think that it is a good trade-off to
use the nicer notation for the more common case.

-Iavor
PS: In the interest of fairness, I am also partial to the new notation
because I've been working on support for arithmetic at the type-level,
and seem to have developed a bit of an allergy to typing :+:, :*:, :=
etc all the time :-)


On Wed, Jan 18, 2012 at 9:36 AM, Brandon Allbery allber...@gmail.com wrote:
 On Wed, Jan 18, 2012 at 10:42, Brent Yorgey byor...@seas.upenn.edu wrote:

 I'm not sure at this point which way I would lean on the issue.
 Having infix type constructors that don't have to start with : is
 something I would like, too.  But I just thought I would point out
 that code like tc192 is not as esoteric as you seem to think.


 I seem to recall @src outputting a Prelude definition for something
 (Monoid?) that used (*) as a type variable.

 --
 brandon s allbery                                      allber...@gmail.com
 wandering unix systems administrator (available)     (412) 475-9364 vm/sms


 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users