On *Thu Nov 29 15:00:19 UTC 2018, Doug McIlroy wrote:*
> >* Frankly after you've filtered out all that, I'd be astonished if you**
have anything left. It seems to be usual practice on Hackage to switch** on
a swag of LANGUAGE pragmas even if this module isn't using them.*
>>* (MPTCs,
*On 2018-11-28 14:03:30 UTC, **Mario Blažević wrote:*
>> On 2018-11-28 2:17 a.m., Jurriaan Hage wrote:
>
>>* do we actually have something like an extensive set of tests*
>>* to throw at any Haskell 2010 compliant compiler that would help find
>>mistakes on our parr?*
> If you want to be
s for Haskell,
> Rodrigo Ribeiro, Carlos Camarão, Lucília Figueiredo, Cristiano
> Vasconcellos,
> SBLP'2016 (20th Brazilian Symposium on Programming Languages),
> Marília, SP, September 19-23, 2016.
>
> [2]
>
> https://github.com/carlos1camarao/ghc-propo
On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote
You may be interested in Carlos Camarao’s interesting work. For a long
> time now he has advocated (in effect) making each function into its own
> type class, rather that grouping them into classes. Perhaps that is in
> line with your
"class" and "method". Since Helium has a focus
on Haskell learners/beginners: I wonder how much confusion we might have
saved those coming from OOP where the terms mean something really quite
different. We might have avoided "class" altogether; and talked of
"overl
r achieving both
> these directions.
>
I don't think there's any solution for achieving "satisfy the xxx laws".
AntC
> čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden <
> anthony_clay...@clear.net.nz> napsal:
>
>> > We are adding classes and instances to Heli
On Fri, 5 Oct 2018 at 9:00 PM, Jurriaan Hage wrote:
>
> We first go the slavish route, to provide a basis for changing things
> later.
Ah. That comment seemed strange, but I've just read up on Helium: you're
aiming to provide a beginners' environment for Haskell.
Then without type classes,
ider at this time is GADTs,
I do find the (~) type equality constraints from GADTs/Type Families very
pleasing and intuitive. You might be able to implement that without all the
other paraphernalia.
AntC
> > On 4Oct, 2018, at 03:55, Anthony Clayden
> wrote:
> >
> > > W
> There was no Haskell 2020 meeting this year at ICFP. Sadly, interest
seems to have waned here...
Yes that is sad. So either Haskell 2020 won't happen, or it'll be only
minor tweaks over H2010, as that was over H98.
It's hard to imagine any serious Haskelling without
> We are adding classes and instances to Helium.
> We wondered about the aspect that it is allowed to have a class instance
> of which not all fields have a piece of code/value associated with them, ...
I have a suggestion for that. But first let me understand where you're
going with Helium.
> On Fri Sep 8 15:58:10 UTC 2017, Carter Schonwald wrote:
>
> I mostly wanted to confirm that we in fact will actually
say yes
> before doing the formal writtingup :)
Seriously -- and please stop using smileys:
you're right to be cautious.
You need to rewrite the whole of Section 6.4
(nearly 5
GADTs (for example) have been in GHC
far longer.
OK it's bit naughty GHC doesn't have a flag
for something that's not compliant to the report.
But that's a GHC issue, not a grounds for changing
the language spec.
AntC
>
>> On 8 Sep 2017 8:35 am, "Anthony Clayden" wrote:
> On 2017-09-08 at 08:43 AM, Herbert RIedel wrote:
Thank you Herbert for the explanation.
>> On 2017-09-08 at 09:19:54 +0200, Anthony Clayden wrote:
>
> [...]
>
> I can see how the proliferation of committees & github
> repos may seem confusing to casual observers,
I'm baffled. Is this some sort of 'in' joke at ICFP?
Then remember the rest of the world can see this list.
> All yays from committee members please reply with yes to
this email :)
If this is to the committee, shouldn't it be on the
committee list?
(I mean ghc-steering-committee.)
Or is there
... I'm struggling to see why people
are fighting so hard to get the dot character in
particular for field access. It seems like a huge amount
of work and discussion for a tiny bit of syntactic
convenience that we've only come to expect because of
exposure to other very different languages.
Sorry for the late reply.
Thanks Oleg, I take it the Northern hemisphere is now on
academic summer holidays.
[snip]
Finally, I still think most of the magic in everything
we've been talking about boils down to being able to
have a type variable that can take on any type *except*
a
,
Anthony Clayden wrote:
Totally brilliant, and almost impenetrable.
If I understand what's going on (big IF), I'm wondering a
few things:
- You've used type-level NAT to encode the type.
What if two different types get encoded as the same NAT?
In your MonadState example you've
Thank you Oleg
I have implemented type-level TYPEREP (along with a small
library for
higher-order functional programming at the type level).
Overlapping
instances may indeed be avoided. The library does not use
functional
dependencies either.
So this is essentially the
Hi all
THE TOPIC: [from the original post]
TypeFamilies vs. FunctionalDependencies type-level
recursion
David Mazieres dm-list-haskell-prime at scs.stanford.edu
Sun May 29 20:59:44 CEST 2011
... GHC is on its way to accepting a ~ b as a constraint
that
types a and b are equal. If there were
Isaac Dupree m...@... writes:
On 02/24/10 13:40, Martijn van Steenbergen wrote:
Ian Lynagh wrote:
I have a feeling I'm in the minority, but I find record punning an ugly
feature.
Given
data T = C { f :: Int }
we implicitly get
f :: T - Int
which punning shadows with
f :: Int
20 matches
Mail list logo
