Re: GHC Logo
Ben, what if we have someone draw a cartoony version of your box turtle? i feel like that would be a pretty cute logo! totally ahistorical, but would certainly be cute! On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov wrote: > Hi, > > Is it a contest for picking up a new logo? > As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here > means Haskell. > > So logo should be GλC. > > Best Regards, > Daniil. > > On Sat, Aug 15, 2020, 8:50 AM Ben Gamari wrote: > >> Hi everyone, >> >> Recently a sponsor asked for a logo for our project. As far as I know, >> GHC doesn't really have a consistent logo; the closest that we have had >> is the stylized "GHC" on the top of ghc.haskell.org. >> >> To accomodate the request, I took a few minutes and reworked the >> typography of the Thompson-Wheeler Haskell logo for use by GHC. I >> couldn't positively identify the typeface used for the "Haskell" text, >> but I believe that the extra-bold Cantarell face that I chose in the GHC >> variant has a similar feel to the Haskell logo and is free to use. >> >> I've posted the logo on the Wiki for future reference [1]. Feedback is >> very much welcome. >> >> Cheers, >> >> - Ben >> >> >> >> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Logo
Hi, Is it a contest for picking up a new logo? As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here means Haskell. So logo should be GλC. Best Regards, Daniil. On Sat, Aug 15, 2020, 8:50 AM Ben Gamari wrote: > Hi everyone, > > Recently a sponsor asked for a logo for our project. As far as I know, > GHC doesn't really have a consistent logo; the closest that we have had > is the stylized "GHC" on the top of ghc.haskell.org. > > To accomodate the request, I took a few minutes and reworked the > typography of the Thompson-Wheeler Haskell logo for use by GHC. I > couldn't positively identify the typeface used for the "Haskell" text, > but I believe that the extra-bold Cantarell face that I chose in the GHC > variant has a similar feel to the Haskell logo and is free to use. > > I've posted the logo on the Wiki for future reference [1]. Feedback is > very much welcome. > > Cheers, > > - Ben > > > > [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Logo
Late to the party here, but I'm wondering whether we can enlist someone with graphic design experience to create a more iconic logo for the compiler. I use the word "iconic" deliberately: it should both be recognizable, and in the shape of an icon (that is, more square). The Haskell logo does this wonderfully, but I think Ben's proposal just appends GHC to that. My own preference would be to retain a connection with the Haskell logo (as Ben's submission does), but that needn't be a hard requirement. Thanks, Richard > On Aug 16, 2020, at 2:30 PM, Ben Gamari wrote: > > Merijn Verstraaten writes: > >>> On 16 Aug 2020, at 16:02, Ben Gamari wrote: >>> >>> Carter Schonwald writes: >>> I def like the serif / times new Roman version >>> I'm not aware of a serif version and in general I would be hesitant to >>> introduce one given that: >> >> The one you send out renders using a serif font for GHC on my system (and, >> presumably, Carter's). >> > Indeed, sounds like a missing font. The typeface used is Cantarell, > which is certainly a sans-serif face. You will find a version on the > Wiki which has had the text projected to paths. > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: COMPLETE pragmas
Am Dienstag, den 01.09.2020, 10:11 +0200 schrieb Sebastian Graf: > > 2.) Another scenario that I'd really love to see supported with > > COMPLETE pragmas is a way to use | notation with them like you can > > with MINIMAL pragmas. > > (2) is a neat idea, but requires a GHC proposal I'm not currently > willing to get into. I can also see a design discussion around > allowing arbitrary "formulas" (e.g., not only what is effectively > CNF). > > A big bonus of your design is that it's really easy to integrate into > the current implementation, which is what I'd gladly do in case such > a proposal would get accepted. in the original ticket where a COMPLETE pragma was suggested ( https://gitlab.haskell.org/ghc/ghc/-/issues/8779) the ability to specify arbitrary boolean formulas was already present: “So here is what I think might work well, inspired by the new MINIMAL pragma: … The syntax is essentially the same as for MINIMAL, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case” So one _could_ say that this doesn’t need a proposal, because it would just be the implementation finishing the original task ;-) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: COMPLETE pragmas
Hi Edward,
I'd expect (1) to work after fixing #14422/#18276.
(3) might have been https://gitlab.haskell.org/ghc/ghc/-/issues/16682, so
it should be fixed nowadays.
(2) is a neat idea, but requires a GHC proposal I'm not currently willing
to get into. I can also see a design discussion around allowing arbitrary
"formulas" (e.g., not only what is effectively CNF).
A big bonus of your design is that it's really easy to integrate into the
current implementation, which is what I'd gladly do in case such a proposal
would get accepted.
Cheers
Sebastian
Am Di., 1. Sept. 2020 um 00:26 Uhr schrieb Edward Kmett :
> I'd be over the moon with happiness if I could hang COMPLETE pragmas on
> polymorphic types.
>
> I have 3 major issues with COMPLETE as it exists.
>
> 1.) Is what is mentioned here:
>
> Examples for me come up when trying to build a completely unboxed 'linear'
> library using backpack. In the end I want/need to supply a pattern synonym
> that works over, say, all the 2d vector types, extracting their elements,
> but right now I just get spammed by incomplete coverage warnings.
>
> type family Elem t :: Type
> class D2 where
> _V2 :: Iso' t (Elem t, Elem t)
>
> pattern V2 :: D2 t => Elem t -> Elem t -> t
> pattern V2 a b <- (view _V2 -> (a,b)) where
> V2 a b = review _V2 (a,b)
>
> There is no way to hang a COMPLETE pragma on that.
>
> 2.) Another scenario that I'd really love to see supported with COMPLETE
> pragmas is a way to use | notation with them like you can with MINIMAL
> pragmas.
>
> If you make smart constructors for a dozen constructors in your term type
> (don't judge me!), you wind up needing 2^12 COMPLETE pragmas to describe
> all the ways you might mix regular and start constructors today.
>
> {# COMPLETE (Lam | LAM), (Var | VAR), ... #-}
>
> would let you get away with a single such definition. This comes up when
> you have some kind of monoid that acts on terms and you want to push it
> down through
> the syntax tree invisibly to the user. Explicit substitutions, shifts in
> position in response to source code edits, etc.
>
> 3.) I had one other major usecase where I failed to be able to use a
> COMPLETE pragma:
>
> type Option a = (# a | (##) #)
>
> pattern Some :: a -> Option a
> pattern Some a = (# a | #)
>
> pattern None :: Option a
> pattern None = (# | (##) #)
>
> {-# COMPLETE Some, None #-}
>
> These worked _within_ a module, but was forgotten across module
> boundaries, which forced me to rather drastically change the module
> structure of a package, but it sounds a lot like the issue being discussed.
> No types to hang it on in the interface file. With the ability to define
> unlifted newtypes I guess this last one is less of a concern now?
>
> -Edward
>
> On Mon, Aug 31, 2020 at 2:29 PM Richard Eisenberg
> wrote:
>
>> Hooray Sebastian!
>>
>> Somehow, I knew cluing you into this conundrum would help find a
>> solution. The approach you describe sounds quite plausible.
>>
>> Yet: types *do* matter, of course. So, I suppose the trick is this: have
>> the COMPLETE sets operate independent of types, but then use types in the
>> PM-checker when determining impossible cases? And, about your idea for
>> having pattern synonyms store pointers to their COMPLETE sets: I think data
>> constructors can also participate. But maybe there is always at least one
>> pattern synonym (which would be a reasonable restriction), so I guess you
>> can look at the pattern-match as a whole and use the pattern synonym to
>> find the relevant COMPLETE set(s).
>>
>> Thanks for taking a look!
>> Richard
>>
>> On Aug 31, 2020, at 4:23 PM, Sebastian Graf wrote:
>>
>> Hi Richard,
>>
>> Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenberg <
>> r...@richarde.dev>:
>>
>>> Hi Sebastian,
>>>
>>> I enjoyed your presentation last week at ICFP!
>>>
>>
>> Thank you :) I'm glad you liked it!
>>
>> This thread (
>>> https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms)
>>> played out before you became so interested in pattern-match coverage. I'd
>>> be curious for your thoughts there -- do you agree with the conclusions in
>>> the thread?
>>>
>>
>> I vaguely remember reading this thread. As you write there
>>
>>
>> And, while I know it doesn't work today, what's wrong (in theory) with
>>>
>>> {-# COMPLETE LL #-}
>>>
>>> No types! (That's a rare thing for me to extol...)
>>>
>>> I feel I must be missing something here.
>>>
>>
>> Without reading the whole thread, I think that solution is very possible.
>> The thread goes on to state that we currently attach COMPLETE sets to type
>> constructors, but that is only an implementational thing. I asked Matt (who
>> implemented it) somewhere and he said the only reason to attach it to type
>> constructors was because it was the easiest way to im
