Re: PSA: `cabal update` command needs manual unsticking

2018-01-02 Thread Michael Snoyman 
On Tue, Jan 2, 2018 at 11:47 AM, Sven Panne  wrote:

> 2018-01-02 2:24 GMT+01:00 Gershom B :
>
>> A recent update to hackage, which fixed up the 01-index.tar.gz file,
>> revealed a bug in existing versions of cabal-install, when index files
>> are cleaned up. This bug means that the `cabal update` command, which
>> updates the hackage index file, will fail silently and leave the old
>> file in place. It is easy to get things working again, but it requires
>> manual intervention. [...]
>
>
> Quick question: Are stack users affected, too, or only cabal users? I'm
> just asking because as a stack user you have 
> ~/.stack/indices/Hackage/01-index.*
> files lying around, too...
>
>
Hey Sven,

Gershom sent me an email about this earlier, and I looked into it. As far
as I can tell, Stack is _not_ affected by this, since—although it uses the
same hackage-security library as cabal-install—it follows a different
codepath outside of hackage-security for downloading tarballs. I'm not 100%
certain Stack is immune, however, so if someone notices a problem, please
report it.

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

Re: How to uninstall all cabal packages?

2017-12-03 Thread Michael Snoyman 
You'll need to delete your ~/.ghc directory as well.

On Sun, Dec 3, 2017 at 8:24 PM, Volker Wysk  wrote:

> Hi!
>
> I want to remove eveything which cabal has installed, and begin again with
> a clean installation. How is this accomplished? I've deleted ~/.cabal, but
> it still says that hsshellscript is already installed:
>
> desktop ~ $ cabal install hsshellscript
> Resolving dependencies...
> All the requested packages are already installed:
> hsshellscript-3.4.3
> Use --reinstall if you want to reinstall anyway.
>
> Bye
> V.W.
>
> ___
> 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: Rewrite rules

2017-01-12 Thread Michael Snoyman 
Could be I'm misunderstanding, but are you looking for -ddump-rule-firings?

On Thu, Jan 12, 2017 at 10:46 AM, Erik de Castro Lopo 
wrote:

> HI all,
>
> I'm having an look at rewrite rules, but something bugs me a little.
> How do I tell if my rewrite rules are firing or not? Even If I
> introduce deliberate errors in the function name that is being
> re-written I still don't get so much as a warning.
>
> Clues?
>
> 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: Optimization of IORefs and STRefs - comparison to g++

2015-12-11 Thread Michael Snoyman 
My mutable-containers package has unboxed and storable references actually.

On Fri, Dec 11, 2015, 12:26 PM Akio Takano  wrote:

