Re: idea: tool to suggest adding imports

[Erik Hesselink]

I wrote halberd a while ago. It was mostly as an example of using the
haskell-names and haskell-packages packges (combined with
haskell-src-exts) that Roman Cheplyaka was working on at the time,
combined with a useful tool that I wanted for myself. The downside is
that haskell-packages doesn't use the same package database as ghc, so
you had to compile the packages twice: once with ghc, and once with
haskell-packages. That made the task of actually integrating it with
an editor in a useful way for large projects seem pretty hairy, so I
didn't continue working on it. Later there was a big API change in
haskell-names that I never took the time to support, so it currently
doesn't support the newest versions of its dependencies.

Let me know if you (or anyone else) wants to work on it or rip out
useful parts. Perhaps I can help out a bit.

Regards,

Erik

On 18 March 2016 at 20:12, Harendra Kumar  wrote:
> That's cool, I'd love to have that feature in my editor. Have you seen this:
>
> https://hackage.haskell.org/package/halberd
>
> The readme says:
>
> ---cut---
>
> Halberd is a tool to help you add missing imports to your Haskell source
> files. With it, you can write your source without imports, call Halberd, and
> just paste in the import lines.
>
> Currently, it tries to automatically choose an import if there is a single
> sensible option. If it can't, it will prompt you with a simple menu. After
> running, it prints the imports, which you need to copy manually. Editor
> integration is planned.
>
> ---cut---
>
>
> I have been thinking of exactly the same problem. That's how found this. I
> have not tried it yet but this could be a starting point even if its not
> working perfectly. In the best case you will have to just do the editor
> integration part.
>
>
> -harendra
>
> On 18 March 2016 at 23:57, John Williams  wrote:
>>
>> I have an idea for a tool I'd like to implement, and I'm looking for
>> advice on the best way to do it.
>>
>> Ideally, I want to write an Emacs extension where, if I'm editing Haskell
>> code and I try to use a symbol that's not defined or imported, it will try
>> to automatically add an appropriate import for the symbol. If instance, if I
>> have "import Data.Maybe (isNothing)" in my module, and I try to call
>> "isJust", the extension would automatically change the import to "import
>> Data.Maybe (isJust, isNothing)".
>>
>> The Emacs part is easy, but the Haskell part has me kind of lost.
>> Basically I want to figure out how to heuristically resolve a name, using an
>> existing set of imports as hints and constraints. The main heuristic I'd
>> like to implement is that, if some symbols are imported from a module M,
>> consider importing additional symbols from M. A more advanced heuristic
>> might suggest that if a symbol is exported from a module M in a visible
>> package P, the symbol should be imported from M. Finally, if a symbol is
>> exported by a module in the Haskell platform, I'd like to suggest adding the
>> relevant package as a dependency in the .cabal and/or stack.yaml file, and
>> adding an import for it in the .hs file.
>>
>> Here are some implementation options I'm considering:
>>
>> 1. Add a ghci command to implement my heuristics directly, since ghc
>> already understands modules, packages and import statements.
>> 2. Load a modified version of the source file into ghci where imports like
>> "import M (...)" are replaced with "import M", and parse the error messages
>> about ambiguous symbols.
>> 3. Write a separate tool that reads Haskell imports and duplicates ghc and
>> cabal's name resolution mechanisms.
>> 4. Write a tool that reads Haskell imports and suggests imports from a
>> list of commonly imported symbols, ignoring which packages are actually
>> visible.
>>
>> Right now the options that look best to me are 2 and 4, because the don't
>> require me to understand or duplicate big parts of ghc, but if modifying ghc
>> isn't actually that hard, then maybe 1 is the way to go. Option 3 might be a
>> good way to go if there are libraries I can use to do the hard work for me.
>>
>> Any thoughts?
>>
>> ___
>> 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
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: GHC 8.0.1 status

[Erik Hesselink]

I've found what I believe to be a regression in GHC 8 rc2 [1], and the
wiki says to yell if I want to bring it to the attention of GHC
developers. So this is me yelling, I guess :) I'm not sure if this bug
is important enough to be included, but I think it would be good for
someone to look at it and make that call. It's at least breaking one
package that I maintain (but it can be worked around).

Erik

[1] https://ghc.haskell.org/trac/ghc/ticket/11662

