Friends
Provoked the (very constructive) Yesod blog post on "Limitations of Haskell",
and the follow up discussion, I've started a wiki page to collect whatever
ideas we have about the name spacing issue for record fields.
http://hackage.haskell.org/trac/ghc/wiki/Records
As Sim
I added my evaluation of the module-based approach to existing
records, but on second thoughts it's maybe inappropriate, so I'll post
it here. I saw that some people commented on the reddit discussion
that the solution is to put your types in separate modules but it
doesn't seem that anyone has tri
As formulated on the wiki page, the "narrow issue" is a problem without a good
solution. The reason the community rejected TDNR is because it's basically
polymorphism done wrong. Since we already have polymorphism done right, why
would we want it?
The right way to deal with records is first to
On Thu, Sep 15, 2011 at 6:03 AM, Barney Hilken wrote:
> The right way to deal with records is first to agree a mechanism for
> writing a context which means
>
> "a is a datatype with a field named n of type b"
>
> then give the selector n the type
>
> "a is a datatype with a field na
TRex is already mentioned on the wiki as coming at a too high
implementation cost.
2011/9/15 J. Garrett Morris :
> On Thu, Sep 15, 2011 at 6:03 AM, Barney Hilken wrote:
>> The right way to deal with records is first to agree a mechanism for
>> writing a context which means
>>
>> "a is a da
I'm trying to set up a build/test environment on Windows.
Building ghc (sh validate) fails after a while due to flex and bison
crashing. Those two come with git and even
$ flex --version
(or bison) crashes, so they seem truly hosed.
Do I need flex/bison at all to build ghc?
It seems they're not
On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote:
>
> Provoked the (very constructive) Yesod blog post on "Limitations of Haskell",
> and the follow up discussion, I've started a wiki page to collect whatever
> ideas we have about the name spacing issue for record fields.
>
>
J Garrett Morris asked me
| I also rather like the TDNR proposal, as it's rather similar to the
| approach we're taking in Habit (our pet language at Portland State).
| However, I'm curious as to why you don't want to quantify over name
| resolution constraints. For example, why shouldn't:
|
| x
I personally really like the proposal here:
http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html
The wiki doesn't show any opposition to this system. If Haskell had
that record system now I would be very happy and would be fine with
leaving other record systems as purely rese
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
On Thu, Sep 15, 2011 at 7:51 AM, Simon Peyton-Jones
wrote:
> class Select (rec :: *) (fld :: String) where
> type ResTy rec fld:: *
> get :: rec -> ResTy rec fld
>
> data T = MkT { x,y :: Int }
> instance Select T "x" where
> get (MkT {x = v}) = v
>
> And now we desugar
> f.x
> as
> get
Hi
I have some long running (multi-gigabit, multi-cpu hour) programs and
as part of trying to speed up I thought I would set the -V0 flag -
when I did this there was a slow space leak that caused it to blow the
heap.
Anyone out there have an explanation? Is there some garbage collection
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 prefixing. I had thought that in your case since you are big on model
> separation that you would have liked havi
I should be clear that in my counter point I am using Ruby, not Haskell on
those projects. In Ruby one can use a string for the name of a class (which
will be evaluated later) and other general dynamic typing tricks to avoid
cyclical dependencies.
I have worked on one large Yesod project. I felt t
2011/9/15 Greg Weber :
> I should be clear that in my counter point I am using Ruby, not Haskell on
> those projects. In Ruby one can use a string for the name of a class (which
> will be evaluated later) and other general dynamic typing tricks to avoid
> cyclical dependencies.
Ah, okay. Sure, lat
Here is a simple concrete proposal:
Nonextensible records with polymorphic selectors.
=
1. Introduce a built-in class Label, whose members are strings at the type
level. We need a notation for them; I will use double single quotes, so
''string'' i
>From Daniel Fischer:
> I'm trying to set up a build/test environment on Windows.
> Building ghc (sh validate) fails after a while due to flex and bison
> crashing. Those two come with git and even
> $ flex --version
> (or bison) crashes, so they seem truly hosed.
> Do I need flex/bison at all t
Typos in my last message: the identifier "field" should be "Field" throughout,
and "undef" should be "undefined". Here is the corrected version:
Nonextensible records with polymorphic selectors.
=
1. Introduce a built-in class Label, whose members
On Thursday 15 September 2011, 21:41:10, Bill Tutt wrote:
> From Daniel Fischer:
> > I'm trying to set up a build/test environment on Windows.
> >
> > Building ghc (sh validate) fails after a while due to flex and bison
> > crashing. Those two come with git and even
> > $ flex --version
> > (or bi
On Thu, Sep 15, 2011 at 6:00 PM, Daniel Fischer
wrote:
>>
>> flex appears to be required from integer-gmp's ./configure for one of
>> GMP's demo programs. (a calculator demo I think)
>
> I can't find anything indicating that on linux, so it'd be probably be due
> to using the in-tree gmp on Window
On Thu, Sep 15, 2011 at 9:01 PM, Bill Tutt wrote:
>
> I ended up getting an error during stage 2 about the iconv.dll not
> being findable. (I'm guessing the new msys/mingw autosmarted GHC
> boot/configure or cabal configure process somehow )
>
Yep. This is most likely the problem. -liconv was
> It ''also'' demonstrated, to me, that qualified imports are horrible
> when used on a large scale. It happened all the time, that'd I'd
> import, say, 10 different data types all qualified. Typing map
> (Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious
> and distracting, especi
Bill:
It might also be the case that you're seeing the same issue as ghci not finding
the stdc++ library. The solution may be as simple as hacking the Makefile is
nail a specific PATH to where iconv.dll is located. But, I'm not in front of a
development box, so I can't be of much help.
-scoot
Hi,
It would be useful to access the current compilation parameters or even
an entire RunGhc monad from inside a Template Haskell splice. Is there
any way to do this?
The reason I want to do this is I'm using the ghc API at runtime to
dynamically execute code, and I want both the dynamically load
On 15/09/2011 15:43, Ian Lynagh wrote:
> On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote:
>>
>> Provoked the (very constructive) Yesod blog post on "Limitations of
>> Haskell", and the follow up discussion, I've started a wiki page to collect
>> whatever ideas we have about the
25 matches
Mail list logo