> Hi Mateusz,
>
> IORef and STRef are boxed references. That is, they are a mutable cell
> that contains a pointer to some immutable Haskell value. When you
> increment a (STRef Int), you first dereference the pointer, allocate a
> new immutable heap object to represent the new integer value, then
> mutate the reference to point to the new object. This costs much more
> than updating a plain mutable integer.
>
> As far as I know there is no particularly popular library that
> provides mutable references like this. As a workaround, you can create
> a 1-sized unboxed mutable vector using the vector package, and use it
> like a reference.
>
> On 3 December 2015 at 01:10, Mateusz Kłoczko
>  wrote:
> > Hello!
> >
> > I've performed a few simple tests using Haskell and C++ on primitives.
> > I've compilled all Haskell programs with -O2 optimizations, and C++ ones
> > with -O3
> > ghc version - 7.10.2, gcc version : 5.1.1
> >
> > I'm sending the codes in the zip file.
> >
> > Problem1 -  100 000 000  iterations.
> >
> > Time of execution (in seconds):
> > Int  pure tail recursion: 6.911011299962411e-2
> > Int# pure tail recursion : 4.587398100011342e-2
> > IORef for loop 1.153397082832
> > IORef 'tail' recursion 1.0696569040001123
> > STRef for loop 1.1545546840006864
> > STRef tail recursion 1.1110019479992843
> > C++ : 2.7e-07
>
> On this one, g++ manages to eliminate the loop entirely, but GHC doesn't.
>
> >
> > The llvm version could be as fast as C++ one in this problem.
> >
> > Buuut... then there's problem 2 (using if or case) - 100 000 000
> iterations:
> > Int# tail recursion 1.315346227000191
> > IORef for loop: 2.6442542390004746
> > STRef for loop: 2.669217500999366
> > C++: 0.158056
> >
> >
> > Here haskell is about 9 times slower than C++.
>
> The main difference on this comes from the fact that GHC does not
> optimize (n `remInt#` 2#) into (n `andI#` 1#). There is a ticket [0]
> that contains some discussion of this issue.
>
> [0]: https://ghc.haskell.org/trac/ghc/ticket/5615
>
> Hope this helps,
> Takano Akio
> ___
> 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: ANNOUNCE: GHC 7.8.4 Release Candidate 1

2014-11-26 Thread Michael Snoyman 
On Tue Nov 25 2014 at 9:46:46 PM Austin Seipp aus...@well-typed.com wrote:

 We are pleased to announce the first release candidate for GHC 7.8.4:

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

 This includes the source tarball and bindists for 64bit Linux. Binary
 builds for other platforms will be available shortly. These binaries
 and tarballs have an accompanying SHA256SUMS file signed by my GPG key
 id (0x3B58D86F).

 We plan to make the 7.8.4 release sometime in the next few weeks.

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



Just wanted to report: I ran a full Stackage build + test suite using the
release candidate, and everything passed. This build consisted of ~750
packages. You can find the list of packages at:

http://lpaste.net/115090

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

Re: Document for review: evaluation order and state tokens

2014-08-26 Thread Michael Snoyman 
On Mon, Aug 25, 2014 at 9:37 PM, Bertram Felgenhauer 
bertram.felgenha...@googlemail.com wrote:

 Dear Michael,

 Michael Snoyman wrote:
  As part of trac ticket 9390[1], Simon PJ recommended that we try to get a
  document written that clarifies some of the issues regarding evaluation
  order, and get it included in the GHC wiki. After a few iterations with
  review from Simon, I've got a first publicly consumable version
 available
  at:
 
 
 https://www.fpcomplete.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens

 Thanks for writing this, it looks very useful.

  I'd appreciate any feedback on this document before I add it to the wiki.

 [on unsafeDupablePerformIO]
 | And when the first thread completes the action, it may terminate the
 | execution of the other thread.

 I think it's worthwhile to stress that bracket does not help, because
 evaluation of the thunk in the other thread simply stops, without
 throwing an exception.


 Could you add something about unsafePerformIO inside STM? The upshot is
 that you get the behaviour of unsafeDupablePerformIO, except for the
 parallelism: When an STM transaction is interrupted to be retried, its
 evaluation simply stops. This is a known bug which causes real problems
 with FFI bindings, see

   https://ghc.haskell.org/trac/ghc/ticket/2401
   http://www.haskell.org/pipermail/haskell-cafe/2014-February/112555.html

 but it has been around for a long time.

 Cheers,

 Bertram


Thanks for the feedback, I've added information on both of these points to
the document (STM in its own section at the bottom, as I couldn't find a
good place where it fit with the existing flow).

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

Document for review: evaluation order and state tokens

2014-08-25 Thread Michael Snoyman 
As part of trac ticket 9390[1], Simon PJ recommended that we try to get a
document written that clarifies some of the issues regarding evaluation
order, and get it included in the GHC wiki. After a few iterations with
review from Simon, I've got a first publicly consumable version available
at:

https://www.fpcomplete.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens

I'd appreciate any feedback on this document before I add it to the wiki.

Michael

[1] https://ghc.haskell.org/trac/ghc/ticket/9390
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: hmatrix-0.16.0.4 installation problem

2014-08-21 Thread Michael Snoyman 
On Thu, Aug 21, 2014 at 3:26 PM, Adrian Victor Crisciu acris...@gmail.com
wrote:

 Hi,

 I tried to upgrade from hmatrix 0.15.2.1 to hmatrix-0.16.0.4 and both
 cabal install and cabal configure complained about missing blas and lapack
 libraries. However, I do have those libraries installed, and I passed their
 locations through --extra-include-dirs and --extra-lib-dirs with no results.

 I use cabal 1.20.0.3, ghc 7.8.2 and gcc 4.4.4 on a Slackware-13.1 64-bit
 linux box.

 Any idea of what is going wrong (and how to correct it?)

 Thanks,
 Adrian-Victor.



A report like this is much easier to answer if it includes the actual
command you ran and its output.

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

Re: GHC 7.8.3 release

2014-05-27 Thread Michael Snoyman 
I'm building the GHC-7.8 branch now, and will then kick off a Stackage
build. That should give a good indication if there are regressions.


On Tue, May 27, 2014 at 11:06 AM, Austin Seipp aus...@well-typed.comwrote:

 Hello all,

 After a long week, I've finally gotten a little time to reply to
 emails, and I mainly have one question I'd like to ask.

 First, please direct your attention to this:


 https://ghc.haskell.org/trac/ghc/query?status=closedstatus=mergestatus=patchmilestone=7.8.3group=resolutioncol=idcol=summarycol=ownercol=typecol=prioritycol=componentcol=versionorder=priority

 This is the 7.8.3 milestone, but it only considers things that are:

  - 1) Fixed
  - 2) Going to be merged
  - 3) Are a patch to be still merged.

 That is, it is a solid representation of the difference between 7.8.2
 and the 7.8 branch tip.

 The question is: when should we do the release? There are several bugs
 there that seem quite problematic for users - #9045, #7097, #9001,
 #8768 and #9078 in particular.

 If these bugs are really problematic (and I sort of feel they are)
 then the release can happen soon. I can do it within a week from now,
 and we could punt more to a 7.8.4 release.

 I ask this because my time to dedicate to GHC is a bit thin right now,
 so you must help me decide what's important! So please let me know -
 just a general vote in favor of doing it within some X timeframe (even
 'real soon' or 'a week would be great') would be nice.

 PS: I apologize for the lack of status updates and brief email - my
 time for GHC has been in very short order the past two weeks in
 particular, and I've finally just returned to a computer (not mine)
 for right now to ask this.

 PPS: This might also impact the 7.10 schedule, but last Simon and I
 talked, we thought perhaps shooting for ICFP this time (and actually
 hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
 happen a few months from now, after summer.

 --
 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: 7.8.1 cabal install of vector package (dependent on primitive package) fails

2014-04-10 Thread Michael Snoyman 
On Thu, Apr 10, 2014 at 6:42 AM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 i bet you have cabal --version reply with  1.16 :)

 1) cabal update
 2) cabal install cabal-install
 3) rm ~/.cabal/config # old pre 1.18 config should go!