On 27 February 2016 at 14:57, Ben Gamari  wrote:
> tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated.
>The release schedule is being pushed back a bit.
>
>
> Hello everyone,
>
> As you likely know we are currently in the depths of the 8.0 release. In
> fact, under more ideal circumstances I would probably be cutting another
> release candidate right now instead of writing this email, in
> preparation for a final release next week or so.
>
> However, our world is far from ideal as evidenced by the number
> [1] of significant bugs present on the 8.0 branch. This isn't altogether
> unexpected; we knew we were taking a bit of a risk in merging so many
> high-impact patches in one release. However, we thought that given a
> longer-than-usual period between first-candidate and the final release,
> we'd have enough time to smooth out the wrinkles. Sadly, this has taken
> a bit longer than we anticipated.
>
> Of course, the last thing we want is to push a known buggy release out
> the door. Consequently, we won't be delivering the 8.0.1 release next
> week as originally planned. Instead, we'll be pushing the release back
> by about three weeks. This will give developers a bit more breathing
> room in which to work out the remaining issues. Hopefully in a few weeks
> the tree will be in such a state that we can push out yet another
> candidate which, with luck, will be the last before the release.
>
> If you'd like to expedite the process (and have fun in the process), you
> could do worse than to having a look at Trac [1], choosing a bug of your
> liking, and trying your hand at solving it.
>
> Thanks to everyone who has contributed to this effort thusfar.
> If you have any questions about the release process or how you can help,
> don't hesistate to ask.
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
>
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3

[Erik Hesselink]

I made an unofficial OS X build again [0]. I'd be happy to offer my
services to make an official build as well if people are interested
and know how to get this on the ghc download page.

Regards,

Erik

[0] 
http://www.reddit.com/r/haskell/comments/2rims6/ghc_7100rc1_build_for_mac_os_x/

On Thu, Mar 19, 2015 at 2:53 PM, George Colpitts
george.colpi...@gmail.com wrote:
 Do we have an ETA for a MacOS binary distribution?

 Regards
 George

 On Mon, Mar 16, 2015 at 5:30 PM, Austin Seipp aus...@well-typed.com wrote:

 We are pleased to announce the third release candidate for GHC 7.10.1:

 https://downloads.haskell.org/~ghc/7.10.1-rc3
 https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/

 This includes the source tarball and bindists for Windows and Debian
 Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow
 soon. These binaries and tarballs have an accompanying
 SHA256SUMS file signed by my GPG key id (0x3B58D86F).

 We plan to make the 7.10.1 final release at the end of this week - so
 please test as much as possible; bugs are much cheaper if we find them
 before the release!

 The list of issues we plan on fixing can always be found in an
 up-to-date form here:
 https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1

 --
 Regards,

 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



 ___
 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: ValidateMonoLiterals - Initial bikeshed discussion

[Erik Hesselink]

On Fri, Feb 6, 2015 at 2:49 PM, Dominique Devriese
dominique.devri...@cs.kuleuven.be wrote:
 Agreed.  For the idea to scale, good support for type-level
 programming with Integers/Strings/... is essential.  Something else
 that would be useful is an unsatisfiable primitive constraint
 constructor `UnsatisfiableConstraint :: String - Constraint` that can
 be used to generate custom error messages. Then one could write
 something like

   type family MustBeTrue (t :: Bool) (error :: String) :: Constraint
   type family MustBeTrue True _ = ()
   type family MustBeTrue False error = UnsatisfiableConstraint error

   type family MustBeEven (n :: Nat) :: Constraint
   type family MustBeEven n = MustBeTrue (IsEven n) (Error in Even
 literal :' ++ show n ++ ' is not even!)

   instance (KnownNat n, MustBeEven n) = HasIntegerLiteral Even n where ...

Note that there is a trick to fake this with current GHC: you can
write an equality constraint that is false, involving the type level
string:

   type family MustBeTrue False error = (() ~ error)

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

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2

[Erik Hesselink]

On Mon, Feb 2, 2015 at 9:37 AM, Herbert Valerio Riedel h...@gnu.org wrote:
 Hi Mark,

 On 2015-01-28 at 04:31:29 +0100, Mark Lentczner wrote:
 I've just built a bindist under 10.10, but just normal not expressly llvm.
 I'll test this in a bit then post it -- but might be sometime tomorrow
 before it is up.

 How's progress on this btw? Are you also working on a GHC 7.8.4 OSX
 bindist by any chance?

I made a bindist of RC2 (just like I did for RC1) which is here [1].
This was built on 10.9, without anything special for llvm. If anyone
wants me to try something or produce a different build, please let me
know.

