Is the 7.10.2 hvr ppa using this RC?
We just reported a 7.10 regression that I am hoping will be fixed before
the release that I was trying to verify
https://ghc.haskell.org/trac/ghc/ticket/10599
On Sun, Jun 14, 2015 at 5:16 PM, Austin Seipp wrote:
> We are pleased to announce the first release
We have observed issues with compile-time inlining taking much longer in
newer versions of GHC in some cases
https://github.com/larskuhtz/toCaseFoldBuildTimes
This particular issue was reported to the text repo:
https://github.com/bos/text/issues/116
On Fri, May 1, 2015 at 7:49 AM, Simon Peyton Jo
skell.html
[2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
On Mon, Feb 2, 2015 at 11:31 AM, Greg Weber wrote:
> Hi Simon,
>
> I am just starting the proposal: gathering interested parties and pointers
> to related information.
> Thanks for the pointer to
the wild or been able to use it
myself unfortunately due to backwards compatibility needs (once the next
GHC release is out libraries will start to consider dropping 7.6 support
and we will see more usage, although Ubuntu still ships 7.6 by default).
I will study Typed Template Haskell.
Greg Weber
On Fri, Jan 30, 2015 at 7:05 PM, adam vogt wrote:
> Hi Greg,
>
> Perhaps a less-invasive way to implement the -XSafe part of your
> proposal would be to provide a module like:
>
> module Language.Haskell.TH.Safe (
> module Language.Haskell.TH,
> reifyWithoutNameG,
> ) where
> import Languag
/TemplateHaskell/Restricted
Right now the proposal does not have any details and the goal is to write
out a clear specification.
If this sounds interesting to you, let me know or leave some feedback on
the wiki.
Thanks,
Greg Weber
___
Glasgow-haskell-users
No, it is a big change and the merge window is closed now. This question
was just asked on reddit:
http://www.reddit.com/r/haskell/comments/2pnjdk/is_overloadedrecordfields_getting_it_into_7101/
On Tue, Dec 23, 2014 at 6:12 PM, Kazu Yamamoto wrote:
> Hi,
>
> If I understand correctly, Overloaded
I was able to get in touch with the author and I am discussing my use case
with him. Thanks!
On Thu, Nov 6, 2014 at 10:23 AM, Greg Weber wrote:
> Should I be asking this question on a different mailing list such as
> ghc-devs?
>
> On Wed, Nov 5, 2014 at 12:21 PM, Greg Weber wrote:
Should I be asking this question on a different mailing list such as
ghc-devs?
On Wed, Nov 5, 2014 at 12:21 PM, Greg Weber wrote:
> I would like to be able to retrieve user-supplied annotations in Template
> Haskell. The 7.8 user manual doesn't mention this ability. However, I see
/8460
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I created a GHC patch that spits out the generated Template Haskell code to
a file with -dump-to-file -ddump-splices
https://ghc.haskell.org/trac/ghc/ticket/9126
On Sat, Jul 5, 2014 at 8:18 PM, adam vogt wrote:
> Zeroth takes the first approach. It only supports a subset of TH
> (DecsQ splices)
For me upgrading to 7.8 was very easy. The release slippage actually helped
out with that. 7.8 had already been specified well enough and already had
some active users for a long time. This made for a long window for package
maintainers to update their packages to have 7.8 compatibility. Perhaps
Oc
Can we get a little more information on what pandoc is doing? Is there a
documentation link?
In part am wondering if it is possible to have a Foo.hs.md file that pandoc
compiles down to Foo.hs with or without help from GHC.
On Sun, Mar 16, 2014 at 5:56 AM, Merijn Verstraaten
wrote:
> Ola!
>
> I
I think there are 2 use cases:
* explicit ado is best, it communicates the intent of the writer and can
give better error messages
* we want users to write code in a do style and the implementer to make it
applicative if possible
So we probably need to accommodate 2 use cases with 2 extensions, on
Yes, this is only an issue on Windows.
On Fri, Oct 4, 2013 at 11:19 PM, Christopher Done wrote:
> They're on Windows?
>
> On 5 October 2013 01:36, Greg Weber wrote:
> > A Windows user rerported using Data.Text.IO.writeFile to write out
> > quasi-quoted text.
>
A Windows user rerported using Data.Text.IO.writeFile to write out
quasi-quoted text.
writeFile automatically translates '\r' to "\r\n", so the user ended up
writing out "\r\r\n" to a file.
Haskell seems to be adopting the policy or removing '\r' from Haskell land.
Is there any reason why quasi-q
The 2 approaches are not mutually exclusive.
ticket#_description.hs
tc12345_GADT.hs
On Tue, Dec 18, 2012 at 6:22 AM, Simon Marlow wrote:
> On 18/12/12 12:33, Roman Cheplyaka wrote:
>
>> * Simon Peyton-Jones [2012-12-18 10:32:39+]
>>
>>> (This belongs on cvs-ghc, or the upcoming ghc-devs
a lot of packages are doing this already, would be nice to formalize it
On Tue, Sep 4, 2012 at 3:56 AM, Herbert Valerio Riedel wrote:
> Hello Haskellers,
>
> I've been wondering whether it might be useful to add a feature to
> Haddock similar to what can be found in other API documentation system
mport Data.Text as T
default (T.Text)
classNoDefault awhere noDefault :: a -> [Text]
instance NoDefault [T.Text] where noDefault = id
main = print (noDefault ["Hello!"])
On Sun, Apr 22, 2012 at 8:31 PM, Greg Weber wrote:
> Sorry, someone responded on haskell-cafe a
plementations of IsString that cause
> syntax errors to be caught only at run time instead of at
> compile time. That is the opposite of one of the most
> important things we are trying to accomplish by using
> Haskell instead of, say, some dynamically typed language.
>
> Greg Web
file. Things tend to be all String, all Text, etc.
> So, if I could just pick a concrete type for all the string literals
> in my file, I would be happy.
>
> - jeremy
>
>
>
> On Sat, Apr 21, 2012 at 7:20 PM, Greg Weber wrote:
>> I would like to default IsString to use the
/docs/latest/html/users_guide/type-class-extensions.html#overloaded-strings
>
> On Sun, Apr 22, 2012 at 4:54 PM, Greg Weber wrote:
>> Thanks Markus, I think you have saved the day!
>> Even after googling for this extension and searching in the manual I
>> am still coming up pr
n for `main': main = print (noDefault "Hello!")
On Sat, Apr 21, 2012 at 7:51 PM, Greg Weber wrote:
> my actual use case looks more like this:
>
> {-# LANGUAGE OverloadedStrings #-}
> {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
>
> import Data.T
instance for a typeclass I
define that uses isString instances.
On Sat, Apr 21, 2012 at 6:24 PM, Daniel Peebles wrote:
> I think it'll be hard to do that without putting Text in base, which I'm not
> sure anyone wants to do.
>
> Dan
>
> On Sat, Apr 21, 2012 at 8:20 PM, Gr
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting capability is available for Num. Is there any way to
do this for IsString?
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow
7:40 AM, Gregory Collins wrote:
> Whoosh? :-)
>
> On Sun, Apr 1, 2012 at 3:54 PM, Greg Weber wrote:
>>
>> Hi Gershom,
>>
>> This sounds very interesting even if I have no idea what you are
>> talking about :)
>> Please create a proposal linked from this
e are all going through the
requirements phase correctly.
I can assure you that haskell prime would not accept a records change
until it is first implemented in GHC or another Haskell compiler.
Thanks,
Greg Weber
On Sat, Mar 31, 2012 at 11:14 PM, Gershom B wrote:
> The records discussion
, Mar 8, 2012 at 1:14 PM, Chris Smith wrote:
> On Thu, Mar 8, 2012 at 2:09 PM, Greg Weber wrote:
>> The semantics that will be exposed to users have already been largely
>> decide upon.
>
> Admittedly I haven't had time to carefully read some parts of this
> thread, and i
On Thu, Mar 8, 2012 at 12:37 PM, Chris Smith wrote:
> On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber wrote:
>> This discussion has largely centered around trying to come up with a
>> hack that desugars to Haskell's existing language constructs.
>
>> There is an alternat
>> I think it is time to close down the records discussion on the mail
>> list and ask for an implementation
>> The implementer should use any means at their disposal, probably by
>> adding a new construct to the language. However, for now any new
>> constructs or other implementation details shoul
5, 2012 at 10:59 AM, Greg Weber wrote:
> Thanks so much for stepping up and attempting a solution at our big
> problem, Barney!
>
> I would ask everyone restrict their comments on this for now solely as
> to figuring out whether it makes updates work. There has been a lively
>
Thanks so much for stepping up and attempting a solution at our big
problem, Barney!
I would ask everyone restrict their comments on this for now solely as
to figuring out whether it makes updates work. There has been a lively
debate about ideal details on a record implementation, but until
update
kable
implementation and just avoid exposing the implementation details for
now. If anyone can lend a hand at figuring out SORF updates or
determining if type inference of records in the Ur paper can be made
to work in Haskell, that would be very helpful!
Greg Weber
On Sun, Feb 26, 2012 at 7:01 AM
Sorry for getting offended!
I agree with your sentiment, which is why I thought having to write an
extra word in a Record declaration to get automatic abstraction over
fields was a good solution to the problem.
But now I am in the position of being the lone dissenter on automatic
abstraction over
>
> No, I don't think anybody has a satisfactory approach to
> updating polymorphic/higher-ranked fields. (DORF mentions
> one, but it's a ghastly hack.
So are the proposals dead until this is tackled, or should SORF/DORF
propose not to allow that?
>
> What on earth do you mean by "not automatica
been willing to do for years to push Haskell's records
forward. I would appreciate respectful disagreement - I think I have
earned that much. Please just stick to logical arguments.
Greg Weber
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
b 24, 2012 at 9:27 AM, Greg Weber wrote:
> I looked at the DORF implementers view
> http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/ImplementorsView
>
> It appears that we still have no solution for record updates that
> change the type of a polymorp
this update issue
other than just de-sugaring to typeclasses.
On Thu, Feb 23, 2012 at 5:01 PM, Greg Weber wrote:
> On Thu, Feb 23, 2012 at 4:25 PM, AntC wrote:
>> Greg Weber gregweber.info> writes:
>>
>>>
>>> Thanks to Anthony for his DORF proposal, and spendi
On Thu, Feb 23, 2012 at 4:25 PM, AntC wrote:
> Greg Weber gregweber.info> writes:
>
>>
>> Thanks to Anthony for his DORF proposal, and spending time to clearly
>> explain it on the wiki.
>>
>> I have a big issue with the approach as presented - it assumes t
the best default behavior.
And the section "Modules and qualified names for records" shows that
the proposal doesn't fully solve the name-spacing issue.
On Sat, Feb 11, 2012 at 9:43 PM, wren ng thornton wrote:
> On 2/11/12 9:47 AM, Greg Weber wrote:
>>
>> What is the use
just remove this capability or have an explicit
syntax for changing the type to make it easier for both implementer
(to distinguish) and user (to declare intent). I am not sure what the
syntax would be, or if it should be a separate action or mixed in with
a normal reco
being more
demanding of type annotations?
Greg Weber
On Fri, Jan 20, 2012 at 3:22 PM, Greg Weber wrote:
> 2012/1/18 Simon Peyton-Jones :
>> | > Has *is* a type class. It can be used and abused like any other.
>> | > Record members with the same key ought to ha
2012/1/18 Simon Peyton-Jones :
> | > Has *is* a type class. It can be used and abused like any other.
> | > Record members with the same key ought to have the same semantics; the
> | > programmer must ensure this, not just call them all "x" or the like.
> | >
> | > Weak types these are not. The sel
Thank you Nils for those excellent links.
Yitz would like Agda's module/record setup which allows for multiple
modules in a single file.
Records are yet another local module.
The neat thing is, that like any module you can "open" it, or put it
into the scope of your current module for convenient u
ifficult to work out.
My point is that Has abstractions are weak types and that likely we should
be searching for something stronger or using type classes. If I am wrong
then we should have convincing use cases outlined before we make this a
goal of a records i
I broke out the dot operator section of the proposal to its own page since
it is actually fairly independent of the different proposals.
http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
On Sat, Jan 14, 2012 at 7:26 PM, wren ng thornton wrote:
> On 1/13/12 11:31 PM, Chris Smith wrote
That is a downside the Frege author had - one of the reasons he
abandandoned this style of implementation. It is listed on the wiki.
On Sat, Jan 14, 2012 at 3:28 PM, Jan-Willem Maessen
wrote:
> On Fri, Jan 13, 2012 at 6:52 PM, Simon Peyton-Jones
> wrote:
> > [... good summary of the issues...]
>
On Sat, Jan 14, 2012 at 12:52 AM, Simon Peyton-Jones
wrote:
>
> Complexities of (Plan B)
>
> Proposal (Plan B) sounds innocent enough. But I promise you, it isn't.
> There has ben some mention of the "left-to-right" bias of Frege type
> inference engine; indeed the wohle
>
>
> Let me suggest that a simple non-nuclear alternative would be for people
> interested in Unicode symbols to use an editor that auto converts from
> Haskell Ascii to Haskell Unicode when loading and (of course) back again
> when saving. You can do that today. You can even pick your own Ascii
>
On Thu, Jan 12, 2012 at 6:23 PM, Malcolm Wallace wrote:
>
> On 12 Jan 2012, at 18:41, Evan Laforge wrote:
>
> >>> Unicode dot (∘) would be optimal, since that's what it's for.
> >>
> >> Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.**
> >
> > However, changing the composition
I added this and your Control.Category.<<< to the wiki.
I am not sure about the tuple proposal - tuples normally imply an ordering,
which would imply that all record fields must be accounted for at least
with an empty comma or an underscore, particularly if updating the last
field in a record. For
types the field name).
We do need those very familiar with the GHC internals to weigh in with any
implementation objections.
On Tue, Jan 10, 2012 at 11:42 PM, Isaac Dupree <
m...@isaac.cedarswampstudios.org> wrote:
> On 01/10/2012 05:06 AM, Greg Weber wrote:
>
>> Some of your com
ecord, and generally the field cannot contribute to this effort.
Otherwise the comments have some good ideas and details that I will have
time to look over in more detail and incorporate into the wiki later.
On Mon, Jan 9, 2012 at 6:07 PM, Greg Weber wrote:
>
>
> On Mon, Jan 9, 2012 a
verloading - although there is really no reason why it can't instead
assume name-spacing. TDNR and this record proposal share many of the same
syntax issues you list. Thanks for the detailed feedback! I am travelling
right now, will review when I get a chance.
Greg Weber
__
Thank you for all your feedback! I updated the wiki page accordingly.
Let us stop and take note of what this feedback is about: the most
convenient syntax for manipulating records, and much of this feedback
applies to any records proposal. That is, there are no fundamental
objections to the implem
2012/1/8 Gábor Lehel
>
> >
> >>
> >>
> >>
> >> Later on you write that the names of record fields are only accessible
> >> from the record's namespace and via record syntax, but not from the
> >> global scope. For Haskell I think it would make sense to reverse this
> >> decision. On the one hand,
osal that is awaiting your
critique
The Frege language originally had overloaded record fields but then moved
to the latter system. The existing experience of the Frege language is very
fortunate for us as we now have some experience to help inform our own
decision.
Greg Weber
[1]
struct (after let unrolling etc.)
I think one could do better and guarantee that, if the type of x is
inferrable at all, then so will be x.e (Still, it must be more than just a
type variable.)
On Sun, Jan 1, 2012 at 2:39 PM, Greg Weber wrote:
>
>
> On Sat, Dec 31, 2011 at 3:28 PM, Sim
ashing fields in the same module.
However, without TDNR we don't have convenient access to those fields.
I am contacting the Frege author to see if we can get any more insights on
implementation details.
> Simon
>
> ** **
>
> ** **
>
> We only want critiques about
>
a way that extensible records could be
implemented in its place in the future, although we will not allow that
discussion to hold up a records implementation now, just possibly modify
things slightly.
Greg Weber
On Thu, Dec 29, 2011 at 2:00 PM, Simon Peyton-Jones
wrote:
> | The lack of res
On Wed, Dec 28, 2011 at 3:34 PM, Donn Cave wrote:
> Quoth Greg Weber ,
> > On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave wrote:
> ...
> >> I would think row polymorphism is a must-have.
> >>
> >
> > Perhaps if you want *extensible* records. If you would l
On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave wrote:
> Quoth Greg Weber ,
> ...
> > Many of the built-in record proposals seem more ambitious (create a new
> > record from an existing one, generalize in some other direction). More
> > power or generalization could be very
s a great desugaring solution) we make it the immediate goal
to have records built into the compiler, but done in the simplest (perhaps
least "Extensible") way that just accomplishes name-spacing.
[1] http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf
On Tue, Dec 27, 2011
t returns true iff the argument was constructed
with a data constructor that has field x.
In the Opa language a Module is in fact a Record specially marked as a
module.
What do you think of the Frege system?
On Fri, Dec 23, 2011 at 2:40 PM, Greg Weber wrote:
> I am willing to help on this as m
ant a dot selector, so it is a
good idea for Haskell to require the normal function (composition) dot to
have spaces around it - should this be brought to the Haskell
Prime committee?
Greg Weber
On Fri, Dec 23, 2011 at 1:52 PM, Simon Peyton-Jones
wrote:
> Are Records stalled out again? I am p
How much does using ghc without cabal imply a newer programmer? I don't use
cabal when trying out small bits of code (maybe I should be using ghci),
but am otherwise always using cabal.
On Wed, Nov 9, 2011 at 3:18 AM, Duncan Coutts
wrote:
> On 9 November 2011 00:17, Felipe Almeida Lessa
> wrote:
> to bottom. I’d be strongly inclined to use a proper Map structure if you
> want good performance on that. Is there some reason you don’t want to?
>
> Simon
>
> ** **
>
> *From:* glasgow-haskell-users-boun...@haskell.org [mailto:
> glasgow-haskell-users-boun...@ha
We have a couple use cases in Yesod that can potentially match many
different patterns. Routing connects the url of an http request to a Haskell
function. The current code just uses a pattern match, which scales linearly.
So if a site has a hundred different routes (urls), it could take 100
compari
it isn't.
On Thu, Sep 15, 2011 at 8:15 AM, Christopher Done
wrote:
> 2011/9/15 Greg Weber :
> > Chris, Thank you for the real word experience report. I had assumed
> (because
> > everyone else told me) that importing qualified would be much, much
> better
> > than
Chris, Thank you for the real word experience report. I had assumed (because
everyone else told me) that importing qualified would be much, much better
than prefixing. I had thought that in your case since you are big on model
separation that you would have liked having a separate file for each mod
I am informed that the google gold linker does not like relative paths
https://bugzilla.redhat.com/show_bug.cgi?id=635935
I uninstalled the gold linker and all is well now.
On Wed, Sep 14, 2011 at 9:11 PM, Greg Weber wrote:
> I just cloned GHC from github and tried to build it for the fi
I just cloned GHC from github and tried to build it for the first time. I
get the below result where the build tool says that existing object files
are missing. I haven't touched a Makefile in a long time- help here is very
appreciated.
===--- building final phase
make -r --no-print-directory -f g
72 matches
Mail list logo