This was news to me. Is there a list of the important changes?


 4) cabal update # also probably add ~/.cabal/bin to path
 5)  cabal install vector



 On Wed, Apr 9, 2014 at 11:24 PM, Vivian McPhail 
 haskell.vivian.mcph...@gmail.com wrote:

 Hi,

 Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following:

 # cabal install --global vector
 ...
 [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
 Data/Vector/Fusion/Stream/Monadic.hs,
 dist/build/Data/Vector/Fusion/Stream/Monadic.o )
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 Loading package primitive-0.5.2.1 ... command line: can't load .so/.DLL
 for: libHSprimitive-0.5.2.1.so (libHSprimitive-0.5.2.1.so: cannot open
 shared object file: No such file or directory)
 cabal: Error: some packages failed to install:
 vector-0.10.9.1 failed during the building phase. The exception was:
 ExitFailure 1

 Cheers,

 Vivian


 ___
 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] New GHC Features for 7.10.1 and Beyond

2014-03-31 Thread Michael Snoyman 
On Tue, Apr 1, 2014 at 8:07 AM, Kazu Yamamoto k...@iij.ad.jp wrote:

 Hi Gershom,

  We've also seen a lot of interest in distribution and cloud computing.
  From the articles I've read, efficient concurrent programming involves
  using node.js, so I think we should put some work into writing a
  new-new-new-IO Manager built on top of this technology.

 As a member of Mio developers, I don't understand this sentence. Would
 you concretely explain what kind of node.js technologies should be
 taken into new-new-new-IO Manager?


It's really simple: node.js is webscale, Mio is not. I'm sorry, but you
simply didn't do a good enough job making sure that random packets were
lost when sending network traffic, or that writing data to disk may
sporadically fail. Better luck next time.

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

Re: 7.8.1, template haskell, and dynamic libraries