Erik

[1] 
https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nVmJ3WElQZW81b1Uexport=download
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1

[Erik Hesselink]

I made a Mac OS X build. If people want to try it out, you can
download it from [0]. Let me know if you run into any issues.

Regards,

Erik

[0] 
https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nNFR4WUVNZzRtbGsexport=download

On Tue, Dec 23, 2014 at 3:36 PM, Austin Seipp aus...@well-typed.com wrote:
 We are pleased to announce the first release candidate for GHC 7.10.1:

 https://downloads.haskell.org/~ghc/7.10.1-rc1/

 This includes the source tarball and bindists for 64bit/32bit Linux
 and Windows. Binary builds for other platforms will be available
 shortly. (CentOS 6.5 binaries are not available at this time like they
 were for 7.8.x). These binaries and tarballs have an accompanying
 SHA256SUMS file signed by my GPG key id (0x3B58D86F).

 We plan to make the 7.10.1 release sometime in February of 2015. We
 expect another RC to occur during January of 2015.

 Please test as much as possible; bugs are much cheaper if we find them
 before the release!

 --
 Regards,

 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: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS

[Erik Hesselink]

It seems to be building a very old cpphs (1.13) with a new version of
cabal. cpphs-1.13 has a top-level build-depends statement which isn't
allowed anymore: it should now be added to the library section, which
is what the error message tries to indicate.

Erik

On Thu, Jan 1, 2015 at 3:43 PM, Malcolm Wallace malcolm.wall...@me.com wrote:

 On 1 Jan 2015, at 13:58, George Colpitts wrote:

 Configuring cpphs-1.13...
 Building cpphs-1.13...
 Warning: cpphs.cabal: Unknown fields: build-depends (line 5)

 Could not find module ‘Prelude’
 It is a member of the hidden package ‘base-4.8.0.0’.
 Perhaps you need to add ‘base’ to the build-depends in your .cabal file.

 The two statements unknown field build-depends and add package to 
 build-depends seem rather contradictory.  How can this be fixed?

 Regards,
 Malcolm

 ___
 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: Hiding module *exports*

[Erik Hesselink]

On Mon, Oct 27, 2014 at 2:41 PM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
 There's a little bit of bikeshedding that needs to happen (e.g. is hiding 
 (Foo
 (..)) sufficient to hide the type Foo and not just its constructors), but 
 are
 people +1 on this? I've frequently wanted this behavior.

 I would be surprised if 'Foo(..)' would mean in this case something
 different, so yes, the type Foo should be hidden too.

One related question: how would you export only the type if you have

newtype Foo = Foo ...

which is a pretty common pattern? Since hiding (Foo(Foo)) would also
hide the type, I don't see many options, which is unfortunate.

In general, I'm +1 on the proposal.

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

Re: Hiding import behaviour

[Erik Hesselink]

On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević mblaze...@stilo.com wrote:
 On 14-10-19 08:10 AM, Erik Hesselink wrote:

 Adding an explicit
 import can suddenly cause type errors in completely unrelated places
 (when it hides an implicit import and the new function is type
 incorrect), or worse, can cause semantic change (when it hides an
 implicit import and the new function is type correct, but has
 different behavior). Remember that not all code is written by the same
 person, or in a short time frame, so not everybody might fully
 understand every module and every import of the code they're editing.

 Your example requires somebody actively editing the import list. A
 code change causes a compile error or worse? That is not all that
 surprising.

But right now, we have a useful property that adding imports and code
to a module does not break or change other code in that module. With
this extension, that changes. I find this kind of local reasoning very
useful, IMHO it's one of the most useful things about Haskell in
general.

 No, what I find much worse is a cabal update causing an error in a
 module that was correct before the update. Consider

 module Main where

 import Foo (foo)
 import Bar

 main = foo

 Now suppose Bar came from the package bar-1.0, and the new version
 bar-1.0.1 decides to export foo. With the current behaviour, this change
 would break my module. With Malcolm's proposal the old code would continue
 to work.

That's a very good point. Given that and the above, I don't understand
your conclusion:

 Anyway, count me as +1 on the proposal. It would improve the
 long-term stability of Haskell code.

How is adding more ways to break something improving the long-term stability?

Regards,

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

Re: Hiding import behaviour

[Erik Hesselink]

On Tue, Oct 21, 2014 at 4:55 PM, Mario Blažević mblaze...@stilo.com wrote:
 On 14-10-21 07:14 AM, Erik Hesselink wrote:

 On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević mblaze...@stilo.com
 wrote:
  No, what I find much worse is a cabal update causing an error in
 a
 module that was correct before the update. Consider

 module Main where

 import Foo (foo)
 import Bar

 main = foo


  Now suppose Bar came from the package bar-1.0, and the new
 version
 bar-1.0.1 decides to export foo. With the current behaviour, this change
 would break my module. With Malcolm's proposal the old code would
 continue
 to work.


 That's a very good point. Given that and the above, I don't understand
 your conclusion:

  Anyway, count me as +1 on the proposal. It would improve the
 long-term stability of Haskell code.


 How is adding more ways to break something improving the long-term
 stability?


 You seem determined to misunderstand every message in this thread.
 What I said was that the change from bar-1.0 to bar-1.0.1 breaks the example
 code *with the current behaviour*. The proposal removes this breakage.
 Anything that keeps the old code compiling and working with new libraries
 improves its long-term stability in my book.

 Note that the bar-1.0.1 upgrade wasn't even a major version change.
 This is correct according to the PVP:

You're right, I misread your message. I understand now, and you're
right that this is currently something that can break your package,
although it happens so rarely that people still depend on major
version ranges, even though they sometimes don't use explicit or
qualified imports.

Regards,

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

Re: Hiding import behaviour

[Erik Hesselink]

I feel that this extension, while looking tempting for writing code
from scratch, might hurt maintainability of code. Adding an explicit
import can suddenly cause type errors in completely unrelated places
(when it hides an implicit import and the new function is type
incorrect), or worse, can cause semantic change (when it hides an
implicit import and the new function is type correct, but has
different behavior). Remember that not all code is written by the same
person, or in a short time frame, so not everybody might fully
understand every module and every import of the code they're editing.

Erik

On Sun, Oct 19, 2014 at 1:32 AM, David Feuer david.fe...@gmail.com wrote:
 I'm generally in favor of the proposal, but I figured I should mention one
 situation when I personally might find this confusing. If the module import
 list is very long, and includes an unrestricted import of a well-known
 module, it might be easy to assume a certain well-known function comes from
 there, when in fact it comes from some other module on the other end of the
 import list.

 On Oct 18, 2014 6:39 PM, Joachim Breitner m...@joachim-breitner.de
 wrote:

 Hi,

 Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka:
  I guess my central point is I don't see how anyone can benefit from the
  current behaviour. For instance, a simple real world example:
 
  import Prelude
  import Data.Text.Lazy.IO (putStrLn)

 I find this quite convincing. If I bother to explicitly write out „take
 putStrLn from Data.Text.Lazy.IO“, why should the compiler assume that I
 might have meant some putStrLn from somewhere else.

 Of course, order should not matter (I don’t think anyone suggested it
 should, I think Austin simply mis-read that).

 Greetings,
 Joachim


 --
 Joachim “nomeata” Breitner
   m...@joachim-breitner.de • http://www.joachim-breitner.de/
   Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
   Debian Developer: nome...@debian.org


 ___
 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: converting type-level natural numbers to data-level

[Erik Hesselink]

I think most of the singletons stuff has been moved to the
'singletons' package [0].

Erik

[0] http://hackage.haskell.org/package/singletons