2014-02-09 Thread Michael Snoyman 
On Sun, Feb 9, 2014 at 10:30 AM, harry volderm...@hotmail.com wrote:

 Carter Schonwald wrote
  Yes.  (And thence ghc itself is then invoked with dynamic or dynamic-too)
 
  The docs for 7.8.1 say Template Haskell must now load dynamic object
  files,
  not static ones. Does this mean that, if I'm using Template Haskell,
  every
  package which the templates depend on have to be built with
  --enable-shared?

 Perhaps there should be a clear warning about this? If I've understood
 correctly, anything using Template Haskell will break when upgrading to
 7.8,
 until all the dependencies are reinstalled with  --enable-shared.



When upgrading to a new version of GHC, you'll have to reinstall all of the
packages anyway. You can't simply use GHC 7.6 compiled packages with your
new GHC 7.8.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

2013-02-08 Thread Michael Snoyman 
On Fri, Feb 8, 2013 at 3:55 PM, Ian Lynagh i...@well-typed.com wrote:

 On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote:
 
  I wish GHC would radically change it's release process. Things like 7.8
  shouldn't be release as 7.8. That sounds major and stable. The web site
  will have 7.8 at the top. The warning to use the platform will fall flat
  because it makes the platform look out of date. Really, 7.8 should be
 in
  a different release channel, not on the front page. It should bake in
 that
  channel for six months - where only the third group of people will use
 it,
  until it is getting close to merge into main, at which point the fourth
  group will start to use it, so that the day it hits main, all the
 libraries
  just work. Ideally, the first two groups of people will not pay the
  slightest attention to it until it is further baked.

 It's a catch-22: We don't want people to use a new release until all the
 bugs have been found and fixed, and all the libraries have been updated.
 But if people don't use it, then the bugs won't be found and the
 libraries won't be updated.

 I think you're saying that you'd like the uptake of new GHC versions to
 be slower, which would mean fewer people would be using 7.6 now, but in
 the last few days I've seen the Debian guys have had to send mails to
 maintainers telling them that their packages don't work with 7.6:
 http://lists.debian.org/debian-haskell/2013/02/threads.html
 despite 7.6 having been out for 5 months and about to enter the HP.

 Perhaps more automatic Hackage building, with a group of people looking
 at the logs of failing packages and acting appropriately, is the way
 forward. Some cases (such as installation failed due to dependencies
 not being installable) you'd want to be handled automatically.


 Thanks
 Ian


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


This is an issue I'm hoping Stackage will be able to help address.
Currently, we're running daily builds of the Stackage package set
(currently at about 330 packages) using the most recent Haskell Platform.
However, I'm hoping to augment this with GHC 7.6.2 as well (obviously
dropping the Haskell Platform version constraints at that point, as they
would not be compatible). We could also theoretically include release
candidates in this process, which I think would help flesh out bugs and
drive support for newer GHCs more quickly.

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

Re: GADTs in the wild

2012-08-14 Thread Michael Snoyman 
On Tue, Aug 14, 2012 at 2:32 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:

  Friends


 I’m giving a series of five lectures at the Laser Summer 
 Schoolhttp://laser.inf.ethz.ch/2012/(2-8 Sept), on “Adventures with types 
 in Haskell”.  My plan is:
 

 **1.   **Type classes

 **2.   **Type families [examples including Repa type tags]

 **3.   **GADTs

 **4.   **Kind polymorphism

 **5.   **System FC and deferred type errors

 ** **

 This message is to invite you to send me your favourite example of using a
 GADT to get the job done.  Ideally I’d like to use examples that are (a)
 realistic, drawn from practice (b) compelling and (c) easy to present
 without a lot of background.  Most academic papers only have rather limited
 examples, usually eval :: Term t - t, but I know that GADTs are widely
 used in practice.

 ** **

 Any ideas from your experience, satisfying (a-c)?  If so, and you can
 spare the time, do send me a short write-up. Copy the list, so that we can
 all benefit.

 ** **

 Many thanks


 Simon

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


Hi Simon,

In the webcast I gave last week, I used a dumbed-down version of how we do
safe queries in Persistent. The example is on slides 20-22 of [1].
Persistent works mostly the same way (and was inspired in this usage by
groundhog[2]). If you want a more thorough explanation of how Persistent
uses GADTs, let me know.