On Sat, Mar 15, 2014 at 6:26 PM, Henning Thielemann
lemm...@henning-thielemann.de wrote:
 Am 15.03.2014 18:13, schrieb adam vogt:


 http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/syntax-extns.html#explicit-namespaces
 is the trick


 Great, this works!

 Now I run into the next problem: How can I convert a type-level natural
 number into a data-level number? The Trac-Wiki mentions singletons:
   https://ghc.haskell.org/trac/ghc/wiki/TypeNats/Basics
 and the base package of GHC-7.6 exports the Sing class:
   http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC-TypeLits.html
 but it seems to have gone in GHC-7.8. :-(

 ___
 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: Problem with the object file name of the Main module.

[Erik Hesselink]

I'd like to repeat the suggestion to use cabal. It's very well suited
for simple programs. In addition, you get the ability to specify
dependencies, you can upload to hackage, etc.

Erik

On Mon, Jan 13, 2014 at 11:10 PM, Christian Brolin cbro...@gmail.com wrote:
 Thanks, but it is not a complicated build process. Just a few simple
 programs that share some modules. I like to keep it simple.


 On 2014-01-13 19:28, Carter Schonwald wrote:

 i warmly recommend you use cabal for any complicated build processes. if
 you're stuck, holler and we or haskell-cafe are happy to help


 On Mon, Jan 13, 2014 at 1:22 PM, Christian Brolin cbro...@gmail.com wrote:

 No. As a workaround I remove the Main.o file after the executable has been
 linked. It works, but it has its drawbacks.


 On 2014-01-12 17:23, Carter Schonwald wrote:

 Christian, have you tried using cabal? People write cabal files with
 multiple executables being generated all the time.

 On Sunday, January 12, 2014, Christian Brolin wrote:

 H.

 The documentation (version 7.6.3) section 7.7.2 Output files says that
 the source file name of the Main module does not have to be Main.hs making
 it possible to have several Main modules in separate source files in the
 same directory. While this is true and promising it is seems to be unusable
 since GHC always compiles the main source file into an object file called
 Main.o.

 ___
 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: Feature request: Vacuous/error constraint (related to 7.7 closed type families regression)

[Erik Hesselink]

You can of course produce an infinite set of vacuous constraints using
the Symbol type (or any two non-equal types). For example, here you
could use:

Restrict a (a ': as) = (Error ~ Oops! Tried to apply a restricted type!)

Erik

On Tue, Jan 14, 2014 at 2:56 PM, Merijn Verstraaten
mer...@inconsistent.nl wrote:
 I was trying to fix one of my closed type families examples for the new 
 syntax, and run into an unfortunate issue. Due to a kind error in my code one 
 of my constraints was being silently discarded (see ticket: 
 https://ghc.haskell.org/trac/ghc/ticket/8669)

 The main reason I resorted to this (in hindsight) ill-kinded hack is the lack 
 of a vacuous (i.e. never holding) constraint to produce type errors. I would 
 love to be able to explicitly force GHC into realising this constraint can 
 never hold, if I had the ability to pass along a String/Symbol to be 
 reported to the user, that would be even better.

 Cheers,
 Merijn

 ___
 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: Enabling TypeHoles by default

[Erik Hesselink]

I think that's a good idea. It was also suggested in a reddit thread
[0] a year ago, and it doesn't seem like that thread has any arguments
against it.

Erik

[0] 
http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdalike_holes/c6gvy0r

On Mon, Jan 13, 2014 at 8:03 PM, migmit mig...@gmail.com wrote:
 Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can
 break anything.

 Отправлено с iPad

 13 янв. 2014 г., в 22:54, Edward Kmett ekm...@gmail.com написал(а):

 I have to admit, I rather like this suggestion.

 -Edward


 On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski
 krz.gogolew...@gmail.com wrote:

 Hello,

 As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
 default. Rationale:

 (1) This way holes are far easier to use; just entering _ allows to
 check type of a subexpression, no need of adding -XTypeHoles.

 (2) This affects error messages only; i.e. the set of programs that
 compile stays the same - Haskell 2010. The only exception is that if you use
 -fdefer-type-errors, then a program with a hole compiles, but this seems
 fine with philosophy of -fdefer-type-errors.

 If so: would you like it to be in 7.8 or wait a cycle? My preference is
 7.8, two people (John and Richard) suggested 7.10.

 -KG

 ___
 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: love for hpc?

[Erik Hesselink]

I use HPC. It's really powerful in combination with tests, to see how
much of your code is covered. But I have also run into some of the
problems you mention, mostly to do with tix files.

Erik

On Thu, Nov 7, 2013 at 6:03 AM, Evan Laforge qdun...@gmail.com wrote:
 Is anyone out there using HPC?  It seems like it was gotten into a
 more or less working if not ideal state, and then abandoned.

 Things I've noticed lately:

 The GHC runtime just quits on the spot if there's already a tix file.
 This bit me when I was parallelizing tests.  It's also completely
 unsafe when run concurrently, mostly it just overwrites the file,
 sometimes it quits.  Sure to cause headaches for someone trying to
 parallelize tests.

 You can't change the name of the output tix file, so I worked around
 by hardlinking the binary to a bunch of new ones, and then doing 'hpc
 sum' on the results.

 The hpc command is super slow.  It might have to do with it doing its
 parsing with Prelude's 'read', and it certainly doesn't help the error
 msgs.

 And the whole thing is generally minimally documented.

 I can already predict the answer will be yes, HPC could use some
 love, roll up your sleeves and welcome!  It does look like it could
 be improved a lot with just a bit of effort, but that would be a yak
 too far for me, at the moment.  I'm presently just curious if anyone
 else out there is using it, and if they feel like it could do with a
 bit of polishing.
 ___
 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: Overloaded record fields

[Erik Hesselink]

It looks like this instance is partial. Note that the record field 'y'
is also a partial function in plain Haskell. I've always considered
this a misfeature, but perhaps fixing that is outside the scope of
this proposal.

Erik

On Mon, Jun 24, 2013 at 4:40 PM, Oliver Charles ol...@ocharles.org.uk wrote:
 On 06/24/2013 08:44 AM, Adam Gundry wrote:
 Hi everyone,

 I am implementing an overloaded record fields extension for GHC as a
 GSoC project. Thanks to all those who gave their feedback on the
 original proposal! I've started to document the plan on the GHC wiki:

 http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan

 If you have any comments on the proposed changes, or anything is unclear
 about the design, I'd like to hear from you.

 Thanks,

 Adam Gundry

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

 The base design has the following distinct components:

   * A library class

 class Has (r :: *) (f :: String) (t :: *) where
   get :: r - t

   * A record declaration generates an instance declaration for each
 field. For example

 data T a = T1 { x :: a, y :: Bool }
  | T2 { x :: a }

 would generate

 instance (t~a) = Has (T a) x t where
   get (T1 x _) = x
   get (T2 x)   = x
 instance (t~Bool) = Has (T a) y t where
   get (T1 _ y) = y

 Is this instance for y not partial? If it is, is that a problem?
 Perhaps I missed something that makes that instance total.

 - Ollie



 ___
 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: data kinds

[Erik Hesselink]

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


 What about just 'kind'? It's symmetric with 'type'.

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

Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program

[Erik Hesselink]

That's strange. Here, it only fails with both NoMonomorphismRestriction and
NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1.

Erik


On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info wrote:

 Apparently not — the code comilers with any of -XNoMonoLocalBinds and
 -XMonoLocalBinds, but not with -XNoMonomorphismRestriction.

 * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09
 14:07:59-0500]
  It's possible that the below blog post is related.
  ~d
 
  http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
 
  Quoting Roman Cheplyaka r...@ro-che.info:
 
  For this module
  
  module Test where
  
  import System.Random
  
  data RPS = Rock | Paper | Scissors deriving (Show, Enum)
  
  instance Random RPS where
random g =
  let (x, g') = randomR (0, 2) g
  in (toEnum x, g')
randomR = undefined
  
  ghc (7.4.1 and 7.6.1) reports an error:
  
  rand.hs:9:9:
  No instance for (Random t0) arising from the ambiguity check
 for g'
  The type variable `t0' is ambiguous
  Possible fix: add a type signature that fixes these type
 variable(s)
  Note: there are several potential instances:
instance Random RPS -- Defined at rand.hs:7:10
instance Random Bool -- Defined in `System.Random'
instance Random Foreign.C.Types.CChar -- Defined in
 `System.Random'
...plus 34 others
  When checking that g' has the inferred type `g'
  Probable cause: the inferred type is ambiguous
  In the expression: let (x, g') = randomR (0, 2) g in (toEnum x,
 g')
  In an equation for `random':
  random g = let (x, g') = randomR ... g in (toEnum x, g')
  Failed, modules loaded: none.
  
  There should be no ambiguity since 'toEnum' determines the type of x
  (Int), and that in turn fixes types of 0 and 2. Interestingly,
  annotating 0 or 2 with the type makes the problem go away.
  
  jhc 0.8.0 compiles this module fine.
  
  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

 ___
 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: Unexpected ambiguity in a seemingly valid Haskell 2010 program

[Erik Hesselink]

That makes sense: MonomorphismRestriction makes bindings without parameters
monomorphic, and MonoLocalBinds makes local bindings monomorphic. So either
one will make this binding monomorphic. Only when both are off does it
become polymorphic and does the error occur.

Erik


On Sun, Nov 11, 2012 at 5:37 PM, Roman Cheplyaka r...@ro-che.info wrote:

 Right. What I meant is that with -XMonomorphismRestriction, it compiles
 with with both -XMonoLocalBinds and -XNoMonoLocalBinds.

 That means that MonoLocalBinds can not be solely responsible for this
 behaviour.

 Anyway, I just noticed that a very similar example (using Read) is
 described in the Haskell report's section on the monomorphism
 restriction.

 Roman

 * Erik Hesselink hessel...@gmail.com [2012-11-11 16:43:20+0100]
  That's strange. Here, it only fails with both NoMonomorphismRestriction
 and
  NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1.
 
  Erik
 
 
  On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info
 wrote:
 
   Apparently not — the code comilers with any of -XNoMonoLocalBinds and
   -XMonoLocalBinds, but not with -XNoMonomorphismRestriction.
  
   * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09
   14:07:59-0500]
It's possible that the below blog post is related.
~d
   
http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
   
Quoting Roman Cheplyaka r...@ro-che.info:
   
For this module

module Test where

import System.Random

data RPS = Rock | Paper | Scissors deriving (Show, Enum)

instance Random RPS where
  random g =
let (x, g') = randomR (0, 2) g
in (toEnum x, g')
  randomR = undefined

ghc (7.4.1 and 7.6.1) reports an error:

rand.hs:9:9:
No instance for (Random t0) arising from the ambiguity check
   for g'
The type variable `t0' is ambiguous
Possible fix: add a type signature that fixes these type
   variable(s)
Note: there are several potential instances:
  instance Random RPS -- Defined at rand.hs:7:10
  instance Random Bool -- Defined in `System.Random'
  instance Random Foreign.C.Types.CChar -- Defined in
   `System.Random'
  ...plus 34 others
When checking that g' has the inferred type `g'
Probable cause: the inferred type is ambiguous
In the expression: let (x, g') = randomR (0, 2) g in
 (toEnum x,
   g')
In an equation for `random':
random g = let (x, g') = randomR ... g in (toEnum x, g')
Failed, modules loaded: none.

There should be no ambiguity since 'toEnum' determines the type of x
(Int), and that in turn fixes types of 0 and 2. Interestingly,
annotating 0 or 2 with the type makes the problem go away.

jhc 0.8.0 compiles this module fine.

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
  
   ___
   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: default instance for IsString

[Erik Hesselink]

On Wed, Apr 25, 2012 at 10:15, Yitzchak Gale g...@sefer.org wrote:
 The only reason I don't like using OverloadedStrings
 for typing string literals as Text and ByteString
 is that when you turn on OverloadedStrings, you turn
 it on for all types, not just Text and ByteString.
 I don't want to be forced to do that. Because
 all other uses of OverloadedStrings that I have
 seen, and there are many, are ill-advised in my
 opinion. They all should have been quasiquoters.

I don't think IsString should be dismissed so easily. I agree that
instances should be total functions (and I don't like the
ByteString.Char8 instance for that reason) but there are many more
good use cases than Text and (UTF8) ByteStrings. For example, we have
a couple of newtypes over Text that do different kinds of
normalization. An IsString instance for these is useful and total.

Erik

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

Re: default instance for IsString

[Erik Hesselink]

On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com wrote:
 Here's a theoretically simple solution to the problem. How about
 adding a new method to the IsString typeclass:

    isValidString :: String - Bool

If you're going with this approach, why not evaluate the conversion
from String immediately? For either case you have to know the
monomorphic type, and converting at compile time is more efficient as
well. But we're getting pretty close to Template Haskell here.

Erik

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

Re: default instance for IsString

[Erik Hesselink]

On Tue, Apr 24, 2012 at 10:55, Michael Snoyman mich...@snoyman.com wrote:
 On Tue, Apr 24, 2012 at 11:36 AM, Erik Hesselink hessel...@gmail.com wrote:
 On Tue, Apr 24, 2012 at 08:32, Michael Snoyman mich...@snoyman.com wrote:
 Here's a theoretically simple solution to the problem. How about
 adding a new method to the IsString typeclass:

    isValidString :: String - Bool

 If you're going with this approach, why not evaluate the conversion
 from String immediately? For either case you have to know the
 monomorphic type, and converting at compile time is more efficient as
 well. But we're getting pretty close to Template Haskell here.

 I could be mistaken, but I think that would be much harder to
 implement at the GHC level. GHC would then be responsible for taking a
 compile-time value and having it available at runtime (i.e., lifting
 in TH parlance). Of course, I'm no expert on GHC at all, so if someone
 who actually knows what they're talking about says that this concern
 is baseless, I agree that your approach is better.

But GHC already has all the infrastructure for this, right? You can do
exactly this with TH.

Erik

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