An example that came up at work (with Yitzchak Gale, he probably has more
details) was essentially two different types of documents that shared a lot
of the same kinds of elements (tables, lists, paragraphs, etc) but some
elements only appeared in one of the document types. We needed to render to
(for sake of argument) two different XML formats, and wanted to be certain
we didn't put in elements from type 1 in type 2. The solution looked
something like this (using data kinds and GADTs):

data DocType = Doc1 | Doc2

data Element (doctype :: DocType) where
Paragraph :: Text - Element doctype
Table :: [Element doctype] - Element doctype
...
BulletList :: [[Element doctype]] - Element Doc1

renderDoc1 :: Element Doc1 - XML
renderDoc2 :: Element Doc2 - XML

Michael

[1]
https://docs.google.com/presentation/d/1c6pkskue6WbTlONFTpFhYqzSlQe_sxO7LfP5SW7InVE/edit
[2] http://hackage.haskell.org/package/groundhog
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: default instance for IsString

2012-04-24 Thread Michael Snoyman 
On Tue, Apr 24, 2012 at 9:26 AM, Yitzchak Gale g...@sefer.org wrote:
 Greg Weber wrote:
 I very much agree with you. However, when we complain about something
 essentially we are asking others to prioritize it ahead of other
 things. I don't think any more visibility of this issue is going to
 improve its prioritization. I suspect your only way forward right now
 is to start implementing something yourself.

 You're right. But as a professional Haskell developer, I am
 under the same kinds of deadline pressures as any other
 professional. So I'm afraid it's not going to be me, at least
 not in the near future.

 However, what I can do is raise the red flag. Some people
 are pushing things in directions which would cause
 OverloadStrings to become more and more ubiquitous,
 perhaps even the default. I want to make sure that the
 people who are doing that are aware of the deep problems
 with that approach.

 Sure, as much as anyone else, I want string literals
 that can be typed as Text. But not at the cost of
 delaying syntax checking to run time.

  And, as Bas points out, that there are many different
 compile time mechanisms that could be used for this.

 Thanks,
 Yitz

Here's a theoretically simple solution to the problem. How about
adding a new method to the IsString typeclass:

isValidString :: String - Bool

We can give it a default implementation of `const True` for backwards
compatibility. Then, whenever GHC applies OverloadedStrings in a case
where the type is fully known at compile time (likely the most common
case), it can run the check and- if it returns False- stop the
compile. This has the benefits of letting existing code continue to
work unchanged, and not requiring any Template Haskell to be involved.

A downside is that it will still let invalid code through sometimes.
Perhaps a solution is to modified the OverloadedStrings extension that
requires that the type be fully known. If someone *really* wants
polymorphic strings, they can explicitly add `fromString`. I actually
think I'd prefer this version.

Michael

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

Re: default instance for IsString

2012-04-24 Thread Michael Snoyman 
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.

 Erik

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.

Michael

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

Re: default instance for IsString

2012-04-24 Thread Michael Snoyman 
On Tue, Apr 24, 2012 at 12:35 PM, Yitzchak Gale g...@sefer.org wrote:
 Markus Läll wrote:
 You do know, that you already *can* have safe Text and ByteString from
 an overloaded string literal.

 Yes, the IsString instances for Text and ByteString are safe
 (I hope).

 But in order to use them, I have to turn on OverloadedStrings.
 That could cause other string literals in the same module
 to throw exceptions at run time.

 -Yitz

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

Actually, the ByteString instance is arguably unsafe as well:

{-# LANGUAGE OverloadedStrings #-}
import qualified Data.ByteString.Char8 as S8

main = S8.putStrLn שלום

It would be nice if usage of characters outside of the 0-255 range
could be caught at compile time.

Michael

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

Re: default instance for IsString

2012-04-24 Thread Michael Snoyman 
On Tue, Apr 24, 2012 at 1:08 PM, Erik Hesselink hessel...@gmail.com wrote:
 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

Yes, absolutely. The issue is that TH can be too heavy for both the
library author and user:

* For the author, you now have to deal with generating some `Q Exp`
instead of just producing your data with normal Haskell code.
* For the user, you need to replace foo with [qqname|foo|].

There's also quite a bit of TH hatred out there, but I'm definitely
not in that camp. Nonetheless, I *do* think it would be nice to avoid
TH in this case if possible.

Michael

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